Start by the law and a proper registration system that requires gun owners to be licensed, effectively background checked, required register every fire arm they own and which is tied into crime and mental health databases so they can be flagged when necessary.
Firefox implements PDF.js. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.
Chrome uses plugin called PDFium. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.
Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.
Many Chromebook applications are front ends to cloud based services. If Google decides to end of life one of those services then you're screwed. And this has happened before such as when YouTube end-of-lifed an older client API. So yeah your chromebook might work for a while and then gradually bitrot and break as one service after another is withdrawn.
Aside from the cloud services, chances are the browser will be start breaking over time too. Sites that expect chrome won't be happy about some 2 or 3 year old version and will start throwing up errors to upgrade and so on. Except of course you can't upgrade.
I already have. If it's hard to understand, consider that an aircraft's black box. It tells you a plane lost altitude and crashed. It doesn't say that it happened because the pilot collapsed, or someone hit him on the head and threw the switches or the cabin was filled with smoke. Therefore aircraft have cockpit voice recorders and there is an increasing call for them to have cabin cameras. A second channel of information that can be correlated to the first but isn't captured in the same way.
*sigh* I'm not talking about single or multiple sensors. I am talking about independent channels where the cause and effect can be independently verified. Why is this so hard to understand?
If you don't want case sensitivity then don't create passwords with mixed case. The purpose of course for mixed case is to increase the key strength for any given length of password.
I didn't say anything about the number of sensors but the number of channels. And given the scant info from Tesla it's reasonable to argue from the position that they don't have a second channel. If you think otherwise, then you can provide a link showing what this second channel might be.
I'd be inclined to agree with you but for one thing... A few years ago Tesla let BBC Top Gear test a Roadster, and Jeremy Clarkson lampooned the vehicle in a way that annoyed Elon Musk. Ever since then Tesla have put a *lot* of data capture capability and performance monitoring into all of their vehicles, specifically to stop these sorts of claims.
I have a broken console controller that insists I'm pushing on the left stick when I'm not at all. If the console were logging this info then it might claim I initiated this action. Anyone watching me could see that I wasn't.
The same could hold true for a car's accelerator. It is necessary for the logs to have separate channels that correlate user actions to backend commands. e.g. a camera filming the pedal actions is a separate channel, as are resistive pressure pads inside the rubber of the pedals themselves. These channels could be logged with the command and demonstrate a simple cause and effect - user put their foot down (as seen from side channel) and the car sent a command to accelerate. It's an unambiguous way to see what the hell happened.
But if all they're logging is the backend command then it is far harder to prove. I suppose they could construct a graph showing acceleration % rising and falling over time. That might strongly indicate a human or a computer fault - e.g. if it went from 30 to 100% instantaneously, or relatively smoothly as a human might do. But it wouldn't be as unambiguous as a separate channel.
Depends what Tesla thinks by the term and what some driver might think if their car suddenly developed a mind of its own and started uncontrolled acceleration. I might call it autopilot too (in a Death Proof kind of way) if it happened to me. Not saying that's what happened but its certainly possible.
Firefox demonstrates why going 64-bit is not always as trivial some people suppose. NPAPI plugins on Windows are 32-bit DLLs. You can't load 32-bit DLLs into a 64-bit application so you either dump support for that feature or somehow shim your product so they still work. In Firefox's case they chose to deprecate NPAPI. But that isn't the end of their issues since even with a 64-bit Firefox for Windows they still have to produce a 32-bit Firefox with NPAPIs enabled. So now they've got two products to build, test and support instead of one and some edge cases like how does somebody upgrade / migrate from one version to the other.
I expect Visual Studio's problems are 10x as bad. There are thousands of extensions for VS, many of which are commercial, many of which are tied to other substantial products. If VS went 64-bit then chances are that many of these would break. That's one example problem that VS would have to figure out. I'm sure there are many others unrelated to just flipping some compile flags.
Python 3 isn't that different 2 at all. It certainly cleans up some quirks and makes the language more unicode friendly but it's still Python. Running a script can fix or highlight the majority of issues, most of which are trivial to fix or identify. And lots of software packages run on either 3 or 2 and there compatibility libraries too.
But the reality is ALL Python libraries should be on 3 now and Python 2 should have been mothballed. I can understand how when 3.0 first appeared it might have made sense to run both codebases side by side until it stabilised. But 3.x has been stable and production ready for at least the last 5 years and 2.x should have been mothballed all the way back then - no backports, no bug fixes, no support. But it wasn't. And so the Python community wastes its time split between two codebases with the consequent confusion, uncertainty, complexity, bugs and mixed messages to the outside world that it sends out.
The fact you call 2.x viable speaks for that. 3.x is viable and preferable but 2.x hangs around Python's neck like a millstone. The way the Python community conducted this transition (or didn't) should serve as a warning to other language maintainers - get the transition over with and get it over with as fast as possible or watch your language wallow.
The primary one is that Rust and Swift serve different purposes. Swift is an application programming language primarily for mobile apps and Rust is a systems programming language primarily for services, IoT, drones and so on. Swift sacrifices performance for convenience. Rust sacrifices convenience for performance. They could be used in each other's place but not without bringing baggage with them. A simple example of that Rust tracks and enforces most lifetimes at compile time - it knows when you're not using an object any more and inserts code to delete it. But it will kick your ass if you don't do things exactly how it likes. Swift uses automatic reference counting which means object an additional runtime cost but it's more forgiving and easier to work with. On a more practical level Rust runs and works on Windows, Linux and Mac and has a burgeoning number of libraries and projects whereas Swift is mostly Mac with some token cross platform thrown out there but not much else yet.
Secondly, for C++, I don't see that it can ever fix the basic problem that it is dangerous by default. It's easy to corrupt or leak memory. It could grow directives or classes which define lifetimes or ownership information but it doesn't solve the problem of bad / dangerous code that already exists or new code that ignores these directives. That isn't to say C++ is going away soon but someone writing something that needs to be safety critical, or scalable, or reliable might think twice about using it.
Lots of people quite evidently and while some presidents have exhibited some pattern of mental illness (usually related to depression, alcoholism, bipolar etc.) most of them don't. And certainly not narcissism, sociopathy or psychopathy. Trump must be the first mainstream candidate in recent times who quite obviously suffers from a mental illness.
I'm sure the Debian package could have handled things better such as warning the user or asking them for the behaviour to adopt. But I'm sure it's not the first time a package has locked itself down or changed a default in a way that improves stability / security / performance or whatever and has required some workaround to deal with. I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.
This hypothetical admin of yours should be competent enough to type "loginctl enable-linger someuser" if there is a reason they need long running services knocking around on the box. Or just disable the conf setting which was set to kill services in the first place.
I expect most admins would prefer the default behaviour to be to clear up left over processes and services when the user's last session disappears.
I'm not sure that would be hard - something that expounds some ill defined technological singularity occurring a few decades hence over and over would do the trick.
Any rider that is unrelated to the title or purpose of a bill should be automatically struck out. Maybe someone should slip this law in as a rider to another bill in order to make the point.
Slashdot Mirror
Or watch as this happens over and over again.
The Chrome PDF viewer is C++. But PDF viewers in browsers work best with web optimized PDFs.
Firefox implements PDF.js. PDF is rendered with HTML and Javascript. The Javascript draws into a canvas element. Here is an online demo of it that works in most browsers. There is one callback to the browser for printing functionality. The main downside to Firefox's PDF viewer is its a little slow and when you print a PDF you're basically just printing a bitmap so the quality can be poor.
Chrome uses plugin called PDFium. This is a C++ based plugin that takes care of rendering the PDF and its output. It's faster and produces better prints but it's also an attack surface in its own right. The exploit in this case was in a 3rd party dependency openjpeg which could be exploited.
Personally I think the JS approach is the way to go, although it would be nice if it would refine how it renders the canvas DPI / backing store so the quality was better. And I believe browsers are better off with a PDF viewer. External viewers are a source of far more exploits than one that is built-in, especially since Chrome / Firefox can force updates for critical issues. But it can still be turned off if someone is paranoid or prefers to use an external viewer.
Many Chromebook applications are front ends to cloud based services. If Google decides to end of life one of those services then you're screwed. And this has happened before such as when YouTube end-of-lifed an older client API. So yeah your chromebook might work for a while and then gradually bitrot and break as one service after another is withdrawn.
Aside from the cloud services, chances are the browser will be start breaking over time too. Sites that expect chrome won't be happy about some 2 or 3 year old version and will start throwing up errors to upgrade and so on. Except of course you can't upgrade.
I already have. If it's hard to understand, consider that an aircraft's black box. It tells you a plane lost altitude and crashed. It doesn't say that it happened because the pilot collapsed, or someone hit him on the head and threw the switches or the cabin was filled with smoke. Therefore aircraft have cockpit voice recorders and there is an increasing call for them to have cabin cameras. A second channel of information that can be correlated to the first but isn't captured in the same way.
*sigh* I'm not talking about single or multiple sensors. I am talking about independent channels where the cause and effect can be independently verified. Why is this so hard to understand?
If you don't want case sensitivity then don't create passwords with mixed case. The purpose of course for mixed case is to increase the key strength for any given length of password.
I didn't say anything about the number of sensors but the number of channels. And given the scant info from Tesla it's reasonable to argue from the position that they don't have a second channel. If you think otherwise, then you can provide a link showing what this second channel might be.
I'd be inclined to agree with you but for one thing... A few years ago Tesla let BBC Top Gear test a Roadster, and Jeremy Clarkson lampooned the vehicle in a way that annoyed Elon Musk. Ever since then Tesla have put a *lot* of data capture capability and performance monitoring into all of their vehicles, specifically to stop these sorts of claims.
I have a broken console controller that insists I'm pushing on the left stick when I'm not at all. If the console were logging this info then it might claim I initiated this action. Anyone watching me could see that I wasn't.
The same could hold true for a car's accelerator. It is necessary for the logs to have separate channels that correlate user actions to backend commands. e.g. a camera filming the pedal actions is a separate channel, as are resistive pressure pads inside the rubber of the pedals themselves. These channels could be logged with the command and demonstrate a simple cause and effect - user put their foot down (as seen from side channel) and the car sent a command to accelerate. It's an unambiguous way to see what the hell happened.
But if all they're logging is the backend command then it is far harder to prove. I suppose they could construct a graph showing acceleration % rising and falling over time. That might strongly indicate a human or a computer fault - e.g. if it went from 30 to 100% instantaneously, or relatively smoothly as a human might do. But it wouldn't be as unambiguous as a separate channel.
Depends what Tesla thinks by the term and what some driver might think if their car suddenly developed a mind of its own and started uncontrolled acceleration. I might call it autopilot too (in a Death Proof kind of way) if it happened to me. Not saying that's what happened but its certainly possible.
I expect Visual Studio's problems are 10x as bad. There are thousands of extensions for VS, many of which are commercial, many of which are tied to other substantial products. If VS went 64-bit then chances are that many of these would break. That's one example problem that VS would have to figure out. I'm sure there are many others unrelated to just flipping some compile flags.
Explain please.
But the reality is ALL Python libraries should be on 3 now and Python 2 should have been mothballed. I can understand how when 3.0 first appeared it might have made sense to run both codebases side by side until it stabilised. But 3.x has been stable and production ready for at least the last 5 years and 2.x should have been mothballed all the way back then - no backports, no bug fixes, no support. But it wasn't. And so the Python community wastes its time split between two codebases with the consequent confusion, uncertainty, complexity, bugs and mixed messages to the outside world that it sends out.
The fact you call 2.x viable speaks for that. 3.x is viable and preferable but 2.x hangs around Python's neck like a millstone. The way the Python community conducted this transition (or didn't) should serve as a warning to other language maintainers - get the transition over with and get it over with as fast as possible or watch your language wallow.
The primary one is that Rust and Swift serve different purposes. Swift is an application programming language primarily for mobile apps and Rust is a systems programming language primarily for services, IoT, drones and so on. Swift sacrifices performance for convenience. Rust sacrifices convenience for performance. They could be used in each other's place but not without bringing baggage with them. A simple example of that Rust tracks and enforces most lifetimes at compile time - it knows when you're not using an object any more and inserts code to delete it. But it will kick your ass if you don't do things exactly how it likes. Swift uses automatic reference counting which means object an additional runtime cost but it's more forgiving and easier to work with. On a more practical level Rust runs and works on Windows, Linux and Mac and has a burgeoning number of libraries and projects whereas Swift is mostly Mac with some token cross platform thrown out there but not much else yet.
Secondly, for C++, I don't see that it can ever fix the basic problem that it is dangerous by default. It's easy to corrupt or leak memory. It could grow directives or classes which define lifetimes or ownership information but it doesn't solve the problem of bad / dangerous code that already exists or new code that ignores these directives. That isn't to say C++ is going away soon but someone writing something that needs to be safety critical, or scalable, or reliable might think twice about using it.
Commodore's IoT offering is bound to be superior.
It isn't a major use case. Please explain to me why it's so common that it should be the default behaviour.
Thanks but I do. It is reasonable to clean up a user's mess when they log out unless there is an explicit reason not to.
Lots of people quite evidently and while some presidents have exhibited some pattern of mental illness (usually related to depression, alcoholism, bipolar etc.) most of them don't. And certainly not narcissism, sociopathy or psychopathy. Trump must be the first mainstream candidate in recent times who quite obviously suffers from a mental illness.
It's 130+ acres.
I'm sure the Debian package could have handled things better such as warning the user or asking them for the behaviour to adopt. But I'm sure it's not the first time a package has locked itself down or changed a default in a way that improves stability / security / performance or whatever and has required some workaround to deal with. I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.
Lost is the reality of a batshit crazy nut job 'running' for president.
Well there's already one batshit crazy nut job running for president. McAfee should have campaigned from the drug fueled maniac platform.
I expect most admins would prefer the default behaviour to be to clear up left over processes and services when the user's last session disappears.
I'm not sure that would be hard - something that expounds some ill defined technological singularity occurring a few decades hence over and over would do the trick.
It's funny how fast chatbots develop National Socialist ideals when they're exposed to the internet.
Any rider that is unrelated to the title or purpose of a bill should be automatically struck out. Maybe someone should slip this law in as a rider to another bill in order to make the point.