A soda can worked for some mercedes S class. However that is a lot more blatantly obvious that a user is doing unreasonable stuff to bypass safety mechanisms, so vendor can reasonably be considered less responsible if the user is having to get so 'imaginitive' to be jackasses.
Simple. In the unaided case, it's unbelievably obvious what will happen immediately. There's no perception that the car will save you. Driver's ed required pretty well covers what will happen if you aren't paying attention.
The problem is the assist technologies can let you get away with it for extended periods of time, the majority of the time. So car has to nag the user to remind them that it is *not* safe to remove human attention as well. It's mitigating risk and doing a deceptively good job at it when it doesn't nag the user. Also not helping when Musk talks about how safe it is, abusing statistics in an unfair way that further encourages risky behavior for the sake of making Tesla sound like magic.
Also, here, the hands can be off the steering wheel for a minute in the old scheme. This tells us that they *explicitly* put in a mechanism to measure driver attention and explicitly chose to let them neglect the vehicle for a full minute.
It is the average user understanding that must be kept in mind when doing branding/naming exercises like calling something 'autopilot', unless you have a very thorough licensing process that explicitly covers what autopilot is or is not.
Here it's a marketing gimmick to sound cool. There are repurcussions.
Also, Musk was still saying 'hey it's still safer than driving yourself', which again reinforces the common imagined image of autopilot.
Though in that case, I think anyone can argue that a person getting killed doing that was *really* going out of their way to act against the designer's intent for the vehicle. Contrasted with Tesla which had messaging *and* implementation that encouraged people to be reckless.
This is less like something like adding airbags and more like when airbags explode with shrapnel.
The former is an improvement that's seen as natural evolution of things. The second is a safety problem where a functionality is likely to do more harm than good and comes with liability issues.
Here, Tesla may be found to have been irresponsible by calling the feature 'autopilot' with a bunch of connotations in the minds of the users causing them to watch DVDs instead of driving. Additionally, 'beta testing' highly dangerous functionality is not something car companies generally get to do. When it comes to anything resembling autonomous vehicle operation, you can point at *any* other company and how extremely careful and conservative they are being. Even with similar 'lane assist' technologies that are in production vehicles, they *already* were being far more strict about monitoring driver attention than Tesla was.
So here we have Tesla being more aggressive about how 'automatic' things are, taking less measures for safety than the rest of the market offering equivalent feature today, and not being as conservative as the efforts that are what Tesla purports this technology to be.
I know there is a desire to bow down and really kiss up to Tesla, but they need to be held to the same standards as their competitors. They are not holy saviors of our society. They aren't even the only electric car company. They are certainly not the most accessible/affordable things. They have done nothing to earn having a blind eye turned to their mistakes.
Well, with SSD, I don't necessarily have a problem with vibration. However the concept doesn't exactly excite me. Particualrly since it's general purpose, windows oriented means that headless interaction is going to be woefully limited, making that microphone array less intriguing.
Other vendors have done the stacking and it's not caught on, probably because of what you say in part, but for another there's relatively little they've thought to do with it. I can add what is not going to be much better than mono speaker, or I could add real speakers. Maybe with that and the phone controls they imagine this as a basis for a VOIP appliance, but again the general purpose OS means that will be limited.
Of course there is TOTP (which can use pretty much *any* compute device) and U2F (dongle required). Practically speaking, requiring one of these two neatly gets the Nonce behavior you desire (well, roughly, a phishing attack would get a token that would be valid for at least a short period of time).
I agree SRP was a nice concept, but in practice, no one is interested.
But then people would complain 'what if they had a slow internet and went to sip a cup of coffee or something' if the time is too short. The click-through idea seems viable enough. However I'm still skeptical that a user that would be vigilant about the address bar would suddenly stop being vigilant if the page clearly reloads. Either they are vigilant throughout or they would fall for a phishing page without ever touching google's servers.
No static typing. Great until you get over 1000 lines of code.
If you are saying it is a code maintenance nightmare, then whether it is typed or not, your code must be spaghetti code if the overall line count significantly impacts your variables. Even in a complex project, things should be nicely scoped so that readability is preserved enough that lines of code does not impact whether static typing is a good idea or not. That's not to say it is not a good idea, just that the good idea is pretty constant whether the project is small or large.
Also, Java compiles to some abstracted bytecode. This is the case for pretty much all interpreted languages (just the compile step happens on 'load', and many languages make effort to cache that). Performance is governed by the quality of the runtime, and yese the JRE is one of the better language runtimes, though Javascript has had a *lot* of similar work, but the language is limited. Ruby, Perl, and Python do have runtimes that are far behind the JRE, but at this point more to do with relative investment in the runtimes than things enabled by the language (though yes there is a difference by having things like static typing, it's tiny compared to general optimization potential).
On GUI/Web, if you mean it's 'good enough', fine, but if you are claiming it is advantaged, it really isn't. Particularly on the Web side, Java really doesn't do *anything* for you GUI wise, it's just beyond the scope (unless you are saying applets, which no sane person would start new and in fact getting an applet to run in a modern browser is insanity). If you refer to Java webstart, for just make your app run in the browser already and not subject the users to the pain in the ass that is making sure javaws runs right.
On cross platform, nowadays it is extremely easy to have a write once, build everywhere. Now if you think the 'build once, run anywhere' is significant, then your build system isn't adequate and your users' lives are made more complex because they suddenly need to understand how to launch a jar, which is somewhat unnatural for all the platforms.
Basically, Java is the right choice when your developers happen to be experienced in Java. However you still need to make platform specific builds to abstract the java-ness (e.g. user downloads an '.exe' rather than a.jar') and your users will be pissed if you deliver your 'webapp' as a jnlp.
It may be abuse, it may be a stupid patent, but it's not patent trolling. The point is that is a specific form of nastiness that describes company with literally *no* product but a patent portfolio and only makes money through litigation.
The point being a 'patent troll' is defined as some entity holding patents, but not actually *making* anything. Bad for both being a leech, but also challenging as the potential to fight back to pursue cross-licensing is impossible since the attack doesn't do anything.
Now if you think the patents are stupid and not worthy of being patent, that's something else and I'm particularly inclined to agree about the VFAT patent. But 'patent troll' is a specific phenomenon, and Microsoft is not (yet) in that role.
Though one of the chiefly cited daemons (pulseaudio) is in the same ballpark with the same set of developers available to work it.
The problem with your logic is that at some point pulseaudio and the like could in turn decides it wants to declare itself as 'really wanting to persist' using the systemd mechanism, and again be running stray. Then systemd could add yet another layer of 'really *really* mean to persist. It's an arms race of crappy software. The question is 'why does the daemon *think* it needs to persist?' not 'how can we invent a way to ignore their request to persist and hope they don't update to the new scheme'.
The point being that it's what systemd upstream decided would be a good default behavior. This speaks to the mindset of the architects and how it factors to their general design.
Yes when they offer choices, distros can opt out. However they are inventing new paradigms where existing ones already serve.
I think there is a lot of room for improvement for reasonable defaults and auto-sensing correct behavior.
However I take issue with the 'highly intuitive graphical interface for changing the way it works' *always* being available. The GUI should really focus on the most frequently fiddled with things. In Microsoft, you can very rapidly need to drop to do things via powershell commandlets or registry edits to modify some hopelessly obscure thing. Similar in OSX. It's a rare circumstance and frankly the ability for a user to 'intuitively' figure out such an action is needed is just beyond reach.
GUIs that try to encompass *everything* are confused messes. Some KDE dialogs are dizzying, and they still aren't all encompassing. So be very careful suggesting that everything should have an intuitive GUI, because that really isn't the case for any general purpose platform (mobile OSes come closest, but mostly by virtue of not being at all configurable).
Well the point is the humble beginnings were Linus sharing a hobbyist project without much ambition. At the time, GNU was a big effort to produce a full Unix system, but licensed under GPL. Proceeding very carefully/slowly for things. Making sure they had the right plan in mind before going and executing to that plan pretty thoroughly. This worked fine for a lot of the system, but kernel wise there was a big gap.
So along comes Torvalds, with an appropriate amount of uncertainty, sharing his quick and dirty stab at a kernel. Ultimately his more pragmatic approach would lead to a usable system long before GNU could deliver one. As such despite not originally seen as a 'serious' attempt, n practice it is the backbone of a great deal of professional work, as well as the target of a lot of code developed professionally.
The generic sentiment is the same, part of the value of a software vendor is how much they can be relied upon to not screw you over in updates. When that equation starts not working out, the answer is not to create long term plans on how you are going to vet each individual minor upgrade, balance the risk of that update versus the risk of not applying it, and so on. The answer is evaluating a long term move to another vendor. There might be some short term making the best of the current situation, but people shouldn't be looking at a long term 'just deal with it' workaround. To put it simply, if you can *credibly* do a better job of evaluating software updates than your vendor, you need to rethink your vendor relationship.
This is a somewhat subjective call and depends on the circumstances. I would say that MS has indeed compromised this value by laying off their QA team and going to a rolling release model and I won't use them for anything other than Windows gaming, but everyone has to make that judgement call based on their needs and such.
I think dbus gets a pass *way* too much for the crap it causes. I think people only started noticing when systemd started to depend upon it so heavily for core function. Of course, a good criticicsm is that systemd shouldn't incur such dependencies for core functions, and that it shares some blame for dbus problems which used to only screw up desktop applications are now screwing with core services or servers.
The short of it is systemd decided all of a sudden the 'right' behavior was to assume processes were killable when your shell exits, unless they took some special measures to explicitly inform systemd directly that it realy really really meant to persist. screen, tmux, et al were suggested to change to support yet another paradigm for indicating wanting to *really* stay alive after session logout.
IIRC, it was all caused because some processes like pulseaudio were abusing the existing paradigm of requesting to run in a way that would persist beyond session exit and failing to close themselves. Rather than correct those bugs, they decided it would be easier to introduce *another* layer of requesting such persistence.
Unless you run it in check-only mode. I have seen systems blindly try to detect and *correct* problems in a filesystem cause tremendous harm. Even Windows prompts the user before taking such measures on removable media. The fact of the matter is you may have some unexpected situation that would be corrupted by that action. Maybe a newer version of the filesystem your version of fsck mistakens for corrupt. Maybe it had one type of partition table at some point now it has a new one you don't recognize, but you see a backup block and corrupt the storage by restoring backup block of what you do recognize.
The fact of the matter is, users should be asked/made to take corrective action in something like fixing a filesystem.
The thing is it works well, until something cocks up, then it's utter hell. The non-deterministic boot process is killer. I have had a hell of a time diagnosing systems where people have done things so root filesystem will not mount on normal boot. Then I try to boot single and it works fine, or rdshell. It turns out to be some crazy ass race condition between two things *no one* realized would be related, or should be related.
Also, things that were straightforward get strangely complicated. SysV init didn't care one bit about something like docker, but a lot of work and complication went on to coordinate systemd and docker.
I have more admins than ever requiring support and I can't fault them for being unable to contend with the mess they have been saddled with. It's more featureful, but it takes things too far making a lot of things impossible to reasonably debug. I personally would love to see journald eschew the binary-only logging and for systemd to offer a deterministic boot mode, where boot speed is compromised for the sake of repeatability.
It's not just old folks whining about change,, there are very concrete things that are being done incorrectly. Sure there are more nebuluous rants that may be either folks trying to get a rise out of the community or have a difficult time expressing their general frustration in a more concrete ways, but that's no reason to sweep the real problems under the rug along with them.
The one threat I don't get is people who claim to dislike systemd sometimes claim they will go to windows instead. Windows in general is managed in a very systemd like way, except more shoddy. I'm not a fan of how SystemD is going personally, but if it *had* to be Windows or Systemd, I'd pick systemd in a heartbeat.
Seriously speaking, it seems the short of it is that WSL should be disabled if AppLocker is desired. I suspect that wouldn't upset too many folks, as I imagine the intersection of audience that uses AppLocker and the audience that would use WSL is non-existent. AppLocker is a pretty extreme lockdown to inflict on your users, and I can't imagine those admins wanting to use Linux applications.
WSL can be disabled, so I don't think this is as large a deal as the article wants it to be. In fact I assume the default is disabled.
Slashdot Mirror
GM was crucified in the media for that. No one took GM's side on that. That is how reaction *should* be.
With Tesla, tons of folks are white knighting for a luxury car brand. It's insane.
A soda can worked for some mercedes S class. However that is a lot more blatantly obvious that a user is doing unreasonable stuff to bypass safety mechanisms, so vendor can reasonably be considered less responsible if the user is having to get so 'imaginitive' to be jackasses.
Simple. In the unaided case, it's unbelievably obvious what will happen immediately. There's no perception that the car will save you. Driver's ed required pretty well covers what will happen if you aren't paying attention.
The problem is the assist technologies can let you get away with it for extended periods of time, the majority of the time. So car has to nag the user to remind them that it is *not* safe to remove human attention as well. It's mitigating risk and doing a deceptively good job at it when it doesn't nag the user. Also not helping when Musk talks about how safe it is, abusing statistics in an unfair way that further encourages risky behavior for the sake of making Tesla sound like magic.
Also, here, the hands can be off the steering wheel for a minute in the old scheme. This tells us that they *explicitly* put in a mechanism to measure driver attention and explicitly chose to let them neglect the vehicle for a full minute.
It is the average user understanding that must be kept in mind when doing branding/naming exercises like calling something 'autopilot', unless you have a very thorough licensing process that explicitly covers what autopilot is or is not.
Here it's a marketing gimmick to sound cool. There are repurcussions.
Also, Musk was still saying 'hey it's still safer than driving yourself', which again reinforces the common imagined image of autopilot.
Note that people treat 'assist' as 'auto' as well. However no doubt Tesla exacerbates the issue by calling it that.
A bigger thing is that in addition to calling it 'lane assist', competitors *also* more aggressively monitored user attention.
For example, Mercedes drivers taped a can to trick the sensor:
http://www.roadandtrack.com/ca...
Though in that case, I think anyone can argue that a person getting killed doing that was *really* going out of their way to act against the designer's intent for the vehicle. Contrasted with Tesla which had messaging *and* implementation that encouraged people to be reckless.
This is less like something like adding airbags and more like when airbags explode with shrapnel.
The former is an improvement that's seen as natural evolution of things. The second is a safety problem where a functionality is likely to do more harm than good and comes with liability issues.
Here, Tesla may be found to have been irresponsible by calling the feature 'autopilot' with a bunch of connotations in the minds of the users causing them to watch DVDs instead of driving. Additionally, 'beta testing' highly dangerous functionality is not something car companies generally get to do. When it comes to anything resembling autonomous vehicle operation, you can point at *any* other company and how extremely careful and conservative they are being. Even with similar 'lane assist' technologies that are in production vehicles, they *already* were being far more strict about monitoring driver attention than Tesla was.
So here we have Tesla being more aggressive about how 'automatic' things are, taking less measures for safety than the rest of the market offering equivalent feature today, and not being as conservative as the efforts that are what Tesla purports this technology to be.
I know there is a desire to bow down and really kiss up to Tesla, but they need to be held to the same standards as their competitors. They are not holy saviors of our society. They aren't even the only electric car company. They are certainly not the most accessible/affordable things. They have done nothing to earn having a blind eye turned to their mistakes.
Well, with SSD, I don't necessarily have a problem with vibration. However the concept doesn't exactly excite me. Particualrly since it's general purpose, windows oriented means that headless interaction is going to be woefully limited, making that microphone array less intriguing.
Other vendors have done the stacking and it's not caught on, probably because of what you say in part, but for another there's relatively little they've thought to do with it. I can add what is not going to be much better than mono speaker, or I could add real speakers. Maybe with that and the phone controls they imagine this as a basis for a VOIP appliance, but again the general purpose OS means that will be limited.
Of course there is TOTP (which can use pretty much *any* compute device) and U2F (dongle required). Practically speaking, requiring one of these two neatly gets the Nonce behavior you desire (well, roughly, a phishing attack would get a token that would be valid for at least a short period of time).
I agree SRP was a nice concept, but in practice, no one is interested.
But then people would complain 'what if they had a slow internet and went to sip a cup of coffee or something' if the time is too short. The click-through idea seems viable enough. However I'm still skeptical that a user that would be vigilant about the address bar would suddenly stop being vigilant if the page clearly reloads. Either they are vigilant throughout or they would fall for a phishing page without ever touching google's servers.
No static typing. Great until you get over 1000 lines of code.
If you are saying it is a code maintenance nightmare, then whether it is typed or not, your code must be spaghetti code if the overall line count significantly impacts your variables. Even in a complex project, things should be nicely scoped so that readability is preserved enough that lines of code does not impact whether static typing is a good idea or not. That's not to say it is not a good idea, just that the good idea is pretty constant whether the project is small or large.
Also, Java compiles to some abstracted bytecode. This is the case for pretty much all interpreted languages (just the compile step happens on 'load', and many languages make effort to cache that). Performance is governed by the quality of the runtime, and yese the JRE is one of the better language runtimes, though Javascript has had a *lot* of similar work, but the language is limited. Ruby, Perl, and Python do have runtimes that are far behind the JRE, but at this point more to do with relative investment in the runtimes than things enabled by the language (though yes there is a difference by having things like static typing, it's tiny compared to general optimization potential).
On GUI/Web, if you mean it's 'good enough', fine, but if you are claiming it is advantaged, it really isn't. Particularly on the Web side, Java really doesn't do *anything* for you GUI wise, it's just beyond the scope (unless you are saying applets, which no sane person would start new and in fact getting an applet to run in a modern browser is insanity). If you refer to Java webstart, for just make your app run in the browser already and not subject the users to the pain in the ass that is making sure javaws runs right.
On cross platform, nowadays it is extremely easy to have a write once, build everywhere. Now if you think the 'build once, run anywhere' is significant, then your build system isn't adequate and your users' lives are made more complex because they suddenly need to understand how to launch a jar, which is somewhat unnatural for all the platforms.
Basically, Java is the right choice when your developers happen to be experienced in Java. However you still need to make platform specific builds to abstract the java-ness (e.g. user downloads an '.exe' rather than a .jar') and your users will be pissed if you deliver your 'webapp' as a jnlp.
It may be abuse, it may be a stupid patent, but it's not patent trolling. The point is that is a specific form of nastiness that describes company with literally *no* product but a patent portfolio and only makes money through litigation.
The point being a 'patent troll' is defined as some entity holding patents, but not actually *making* anything. Bad for both being a leech, but also challenging as the potential to fight back to pursue cross-licensing is impossible since the attack doesn't do anything.
Now if you think the patents are stupid and not worthy of being patent, that's something else and I'm particularly inclined to agree about the VFAT patent. But 'patent troll' is a specific phenomenon, and Microsoft is not (yet) in that role.
Though one of the chiefly cited daemons (pulseaudio) is in the same ballpark with the same set of developers available to work it.
The problem with your logic is that at some point pulseaudio and the like could in turn decides it wants to declare itself as 'really wanting to persist' using the systemd mechanism, and again be running stray. Then systemd could add yet another layer of 'really *really* mean to persist. It's an arms race of crappy software. The question is 'why does the daemon *think* it needs to persist?' not 'how can we invent a way to ignore their request to persist and hope they don't update to the new scheme'.
The point being that it's what systemd upstream decided would be a good default behavior. This speaks to the mindset of the architects and how it factors to their general design.
Yes when they offer choices, distros can opt out. However they are inventing new paradigms where existing ones already serve.
I think there is a lot of room for improvement for reasonable defaults and auto-sensing correct behavior.
However I take issue with the 'highly intuitive graphical interface for changing the way it works' *always* being available. The GUI should really focus on the most frequently fiddled with things. In Microsoft, you can very rapidly need to drop to do things via powershell commandlets or registry edits to modify some hopelessly obscure thing. Similar in OSX. It's a rare circumstance and frankly the ability for a user to 'intuitively' figure out such an action is needed is just beyond reach.
GUIs that try to encompass *everything* are confused messes. Some KDE dialogs are dizzying, and they still aren't all encompassing. So be very careful suggesting that everything should have an intuitive GUI, because that really isn't the case for any general purpose platform (mobile OSes come closest, but mostly by virtue of not being at all configurable).
Well the point is the humble beginnings were Linus sharing a hobbyist project without much ambition. At the time, GNU was a big effort to produce a full Unix system, but licensed under GPL. Proceeding very carefully/slowly for things. Making sure they had the right plan in mind before going and executing to that plan pretty thoroughly. This worked fine for a lot of the system, but kernel wise there was a big gap.
So along comes Torvalds, with an appropriate amount of uncertainty, sharing his quick and dirty stab at a kernel. Ultimately his more pragmatic approach would lead to a usable system long before GNU could deliver one. As such despite not originally seen as a 'serious' attempt, n practice it is the backbone of a great deal of professional work, as well as the target of a lot of code developed professionally.
The generic sentiment is the same, part of the value of a software vendor is how much they can be relied upon to not screw you over in updates. When that equation starts not working out, the answer is not to create long term plans on how you are going to vet each individual minor upgrade, balance the risk of that update versus the risk of not applying it, and so on. The answer is evaluating a long term move to another vendor. There might be some short term making the best of the current situation, but people shouldn't be looking at a long term 'just deal with it' workaround. To put it simply, if you can *credibly* do a better job of evaluating software updates than your vendor, you need to rethink your vendor relationship.
This is a somewhat subjective call and depends on the circumstances. I would say that MS has indeed compromised this value by laying off their QA team and going to a rolling release model and I won't use them for anything other than Windows gaming, but everyone has to make that judgement call based on their needs and such.
I think dbus gets a pass *way* too much for the crap it causes. I think people only started noticing when systemd started to depend upon it so heavily for core function. Of course, a good criticicsm is that systemd shouldn't incur such dependencies for core functions, and that it shares some blame for dbus problems which used to only screw up desktop applications are now screwing with core services or servers.
https://bugs.debian.org/cgi-bi...
The short of it is systemd decided all of a sudden the 'right' behavior was to assume processes were killable when your shell exits, unless they took some special measures to explicitly inform systemd directly that it realy really really meant to persist. screen, tmux, et al were suggested to change to support yet another paradigm for indicating wanting to *really* stay alive after session logout.
IIRC, it was all caused because some processes like pulseaudio were abusing the existing paradigm of requesting to run in a way that would persist beyond session exit and failing to close themselves. Rather than correct those bugs, they decided it would be easier to introduce *another* layer of requesting such persistence.
Unless you run it in check-only mode. I have seen systems blindly try to detect and *correct* problems in a filesystem cause tremendous harm. Even Windows prompts the user before taking such measures on removable media. The fact of the matter is you may have some unexpected situation that would be corrupted by that action. Maybe a newer version of the filesystem your version of fsck mistakens for corrupt. Maybe it had one type of partition table at some point now it has a new one you don't recognize, but you see a backup block and corrupt the storage by restoring backup block of what you do recognize.
The fact of the matter is, users should be asked/made to take corrective action in something like fixing a filesystem.
The thing is it works well, until something cocks up, then it's utter hell. The non-deterministic boot process is killer. I have had a hell of a time diagnosing systems where people have done things so root filesystem will not mount on normal boot. Then I try to boot single and it works fine, or rdshell. It turns out to be some crazy ass race condition between two things *no one* realized would be related, or should be related.
Also, things that were straightforward get strangely complicated. SysV init didn't care one bit about something like docker, but a lot of work and complication went on to coordinate systemd and docker.
I have more admins than ever requiring support and I can't fault them for being unable to contend with the mess they have been saddled with. It's more featureful, but it takes things too far making a lot of things impossible to reasonably debug. I personally would love to see journald eschew the binary-only logging and for systemd to offer a deterministic boot mode, where boot speed is compromised for the sake of repeatability.
It's not just old folks whining about change,, there are very concrete things that are being done incorrectly. Sure there are more nebuluous rants that may be either folks trying to get a rise out of the community or have a difficult time expressing their general frustration in a more concrete ways, but that's no reason to sweep the real problems under the rug along with them.
The one threat I don't get is people who claim to dislike systemd sometimes claim they will go to windows instead. Windows in general is managed in a very systemd like way, except more shoddy. I'm not a fan of how SystemD is going personally, but if it *had* to be Windows or Systemd, I'd pick systemd in a heartbeat.
That should make porting WINE easy!
Seriously speaking, it seems the short of it is that WSL should be disabled if AppLocker is desired. I suspect that wouldn't upset too many folks, as I imagine the intersection of audience that uses AppLocker and the audience that would use WSL is non-existent. AppLocker is a pretty extreme lockdown to inflict on your users, and I can't imagine those admins wanting to use Linux applications.
WSL can be disabled, so I don't think this is as large a deal as the article wants it to be. In fact I assume the default is disabled.
Actually, it's not GNU either. It's an implementation of Linux kernel system calls. It only becomes GNU-ish after installation of Ubuntu libraries.
It's not a Linux kernel, it's not an emulator, it's an alternative implementation of Linux system calls.