So it's really baffling to me why Cannonical is reinventing the wheel here
I think the main reason is by owning the display tech they can shut their competition out of the mobile / tablet space. Mir is dual licenced - proprietary or GPLv3. They can do what they like under their proprietary licence while hamstringing their competition with the onerous requirements of the GPLv3 (e.g. not being able to link proprietary drivers, limits on DRM). It's probably why Intel walked away from the project.
The Ubuntu wiki is tries to provide technical reasons but it's all pretty vague - it alludes to issues like lack of support for 3d input devices and a few other problems with the protocol but these don't sound very convincing arguments to write everything from scratch.
It's not steel, it's aluminium. There are also hypotheses that the impact didn't need to pierce the metal but could have caused the battery to arc and catch fire.
Either way it serves as an example of a repair which would be very difficult / expensive to rectify. Hence why they might push a software hack to jack the suspension up a bit.
I agree too, but at the same time there is a very useful saying - never buy version 1.0 of anything. And that applies especially to motor vehicles regardless of their mode of propulsion. They usually suffer recalls and that's just for the critical / safety related problems that the loss adjusters say can't wait. There must be a raft of lesser but still serious issues which either cannot be fixed or only get fixed if you bring the car in for a service. Raising the suspension in vehicles sounds like a kludge for an issue which cannot be fixed in any other way short of strengthening the underside of the car.
A vastly better idea would be to allow these search terms through, monitor which images / sites were subsequently clicked on and then provide this information allow with IP logs to the relevant law enforcement agencies. In other words, let these freaks hang themselves with their own rope. The most likely consequence of banning these terms is that child porn will be driven underground, into Tor servers and so forth where it is far more difficult to monitor.
". I KNOW natural food to be safe, you merely BELIEVE synthetic food is on someone elses say-so. "
That's an utterly absurd assertion. There are voluminous examples of "natural" vegetable and meat products which have caused outbreaks. e.g. Europe suffered a mass e.coli outbreak from cucumbers of all things that was estimated to have killed 53 people and sickened thousands more. Just one example of many.
There is nothing inherently unsafe about synthetic products because it is a completely meaningless blanket term. For example, most preservatives are "synthetic" (produced by biochemical or strictly chemical processes) but they are put into foods to inhibit microbes which themselves can be extremely harmful.
But you seem to believe that synthetic means carcinogenic and there is some conspiracy by corrupt scientists to push this stuff into foods. It's absurd.
I expect if you're not too fussy about appearances that you need very little more than a shotgun cartridge, a metal tube snug enough to hold it, a pin, a rubber band and lots and lots of masking tape.
Personally I think the hysteria over 3D gun printing (and the attendant hype by those who think it is a wonderful thing) is totally overblown. Anyone fashioning home made guns, be they from masking tape or plastic deserves everything they get. If the gun blows up in their faces, or ends up being used against them then it serves them right.
Sorry but your response is not very rational. Foods should be regarded on their individual merits whether they are natural, processed, or "synthetic" (which usually just means processed).
It is incredibly easy for someone to eat a bad oyster or be poisoned by a misidentified berry / mushroom or get a dose of ecoli / salmonella / botulin and suffer a serious, potentially fatal reaction. Implying that "natural" foods are in some way safer belies the reality that they aren't. In some ways they are far less safe because the quality from one batch to the next could be all over the shop.
And allergies are not some modern phenomena either. Diagnostic tests are better. It's just in the good old days some kid who was coeliac (for example) would simply fail to thrive and be lumped in with other causes of high infant mortality.
Why should "synthetic garbage" be any more detrimental to someone's health than organic or natural items? There are plenty of plants which in their wild variety, or in unprocessed or uncooked form can make people horribly sick.
An ActiveX control is fundamentally no difference from a Netscape plugin. They are both native DLLs running with the full privilege and power of the process they are hosted by. Plugins could even be scripted like ActiveX controls through LiveConnect and later through XPConnect.
The reason ActiveX got the heat was that authors were meant to self-declared controls as safe for scripting, and IE honoured that declaration. If I had installed BadlyWritenControl then any website could instantiate it and exploit it. Scripting a control was easy too thanks to OLE automation and IDispatch interface. Worse, even if I didn't have BadlyWrittenControl installed, the website could still reference the CAB file that contained it and IE would facilitate the automatic download and installation of it.
Conversely installing a plugin was a pain in the ass. Even if a page said it needed a plugin and provided the url to it, the user still had to manually go off and install it. Therefore by default plugins had a level of safety which IE did not have. And it was also a pain for developers to write a scripting API for a plugin, so many plugins didn't bother or offered only minimal scripting. I don't think this was intentional security, just the general craptitude of LiveConnect provided better security as a side effect.
Anyway, I don't see PNaCl as being unsafe per se but it should be something that is disabled by default, and even when it is enabled, users should be alerted and given the option of blocking execution of apps on a per site basis.
I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js
NaCl stands for native client. i.e. you download software compiled for x86 or ARM instructions and run it in your browser at native speeds. It is sandboxed and limited to what it can do within its sandbox. But having to recompile the same code for each architecture is obviously a pain, so PNaCl allows devs to compile once to LLVM and run anywhere.
Asm.js is an important thing to pursue but it fundamentally a hack. Tools like Emscripten compiled code to LLVM (like PNaCl), and then emit equivalent JS. Then that has to be loaded, parsed, recompiled again and run over a JS engine with the performance and memory overhead that this implies. I would rather than browsers adopt a LLVM based runtime framework like PNaCl so few of the overheads of using JS are necessary.
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
That could be said of most cross-platform toolkits and its hardly surprising. C/C++ traditionally hasn't bothered to make the distinction between an immutable and mutable string, nor provide hints as to who owned the string (implementation or caller), or of making efficient use of memory, or of providing utils to convert or manipulate character sets or encodings. So the toolkits typically encapsulated strings in classes to provide these things.
And even though the standard C++ library has a std::string class, I expect toolkits have enough reasons to stick with their own classes. And that's just strings. I expect there is a similar story for things like threads (and various thread patterns like thread pools), collections, semaphores, mutexes, file handles, sockets, etc.
Nothing has happened except for the mass evacuation of 300,000 people, the > 1000 deaths which have been attributed to this evacuation, the 30km exclusion zone around the plant, the loss to industry caused by power shortages, the financial turmoil, the trashed reactors that must be made safe, the headache of decontaminating and decommissioning the entire site and the trillion yen bill at the end.
I don't think there is serious debate that nuclear is a very important source of power, one that can not be discounted. But it would be wise for any strategy to make use of renewables whenever humanly possible. Perhaps Japan is now sufficiently motivated to show other countries how it can be done.
Knifing tyres is criminal damage. Throwing a coke bottle on the line is littering. It's easier to get away with. It's also easier to retreat to a safe distance and watch as a stupid system fails to safe over a coke bottle (or a strategically placed wrapper) and backs up all the way down the system. If the designers of this system don't don't anticipate this they don't understand human nature.
Given how the process works I would say it took hours if not days to print out, and many more hours of finishing, removing supporting bits, polishing etc.. However it would be interesting to see a time lapse of the main frame being printed or something.
I wonder how long it will take for the locals to devise ways of griefing these pods - forcing them to stop dead if they detect a plastic bottle in their way, slapping a burger wrapper over the sensors or something similar. I could see the entire system failing right there. It's a problem that self driving cars would face assuming they ever moved beyond a pipe dream.
The point I'm making is there should be no need for a CA.
I can roll a PGP key myself and it works of whether I have zero signatures, or multiple signatures. It's up to the recipient to determine if they trust me based on my signatures. The more signatures I have, the harder it is to fake or do a man in the middle, but even zero signatures means protection from casual eavesdropping.
That's how it should be for web certs. Roll your own. At a bare minimum you get encrypted communication. If someone wants more they can get their partner sites to sign their key. If they want more again, then then can pay for a CA and jump through the hoops it expects for this service.
But a CA signed cert should not be necessary just to get crypto in a browser. It should also be abundantly clear from recent events how illusory this security is. If someone has a compliant root CA they can do a man in the middle attack. It's far more difficult to do if the cert is signed by multiple signatories (since each would have to be compromised) and if the browser is capable of comparing the cert between sessions and alerting the user to major differences.
I don't give a damn that you someone jump through hoops to get a cert for free or even a fee. Why the fuck should I have to ask somebody else for a cert at all?
It's a tax on security. I should be able to roll my own cert and at least benefit from crypto. If the nature of my business demands I sign the key I should be able to decide if I want to pay a notary / CA for a signature, or just get all my business contacts to sign it for me.
What I shouldn't have to do is what the current model requires. It's onerous, and it means insecurity by default.
It's always possible they intend to stick it in later (I doubt DLNA support was a launch day priority), but it would definitely put me off preordering if I had. But then again, a good reason not to preorder in the first place is because of things like this.
If it's a good console then it will still be a good console in 6 months from now when there are some actual worthwhile games to play on it and the firmware has gone through a few feature enhancements. It took several major updates of the PS3 firmware for some things to appear that we take for granted. Including DLNA.
It's too bad http doesn't dump CAs as well, or rather the rigid model that is adopted now. It's basically a tax on security and clearly many sites choose to have no encryption at all rather than pay this tax. So any site should be able to present an unsigned key to a browser and and instantly benefit from encryption. The browser shouldn't object to this either (unless the site used to present a signed cert) since it is still better than plain text even if it permits man in the middle attacks.
And if a site wants something more then they should be able to have their key signed by their buddies, business partners, trade associations, governments, and yes even CAs to build a web of trust. So a bank might well pay a CA for a signature, but it might also get a signature from its banking federation, it's rival / partner banks, the government, and a business bureau. If the cert suddenly changes, or if any of the signatures mysteriously change then the browser has the knowledge necessary to warn a user. That makes it far harder to compromise the security. It also means that no site has to pay a CA for the privilege of security. It might be advantageous to do it for a bank or suchlike, but smaller operations would build out a more organic trust model.
How a browser presents this information falls outside of this. I don't see it being especially different from how browsers present this information now except it would be more important to users to know when the information changes, rather than when it doesn't.
The exit() method doesn't dump a core and that might be why that code is there, to debug a situation which should not happen post mortem. Apps need a signal which causes a core dump, e.g. a segmentation fault with an illegal memory access (SIGSEGV), or divide by zero (SIGFPE) or something timilar. An easy way to do that is perform an illegal action in the code.
And it's no good pretending "devs shouldn't do that". Maybe they shouldn't, at least not in production code, but it's quite possible they might and that is what a tool might pick up. There are also far more subtle things that are not intentional but are still optimized away. There are links on this page which describe some of them, such as null pointer checks in the kernel which are optimized away simply due to the order some of the tests are made in.
1. This is meaningless since it will be separate device
2. It is a bullet that is put in a hand gun. It will be a separate device which could be mounted on the pursuing cop car.
3. $500 is chicken feed compared to the damage, potential loss of life, insurance liability etc. of a high speed pursuit. Cops don't have to maintain constant visual contact to see where the vehicle is going. Consequently they can drop back, lessen the tension of the pursuit, plan to intercept the vehicle with stingers etc and bring the thing to a safer and faster conclusion.
4. It'll go to those departments which see merit in carrying it. Presumably the FBI have far more covert means of tracking the car than chasing after it and firing something at it which splats on the back of the car.
Maybe a developer has added logic like this - "if (someBadCondition) int x = 1 / 0;" to force an exception or fault to be thrown. Maybe on their compiler it causes the code to die (and dump core) makes it easier to figure out what went wrong post mortem.
But if the behaviour is undefined then another compiler or one with different optimization enabled might no-op this code so it drops through into the next section where something less obvious might happen. So a tool which checks for deliberately undefined behaviour in code is probably a good thing.
Slashdot Mirror
So it's really baffling to me why Cannonical is reinventing the wheel here
I think the main reason is by owning the display tech they can shut their competition out of the mobile / tablet space. Mir is dual licenced - proprietary or GPLv3. They can do what they like under their proprietary licence while hamstringing their competition with the onerous requirements of the GPLv3 (e.g. not being able to link proprietary drivers, limits on DRM). It's probably why Intel walked away from the project.
The Ubuntu wiki is tries to provide technical reasons but it's all pretty vague - it alludes to issues like lack of support for 3d input devices and a few other problems with the protocol but these don't sound very convincing arguments to write everything from scratch.
Either way it serves as an example of a repair which would be very difficult / expensive to rectify. Hence why they might push a software hack to jack the suspension up a bit.
I agree too, but at the same time there is a very useful saying - never buy version 1.0 of anything. And that applies especially to motor vehicles regardless of their mode of propulsion. They usually suffer recalls and that's just for the critical / safety related problems that the loss adjusters say can't wait. There must be a raft of lesser but still serious issues which either cannot be fixed or only get fixed if you bring the car in for a service. Raising the suspension in vehicles sounds like a kludge for an issue which cannot be fixed in any other way short of strengthening the underside of the car.
They aren't technical enough yet. Blocking search terms just incentivizes people to search for alternate sources of material.
A vastly better idea would be to allow these search terms through, monitor which images / sites were subsequently clicked on and then provide this information allow with IP logs to the relevant law enforcement agencies. In other words, let these freaks hang themselves with their own rope. The most likely consequence of banning these terms is that child porn will be driven underground, into Tor servers and so forth where it is far more difficult to monitor.
That's an utterly absurd assertion. There are voluminous examples of "natural" vegetable and meat products which have caused outbreaks. e.g. Europe suffered a mass e.coli outbreak from cucumbers of all things that was estimated to have killed 53 people and sickened thousands more. Just one example of many.
There is nothing inherently unsafe about synthetic products because it is a completely meaningless blanket term. For example, most preservatives are "synthetic" (produced by biochemical or strictly chemical processes) but they are put into foods to inhibit microbes which themselves can be extremely harmful.
But you seem to believe that synthetic means carcinogenic and there is some conspiracy by corrupt scientists to push this stuff into foods. It's absurd.
Personally I think the hysteria over 3D gun printing (and the attendant hype by those who think it is a wonderful thing) is totally overblown. Anyone fashioning home made guns, be they from masking tape or plastic deserves everything they get. If the gun blows up in their faces, or ends up being used against them then it serves them right.
Sorry but your response is not very rational. Foods should be regarded on their individual merits whether they are natural, processed, or "synthetic" (which usually just means processed). It is incredibly easy for someone to eat a bad oyster or be poisoned by a misidentified berry / mushroom or get a dose of ecoli / salmonella / botulin and suffer a serious, potentially fatal reaction. Implying that "natural" foods are in some way safer belies the reality that they aren't. In some ways they are far less safe because the quality from one batch to the next could be all over the shop. And allergies are not some modern phenomena either. Diagnostic tests are better. It's just in the good old days some kid who was coeliac (for example) would simply fail to thrive and be lumped in with other causes of high infant mortality.
With a side dish of castor beans and wild almonds for desert.
Why should "synthetic garbage" be any more detrimental to someone's health than organic or natural items? There are plenty of plants which in their wild variety, or in unprocessed or uncooked form can make people horribly sick.
The reason ActiveX got the heat was that authors were meant to self-declared controls as safe for scripting, and IE honoured that declaration. If I had installed BadlyWritenControl then any website could instantiate it and exploit it. Scripting a control was easy too thanks to OLE automation and IDispatch interface. Worse, even if I didn't have BadlyWrittenControl installed, the website could still reference the CAB file that contained it and IE would facilitate the automatic download and installation of it.
Conversely installing a plugin was a pain in the ass. Even if a page said it needed a plugin and provided the url to it, the user still had to manually go off and install it. Therefore by default plugins had a level of safety which IE did not have. And it was also a pain for developers to write a scripting API for a plugin, so many plugins didn't bother or offered only minimal scripting. I don't think this was intentional security, just the general craptitude of LiveConnect provided better security as a side effect.
Anyway, I don't see PNaCl as being unsafe per se but it should be something that is disabled by default, and even when it is enabled, users should be alerted and given the option of blocking execution of apps on a per site basis.
I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js
NaCl stands for native client. i.e. you download software compiled for x86 or ARM instructions and run it in your browser at native speeds. It is sandboxed and limited to what it can do within its sandbox. But having to recompile the same code for each architecture is obviously a pain, so PNaCl allows devs to compile once to LLVM and run anywhere.
Asm.js is an important thing to pursue but it fundamentally a hack. Tools like Emscripten compiled code to LLVM (like PNaCl), and then emit equivalent JS. Then that has to be loaded, parsed, recompiled again and run over a JS engine with the performance and memory overhead that this implies. I would rather than browsers adopt a LLVM based runtime framework like PNaCl so few of the overheads of using JS are necessary.
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
That could be said of most cross-platform toolkits and its hardly surprising. C/C++ traditionally hasn't bothered to make the distinction between an immutable and mutable string, nor provide hints as to who owned the string (implementation or caller), or of making efficient use of memory, or of providing utils to convert or manipulate character sets or encodings. So the toolkits typically encapsulated strings in classes to provide these things.
And even though the standard C++ library has a std::string class, I expect toolkits have enough reasons to stick with their own classes. And that's just strings. I expect there is a similar story for things like threads (and various thread patterns like thread pools), collections, semaphores, mutexes, file handles, sockets, etc.
I don't think there is serious debate that nuclear is a very important source of power, one that can not be discounted. But it would be wise for any strategy to make use of renewables whenever humanly possible. Perhaps Japan is now sufficiently motivated to show other countries how it can be done.
Knifing tyres is criminal damage. Throwing a coke bottle on the line is littering. It's easier to get away with. It's also easier to retreat to a safe distance and watch as a stupid system fails to safe over a coke bottle (or a strategically placed wrapper) and backs up all the way down the system. If the designers of this system don't don't anticipate this they don't understand human nature.
Given how the process works I would say it took hours if not days to print out, and many more hours of finishing, removing supporting bits, polishing etc.. However it would be interesting to see a time lapse of the main frame being printed or something.
I wonder how long it will take for the locals to devise ways of griefing these pods - forcing them to stop dead if they detect a plastic bottle in their way, slapping a burger wrapper over the sensors or something similar. I could see the entire system failing right there. It's a problem that self driving cars would face assuming they ever moved beyond a pipe dream.
I can roll a PGP key myself and it works of whether I have zero signatures, or multiple signatures. It's up to the recipient to determine if they trust me based on my signatures. The more signatures I have, the harder it is to fake or do a man in the middle, but even zero signatures means protection from casual eavesdropping.
That's how it should be for web certs. Roll your own. At a bare minimum you get encrypted communication. If someone wants more they can get their partner sites to sign their key. If they want more again, then then can pay for a CA and jump through the hoops it expects for this service.
But a CA signed cert should not be necessary just to get crypto in a browser. It should also be abundantly clear from recent events how illusory this security is. If someone has a compliant root CA they can do a man in the middle attack. It's far more difficult to do if the cert is signed by multiple signatories (since each would have to be compromised) and if the browser is capable of comparing the cert between sessions and alerting the user to major differences.
It's a tax on security. I should be able to roll my own cert and at least benefit from crypto. If the nature of my business demands I sign the key I should be able to decide if I want to pay a notary / CA for a signature, or just get all my business contacts to sign it for me.
What I shouldn't have to do is what the current model requires. It's onerous, and it means insecurity by default.
If it's a good console then it will still be a good console in 6 months from now when there are some actual worthwhile games to play on it and the firmware has gone through a few feature enhancements. It took several major updates of the PS3 firmware for some things to appear that we take for granted. Including DLNA.
And if a site wants something more then they should be able to have their key signed by their buddies, business partners, trade associations, governments, and yes even CAs to build a web of trust. So a bank might well pay a CA for a signature, but it might also get a signature from its banking federation, it's rival / partner banks, the government, and a business bureau. If the cert suddenly changes, or if any of the signatures mysteriously change then the browser has the knowledge necessary to warn a user. That makes it far harder to compromise the security. It also means that no site has to pay a CA for the privilege of security. It might be advantageous to do it for a bank or suchlike, but smaller operations would build out a more organic trust model.
How a browser presents this information falls outside of this. I don't see it being especially different from how browsers present this information now except it would be more important to users to know when the information changes, rather than when it doesn't.
And it's no good pretending "devs shouldn't do that". Maybe they shouldn't, at least not in production code, but it's quite possible they might and that is what a tool might pick up. There are also far more subtle things that are not intentional but are still optimized away. There are links on this page which describe some of them, such as null pointer checks in the kernel which are optimized away simply due to the order some of the tests are made in.
Back off doesn't mean let the guy get away and your scenario sounds pretty ludicrous.
2. It is a bullet that is put in a hand gun. It will be a separate device which could be mounted on the pursuing cop car.
3. $500 is chicken feed compared to the damage, potential loss of life, insurance liability etc. of a high speed pursuit. Cops don't have to maintain constant visual contact to see where the vehicle is going. Consequently they can drop back, lessen the tension of the pursuit, plan to intercept the vehicle with stingers etc and bring the thing to a safer and faster conclusion.
4. It'll go to those departments which see merit in carrying it. Presumably the FBI have far more covert means of tracking the car than chasing after it and firing something at it which splats on the back of the car.
5. Read the article.
But if the behaviour is undefined then another compiler or one with different optimization enabled might no-op this code so it drops through into the next section where something less obvious might happen. So a tool which checks for deliberately undefined behaviour in code is probably a good thing.