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.
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....
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)
I've looked into PWAs some, but am no expert (yet). From what I see, they have very little to do with Google per se. Your web app declares a service worker. That worker retrieves some pre-cached data to "install" the app (stuff like icons, fonts, etc.). Then as you use your app you can have the service worker cache the retrieved data locally for offline use. Nowhere in that process have I seen "Thou shalt use Google's version of PWAs". It just so happens that the best documentation for PWAs comes from Google postings and Google is trying to control the flow. If I build my app to use a third party resource that can be turned off, that's a bad choice by me, IMO. But adopting the PWA structure does not tightly tie me to any particular vendor. It is a Javascript technique for structuring an app - much like using CSS for styling instead of putting your color/font/positioning markup directly in the HTML. At least that's my take on it thus far.
Give me an image file, and I can generate an SHA hash for it that is relatively unique. Then I can delete the file. I can then compare other hashes for other pictures without having the original picture, or even being able to recreate the picture. But now that begs the question, why can't I just provide the hash generated from a client side app without passing the actual image? As a dev, my spidey sense is tingling - they want the pictures for something other than just the stated reason.
The write up states that the system scans the internet to find feeds. So the content producers go after the people who might scan for those feeds? Why not go after the people who are providing the feeds in the first place? Stop the signal at the source, not at the receivers... But that would mean the music industry must sue themselves because they have been caught seeding content to collect infos on the pirates... What an odd world we have created...:)
It's not that cut and dry. The downloading in this sense has not had a great case through the courts yet. So the legality is still a little murky around downloading. And it would make sense to me that if you are knowingly downloading content that is not legally available via other means - or even released yet, then you know you are breaking the law and shouldn't benefit from that gray area. However if you are downloading that show that aired on cable (that you pay for) that you missed because you were at work, then you are likely just time-shifting and would probably be fine by Canadian law. But don't take my advice - I'm not a lawyer either.
I haven't gone to look it up, but that number sounds kinda familiar... wasn't that the amount (or close to it) Apple won from Samsung for infringing the rounded corners patent?
I've been around for a number of years in the dev trade. I've seen good and bad projects. When project management is done well it makes a world of difference. Everyone knows what needs to be done without needing three meetings a week just to figure out who is working on what. The deliverables get clearly defined, and change management is enshrined and accounted for. Working in this environment is awesome. Now, do project management badly and your project WILL be over budget and over schedule. Nobody will be happy and it will be a crap job. Nobody will be especially clear what the deliverables are because change management is not accounted for and you have moving targets. The team spends more time finding who to blame than just fixing the problem. My opinion - if you are using the wrong tools, you'll have wrong project management. (i.e. Asana is a task tracker, not an asset manager, resource planner, time log, or credential manager... Task tracking is only part of the equation).
If you are talking about the headline news you might expect to see on your local TV News station, then I fully agree with most of your sentiments. BUT, if you are trying to stay abreast of the trends in a particular area, learn new things that are of interest to you but not necessarily to the news channels, or just curious about how the world is changing around you, then having an aggregated news feed of all your interests at your your fingertips is handy. Side question, if you have such a view, why are you commenting on Slashdot - News For Nerds. lol (And did you see this article pop up in your RSS feed reader??)
I picked up Nexus 6Ps for my wife and myself a year and a half ago with Android 6 on it. I kinda expected the upgrade to Android 7 (which was released within a few months of the phone). I was surprised to learn the phones are eligible for Android Oreo. While it is not a sub $400 phone, it is not "new", but is still receiving updates. I bought the Google favoured phones specifically because I got burned in the past buying a Cell Service Provider feature phone and never getting ANY updates to it. That phone was more than $400 as well and was effectively stagnant by the time I got it home. So a little patience and (cash) leads to a longer serving phone than if I had bought the flavor of the month instead. Needless to say I've updated my phone to Oreo. I'm liking the improved power management thus far, but it still has only been one full day....
perhaps the other vessels involved were the alleged hacking targets, with the intention of causing grief for a US military vessel... I find it easier to believe a commercial vessel would be easier to hack than a warship...
Slashdot Mirror
"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)
I've looked into PWAs some, but am no expert (yet). From what I see, they have very little to do with Google per se. Your web app declares a service worker. That worker retrieves some pre-cached data to "install" the app (stuff like icons, fonts, etc.). Then as you use your app you can have the service worker cache the retrieved data locally for offline use. Nowhere in that process have I seen "Thou shalt use Google's version of PWAs". It just so happens that the best documentation for PWAs comes from Google postings and Google is trying to control the flow. If I build my app to use a third party resource that can be turned off, that's a bad choice by me, IMO. But adopting the PWA structure does not tightly tie me to any particular vendor. It is a Javascript technique for structuring an app - much like using CSS for styling instead of putting your color/font/positioning markup directly in the HTML. At least that's my take on it thus far.
Give me an image file, and I can generate an SHA hash for it that is relatively unique. Then I can delete the file. I can then compare other hashes for other pictures without having the original picture, or even being able to recreate the picture. But now that begs the question, why can't I just provide the hash generated from a client side app without passing the actual image? As a dev, my spidey sense is tingling - they want the pictures for something other than just the stated reason.
The write up states that the system scans the internet to find feeds. So the content producers go after the people who might scan for those feeds? Why not go after the people who are providing the feeds in the first place? Stop the signal at the source, not at the receivers... But that would mean the music industry must sue themselves because they have been caught seeding content to collect infos on the pirates... What an odd world we have created... :)
It's not that cut and dry. The downloading in this sense has not had a great case through the courts yet. So the legality is still a little murky around downloading. And it would make sense to me that if you are knowingly downloading content that is not legally available via other means - or even released yet, then you know you are breaking the law and shouldn't benefit from that gray area. However if you are downloading that show that aired on cable (that you pay for) that you missed because you were at work, then you are likely just time-shifting and would probably be fine by Canadian law. But don't take my advice - I'm not a lawyer either.
I haven't gone to look it up, but that number sounds kinda familiar... wasn't that the amount (or close to it) Apple won from Samsung for infringing the rounded corners patent?
I've been around for a number of years in the dev trade. I've seen good and bad projects. When project management is done well it makes a world of difference. Everyone knows what needs to be done without needing three meetings a week just to figure out who is working on what. The deliverables get clearly defined, and change management is enshrined and accounted for. Working in this environment is awesome. Now, do project management badly and your project WILL be over budget and over schedule. Nobody will be happy and it will be a crap job. Nobody will be especially clear what the deliverables are because change management is not accounted for and you have moving targets. The team spends more time finding who to blame than just fixing the problem. My opinion - if you are using the wrong tools, you'll have wrong project management. (i.e. Asana is a task tracker, not an asset manager, resource planner, time log, or credential manager... Task tracking is only part of the equation).
If you are talking about the headline news you might expect to see on your local TV News station, then I fully agree with most of your sentiments. BUT, if you are trying to stay abreast of the trends in a particular area, learn new things that are of interest to you but not necessarily to the news channels, or just curious about how the world is changing around you, then having an aggregated news feed of all your interests at your your fingertips is handy. Side question, if you have such a view, why are you commenting on Slashdot - News For Nerds. lol (And did you see this article pop up in your RSS feed reader??)
Maybe go back to school? What you are describing is called a "quota", not a commission. Quota's are Standard Operating Procedures for sales positions.
I picked up Nexus 6Ps for my wife and myself a year and a half ago with Android 6 on it. I kinda expected the upgrade to Android 7 (which was released within a few months of the phone). I was surprised to learn the phones are eligible for Android Oreo. While it is not a sub $400 phone, it is not "new", but is still receiving updates. I bought the Google favoured phones specifically because I got burned in the past buying a Cell Service Provider feature phone and never getting ANY updates to it. That phone was more than $400 as well and was effectively stagnant by the time I got it home. So a little patience and (cash) leads to a longer serving phone than if I had bought the flavor of the month instead. Needless to say I've updated my phone to Oreo. I'm liking the improved power management thus far, but it still has only been one full day....
perhaps the other vessels involved were the alleged hacking targets, with the intention of causing grief for a US military vessel... I find it easier to believe a commercial vessel would be easier to hack than a warship...
It must be. That one was decent for the time. Overplayed on cable these days though...The death knell of any good movie.