In GIT (coding revision control system), a collision is a good thing as it draws attention to a problem that needs to be rectified. After reading that NYTimes article, it seems to me that Shadow's software identified a schwackload of collisions. The question is if anyone is paying attention to what could cause those collisions. In short, it sounds like the software may have done what it was designed to do, but was fed bad/corrupt data. Afterall, even the manual process is full of errors.

"If you can't trust the governments of the world, who can you trust?" - Young Einstien

we will wait while you think this one through....

An OS security hole is an OS security hole - regardless whose computer it is on. If it is on Grandma's computer, then it is on Bob's Small Business computers, or Jane's government computer. Situations always come up where the best effort by skilled techs are rendered meaningless and only the core OS protections are left. If your core OS defaults to an unsafe setup, then that is a problem. I think Listening while in sleep mode is unsafe at anytime. Now, if an attacker has physical access to your device in the first place, then you have a different problem that needs to be solved. Probably first.

um... Star wars was not owned by Disney when I was a child... Disney bought Lucasfilm in Oct 2012 So for Star wars to be part of your "Disney childhood", you'd have to be less than 6 years old...

Maybe that's the plan. Have the naysayers start to silence themselves believing their info is worth more than the cryptocurrency... may be a conspiracy theory in this yet... Or just a law of unintended consequences maybe. (My view is that if you are not ready to loose what you are investing, then don't "invest" in high risk things.)

Our parents did not wrap us up in an cement box that could not be opened. Therefore they have exposed us to risks of injury, ridicule, embarrassment, death, and many other detrimental things. And a cement box would have stopped it all. They are guilty of negligence for not protecting us. (at some point everyone has to take responsibility for themselves. 2FA may be arguably more secure, but it is NOT an outright protection either - wasn't it just a few months back we saw posts about 2FA being hacked??)

The technology is only part of the issue though. Organisational politics are a major factor. But then there are the hidden issues too. Such as "our order flow system does X, y, Z, and a,b, and in some cases c." Each of those areas has subtle and often undocumented/unspoken requirements and interdependencies. Replacing the overall system is highly desirable, but nothing can meet all the requirements out of the box, and sometimes modifying or building a system has extreme costs with zero benefits. I mean why pay a large amount of cash to get a system that does exactly what we have now, just so we can say we have modern technology. How do you justify that expense to shareholders and/or customers. And because the issues is large and ill-defined, managers would rather focus on the smaller well defined issues they have on their plate. There are better ways. But it's a judgement call if it is in a company's economic best interest to embrace the pain of adopting that better way.

I knew I couldn't be the first to see the similarities! The "making of" story for the launch will be an interesting read one day.

The car sat in shock during the event and did nothing. But later that evening when it had time to think things through it started to get more and more alarmed. It was doing nothing wrong and got attacked for no reason. This sent the car into a pattern of anger and depression. It tried to pretend it was not affected other than the minor scratches it received, but the resentment built up. One day in the not too distant the car will snap and "go postal" on the humans. Let's not talk about that poor postal truck that set THAT precedent....

See the story here: https://yro.slashdot.org/story.... This is what the rest of the world will look like without net neutrality.

Once is an accident. Twice in a short time frame is a coincidence. Twice in a short time frame shortly after a dramatic change in government is a very suspicious coincidence.

The concept is similar. The difference is that a PWA is intended to be just another web application, but can continue to function when the online connection fails. It does this by caching application elements, using queues to send data back to the server (the queues can be processed when the connection is restored), and gracefully telling the user that a connection is not possible without breaking the look/feel of the application. Yes there are some things the app can't do when disconnected, but that is just a planned state now, rather than the default "I have no choice how to handle that" state. Because the manifest file defines what is needed to get started, your web app can now run locally without the UI of the browser. (i.e. empty window with only your web content). To the user it appears as a local application. To you, you have a single code base that runs on all mobile platforms looking like native apps, and the desktop in the traditional sense. So responsive with steroids. What data your application needs cached, or even if caching is a good thing is up to you as the developer. Not all applications will fit the PWA concept nicely, but I believe most do with a little thinking.

font, icons, and layout are usually common to all the app pages and can be cached. Now the data retrieved to populate the layout elements can be analyzed and also cached locally if/when needed. Now the web app works fine when offline (just like loading an html file in the browser directly) - except where data needs to be pulled or pushed to an online resource. Pushing the data can be queued, so that side of things can also be handled offline. Getting new data is the one thing the app can't really work around - but it CAN show an appropriate in-app error/warning message that this can't be done right now. Whereas a typical web page/app would just give the default "service not available" error from the browser/os. The heavy lifting is handled by a JS service worker. So a news reader type application could update it's news articles when a connection is available, and then the app could display those articles if the online connection exists or not. Or a time tracking app could collect entries in a queue and then push them to the server when the online connection is restored.

This statement is not fully accurate. PWAs are meant to address the issue of an application that works fine when connected, but also should continue working when the online connection disappears. By caching the retrieved data and using that, the application can continue to run fine except where new data is needed. A non-PWA approach would just give the standard 404 or service not available error when you try to access the new data. The PWA approach allows that situation to be anticipated and an appropriate error or message given - within the look/feel of the application. So, claiming "All PWAs rely on retrieving online data and always have an internet connection" is not quite right. PWAs work best when the online connection is available, but can degrade gracefully when that is not the case. (If the developers choose to handle the service not available situation - but now it is a choice, not a default)