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.

https://www.sidnlabs.nl/en/news-and-blogs/can-we-do-without-...

AAAA record resolution is the real bottleneck for adoption. Once you have dual stack working, I did a real-world, simple test: Release your ISP IPv4 DHCP lease on the router (kill udhcpc) and flush DNS on your hosts. Now all public DNS lookups must resolve to a IPv6 domain. You will very quickly find many domains on the Internet still don't have AAAA records. Lots of popular services will simply fail to resolve their hard coded domains. QED.

https://whynoipv6.com/

I was thinking about the same thing. Such a classic!

I fully expected the smoke alarm CW key to work by picking up smoke signals: https://sites.google.com/site/oh6dccw/smoke-alarm-cw-key

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.

https://hackaday.com/2020/08/01/playing-the-pixelflut/

At GPN23 there was also Pixelebbe which was much fun!

https://pixeleb.be/

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.

A lot of older 17" laptops had dual HDD slots.

Or DVD drives in which you could add a disk caddy.

Ah yes, optical drives were very common for a while.

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.

That’s the best one of the lot. "Dein Name ist ungültig", "Your name is invalid", written with the informal word for "your".

They're trying to say that you and the server are very close friends, you see? No, no, I get this is not correct, just a joke...

Formal pronouns in German are on their way out anyway, including in but not limited to software interfaces.

It's only insulting if you want to be insulted. You'd do better learning to understand that its a computer system and not a personal attack.

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.

Why stop there? Probes traverse the whole TCP/IP stack, best to stop them early at layer 1: https://www.bit.nl/news/115/88/Cut-here-to-activate-firewall...

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 one appears to have been published in the summer of 2024.

"Summer" in certain parts of the world, at least.

Sharp!

For a while (currently?) there was SEO "wisdom" going around about not putting dates on content so that search engines would treat the content as "evergreen" rather than "stale".

There's a related trend of updating the publish date so it's always today, or recent.

Thanks! The irony is not missed on me. I think I have the dates internally in the article metadata, just didn't set up my Hugo templates to display it. TODO!

Ah, so it wasn’t some SEO trick (see your sibling comment) after all :)

Thanks for the fun and informative blog post!

I figured I'd check the RSS feed to see the timestamp there, only to discover that this "blog" doesn't even have a feed!

Seems like pretty timeless content to me.

There's a couple of things that made me think the article was way older than it actually is (and made me mildly irritated that it doesn't include the publication date).

First off, the author starts off by talking about GMT and goes on to educate the reader how UTC is actually the current standard. Maybe it's just me but I thought this would be common knowledge by now, while the author frames this as some sort of a revelation.

Then there's the jab about The IERS breaking Wikipedia's css which just doesn't seem to happen on the two devices I opened it on, so I assumed that was the case prior to Wikipedia's redesign.

Minor things for sure, and the content itself is pretty timeless (heh).

Leap seconds are also set to be removed eventually. UTC will become UT1 with a fixed offset, at least until enough seconds add up for the BIPM to care about the offset and insert a leap minute or hour or something TBD.

> UTC will become UT1 with a fixed offset

I'm not sure what you mean, but this sounds wrong. The whole thing about leap second abolishment is to effectively disconnect UTC from UT1, i.e. allow DUT1 to grow unbounded and make UTC a fixed offset of TAI.

Right, swapped UT1 and TAI in my head. Oops!

While there's no explicit publication date, there are a few shell commands which strongly imply that the blogger was writing on or about "Tue Jul 30 23:52:11 UTC 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.

If you're writing scripts, use that and don't forget -e and -u

  -e      Exit  immediately if a pipeline (which may consist of a single simple command), a list, or a compound command (see SHELL GRAMMAR above), exits with a non-zero status

  -u      Treat  unset variables and parameters other than the special parameters "@" and "*" as an error when performing parameter expansion

For `set -u` I mostly agree. For `set -e` see my comment below and Greg's wiki: http://mywiki.wooledge.org/BashFAQ/105

> and they still fail to catch even some remarkably simple cases

I totally agree. Although I'd say that there isn't anything "remarkably simple" about writing a bash script. Anything in the shell scripting world that seems remarkably simple is just because one hasn't realised the ghosts and horrors that lurk in the shadows.

But I'll use -e anytime. It feels like having a protective proton pack at least.

Does it? It is not mentioned anywhere in the post. Can you post a reference to your source?

The post only have a few highlights. The Posix specs are only for paying IEEE customers though, but https://pubs.opengroup.org/onlinepubs/9799919799/ mentions it.

That is the POSIX spec, no?

It's at: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...

(no permalink, search for "pipefail")

Holy balls that's like Christmas!

Really? Wont that break piping grep?

Probably, so don't `set -o pipefail` in scripts that pipe into grep.

Ah ok I read it as 'sets it by default' for some reason.

I'd rather both have this option and have it work reliably. It's ridiculous that

    export VAR=$(cmd1 | cmd2)

does not count as a pipefail when cmd1 or cmd2 fail but

    VAR=$(cmd1 | cmd2)

does, so the "correct" way to set an environment variable from a pipeline's output is actually

    VAR=$(cmd1 | cmd2)
    export VAR

Pipefail is useful and very hard to emulate on pure POSIX; you need to create named fifos, break the pipeline into individual redirections and check for error on each line.

And that is fine; but sometimes you want to treat a pipeline as a "single command" and then you can use pipefail to abort the pipeline on error. Then you can handle the error at the granularity of the entire pipeline without caring which part failed.

Lastly, I am confused as to the "silent" failures; maybe you are thinking of combining this with `set -e`? Then yes, that is bad and I recommend against the combination; but then again, I and most advanced scripters recommend against shotgunning `set -e` in the first place. Use it in specific portions of the script when appropriate, and use proper error handling otherwise.

Why does `set -e` make a pipeline fail silently?

`set -e` makes the script abort and is often used in lieu of proper error handing:

  set -e
  command
  command [fails]
  command

Whether the above reports error or not depends on the command; when you have a pipeline failing in the above way, it is even sneakier:

  set -e
  command
  command | command | command [fails]
  command

You are reliant on all commands in the pipeline being verbose about failure to signal error.

None of the above is advisable. The advisable code is

  error_handler() { proper error handling; }

  command || error_handler "parameter"
  command || error_handler "parameter"

  { command | command | command; } || error_handler "parameter"

  {
  set -e
  exceptional section that needs to be bailed out
  set +e
  }

  command || error_handler "parameter"

Error handling like that makes sense if you’re writing a program. But if you just want a script for an automation, `set -e` is enough.

It is not; Greg's wiki further explains why, if the silent failure problem above is not enough reason.

Gee, imagine if shells with errexit option enabled wrote some diagnostic output to stderr before exiting. "Add your own error checking instead", how do I check which piece of pipeline has failed, exactly? The PIPESTATUS variable is bash-specific and was not standardized.

? Why are you replying to me? My position was pretty clear:

"Pipefail is useful and very hard to emulate on pure POSIX; you need to create named fifos, break the pipeline into individual redirections and check for error on each line.

And that is fine; but sometimes you want to treat a pipeline as a "single command" and then you can use pipefail to abort the pipeline on error. Then you can handle the error at the granularity of the entire pipeline without caring which part failed."

By the way, I never script in Bash; I only script in POSIX primitives using dash as my executable.