Would the magnetic field affect the movement of charged particles through the body, such as the ions of dissolved salts in the bloodstream? Or does blood move sufficiently slowly that this isn't an issue? What about synapse junctions?
I've always wondered why people in this situation didn't build private networks based on protocols other than IP. A quick glance at/etc/protocols shows dozens of different protocols that can be carried by ethernet --- there must be something there that's sufficiently flexible to build a useful network out of but can't be carried by the Internet without protocol conversion. The old OSI protocol suite, for example. Or even write your own if you want special features, such as pervasive authentication on all connections (so you always know who made a connection, not just where from).
This adds an extra level of protection, in that it's much harder to be accidentally gatewayed onto the Internet; you need to have special applications that speak both IP and whatever protocol you're using and translate between them to even communicate.
Of course, you'll probably end up having to rewrite your entire set of application software from scratch to speak the new protocol, but TBH if you really need the security this is likely to be a good idea anyway (provided you don't farm it out to the lowest bidder). And if you're so concerned about security that you're willing to contemplate partitioning the Internet, cost isn't likely to be an issue...
Looks to me like this is designed for the mobile market: two SMP processors to run the application OS, one lower-power processor to run the radio OS. Pretty much every smartphone on the market works like this, albeit with a single application processor.
The reason is that GSM (and most likely CDMA, although I've no experience of that) is critically real-time and needs a real-time OS to manage: Linux basically doesn't cut it. So you dedicate a complete processor with its own real-time operating system to it. I know that the G1, for example, runs L4/Iguana on its radio processor.
This allows you to run an ordinary desktop operating system, which isn't hard real time, on the application processor; Linux, Windows, etc.
There are also legal benefits in that since you can update each OS independently, you don't need to get your device (expensively) recertified by your local radio regulator in order to do an application OS update. If you were using a one-chip device, where there was a single processor that ran both the application layer and the radio stack combined, then you couldn't update one without updating the other.
This, BTW, is one of the reasons why so many people are interested in virtualisation on embedded devices; if you can run two operating systems at the same time on a single processor, it allows all the benefits of a two-chip device on vastly cheaper single-chip hardware.
Actually, you are legally required to have your passport on you at all times when traveling in foreign countries; or at least, that is the case as a U.S. citizen traveling in Thailand.
It depends on the country. I specifically asked about it, and was told that as a UK citizen in the US I did not need to carry my passport. OTOH while in Korea I did have to carry my passport.
Perhaps there's a US rule that US citizens abroad must carry passports, but that would seem really weird. (Not necessarily wrong, though.)
The 1st Amendment *clearly* is not limited to citizens.
Well, no --- that was what the whole Guantanamo Bay thing was about; the legal fiction was that since the interns were neither citizens nor prisoners of war, and were not held on non-US soil, then constitutional and international treaty rights did not apply.
And as a visitor to the US, the piece of paper they made me sign on entry was very scary. As a non-citizen on US soil I can be deported at any time, for any reason, with no right to appeal... and if they did decide to deport me, I wouldn't even be allowed to complain. At least they didn't make me carry identification papers at all times.
From a programmers point of view segments are hell because you never know when you run into the boundary set by the segment and then the shuffeling beings. Also if you have data bigger than the segment you have to press it into multiple ones.
What's most likely going to happen is that the kernel does the segment shuffling and user-mode processes won't care, still thinking they're running on a traditional 32-bit system. That way you get a system which can handle more than 4GB of RAM with ease, even though each individual process can still only address 4GB. This suffices for most use cases. It also has the huge advantage of being completely ABI compatible with 32-bit code, which means there's an easy upgrade path.
I expect that they're working on a major ABI change that will support 64-bit addressing, to come out sometime in the future. (Hopefully they'll also fix the cruft that crept into the opcode design over the years.) But for now, a segmentation hack is actually the sensible thing to do.
Right, I found the source (for some reason cut-and-paste isn't working into a Slashdot text box, but it's prominently linked by another story).
Yes, these drivers require firmware. No, this release does not include source for the firmware. You still need to have the binary blob from Broadcom to make the drivers work.
I haven't looked at the source code --- I can't find it; shouldn't it be visible in in this directory? --- but the announcement doesn't mention any firmware.
A lot (but not all) of wireless cards are usually embedded ARM processors with a radio glued on. The operating system driver just talks to the firmware, and the firmware does most of the heavy lifting. Some cards store firmware in flash, but some store it in RAM and it has to be uploaded from the host computer every time the device is reset.
Does anyone know whether these chipsets do require firmware, and if so whether it's included in the source release?
My school had a network of BBC Masters, connected via Acorn's proprietary Econet networking system (blazing fast as 25kB/s!). It was a surprisingly modern networking protocol, with ports, subnets, bridging, RPC, etc: we used it to connect the machines to a central file server (a souped-up Master with second processor connected to a 20MB Winchester). The system eventually died when the file server got struck by lightning.
What Econet didn't have was any form of designed-in security --- out of the box, each computer would honour RPC requests to do stuff like read and write memory, force jumps to addresses, etc. You could turn it off, but the default was to have all this enabled! I wrote a little program with would suck the framebuffer off someone else's machine and display it on my own, and if I didn't like what they were doing I could reset their machine remotely.
The BBC was a beautifully designed machine. While competitors like the Commodore 64 and the ZX Spectrum were basically designed as CPUs in a box, with just enough OS to load your software, the BBC had a genuine modular operating system with pluggable file systems, application ROMs, invisible access to paged memory, vectored system calls, etc. It scaled well enough that the early ARM machines ran a variant. It's a shame that Acorn's master plan didn't work out: the BBC Micro was originally conceived as the I/O processor for a multiprocessor system, connected via a high-speed parallel bus ('the Tube'). That way your applications ran on a dedicated processor with 63.5kB of usable RAM and no interrupt overhead, and system calls were RPCd to the BBC Micro. It even supported multiple architectures; while the 6502 second processor was the only one that really shipped, Acorn also made a Z80 model (which could run CP/M! And Acorn MOS! At the same time!), a 32016 with FPU and 1 to 4MB of RAM, and the original ARMs were bootstrapped as BBC Micro second processors.
If only the BBC Micros were cheaper, and Acorn had some (any) marketing skill, we might not be using PCs today...
Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?
TV set-top boxes are traditionally MIPS. Lots of them have web browsers in them these days (albeit limited, crappy ones).
That... is awesome. It is one of the most hardcore pieces of badass geekery I've ever seen. Not only has the guy written a kick-ass demo that runs on a 20MHz device with 1kB of RAM and 8kB of ROM, but he also built his own computer to run it on. And then made it generate Julia sets. And submitted it to a demo competition. And won. And it's generating all the audio and video signals in software!
You may be interested in Haidinger's Brush: it's basically an undocumented feature of the human eye that allows you, with practice, to see polarised light. It works due to one of the pigments in the eye being sensitive to polarised light (they think), producing a distinctive pattern when you observe strongly polarised light. By observing this pattern you can determine the direction of polarisation.
These are ARM based platforms, but unlike the PC, there's not one single platform.
Having worked on this sort of thing... you are so right. (Aside: there are some non PC x86 devices. SGI made some non-PC x86 workstations at one point, and the new generation of Atom phones won't be PCs.)
However, all is not lost: this is exactly the kind of problem that Open Firmware was designed to solve. Each machine has an Open Firmware interpreter on it that acts as a boot loader. Once loaded, the OS can query Open Firmware to find stuff out about the machine. What's more, Open Firmware has the ability to find basic device drivers written in bytecode on the devices themselves. Plug in a PCI mass storage device and you can boot from it --- regardless of your machine's architecture! And since Open Firmware is based around a Forth interpreter, you have a complete programming environment out of the box, which is fantastic for troubleshooting.
Anyone who's used a Sun workstation, a PowerPC Mac or an OLPC will have been exposed to it. Unfortunately, Intel's adoption of EFI as the official next-gen PC boot architecture pretty much squashed Open Firmware's momentum.
You can find a BSD/MIT licensed version here... and yes, there is an ARM version.
On the other hand, maybe it would make disrupting asteroids easier. Instead of one large impact, you have thousands of smaller bodies that have a greater chance of simply burning up on reentry.
That is not necessarily a good thing.
A single large asteroid hits the surface and, largely, converts all its kinetic energy into heat. An awful lot of that heat radiates harmlessly off into space.
Turn your asteroid into dust and what happens instead is, yes, it all burns up in the atmosphere --- dumping the entire kinetic energy of the asteroid (which hasn't changed, remember!) into the atmosphere as heat, increasing the temperature massively. I forget the precise wording in the study I read but I believe the phrase was along the lines 'can ignite entire continents'...
During the second stage burn, the vehicle appeared to start to rotate, gradually accelerating as the burn continued. Does anyone know if this was part of the planned ascent profile, or something gone wrong?
It's hard to tell due to the angle of the rocketcam camera, but it didn't appear to be rolling around the vehicle's axis --- which makes it more of a tumble. OTOH, that might have been an optical illusion. I gather that the Dragon demonstrator that was being launched didn't have any propulsion, so this could have been planned to spin-stabilise it, but... it did look odd.
I don't want to put any dampeners on the launch, though. For a first launch of a prototype rocket, it's still a fantastic achievement to get to orbit first time.
I think it's an uncanny valley issue. The MIDI versions are trying to sound realistic without being realistic enough, resulting in that classic and very distinctive GM effect. (Not to mention the traditional problem with any form of GM music in that patch sets are so dissimilar that anything that sounds good on one device will suck on another. Consider that all the MIDI synths in that video are likely to be playing the same piece of music.) And the CD audio version is cheating --- it's just a recording of real people playing real instruments, and what's the point of that? Not to mention that it's damned hard to do iMuse with PCM music.
So, give me those lovely warm FM tones any day, the way Michael Lands intended it to sound!
...is a Flash runtime written in Javascript, using HTML5 to do the rendering. It runs purely in the web browser. It runs on the iPhone. It's still pretty basic, but looks promising. Running the demos in Chromium on Linux doesn't appear to show much difference in speed --- of course, those demos have been carefully chosen to work.
It claims to support SWF1 and a lot of SWF2. Right now I believe we're on SWF9, so there's a long way to go, but it does show that the approach works.
cowlark.com is run off a single SheevaPlug with some USB hard drives attached. This is: SMTP server (postfix), spam filter (spey), IMAP server (dovecot); web server (thttpd); Java servlet server (winstone, run in OpenJDK, interpreted. Yuck. No JIT available for ARM); my local news server (leafnode); my local DNS/DHCP server (dnsmasq); my local backup server (rsnapshot). It's also my main shell box for doing downloads and stuff.
The whole hardware stack, UPS included, consumes about 18 watts, although this varies depending on whether the hard drives are spun up or not. Most storage is on a 64GB home-made SSD (4 x 16GB USB keys & RAID!), so it's completely silent.
The SheevaPlug is a 1.2GHz Marvell ARMv5, with 512MB of RAM and 512MB of flash (which I'm not using). It cost me about 70 UKP. Unfortunately it's only got one ethernet port, so I've got way too much stuff hung off its single USB port --- and Marvell's USB hardware is notoriously dodgy. The new GuruPlug looks way more exciting: same processor, but two ethernet ports, more USB ports, and SATA!
Still, I'd disagree with the poster that for OSS documentation-by-API-user "is worse than no documentation at all".
It's a tough call.
One of the worst examples of this is the NSLU2 wiki. This is the official place where documentation is kept. Unfortunately there's no editorial oversight, which means the contents of the wiki is badly sorted, out-of-date, incomplete, and frequently just plain wrong. Actually finding anything is a nightmare because there aren't any proper indices (and MediaWiki's search function is pretty bad, but that's another rant), and once you've found it it usually doesn't help.
Is this better than none at all? I dunno. The information is in there, usually, but in order to extract the signal from the noise you usually have to know enough that you could figure it out on your own anyway...
My best guess [and I am not trying to be facetious] is that unless you were in on kernel development in the very early days [so that you had some hope of learning it when it was still tractable], then the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?], and the learning curve has gotten so steep, that no new developers have any realistic hope of grokking it anymore.
Not to mention the lousy documentation. The kernel docs for Linux are stunningly poor, verging on non-existent --- most of the design appears to live only in people's heads.
I have a project that involves lots of grubby work with the Linux system call interface (<plug> LBW, a tool for running Linux binaries on Windows <plug/>). The man pages are of very little use here. Not only do they not go into enough detail, but they're frequently horribly out of date. futex(2) now bears very little resemblance to what the futex man page actually does. I eventually had to resort to groping through the Linux kernel code simply to try and figure out how what structures were used where --- and to determine the layout of struct stat I actually had to start comparing hex dumps to find the binary layout (tip: gcc's alignment attribute does not work the way you think it does).
What's worse is that there appears to be very little recognition that this is a problem. Asking on the newsgroups about futex(), for example, I just got pointed at a years-old PDF entitled 'Futexes are tricky'. I don't believe that any proper spec for what futex() does actually exists. Without prescriptive and definitive documentation, how do you know if it's working correctly?
Compare to BSD culture: OpenBSD's man pages are a joy to behold --- everything is documented in copious detail, including internal kernel functions!
I weep for OpenMOSIX. I was hoping that the project would continue and ere long we'd be motivated to buy all one architecture in our house simply because all the machines would form a cluster almost without our involvement and just accelerate each others' tasks. A terminal cluster where the terminals also make the entire system faster is kind of an ideal dream.
What happened to OpenMOSIX, anyway? I used it very successfully to turn groups of workstations into build servers; they all ran OpenMOSIX, and then make -j8 on any of the workstations would farm out the build to all the workstations. And it all Just Worked, and there was bugger all maintenance involved, etc. I was really looking forward to it getting mainlined into the kernel and then it just all kind of vanished.
There's no indication of what happened on the mailing list --- it just stops. There's a new project called LinuxPMI that claims to be a continuation but there's no mailing list traffic...
You may want to look at rsnapshot. It's a very small shell script that pretty much duplicates the functionality of Apple's Time Machine. Each backup becomes a timestamped directory containing all the data in the backup; files that haven't changed from backup to backup are hardlinked together, so they only get stored once (per-file deduplication). This makes incremental backups very cheap, while also avoiding the need for specialised backup restoration software. It all works through the magic of rsync.
On my system, each incremental backup of a 24GB dataset occupies about 600MB (depending how many files have changed). And each incremental backup is a complete, uncompressed copy of the dataset, making extracting files trivial!
It'll also backup across the network with ssh, so you can back up remote servers; it'll even back up Windows machines. It does proper backup rotation (I store two weeks' worth of daily backups, then a a couple of weekly backups, then monthly). It's totally awesome.
Slashdot Mirror
Would the magnetic field affect the movement of charged particles through the body, such as the ions of dissolved salts in the bloodstream? Or does blood move sufficiently slowly that this isn't an issue? What about synapse junctions?
I've always wondered why people in this situation didn't build private networks based on protocols other than IP. A quick glance at /etc/protocols shows dozens of different protocols that can be carried by ethernet --- there must be something there that's sufficiently flexible to build a useful network out of but can't be carried by the Internet without protocol conversion. The old OSI protocol suite, for example. Or even write your own if you want special features, such as pervasive authentication on all connections (so you always know who made a connection, not just where from).
This adds an extra level of protection, in that it's much harder to be accidentally gatewayed onto the Internet; you need to have special applications that speak both IP and whatever protocol you're using and translate between them to even communicate.
Of course, you'll probably end up having to rewrite your entire set of application software from scratch to speak the new protocol, but TBH if you really need the security this is likely to be a good idea anyway (provided you don't farm it out to the lowest bidder). And if you're so concerned about security that you're willing to contemplate partitioning the Internet, cost isn't likely to be an issue...
Looks to me like this is designed for the mobile market: two SMP processors to run the application OS, one lower-power processor to run the radio OS. Pretty much every smartphone on the market works like this, albeit with a single application processor.
The reason is that GSM (and most likely CDMA, although I've no experience of that) is critically real-time and needs a real-time OS to manage: Linux basically doesn't cut it. So you dedicate a complete processor with its own real-time operating system to it. I know that the G1, for example, runs L4/Iguana on its radio processor.
This allows you to run an ordinary desktop operating system, which isn't hard real time, on the application processor; Linux, Windows, etc.
There are also legal benefits in that since you can update each OS independently, you don't need to get your device (expensively) recertified by your local radio regulator in order to do an application OS update. If you were using a one-chip device, where there was a single processor that ran both the application layer and the radio stack combined, then you couldn't update one without updating the other.
This, BTW, is one of the reasons why so many people are interested in virtualisation on embedded devices; if you can run two operating systems at the same time on a single processor, it allows all the benefits of a two-chip device on vastly cheaper single-chip hardware.
Neither the Martians or Irish (or Scots) appear to have much of an imagination.
Actually, you are legally required to have your passport on you at all times when traveling in foreign countries; or at least, that is the case as a U.S. citizen traveling in Thailand.
It depends on the country. I specifically asked about it, and was told that as a UK citizen in the US I did not need to carry my passport. OTOH while in Korea I did have to carry my passport.
Perhaps there's a US rule that US citizens abroad must carry passports, but that would seem really weird. (Not necessarily wrong, though.)
The 1st Amendment *clearly* is not limited to citizens.
Well, no --- that was what the whole Guantanamo Bay thing was about; the legal fiction was that since the interns were neither citizens nor prisoners of war, and were not held on non-US soil, then constitutional and international treaty rights did not apply.
And as a visitor to the US, the piece of paper they made me sign on entry was very scary. As a non-citizen on US soil I can be deported at any time, for any reason, with no right to appeal... and if they did decide to deport me, I wouldn't even be allowed to complain. At least they didn't make me carry identification papers at all times.
From a programmers point of view segments are hell because you never know when you run into the boundary set by the segment and then the shuffeling beings. Also if you have data bigger than the segment you have to press it into multiple ones.
What's most likely going to happen is that the kernel does the segment shuffling and user-mode processes won't care, still thinking they're running on a traditional 32-bit system. That way you get a system which can handle more than 4GB of RAM with ease, even though each individual process can still only address 4GB. This suffices for most use cases. It also has the huge advantage of being completely ABI compatible with 32-bit code, which means there's an easy upgrade path.
I expect that they're working on a major ABI change that will support 64-bit addressing, to come out sometime in the future. (Hopefully they'll also fix the cruft that crept into the opcode design over the years.) But for now, a segmentation hack is actually the sensible thing to do.
Yes, these drivers require firmware. No, this release does not include source for the firmware. You still need to have the binary blob from Broadcom to make the drivers work.
A lot (but not all) of wireless cards are usually embedded ARM processors with a radio glued on. The operating system driver just talks to the firmware, and the firmware does most of the heavy lifting. Some cards store firmware in flash, but some store it in RAM and it has to be uploaded from the host computer every time the device is reset.
Does anyone know whether these chipsets do require firmware, and if so whether it's included in the source release?
What Econet didn't have was any form of designed-in security --- out of the box, each computer would honour RPC requests to do stuff like read and write memory, force jumps to addresses, etc. You could turn it off, but the default was to have all this enabled! I wrote a little program with would suck the framebuffer off someone else's machine and display it on my own, and if I didn't like what they were doing I could reset their machine remotely.
The BBC was a beautifully designed machine. While competitors like the Commodore 64 and the ZX Spectrum were basically designed as CPUs in a box, with just enough OS to load your software, the BBC had a genuine modular operating system with pluggable file systems, application ROMs, invisible access to paged memory, vectored system calls, etc. It scaled well enough that the early ARM machines ran a variant. It's a shame that Acorn's master plan didn't work out: the BBC Micro was originally conceived as the I/O processor for a multiprocessor system, connected via a high-speed parallel bus ('the Tube'). That way your applications ran on a dedicated processor with 63.5kB of usable RAM and no interrupt overhead, and system calls were RPCd to the BBC Micro. It even supported multiple architectures; while the 6502 second processor was the only one that really shipped, Acorn also made a Z80 model (which could run CP/M! And Acorn MOS! At the same time!), a 32016 with FPU and 1 to 4MB of RAM, and the original ARMs were bootstrapped as BBC Micro second processors.
If only the BBC Micros were cheaper, and Acorn had some (any) marketing skill, we might not be using PCs today...
TV set-top boxes are traditionally MIPS. Lots of them have web browsers in them these days (albeit limited, crappy ones).
Or a newline.
More info here.
You may be interested in Haidinger's Brush: it's basically an undocumented feature of the human eye that allows you, with practice, to see polarised light. It works due to one of the pigments in the eye being sensitive to polarised light (they think), producing a distinctive pattern when you observe strongly polarised light. By observing this pattern you can determine the direction of polarisation.
These are ARM based platforms, but unlike the PC, there's not one single platform.
Having worked on this sort of thing... you are so right. (Aside: there are some non PC x86 devices. SGI made some non-PC x86 workstations at one point, and the new generation of Atom phones won't be PCs.)
However, all is not lost: this is exactly the kind of problem that Open Firmware was designed to solve. Each machine has an Open Firmware interpreter on it that acts as a boot loader. Once loaded, the OS can query Open Firmware to find stuff out about the machine. What's more, Open Firmware has the ability to find basic device drivers written in bytecode on the devices themselves. Plug in a PCI mass storage device and you can boot from it --- regardless of your machine's architecture! And since Open Firmware is based around a Forth interpreter, you have a complete programming environment out of the box, which is fantastic for troubleshooting.
Anyone who's used a Sun workstation, a PowerPC Mac or an OLPC will have been exposed to it. Unfortunately, Intel's adoption of EFI as the official next-gen PC boot architecture pretty much squashed Open Firmware's momentum.
You can find a BSD/MIT licensed version here... and yes, there is an ARM version.
Do you really want to be strapped to a Star Trek console in a crisis situation?
On the other hand, maybe it would make disrupting asteroids easier. Instead of one large impact, you have thousands of smaller bodies that have a greater chance of simply burning up on reentry.
That is not necessarily a good thing.
A single large asteroid hits the surface and, largely, converts all its kinetic energy into heat. An awful lot of that heat radiates harmlessly off into space.
Turn your asteroid into dust and what happens instead is, yes, it all burns up in the atmosphere --- dumping the entire kinetic energy of the asteroid (which hasn't changed, remember!) into the atmosphere as heat, increasing the temperature massively. I forget the precise wording in the study I read but I believe the phrase was along the lines 'can ignite entire continents'...
During the second stage burn, the vehicle appeared to start to rotate, gradually accelerating as the burn continued. Does anyone know if this was part of the planned ascent profile, or something gone wrong?
It's hard to tell due to the angle of the rocketcam camera, but it didn't appear to be rolling around the vehicle's axis --- which makes it more of a tumble. OTOH, that might have been an optical illusion. I gather that the Dragon demonstrator that was being launched didn't have any propulsion, so this could have been planned to spin-stabilise it, but... it did look odd.
I don't want to put any dampeners on the launch, though. For a first launch of a prototype rocket, it's still a fantastic achievement to get to orbit first time.
To me, the FM synth version sounds the best.
I think it's an uncanny valley issue. The MIDI versions are trying to sound realistic without being realistic enough, resulting in that classic and very distinctive GM effect. (Not to mention the traditional problem with any form of GM music in that patch sets are so dissimilar that anything that sounds good on one device will suck on another. Consider that all the MIDI synths in that video are likely to be playing the same piece of music.) And the CD audio version is cheating --- it's just a recording of real people playing real instruments, and what's the point of that? Not to mention that it's damned hard to do iMuse with PCM music.
So, give me those lovely warm FM tones any day, the way Michael Lands intended it to sound!
It claims to support SWF1 and a lot of SWF2. Right now I believe we're on SWF9, so there's a long way to go, but it does show that the approach works.
cowlark.com is run off a single SheevaPlug with some USB hard drives attached. This is: SMTP server (postfix), spam filter (spey), IMAP server (dovecot); web server (thttpd); Java servlet server (winstone, run in OpenJDK, interpreted. Yuck. No JIT available for ARM); my local news server (leafnode); my local DNS/DHCP server (dnsmasq); my local backup server (rsnapshot). It's also my main shell box for doing downloads and stuff.
The whole hardware stack, UPS included, consumes about 18 watts, although this varies depending on whether the hard drives are spun up or not. Most storage is on a 64GB home-made SSD (4 x 16GB USB keys & RAID!), so it's completely silent.
The SheevaPlug is a 1.2GHz Marvell ARMv5, with 512MB of RAM and 512MB of flash (which I'm not using). It cost me about 70 UKP. Unfortunately it's only got one ethernet port, so I've got way too much stuff hung off its single USB port --- and Marvell's USB hardware is notoriously dodgy. The new GuruPlug looks way more exciting: same processor, but two ethernet ports, more USB ports, and SATA!
Still, I'd disagree with the poster that for OSS documentation-by-API-user "is worse than no documentation at all".
It's a tough call.
One of the worst examples of this is the NSLU2 wiki. This is the official place where documentation is kept. Unfortunately there's no editorial oversight, which means the contents of the wiki is badly sorted, out-of-date, incomplete, and frequently just plain wrong. Actually finding anything is a nightmare because there aren't any proper indices (and MediaWiki's search function is pretty bad, but that's another rant), and once you've found it it usually doesn't help.
Is this better than none at all? I dunno. The information is in there, usually, but in order to extract the signal from the noise you usually have to know enough that you could figure it out on your own anyway...
My best guess [and I am not trying to be facetious] is that unless you were in on kernel development in the very early days [so that you had some hope of learning it when it was still tractable], then the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?], and the learning curve has gotten so steep, that no new developers have any realistic hope of grokking it anymore.
Not to mention the lousy documentation. The kernel docs for Linux are stunningly poor, verging on non-existent --- most of the design appears to live only in people's heads.
I have a project that involves lots of grubby work with the Linux system call interface (<plug> LBW, a tool for running Linux binaries on Windows <plug/>). The man pages are of very little use here. Not only do they not go into enough detail, but they're frequently horribly out of date. futex(2) now bears very little resemblance to what the futex man page actually does. I eventually had to resort to groping through the Linux kernel code simply to try and figure out how what structures were used where --- and to determine the layout of struct stat I actually had to start comparing hex dumps to find the binary layout (tip: gcc's alignment attribute does not work the way you think it does).
What's worse is that there appears to be very little recognition that this is a problem. Asking on the newsgroups about futex(), for example, I just got pointed at a years-old PDF entitled 'Futexes are tricky'. I don't believe that any proper spec for what futex() does actually exists. Without prescriptive and definitive documentation, how do you know if it's working correctly?
Compare to BSD culture: OpenBSD's man pages are a joy to behold --- everything is documented in copious detail, including internal kernel functions!
I weep for OpenMOSIX. I was hoping that the project would continue and ere long we'd be motivated to buy all one architecture in our house simply because all the machines would form a cluster almost without our involvement and just accelerate each others' tasks. A terminal cluster where the terminals also make the entire system faster is kind of an ideal dream.
What happened to OpenMOSIX, anyway? I used it very successfully to turn groups of workstations into build servers; they all ran OpenMOSIX, and then make -j8 on any of the workstations would farm out the build to all the workstations. And it all Just Worked, and there was bugger all maintenance involved, etc. I was really looking forward to it getting mainlined into the kernel and then it just all kind of vanished.
There's no indication of what happened on the mailing list --- it just stops. There's a new project called LinuxPMI that claims to be a continuation but there's no mailing list traffic...
On my system, each incremental backup of a 24GB dataset occupies about 600MB (depending how many files have changed). And each incremental backup is a complete, uncompressed copy of the dataset, making extracting files trivial!
It'll also backup across the network with ssh, so you can back up remote servers; it'll even back up Windows machines. It does proper backup rotation (I store two weeks' worth of daily backups, then a a couple of weekly backups, then monthly). It's totally awesome.