I'm dissatisfied streaming, but that's because in the last two years I've seen my Suddenlink Internet bill (after calling them to negotiate a lower price each year) go up by 66%, from $30/mo. to $50/mo., despite having the exact same 50 Mbps connection with a 250GB/mo. data cap the entire time. It's the lowest tier of service they offer, so there are no cheaper options through them. In my repeated searches for alternatives (cable, DSL, WISP, satellite, whatever), what I've discovered is that their biggest competition currently comes from Frontier DSL...which offers 3 Mbps for $30/mo..
The 3 is not a typo.
Mind you, the area I live in is flat terrain with over 200K people, so we aren't in difficult terrain or miles away from civilization. It's a metropolitan area centrally located between three of the nation's ten largest cities, but the absolute cheapest, most rock-bottom, lowest available broadband service is still $50/month. In 2017. Which is about the same as what I was paying back in 2013 when 50 Mbps was the highest tier they offered and there were no data caps on any plans.
The only change around here during that time was that Verizon DSL was around back in 2013 with a 10 Mbps plan. But Verizon exited the area a few years ago. With the next closest plan being Frontier's 3 Mbps, Suddenlink is apparently free to gouge its customers without fear that we'll leave for someone else. Because where else would we go?
What. The. Hell.
So, yes, I'm dissatisfied. The only thing I was more dissatisfied with was my cable TV bill back before I ended that.
Sure, which is why RSS was able to be built using XML. But if you want to fix the problems in RSS, you need something that isn't RSS. They could have implemented their ideas in XML and given it a different name, but if you're already creating a new format, why use XML when the library support in the relevant software stacks makes it far easier to export to JSON in far fewer lines of code?
A) The duplicate issue is a model problem. RSS doesn't require unique identifiers, so clients can't distinguish between outdated entries that have been removed and edited entries that have been replaced. We need to keep the former so the user can read them, but the latter need to be eliminated, lest we have both the original and edited versions in the client. Even if the publisher and the client both follow the RSS spec, it's still left to the clients to implement their own special sauce to recognize duplicates. I probably see this happen once a week with Slashdot's feed alone.
B) Yes, people read old content. I can't count how many times I've started reading a webcomic years after it launched and wished that I was able to go back to the start in the feed, since it'd make it easier to track my position. Allowing pagination enables them to make it possible for people like me to go back through their content as far as we want.
C) While favicons are usually at the root as a matter of convention, the correct way to specify their location is through the use of <link rel="shortcut icon"/> in the head of a page. Because that's not part of the RSS spec, clients are left to themselves to try to find the favicon, either by hoping it's at root or by scraping the site to see if it specifies the location via a link tag. I used to run a very modest site that published an RSS feed, and I can't count how many requests I got for a favicon that didn't exist from RSS clients trying to find it.
Most of what you're saying amounts to, "I haven't had any problems, so there aren't any", whereas I've actually had problems with each of these areas, so I'm looking forward to seeing the possibility of some movement in the space.
You've listed one problem, and were that the only one, you'd be right. But it wasn't. The summary itself obliquely mentions three other problems...
Problem: Duplicate entries frequently appear in feed clients. Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years. Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.
Given all of those, a new format is not just the obvious solution, it's the only solution, which is why they had to create the new format to address those issues, among many other ones. Once you realize that fact, basing it on JSON or something else simply makes sense, what with it having far simpler and more ubiquitous library support in the software stacks involved, which is in addition to it being simpler to read and write.
I linked to three clients in the summary. Of those, I personally use Feedbin and have been a huge fan of it ever since Google Reader shut down. It's operated as a for-pay service, but the developer open sources all of the code, so if you have your own servers you can run it yourself.
People making mistakes implementing a spec is not in itself a good reason to drop it.
Were that the sole difference, I'd wholly agree, but that's absolutely not the case here, which is why I tried to draw attention in the summary to some of the more substantive differences involved with this particular format. Had they simply ported RSS to JSON, this wouldn't be a story. Instead, they created a new format that is designed to address the issues they've faced in working with RSS and Atom over the last few decades, and in the process of doing so, it also made sense to switch to JSON.
I actually find it rather unfortunate that they named it "JSON Feed" because it obfuscates the fact that the most important changes aren't about the switch to JSON, but are rather about the ways in which they're using it.
It brings me an irrational amount of happiness to see that linked in the very first comment, since I had actually pulled up that strip and considered including it in the summary, but decided against it in the end.
I don't disagree with any of the facts you've said. Where I differ is that I think most of that stuff was more important to Apple than to society, particularly with regards to the influence they were able to exert, hence my leaving it out.
As for changing the music industry, the change to digital was already happening. iTunes and the iPod helped give it a significant push, to be sure, but digital was already established as the successor to CDs at that point, just as CDs had been the successor to cassettes.
Not mentioning the iPod was an intentional omission, actually. While the iPod helped the company take the next step in its recovery from near-bankruptcy, and also demonstrated that they had the ability to move into markets outside of computers, it didn't have a massive cultural impact. Sure, it had an impact, but not on the scale of the other revolutions being discussed.
If they launched something "as successful as" the iPod today, it'd likely be viewed as little more than a blip in their product lineup, much like the Apple TV and Apple Watch, neither of which have managed to break out yet in a big way.
They're only proprietary formats until everyone else adopts them
No, they're still proprietary at that point too. They may no longer be considered "non-standard" if everyone adopts them as standard, but that doesn't make them any less proprietary.
They may not have one of those moments again, but I think it's too early to say, since those sorts of revolutionary shifts only occur once every decade or two at best.
Thinking back over the last 50 years or so, we've had three biggest revolutions in our everyday approach to technology: PCs, the Internet, and smartphones. Apple was able to ride or contribute to each of those waves, first with the original Mac, then with the iMac (the "i" stood for Internet, as you'll recall), and then with the iPhone. Those sorts of revolutions don't come often. Again, we're talking once every decade or two at best.
But it's been 10 years since the iPhone ushered in the modern age of smartphones, so where's the next thing? It's may be autonomous cars, which Apple is known to be working on, but that technology is still a few years away from prime time. It could be AI assistants. Apple is already lagging behind their competitors in that area, despite being one of the earliest to market with a widely deployed assistant, but it's arguable whether these assistants will eventually become features of other products or revolutionary products unto themselves. It may be AR/VR, which is an area they've said is of great interest to them and in which they've made various acquisitions, but it's still too expensive to become ubiquitous, too nerdy to be culturally acceptable, and a bit like a hammer looking for a nail, so we're still a few years away from AR/VR becoming a revolution, assuming it actually ever happens.
No matter which way you cut it, we're still a few years away from Apple needing to reinvent itself around a new revolution, so I think it's a bit too early to say with certainty that they've missed the boat, though you may well be proven right in a few years if they do in fact miss the boat.
I'll grant that they've come a long way from the rootkit scandal, such as when they responded to the Xbox One's original, draconian policy of tying discs to consoles so friends couldn't loan games to each other with their own, much better policy for sharing games, but that rootkit debacle destroyed a lot of trust.
I consider myself to be one of the more lenient ones around here, in that I'm fine with owning other products of theirs, provided they're sandboxed or disconnected from anything important, but the notion of running a Sony-developed OS that has the ability to tell them everything about my life? Not until I'm convinced their interests align with mine, which is to say, not a chance in hell as long as they are one of the major players in the media industry.
Building on what you said, biometrics are generally safe to use for identification (i.e. I'm referring to X person), not authentication (i.e. I am X person). In much the same way that many of us here are identifiable by unique usernames that everyone else can see, biometrics are merely pieces of information that (mostly) uniquely identify each of us, but we should not assume that they will remain private or secure.
If you're dealing with a secure system, you shouldn't be treating biometrics as anything more than a username.
The entire universe is a game with a strict set of rules. We may not understand them all, but we know they exist and that there's even the possibility that different universes have different rules. If having a strict set of rules within which a thing operates precludes that thing from being considered "intelligent", then apparently humans aren't intelligent either. We're just components in a universe-sized quantum computer implementing algorithms that we don't understand, in much the same way that AlphaGo is implementing algorithms that it doesn't understand.
But that's not a particularly useful way to think about things most of the time, so we've instead accepted that we can refer to any of these sorts of complex algorithms that are capable of competing with human intelligence as "AI". Granted, AlphaGo is limited to the problem space for which it was designed, so it isn't a general purpose AI, but it is nonetheless still an AI.
Suggesting otherwise is just playing games with semantics, usually because you don't like the implications involved with accepting that we now have purpose-built algorithms that can displace the need for human intelligence in specific, complex tasks. Regardless of what you decide to call them, that's an awesome and terrifying fact.
Are you talking about Microsoft Sync? The infotainment system? That's hardly the same as software used to make decisions that have the potential to kill you if they go wrong.
even though they are testing in very controlled conditions, their drivers still need to take control frequently.
You've got your statement backwards: the reason they take control frequently is because they are only testing in controlled conditions.
The world isn't uniformly filled with controlled conditions, so they take control anytime they enter conditions the system isn't yet designed or authorized to operate in (e.g. inclement weather, construction zone, power outage, unmapped shortcut, etc.). Each time they do, the current regulations in California dictate that it counts towards the same statistic that measures the number of times they take control to avoid an accident, even though the latter is vastly different and little more than a rounding error compared to the former. And that's where this reporting about them needing to "take control frequently" is coming from.
Most of these cars (Uber excepted) are already to the point where it's exceedingly uncommon for them to take control to avoid an accident, which is why the companies have been lobbying California to allow them to break the numbers apart (while still reporting both) so that they can provide the public with better granularity and a clearer understanding of their safety record. It's likely California will allow them to do so, since it's clearly in the best interests of the public.
In the meantime, however, naysayers have cited the inflated number without context in order to imply there's a problem, when that really isn't the case at all.
Oh, and regarding regulation, self-driving cars can't operate in states unless they're licensed, meaning that states are more or less opt-in for self-driving cars. In the states that have opted-in, such as California, they mostly do exercise an appropriate level of government oversight. For instance, California kicked Uber's self-driving cars out of the state for operating without a license, require that self-driving cars pass certain safety thresholds (including simulations) before being allowed on the road, and mandate that the companies involved publicly disclose various statistics regarding the safety of their vehicles.
If your state allows self-driving cars but isn't doing that, it's inevitable that some bad actors (e.g. Uber) will abuse that situation to their advantage, but they aren't indicative of the industry as a whole. The appropriate fix is to take the issue up with your state.
Again, however, all of this is separate from the topic of whether or not the market has decided against self-driving cars, which it clearly hasn't.
A) Most humans would fail to meet the bar you just set.
B) Nothing you said relates to the topic I was addressing (whether the market has declared the tech a flop).
C) You're conflating the repeated failures of one particular company for the failures of the industry as a whole.
What I keep hearing from these examples involving Uber is that Uber should not be testing self-driving cars, since they are demonstrating a history of ignoring warning signs and causing dangerous situations, first in California (e.g. the red light running that got them kicked out of the state) and now in Pittsburgh. Meanwhile, Google, Tesla, and a host of other companies have been demonstrating automated driving records that already far exceed the safety expectations of human drivers, though they're being careful with the tests and the conditions under which they conduct them.
Back on point: the full-fledged technology isn't yet ready for the market, which is why it isn't yet on the market, which is why it's plain silly to suggest that it's already flopped in the market, particularly so given the obvious demand for it, should it ever arrive.
Your comment would carry a bit more "oomph" if fully autonomous cars had already hit the market and flopped, but they clearly haven't. Instead, what we have so far are half-implementations and "advanced cruise control", all of which have been headline features driving sales for the handful of cars that have them.
On the plus side, you're continuing the tradition of trolls who have denied the marketability of everything from PCs to the Internet to smartphones in the years immediately prior to their breakout success, despite the writing being on the wall to anyone paying attention.
Look, I'd love to see the software used in these sorts of things go open source as well, but it seems like a bit of a stretch to suggest that it's "unacceptable", when we already accept closed source in plenty of other devices that have life-and-death stakes.
For instance, when was the last time you saw the source code for traffic lights, elevators, trains, or x-ray machines? Any of those could result in life-threatening injuries or death if the software malfunctioned in just the wrong way* (e.g. Therac-25, Schindler elevators, etc.), but most of us have no problem accepting them as part of our everyday lives without having seen the source code, and I'd be willing to wager that the same is true for you as well.
* To be fair, some would require corresponding hardware failures as well before they could kill you, though in many cases, a software failure would greatly increase the odds of a related hardware failure.
...you do realize that's how git works, right? Every dev box is its own repo, so of course he had a repo. That doesn't mean it's mission critical. Quite the opposite, it would suggest it's expendable.
Or perhaps you don't know what mission critical means? It's not just things that are important to your business. It's the things that you can't operate without, like a cloud backend on which your SaaS business operates, or a payment system without which you can't generate any income. Those are mission critical. Expendable repos? Decidedly NOT mission critical.
Setting aside your cluelessness, however, it actually wasn't the repo on his dev box that was the problem. Rather, the credentials for their private github repo happened to be on his dev box, which is how the hacker gained access to it. That repo was the one that contained the source for all of their apps. So, again, it was NOT the one on his dev box that was compromised, though even if had it been, it wouldn't have been out of the ordinary in the least for him to have had it on his dev box, nor would it have made any of that stuff mission critical.
The problem is Handbrake isn't a signed app, period.
Actually, it is signed. While they don't use an Apple Developer certificate, they still do cryptographically sign each release. All of that is in addition to providing SHA1 and SHA256 checksums.
As I said, the user didn't check the signature, and you're quite right that they blew by the warnings about the app being from an unidentified developer, given that those warnings already occur even with the official Handbrake releases. Even so, your claim that they don't sign their releases is entirely incorrect.
Slashdot Mirror
I'm dissatisfied streaming, but that's because in the last two years I've seen my Suddenlink Internet bill (after calling them to negotiate a lower price each year) go up by 66%, from $30/mo. to $50/mo., despite having the exact same 50 Mbps connection with a 250GB/mo. data cap the entire time. It's the lowest tier of service they offer, so there are no cheaper options through them. In my repeated searches for alternatives (cable, DSL, WISP, satellite, whatever), what I've discovered is that their biggest competition currently comes from Frontier DSL...which offers 3 Mbps for $30/mo..
The 3 is not a typo.
Mind you, the area I live in is flat terrain with over 200K people, so we aren't in difficult terrain or miles away from civilization. It's a metropolitan area centrally located between three of the nation's ten largest cities, but the absolute cheapest, most rock-bottom, lowest available broadband service is still $50/month. In 2017. Which is about the same as what I was paying back in 2013 when 50 Mbps was the highest tier they offered and there were no data caps on any plans.
The only change around here during that time was that Verizon DSL was around back in 2013 with a 10 Mbps plan. But Verizon exited the area a few years ago. With the next closest plan being Frontier's 3 Mbps, Suddenlink is apparently free to gouge its customers without fear that we'll leave for someone else. Because where else would we go?
What. The. Hell.
So, yes, I'm dissatisfied. The only thing I was more dissatisfied with was my cable TV bill back before I ended that.
Well, Obama promised more government transparency. These leaks delivered quite a bit of that, though I doubt it was what he had in mind...
Atom only fixes the first problem I listed, so far as I know. If I'm mistaken, feel free to correct me.
Sure, which is why RSS was able to be built using XML. But if you want to fix the problems in RSS, you need something that isn't RSS. They could have implemented their ideas in XML and given it a different name, but if you're already creating a new format, why use XML when the library support in the relevant software stacks makes it far easier to export to JSON in far fewer lines of code?
A) The duplicate issue is a model problem. RSS doesn't require unique identifiers, so clients can't distinguish between outdated entries that have been removed and edited entries that have been replaced. We need to keep the former so the user can read them, but the latter need to be eliminated, lest we have both the original and edited versions in the client. Even if the publisher and the client both follow the RSS spec, it's still left to the clients to implement their own special sauce to recognize duplicates. I probably see this happen once a week with Slashdot's feed alone.
B) Yes, people read old content. I can't count how many times I've started reading a webcomic years after it launched and wished that I was able to go back to the start in the feed, since it'd make it easier to track my position. Allowing pagination enables them to make it possible for people like me to go back through their content as far as we want.
C) While favicons are usually at the root as a matter of convention, the correct way to specify their location is through the use of <link rel="shortcut icon"/> in the head of a page. Because that's not part of the RSS spec, clients are left to themselves to try to find the favicon, either by hoping it's at root or by scraping the site to see if it specifies the location via a link tag. I used to run a very modest site that published an RSS feed, and I can't count how many requests I got for a favicon that didn't exist from RSS clients trying to find it.
Most of what you're saying amounts to, "I haven't had any problems, so there aren't any", whereas I've actually had problems with each of these areas, so I'm looking forward to seeing the possibility of some movement in the space.
You've listed one problem, and were that the only one, you'd be right. But it wasn't. The summary itself obliquely mentions three other problems...
Problem: Duplicate entries frequently appear in feed clients.
Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.
Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.
Given all of those, a new format is not just the obvious solution, it's the only solution, which is why they had to create the new format to address those issues, among many other ones. Once you realize that fact, basing it on JSON or something else simply makes sense, what with it having far simpler and more ubiquitous library support in the software stacks involved, which is in addition to it being simpler to read and write.
I linked to three clients in the summary. Of those, I personally use Feedbin and have been a huge fan of it ever since Google Reader shut down. It's operated as a for-pay service, but the developer open sources all of the code, so if you have your own servers you can run it yourself.
People making mistakes implementing a spec is not in itself a good reason to drop it.
Were that the sole difference, I'd wholly agree, but that's absolutely not the case here, which is why I tried to draw attention in the summary to some of the more substantive differences involved with this particular format. Had they simply ported RSS to JSON, this wouldn't be a story. Instead, they created a new format that is designed to address the issues they've faced in working with RSS and Atom over the last few decades, and in the process of doing so, it also made sense to switch to JSON.
I actually find it rather unfortunate that they named it "JSON Feed" because it obfuscates the fact that the most important changes aren't about the switch to JSON, but are rather about the ways in which they're using it.
It brings me an irrational amount of happiness to see that linked in the very first comment, since I had actually pulled up that strip and considered including it in the summary, but decided against it in the end.
I don't disagree with any of the facts you've said. Where I differ is that I think most of that stuff was more important to Apple than to society, particularly with regards to the influence they were able to exert, hence my leaving it out.
As for changing the music industry, the change to digital was already happening. iTunes and the iPod helped give it a significant push, to be sure, but digital was already established as the successor to CDs at that point, just as CDs had been the successor to cassettes.
That's per year. The average driver goes about fifteen years between crashes, so most of us will be involved in an accident at some point.
Not mentioning the iPod was an intentional omission, actually. While the iPod helped the company take the next step in its recovery from near-bankruptcy, and also demonstrated that they had the ability to move into markets outside of computers, it didn't have a massive cultural impact. Sure, it had an impact, but not on the scale of the other revolutions being discussed.
If they launched something "as successful as" the iPod today, it'd likely be viewed as little more than a blip in their product lineup, much like the Apple TV and Apple Watch, neither of which have managed to break out yet in a big way.
They're only proprietary formats until everyone else adopts them
No, they're still proprietary at that point too. They may no longer be considered "non-standard" if everyone adopts them as standard, but that doesn't make them any less proprietary.
Wow, I really should re-read what I write before clicking submit.
"we've had three biggest revolutions" should have been "we've had three big revolutions".
"It's may be" obviously should have been "It may be".
Ugh.
They may not have one of those moments again, but I think it's too early to say, since those sorts of revolutionary shifts only occur once every decade or two at best.
Thinking back over the last 50 years or so, we've had three biggest revolutions in our everyday approach to technology: PCs, the Internet, and smartphones. Apple was able to ride or contribute to each of those waves, first with the original Mac, then with the iMac (the "i" stood for Internet, as you'll recall), and then with the iPhone. Those sorts of revolutions don't come often. Again, we're talking once every decade or two at best.
But it's been 10 years since the iPhone ushered in the modern age of smartphones, so where's the next thing? It's may be autonomous cars, which Apple is known to be working on, but that technology is still a few years away from prime time. It could be AI assistants. Apple is already lagging behind their competitors in that area, despite being one of the earliest to market with a widely deployed assistant, but it's arguable whether these assistants will eventually become features of other products or revolutionary products unto themselves. It may be AR/VR, which is an area they've said is of great interest to them and in which they've made various acquisitions, but it's still too expensive to become ubiquitous, too nerdy to be culturally acceptable, and a bit like a hammer looking for a nail, so we're still a few years away from AR/VR becoming a revolution, assuming it actually ever happens.
No matter which way you cut it, we're still a few years away from Apple needing to reinvent itself around a new revolution, so I think it's a bit too early to say with certainty that they've missed the boat, though you may well be proven right in a few years if they do in fact miss the boat.
I'll grant that they've come a long way from the rootkit scandal, such as when they responded to the Xbox One's original, draconian policy of tying discs to consoles so friends couldn't loan games to each other with their own, much better policy for sharing games, but that rootkit debacle destroyed a lot of trust.
I consider myself to be one of the more lenient ones around here, in that I'm fine with owning other products of theirs, provided they're sandboxed or disconnected from anything important, but the notion of running a Sony-developed OS that has the ability to tell them everything about my life? Not until I'm convinced their interests align with mine, which is to say, not a chance in hell as long as they are one of the major players in the media industry.
Building on what you said, biometrics are generally safe to use for identification (i.e. I'm referring to X person), not authentication (i.e. I am X person). In much the same way that many of us here are identifiable by unique usernames that everyone else can see, biometrics are merely pieces of information that (mostly) uniquely identify each of us, but we should not assume that they will remain private or secure.
If you're dealing with a secure system, you shouldn't be treating biometrics as anything more than a username.
The entire universe is a game with a strict set of rules. We may not understand them all, but we know they exist and that there's even the possibility that different universes have different rules. If having a strict set of rules within which a thing operates precludes that thing from being considered "intelligent", then apparently humans aren't intelligent either. We're just components in a universe-sized quantum computer implementing algorithms that we don't understand, in much the same way that AlphaGo is implementing algorithms that it doesn't understand.
But that's not a particularly useful way to think about things most of the time, so we've instead accepted that we can refer to any of these sorts of complex algorithms that are capable of competing with human intelligence as "AI". Granted, AlphaGo is limited to the problem space for which it was designed, so it isn't a general purpose AI, but it is nonetheless still an AI.
Suggesting otherwise is just playing games with semantics, usually because you don't like the implications involved with accepting that we now have purpose-built algorithms that can displace the need for human intelligence in specific, complex tasks. Regardless of what you decide to call them, that's an awesome and terrifying fact.
Are you talking about Microsoft Sync? The infotainment system? That's hardly the same as software used to make decisions that have the potential to kill you if they go wrong.
even though they are testing in very controlled conditions, their drivers still need to take control frequently.
You've got your statement backwards: the reason they take control frequently is because they are only testing in controlled conditions.
The world isn't uniformly filled with controlled conditions, so they take control anytime they enter conditions the system isn't yet designed or authorized to operate in (e.g. inclement weather, construction zone, power outage, unmapped shortcut, etc.). Each time they do, the current regulations in California dictate that it counts towards the same statistic that measures the number of times they take control to avoid an accident, even though the latter is vastly different and little more than a rounding error compared to the former. And that's where this reporting about them needing to "take control frequently" is coming from.
Most of these cars (Uber excepted) are already to the point where it's exceedingly uncommon for them to take control to avoid an accident, which is why the companies have been lobbying California to allow them to break the numbers apart (while still reporting both) so that they can provide the public with better granularity and a clearer understanding of their safety record. It's likely California will allow them to do so, since it's clearly in the best interests of the public.
In the meantime, however, naysayers have cited the inflated number without context in order to imply there's a problem, when that really isn't the case at all.
Oh, and regarding regulation, self-driving cars can't operate in states unless they're licensed, meaning that states are more or less opt-in for self-driving cars. In the states that have opted-in, such as California, they mostly do exercise an appropriate level of government oversight. For instance, California kicked Uber's self-driving cars out of the state for operating without a license, require that self-driving cars pass certain safety thresholds (including simulations) before being allowed on the road, and mandate that the companies involved publicly disclose various statistics regarding the safety of their vehicles.
If your state allows self-driving cars but isn't doing that, it's inevitable that some bad actors (e.g. Uber) will abuse that situation to their advantage, but they aren't indicative of the industry as a whole. The appropriate fix is to take the issue up with your state.
Again, however, all of this is separate from the topic of whether or not the market has decided against self-driving cars, which it clearly hasn't.
A) Most humans would fail to meet the bar you just set.
B) Nothing you said relates to the topic I was addressing (whether the market has declared the tech a flop).
C) You're conflating the repeated failures of one particular company for the failures of the industry as a whole.
What I keep hearing from these examples involving Uber is that Uber should not be testing self-driving cars, since they are demonstrating a history of ignoring warning signs and causing dangerous situations, first in California (e.g. the red light running that got them kicked out of the state) and now in Pittsburgh. Meanwhile, Google, Tesla, and a host of other companies have been demonstrating automated driving records that already far exceed the safety expectations of human drivers, though they're being careful with the tests and the conditions under which they conduct them.
Back on point: the full-fledged technology isn't yet ready for the market, which is why it isn't yet on the market, which is why it's plain silly to suggest that it's already flopped in the market, particularly so given the obvious demand for it, should it ever arrive.
Your comment would carry a bit more "oomph" if fully autonomous cars had already hit the market and flopped, but they clearly haven't. Instead, what we have so far are half-implementations and "advanced cruise control", all of which have been headline features driving sales for the handful of cars that have them.
On the plus side, you're continuing the tradition of trolls who have denied the marketability of everything from PCs to the Internet to smartphones in the years immediately prior to their breakout success, despite the writing being on the wall to anyone paying attention.
Look, I'd love to see the software used in these sorts of things go open source as well, but it seems like a bit of a stretch to suggest that it's "unacceptable", when we already accept closed source in plenty of other devices that have life-and-death stakes.
For instance, when was the last time you saw the source code for traffic lights, elevators, trains, or x-ray machines? Any of those could result in life-threatening injuries or death if the software malfunctioned in just the wrong way* (e.g. Therac-25, Schindler elevators, etc.), but most of us have no problem accepting them as part of our everyday lives without having seen the source code, and I'd be willing to wager that the same is true for you as well.
* To be fair, some would require corresponding hardware failures as well before they could kill you, though in many cases, a software failure would greatly increase the odds of a related hardware failure.
...you do realize that's how git works, right? Every dev box is its own repo, so of course he had a repo. That doesn't mean it's mission critical. Quite the opposite, it would suggest it's expendable.
Or perhaps you don't know what mission critical means? It's not just things that are important to your business. It's the things that you can't operate without, like a cloud backend on which your SaaS business operates, or a payment system without which you can't generate any income. Those are mission critical. Expendable repos? Decidedly NOT mission critical.
Setting aside your cluelessness, however, it actually wasn't the repo on his dev box that was the problem. Rather, the credentials for their private github repo happened to be on his dev box, which is how the hacker gained access to it. That repo was the one that contained the source for all of their apps. So, again, it was NOT the one on his dev box that was compromised, though even if had it been, it wouldn't have been out of the ordinary in the least for him to have had it on his dev box, nor would it have made any of that stuff mission critical.
The problem is Handbrake isn't a signed app, period.
Actually, it is signed. While they don't use an Apple Developer certificate, they still do cryptographically sign each release. All of that is in addition to providing SHA1 and SHA256 checksums.
As I said, the user didn't check the signature, and you're quite right that they blew by the warnings about the app being from an unidentified developer, given that those warnings already occur even with the official Handbrake releases. Even so, your claim that they don't sign their releases is entirely incorrect.