Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment: Re:Compelling? (Score 1) 241

by Junta (#49735353) Attached to: Why Apple Ditched Its Plan To Build a Television

No one in tech does that.

Not true. In automotive space (what we are talking about here), repair of a 20 year old vehicle is quite common. In x86 space, modern software releases commonly apply to a decade old platform.

But the insinuation that Apple is a worst offender here is demonstrably false.

I wasn't implying that Apple was any worse than Google. However I do think such a perspective is a valid one on the x86 desktop platform side, where every other player except for Apple does a better job of supporting platforms over a longer time.

as far as the hardware itself will allow,

At the whim of Apple dropping support from some component of that hardware. In the handset business, no provider has proven that it could be easy to support older platforms so there might legitimately be too much churn in the platforms for that to be reasonable, but in the desktop space, the causes for Apple dropping support seem to be things that don't phase the other OS providers on that platform.

Comment: Re:Compelling? (Score 2) 241

by Junta (#49728837) Attached to: Why Apple Ditched Its Plan To Build a Television

*Being* the infotainment system is not that great a play. Those systems are increasingly tied to the platform of the vehicle so you can't easily upgrade it without buying a new vehicle. Apple nor Google are particularly well known for being fond of supporting tech that, on average, would not receive a hardware upgrade for 11 years for any user.

Improving infotainment systems interaction with the driver's handset so that a handset upgrade drives all the value add they would want, that works. Hence Google and Apple doing their respective platforms, and car vendors looking to support both from a neutral platform rather than locking a very expensive vehicle to one platform or the other.

Comment: Re:Driverless is the real threat (Score 1) 284

by Junta (#49718041) Attached to: The Auto Industry May Mimic the 1980s PC Industry

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

Comment: Re:Editorializing... (Score 1) 408

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.

Comment: Re:Not yet statistically significant (Score 2) 408

. While a car may be capable of self-driving, if a human is in control when an accident occurs, then the car was not a self-driving one as far as the accident goes.

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.

Comment: Re:The pain isn't in the switch (Score 3, Insightful) 347

by Junta (#49663521) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

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.

Comment: Editorializing... (Score 2, Insightful) 408

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

Comment: Re:The pain isn't in the switch (Score 3, Informative) 347

by Junta (#49663321) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

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.

Comment: Re:The pain isn't in the switch (Score 4, Insightful) 347

by Junta (#49663235) Attached to: Linux Mint Will Continue To Provide Both Systemd and Upstart

SystemD - works well when it works, fails spectacularly when it fails.

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

Comment: Re:Developers! Developers! Developers! (Score 4, Informative) 265

by Junta (#49637893) Attached to: Microsoft Releases PowerShell DSC For Linux

can be run without a GUI at all

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.

Comment: Well there is a bigger issue... (Score 2) 265

by Junta (#49637863) Attached to: Microsoft Releases PowerShell DSC For Linux

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.

Comment: Re:I'll bite (Score 1) 265

by Junta (#49637835) Attached to: Microsoft Releases PowerShell DSC For Linux

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.

Comment: Not all rosy... (Score 1) 265

by Junta (#49637683) Attached to: Microsoft Releases PowerShell DSC For Linux

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.

How come financial advisors never seem to be as wealthy as they claim they'll make you?