kjetijor

It seems naive to think this will only have big consequences for the EU, it'll be disastrous for everything around the Atlantic, and likely beyond.

"decades ago"

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'm very reminded of this Money Stuff: https://www.bloomberg.com/opinion/articles/2024-04-18/jane-s...

Probably unrelated, no mention of Millennium.

namely the lack of pesticides

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

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.

3DES is still an approved security function for FIPS 140-2 :)

So yea - great stuff!

"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.

ed might do truncate/write, and vim might do create/write/rename. New file, cache miss.

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.

The Nidaros Cathedral in Trondheim has this interesting feature as well: https://radiojente.files.wordpress.com/2011/07/nidarosdomen-...

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.

Norway is (probably) still a manual transmission holdout, potentially in part because you'll most likely end up being taught driving a manual as there's restrictions attached to your license. If you do your practical on an automatic, you're restricted to automatic, if you do it on a manual you get to drive both manual/automatic.

Anecdotally - early automatic transmissions weren't all that great on the windy mountain roads. My dad had two primary complaints (after having had an automatic rental). Tricking the car into downshifting to maintain speed or accelerate on steep ascents, and passing people on steep ascents, usually involved slamming on the brakes to trick the car into downshifting. (This were in the mid-90ies). My dad held onto the manual transmission until probably 2012-2013.

If you have bash, you can even partially get by without netcat as well. Bash has the wonderful "fake" devicenodes, /dev/tcp/host/port and /dev/udp/host/port.

An friend of mine had a similar thing, where desktop-box-turned-server essentially locked up after just over 24h of uptime. Solution: Outlet/timer-thing which cycled power around 2am when nobody were looking.

Similarly - there were some minor issues with the cooling for my compute cluster at my previous job, where it weren't really designed to function in climates which had temperatures that varied too much. Notably, it'd turn off the compressors on hot summer days and cold winter days. While waiting for the tech, tiny rocks found on the roof were used in conjunction with some tape to force the mechanical relays on while waiting for the techs.

http://www.pvv.ntnu.no/~kjetijor/images/tape_rocks.jpg

And another good example is ceph+radosgw.

Reminds me of a random google SRE slide deck I stumbled across a couple of years ago. Switch itself corrupts payload; dense enough to pass the tcp checksum in use.

http://www.catonmat.net/blog/wp-content/uploads/2008/11/that...

I did have the general impression that Norway had decent privacy laws, it does however seem it's rapidly changing.

Norway is implementing the EU "Data retention Directive", 2006/24/EC.

While I don't know the exact specifics, it were recently opened for private parties to conduct piracy investigations on behalf of the media industry. I don't imagine they were granted powers in regard to gathering information, I think it's more in regards of keeping/storing it.

In the case of (La)TeX I'd actually also be curious if i.e. the rules governing hyphenation/justification makes any difference as well, not just the typeface.

If I were to make a guess, you might be able to shave off some of the time it takes by enabling write-caching for the usb-device.

I believe that by default, windows disables write-caching for USB devices. Somewhere in the device manager, there should be a choice between "optimize for performance" (enable write caching) or "optimize for safe removal" (disable write caching).