Granted, I'm mostly familiar with the Scandinavian bit of Europe, but you can't do jack shit with banking without 2FA which is tied into the national population register.

They decided in the 80ies or 90ies that "relying on knowing secret fixed magic numbers" was not ideal for authenticating people, and sat down and worked out solutions to that problem.

Probably unrelated, no mention of Millennium.

lack of synthetic pesticides, you can use as much organic pesticides as you want.

Order a ticket online, they pick the transliteration for ø as o, passports transliterate ø to oe - the less ambiguous choice. This generally isn't a problem until you want to travel to one of the APIS countries - USA or UK, which won't let you check in if the name on your passport doesn't match the name on the ticket.

I have tormented many check-in counter staff with this, especially at regional airports that don't see a lot of international travel.

And yes - this is partially a maturity thing, although more in the sense in that the embedded ecosystem is very vendor specific, and you're traveling outside the path the vendor forged for you, so you'll be an early trailblazer - you get to deal with all the integration shit, rather than finding some other random person on the internet that's dealt with something similar.

(And it's not necessarily that the vendors path is all that great, but at least there's a whole collection of other people that's struggled with it and posted about it online).

Our professor in college was livid when we suggested not using the vendors toolchain (back in the early 2000's), "yes $vendor's toolchain is broken and shit, but it's marginally less broken and shit than $non-vendor toolchain".

So yea - great stuff!

Generally - both the tcp checksum and the 802.11/Ethernet CRC isn't all that strong, so it's entirely within the realm of possibility of having bitflip patterns that fool both.

Regarding recovery: The FTL is likely toast, in which case while the data probably is unharmed and there, it's basically a giant block-sized jigsaw puzzle. With enough effort, and all the stars align - sure, you might be able to recover some/all of it.

Regarding un-bricking/reset: Potentially, no longer any access to wear-levels at the time. So the future integrity/reliability is kind-of dubious.

Control software, or for that matter, software for a sufficiently narrow domain, tends to come "with bugs" and "for compatibility reasons you need to run this on OS/release version X (which is probably what the vendor ran at the point in time when the software were minted/released).

I've had the displeasure of crossing paths with both the linux and windows variety of this.

In some cases you can ignore the vendors and just upgrade, and jump through some amount of hoops to make it work.

I'm sure in most cases you could engineer around this with isolating it from the world, although it may be non-trivial since it'll probably want to communicate over a network of some sort. Although - exactly what is needed in terms of achieving that may be less than well documented, it costs time and money, and is maybe not really budgeted for, there's aggressive installation timelines, and the security part is probably the first thing to get slashed from when the installation timelines starts slipping.

The vendor just wants to sell you a black box, and preferably not touch it ever again after they've sold it to you. (Actually - some even do sell you a branded, badly engineered, stock PC running some variety of windows or linux or bsd, to control your winch/navigation/foundry/whatnot).

I have witnessed "IT for offshore", in which a vessel is docked for X days, here's a list of things that we need to do, after X days the vessel will depart. You may have a few days on top of X days if you can leave somebody at the vessel, after X+Y days, the vessel needs to be somewhere in an operable state, because we have a commissioned work to perform.

For say running a foundry, I'm sure much of this is similar, except the foundry doesn't have go anywhere - but having your foundry do nothing is exceedingly expensive, and making changes during production comes with a different set of risks.

People have probably complained somewhere along the road, disagreeing with the risks, and somewhere higher up in the chain, the choice were made to take on the risk.

Assuming that you run with 3 failure domains, and only maintain one failure domain at a time. Noout mostly gets the job done. What it doesn't do for you is save you from an actual failure in a different failure domain during maintenance. EC pools & k+(m>=2) or replication > 3 - would cover this as well.

We've had mostly great success with noout + maintain failure domain at a time, wait for recovery, proceed to next failure domain, repeat until done. To the point where we've been comfortable leaving a lot of the babysitting & work to machines.

> Only signals for which the "init" process has established a signal handler can be sent to the "init" process by other members of the PID namespace. This restriction applies even to privileged processes, and prevents other members of the PID namespace from accidentally killing the "init" process.

> Likewise, a process in an ancestor namespace can—subject to the usual permission checks described in kill(2)—send signals to the "init" process of a child PID namespace only if the "init" process has established a handler for that signal.

The story behind that were something along the lines of, according to legend, if Nidaros Cathedral ever were finished, Trondheim would be swept into the ocean by clay/land-slide, hence, there's a missing brick that'll never be laid.