I'm pretty sure it wasn't entirely uncommon in Norway (and probably also Sweden) to quit cigarettes by switching to snus (tobacco between your lip/gum).
68 karma · joined August 7, 2011
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.
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.
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.catonmat.net/blog/wp-content/uploads/2008/11/that...
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.
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).