He probably knew about it, at least at the time, because the piano work was mentioned by John Peel prior to them playing on his show. (It's on the BBC recordings they released as a double CD some time back.)
...the Renaissance relied heavily on such donations from sponsors. People like Leonardo da Vinci simply could not have operated without them. This is a valid model to work with, as history has unquestionably shown, but it's unstable if the rich and powerful get unseated, as happens when the economy collapses.
The other option is to have a public sector Open Source laboratory, funded through the tax system. Americans hate taxes, though, even in those cases where the alternative costs them more, gives them less freedom and has less accountability. It would mean convincing a lot of skeptical (possibly paranoid) people that the Government was capable of running such a facility in a mature and intelligent fashion, and that it would do some good. A "National Institute for Open Source" (NIOS) might not even require taxes to be raised - I imagine the costs for such a place would be well below the variations in the price-tag for NIST, NIH, NSF and related organizations already in the public sector. And even if it did involve raising taxes, how much does it take to have a few dozen people on workstations covering the full scope of supported hardware? Adding a 0.1% raise to the uppermost tax bracket that nobody on this site even comes close to would more than cover such a facility, and frankly the amount they'd "lose" would probably be less than they amount they lose behind the sofa or pay on designer shoes in a given week. In other words, they'd either not notice or not care.
Remember, this NIOS doesn't have to be big or sophisticated. A handful of people who are skilled coders and skilled QAers testing and debugging software deemed "critical" for Government users (the Linux and *BSD kernels, for example, along with GCC, Glibc, and a selection of fundamental tools and libraries) on all hardware the Government users deemed "important" (which is everything Linux runs on, other than perhaps the Vax, but given that they hold onto old hardware...) and you've covered everything a NIOS would need to do. It wouldn't be a distribution, it wouldn't favour any particular system or technology and it wouldn't be concerned with mainstream applications. Applications are the affairs of vendors. Governments should only be concerned with ensuring the foundations are correct and solid.
Of course, everyone has a different idea of what a NIOS would do. My vision won't necessarily be the same as other people's, but I do feel that my vision would be doable, cost-effective, genuinely justifiable as being in the national interest and sufficiently outside of the scope of competing with the private sector that nobody would feel threatened or believe that the competition they were facing was getting an unfair advantage. Microsoft has reused Open Source code in the past - network stacks from BSD, Kerberos for security, NCSA's webserver for part of IIS, etc. Other vendors doubtless do the same. Having a dedicated facility for debugging such code therefore IMPROVES the position of the vendors out there, as they can then focus on genuine added value, rather than duplicating all the QA and refactoring work. It would eliminate part of the common denominator that was unnecessary, wasteful and not really getting done anyway (as demonstrated by all the bugs in Microsoft products).
People will complain about my idea, probably throwing in words like "socialism" in the process, but this isn't a proposal for an actual Government department. Aside from the fact that I don't have the means to set one up even if I wanted to, I am much more interested in hearing how this idea could itself be bugfixed to make it viable, or in hearing alternative ideas that people might come up with once they stop thinking about the idiotic ways Governments have screwed things up and start thinking about what a centralized facility could do in principle when it has the freedom to pursue what it likes without sponsors to answer to.
Occasionally see this in the private sector? We OFTEN see this in the private sector. With or without competition. The problem is not lack of competition - the NASA bosses are competing with each other, which is 99% of the problem - but knowing when to compete, when to cooperate and when to simply go after mutually orthogonal goals and get out of each other's way. When you compete, you create overhead as well as incentive. The "wrong" sort of competition creates more overhead than incentive, causing everyone to lose. Nor do you need to fight against others to create the adversity which spawns creativity. It's sometimes the easiest way to create adversity, but it isn't essential. Often, a "good" problem is adversity enough. Unfortunately, society is geared to avoiding problems, not facing them, which gives you inertia and impedance. Artificially forcing society to have problems, as opposed to simply changing society to delight in their solving, creates yet more overhead and also engenders mistrust and resentment within society. This resentment will eventually poison any line of development, whether Governmental or private sector. The "you either win or you're a failure" mindset either creates a Japanese-style mania/suicide mentality or a "let's declare everyone a winner" modern American mentality. Neither is helpful and you don't need either if you don't think in those very limited terms.
It would be trivial to have a pseudo directory tree (Linux already uses them for/proc and/sys) which allows you to see any regular filesystem via whatever view you felt like having. A series of meta-tags can be represented by a graph (not a tree, since there are multiple paths to the same point) of directories, one directory per tag, of those tags you specifically want to look for, provided there is a complete graph of all tags stored on the filesystem. Instead of using user-provided tags, have a self-organizing network or an expert system shell generate the tags for you. Or have some combination thereof.
To extend this concept to work with networked filesystems such as NFS and Lustre, you want something that caches the way SQUID does and CODA was supposed to, with the capability of remote systems flagging a page in a file as dirty in much the same way ccNUMA does. To get scalability, just use NORM or one of the other scalable reliable multicast protocols. In terms of web content, you're talking nothing more complex than the 80s idea of PUSH. The ideas are already there, but have never been brought together in the way required or to the level required. But they could.
I posted a slightly longer version of this on Mark Shuttleworth's blog, but it was flagged as spam by some nannybot he bought that itself is clearly in need of an urgent re-write. Yeesh. The ugliness of the software currently out there horrifies me. The fact that I'm currently employed to write work-arounds for botched-up business software (and the fact that it's cheaper TO have someone fulltime to de-munge the output commercial software than buy something else) just illustrates to me how bad things currently are. There's an old saying that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization. I regret to say that this saying is wrong. Based on my current experience, the first air movement from said woodpecker's wings would have destroyed civilization long before the woodpecker got there.
It's not from a shortage of software that COULD be in Ubuntu (or Debian), and it's not from a shortage of updates available that supply lots of goodies not in the versions provided. I've often wondered about either running a repository for Linux software or even setting up my own distro, but the latter seems unnecessary given the number of distros out there, and the former is only going to be any good if I fork out a fair bit for space on a provider. I was actively considering that prior to the economic collapse, but right now I have neither the time nor the money to do a decent job of such a repository. Even when it was under consideration, the sort of scale I was thinking of was really beyond anything one person could do, I'd have needed help. Maybe when things improve, I might be able to tempt some fellow Slashdotters into jointly running a decent-sized repo. (By decent-sized, I mean something that satisfies a reasonable subset of the cravings of specialist users of Linux, such as astronomers, mathematicians, physicists, gamers and software developers outside of the C/C++/Java cabal.)
On the one hand, you've cloud computing resources, which supply minimal information, some source but a LOT of buzzwords, versus distributed computing versus grid computing, where there's a lot more information on what is (and is not) provided, and a lot more code is there. Ultimately, the best way to tell if something is worthwhile is to see if the provider thinks it's worthwhile. Cloud providers don't think it worthwhile to do for profit the work grid providers do for free, ergo cloud providers don't rate their own service highly. If they don't, why should anyone else?
Talking of Thrust SSC, the engineers noted afterwards that if the car had gone even marginally faster, it would have been utterly destroyed. During the practice runs, they also had the downforce too great, causing the car to gouge massive tracks in the desert. This car will be traveling 300 mph faster, giving them far far less margin for error. With a vertical layout, rather than the horizontal arrangement of engines used for Thrust SSC, their ability to use what past data exists is also greatly reduced.
I wonder if any aerodynamics guru can answer something for me - given that the shockwave was one of the biggest problems, why are they using a tubular design? Wouldn't something closer to a waverider be better, since that should experience far less stress? (I would have also thought it would experience a more controllable and predictable amount of turbulence, which should give them a better chance of reaching or exceeding their target speed.) I'm basing this partly on claims that waveriders can go a hell of a lot faster than tubular aircraft, but also on claims that they'd be more fuel-efficient as well, fuel consumption being a function of air resistance where some air resistance is necessary to supply lift and anything in excess of that is presumably just burning fuel for no gain. Since these guys are experts (Breedlove, in comparison, only managed to build a car that did spectacular roll-and-burn shows) they picked this design for a reason and we can assume it's a very good reason, but it's not a reason that is obvious to me. They can't be going by "that's the way it has always been done" or "that's the design for which we have the most data", because nobody has gone this fast in a car and the changes mean the data they do have isn't truly applicable. Besides, as already noted, Thrust SSC's design almost destroyed itself.
The whooooooooshing sound is the point of "minus any of the group" going over your head at hypersonic velocity. (I would have said White Noise, but (a) almost nobody has heard of them, apart from fans of arcane Doctor Who trivia, and (b) I'd have to miss out the bit of excluding the band.)
Silicon for electronics has additional requirements. It isn't simply that it has to be ultra-pure for the element, but it also needs to be ultra-pure for the specific isotope. Further, there have to be minimal flaws in the crystalline structure across the entire wafer for any reason whatsoever. That gets complicated when you consider that modern chip making uses all kinds of techniques for doping, stressing and god-knows-what-elsing to improve performance, though there are other factors. If pharmaceuticals can be improved in microgravity, where the smallest unit you care about is an entire complex molecule, a process that is sensitive to the displacement of single atoms is necessarily going to be much more sensitive to any issues full Earth gravity is going to throw into the mix. (I'm not saying that that's a real problem, only that if the oft-quoted case for pharmaceuticals is true, it must be hundreds if not thousands of times more so for wafer production.)
The way silicon wafer production tends to work is to assume a moderate rejection rate. Chip makers test the chips and if they fail QA may simply be re-stamped at a lower grade. The best-known example of this was the early production of the 486SX and the 487, which were just 486DXes in which either the main CPU or the coprocessor had failed in testing. Those from Britain may also be familiar with Sir Clive Sinclair buying rejected chips on the grounds that most rejects for industrial use were perfectly acceptable for home use, and the cost of replacing was still cheaper than buying the better quality chips.
Now that I completely agree with. Diagnostics and data analysis via the patterns inherent in sound makes a lot of sense - the human brain is designed to do pattern recognition in raw data for starters and computers could theoretically do pattern recognition for large volumes (no pun intended) of data far more efficiently this way because you are dealing with the information holistically rather than as a serial stream. You can also identify subtle differences in stars by means of sound - a subtle variation that might not be detectable otherwise might easily set up a very audible beat frequency when compared to a reference star. For that matter, if you know two stars to be functionally identical, then the interference pattern when overlaying the two sounds is going to be a function of velocity. As interference patterns will tend to make visible to humans information that is otherwise hidden in the general noise, this should allow you to determine differences in distances that are far too subtle to pick up otherwise.
Actually, now that I think about it, if there is a planet orbiting a star, the star wobbles. But there have been problems in the past in determining when the wobble is real and when it is simply an illusion. This might be a case where the sound from the star differs enough in the two cases (wobble = change in relative velocity = change in sound = change in the beat frequency relative to a reference star with no planetary mass, the illusion will change nothing) where you could identify which case it was with much greater confidence. In some cases, you may be able to detect a wobble via sound that would not be visible by direct measurement, exposing the existence of an orbiting mass that would not otherwise be detected.
Old fighters, sure. After a certain period of time of disuse, warbirds become available for civilians - usually sans armament. However, something still in use in the 1980s seems... very modern to have been released into civilian hands. However, released it has been. There seems to be no question of that. Getting spare parts - ah, now that's another matter. Since such planes are only released long after any serious production has ceased, both the parts and the expertise to make them correctly will be in very short supply. This is not a trivial matter. The last flying Mosquito crashed because a replacement carburetor for one of the engines failed during an aerobatics display, and component failures that would simply not have happened under any kind of meaningful quality assurance are nowhere near as uncommon as they aught to be.
That is a fairly poor way of generating a seed. I don't claim to be an expert on encryption (but you can call me one if you like), but I would use one of several different approaches, depending on the situation and the compute power available.
One option would be to assume that the two images are a pair of asymmetric keys, given some shared asymmetric encryption function which is derived once the two images are uploaded. It doesn't matter, then, if either image (but not both) falls into the hands of someone wanting to break the encryption - without knowing the function used, having what is effectively a private key for one side of the communication won't help.
A second option is to just use them as seeds for generating key pairs and instead of trading images, use an established method for key exchange to copy the keys across.
Thirdly, you could generate completely random key pairs, then use the photographs as part of the encryption mode between blocks. (This would go back to needing the photographs shared, but even if both photographs were obtained by someone, it wouldn't help them much in decrypting any message.)
Fourthly, you could generate a digital signature, where the signature assumes the image is appended to the message, with the signature as the first part of the encrypted message. This adds a little to the authentication, but also as the signature is non-deterministic, it makes those decryption techniques which involve some sort of pattern analysis of the encrypted data much less useful - you don't know where the text starts.
Next, you could use different slices of the images to pre-generate different keypairs. You could then specify a key by specifying the offset into the image. A variant of that is to pre-generate keys randomly and use the image content at a given offset as a pointer into the key table.
Lastly, you could prepend the message with the image, use a compression algorithm and then encrypt the compressed data. The reason for compressing is that it hides patterns in the data still visible when encrypted. By prepending the image, you absolutely drown out any possibility of residual information that could be used.
I'd look at it slightly differently. A manned mission to Mars is inevitable. Eventually. But to be useful, those who go need to have adequate resources. So, some percentage of robot missions should carry significant extra cargo to support the eventual manned mission. This covers the need for more robots and brings a manned mission into the realms of something that could do useful work, stay active for an adequate length of time, and be safe against the known hazards on Mars. If it's done well enough, the manned mission could be scheduled as indefinite in duration, with additional supplies shipped up as needed. The "ideal" would be to have some of the robotic missions NOT be exploratory but construction. If you can get a Biosphere II up and running on Mars, bearing in mind you need it 2-3 times the size of the Biosphere II built on Earth to be stable, you could sensibly talk about people staying on Mars indefinitely/permanently. Given the difficulty of that level of construction, this sort of scheme would require decades of preparatory work before a manned mission and wouldn't be cheap or easy. However, it meets the needs of robotic missions and it meets the resource requirements for a manned mission to be genuinely successful and not just a there-and-back-again stunt for showing off.
You are correct that speed and size age generally incompatible. There are two possible alternatives to solve this. The first, which I suggested here, is to optimize for size and then place at a lower level in the system (software migrates to hardware, data migrates to software). This gives you a system that is fast because it is compact enough TO place in hardware. The second option is to optimize for speed, rather than size. Because everything is as close to linear as possible, it would be impractical to place in hardware, but you don't need to because it's already fast. Because macros don't impinge on speed (when you compile you get the same near-linear code), you can then run a source optimizer over the code. Because it is totally broken down into a very very large number of the simplest possible steps, it is possible for even a fairly naive optimizer to macro-ize the code into something extremely compact, as you know EXACTLY where each and every re-use of code takes place. It's not hidden by differently phrasing the same logic.
My use of "space per unit of functionality" could equally well be written as "speed per unit of functionality" - for a given architecture and language, a given set of capabilities can be expressed in many ways, some more optimal than others. As you add functionality, the probability of reusing code you already have increases. If you then go through a round of refactoring, you can increase that probability further. Then, if you optimize for space, you add arcs (at negligible cost in space) and add data (to drive the code through the correct arcs). At the limit, you have an engine that performs the core operations and everything else is done by emulating the more complex stuff via data, the same way you can do CISC-like work on RISC architectures through software emulating the instructions you need.
Now, what happens when you want to optimize for speed, rather than space? CISC is slower than RISC, even though everything is spelled out in full, because determining what it is you are trying to do becomes more expensive than whatever it is you're doing. To solve this, CISC chip makers went to a hybrid architecture, where you've a RISC base and a CISC layer for anything that would be too slow in pure software. In software, a completely flat program will also not be able to make good use of the L1 and L2 caches. Thus, to finish the optimization on speed, you will also end up with a hybrid system - one that uses just enough structure to efficiently use the caches but not so much that it becomes too slow. However, the source only sees this to the extent that you denote what stays folded in the binary and what is fully inlined.
They do mean 100 times colder! By being below absolute zero, distances and therefore time becomes negative. With sufficient negativity, they can produce a Pentium that'll give you the wrong answer before you provide it with the data!
If you've hand-turned the code into its most reduced state, such that not so much as a single opcode can be taken out without reducing the problem-space the program can handle, you by definition have the least number of points at which a vulnerability can occur. Since all further logic is data-based, not code-based, you can stop there as you can debug the code via data. This could be done the same way Intel used downloadable microcode, or it could be done by compensating for the flaw at the data level.
Alternatively, if you define security as part of the problem-space, then all code which has the potential of offering a vulnerability is placed in what is known as a "security kernel". This is usually simple enough that you can actually prove it correct, at which point it is irrelevant as to whether there are any bugs elsewhere, they can't lead to security holes. This is how B3 and A1 general-purpose operating systems are written. They don't need to prove the correctness of any part outside of that self-contained unit. At this point, there are no vulnerabilities to worry about. Possibly bugs, but again you can work around those, so long as there's nothing major out there. A hard drive is only under warranty for 5 years, so you only have to be at the point where you've a low probability of needing to do a bugfix release that can't be entirely in data within that timeframe. (If it can be done in data, it's a firmware update or a microcode update and you don't give a damn.)
At the limit, the code is already optimized. Otherwise, you could still perform hand optimizations, producing code that is smaller and at least as functional, possibly more so. (When you abstract out a unit of code to reduce space, you add the potential to refer to that unit of code from anywhere that it is in scope of. Often this won't be useful, so the code is only smaller. It hasn't lost any functionality, though. Sometimes, however, it is handy, resulting in code that is both smaller and more functional.)
At the very limit, by definition any reduction in the code will lead to a loss of functionality, and any transformation you apply that retains or expands functionality must lead to an increase in code size. In practice, very few "real world" programs will ever reach that limit, so in any "real world" scenario an optimizing compiler will GENERALLY be able to get you closer to that limit. But there is no compiler or programmer in the world that can ever pass that limit, given the parameters that make up that limit. Compilers may be smarter than humans in some regards about how to get closer to that lower bound, and humans may be smarter than compilers in other regards, but there will always be a totally reduced form of a given program on a given architecture. There may be more than one, but they will be identical in size, since that's how the problem is defined.
Yes, but it can go down with optimizations and refactoring (finding duplicated code and pushing it into a function or macro, for example) and with eliminating dead code. Ideally, code size should be asymptotic to an optimal size. As you approach the optimal size, more and more of what you need to do is already available to you. As you approach the limit, the amount of special-case logic and hardcoding approaches zero, and the amount of data-driven logic approaches 100%. Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs. Simulating a computer is always going to be slower than actually using the real computer directly. In most cases, this is considered "acceptable" because your virtual machine is simply too advanced for any physical hardware to support at this time. (There is also the consideration of code changes, but as you approach the limit, your changes will largely be to the data and not to the codebase. At the limit, you will change the codebase only when changing the hardware, so if you could hardwire the code, it would not impact maintenance at all. All the maintenance you could want to do would be at the data level, given this level of abstraction.)
Linux is clearly nowhere near the point of being that abstract, although some components are probably getting close. It would be interesting to see, even if it could only be done by simulation, what would happen if you moved Linux' VMM into an enlarged MMU, or what would happen if an intelligent hard drive supported Linux' current filesystem selection and parts of the VFS layer. Not as software running on a CPU, but as actual hard-wired logic. Software is just a simulation of wiring, so you can logically always reverse the process. Given that Linux has a decent chunk of the server market, and the server market is less concerned with cost as it is with high performance, high reliability and minimal physical space, it is possible (unlikely but possible) that there will eventually be lines of servers that use chips specially designed to accelerate Linux by this method.
Exactly right. Ethernet won't scale up in speed, but there are already some Infiniband cards out there that'll go as high as 60 Gb/s, with no obvious limits to how fast the data can travel. Current 10 Gb Ethernet is about the fastest Ethernet will go, all attempts at going faster have slapped 10 Gb Ethernet pipes in parallel, which reduces distance still further to prevent stagger. Infiniband is going the other direction, with WAN-based Infiniband products being boasted about by vendors. When you start talking stacks of terabyte drives and extreme-end servers (and the limitations of multiple T3 lines), the idea of a single unified network connection that can handle the throughput becomes attractive.
Also bear in mind that clustered databases, such as Oracle RAC, are no longer being designed with Ethernet in mind. The extra performance is squeezed out of the higher bandwidths but also out of features such as RDMA and network offloading. You can do this with Ethernet, sure - Ethernet iWARP and TCP offloading do exist, but can you name me any STANDARD server boxes that support both of these? Data centres don't want to rip open the boxes, invalidate their (fictional) warranty, and install all-new Ethernet cards which may or may not have drivers for their specific OS.
I don't believe Infiniband is the be-all and end-all - it is merely better than Ethernet as it exists today. Of course, that was also true of the micro-channel architecture and EISA, neither of which got seriously adopted before PCI replaced everything that had gone on before. The question is not whether Infiniband is superior to "smart" Ethernet, the question is whether either of these corresponds to PCI or to one of the failed bus standards. My guess is that "smart" Ethernet corresponds to EISA, but I am undecided as to whether Infiniband is MCA or PCI. If the former, then expect a new LAN technology to emerge when the existing standards simply cannot meet market requirements.
Slashdot Mirror
He probably knew about it, at least at the time, because the piano work was mentioned by John Peel prior to them playing on his show. (It's on the BBC recordings they released as a double CD some time back.)
...the Renaissance relied heavily on such donations from sponsors. People like Leonardo da Vinci simply could not have operated without them. This is a valid model to work with, as history has unquestionably shown, but it's unstable if the rich and powerful get unseated, as happens when the economy collapses.
The other option is to have a public sector Open Source laboratory, funded through the tax system. Americans hate taxes, though, even in those cases where the alternative costs them more, gives them less freedom and has less accountability. It would mean convincing a lot of skeptical (possibly paranoid) people that the Government was capable of running such a facility in a mature and intelligent fashion, and that it would do some good. A "National Institute for Open Source" (NIOS) might not even require taxes to be raised - I imagine the costs for such a place would be well below the variations in the price-tag for NIST, NIH, NSF and related organizations already in the public sector. And even if it did involve raising taxes, how much does it take to have a few dozen people on workstations covering the full scope of supported hardware? Adding a 0.1% raise to the uppermost tax bracket that nobody on this site even comes close to would more than cover such a facility, and frankly the amount they'd "lose" would probably be less than they amount they lose behind the sofa or pay on designer shoes in a given week. In other words, they'd either not notice or not care.
Remember, this NIOS doesn't have to be big or sophisticated. A handful of people who are skilled coders and skilled QAers testing and debugging software deemed "critical" for Government users (the Linux and *BSD kernels, for example, along with GCC, Glibc, and a selection of fundamental tools and libraries) on all hardware the Government users deemed "important" (which is everything Linux runs on, other than perhaps the Vax, but given that they hold onto old hardware...) and you've covered everything a NIOS would need to do. It wouldn't be a distribution, it wouldn't favour any particular system or technology and it wouldn't be concerned with mainstream applications. Applications are the affairs of vendors. Governments should only be concerned with ensuring the foundations are correct and solid.
Of course, everyone has a different idea of what a NIOS would do. My vision won't necessarily be the same as other people's, but I do feel that my vision would be doable, cost-effective, genuinely justifiable as being in the national interest and sufficiently outside of the scope of competing with the private sector that nobody would feel threatened or believe that the competition they were facing was getting an unfair advantage. Microsoft has reused Open Source code in the past - network stacks from BSD, Kerberos for security, NCSA's webserver for part of IIS, etc. Other vendors doubtless do the same. Having a dedicated facility for debugging such code therefore IMPROVES the position of the vendors out there, as they can then focus on genuine added value, rather than duplicating all the QA and refactoring work. It would eliminate part of the common denominator that was unnecessary, wasteful and not really getting done anyway (as demonstrated by all the bugs in Microsoft products).
People will complain about my idea, probably throwing in words like "socialism" in the process, but this isn't a proposal for an actual Government department. Aside from the fact that I don't have the means to set one up even if I wanted to, I am much more interested in hearing how this idea could itself be bugfixed to make it viable, or in hearing alternative ideas that people might come up with once they stop thinking about the idiotic ways Governments have screwed things up and start thinking about what a centralized facility could do in principle when it has the freedom to pursue what it likes without sponsors to answer to.
Secret prisons are a crime! Free the Motorola 68000!
Occasionally see this in the private sector? We OFTEN see this in the private sector. With or without competition. The problem is not lack of competition - the NASA bosses are competing with each other, which is 99% of the problem - but knowing when to compete, when to cooperate and when to simply go after mutually orthogonal goals and get out of each other's way. When you compete, you create overhead as well as incentive. The "wrong" sort of competition creates more overhead than incentive, causing everyone to lose. Nor do you need to fight against others to create the adversity which spawns creativity. It's sometimes the easiest way to create adversity, but it isn't essential. Often, a "good" problem is adversity enough. Unfortunately, society is geared to avoiding problems, not facing them, which gives you inertia and impedance. Artificially forcing society to have problems, as opposed to simply changing society to delight in their solving, creates yet more overhead and also engenders mistrust and resentment within society. This resentment will eventually poison any line of development, whether Governmental or private sector. The "you either win or you're a failure" mindset either creates a Japanese-style mania/suicide mentality or a "let's declare everyone a winner" modern American mentality. Neither is helpful and you don't need either if you don't think in those very limited terms.
It would be trivial to have a pseudo directory tree (Linux already uses them for /proc and /sys) which allows you to see any regular filesystem via whatever view you felt like having. A series of meta-tags can be represented by a graph (not a tree, since there are multiple paths to the same point) of directories, one directory per tag, of those tags you specifically want to look for, provided there is a complete graph of all tags stored on the filesystem. Instead of using user-provided tags, have a self-organizing network or an expert system shell generate the tags for you. Or have some combination thereof.
To extend this concept to work with networked filesystems such as NFS and Lustre, you want something that caches the way SQUID does and CODA was supposed to, with the capability of remote systems flagging a page in a file as dirty in much the same way ccNUMA does. To get scalability, just use NORM or one of the other scalable reliable multicast protocols. In terms of web content, you're talking nothing more complex than the 80s idea of PUSH. The ideas are already there, but have never been brought together in the way required or to the level required. But they could.
I posted a slightly longer version of this on Mark Shuttleworth's blog, but it was flagged as spam by some nannybot he bought that itself is clearly in need of an urgent re-write. Yeesh. The ugliness of the software currently out there horrifies me. The fact that I'm currently employed to write work-arounds for botched-up business software (and the fact that it's cheaper TO have someone fulltime to de-munge the output commercial software than buy something else) just illustrates to me how bad things currently are. There's an old saying that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization. I regret to say that this saying is wrong. Based on my current experience, the first air movement from said woodpecker's wings would have destroyed civilization long before the woodpecker got there.
It's not from a shortage of software that COULD be in Ubuntu (or Debian), and it's not from a shortage of updates available that supply lots of goodies not in the versions provided. I've often wondered about either running a repository for Linux software or even setting up my own distro, but the latter seems unnecessary given the number of distros out there, and the former is only going to be any good if I fork out a fair bit for space on a provider. I was actively considering that prior to the economic collapse, but right now I have neither the time nor the money to do a decent job of such a repository. Even when it was under consideration, the sort of scale I was thinking of was really beyond anything one person could do, I'd have needed help. Maybe when things improve, I might be able to tempt some fellow Slashdotters into jointly running a decent-sized repo. (By decent-sized, I mean something that satisfies a reasonable subset of the cravings of specialist users of Linux, such as astronomers, mathematicians, physicists, gamers and software developers outside of the C/C++/Java cabal.)
On the one hand, you've cloud computing resources, which supply minimal information, some source but a LOT of buzzwords, versus distributed computing versus grid computing, where there's a lot more information on what is (and is not) provided, and a lot more code is there. Ultimately, the best way to tell if something is worthwhile is to see if the provider thinks it's worthwhile. Cloud providers don't think it worthwhile to do for profit the work grid providers do for free, ergo cloud providers don't rate their own service highly. If they don't, why should anyone else?
Talking of Thrust SSC, the engineers noted afterwards that if the car had gone even marginally faster, it would have been utterly destroyed. During the practice runs, they also had the downforce too great, causing the car to gouge massive tracks in the desert. This car will be traveling 300 mph faster, giving them far far less margin for error. With a vertical layout, rather than the horizontal arrangement of engines used for Thrust SSC, their ability to use what past data exists is also greatly reduced.
I wonder if any aerodynamics guru can answer something for me - given that the shockwave was one of the biggest problems, why are they using a tubular design? Wouldn't something closer to a waverider be better, since that should experience far less stress? (I would have also thought it would experience a more controllable and predictable amount of turbulence, which should give them a better chance of reaching or exceeding their target speed.) I'm basing this partly on claims that waveriders can go a hell of a lot faster than tubular aircraft, but also on claims that they'd be more fuel-efficient as well, fuel consumption being a function of air resistance where some air resistance is necessary to supply lift and anything in excess of that is presumably just burning fuel for no gain. Since these guys are experts (Breedlove, in comparison, only managed to build a car that did spectacular roll-and-burn shows) they picked this design for a reason and we can assume it's a very good reason, but it's not a reason that is obvious to me. They can't be going by "that's the way it has always been done" or "that's the design for which we have the most data", because nobody has gone this fast in a car and the changes mean the data they do have isn't truly applicable. Besides, as already noted, Thrust SSC's design almost destroyed itself.
I regret to have to inform you that whitespace can no longer be considered as inside the US for purposes of claiming rights under the constitution.
The whooooooooshing sound is the point of "minus any of the group" going over your head at hypersonic velocity. (I would have said White Noise, but (a) almost nobody has heard of them, apart from fans of arcane Doctor Who trivia, and (b) I'd have to miss out the bit of excluding the band.)
Silicon for electronics has additional requirements. It isn't simply that it has to be ultra-pure for the element, but it also needs to be ultra-pure for the specific isotope. Further, there have to be minimal flaws in the crystalline structure across the entire wafer for any reason whatsoever. That gets complicated when you consider that modern chip making uses all kinds of techniques for doping, stressing and god-knows-what-elsing to improve performance, though there are other factors. If pharmaceuticals can be improved in microgravity, where the smallest unit you care about is an entire complex molecule, a process that is sensitive to the displacement of single atoms is necessarily going to be much more sensitive to any issues full Earth gravity is going to throw into the mix. (I'm not saying that that's a real problem, only that if the oft-quoted case for pharmaceuticals is true, it must be hundreds if not thousands of times more so for wafer production.)
The way silicon wafer production tends to work is to assume a moderate rejection rate. Chip makers test the chips and if they fail QA may simply be re-stamped at a lower grade. The best-known example of this was the early production of the 486SX and the 487, which were just 486DXes in which either the main CPU or the coprocessor had failed in testing. Those from Britain may also be familiar with Sir Clive Sinclair buying rejected chips on the grounds that most rejects for industrial use were perfectly acceptable for home use, and the cost of replacing was still cheaper than buying the better quality chips.
Nucleii would be be multiple imaginary nuclei, since they're multiplied by the square root of -1.
Now that I completely agree with. Diagnostics and data analysis via the patterns inherent in sound makes a lot of sense - the human brain is designed to do pattern recognition in raw data for starters and computers could theoretically do pattern recognition for large volumes (no pun intended) of data far more efficiently this way because you are dealing with the information holistically rather than as a serial stream. You can also identify subtle differences in stars by means of sound - a subtle variation that might not be detectable otherwise might easily set up a very audible beat frequency when compared to a reference star. For that matter, if you know two stars to be functionally identical, then the interference pattern when overlaying the two sounds is going to be a function of velocity. As interference patterns will tend to make visible to humans information that is otherwise hidden in the general noise, this should allow you to determine differences in distances that are far too subtle to pick up otherwise.
Actually, now that I think about it, if there is a planet orbiting a star, the star wobbles. But there have been problems in the past in determining when the wobble is real and when it is simply an illusion. This might be a case where the sound from the star differs enough in the two cases (wobble = change in relative velocity = change in sound = change in the beat frequency relative to a reference star with no planetary mass, the illusion will change nothing) where you could identify which case it was with much greater confidence. In some cases, you may be able to detect a wobble via sound that would not be visible by direct measurement, exposing the existence of an orbiting mass that would not otherwise be detected.
Yes, this is terribly informative. Maybe it would be better to describe it as like the Art Of Noise, minus any of the group.
Old fighters, sure. After a certain period of time of disuse, warbirds become available for civilians - usually sans armament. However, something still in use in the 1980s seems... very modern to have been released into civilian hands. However, released it has been. There seems to be no question of that. Getting spare parts - ah, now that's another matter. Since such planes are only released long after any serious production has ceased, both the parts and the expertise to make them correctly will be in very short supply. This is not a trivial matter. The last flying Mosquito crashed because a replacement carburetor for one of the engines failed during an aerobatics display, and component failures that would simply not have happened under any kind of meaningful quality assurance are nowhere near as uncommon as they aught to be.
One option would be to assume that the two images are a pair of asymmetric keys, given some shared asymmetric encryption function which is derived once the two images are uploaded. It doesn't matter, then, if either image (but not both) falls into the hands of someone wanting to break the encryption - without knowing the function used, having what is effectively a private key for one side of the communication won't help.
A second option is to just use them as seeds for generating key pairs and instead of trading images, use an established method for key exchange to copy the keys across.
Thirdly, you could generate completely random key pairs, then use the photographs as part of the encryption mode between blocks. (This would go back to needing the photographs shared, but even if both photographs were obtained by someone, it wouldn't help them much in decrypting any message.)
Fourthly, you could generate a digital signature, where the signature assumes the image is appended to the message, with the signature as the first part of the encrypted message. This adds a little to the authentication, but also as the signature is non-deterministic, it makes those decryption techniques which involve some sort of pattern analysis of the encrypted data much less useful - you don't know where the text starts.
Next, you could use different slices of the images to pre-generate different keypairs. You could then specify a key by specifying the offset into the image. A variant of that is to pre-generate keys randomly and use the image content at a given offset as a pointer into the key table.
Lastly, you could prepend the message with the image, use a compression algorithm and then encrypt the compressed data. The reason for compressing is that it hides patterns in the data still visible when encrypted. By prepending the image, you absolutely drown out any possibility of residual information that could be used.
I'd look at it slightly differently. A manned mission to Mars is inevitable. Eventually. But to be useful, those who go need to have adequate resources. So, some percentage of robot missions should carry significant extra cargo to support the eventual manned mission. This covers the need for more robots and brings a manned mission into the realms of something that could do useful work, stay active for an adequate length of time, and be safe against the known hazards on Mars. If it's done well enough, the manned mission could be scheduled as indefinite in duration, with additional supplies shipped up as needed. The "ideal" would be to have some of the robotic missions NOT be exploratory but construction. If you can get a Biosphere II up and running on Mars, bearing in mind you need it 2-3 times the size of the Biosphere II built on Earth to be stable, you could sensibly talk about people staying on Mars indefinitely/permanently. Given the difficulty of that level of construction, this sort of scheme would require decades of preparatory work before a manned mission and wouldn't be cheap or easy. However, it meets the needs of robotic missions and it meets the resource requirements for a manned mission to be genuinely successful and not just a there-and-back-again stunt for showing off.
You are correct that speed and size age generally incompatible. There are two possible alternatives to solve this. The first, which I suggested here, is to optimize for size and then place at a lower level in the system (software migrates to hardware, data migrates to software). This gives you a system that is fast because it is compact enough TO place in hardware. The second option is to optimize for speed, rather than size. Because everything is as close to linear as possible, it would be impractical to place in hardware, but you don't need to because it's already fast. Because macros don't impinge on speed (when you compile you get the same near-linear code), you can then run a source optimizer over the code. Because it is totally broken down into a very very large number of the simplest possible steps, it is possible for even a fairly naive optimizer to macro-ize the code into something extremely compact, as you know EXACTLY where each and every re-use of code takes place. It's not hidden by differently phrasing the same logic.
My use of "space per unit of functionality" could equally well be written as "speed per unit of functionality" - for a given architecture and language, a given set of capabilities can be expressed in many ways, some more optimal than others. As you add functionality, the probability of reusing code you already have increases. If you then go through a round of refactoring, you can increase that probability further. Then, if you optimize for space, you add arcs (at negligible cost in space) and add data (to drive the code through the correct arcs). At the limit, you have an engine that performs the core operations and everything else is done by emulating the more complex stuff via data, the same way you can do CISC-like work on RISC architectures through software emulating the instructions you need.
Now, what happens when you want to optimize for speed, rather than space? CISC is slower than RISC, even though everything is spelled out in full, because determining what it is you are trying to do becomes more expensive than whatever it is you're doing. To solve this, CISC chip makers went to a hybrid architecture, where you've a RISC base and a CISC layer for anything that would be too slow in pure software. In software, a completely flat program will also not be able to make good use of the L1 and L2 caches. Thus, to finish the optimization on speed, you will also end up with a hybrid system - one that uses just enough structure to efficiently use the caches but not so much that it becomes too slow. However, the source only sees this to the extent that you denote what stays folded in the binary and what is fully inlined.
They do mean 100 times colder! By being below absolute zero, distances and therefore time becomes negative. With sufficient negativity, they can produce a Pentium that'll give you the wrong answer before you provide it with the data!
If you've hand-turned the code into its most reduced state, such that not so much as a single opcode can be taken out without reducing the problem-space the program can handle, you by definition have the least number of points at which a vulnerability can occur. Since all further logic is data-based, not code-based, you can stop there as you can debug the code via data. This could be done the same way Intel used downloadable microcode, or it could be done by compensating for the flaw at the data level. Alternatively, if you define security as part of the problem-space, then all code which has the potential of offering a vulnerability is placed in what is known as a "security kernel". This is usually simple enough that you can actually prove it correct, at which point it is irrelevant as to whether there are any bugs elsewhere, they can't lead to security holes. This is how B3 and A1 general-purpose operating systems are written. They don't need to prove the correctness of any part outside of that self-contained unit. At this point, there are no vulnerabilities to worry about. Possibly bugs, but again you can work around those, so long as there's nothing major out there. A hard drive is only under warranty for 5 years, so you only have to be at the point where you've a low probability of needing to do a bugfix release that can't be entirely in data within that timeframe. (If it can be done in data, it's a firmware update or a microcode update and you don't give a damn.)
At the limit, the code is already optimized. Otherwise, you could still perform hand optimizations, producing code that is smaller and at least as functional, possibly more so. (When you abstract out a unit of code to reduce space, you add the potential to refer to that unit of code from anywhere that it is in scope of. Often this won't be useful, so the code is only smaller. It hasn't lost any functionality, though. Sometimes, however, it is handy, resulting in code that is both smaller and more functional.)
At the very limit, by definition any reduction in the code will lead to a loss of functionality, and any transformation you apply that retains or expands functionality must lead to an increase in code size. In practice, very few "real world" programs will ever reach that limit, so in any "real world" scenario an optimizing compiler will GENERALLY be able to get you closer to that limit. But there is no compiler or programmer in the world that can ever pass that limit, given the parameters that make up that limit. Compilers may be smarter than humans in some regards about how to get closer to that lower bound, and humans may be smarter than compilers in other regards, but there will always be a totally reduced form of a given program on a given architecture. There may be more than one, but they will be identical in size, since that's how the problem is defined.
If you have a hamster in a glass box, with scotch tape on its back, it'll white out an airport X-Ray machine?
Yes, but it can go down with optimizations and refactoring (finding duplicated code and pushing it into a function or macro, for example) and with eliminating dead code. Ideally, code size should be asymptotic to an optimal size. As you approach the optimal size, more and more of what you need to do is already available to you. As you approach the limit, the amount of special-case logic and hardcoding approaches zero, and the amount of data-driven logic approaches 100%. Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs. Simulating a computer is always going to be slower than actually using the real computer directly. In most cases, this is considered "acceptable" because your virtual machine is simply too advanced for any physical hardware to support at this time. (There is also the consideration of code changes, but as you approach the limit, your changes will largely be to the data and not to the codebase. At the limit, you will change the codebase only when changing the hardware, so if you could hardwire the code, it would not impact maintenance at all. All the maintenance you could want to do would be at the data level, given this level of abstraction.)
Linux is clearly nowhere near the point of being that abstract, although some components are probably getting close. It would be interesting to see, even if it could only be done by simulation, what would happen if you moved Linux' VMM into an enlarged MMU, or what would happen if an intelligent hard drive supported Linux' current filesystem selection and parts of the VFS layer. Not as software running on a CPU, but as actual hard-wired logic. Software is just a simulation of wiring, so you can logically always reverse the process. Given that Linux has a decent chunk of the server market, and the server market is less concerned with cost as it is with high performance, high reliability and minimal physical space, it is possible (unlikely but possible) that there will eventually be lines of servers that use chips specially designed to accelerate Linux by this method.
0.1 was written in APL, and the remaining 0.2% was in SNOBOL.
Exactly right. Ethernet won't scale up in speed, but there are already some Infiniband cards out there that'll go as high as 60 Gb/s, with no obvious limits to how fast the data can travel. Current 10 Gb Ethernet is about the fastest Ethernet will go, all attempts at going faster have slapped 10 Gb Ethernet pipes in parallel, which reduces distance still further to prevent stagger. Infiniband is going the other direction, with WAN-based Infiniband products being boasted about by vendors. When you start talking stacks of terabyte drives and extreme-end servers (and the limitations of multiple T3 lines), the idea of a single unified network connection that can handle the throughput becomes attractive.
Also bear in mind that clustered databases, such as Oracle RAC, are no longer being designed with Ethernet in mind. The extra performance is squeezed out of the higher bandwidths but also out of features such as RDMA and network offloading. You can do this with Ethernet, sure - Ethernet iWARP and TCP offloading do exist, but can you name me any STANDARD server boxes that support both of these? Data centres don't want to rip open the boxes, invalidate their (fictional) warranty, and install all-new Ethernet cards which may or may not have drivers for their specific OS.
I don't believe Infiniband is the be-all and end-all - it is merely better than Ethernet as it exists today. Of course, that was also true of the micro-channel architecture and EISA, neither of which got seriously adopted before PCI replaced everything that had gone on before. The question is not whether Infiniband is superior to "smart" Ethernet, the question is whether either of these corresponds to PCI or to one of the failed bus standards. My guess is that "smart" Ethernet corresponds to EISA, but I am undecided as to whether Infiniband is MCA or PCI. If the former, then expect a new LAN technology to emerge when the existing standards simply cannot meet market requirements.