There are two reasons that GCC does not cover that kind of code. One is that the mere act of compilation (a mechanical translation of the code from one form to another) does not implicate copyright. The other is that GCC includes a specific exception for standard header files and things that it compiles or links into your code as a result of the language features you use. The Opa developers explicitly reject that approach.
Don't worry, the OSGi people are going to fix the confusing name mess. Pretty soon, those libraries will be OSGi Spring or Struts OSGi or HibernateBeanOSGi.
But first they need to figure out what OSGi stands for. Or even what it does. (They know it doubles as a sandwich spread and a floor cleaner, and there are a lot of buzzwords involved, but are not quite clear beyond that.)
What cost of a new phone? If you like your current phone, keep it or move to something similar. At the end of your current contract, something that has comparable specs is probably going to be available for $50 or less with a new contract. If you pay $200+ for a phone when you contract with a wireless carrier, it's because you want a relatively new and powerful phone.
Has anyone come up with better attacks on ROT13 lately?
There are also putatively strong cryptosystems that have simply not been the focus of much recent study, and so nobody has devised better attacks on them, even though better attacks probably exist.
It is usually not practical to pick "a simpler, more elegant math algorithm" because those are easy -- or at least easier -- to break. As someone mentioned up-thread, and as Bruce Schneier likes to remind us, attacks tend to get better over time -- they never get worse.
Modern cryptosystems are carefully tuned to resist a lot of clever attacks. Probably every stage in every (credibly) proposed encryption scheme has been closely examined by very smart people to understand its behavior and look for weaknesses. Existing systems have very elegant structures that are simple in most respects, but they are complicated in certain ways because consistently simple designs are much easier to exploit.
(As a further complicating factor, using a longer key generally requires using more internal state and more rounds. You might -- or might not -- be able to double the block size, but to move from 128-bit to 256-bit keys, you are very likely to need to increase your cipher from [say] 8 rounds to 12. This means at least a 50% increase in execution time for the same amount of data, and possibly more. If the increased size bumps your S-boxes, state and code out of L1 cache, it will be much worse. If you cannot double the block size, but need to double your internal state size for the larger key, that will add another doubling of execution time.)
The fine print from the summary isn't even quite accurate -- the attack complexity is slightly more than 2^125. If you assume computers can check about a billion (2^30) keys per second, and given that you have about 2^25 seconds in a year, you would need about a trillion (2^40) computers to guarantee success in a billion years. (125=30+25+40+30.)
Microkernel versus monolithic kernel has nothing to do with board support packages.
Linux has the equivalent of "board support packages" -- they can be as small as one file, but are more often just a handful: a C file that describes memory and I/O mappings and other peripherals that cannot be safely detected at runtime, sometimes a default configuration (defconfig) file, and maybe some other pretty small driver-like files that manage some of the mess that Linus was talking about. (For example, the BeagleBoard has three C files: one to define the board, one to manage LCD video configuration, and one for audio setup; it shares a defconfig with every other board using an OMAP2/3/4 CPU.)
That is in sharp contrast to my experience with commercial RTOSes, where a BSP might consist of a dozen C source and header files, plus another half-dozen configuration files. For the boards I have used, Linux has the smallest set of board-specific files, a microkernel RTOS has the next smallest, and a Unix-based RTOS has the largest. Linux doesn't call its board-specific file sets BSPs because they are (a) too small to really call a "package" and (b) not controlled and shipped separately. (Linux is not about locking down what the end user can do, so there would be no point in having BSPs for officially supported boards.)
Your position, taken to an extreme, would also be deleterious. Guess what: Most people don't take their own positions to the ultimate extreme. People who don't want to engage the other person's actual position do that. It is called attacking a straw man.
And the Democratic media called Florida for Gore before polls closed in the heavily conservative panhandle parts of Florida, deterring residents there from registering their preferences. There are a thousand and one counterfactuals about things that might have changed the results but didn't.
The anecdote doesn't tell you much, but the state probably is not going to release any information on the false alarm rate among the software's detections. Doing so would reveal how much of a waste the money was.
This kind of system tends to suffer badly as the database size grows, because the false alarm rate per comparison tends to grow with the number of templates (which is probably the number of people with driver's licenses), and the number of comparisons is proportional to the square of the number of people with driver's licenses -- so the number of false alarms is O(N*N*f(N)), where f(N) is some function that increases with N.
I think it's pretty fair -- if a web app doesn't have quality from the start, it will take a rewrite for it to have quality later. You can't just patch one or two things to fix it.
On the other hand, an awful lot of internally hosted "enterprise ready" applications with servers running at a business have really lousy performance, usability and stability. At my workplace, they are on I think the third "Enterprise Resource Planning" system in four years. I don't know exactly what made them abandon the last one; the new one seems to have an extremely similar UI and the server seems to be less stable. That's all with native applications -- no web involved, which surprises me a bit.
This. Some of the people on LKML pointed out that the guy's floods of ~180 patches at a time grossly violated the patch submission standards laid out in Documentation/SubmittingPatches ("Do not more than 15 patches at once to the vger mailing lists!!!"). I know it annoyed me, and it seemed like a huge amount of code churn for a driver in staging. I didn't realize until I saw this story what the driver was or who the author was.
I call shenanigans. How many people get 80-page bills for their (home) land lines? My bill for a combined voice/data/television package (from the incumbent phone carrier) is about five pages long each month, and a lot of that is legally-required boilerplate notices and disclaimers. Half of the rest is formatting to make it easier to follow the content.
Amen. One can rely on developer-written regression tests and QA to detect bugs, but those two approaches will never find all the bugs. Your customers spend years or decades stumbling over all the bugs that QA missed. A lot of companies and customers are going to accept that, but that acceptance is almost unique to software. If any other kind of designers routinely delivered the kind of flawed products that software houses pump out, those other designers would be sued out of business by angry customers and regulators.
Probably some kind of interpreter or command dispatch system, where the inputs and outputs are regular across a lot of functions. The code to build and dispatch those things is a lot simpler and clearer if you map the command names (or other search or trigger criteria) to pointers-to-member-functions than if you use a switch or if/then chain.
You're almost right -- but please save me from stream-of-consciousness comments. I have seen comments where I think the programmer's complete thoughts *were* in the comments, but they were not helpful because there were related assumptions that weren't part of the conscious thought, and they were hard to follow because the programmer had to exert effort to communicate clearly. (Not because of a language issue or anything like that; this programmer just didn't have much practice at explaining things in writing.)
Good comments convey the things you mentioned to a future maintainer, tester or reviewer.
So, how many European countries have fair dealing or some similar set of exemptions? One? That Wikipedia page doesn't even list Ireland as a place where a fair dealing defense is available.
Shaders are not really more complicated than the geometric transforms and image management bits in the Canvas element. They are simpler than CSS inheritance rules. I could go on, but I hope you get the point.
You seem to be a narrow-minded Microsoft shill with no tact. There is a lot more code in the rest of the web client stack than in the WebGL and OpenGL layers; there is only hand-waving support for the claim that GL shader code running on the video card could trigger undesired DMAs; there are only vague suggestions that bugs in the GL rendering stack are (a) exploitable via WebGL and (b) have any security impact. The code to handle a lot of web content -- for example, video or image data -- is also more complicated and more susceptible to remote exploits by its nature, compared to the GL compilation and rendering stack. Your proposed analogy is way off.
Unless users disable them (coincidentally breaking plenty of web sites), those plugins run on their systems and are driven by web content. That makes the plugin thing a largely irrelevant distinction.
How does the browser control what Flash draws to the screen? How does the browser control what (as many people here point out) Silverlight draws to the screen or touches on disk? The Canvas element certainly isn't 10 years old -- it adds a bunch of things to HTML that don't have 10 years of sandboxing experience behind them. I do not deny the security concerns relating to WebGL, but I think that they are distorted and overblown by people with an agenda; there are equally great security concerns with a lot of other new web client technologies.
Consequently, the Canvas element is obviously harmful too.
Video drivers do a lot more than just OpenGL. It's not clear to me that WebGL exposes any more potential security issues than anything else in a web browser.
Bugs in the OpenGL stack are no more plausible than bugs in the rest of a web client stack. Arguably they are less likely in OpenGL because the semantics are more tightly defined and the set of commands is smaller and less complex than in (say) HTML 5. Heck, the Canvas element is almost as complex in a lot of ways as WebGL, and has equal scope for exploiting graphics driver bugs.
Slashdot Mirror
Wikileaks is an "enterprise". Why shouldn't Assange's transparency rules apply to it?
There are two reasons that GCC does not cover that kind of code. One is that the mere act of compilation (a mechanical translation of the code from one form to another) does not implicate copyright. The other is that GCC includes a specific exception for standard header files and things that it compiles or links into your code as a result of the language features you use. The Opa developers explicitly reject that approach.
Don't worry, the OSGi people are going to fix the confusing name mess. Pretty soon, those libraries will be OSGi Spring or Struts OSGi or HibernateBeanOSGi.
But first they need to figure out what OSGi stands for. Or even what it does. (They know it doubles as a sandwich spread and a floor cleaner, and there are a lot of buzzwords involved, but are not quite clear beyond that.)
What cost of a new phone? If you like your current phone, keep it or move to something similar. At the end of your current contract, something that has comparable specs is probably going to be available for $50 or less with a new contract. If you pay $200+ for a phone when you contract with a wireless carrier, it's because you want a relatively new and powerful phone.
Except for waterboarding and maybe keyloggers, none of those are new. They are also not attacks in the sense that everyone else is talking about.
Has anyone come up with better attacks on ROT13 lately?
There are also putatively strong cryptosystems that have simply not been the focus of much recent study, and so nobody has devised better attacks on them, even though better attacks probably exist.
It is usually not practical to pick "a simpler, more elegant math algorithm" because those are easy -- or at least easier -- to break. As someone mentioned up-thread, and as Bruce Schneier likes to remind us, attacks tend to get better over time -- they never get worse.
Modern cryptosystems are carefully tuned to resist a lot of clever attacks. Probably every stage in every (credibly) proposed encryption scheme has been closely examined by very smart people to understand its behavior and look for weaknesses. Existing systems have very elegant structures that are simple in most respects, but they are complicated in certain ways because consistently simple designs are much easier to exploit.
(As a further complicating factor, using a longer key generally requires using more internal state and more rounds. You might -- or might not -- be able to double the block size, but to move from 128-bit to 256-bit keys, you are very likely to need to increase your cipher from [say] 8 rounds to 12. This means at least a 50% increase in execution time for the same amount of data, and possibly more. If the increased size bumps your S-boxes, state and code out of L1 cache, it will be much worse. If you cannot double the block size, but need to double your internal state size for the larger key, that will add another doubling of execution time.)
The fine print from the summary isn't even quite accurate -- the attack complexity is slightly more than 2^125. If you assume computers can check about a billion (2^30) keys per second, and given that you have about 2^25 seconds in a year, you would need about a trillion (2^40) computers to guarantee success in a billion years. (125=30+25+40+30.)
Microkernel versus monolithic kernel has nothing to do with board support packages.
Linux has the equivalent of "board support packages" -- they can be as small as one file, but are more often just a handful: a C file that describes memory and I/O mappings and other peripherals that cannot be safely detected at runtime, sometimes a default configuration (defconfig) file, and maybe some other pretty small driver-like files that manage some of the mess that Linus was talking about. (For example, the BeagleBoard has three C files: one to define the board, one to manage LCD video configuration, and one for audio setup; it shares a defconfig with every other board using an OMAP2/3/4 CPU.)
That is in sharp contrast to my experience with commercial RTOSes, where a BSP might consist of a dozen C source and header files, plus another half-dozen configuration files. For the boards I have used, Linux has the smallest set of board-specific files, a microkernel RTOS has the next smallest, and a Unix-based RTOS has the largest. Linux doesn't call its board-specific file sets BSPs because they are (a) too small to really call a "package" and (b) not controlled and shipped separately. (Linux is not about locking down what the end user can do, so there would be no point in having BSPs for officially supported boards.)
Your position, taken to an extreme, would also be deleterious. Guess what: Most people don't take their own positions to the ultimate extreme. People who don't want to engage the other person's actual position do that. It is called attacking a straw man.
And the Democratic media called Florida for Gore before polls closed in the heavily conservative panhandle parts of Florida, deterring residents there from registering their preferences. There are a thousand and one counterfactuals about things that might have changed the results but didn't.
The anecdote doesn't tell you much, but the state probably is not going to release any information on the false alarm rate among the software's detections. Doing so would reveal how much of a waste the money was.
This kind of system tends to suffer badly as the database size grows, because the false alarm rate per comparison tends to grow with the number of templates (which is probably the number of people with driver's licenses), and the number of comparisons is proportional to the square of the number of people with driver's licenses -- so the number of false alarms is O(N*N*f(N)), where f(N) is some function that increases with N.
I think it's pretty fair -- if a web app doesn't have quality from the start, it will take a rewrite for it to have quality later. You can't just patch one or two things to fix it.
On the other hand, an awful lot of internally hosted "enterprise ready" applications with servers running at a business have really lousy performance, usability and stability. At my workplace, they are on I think the third "Enterprise Resource Planning" system in four years. I don't know exactly what made them abandon the last one; the new one seems to have an extremely similar UI and the server seems to be less stable. That's all with native applications -- no web involved, which surprises me a bit.
This. Some of the people on LKML pointed out that the guy's floods of ~180 patches at a time grossly violated the patch submission standards laid out in Documentation/SubmittingPatches ("Do not more than 15 patches at once to the vger mailing lists!!!"). I know it annoyed me, and it seemed like a huge amount of code churn for a driver in staging. I didn't realize until I saw this story what the driver was or who the author was.
I call shenanigans. How many people get 80-page bills for their (home) land lines? My bill for a combined voice/data/television package (from the incumbent phone carrier) is about five pages long each month, and a lot of that is legally-required boilerplate notices and disclaimers. Half of the rest is formatting to make it easier to follow the content.
Amen. One can rely on developer-written regression tests and QA to detect bugs, but those two approaches will never find all the bugs. Your customers spend years or decades stumbling over all the bugs that QA missed. A lot of companies and customers are going to accept that, but that acceptance is almost unique to software. If any other kind of designers routinely delivered the kind of flawed products that software houses pump out, those other designers would be sued out of business by angry customers and regulators.
Probably some kind of interpreter or command dispatch system, where the inputs and outputs are regular across a lot of functions. The code to build and dispatch those things is a lot simpler and clearer if you map the command names (or other search or trigger criteria) to pointers-to-member-functions than if you use a switch or if/then chain.
You're almost right -- but please save me from stream-of-consciousness comments. I have seen comments where I think the programmer's complete thoughts *were* in the comments, but they were not helpful because there were related assumptions that weren't part of the conscious thought, and they were hard to follow because the programmer had to exert effort to communicate clearly. (Not because of a language issue or anything like that; this programmer just didn't have much practice at explaining things in writing.)
Good comments convey the things you mentioned to a future maintainer, tester or reviewer.
So, how many European countries have fair dealing or some similar set of exemptions? One? That Wikipedia page doesn't even list Ireland as a place where a fair dealing defense is available.
Shaders are not really more complicated than the geometric transforms and image management bits in the Canvas element. They are simpler than CSS inheritance rules. I could go on, but I hope you get the point.
You seem to be a narrow-minded Microsoft shill with no tact. There is a lot more code in the rest of the web client stack than in the WebGL and OpenGL layers; there is only hand-waving support for the claim that GL shader code running on the video card could trigger undesired DMAs; there are only vague suggestions that bugs in the GL rendering stack are (a) exploitable via WebGL and (b) have any security impact. The code to handle a lot of web content -- for example, video or image data -- is also more complicated and more susceptible to remote exploits by its nature, compared to the GL compilation and rendering stack. Your proposed analogy is way off.
Unless users disable them (coincidentally breaking plenty of web sites), those plugins run on their systems and are driven by web content. That makes the plugin thing a largely irrelevant distinction.
How does the browser control what Flash draws to the screen? How does the browser control what (as many people here point out) Silverlight draws to the screen or touches on disk? The Canvas element certainly isn't 10 years old -- it adds a bunch of things to HTML that don't have 10 years of sandboxing experience behind them. I do not deny the security concerns relating to WebGL, but I think that they are distorted and overblown by people with an agenda; there are equally great security concerns with a lot of other new web client technologies.
Consequently, the Canvas element is obviously harmful too.
Video drivers do a lot more than just OpenGL. It's not clear to me that WebGL exposes any more potential security issues than anything else in a web browser.
Bugs in the OpenGL stack are no more plausible than bugs in the rest of a web client stack. Arguably they are less likely in OpenGL because the semantics are more tightly defined and the set of commands is smaller and less complex than in (say) HTML 5. Heck, the Canvas element is almost as complex in a lot of ways as WebGL, and has equal scope for exploiting graphics driver bugs.