My former colleague Marco Davids from SIDN Labs (the R&D department at the .nl TLD operator) did an experiment in 2021 where he actively disabled IPv4 support on all components in his test network, even disabling the complete IPv4 stack in the FreeBSD kernel (not possible on Linux, at least not at the time). So far, his test is the only thing I know of that came close to an authentic simulation of an IPv6-only world.
Reminds me of the Pixelflut LED display. The hacker camp SHA2017 had one above a bar, 36C3 had one as well. Their traffic peaked at 4 Gbit/s and 30 Gbit/s respectively.
And: they have a crash cart (keyboard, mouse and display) and battery backup built-in. An old laptop is perfect for starting a homelab. The only major downside I can think of, and as another commenter already mentioned, is the limited storage (RAID) options.
While I agree with you that an error message like this should not be taken as a personal attack, it still causes a horrible user experience. It’s not like the developers of these systems had no choice in the wording of these errors: they picked the insensitive computer-says-no option, while they could have went with an apologetic “Sorry, our system does not support special characters” instead.
A system not supporting non-latin characters in personal names is pitiful, but a system telling the user that they have an invalid name is outright insulting.
I find it slightly ironic that a blog that’s educating (and entertaining) us on time and timezones does not itself mention when its blogposts were published, at least on mobile.
This one appears to have been published in the summer of 2024.
This adds `set -o pipefail` to POSIX sh, which causes a whole pipeline to fail (non-zero exit code) if one or more of the commands in the pipeline fail.
I wonder if this "all GNU/Linux systems" is correct, or if we'll see some nuance added in a couple of hours/days. I'd be a monstrous patch day if this RCE really impacts all GNU/Linux systems.
> The worst is when a request starts out simple — I help them fix one hallucination — but then that customer wants to build more complex logic, and somehow I’ve set the expectation that I will provide unlimited free support forever. I’ve gotten a number of angry messages from customers who essentially want me to build their whole app for free.
Annoying, but a good way to weed out bad customers. Life’s too short to deal with people who feel this entitled.
A larger battery and more solar panels doesn’t seem to be an option for the authors:
> The modern stack doesn't really work for us, it doesn't apply to the limitations that we have on the boat. We have 180 watts of solar. We just spent the whole summer with two 6-volt batteries, which is very small. When you're going down that route, at every turn people are telling to just put more solar panels, or to buy more batteries. That is such a modern way of solving your problem. In reality, technology like this(especially high-tech) rarely solves problems. It creates a lot of other problems, which on a sailboat is very immediate. Putting more solar would mean more windage, more chance of things flying off and cutting our limbs. More batteries would mean the boat would be heavier, it would stop us from being able to run away from storms.
Reminded me of the Internet Beer Tap by Techinc, a hacker space in Amsterdam:
> Once upon a time, a lovely piece of Purple networking hardware got pushed into the obscene job of having to function in tapping the internet for law-enforcement purposes.
After liberating the quarter-million-dollar-networking-switch, we have taken it upon ourselves to offer it a worthy retirement plan that allows it to re-socialize itself.
The Internet Beer Tap became a fact.
They provide a good reason for completely removing the DSA code:
> We are also likely to start exploring a post-quantum
signature algorithm soon and are mindful of the overall size and complexity of the key/signature code.
Vulnerabilities like heartbleed and Log4Shell is what you get when you have limited developer capacity but insist on endlessly keeping legacy code around.
https://www.sidnlabs.nl/en/news-and-blogs/can-we-do-without-...