/dev/null is also an extremely fast KV store.
Sure, it still has some bugs resulting in occasional data loss, but it is pre-release so that's okay. Look at the speed, people!
14,143 karma · joined July 11, 2016
Sure, it still has some bugs resulting in occasional data loss, but it is pre-release so that's okay. Look at the speed, people!
How did your design process resuls in an architecture which even allows for this kind of failure? How did your review process allow for code to be released which is seemingly completely unread and untested?
"We added some unit tests" is is an extremely damning answer - the lack of tests is a symptom, not the cause. If you ever want to be taken seriously again, you'll have to completely rethink your development process first, and do so publicly.
No matter how well you argue that it is "perfectly secure", when some nerd outside the polling station is showing reporters a real-time feed of who people are voting for, your machine will get thrown out.
It wasn't quite CRT-level of mirroring, but it wasn't far off...
East-west transmission wouldn't have helped here. France is less than an hour ahead, so the solar curve is going to look virtually identical. What really helped is that France had spare hydro capacity able to quickly compensate for the shortage. If anything, the UK's limited north-south transmission capacity making the use of Scotland's spare capacity impossible should be a bigger priority.
With the grid increasingly relying on decentralized solar and short-term battery storage, you just cannot operate it like you would with a bunch of on-demand essentially-unlimited fossil fuel plants. It is going to need a huge mentality shift from an operational perspective, and a large overhaul of the power trading market in general.
If you live in a country where you pay $400 in taxes but all healthcare is paid for by the government, you are better off than someone living in a country where they have to pay only $300 in taxes - but an additional $200 for private health insurance just to cover what you get for "free".
On top of that the tooling is just... not good. The more I use it, the more I get annoyed at weird UX decisions, strange missing features, and the whole thing just being a giant bowl of spaghetti in general. You can easily spend days trying to make your workflows not suck just to realize halfway through that you could've been done already if you had just handwritten the damn thing in Bash.
We now live in the insane world where I am glad our tickets are still in the nightmare called Jira, because every day I get closer to asking management to switch to a forge which is actually functional - and with only CI and Git the transition would not be very difficult...
But there's no reason that has to be your frequency source. Any single battery installation on its own is perfectly capable of making up some frequency, which is why home power banks with island-mode AC output are a thing - or even just a traditional UPS. Doing the same with thousands of individual battery installations across the grid? You'll need some way to get everyone to agree exactly on frequency and phase, which in practice is probably going to mean getting them to agree on time to within a few microseconds, which could be done (albeit not very sabotage-proof) using GPS.
As we also know from the aviation industry, controllers are human and therefore will make mistakes. A controller shouldn't issue a wrong order, but a driver also shouldn't accept an order they aren't certain about, and there should be technical systems backing both sides of that up.
It doesn't "fall" on the driver, but it doesn't "fall" solely on the controller either. It's a systemic issue, and many pieces have to fail for a disaster to happen.
This isn't a game of Hot Potato where the last person touching it goes to jail for gross negligence. You have to look at it through a Swiss Cheese model: every individual safety layer can and will have holes, but a disaster can only occur when all of those holes align.
Why did the LZB system fail? Why did the train dispatcher use the wrong backup procedure? Why did a backup procedure with zero safety checks even exist? Why did the train operator accept this backup procedure? Why did the train allow high-speed driving under those unsafe conditions?
It does indeed seem like the train dispatcher made a big mistake, but that was far from the only thing that went wrong, and it would be myopic to use him as the scapegoat for a far larger systemic issue.
You don't want trains to collide because sick people are forced to work when they shouldn't and realistically can't.
> when it's too cold
You don't want trains to derail due to rails breaking.
> when it's too hot
You don't want trains to derail due to rails buckling.
> when it snows
You don't want trains to go the wrong way (including into another train) due to switches freezing shut.
> when nature drops a leaf on the railroad tracks
You don't want trains to collide as slippery rails made braking impossible.
> or whenever they come up with a new excuse.
Usually it's a reason, not an excuse. Train people like nothing more than seeing the trains ride past, they don't cancel them unless they absolutely have to. Just because you don't personally understand the reasoning behind it, doesn't mean there isn't one.
Giant chunks of it lack basic safety features like crossing gates; there are 4.6 derailments per day; it is considered normal to have trains slow down to near walking pace due to poor track maintenance; electrification is a rounding error; trains routinely sit idling in sidings for huge chunks of the day; railroads are unable to comply with the legally-mandated requirement to let on-time scheduled passenger trains have priority; and high-speed rail basically doesn't exist despite several corridors being the perfect scenario for it.
By any metric except $/ton/mile, US rail is a giant failure. The only reason it still exists is because the US got screwed over by geography and can't make use of waterways for over half the country. Want to ship grain out of Montana, or coal out of Wyoming? You have to use a train, no other option.
The disambiguation page of "John Smith" already contains 287 people. You're looking for the John Smith who was a US Navy sailor and received the Medal of Honor in the second half of the 19th century? There's three of them with a page already, and they have to be distinguished by year of birth. No need to make that page hundreds of thousands of non-noteworthy people long, having to be distinguished by SSN.
China already figured this out, mind you. Their wages have been exploding as the country has developed, and due to their horrible one-child policy they are facing a giant population cliff. They have been pushing very hard to switch their factories from cheap labor to automation, and those dirt-cheap Chinese EVs our Western politicians are working so hard to block in order to keep the horribly outdated Western car manufacturers alive are the direct result of that.
In Shenzhen you can have Some Guy in a truck doing a parts pickup round around town a couple of times a day. In the US you're waiting for overnight Fedex from Digikey. And sure, there's a lot you can stock in advance, but virtually every board will have this one weird part you don't stock yet.
JLCPCB is so cheap because everything is standardized and automated. Their tooling analyzes your input, gives a big fat warning if it spots something it knows it can't manufacture, and renders their processing output for final approval by you. Chinese labor might be cheaper than Western labor, but it is not even remotely cheap enough to babysit every hobbyist's one-off board.
They also assume you know what you are doing. You order a board with a part rotated 180 degrees? Well, it physically fits, so they will make it like that. The final board not working as you intended is a you-problem. You put a via inside a pad and it wicks away all the solder? Not their problem. You forgot to re-render the area fills and short ground to power? Not their problem.
It also wasn't uncommon to install a server's hypervisor to a USB flash drive, or a tiny local SSD. Server motherboards with internal USB-A ports (not headers, the entire port) were quite common, and there were even IDE flash drives you could plug straight into the motherboard. This allowed you to completely dedicate the regular storage to the client VMs. I would not be surprised if that same market also used PXE for the same reason in larger installations.
So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting.
Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies.
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.