I suppose I think of censorship as a bit more dire than removing a decades old joke from versions of documentation. Is it censorship if I propose a change to add that "rather than using abort(), I have a modest proposal for an alternative.." and my change gets denied? Does everyone's submission to add commentary to the documentation have to be allowed, because to do otherwise is to censor that person's speech, even as they have tons of other venues as even their own code tracking system would keep it available for posterity, even if not currently in new downloads?
In this case, the business does not care about 'communication', they care that the call is a legitimate request to buy goods or services. Today a robocall is 0% chance, but this would represent a probable transaction.
Sure, it's creepy. Sure, I'd rather it be blatantly obvious what it is. However, they do have a legitimate concern that an obviously artificial behavior will get terminated by someone mistaking it for spam (no, even if it is by machine, a request for a reservation is not spam).
Now it can more naturally react and say some sentence containing the phrase 'google assisstant', which would be clear as to what it is, but doesn't have to sound intentionally synthetic in the process.
I presume this is for casual idiocy (the kind that has gotten various companies in trouble about someone leaving an unencrypted storage device or laptop with customer data and it getting stolen).
Because presumably places of businesses get obviously recorded spam calls like everyone else, and for the moment no one is going to assume what sounds like a recording is going to be interactive and/or on behalf of an individual customer, and will try to keep the line open/save time by hanging up before they even hear enough words to recognize it wants to make an appointment/reservation.
All in all, impressive as it sounded, this is one area I can't understand why I'd need Google to take care of it for me. In the time it takes for me to tell google to do this, I could have just called the restaurant or whatever.
In this context, it's calling a business as a potential customer. Hanging up on what from all appearances is a potential customer is a good way not to have a job anymore. In fact, even if it is not a human but is calling to arrange the business of a real human customer, it's probably still a bad move to hang up.
In general, the microsd slot at least in motorola made a big comeback. I presumed across the market apart from Google branded devices they are easily had now.
To be fair, if you are faced with endusers either doing password or doing 'something they have' and unable to reasonably require them to do both, it's probably best to let them use 'something they have'.
Biometric of course seems to be the order of the day, though I have a harder time defending the security of that sincerely.
The main thing is that electron means everyone has a distinct browser process. It eschews OS platform provided facilities and as such has to reinvent the wheel and resource sharing between applications is pretty well defeated.
Beyond that, there's the *tendency* for these developers to be sloppy and stop at 'mostly works'. This is not to say you cannot make a solid application with these tools, just that a lot of people who cannot otherwise manage to produce desktop applications can *appear* to succeed with this set of tools, even when they have behaviors where it should really be failing.
The last thing I'l mention is lack of a 'standard' GUI application type behavior. People work with it and yes, css styled spans and divs make for a much more efficient remote drawing sort of protocol than other available options, but the APIs to do usual desktop application stuff are fragmented and ever evolving without ever being embraced in a broader standard (the broader standard continues to focus on the mission of semantically meaningful document markup).
I have presumed the main difficulty in Aviation owes to the fact that it is such a selective market and pilots are simply expected to know more, and adventures in making piloting much more accessible just don't have a good enough business case for upside, and a lot of downside in terms of liability, regulation and safety downsides.
I don't think I'd go so far as to say HTML5 based installer sounding awesome... It's an installer, not much to say about it for the last decade or so. There's no amount of innovation in an installer that's going to change the fortunes of the platform at this point. Even if wanting to make changes, I would think that reworking so much of it would set you back so far and there's no way walking back from that sort of rewrite will save time for whatever incremental functionality people can dream up. The main 'benefit' of HTML5 based applications seem to be able to say 'screw you' to any platform native feel and HIG standards.
I will say that Gnome shell shows a decent implementation of 'web inspired' architecture (with CSS and javascript) can do, though I'm not sure I agree with their vision, they don't seem to suffer from 'crappy foundation feel' like all the applications you cited.
The scenarios where autopilot is safe are relatively specific. For example, you can't autopilot at 500ft through Manhattan.
Additionally, for a landing area to be able to land and be clear in 24 seconds, that goal implies a bit of crowding of the area.
Those exceptional scenarios are common enough that the ambition for fully autonomous aircraft for people without aviation training may be a bit much to do.
I will agree, with the addition of a safety system automation would be good. Not something that allows the operator to ignore operating and it will generally do the job (as is the case for tesla autopilot), but one that will activate and prevent an out-right crash, but not helping the user go in any particular direction or anything.
The issue is that micromanaging multiple rotors is, relatively speaking, a solved problem and that's generally the drone use case that is considered 'solved' (translating a high level maneuver to the appropriate rotor actions). Cars do not have this as a challenge, rolling the car forward and turning it left and right is not something that requires a 'drive by wire' sort of system, so there isn't really that much of an analogous challenge
Autonomous drone navigation without a remote pilot is not a solved problem, much as it is not a solved problem for driving.
Even assuming there were some examples of autonomous drone deliveries for small packages, the problem is the amount of damage a 10lb drone with payload can inflict accidentally is different than something weighing several hundred pounds. Additionally the speed is going to be different, drone deliveries are not generally looking to move at hundreds of miles an hour (can be patient, no human passenger, the benefit is mainly skipping circuitous road defined paths). So on top of being heavier, they would be wanting to move probably an order of magnitude faster, generally.
The challenge is that for consumer, absolutely your perspective is relevant.
For Nintendo, and in fact as an industry as a whole, business goals have moved to extracting recurring revenue, not what is best or most desirable to the customer.
When you carry forward your games that you want to replay without effort, they get nothing out of that transaction. Now in a competitive landscape, having a positive sentiment on that front matters. Additionally, as Nintendo will presumably move to more cross-device revenue from their properties, they will want a subscription type revenue to cover the experience, since they won't have such an experience of forced migration when they have apps on android and ios devices that are generally backwards compatible by nature.
In other words, there isn't competition inclined to drive Nintendo away from this path at the moment.
I share the thought that those downloads do not *necessarily* mean the company deployed insecure software, but to say that 'most of these companies' are patching the security issues is way too optimistic. Sure some, but most are completely oblivious.
Note that a lot of these top-100 companies is chock full of outdated closed source software too.
On a recent random check of a few laptops from one of those sorts of companies, the average was about 2 years since they last received any update whatsoever from Microsoft (their update mechanism had broken and they had no reporting about it). I was working with another company and they were intentionally using a commercial product from a company that went out of business 15 years ago, because it would be too much trouble to migrate off.
Here the open/closed doesn't matter, either way they are terrible at software currency.
If you really need to fix the problem, you *must* hold the decision makers accountable.
There will always be some personnel that will do what they are asked, because they don't care or they don't know how bad things are. If they can't find any in their own country, they will offshore to developers in a country that just have no reason whatsoever to care.
Note that I'm not particularly enthusiastic about unroll.me's model or particularly trusting in their intent, but broadly speaking even if they can justify processing the data, the effort associated with auditing and proving their intent and risk according to the specific terms of GPDR could still be considered too much a burden to be worth it.
That's generally the issue with many regulations. They mean well and there is a definite need for some regulation to serve the purpose, but often they are structured such that compliance also inflicts significant cost upon groups that were not doing anything to be vaguely part of the problem.
I think the goal is admirable, but reading the 'nightmare GPDR letter' highlights that doing things above board is good and required, but it also requires all good actors to respond to some potentially detailed inquiries. This includes both generic information about where and how data about the user is stored (which shouldn't be too much of a burden) to the specific unique details to a specific individual's data. This either means manual effort and/or creating specialized reporting to react to GPDR requests.
I think that's the burden people get worried about, how much burden it puts on *showing* you are not intentionally or at risk for accidentally having data disclosed.
While I wouldn't doubt there are unfortunate facets of their business model that have not come to light, it could also be that avoiding the burden of having to reply to GPDR requesst is worth losing the market, even if you could give replies above board.
On the getting a warning that it's stuck while you are away, the question is what do you do about it? I know that I couldn't say "Oh, I've got to go home, my robot vacuum is stuck". Frankly, it's the sort of scenario that can wait a day.
Sure, I suppose voice commands to specifically do a specific room could be handy, though I continue to be disappointed that the only way companies are doing this is by going through internet servers, when all parties to the situation are in the same house. Of course for spot cleaning in response to an event, it's hard to beat the immediacy of pulling out the vacuum and manually doing it, and it's not like that is particularly onerous. It can be tedious to do whole carpet vacuum cleaning routinely and it's nice to automate that away, but spot cleaning is fairly easy to take care of and for the time being much quicker to do yourself.
On the washing machine, again, if imbalance detected, shut down and make a noise for attention. If you did leave and as such cannot respond in a timely manner, well, it's again not an urgent thing to take care of.
Already my phone annoys the crap out of me with notifications about stuff that can wait without instrumenting all my appliances to then nag me as well.
Slashdot Mirror
I suppose I think of censorship as a bit more dire than removing a decades old joke from versions of documentation. Is it censorship if I propose a change to add that "rather than using abort(), I have a modest proposal for an alternative.." and my change gets denied? Does everyone's submission to add commentary to the documentation have to be allowed, because to do otherwise is to censor that person's speech, even as they have tons of other venues as even their own code tracking system would keep it available for posterity, even if not currently in new downloads?
In this case, the business does not care about 'communication', they care that the call is a legitimate request to buy goods or services. Today a robocall is 0% chance, but this would represent a probable transaction.
Sure, it's creepy. Sure, I'd rather it be blatantly obvious what it is. However, they do have a legitimate concern that an obviously artificial behavior will get terminated by someone mistaking it for spam (no, even if it is by machine, a request for a reservation is not spam).
Now it can more naturally react and say some sentence containing the phrase 'google assisstant', which would be clear as to what it is, but doesn't have to sound intentionally synthetic in the process.
I presume this is for casual idiocy (the kind that has gotten various companies in trouble about someone leaving an unencrypted storage device or laptop with customer data and it getting stolen).
Of course, that same distinction between usb mass storage devices and mtp/ptp protocol phone also means it can't generally be used as a boot device.
Because presumably places of businesses get obviously recorded spam calls like everyone else, and for the moment no one is going to assume what sounds like a recording is going to be interactive and/or on behalf of an individual customer, and will try to keep the line open/save time by hanging up before they even hear enough words to recognize it wants to make an appointment/reservation.
All in all, impressive as it sounded, this is one area I can't understand why I'd need Google to take care of it for me. In the time it takes for me to tell google to do this, I could have just called the restaurant or whatever.
Then they'll subtly modulate their opening words and recognize each other as bots and go modem sounds at each other for improved efficiency.
In this context, it's calling a business as a potential customer. Hanging up on what from all appearances is a potential customer is a good way not to have a job anymore. In fact, even if it is not a human but is calling to arrange the business of a real human customer, it's probably still a bad move to hang up.
Well, the moto g6 currently fits that bill:
https://www.motorola.com/us/pr...
As does the previous gen g5 plus.
In general, the microsd slot at least in motorola made a big comeback. I presumed across the market apart from Google branded devices they are easily had now.
To be fair, if you are faced with endusers either doing password or doing 'something they have' and unable to reasonably require them to do both, it's probably best to let them use 'something they have'.
Biometric of course seems to be the order of the day, though I have a harder time defending the security of that sincerely.
I would have guessed WebAuth to be a bit smoother...
The main thing is that electron means everyone has a distinct browser process. It eschews OS platform provided facilities and as such has to reinvent the wheel and resource sharing between applications is pretty well defeated.
Beyond that, there's the *tendency* for these developers to be sloppy and stop at 'mostly works'. This is not to say you cannot make a solid application with these tools, just that a lot of people who cannot otherwise manage to produce desktop applications can *appear* to succeed with this set of tools, even when they have behaviors where it should really be failing.
The last thing I'l mention is lack of a 'standard' GUI application type behavior. People work with it and yes, css styled spans and divs make for a much more efficient remote drawing sort of protocol than other available options, but the APIs to do usual desktop application stuff are fragmented and ever evolving without ever being embraced in a broader standard (the broader standard continues to focus on the mission of semantically meaningful document markup).
I have presumed the main difficulty in Aviation owes to the fact that it is such a selective market and pilots are simply expected to know more, and adventures in making piloting much more accessible just don't have a good enough business case for upside, and a lot of downside in terms of liability, regulation and safety downsides.
I don't think I'd go so far as to say HTML5 based installer sounding awesome... It's an installer, not much to say about it for the last decade or so. There's no amount of innovation in an installer that's going to change the fortunes of the platform at this point. Even if wanting to make changes, I would think that reworking so much of it would set you back so far and there's no way walking back from that sort of rewrite will save time for whatever incremental functionality people can dream up. The main 'benefit' of HTML5 based applications seem to be able to say 'screw you' to any platform native feel and HIG standards.
I will say that Gnome shell shows a decent implementation of 'web inspired' architecture (with CSS and javascript) can do, though I'm not sure I agree with their vision, they don't seem to suffer from 'crappy foundation feel' like all the applications you cited.
The scenarios where autopilot is safe are relatively specific. For example, you can't autopilot at 500ft through Manhattan.
Additionally, for a landing area to be able to land and be clear in 24 seconds, that goal implies a bit of crowding of the area.
Those exceptional scenarios are common enough that the ambition for fully autonomous aircraft for people without aviation training may be a bit much to do.
I will agree, with the addition of a safety system automation would be good. Not something that allows the operator to ignore operating and it will generally do the job (as is the case for tesla autopilot), but one that will activate and prevent an out-right crash, but not helping the user go in any particular direction or anything.
The issue is that micromanaging multiple rotors is, relatively speaking, a solved problem and that's generally the drone use case that is considered 'solved' (translating a high level maneuver to the appropriate rotor actions). Cars do not have this as a challenge, rolling the car forward and turning it left and right is not something that requires a 'drive by wire' sort of system, so there isn't really that much of an analogous challenge
Autonomous drone navigation without a remote pilot is not a solved problem, much as it is not a solved problem for driving.
Even assuming there were some examples of autonomous drone deliveries for small packages, the problem is the amount of damage a 10lb drone with payload can inflict accidentally is different than something weighing several hundred pounds. Additionally the speed is going to be different, drone deliveries are not generally looking to move at hundreds of miles an hour (can be patient, no human passenger, the benefit is mainly skipping circuitous road defined paths). So on top of being heavier, they would be wanting to move probably an order of magnitude faster, generally.
The challenge is that for consumer, absolutely your perspective is relevant.
For Nintendo, and in fact as an industry as a whole, business goals have moved to extracting recurring revenue, not what is best or most desirable to the customer.
When you carry forward your games that you want to replay without effort, they get nothing out of that transaction. Now in a competitive landscape, having a positive sentiment on that front matters. Additionally, as Nintendo will presumably move to more cross-device revenue from their properties, they will want a subscription type revenue to cover the experience, since they won't have such an experience of forced migration when they have apps on android and ios devices that are generally backwards compatible by nature.
In other words, there isn't competition inclined to drive Nintendo away from this path at the moment.
No one has a lifetime of reading monospace text anymore, which is the only thing this study covered.
Also, in most cases text input have their spaces normalized.
I share the thought that those downloads do not *necessarily* mean the company deployed insecure software, but to say that 'most of these companies' are patching the security issues is way too optimistic. Sure some, but most are completely oblivious.
Note that a lot of these top-100 companies is chock full of outdated closed source software too.
On a recent random check of a few laptops from one of those sorts of companies, the average was about 2 years since they last received any update whatsoever from Microsoft (their update mechanism had broken and they had no reporting about it). I was working with another company and they were intentionally using a commercial product from a company that went out of business 15 years ago, because it would be too much trouble to migrate off.
Here the open/closed doesn't matter, either way they are terrible at software currency.
If you really need to fix the problem, you *must* hold the decision makers accountable.
There will always be some personnel that will do what they are asked, because they don't care or they don't know how bad things are. If they can't find any in their own country, they will offshore to developers in a country that just have no reason whatsoever to care.
Note that I'm not particularly enthusiastic about unroll.me's model or particularly trusting in their intent, but broadly speaking even if they can justify processing the data, the effort associated with auditing and proving their intent and risk according to the specific terms of GPDR could still be considered too much a burden to be worth it.
That's generally the issue with many regulations. They mean well and there is a definite need for some regulation to serve the purpose, but often they are structured such that compliance also inflicts significant cost upon groups that were not doing anything to be vaguely part of the problem.
I think the goal is admirable, but reading the 'nightmare GPDR letter' highlights that doing things above board is good and required, but it also requires all good actors to respond to some potentially detailed inquiries. This includes both generic information about where and how data about the user is stored (which shouldn't be too much of a burden) to the specific unique details to a specific individual's data. This either means manual effort and/or creating specialized reporting to react to GPDR requests.
I think that's the burden people get worried about, how much burden it puts on *showing* you are not intentionally or at risk for accidentally having data disclosed.
While I wouldn't doubt there are unfortunate facets of their business model that have not come to light, it could also be that avoiding the burden of having to reply to GPDR requesst is worth losing the market, even if you could give replies above board.
On the getting a warning that it's stuck while you are away, the question is what do you do about it? I know that I couldn't say "Oh, I've got to go home, my robot vacuum is stuck". Frankly, it's the sort of scenario that can wait a day.
Sure, I suppose voice commands to specifically do a specific room could be handy, though I continue to be disappointed that the only way companies are doing this is by going through internet servers, when all parties to the situation are in the same house. Of course for spot cleaning in response to an event, it's hard to beat the immediacy of pulling out the vacuum and manually doing it, and it's not like that is particularly onerous. It can be tedious to do whole carpet vacuum cleaning routinely and it's nice to automate that away, but spot cleaning is fairly easy to take care of and for the time being much quicker to do yourself.
On the washing machine, again, if imbalance detected, shut down and make a noise for attention. If you did leave and as such cannot respond in a timely manner, well, it's again not an urgent thing to take care of.
Already my phone annoys the crap out of me with notifications about stuff that can wait without instrumenting all my appliances to then nag me as well.