Oh, I agree. The Transputer was an excellent example of a distributed computer. For that matter, so was the Commodore PET (IEEE 488 printers and disk drives all had their own CPU and the main system offloaded all work to them). The Intel iWarp system-on-a-chip was another distributed architecture.
This stuff isn't new, per se, it is merely new in the sense that CPUs became so powerful that everything became hyper-centralized. Only in areas of sound and graphics have they meaningfully decentralized. Networking - well, how many TOE or RDMA engines do you use? There are plenty of Ethernet cards that support both and Linux drivers for those cards, but I'll bet fewer than one in every ten thousand Slashdotters has actually used such a card.
Well, you see, once IBM buys out Sun, Solaris is going to be re-implemented as macros in OpenOffice. Or Emacs. Whichever one they decide to pick as the new OS kernel.
Linux has supported 16-way SMP since the Xeon first came out. Debuggers and latency-monitoring tools that support multicore have existed for Linux for a long time - Intel's VTune being a commercial example, but DAKOTA and KOJAK being open-source examples.
For compilers based on trivial modifications for existing languages, Cilk++ is basically GCC's C++ with instruction-level parallelism. Those wanting something more sophisticated need look no further than OpenMP. If you prefer all-out hardcore parallelism, use KROC.
The tools are all out there. The OS provides the mechanisms. In the case of Cilk and OpenMP, the code will work just fine on a regular GCC install with no parallel support and on uniprocessor systems.
If parallel support is lacking in software, it is not lacking because of any problems in the toolchain or the kernel. It is lacking because there are too many lazy bar stewards who aim only for the lowest common denominator and ignore the needs of anything better.
The lowest common denominator should indeed not suffer and need not suffer, if code is designed well, but the current practice causes everyone else to suffer on their behalf, which is not good practice.
The Universal Remote can be programmed with the signal used in Laser Tag games and is area-effect. This allows you to blast vast areas far more effectively than the pistol they supply you with. The SmartPhone cannot do this, no matter what you do.
There's some validity to that, but remember that routing protocols designed for ad-hoc networks can be used in what is called an "over-net" to bypass these restrictions. Censored paths would be detected the same way that broken ad-hoc paths are, and simply bypassed. I imagine techniques such as TOR already use routing concepts either along these lines or (by now) more advanced.
True if Linux required it. But let's say Linux'll run on any hard drive, but the "super hard drive" will let you run a desktop or server Linux install that is much more robust.
Laptops generally have power regulation, so can flush buffers and do all other I/O in a controlled way if the main battery reaches a critical level, so I don't see any value in adding robustness that would never get utilized on such a system. Although, if it's only going to add $0.5 - $5 to a hard drive, the value of the selling point would likely see it ending up in most laptops anyway.
It's not really compensating for a defect in the software, because an ultracapacitor or battery-backed RAM will work on all filing systems, and indeed on all Operating Systems.
Even the most extreme solution I offered is nothing more than turning a local hard drive into NAS where the "network" just happens to be the internal bus. It has all the benefits of NAS (such as the queue not being corrupted when you power down the machine, not tying up the main CPU, and so on), but at a fraction of the cost (because you don't need the compute power or a whole new network + NICs).
You could also argue that it's not "adding" hardware, since all IEEE 488 (and many SCSI) hard drives used to be intelligent peripherals. Rather, all more modern hard drives are cut-down. It's like the Winmodem. Nobody argued that "full" modems were Winmodems + added hardware. Besides, a 50 cent capacitor and a torch battery are hardly extensive hardware mods.
Nor is this really a departure from current design methods. SCSI drives are forever increasing the size of the queues they support and they are already nominally intelligent peripherals. The most that could be said is that this suggestion extends the idea to ATA and SATA drives and replaces the typical absurd 16-command queue with a 32768-command queue.
This idea isn't heavyweight, like UPS. The drive would not run without mains power. Rather, the drive would retain all commands and finish off whatever it had been doing when power is restored. No need for whopping big batteries and expensive extras to keep the mechanical bits going. All you need is to stop the RAM decaying, just enough juice to keep the dynamic RAM refreshing, nothing more. One, maybe two, rechargeable camera batteries should be enough to handle most situations.
And if there's corruption after that, well, even a "perfect" FS wouldn't have given you any better retention.
If it was that way round (valilla Windows vs. hardware + Linux), sure. However, Linux wouldn't require the extra hardware to run, so you don't "need" it.
It would also be a fairer comparison to say that Linux + a capacitor + a rechargeable battery for RAM = Windows + a SAN box. And unless you're talking one serious capacitor, the SAN box is going to be more expensive.
Besides, battery-backed RAM and ultracapacitors wouldn't be OS-specific. You'd get a performance gain and a reliability gain on ANY OS that supported queued commands. At that point, any OS that failed to queue correctly (on the assumption the drive must be slow) would suddenly be much less reliable than any of its competitors.
Also, bear in mind that a rechargeable battery capable of preserving the disk's command queue is probably going to add fifty cents to every hundred dollars of disk. Unless you're buying disks in the same sort of numbers as Google, the overheads are going to be lower than the difference in disk price between stores. You'd never come close to reaching even a single Windows license fee.
As far as I know, you can't, with POSIX. What you COULD do, however, is have a small battery on the drive and dollops of RAM (say a couple of gigs) dedicated to queueing diskbound traffic. All transactions are dumped to the queue. If the power fails, the queue is intact and can continue being run to the drive when power is restored. This would be good for as long as the battery can maintain the RAM (no reads, no writes, no mechanical devices, no software or CPUs, just the RAM).
An alternative is to have a processor on the drive and shift the filesystem(s) over to that as a program, same way SETI@Home can offload some maths to the GPU. The advantage there is that the filesystem can then spend as long as it likes sorting things out, as it's not tying up the main CPU doing so. Again, it requires a fair chunk of RAM on the drive, and again you'd want to battery-back that RAM dedicated to data to the drive (you don't need to preserve anything else).
Either way would bypass the POSIX issue - to a degree, at least - because it's no longer FS semantics that handle the communication but the virtual FS layer to logical FS layer, and that's not POSIX-specified and can therefore be whatever the inventor of the hardware wants it to be.
(If it's a Linux programmer, the obvious protocol would be the existing virtual-FS-to-logical-FS API that Linux currently uses. Of course, Linux would be the only OS that could use those hard drives for some time, and Windows users likely never could.)
If someone has finally produced a rootkit that sits in the BIOS (and why not?), then yes, this would indeed be possible. All you need to do is upload into the Flash memory a stage loader where the first stage is the malware and the second stage is the "proper" BIOS.
Well, the Pennines in England are contaminated by iron-eating bacteria, and there is a particularly nasty form of Strep that actually digests the entire human body within 24 hours.
But... those of us who learned the Ancient And Most Wise ways always triple-sync. We also sacrifice Peeps and use red food colouring in voodoo ceremonies (hey, it really is blood, so it should work) to keep the hardware from failing.
On next week's Slashdot, there will be a brief tutorial on the right way to burn a Windows CD at the stake, and how to align the standing stones known as RAM Chips to points of astronomical significance.
Slashdot Mirror
Depends on whether Colbert reads Fantastic Four comics.
Calling the modules Seven would make no sense unless the command module is called Blake.
9 out of 10 kittehs agree and would like to perform experiments involving hocking up hairballs in zero gravity.
But how many of them were registered voters or tax payers? You've got to consider the priorities of politicians, in all this.
It's the Haka. They want to get rights to perform it in their ceremonies.
Does anyone else secretly suspect Hank actually has the better odds?
Oh, I agree. The Transputer was an excellent example of a distributed computer. For that matter, so was the Commodore PET (IEEE 488 printers and disk drives all had their own CPU and the main system offloaded all work to them). The Intel iWarp system-on-a-chip was another distributed architecture.
This stuff isn't new, per se, it is merely new in the sense that CPUs became so powerful that everything became hyper-centralized. Only in areas of sound and graphics have they meaningfully decentralized. Networking - well, how many TOE or RDMA engines do you use? There are plenty of Ethernet cards that support both and Linux drivers for those cards, but I'll bet fewer than one in every ten thousand Slashdotters has actually used such a card.
Three Cores for the Gnome kings under the Gtk,
Seven for the KDE lords in their halls of X,
Nine for Emacs Men doomed to spawn,
Well, you see, once IBM buys out Sun, Solaris is going to be re-implemented as macros in OpenOffice. Or Emacs. Whichever one they decide to pick as the new OS kernel.
Linux has supported 16-way SMP since the Xeon first came out. Debuggers and latency-monitoring tools that support multicore have existed for Linux for a long time - Intel's VTune being a commercial example, but DAKOTA and KOJAK being open-source examples.
For compilers based on trivial modifications for existing languages, Cilk++ is basically GCC's C++ with instruction-level parallelism. Those wanting something more sophisticated need look no further than OpenMP. If you prefer all-out hardcore parallelism, use KROC.
The tools are all out there. The OS provides the mechanisms. In the case of Cilk and OpenMP, the code will work just fine on a regular GCC install with no parallel support and on uniprocessor systems.
If parallel support is lacking in software, it is not lacking because of any problems in the toolchain or the kernel. It is lacking because there are too many lazy bar stewards who aim only for the lowest common denominator and ignore the needs of anything better.
The lowest common denominator should indeed not suffer and need not suffer, if code is designed well, but the current practice causes everyone else to suffer on their behalf, which is not good practice.
The Universal Remote can be programmed with the signal used in Laser Tag games and is area-effect. This allows you to blast vast areas far more effectively than the pistol they supply you with. The SmartPhone cannot do this, no matter what you do.
There's some validity to that, but remember that routing protocols designed for ad-hoc networks can be used in what is called an "over-net" to bypass these restrictions. Censored paths would be detected the same way that broken ad-hoc paths are, and simply bypassed. I imagine techniques such as TOR already use routing concepts either along these lines or (by now) more advanced.
But how, exactly, IS the Grand Nagus related to Quark? ....and is there any profit in it?
Well, that depends. Could you build a nanotech Moog from them?
They won't be weightless, they'll be massless.
I dunno. It might cause a reunion of The Village People, if they can figure out a way to handle the extra syllable.
If it's related to the quark, it should be called Rom or Nog.
It might be both. It IS only a few days after St. Patrick's!
True if Linux required it. But let's say Linux'll run on any hard drive, but the "super hard drive" will let you run a desktop or server Linux install that is much more robust.
Laptops generally have power regulation, so can flush buffers and do all other I/O in a controlled way if the main battery reaches a critical level, so I don't see any value in adding robustness that would never get utilized on such a system. Although, if it's only going to add $0.5 - $5 to a hard drive, the value of the selling point would likely see it ending up in most laptops anyway.
It's not really compensating for a defect in the software, because an ultracapacitor or battery-backed RAM will work on all filing systems, and indeed on all Operating Systems.
Even the most extreme solution I offered is nothing more than turning a local hard drive into NAS where the "network" just happens to be the internal bus. It has all the benefits of NAS (such as the queue not being corrupted when you power down the machine, not tying up the main CPU, and so on), but at a fraction of the cost (because you don't need the compute power or a whole new network + NICs).
You could also argue that it's not "adding" hardware, since all IEEE 488 (and many SCSI) hard drives used to be intelligent peripherals. Rather, all more modern hard drives are cut-down. It's like the Winmodem. Nobody argued that "full" modems were Winmodems + added hardware. Besides, a 50 cent capacitor and a torch battery are hardly extensive hardware mods.
Nor is this really a departure from current design methods. SCSI drives are forever increasing the size of the queues they support and they are already nominally intelligent peripherals. The most that could be said is that this suggestion extends the idea to ATA and SATA drives and replaces the typical absurd 16-command queue with a 32768-command queue.
This idea isn't heavyweight, like UPS. The drive would not run without mains power. Rather, the drive would retain all commands and finish off whatever it had been doing when power is restored. No need for whopping big batteries and expensive extras to keep the mechanical bits going. All you need is to stop the RAM decaying, just enough juice to keep the dynamic RAM refreshing, nothing more. One, maybe two, rechargeable camera batteries should be enough to handle most situations.
And if there's corruption after that, well, even a "perfect" FS wouldn't have given you any better retention.
If it was that way round (valilla Windows vs. hardware + Linux), sure. However, Linux wouldn't require the extra hardware to run, so you don't "need" it.
It would also be a fairer comparison to say that Linux + a capacitor + a rechargeable battery for RAM = Windows + a SAN box. And unless you're talking one serious capacitor, the SAN box is going to be more expensive.
Besides, battery-backed RAM and ultracapacitors wouldn't be OS-specific. You'd get a performance gain and a reliability gain on ANY OS that supported queued commands. At that point, any OS that failed to queue correctly (on the assumption the drive must be slow) would suddenly be much less reliable than any of its competitors.
Also, bear in mind that a rechargeable battery capable of preserving the disk's command queue is probably going to add fifty cents to every hundred dollars of disk. Unless you're buying disks in the same sort of numbers as Google, the overheads are going to be lower than the difference in disk price between stores. You'd never come close to reaching even a single Windows license fee.
As far as I know, you can't, with POSIX. What you COULD do, however, is have a small battery on the drive and dollops of RAM (say a couple of gigs) dedicated to queueing diskbound traffic. All transactions are dumped to the queue. If the power fails, the queue is intact and can continue being run to the drive when power is restored. This would be good for as long as the battery can maintain the RAM (no reads, no writes, no mechanical devices, no software or CPUs, just the RAM).
An alternative is to have a processor on the drive and shift the filesystem(s) over to that as a program, same way SETI@Home can offload some maths to the GPU. The advantage there is that the filesystem can then spend as long as it likes sorting things out, as it's not tying up the main CPU doing so. Again, it requires a fair chunk of RAM on the drive, and again you'd want to battery-back that RAM dedicated to data to the drive (you don't need to preserve anything else).
Either way would bypass the POSIX issue - to a degree, at least - because it's no longer FS semantics that handle the communication but the virtual FS layer to logical FS layer, and that's not POSIX-specified and can therefore be whatever the inventor of the hardware wants it to be.
(If it's a Linux programmer, the obvious protocol would be the existing virtual-FS-to-logical-FS API that Linux currently uses. Of course, Linux would be the only OS that could use those hard drives for some time, and Windows users likely never could.)
If someone has finally produced a rootkit that sits in the BIOS (and why not?), then yes, this would indeed be possible. All you need to do is upload into the Flash memory a stage loader where the first stage is the malware and the second stage is the "proper" BIOS.
Well, the Pennines in England are contaminated by iron-eating bacteria, and there is a particularly nasty form of Strep that actually digests the entire human body within 24 hours.
But... those of us who learned the Ancient And Most Wise ways always triple-sync. We also sacrifice Peeps and use red food colouring in voodoo ceremonies (hey, it really is blood, so it should work) to keep the hardware from failing.
On next week's Slashdot, there will be a brief tutorial on the right way to burn a Windows CD at the stake, and how to align the standing stones known as RAM Chips to points of astronomical significance.