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.
I was struck by how similar this seems to Ceph/RADOS/RBD. I.e. how they implemented snapshotted block storage on top, sounds more or less exactly the same as how RBD is implemented on top of RADOS in ceph.
I'll add another airline story. SAS, the Scandinavian flag carrier - which you'd think would have Scandinavian characters down. I've had an account with them since, well, they got a web presence. My last name contains an ø - for which; technically at least Norway accepts both o and oe as valid transliterations.
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.
It's likely not just the English speakers - assuming this is the same way as it is in Norway - even if you tried to learn the language, you'll still struggle with the native speakers "just using English as it's more efficient with both being proficient". I witnessed this in the workplace, and I heard plenty of anecdotes from the local college where PhD students struggling with learning Norwegian for the same reason, and last but not least I've done this myself.
For matter/thread you'll likely even have to go the other way around - link to your thing written in rust from your matter/thread project.
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".
Or just changing tax residency. Moving from Norway to the US, brokerages will tell you to liquidate your assets or they'll do it for you, because they do not want to touch the reporting requirements to the US.
"It depends" - Your NIC could be doing some tcp offload for you, at which point any checksum you'd observe with tcpdump/wireshark would be flat out wrong.
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.
> Likewise, I'm skeptical of "neither the SSD nor the data can be recovered" --- they just want you to buy a new one.
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.
Norway used to at least have bridges built to be easily rigged (they may have been rigged for all I know at some point as well). That fell out of favor "some time ago", and apparently there was recently(-ish) questions about resuming the practice again.
It might. Using Opus does not equate to low audio latency. (I don't actually know Opus, but I have passing familiarity with it's predecessor speex). Assuming Opus has the same design goals as speex, Opus gives you the tools necessary to implement a low-latency audio application. As in - the audio codec piece is "solved", now you need to do the engineering work around client/server/framing/network etc. to actually get to your latency goals.
The problem isn't just windows - it's more along the lines of "narrow software" being very much sold "as is" with "strict and boneheaded compatibility requirements (run known vulnerable software/os)", combined with either consciously or unconsciously taking on the risk of doing so, with or without appropriate mitigations in place.
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.
The video did talk about rather low-tech solutions, constrict the movement of one of your knees lightly by putting a bandage round it, or stick a pebble in your shoe.
I've used ceph since firefly - and noout existed back then as well.
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.
No mention of linux' pid_namespaces documentation ?
> 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.
[Gross oversimplification] Nope - insurers are incentivized to pay as little as they can get away with. Which leads to healthcare providers being incentivized to bill the insurers as much as they can get away with. They'll meet somewhere in the middle.