I don't see how driver-less cars will change (other than the big one of actually *having* self-driving options). If someone would choose a corolla versus a taurus versus whatever today, I don't see them as suddenly not caring about whatever differentiate those cars today. Basically to the extent your categories would apply in the future, they already apply.

I agree that the concept that the infotainment solution would not really change the fundamentals of the workings of the market, but neither does driver-less (unless some companies neglect that concept, or a disruptive player gets something available to mass market early).

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

Thank goodness there are other voices out there calling out WMI (and by extension CIM/WBEM) for the crapfest it is.

Not true, or else you wouldn't be able to run 'notepad' on the console. Not that this is necessarily a big deal, but the Core editions are not GUI-free, they start cmd in a window. If you ignore the graphics console and use EMS only, the GUI is still running, just not visible to you.

Other organizations have tried and failed to do this sort of thing, simply because they are superimposing their own stuff on top of the stuff that really does the work. So you either have the code complexity of code managing the tooling that is really doing the work, or the code managing the work, doing the work, and some middleware that doesn't add meaningful value, but does add complexity. Having translation layers rarely does nice things for maintenance and stability, regardless of who is doing it and what the platform is.

I don't think you are going to reach an accord on Powershell syntax. I personally find it tedious, and frankly the Verb-Noun thing is backwards (Noun-Verb would have worked better, I don't need to know all the things I can 'Get', I need to know the things I can do to a Disk). That said, there is a convention, which is something that cannot be said for the more diverse set of shell commands.

In general the two camps need to recognize the situation for what it is. Empowering Microsoft shops to manage Linux workloads. It isn't going to win over a Linux shop to start using Windows if they don't already.

Powershell works that way because MS controlled the development of the vast majority of components that normal people interact with. It delivers a framework to let third parties do it 'the right way', but there's a lot of missing stuff and when you interact with the few CLI friendly executables that existed, you are right back there.

Basically, you could use 'python' as a shell and have the same benefits, complete with the awkwardness of interacting with non-python executables. In MS world, this is less disastrous because non-python executables were pretty rare anyway and they did a good job of chaining instead to .Net stuff.

This is pretty misleading. OMI is Microsoft's pet 'standard'. They know the politics of DMTF to get things the 'standard' rubber stamp, but it has no bearing on actual applicability to the general environment. Basically going OMI means a pretty crappy set of flaky abstraction/instrumentation has to be put on the target that doesn't actually provide any more value than the open source competitors. CIM/WBEM has long languished for lack of anyone wanting to do it, and MS is trying to force the issue by doing OMI.

The 'article' is an editorial presented as something to be taken as representative of the community at large. My impression is that Canonical is losing mindshare quickly to Mint on the desktop, that Canonical really doesn't care that much about desktop anyway as they pin their business hopes and dreams on servers and embedded (where it also is failing to get much traction business wise).

Note that none of this has to do with the parents referenced points: Gnome 3 (which is largely defined by Gnome Shell, which Ubuntu doesn't even use by default) and systemd (I'm sympathetic, but not sure it's making much of a difference either way in the desktop distribution selection right now).