"Our anti-virus kit moves over files so quickly, the virus shrinks to zero length and has infinite mass!" "The new herustic bends space-time, causing malware to fall off the edge!" "AVSoft's new scanner sends you backwards in time, so you were never infected in the first place!"
For the second email, I think I recognized the random phrase generator from a PET BASIC sample programs book. Well, the presence of a non-human "intelligence" is pretty obvious, but the skew in the randomness exposes the PRNG in use.
a) By having a browser declare what is (supposedly) supported, users will have an easier time identifying buggy components. By allowing those same users to switch to non-buggy components from rival browsers, there is a pressure to do a set of features well rather than all features badly. You can pick up components from elsewhere for what isn't supported by default, but you've no reason at all to stick with half-baked, half-chewed components that don't work, even if you want to use the front-end.
b) It follows the Unix tradition of Keep It Simple (each instance of each component has a single stream in, a single stream out and a single task to perform), making it much harder for programmers to balls up a given component. It's like writing a buggy version of echo. You're not so concerned about the interactions within a highly sophisticated integrated engine, because there isn't one.
I'd rather not see an entire rendering engine in one huge monolithic chunk. Part of the reason that web standards outpace browser development by so much is that most engines are very hard to extend. What's wanted is a "standard" API for a data-to-data transformation engine. Instead of the W3C producing a proof-of-concept browser like Amaya, all they need do is produce a proof-of-concept transformation engine instead, which can then be used also to verify proof-of-correctness. (Any other transformation engine for that same transform will produce the same output for the same input.)
Sure, they can still have their own web browser, but they don't need to re-write it when they add to the standard, they can just slide in another engine.
How would this work, in practice? Well, my thought is that each opening tag and either explicit or implicit closing tag would be assigned a numerical value that would be assigned by the W3C, much as the IANA assign port numbers. Each engine would then register what numerical values it supports.
The browser would then consist of five parts: network I/O, a preprocessor which converts tags to ID, a set of engines which would "compile" the page from a "high-level" format into a much "lower-level" portable format, a rendering engine which converted the portable format into a much more specific format, and then a display engine which displayed the results.
The primary advantage of this sort of arrangement is that things like CSS could then be easily replaced in a browser. It would be much more pluggable than the Mozilla engine or the libwww engine. It would be much more customizable. A major plus, given that very few browsers conform the the whole standard and all conform to different bits. If you could rip out modules from a browser you didn't like but did support a tag or feature you needed, this would not be a problem.
The secondary advantage is that it would be possible to provide support for non-SGML-derived tag-based systems, such as TeX, Postscript, and so on, natively. At the moment, you can include a link to a.ps file on a web page, but it's very hard to embed it, and completely impossible on most browsers to embed it in a way that integrates completely smoothly with HTML or would allow you to include active hyperlinks within it (unless an independent postscript viewer supported them). By compiling the whole page from all kinds of formats into a single, unified format, anything that is possible in one format becomes possible in all formats.
This isn't how web browsers are written, though, and it doesn't seem likely that this is how web browsers will be done in the future. Which keeps document types isolated from each other and keeps browsers from fully supporting any of those document types.
Technically, a driver can be split into three parts. You have a part which talks to the bus (or an abstraction layer that looks like a bus), you have a part which talks to the OS (or, in Microsoft's case, an abstraction layer that looks like an OS), and you have the logic of the driver - the bit that takes an instruction to do something, performs whatever internal operations are needed, and sends to its two interfaces suitable output.
Most drivers combine all of this into one monolithic unit, usually for "optimization" reasons, but you can get good source-to-source and source-to-binary optimizers that can do the conversion for you, if it's really needed. Thus, your raw source can be split as described. You don't care if the driver binary is or isn't, so long as it works and works fast enough.
The only time you absolutely have to know the kernel internals is within the OS interface layer. You also need to know what sort of threading the kernel supports IFF (if and only if) the driver needs to be run as a kernel thread, say when the interface it drives can deliver data to the kernel without the kernel asking for it. Other than that, the OS interface can hide most of the detail. (This layer and the interface layer would likely be a mix of inlinable functions and macros. You want the source to contain the divisions, for portability, you don't care about the binaries.)
Finally, you either write to an existing spec, such as Linux, or you can write to an idealized spec that no OS supports. The former means that you can skip the OS interface layer for the target OS if you want, it's all null operations. Porting to Windows then means you write a new OS interface layer, and all drivers written to the driver spec will then work on the new target OS. Let's say Linux 2.6.27 is your baseline OS, then a conversion layer that'll let you run the driver in Windows is doable - provided the core of the driver is OS-agnostic and uses only APIs that are intended for driver use and documented as such.
The difficulty in driver portability is that drivers are very rarely OS-agnostic. They are written small and fast, but rarely are they written to be clean and portable. OS' also tend to prefer drivers that are "dumb" end-points rather than kernel applets that can take independent action or can be driven from any of their interfaces. This last point is important, in that even if you were to write a "driverlet", it won't work on any OS incapable of handling the concepts involved.
Well, yes, which is why they're desperate to kill off all the old lines as and when they can. (Not that Vista was a serious competitor in the embedded market.) In the end, though, the only advantage in having a genuinely licensed copy of Windows is that you can use Microsoft's update - but as soon as the updates stop coming, Genuine Advantage is no advantage.
But back to the drivers. Microsoft badly underestimated the reaction of users (they didn't just put up with it) and also underestimated the reaction of vendors (they didn't bother with it). This may not offer much of a window of opportunity for alternatives, as users are demonstrably sticking with XP over switching to non-Microsoft OS'. It might, however, persuade those vendors who have not yet taken the Vista OR Linux plunges to listen to Linux "representatives" like Linus, Red Hat or Ubuntu. The reasoning here is that if you're going to write a driver anyway, (a) Linux is simpler, and (b) because the kernel API keeps getting buggered up, the driver will need to be made fairly easy to port. Provided the driver is written correctly, it should be easier to write for Linux and port to Vista than to have written for Vista in the first place. More marketshare for less effort.
The probable net impact of Microsoft's predicament is likely to be close to zero. A few additional vendors might eye Linux, but without a lot of heavy-duty hard-sell, the number likely to add Linux to their list of supported platforms in consequence of Vista is going to be single-digit at best. Most interested vendors already supply the docs or the drivers, the rest don't give a damn.
A far bigger impact will be if the EU rejects any ongoing Microsoft appeals and/or applies further penalties, and/or Obama pushes the DOJ to rip into Microsoft (assuming there's anything definitive they can pin on them). Microsoft hasn't had enough bad publicity to really hurt them. If Vista never sold another copy, Microsoft has sufficient loose change to carry on through to Windows 7, and the sales of their other products pretty much guarantees they could outlast the end of the world if they had to. (3.5 billion years until a species intelligent enough to need a desktop OS evolves? No sweat. Besides, gives them time to apply all of the necessary bugfixes before the release.)
One of the best computer-based documentation systems I ever saw on a computer was Norton Guides. Context-sensitive, pop-up as needed, easily-browsed, navigation was far saner than info. It was little-known when it was around, and died from attention starvation. I've seen nothing comparable for Unix - or, indeed, for any other OS.
The card hardware doesn't, but the kernel driver API has been. Routinely. I pity the poor people who have to use unmaintained drivers on a version of the kernel that has subsequently-filled security holes and/or performance fixes. Also, I suspect for something like fieldbus or VME, where you're likely talking about high-end scientific or engineering uses, the user is likely to want to be able to use more modern CPUs which may or may not be correctly supported on antique kernels.
That's true, but Linux isn't where it could - or should - be. There are many antique 3rd part drivers for Linux for embedded devices and busses (COMEDI doesn't get updated often, DDC's Linux drivers for $1000+ aviation buses haven't been updated in years, VME drivers are equally badly maintained), where comparable drivers for Windows are nice, shiny and up-to-date... even though you know damn well that's not where the market is. It seems to me that some hardware vendors release Windows drivers because they know it'll look good to PHBs, but neglect Linux drivers because they don't give a rat's ass whether the hardware is usable or not after it's out the door.
In order to be applicable to Dark Matter theories, the particle would need to be traveling at near light-speed for the lifetime to be long enough to matter. But if it's traveling that fast, the mass would have changed and no longer fit the theory. However, if the relative velocity is low enough for the mass to be right, it simply isn't going to last long enough to have any impact.
Besides which, I suspect further discoveries in cosmology will reduce - and eventually eliminate - any need for dark matter. Galaxy formation already got something of a re-write not too long ago, and it was galaxy formation that was one of the areas that "needed" dark matter to explain. Grabity - err, gravity - didn't seem to be sufficient in the earlier models. Other models, such as the forming of particles and any biases that might apply, have also been modified. We also know more about the distribution of new stars in a galaxy than we did back then. One can assume the dark matter theorists have redone the calculations to see how all of these different effects alter the models, but when was the last time you saw an article on such a recalculation?
Needless to say, I do not believe in dark matter. I'm willing to be convinced, if it can be shown that all these adjustments are asymptotic to values that still cannot describe what we observe to be true, or if this "dark matter" can be observed in the laboratory. But until then, it seems prudent to be skeptical once you know that the calculations used to predict dark matter were incorrect and there is no clear-cut evidence of recalculations being done with better data.
Quantum crypto is breakable, the only benefit is that you can tell what packets are sniffed. So, if you only use unsniffed packets, you're guaranteed nobody else has those - at least at that time. You can't guarantee it for later on, at least to the same degree of certainty, but you can produce a reasonable level of trust. An A1-class OS with tamper-resistant hardware and strong authentication should put the cost of getting to the key above most infiltrators. Not all, and the greatest vulnerability is still going to be social engineering attacks against those authorized to have access, but it's as close to "good enough" as you're going to see in your lifetime.
The idea of using quantum cryptography for the actual data is BAD. Nonononono. It doesn't protect the data any better, all it does is identifies if it has been looked at. So, using it for data simply allows you to know when others have stolen your secrets, it doesn't stop them from doing the stealing.
The "perfect" encryption system (one that is totally unbreakable) will only exist once computer-brain interfaces move into the Neuromancer realm. Perfect? Yes. Same idea as before, for the one-time pad, but deliver the key and data to the subconcious. Then the person can act on the information without actually knowing they know it. This eliminates any form of social engineering and thus the only remaining weak point. It is also well beyond anything that will exist for a long long time, so will remain theoretical only. Nonetheless, as a theoretical concept, it does establish a method by which an unbreakable system could exist without violating any known physical or mathematical laws.
It struck me that there was a similarity between the timing of the portals and the distance, too. Now, we know of other planets in the solar system with a strong magnetosphere, so in addition to your suggestions, I'd also ask if NASA is looking to see if similar corridors exist for other planets and whether there is any similar correlation between their portals and distance.
One could look at this in one of two ways. The first way is the line taken by the summary writer, that it's doom, gloom and disaster. In practice, this is actually the most likely scenario, as the alternative I'm going to suggest has never been seriously adopted by software vendors yet.
And now for that alternative! Writing code correctly. (Ooooh, scary! Just right for Halloween.) Correct code does not mean "correct according to Microsoft's preferred style", it means "abstracted out, so you don't give a damn about the underlying architecture" with "vendor-specific and platform-specific details encapsulated and hidden by portability libraries and high-level languages". If you write code that will run just equally well on a Cray 2, PC compatible, Apple, SGI Indigo or a microprocessor-controlled toaster, you can afford to simply not care what Microsoft does. The portability library(s), which might be any combination of cross-platform Open Source or Commercial libraries for common stuff, provides almost total immunity from Microsoft API changes, gives you (next to) zero upgrade costs (the "actual" costs are distributed across all of the vendors tied to the library at the time AND in future) and minimizes the risks (the minimum amount of 3rd party code is changed per API change and the maximum number of arcs are tested because everyone linking into the code becomes a QA).
Since the only practical method of maintaining such a model at the pace at which Microsoft breaks^H^H^H^H^H^Hchanges things is Open Source, it will force an increase in the adoption of Open Source methods and Open Source tools. At which point, Microsoft becomes a rather expensive bit-player in the operation, in comparison to alternative clouds. Since portability libraries eliminate lock-in, as well as upgrade headaches, companies would start going with the cheaper option.
This isn't going to happen, of course. Although the tie-in with Microsoft is harming vendors, creating excess overhead and reducing reliability, PHBs won't see it that way. All they will see is that lock-in means you can Blame Somebody Else. You can't sue them, you almost certainly can't even get them to honour their service agreements or any other contracts, but so what? Having Someone Else To Blame is the cornerstone of office politics. Good decisions are not. It doesn't matter if the company sinks as a result, since the notion of "company loyalty" is seen as something "old-fashioned" and inconsequential in today's environment. You go in, you get your paycheck, you eventually move on. It's expected. So why should a manager, who has no interest beyond looking good to other managers, care about good decisions? It won't earn them any more money, it won't get them any more respect, it won't give them a promotion, and it leaves them vulnerable to back-stabbing from other managers.
You cannot break it in a train, you cannot break it in a plane, you cannot break it here or there, you cannot break it anywhere. You cannot break *fish and ham, you cannot break it Sam-I-Am. (Hmmmm.... *fish would be a cool name for the next algorithm in that family...)
A one-time pad is pretty damn uncrackable, so long as the pad can be transferred without being intercepted, and quantum cryptography guarantees a message cannot be intercepted without you knowing. Thus, delivering one-time pads by quantum cryptography and then encrypting at most one message with that pad guarantees that the encryption cannot be broken. Well, unless the machine the pad is stored on is itself broken into, but you'd be stupid to provide an OTP keystore with Internet access or the root password on a sticky note on the monitor.
Let's take a fairly fundamental piece of software in science - the maths library. This needs to be able to do various transforms, perform linear algebra, perform matrix algebra and so on. And this needs to be done fast over a distributed system. Many of the same mathematical routines can be found in pure sound/music synthesis, 3D image manipulation and projection, audio/video codecs, and so on. Distributing code/data across multiple nodes isn't that different from distributing across multiple cores, except the cores only have a single processor cache. Some of the maths, therefore, directly applies to the multimedia sector, the commercial production of synthesizers, the improvement in digital decoders for television, and the games market.
What about more esoteric stuff? Is there any value in the public sector with NASA's open-source hypersonic computational fluid dynamics software? Or Colorado School of Mines' package on seismic data analysis? The first of those - well, it might improve the design of flight simulators, maybe. The other is basically a package for analyzing signals based on timing - very helpful for anyone working with ground-penetrating RADAR. Several other packages for signals processing exist - many sponsored by the Government, including VSIPL - which could be extremely handy for anyone working with software radio, speech recognition, or other projects (hobbyist and commercial) that need signal processing software that is both rigorously correct and fast.
FCC-compliant software for handling the ARINC bus protocols is probably not -that- valuable, but even there, there are enough amateur groups and enthusiasts who maintain historic aircraft that I would be wary of saying this would "never" be useful. Commercial components eventually get discontinued and such groups use whatever resources they can (including cannibalizing wrecks) to build their own replacement parts. That isn't true of modern electronic flight systems and the data buses they use - for now. But it's possible to imagine that such software would eventually be in demand.
Not sure about meaningless - it says ensembles can play chords that either don't exist or cannot be reached on a single instrument. That's quite an interesting observation that has a practical application.
Slashdot Mirror
"Our anti-virus kit moves over files so quickly, the virus shrinks to zero length and has infinite mass!"
"The new herustic bends space-time, causing malware to fall off the edge!"
"AVSoft's new scanner sends you backwards in time, so you were never infected in the first place!"
For the second email, I think I recognized the random phrase generator from a PET BASIC sample programs book. Well, the presence of a non-human "intelligence" is pretty obvious, but the skew in the randomness exposes the PRNG in use.
a) By having a browser declare what is (supposedly) supported, users will have an easier time identifying buggy components. By allowing those same users to switch to non-buggy components from rival browsers, there is a pressure to do a set of features well rather than all features badly. You can pick up components from elsewhere for what isn't supported by default, but you've no reason at all to stick with half-baked, half-chewed components that don't work, even if you want to use the front-end.
b) It follows the Unix tradition of Keep It Simple (each instance of each component has a single stream in, a single stream out and a single task to perform), making it much harder for programmers to balls up a given component. It's like writing a buggy version of echo. You're not so concerned about the interactions within a highly sophisticated integrated engine, because there isn't one.
I'd rather not see an entire rendering engine in one huge monolithic chunk. Part of the reason that web standards outpace browser development by so much is that most engines are very hard to extend. What's wanted is a "standard" API for a data-to-data transformation engine. Instead of the W3C producing a proof-of-concept browser like Amaya, all they need do is produce a proof-of-concept transformation engine instead, which can then be used also to verify proof-of-correctness. (Any other transformation engine for that same transform will produce the same output for the same input.)
Sure, they can still have their own web browser, but they don't need to re-write it when they add to the standard, they can just slide in another engine.
How would this work, in practice? Well, my thought is that each opening tag and either explicit or implicit closing tag would be assigned a numerical value that would be assigned by the W3C, much as the IANA assign port numbers. Each engine would then register what numerical values it supports.
The browser would then consist of five parts: network I/O, a preprocessor which converts tags to ID, a set of engines which would "compile" the page from a "high-level" format into a much "lower-level" portable format, a rendering engine which converted the portable format into a much more specific format, and then a display engine which displayed the results.
The primary advantage of this sort of arrangement is that things like CSS could then be easily replaced in a browser. It would be much more pluggable than the Mozilla engine or the libwww engine. It would be much more customizable. A major plus, given that very few browsers conform the the whole standard and all conform to different bits. If you could rip out modules from a browser you didn't like but did support a tag or feature you needed, this would not be a problem.
The secondary advantage is that it would be possible to provide support for non-SGML-derived tag-based systems, such as TeX, Postscript, and so on, natively. At the moment, you can include a link to a .ps file on a web page, but it's very hard to embed it, and completely impossible on most browsers to embed it in a way that integrates completely smoothly with HTML or would allow you to include active hyperlinks within it (unless an independent postscript viewer supported them). By compiling the whole page from all kinds of formats into a single, unified format, anything that is possible in one format becomes possible in all formats.
This isn't how web browsers are written, though, and it doesn't seem likely that this is how web browsers will be done in the future. Which keeps document types isolated from each other and keeps browsers from fully supporting any of those document types.
I'll only bother with the first part.
Technically, a driver can be split into three parts. You have a part which talks to the bus (or an abstraction layer that looks like a bus), you have a part which talks to the OS (or, in Microsoft's case, an abstraction layer that looks like an OS), and you have the logic of the driver - the bit that takes an instruction to do something, performs whatever internal operations are needed, and sends to its two interfaces suitable output.
Most drivers combine all of this into one monolithic unit, usually for "optimization" reasons, but you can get good source-to-source and source-to-binary optimizers that can do the conversion for you, if it's really needed. Thus, your raw source can be split as described. You don't care if the driver binary is or isn't, so long as it works and works fast enough.
The only time you absolutely have to know the kernel internals is within the OS interface layer. You also need to know what sort of threading the kernel supports IFF (if and only if) the driver needs to be run as a kernel thread, say when the interface it drives can deliver data to the kernel without the kernel asking for it. Other than that, the OS interface can hide most of the detail. (This layer and the interface layer would likely be a mix of inlinable functions and macros. You want the source to contain the divisions, for portability, you don't care about the binaries.)
Finally, you either write to an existing spec, such as Linux, or you can write to an idealized spec that no OS supports. The former means that you can skip the OS interface layer for the target OS if you want, it's all null operations. Porting to Windows then means you write a new OS interface layer, and all drivers written to the driver spec will then work on the new target OS. Let's say Linux 2.6.27 is your baseline OS, then a conversion layer that'll let you run the driver in Windows is doable - provided the core of the driver is OS-agnostic and uses only APIs that are intended for driver use and documented as such.
The difficulty in driver portability is that drivers are very rarely OS-agnostic. They are written small and fast, but rarely are they written to be clean and portable. OS' also tend to prefer drivers that are "dumb" end-points rather than kernel applets that can take independent action or can be driven from any of their interfaces. This last point is important, in that even if you were to write a "driverlet", it won't work on any OS incapable of handling the concepts involved.
Everyone but everyone goes for Cat6! It's not only rated at higher speed, it looks cooler too.
Well, yes, which is why they're desperate to kill off all the old lines as and when they can. (Not that Vista was a serious competitor in the embedded market.) In the end, though, the only advantage in having a genuinely licensed copy of Windows is that you can use Microsoft's update - but as soon as the updates stop coming, Genuine Advantage is no advantage.
But back to the drivers. Microsoft badly underestimated the reaction of users (they didn't just put up with it) and also underestimated the reaction of vendors (they didn't bother with it). This may not offer much of a window of opportunity for alternatives, as users are demonstrably sticking with XP over switching to non-Microsoft OS'. It might, however, persuade those vendors who have not yet taken the Vista OR Linux plunges to listen to Linux "representatives" like Linus, Red Hat or Ubuntu. The reasoning here is that if you're going to write a driver anyway, (a) Linux is simpler, and (b) because the kernel API keeps getting buggered up, the driver will need to be made fairly easy to port. Provided the driver is written correctly, it should be easier to write for Linux and port to Vista than to have written for Vista in the first place. More marketshare for less effort.
The probable net impact of Microsoft's predicament is likely to be close to zero. A few additional vendors might eye Linux, but without a lot of heavy-duty hard-sell, the number likely to add Linux to their list of supported platforms in consequence of Vista is going to be single-digit at best. Most interested vendors already supply the docs or the drivers, the rest don't give a damn.
A far bigger impact will be if the EU rejects any ongoing Microsoft appeals and/or applies further penalties, and/or Obama pushes the DOJ to rip into Microsoft (assuming there's anything definitive they can pin on them). Microsoft hasn't had enough bad publicity to really hurt them. If Vista never sold another copy, Microsoft has sufficient loose change to carry on through to Windows 7, and the sales of their other products pretty much guarantees they could outlast the end of the world if they had to. (3.5 billion years until a species intelligent enough to need a desktop OS evolves? No sweat. Besides, gives them time to apply all of the necessary bugfixes before the release.)
One of the best computer-based documentation systems I ever saw on a computer was Norton Guides. Context-sensitive, pop-up as needed, easily-browsed, navigation was far saner than info. It was little-known when it was around, and died from attention starvation. I've seen nothing comparable for Unix - or, indeed, for any other OS.
For directories, don't forget that many shells support some form of directory stacking - eg: push, pop in BASH.
I think more are surprised that the tab completion enhancements package for BASH haven't been updated in years.
The card hardware doesn't, but the kernel driver API has been. Routinely. I pity the poor people who have to use unmaintained drivers on a version of the kernel that has subsequently-filled security holes and/or performance fixes. Also, I suspect for something like fieldbus or VME, where you're likely talking about high-end scientific or engineering uses, the user is likely to want to be able to use more modern CPUs which may or may not be correctly supported on antique kernels.
That's true, but Linux isn't where it could - or should - be. There are many antique 3rd part drivers for Linux for embedded devices and busses (COMEDI doesn't get updated often, DDC's Linux drivers for $1000+ aviation buses haven't been updated in years, VME drivers are equally badly maintained), where comparable drivers for Windows are nice, shiny and up-to-date... even though you know damn well that's not where the market is. It seems to me that some hardware vendors release Windows drivers because they know it'll look good to PHBs, but neglect Linux drivers because they don't give a rat's ass whether the hardware is usable or not after it's out the door.
In order to be applicable to Dark Matter theories, the particle would need to be traveling at near light-speed for the lifetime to be long enough to matter. But if it's traveling that fast, the mass would have changed and no longer fit the theory. However, if the relative velocity is low enough for the mass to be right, it simply isn't going to last long enough to have any impact.
Besides which, I suspect further discoveries in cosmology will reduce - and eventually eliminate - any need for dark matter. Galaxy formation already got something of a re-write not too long ago, and it was galaxy formation that was one of the areas that "needed" dark matter to explain. Grabity - err, gravity - didn't seem to be sufficient in the earlier models. Other models, such as the forming of particles and any biases that might apply, have also been modified. We also know more about the distribution of new stars in a galaxy than we did back then. One can assume the dark matter theorists have redone the calculations to see how all of these different effects alter the models, but when was the last time you saw an article on such a recalculation?
Needless to say, I do not believe in dark matter. I'm willing to be convinced, if it can be shown that all these adjustments are asymptotic to values that still cannot describe what we observe to be true, or if this "dark matter" can be observed in the laboratory. But until then, it seems prudent to be skeptical once you know that the calculations used to predict dark matter were incorrect and there is no clear-cut evidence of recalculations being done with better data.
Portals == Demons and Chuloid Creatures that Should Not Be == Halloween Material.
I have a simple proof of such a knot, but the margin contains too few shoelaces to contain it.
PS: When asked to pull yourself up by your bootlaces, you can now ask for the Jones Polynomial required to do this.
...abbreviate cutting-and-pasting the first paragraph of the article as the Slashdot article to !summary.
Quantum crypto is breakable, the only benefit is that you can tell what packets are sniffed. So, if you only use unsniffed packets, you're guaranteed nobody else has those - at least at that time. You can't guarantee it for later on, at least to the same degree of certainty, but you can produce a reasonable level of trust. An A1-class OS with tamper-resistant hardware and strong authentication should put the cost of getting to the key above most infiltrators. Not all, and the greatest vulnerability is still going to be social engineering attacks against those authorized to have access, but it's as close to "good enough" as you're going to see in your lifetime.
The idea of using quantum cryptography for the actual data is BAD. Nonononono. It doesn't protect the data any better, all it does is identifies if it has been looked at. So, using it for data simply allows you to know when others have stolen your secrets, it doesn't stop them from doing the stealing.
The "perfect" encryption system (one that is totally unbreakable) will only exist once computer-brain interfaces move into the Neuromancer realm. Perfect? Yes. Same idea as before, for the one-time pad, but deliver the key and data to the subconcious. Then the person can act on the information without actually knowing they know it. This eliminates any form of social engineering and thus the only remaining weak point. It is also well beyond anything that will exist for a long long time, so will remain theoretical only. Nonetheless, as a theoretical concept, it does establish a method by which an unbreakable system could exist without violating any known physical or mathematical laws.
(a) this is Slashdot, and (b) this is Halloween. How on Earth do you expect to find a sensible summary given a juxtaposition like that?
It struck me that there was a similarity between the timing of the portals and the distance, too. Now, we know of other planets in the solar system with a strong magnetosphere, so in addition to your suggestions, I'd also ask if NASA is looking to see if similar corridors exist for other planets and whether there is any similar correlation between their portals and distance.
One could look at this in one of two ways. The first way is the line taken by the summary writer, that it's doom, gloom and disaster. In practice, this is actually the most likely scenario, as the alternative I'm going to suggest has never been seriously adopted by software vendors yet.
And now for that alternative! Writing code correctly. (Ooooh, scary! Just right for Halloween.) Correct code does not mean "correct according to Microsoft's preferred style", it means "abstracted out, so you don't give a damn about the underlying architecture" with "vendor-specific and platform-specific details encapsulated and hidden by portability libraries and high-level languages". If you write code that will run just equally well on a Cray 2, PC compatible, Apple, SGI Indigo or a microprocessor-controlled toaster, you can afford to simply not care what Microsoft does. The portability library(s), which might be any combination of cross-platform Open Source or Commercial libraries for common stuff, provides almost total immunity from Microsoft API changes, gives you (next to) zero upgrade costs (the "actual" costs are distributed across all of the vendors tied to the library at the time AND in future) and minimizes the risks (the minimum amount of 3rd party code is changed per API change and the maximum number of arcs are tested because everyone linking into the code becomes a QA).
Since the only practical method of maintaining such a model at the pace at which Microsoft breaks^H^H^H^H^H^Hchanges things is Open Source, it will force an increase in the adoption of Open Source methods and Open Source tools. At which point, Microsoft becomes a rather expensive bit-player in the operation, in comparison to alternative clouds. Since portability libraries eliminate lock-in, as well as upgrade headaches, companies would start going with the cheaper option.
This isn't going to happen, of course. Although the tie-in with Microsoft is harming vendors, creating excess overhead and reducing reliability, PHBs won't see it that way. All they will see is that lock-in means you can Blame Somebody Else. You can't sue them, you almost certainly can't even get them to honour their service agreements or any other contracts, but so what? Having Someone Else To Blame is the cornerstone of office politics. Good decisions are not. It doesn't matter if the company sinks as a result, since the notion of "company loyalty" is seen as something "old-fashioned" and inconsequential in today's environment. You go in, you get your paycheck, you eventually move on. It's expected. So why should a manager, who has no interest beyond looking good to other managers, care about good decisions? It won't earn them any more money, it won't get them any more respect, it won't give them a promotion, and it leaves them vulnerable to back-stabbing from other managers.
You cannot break it in a train, you cannot break it in a plane, you cannot break it here or there, you cannot break it anywhere. You cannot break *fish and ham, you cannot break it Sam-I-Am. (Hmmmm.... *fish would be a cool name for the next algorithm in that family...)
A one-time pad is pretty damn uncrackable, so long as the pad can be transferred without being intercepted, and quantum cryptography guarantees a message cannot be intercepted without you knowing. Thus, delivering one-time pads by quantum cryptography and then encrypting at most one message with that pad guarantees that the encryption cannot be broken. Well, unless the machine the pad is stored on is itself broken into, but you'd be stupid to provide an OTP keystore with Internet access or the root password on a sticky note on the monitor.
Let's take a fairly fundamental piece of software in science - the maths library. This needs to be able to do various transforms, perform linear algebra, perform matrix algebra and so on. And this needs to be done fast over a distributed system. Many of the same mathematical routines can be found in pure sound/music synthesis, 3D image manipulation and projection, audio/video codecs, and so on. Distributing code/data across multiple nodes isn't that different from distributing across multiple cores, except the cores only have a single processor cache. Some of the maths, therefore, directly applies to the multimedia sector, the commercial production of synthesizers, the improvement in digital decoders for television, and the games market.
What about more esoteric stuff? Is there any value in the public sector with NASA's open-source hypersonic computational fluid dynamics software? Or Colorado School of Mines' package on seismic data analysis? The first of those - well, it might improve the design of flight simulators, maybe. The other is basically a package for analyzing signals based on timing - very helpful for anyone working with ground-penetrating RADAR. Several other packages for signals processing exist - many sponsored by the Government, including VSIPL - which could be extremely handy for anyone working with software radio, speech recognition, or other projects (hobbyist and commercial) that need signal processing software that is both rigorously correct and fast.
FCC-compliant software for handling the ARINC bus protocols is probably not -that- valuable, but even there, there are enough amateur groups and enthusiasts who maintain historic aircraft that I would be wary of saying this would "never" be useful. Commercial components eventually get discontinued and such groups use whatever resources they can (including cannibalizing wrecks) to build their own replacement parts. That isn't true of modern electronic flight systems and the data buses they use - for now. But it's possible to imagine that such software would eventually be in demand.
You can't play chords on an ouija board.
Not sure about meaningless - it says ensembles can play chords that either don't exist or cannot be reached on a single instrument. That's quite an interesting observation that has a practical application.