I'd say for gaming it makes for a logical evolution of displays. Hell I'd love it for working in cubeland (so long as putting it on and taking it off is as easy as headphones).
The fixation on things like mobility, real or fake (omni directional treadmills) only hurts the chances for general adoption, perpetuating the notion that there's no value until you do some very intrusive things that most folks don't have the patience for. In reality, it need not be significantly more intrusive than a pair of headphones. For those of us who do not need to see our keyboards or controllers, it's no big deal now.
However, the prospect of having the world surround you instead of just on a desktop monitor is really nice. Of course, getting into it costs twice as much as a 27" 4k monitor, and current display density means you are making a tradeoff of high resolution for immersion.
AR in theory would be a strict superset. In practice either the virtual or the real portion is going to suffer horribly as the technology stands, and not a lot of reason to be optimistic for that changing. Wearable AR is just not in the cards yet.
I'm saying that *if* a site is competent enough to consider what you propose, it would be competent enough to do server side hashing. Hence a user should take ownership of how this is done to assure themselves, and *not* expect to audit every websites javascript implementation of their particular hashing scheme. So if you have a website, doing the right thing in the server is important. Doing additional things in the client doesn't really help if you've done the right backend stuff.
I think that's where we are deviating. I'm saying solutions like password managers and hashpass where the user *independently* has total control of the scheme make sense as a means of enforcing their sensibilities above and beyond what unknown methods the site is using. Solutions relying upon the javascript sent down by the site do not make sense as *those* guys have every reason to be able to do things right on the backend.
Client hashing would prevent collateral damage in such cases
No, it wouldn't. If the traffic is intercepted, then the fact that the data is the password straight or the result of a one-way hash is of little consequence to the attacker, since the target system takes the value verbatim. The server does not *know* that the user is using the blessed javascript implementation or html form. They are only able to take the submitted data at face value. If you use the result of a one-way hash as a password, then either way the password is known.
If you want to protect against interception in the event of defeating TLS, there must be some pre shared key component to it. Using the password as a pre-shared key is considered bad form as the frequent occurance of a leaked password database would cause cries of storing the password in plain text. Server side hash and salt is the only recognized strategy and deviating from that risks being crucified in the security world (trying to explain the subtleties of going off that is going to be a very uphill battle). So something like RSA, U2F, TOTP or similar supplementing a password in a two factor scheme is the generally accepted way to get both the benefit of an ultimately shared secret based approach and password protection.
Ultimately, as far as the *site* is concerned, server side is the most widely accepted strategy, and there's no value in terms of the security they provide in doing it both places. If you want to protect yourself, then HashPass will do that job, though a much more comprehensive approach is a master store of site unique passwords with no actual relationship between your passwords, and *that* would completely divorce your password in any sort of way from the site unique password, truly compartmentalizing an attack against one of your services.
So there exists a browser extension to implement what you desire, it is called HashPass.
However, if you use such a strategy, you *still* must have a password resilient to dictionary attacks. The attack scenario it provides *some* protection against is if you use a site that has poor security storage policies, without your knowledge (e.g. stored in clear text). The idea is that if such a crappy site gets compromised, it's view of plain text password is the end result of your client side salt, which now can be run against a dictionary attack. It basically is ensuring that *someone* is doing a secure hashing strategy that would reasonably protect a strong password in the manner the server side *should* be doing anyway.
If an otherwise secure site adds what you describe, it would do nothing to enhance security. If your password is *truly* strong and they employ proper salting and one way hash strategy (scrypt, PBKDF with adequate passes, what have you), then a leak of their password database is not actually that big a risk. If your password is weak, then the salting strategy client side doesn't add anything, as they could modify their brute force attack to do the client transform in a trivial fashion, and they can work their way back to the password you *really* use.
Note I *think* he's saying that whatever string the client ultimately sends to the server should still be one-way crypted and salted in the usual way. Meaning a compromise of the database still has reasonable protection.
He wants something to automagically take his password and make it unique per site so he doesn't have to remember them all. Note that this is what things like the extension Hashpass do, generate a site specific password derived from your master password and transformed for the site.
Of course, all this said, the dictionary attack required involves just adding that transform, hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts, and your password would be secure against dictionary attacks offline. It makes zero sense as part of a websites arsenal against attacks.
Note that this *also* would be a sign of an incompetent site. Password databases should be impervious to rainbow tables. Also, a GPU would not really be that useful for a rainbow table. A rainbow table is a precomputed table of hashes, meaning it's a straight lookup rather than actually having to perform the hash calculation. A competent site would have a sufficiently long random salt incorporated to render rainbow table impossible.
Of course, dictionary attacks against offline database are still a problem, and so it would be good if your password is not likely in the first 100 trillion or so guesses a system would make (which on a decently secured password database would buy you about a year of time against 8 full time GTX 1080s working on your password and your password alone).
passwords should contain uppercase and lowercase letters, numbers and symbols
No, far more effective would be minimum password (phrase) length. People thinking 8 characters are fine as long as it is leet-speak is a problem. The way most people use uppercase, numbers, and symbols make the dictionaries a little more tedious, but not *that* much more so.
Sure, the most secure approach is totally random, but if people insist on it being human friendly, number of characters is the key point to emphasize.
Yes, a lot of work went in, but ultimately, all of the *significant* genetic material came from two parents. Passing on your mitochondrial DNA doesn't do anything to really shape your offspring (unless your mitochondrial DNA is just *really* messed up). Now if the donor egg somehow had defective Mitocondrial DNA, ok, this is at least somewhat useful.
But pretending this offspring has three equally biological parents is disingenuous.
Under linux, you might as well give up and run it under docker as they are very messy about their depedencies, but at least that's not too complicated.
For most places and efficient low cost configs, I'd say maybe 30-40/year in energy cost.
The upload bandwidth is killer. The performance of accessing the media is terrible (when I access a local rip, it's super high quality and *instant* seeking, versus streams from netflix and the like.
Actually, I'd say it would be more of a nightmare. Here we have the devils we know. In that scenario, it would be hellish even *knowing* what can't handle things.
Every hop in the network not being certain whether the next hop could or could not handle the conversation would be a nightmare in the making.
It seems funny, because that *ultimately* is the reality of IPv6.
The difference is that in the above scheme, *knowing* whether a hop in the network could or could not do 'big addresses' would be more difficult. With IPv6, it allows things to be very clearly delineated whether the communication is IPv6 capable or not.
The biggest obstacle to IPv6 was the stubborn resistance to any form of NAT. That IPv6 should be all or nothing. The piece needed to make IPv6-only *clients* possible was carrier grade NAT64. Yes, on the server and as a carrier, you need IPv4 *and* IPv6, but the vast bulk of endpoints can be IPv6-only now, taking the pressure off of IPv4. Of course this would have been nice to do a decade ago instead of the last two years or so, so that new servers could have a more comfortable time getting IPv4.
I personally would rather *not* have crypto at the IP or TCP layer. Reason being is that in practical terms, updates *must* be delivered through kernel updates. Given the nature of crypto updates, I'd much rather have librariers in userspace be the channel for updates.
I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.
The issues with DNS/DNSSEC are more reasonably addressed in the DNS layer. There is a lack of will to tackle that problem, but that's the same lack of will that would make implementing at a lower layer impractical as well.
When I pull up my cell phone ip information, it's IPv6.
Now that there's carrier-grade nat to allow ipv6-only endpoints to speak to ipv4-only hosts, it *finally* is plausible to offer most mobile/residential ipv6-only. So a lot of the people who are ipv6-only are precisely the ones that would never realize it.
For enterprise networks and internal networks, those are ipv4 and likely to stay ipv4-only (which is a bummer for software development, because IPv4/IPv6 agnostic code is still relatively rare, since there's so many subtle bugs trying to use AF_INET6 for both, and it's more complicated to have both AF_INET and AF_INET6 addresses).
The software industry realized that for a lot of their users, they couldn't extract upgrade licenses from customers readily because they had already done *too* good a job. Functionality wise, a lot of people don't need anything newer than Photoshop 6 (released 16 years ago). A lot of people could use Office 97. Of course some things have slowly evolved technology wise that *ultimately makes people need updates and there's some forced updates (e.g. fun incompatibilities in ms office formats), In general though, update revenue became a big uncertainty.
So the solution is to switch to rental models, subscriptions, et al. Licenses that terminate when you stop paying, rather than the 'old' way of transactional purchase that has indefinite usage rights.
Now a software company can much more efficiently milk their userbase for money without really having to figure out meaningful value add beyond what they already do.
Also, prior to 3.3, unicode strings couldn't be written in a python 2/3 agnostic way. Of course dealing with binary data as strings is a pain in 2/3 agnostic code still, but I can't see personally how they could have done it better than they did.
In any event, the fact that there is discomfort changing the 'python' to be a python 3 verifies that things aren't exactly rosy. If there *were* no mess, there wouldn't be so much fretting about concurrent installs and python3 and python2.
As a python developer in the real world, I still frequently have to fret about making sure my code does contortions to run in python2 and python3 concurrently. If I were writing internal tools, I wouldn't have to care so much as I could choose the one and only version to support. However, as an owner of pypi content and supporting customers that want to use whatever python interpreter they have installed already, it's a headache.
With some other languages, I could target the oldest reasonable version and testing is required, but rarely is there an issue that needs accommodation. In python terms, today that would be targeting python 2.6 (There are a *lot* of RHEL6/CentOS6 users out there). In practice, I only support 2.6, 2.7, 3.4, and 3.5, and generally have to continually develop against 2.6 and 3.4 (2.7 and 3.5 generally don't need such continual explicit attention beyond what is given 2.6 and 3.4)
That's an overly rosy picture of Python 3. Install most linux distros and run 'python'. Odds are overwhelming that it will be python 2.
There are plenty of modules that *still* are python 2 only. Most are developed to work with both python 2 and 3. Very very few are python 3 only.
Now it's not as bad as angular 1 -> 2, it's *generally* not too terrible to accomodate both python 2 and 3 in the same codebase. You only get to pulling your hair out if you do a lot with binary data, and even then it's not too terrible. Python 3 could have done some other nice things, like recognizing xrange as an alternative name for range, viewitems as a name for items, and other similar things that would make it much easier to go to python three without either doing your own interop or using six all the time. On the flip side, when dealing with a framework like angular, you are *generally* less worried about end-users (you provide the entire runtime) versus something like python, where the non-developer users bring their version of the interpreter to your code.
There's another headache when it comes to living in python 2 world. They decided 2.7 was going to be the last, end of story. As a consequence, 'minor' 2.7 updates are now introducing featurues causing the same sort of compatibility caveats that you historically only saw on 2.5->2.6 type updates.
While in this specific case, your frustration is misplaced (basically, modern Windows UI sensibilities start with DirectWrite), I share your frustration in the broader sense.
I have had some 1 line utility function to shorten some common idiom, and had developers insisting that the utility function should instead import some big framework that inflates execution time by 30% and memory consumption by 50% so I use their identical 1 line function instead of 'reinventing' one from scratch.
Also same mentality that caused some guy yanking some small thing from npm to freak out a gigantic part of the NodeJS ecosystem.
Some of our new developers complain that we create yum and apt repositories for things, saying the fact that publishing to gems, cpan, pypi, npm, etc is good enough and yum/apt are the old, slow way of doing things.
Note I'm not even that particularly crusty yet, I just actually have to deal with users who aren't full time software developers.
I know offtopic, but wanted to say I feel your pain (though not this example).
A click through EULA. I'm sure that was thoroughly reviewed and taken seriously.
The wider industry has several exmaples of being more careful. Tesla is *now* being more careful, like their competition, which is a good thing. I don't know what it buys to continue to defend their previous behavior, which they themselves have realized was wrong.
This may be true, but competitors all were more strict about lane assist and more reluctant to use the term 'auto' in any way associated with the technologies. Google has avoided anything other than trained professional testers to use their system, and has publicly stated their opinion that a system that's 90% there is more dangerous than one not there at all, because user expectations are problematic.
Again, people always say how people who know anything about piloting aircraft know that autopilot is far more limited than the public imagination thinks. The problem being the market is not people who know anything about aircraft, but about common drivers. In their world, they have the 'auto' transmission. In that case, they say 'go forward' and don't have to think about it as it completely takes care of itself. That is the level of expectation set for automobile operators.
If you get your pilot license, you know full well the limitations of the technologies as it's part of the required training. Before you can make a misconception and fail with it, you have gone through personal training, hands on with an experienced pilot. In the Tesla case, there's a click through EULA that is probably not read and not given much weight, because we are just inundated with EULAs. This competes with Tesla execs going around praising how much safer the system is than the human operators, and tossing out apples to orange comparisons to make the case that the user is better of surrendering their attention to the system (the 'deaths per driven miles' statistic).
Also, the 'all inclusive' number includes all ages and variety of vehicles. Tall SUVs, 15 year old cars with fewer safety features. Cars with much older pieces and different levels of maintenance.
It would be interesting to compare Tesla autopilot specifically to good-condition highway miles driven of 2014+ model year vehicles with forward collision alert type systems. That would be a more fair comparison.
I'm saying that, in the Mercedes article, people are still going to be jackasses and tape soda cans to the steering wheel. It's still going to happen.
However, in the Mercedes case they call it assisst and require folks to fool the sensors to be unsafe, so that's a bit excusable.
Mercedes even had to pull an ad that indirectly implied that maybe, possibly the lane assist feature was in the same ballpark of an autonomous car.
So Tesla bad: using autopilot and not being strict about user attentiveness, Mercedes better by using 'assist', being very careful about messaging, and being strict about user attention.
Slashdot Mirror
I'd say for gaming it makes for a logical evolution of displays. Hell I'd love it for working in cubeland (so long as putting it on and taking it off is as easy as headphones).
The fixation on things like mobility, real or fake (omni directional treadmills) only hurts the chances for general adoption, perpetuating the notion that there's no value until you do some very intrusive things that most folks don't have the patience for. In reality, it need not be significantly more intrusive than a pair of headphones. For those of us who do not need to see our keyboards or controllers, it's no big deal now.
However, the prospect of having the world surround you instead of just on a desktop monitor is really nice. Of course, getting into it costs twice as much as a 27" 4k monitor, and current display density means you are making a tradeoff of high resolution for immersion.
AR in theory would be a strict superset. In practice either the virtual or the real portion is going to suffer horribly as the technology stands, and not a lot of reason to be optimistic for that changing. Wearable AR is just not in the cards yet.
I'm saying that *if* a site is competent enough to consider what you propose, it would be competent enough to do server side hashing. Hence a user should take ownership of how this is done to assure themselves, and *not* expect to audit every websites javascript implementation of their particular hashing scheme. So if you have a website, doing the right thing in the server is important. Doing additional things in the client doesn't really help if you've done the right backend stuff.
I think that's where we are deviating. I'm saying solutions like password managers and hashpass where the user *independently* has total control of the scheme make sense as a means of enforcing their sensibilities above and beyond what unknown methods the site is using. Solutions relying upon the javascript sent down by the site do not make sense as *those* guys have every reason to be able to do things right on the backend.
Client hashing would prevent collateral damage in such cases
No, it wouldn't. If the traffic is intercepted, then the fact that the data is the password straight or the result of a one-way hash is of little consequence to the attacker, since the target system takes the value verbatim. The server does not *know* that the user is using the blessed javascript implementation or html form. They are only able to take the submitted data at face value. If you use the result of a one-way hash as a password, then either way the password is known.
If you want to protect against interception in the event of defeating TLS, there must be some pre shared key component to it. Using the password as a pre-shared key is considered bad form as the frequent occurance of a leaked password database would cause cries of storing the password in plain text. Server side hash and salt is the only recognized strategy and deviating from that risks being crucified in the security world (trying to explain the subtleties of going off that is going to be a very uphill battle). So something like RSA, U2F, TOTP or similar supplementing a password in a two factor scheme is the generally accepted way to get both the benefit of an ultimately shared secret based approach and password protection.
Ultimately, as far as the *site* is concerned, server side is the most widely accepted strategy, and there's no value in terms of the security they provide in doing it both places. If you want to protect yourself, then HashPass will do that job, though a much more comprehensive approach is a master store of site unique passwords with no actual relationship between your passwords, and *that* would completely divorce your password in any sort of way from the site unique password, truly compartmentalizing an attack against one of your services.
So there exists a browser extension to implement what you desire, it is called HashPass.
However, if you use such a strategy, you *still* must have a password resilient to dictionary attacks. The attack scenario it provides *some* protection against is if you use a site that has poor security storage policies, without your knowledge (e.g. stored in clear text). The idea is that if such a crappy site gets compromised, it's view of plain text password is the end result of your client side salt, which now can be run against a dictionary attack. It basically is ensuring that *someone* is doing a secure hashing strategy that would reasonably protect a strong password in the manner the server side *should* be doing anyway.
If an otherwise secure site adds what you describe, it would do nothing to enhance security. If your password is *truly* strong and they employ proper salting and one way hash strategy (scrypt, PBKDF with adequate passes, what have you), then a leak of their password database is not actually that big a risk. If your password is weak, then the salting strategy client side doesn't add anything, as they could modify their brute force attack to do the client transform in a trivial fashion, and they can work their way back to the password you *really* use.
Note I *think* he's saying that whatever string the client ultimately sends to the server should still be one-way crypted and salted in the usual way. Meaning a compromise of the database still has reasonable protection.
He wants something to automagically take his password and make it unique per site so he doesn't have to remember them all. Note that this is what things like the extension Hashpass do, generate a site specific password derived from your master password and transformed for the site.
Of course, all this said, the dictionary attack required involves just adding that transform, hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts, and your password would be secure against dictionary attacks offline. It makes zero sense as part of a websites arsenal against attacks.
crunch those against known rainbow tables
Note that this *also* would be a sign of an incompetent site. Password databases should be impervious to rainbow tables. Also, a GPU would not really be that useful for a rainbow table. A rainbow table is a precomputed table of hashes, meaning it's a straight lookup rather than actually having to perform the hash calculation. A competent site would have a sufficiently long random salt incorporated to render rainbow table impossible.
Of course, dictionary attacks against offline database are still a problem, and so it would be good if your password is not likely in the first 100 trillion or so guesses a system would make (which on a decently secured password database would buy you about a year of time against 8 full time GTX 1080s working on your password and your password alone).
passwords should contain uppercase and lowercase letters, numbers and symbols
No, far more effective would be minimum password (phrase) length. People thinking 8 characters are fine as long as it is leet-speak is a problem. The way most people use uppercase, numbers, and symbols make the dictionaries a little more tedious, but not *that* much more so.
Sure, the most secure approach is totally random, but if people insist on it being human friendly, number of characters is the key point to emphasize.
they're definitely equal in being biological donors whose DNA pass on to future generations.
Passing on mitochondrial DNA doesn't really count.
Yes, a lot of work went in, but ultimately, all of the *significant* genetic material came from two parents. Passing on your mitochondrial DNA doesn't do anything to really shape your offspring (unless your mitochondrial DNA is just *really* messed up). Now if the donor egg somehow had defective Mitocondrial DNA, ok, this is at least somewhat useful.
But pretending this offspring has three equally biological parents is disingenuous.
Rather than local, I meant remote, but same house.
At least with emby, local rips are instant. I had a bear of a time with Plex Media server performance, so I migrated. That was a long time ago though.
I used to use plex. I've moved to emby.
Under linux, you might as well give up and run it under docker as they are very messy about their depedencies, but at least that's not too complicated.
For most places and efficient low cost configs, I'd say maybe 30-40/year in energy cost.
The upload bandwidth is killer. The performance of accessing the media is terrible (when I access a local rip, it's super high quality and *instant* seeking, versus streams from netflix and the like.
Actually, I'd say it would be more of a nightmare. Here we have the devils we know. In that scenario, it would be hellish even *knowing* what can't handle things.
Every hop in the network not being certain whether the next hop could or could not handle the conversation would be a nightmare in the making.
It seems funny, because that *ultimately* is the reality of IPv6.
The difference is that in the above scheme, *knowing* whether a hop in the network could or could not do 'big addresses' would be more difficult. With IPv6, it allows things to be very clearly delineated whether the communication is IPv6 capable or not.
The biggest obstacle to IPv6 was the stubborn resistance to any form of NAT. That IPv6 should be all or nothing. The piece needed to make IPv6-only *clients* possible was carrier grade NAT64. Yes, on the server and as a carrier, you need IPv4 *and* IPv6, but the vast bulk of endpoints can be IPv6-only now, taking the pressure off of IPv4. Of course this would have been nice to do a decade ago instead of the last two years or so, so that new servers could have a more comfortable time getting IPv4.
I personally would rather *not* have crypto at the IP or TCP layer. Reason being is that in practical terms, updates *must* be delivered through kernel updates. Given the nature of crypto updates, I'd much rather have librariers in userspace be the channel for updates.
I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.
The issues with DNS/DNSSEC are more reasonably addressed in the DNS layer. There is a lack of will to tackle that problem, but that's the same lack of will that would make implementing at a lower layer impractical as well.
When I pull up my cell phone ip information, it's IPv6.
Now that there's carrier-grade nat to allow ipv6-only endpoints to speak to ipv4-only hosts, it *finally* is plausible to offer most mobile/residential ipv6-only. So a lot of the people who are ipv6-only are precisely the ones that would never realize it.
For enterprise networks and internal networks, those are ipv4 and likely to stay ipv4-only (which is a bummer for software development, because IPv4/IPv6 agnostic code is still relatively rare, since there's so many subtle bugs trying to use AF_INET6 for both, and it's more complicated to have both AF_INET and AF_INET6 addresses).
It's an inefficiency that is very intentional.
The software industry realized that for a lot of their users, they couldn't extract upgrade licenses from customers readily because they had already done *too* good a job. Functionality wise, a lot of people don't need anything newer than Photoshop 6 (released 16 years ago). A lot of people could use Office 97. Of course some things have slowly evolved technology wise that *ultimately makes people need updates and there's some forced updates (e.g. fun incompatibilities in ms office formats), In general though, update revenue became a big uncertainty.
So the solution is to switch to rental models, subscriptions, et al. Licenses that terminate when you stop paying, rather than the 'old' way of transactional purchase that has indefinite usage rights.
Now a software company can much more efficiently milk their userbase for money without really having to figure out meaningful value add beyond what they already do.
Also, prior to 3.3, unicode strings couldn't be written in a python 2/3 agnostic way. Of course dealing with binary data as strings is a pain in 2/3 agnostic code still, but I can't see personally how they could have done it better than they did.
In any event, the fact that there is discomfort changing the 'python' to be a python 3 verifies that things aren't exactly rosy. If there *were* no mess, there wouldn't be so much fretting about concurrent installs and python3 and python2.
As a python developer in the real world, I still frequently have to fret about making sure my code does contortions to run in python2 and python3 concurrently. If I were writing internal tools, I wouldn't have to care so much as I could choose the one and only version to support. However, as an owner of pypi content and supporting customers that want to use whatever python interpreter they have installed already, it's a headache.
With some other languages, I could target the oldest reasonable version and testing is required, but rarely is there an issue that needs accommodation. In python terms, today that would be targeting python 2.6 (There are a *lot* of RHEL6/CentOS6 users out there). In practice, I only support 2.6, 2.7, 3.4, and 3.5, and generally have to continually develop against 2.6 and 3.4 (2.7 and 3.5 generally don't need such continual explicit attention beyond what is given 2.6 and 3.4)
That's an overly rosy picture of Python 3. Install most linux distros and run 'python'. Odds are overwhelming that it will be python 2.
There are plenty of modules that *still* are python 2 only. Most are developed to work with both python 2 and 3. Very very few are python 3 only.
Now it's not as bad as angular 1 -> 2, it's *generally* not too terrible to accomodate both python 2 and 3 in the same codebase. You only get to pulling your hair out if you do a lot with binary data, and even then it's not too terrible. Python 3 could have done some other nice things, like recognizing xrange as an alternative name for range, viewitems as a name for items, and other similar things that would make it much easier to go to python three without either doing your own interop or using six all the time. On the flip side, when dealing with a framework like angular, you are *generally* less worried about end-users (you provide the entire runtime) versus something like python, where the non-developer users bring their version of the interpreter to your code.
There's another headache when it comes to living in python 2 world. They decided 2.7 was going to be the last, end of story. As a consequence, 'minor' 2.7 updates are now introducing featurues causing the same sort of compatibility caveats that you historically only saw on 2.5->2.6 type updates.
While in this specific case, your frustration is misplaced (basically, modern Windows UI sensibilities start with DirectWrite), I share your frustration in the broader sense.
I have had some 1 line utility function to shorten some common idiom, and had developers insisting that the utility function should instead import some big framework that inflates execution time by 30% and memory consumption by 50% so I use their identical 1 line function instead of 'reinventing' one from scratch.
Also same mentality that caused some guy yanking some small thing from npm to freak out a gigantic part of the NodeJS ecosystem.
Some of our new developers complain that we create yum and apt repositories for things, saying the fact that publishing to gems, cpan, pypi, npm, etc is good enough and yum/apt are the old, slow way of doing things.
Note I'm not even that particularly crusty yet, I just actually have to deal with users who aren't full time software developers.
I know offtopic, but wanted to say I feel your pain (though not this example).
A click through EULA. I'm sure that was thoroughly reviewed and taken seriously.
The wider industry has several exmaples of being more careful. Tesla is *now* being more careful, like their competition, which is a good thing. I don't know what it buys to continue to defend their previous behavior, which they themselves have realized was wrong.
This may be true, but competitors all were more strict about lane assist and more reluctant to use the term 'auto' in any way associated with the technologies. Google has avoided anything other than trained professional testers to use their system, and has publicly stated their opinion that a system that's 90% there is more dangerous than one not there at all, because user expectations are problematic.
Again, people always say how people who know anything about piloting aircraft know that autopilot is far more limited than the public imagination thinks. The problem being the market is not people who know anything about aircraft, but about common drivers. In their world, they have the 'auto' transmission. In that case, they say 'go forward' and don't have to think about it as it completely takes care of itself. That is the level of expectation set for automobile operators.
If you get your pilot license, you know full well the limitations of the technologies as it's part of the required training. Before you can make a misconception and fail with it, you have gone through personal training, hands on with an experienced pilot. In the Tesla case, there's a click through EULA that is probably not read and not given much weight, because we are just inundated with EULAs. This competes with Tesla execs going around praising how much safer the system is than the human operators, and tossing out apples to orange comparisons to make the case that the user is better of surrendering their attention to the system (the 'deaths per driven miles' statistic).
Also, the 'all inclusive' number includes all ages and variety of vehicles. Tall SUVs, 15 year old cars with fewer safety features. Cars with much older pieces and different levels of maintenance.
It would be interesting to compare Tesla autopilot specifically to good-condition highway miles driven of 2014+ model year vehicles with forward collision alert type systems. That would be a more fair comparison.
I'm saying that, in the Mercedes article, people are still going to be jackasses and tape soda cans to the steering wheel. It's still going to happen.
However, in the Mercedes case they call it assisst and require folks to fool the sensors to be unsafe, so that's a bit excusable.
Mercedes even had to pull an ad that indirectly implied that maybe, possibly the lane assist feature was in the same ballpark of an autonomous car.
So Tesla bad: using autopilot and not being strict about user attentiveness, Mercedes better by using 'assist', being very careful about messaging, and being strict about user attention.