They were not early adopters or anything else back then, the only path they blazed was down the toilet.

AOL users were the unwashed masses back then. An AOL address was a sign you were a dinosaur/technophobe then as well.

An issue with CC was they took the opportunity to go in a new direction. Having a 5th grader I can tell you math is not about getting it right anymore but the process in the CC that my sons school uses. They use some very dubious methods lots of guess and check that they teach and are pushed to grade to. Problem is that process looks nothing like what we remember.

Yet they don't link to the bug nor can I find anything besides circular references to the Venom announcement.

What is the use case for virt floppy? Drivers nearly never fit, VM's should not need firmware updates. SO why would people still be exposing a virt floppy to VM's?

First off having codes does not mean having the rights, often thats a complex mess on a commercial app. Secondly the build environment is also a complex bit and needed to actually make things work.

It seems to make more sense to work towards the M&M security policy. An edge device that connects the home devices to the internet and deals with a lot of the security aspects. You still need communications security inside the house but if trust is only placed in that one gateway controler.

That said I see things moving to direct wifi connects for mains powered devices, a decent microcontroller and wifi module is down to a few bucks, that is far cheaper that any zwave etc radio. This coupled with every company's desire to have a cloud something that they can try to get a few bucks a month for "special" features to effectively get rent forever. Hell I got a battery powered wifi connected IoT device (wink propane gauge) already.

Yea because that is not trivial to get around, Oh the OEM we bought it from folded, we do not have the source code etc.

You are right that there isn't adequate data. The problem being that the sentence itself paints things in a rosy light based on that data, rather than some meaningful data.

In short, we have an anecdotal gathering of data by third parties that doesn't actually tell us anything at all, with different people praising or blasting it depending on their preconceived notions.

Well it is interesting in so far as knowing when the companies think they need to have human operators still. Not really so much the crash, just the portion of the time that is human versus autonomous.

I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.

'48 self-driving cars have been navigating the roads... Of those, only four have been in accidents'

I know that the bigger point is that zero (known) incidents can be traced to the software making a 'mistake' (though even if the other driver is 'at fault', hard to say if a human would have done better at avoidance). The thing that strikes me though is the editorial bias here. *Only* 4 out of 48.. that's nearly 10%. That's far far above the percentage for the general population. It's perfectly likely that is simply a fluke of the small sample size, but implying that 4 out of 48 is a very promising rate of incident is pretty silly.

Right now the 'debate' is in full on 'no true scotsman' fallacy mode. No *real* users are complaining, so all people who *sound* like they are complaining need to shut up. If you complain, you must not be a *true* user.

dconf uses binary configuration files. As I've said many times, while systemd catches a lot of flak for messing with long standing conventions, it is far from alone in modifying the experience (dbus, dconf, systemd, udev all do interesting things, each component bringing interesting capability with varying degrees of drawbacks).

I think udev generally does a great job of delivering useful capability with minimal downside. Then dconf (most people don't even realize the binary dconf files exist, even when they poke dconf extensively). dbus starts going off the rails (many things that once were simple enough to explore/grep around for are now only possible through internet search of obscure dbus-send commands). systemd I actually consider less bad than having to do more and more dbus stuff.

Incidentally that is precisely the way Windows is. Windows is exceedingly structured and engineered (contrary to some beliefs), but as a a result when it fails... boy does it go down so hard that no one is going to bring it back. Not surprising many of the principles in Windows design match the design principles of many modern linux distros: Binary configuration files, binary log files, increasingly complex IPC schemes, and less and less friendly to simple scripts (though increasingly better for complex scripting).

Thats very dependant on whose implementation of raid 1. I've seen everything from read from one drive, stripe reads, and read from both and compare. Linux will actually let you choose from among some of those options.

ZFS and btrfs add a crc for a group of blocks and and detect which drive has the bad data, correct that and tract that it happened.