I have one question for those people who decide which category stories go into:-
Why is this article about OpenDocument format in the Linux category?
The OpenDocument format can indeed be used by software which happens to run on Linux but it's a *FAR* bigger thing than that. The OpenDocument format is architecture neutral and as such if you could equally choose to classify the article under the BSD daemon or the MacOS or even Windows.
So, surely, this should be under some other, architectural neutral label to do with digital freedom or open standards in general?
Firstly, I'm not going to talk about anything to do with commercial drivers, it's just too much of a religious war and no-one will listen to the arguments either way...
Instead, I can show why having a stable, backwardly compatible and well engineered* driver kernel interface, be it binary or not, is good for everyone, even those hard working open source driver developers:-
*Note: I use the word "engineered" purposefully. Anyone can design something, such as a bridge, but it doesn't mean that it will work. Engineering is a rigorous process with only a small part beinf design, the major part is proving the design works and is the correct one.
(1) A constantly metamorphosing DKI means that everyone has to run to stand still.
Just think of the number of man hours which has to go into modifying every single little device driver when the kernel interface changes. Just think of the number of times the interface has changed in the 2.6 "stable" series. Just think how many man hours could have gone into making the drivers better instead.
(2) A constantly metamorphosing DKI means that drivers get orphaned.
If a driver maintainer gives up or the company which made the hardware and maintained a driver goes under or is taken over then it won't be very long until the change in the kernel interface makes the driver unusable. There are many drivers in the current kernel which are still lurking, unloved and uncompilable at the moment, such as the Advansys SCSI driver. One of the great cries as to why Linux was so great was that it supported all that old, lovely hardware that the manufacturers forgot about. Well, it seems that because of the supersonic DKI Linux has as well.
(3) Separating the kernel totally from the drivers means both can concentrate on what they do best.
OK, so what would separating logically the driver and the kernel mean?
Well, firstly, with a fully engineered interface the kernel can interface with all the drivers in a sane and virtual way. The drivers are a black box, the kernel doesn't know and shouldn't know how a disk drive works, just that every disk drive looks like any other disk drive. In that way the kernel developers can stop worrying about those trivia and worry more about how they may optimise moving data around the kernel better or scheduling the reads etc. Why should the kernel care if it's an IDE disk on its own motherboard or a virtual disk held on a server the other side of the world as long as when it requests something to happen it happens?
Secondly, if the kernel is a black box to the device driver author then he/she doesn't need to care what the kernel does, as long as it performs to the tight specification and the driver is written to that specification then it will work. If it doesn't then there's a bug in the driver code and he/she knows that they have to fix it. It also means that the kernel can vet the arguments and data it's given to make sure that the driver isn't insane and trying to do nasty things to it.
(4) But we need supersonic goal posts because we need to be flexible and make things better!
How many times have I heard that one? Far too many.
If a kernel/driver interface is properly engineered there should never be a need to change it other than to maybe add functionality in a structured and backwardly compatible fashion for new types of device which were not envisioned when the original specification was produced.
ie. if the specification has to be changed incompatibily then whoever engineered the original needs a kick up the backside for not doing his/her job.
The problem with trying to produce such an interface specification is that it takes a great deal of effort and thought for somerthing which in the short term will only produce pain. Most developers of free software are unlikely to either put the effort in or have the political power to make it happen in the first place.
Long ago, in a time before Adware there once was a wonderful medium called IRC.
People used to talk inanely for days on it and, as long as you could find a server which was on the right network, wasn't full and hadn't split itself from the rest of the IRC network you could happily chat with your friends on #dl-bar or #gb or whatever (until someone decided that their ego was too great and booted most of the residents off it).
Today, however, the dreaded robot revolution has arrived. Hords of robotic critters are being controlled by a few, evil people in attempt to make money and destroy the world. That's where IRC is these days. There is no signal left, it's all noise and automatic control.
Oh, I missed that bit. Even so, there is, of course the chance that the bug which killed the driver the first time will trigger its replacement's demise because of the same conditions applying.
Of course, the OS could have two different drivers for each critical bit of hardware which were independently developed so that if one crashes the other gets loaded... but that silly.:-)
Oh, indeed, but the quote given gave the impression that it was a magic bullet which would stop device drivers bringing a system to its knees.
Now, as a friend pointed out to me, having the device drivers as user-mode processes allows for easy maintenance and upgrade of the system on the fly. That's just one advantage (as well as enforcing a standard, thought through binary programming interface for drivers which Linux sorely lacks).
For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs.
This is all well and good until the crashing device driver locks the system bus or grams an NMI etc. And what if the device driver in qestion is the one accessing the disk? How does the microkernel recover from that one when it can't access the drive the device driver is sitting upon?
I can see where his thought processes are coming from, but I still think he lives in Computer Science Heaven, I'm afraid, where all hardware is mathematically perfect and I/O never happens (as it's not mathematically provable).
In the real world device drivers hardly ever crash the system 'cos they're kernel mode, they crash it because the hard-hang the system or denigh the kernel the resources to dig itself out of the hole. Neither of these change by moving the code into user space.
The test you saw was the emergency deployment when all hydraulic power has been lost and not normal deployment.
In the case of a complete hydraulics failure the crew can actuate a manual lever which unlocks the undercarrage and deploys it using only gravity to do so. This is what you saw.
Normally, the doors and the undercarrage itself are driven fully by the hydraulic system and the doors are never touched by the wheels or anything else.
That episode aired in the UK.. in fact we got all the episodes, in order. Firstly on Skay One and recently on UK SciFi (which no-longer has links with the US SciFi channel, unfortunately).
In fact, this weekend UK SciFi channel are having a marathon showing with Joss and the crew introducing the whole event. This probably isn't surprising as UK SciFi channel is owned by Universal Studios.
KDE Version 1 was nice, lean, clean and fast. It worked wonderfully on old kit such as Sun SPARCstation 2s etc.
KDE version 2 started eating memory and resources because it added a whole lot of underlying engineering, most of which a technical user who doesn't use it as just a desktop to manage xterms and other X programs doesn't use. You needed at least a Sun Ultra 1 with 256MB of RAM for it to be useful.
KDE version 3 increased the overhead quite a bit and increased the disk usage a lot. Unless you had a 440MHz Sun Ultra 10 with half a gig of RAM it's painful.
I'm guessing that KDE 4 won't even run on platforms which don't use an X server without the new Xorg server extensions and a gigahertz processor or two.
You may ask yourself why I'm not talking about the power of PC's running Linux as a comparison against which to judge the different versions.. well, firstly, KDE is supposed to be fully cross (unix-like) platform. Secondly, we're a mostly Sun shop for the research side of things here, with Linux increasing in number, but because of the extended nature of machine replacement in academia I still have to support and run 8-10 year old machines. To me, being able to run a reasonably modern desktop for my users is important. KDE used to be the ideal replacement for the really increadibly crummy CDE which comes with Solaris.. it's getting harder and harder to keep it running on the old hardware.
Would that second item be the same as "Safe Mode with Command Prompt"? If it is then it's already too late.
I'm guessing that because the only way the NT kernel know how to ready the filesystem is by loading the ntfs drivers it'll also load the nasty drivers installed by the root kit.
Am I right in thinking that the recovery console is specific to each machine?
If it is then it's unmanagable for anything other than a very few machines managed by a single person, rather than the various user machines which I first see when they turn up with their laptop with a problem.
The main problem when trying to get rid or detect rootkits on Windows XP/Server 2003 is that the "Safe Mode" is not at all safe at all.
By the time the system has booted far enough to get into "Safe Mode" it's already loaded so many DLL's, including the obfucating rootkit ones, that there's no way of accessing the filesystem to see the malware.
Now, if Microsoft had added a single-tasking, statically linked command line emergency system which would allow you to just manipulate an NTFS filesystem this would be the greatest step forward in rootkit/malware removal.
Alternatively, "Safe Mode" should load only those DLL's which are hard coded into the kernel to load, along with signatures and checksums to make sure (as much as you can) that those files haven't been tampered with.
As it is, the only way I've found of de-rootkitting machine is using Knoppix 3.6 and captive-NTFS!
Yes, it's only pointers (plus the extra data transfer upon process context switch due to the extra size and number of registers) which changed size.
However, the program code itself will have a lot more 64bit addresses in it (which means that the "instruction cache" size is effectively reduced) plus as soon as you start using linked lists or function look-up tables you're into lots of pointer work, which effectively reduces the "data cache". (I'm using quotes as the cache is unified on the AMD64 processors, but the effect is to for all intents and purposes to reduce the effective cache size.)
Myself, I've not seen a great number of x86_64 binaries go quicker at all. This is both under Linux with GCC and Portland C compilers with all the optimisations I can throw at it switched on and under Solaris x86 with GCC and Studio 10 compilers.
For purely integer code on our v40z's, v20z's and W2100z machines there seems to be a 50% drop in speed, for floating point scientific code generally a bit less. This is the same for FORTRAN as well. These are all Opteron with dual channel memory.
I've tried similar on an Athlon64 machine with single channel memory and the performance drop is far greater.
All the advantages of the extra registers seems to be offset by the extra memory overhead at the moment, at least on the codes we run.
Of course, when you port the application to a 64bit environment you have to start worrying about data type sizes and the way the application reads and writes the files stored on disk.
There's always the problem of having to do type conversions so as to make sure that the data types in the files are the same size as the other architectures produce. Admittedly, it helps that GCC on x86 and x86_64 both use the same sizes for native integer types (short, int, long) but this isn't always the case. (DEC Alpha OSF/1 used 64 bit longs which messed up a lot of programs.) However, there is still the problem of data alignment and padding in structures.
Unless you want to have a document which uses more than about 3GB of memory, what's the point of building it 64bit?
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Seeing as the Opteron/Athlon64/Turion64 run 32bit applications fast natively there's no actual point (other than religious) to build and run an office product (or, indeed, most other applications) in 64bit mode.
The problems with New Orleans runs far-far deeper than polluting etc.
New Orleans is placed on a river delta. After the sediments in a delta are deposited they are guaranteed to subside. It's a consiquence of compaction, de-watering and the isostatic response of the lithosphere below the basin to the extra load. Unless more sediment is added continuously the delta will eventually (and quite quickly in geological and indeed historical terms) sink beneath the sea.
When New Orleans was founded a few hundred years ago it was above sea level. (after all, who would found a town on a salt marsh?) Since then it's subsided continuously until today a great deal of the city is now below sea level and a great deal lower than the river (which has since built up its base by depositing sediment).
When the corps of engineers stopped the river naturally switching its channel (which it does around once every 1000 years) and straightened the current channel they put in motion a set of events which meant that the delta lost its sediment load to further out in the Gulf of Mexico as the river is flowing at a greater rate. This has caused the coastline (and all the natural defences) to not be replenished and go below the sea.
You may like to see this google cached article from a Baton Rouge newspaper in 2002. It gives a decent overview of the situation.
As a geologist, I would be in the camp which suggests that the government take this as an opportunity to move the city to higher and more stable ground and abandon the old city to be an archaeological curiosity and tourist attraction. Rebuilding it would merely prime the charge for an even bigger loss of life when, not if, the river breaks its banks. This time only the low-level lake to the north broke through which soon equalised its level.. this wouldn't happen with the great river.
How long do you want to fight a losing battle with the planet? How high do you eventually want the levees to be before you give up? When the city's subsided to the point where it's an isolated bowl in the ocean?
I know it's not going to be abandoned, there are too many politicians who have staked their carreer on the "we will rebuild it" bravardo and a King Kanute attitude.
(Before anyone corrects me about King Kanute, I know that the popular story is wrong, the King was trying to show how impotent he was rather than believing that he could actually stop the sea.)
And once that's done and a problem is found in the interface (which will always occur), what do you do then?
Then it's fixed in the next major release of the ABI specification. It's standard software engineering best practise. Poorly documented interfaces with super-sonic goalposts are a recipe for long-term disaster and/or stability. It also disuades people from contributing driver code because by the time they've developed their code the interfaces have changed or they have to keep re-engineering their code (which costs time/money) every couple of months.
For Linux, where the vast bulk of drivers are maintained in the kernel, by the kernel people, alongside the rest of the core kernel code, it doesn't make sense to spend time guaranteeing interfaces for a very few 3rd party drivers.
And the reason for this is....? The only people who can keep up to date with the kernel/driver interface or who can work out what that interface is are the people who know the insides of the kernel. If there were a standardised API even which was scrupulously documented it would be far easier for people who are not kernel developers to develop drivers.
- lobby your vendor for open-drivers and/or programming specifications for your hardware (cause then it can be integrated into Linux kernel, the kernel people will help maintain it, and other kernel's can benefit from having source/docs to look at to help implement their own drivers).
Commercial companies won't do this is they have to spend resources rewriting their driver every couple of months 'cos the kernel's changed. They're also far less likely to do this if they have to generate a binary driver version for each build each distribution produces for the majority of real users who don't know what a compiler is let alone how to build anything. (This is the target audience for Linux on the desktop, isn't it?)
It seems from what you have said that you'd prefer people who don't share your point of view about the Linux kernel and want to express their view about how the status quo is not good for the long-term survival to just go elsewhere. Well, they might just do that, along with most of the computer using masses. It's a big-picture thing.
Wow, Linux is dying!!! That's a new one on slashdot.
I didn't say that at all. I'm sure it'll continue to be used for a long-long time.. but not by the masses.
Slashdot Mirror
I have one question for those people who decide which category stories go into:-
Why is this article about OpenDocument format in the Linux category?
The OpenDocument format can indeed be used by software which happens to run on Linux but it's a *FAR* bigger thing than that. The OpenDocument format is architecture neutral and as such if you could equally choose to classify the article under the BSD daemon or the MacOS or even Windows.
So, surely, this should be under some other, architectural neutral label to do with digital freedom or open standards in general?
Firstly, I'm not going to talk about anything to do with commercial drivers, it's just too much of a religious war and no-one will listen to the arguments either way...
Instead, I can show why having a stable, backwardly compatible and well engineered* driver kernel interface, be it binary or not, is good for everyone, even those hard working open source driver developers:-
*Note: I use the word "engineered" purposefully. Anyone can design something, such as a bridge, but it doesn't mean that it will work. Engineering is a rigorous process with only a small part beinf design, the major part is proving the design works and is the correct one.
(1) A constantly metamorphosing DKI means that everyone has to run to stand still.
Just think of the number of man hours which has to go into modifying every single little device driver when the kernel interface changes. Just think of the number of times the interface has changed in the 2.6 "stable" series. Just think how many man hours could have gone into making the drivers better instead.
(2) A constantly metamorphosing DKI means that drivers get orphaned.
If a driver maintainer gives up or the company which made the hardware and maintained a driver goes under or is taken over then it won't be very long until the change in the kernel interface makes the driver unusable. There are many drivers in the current kernel which are still lurking, unloved and uncompilable at the moment, such as the Advansys SCSI driver. One of the great cries as to why Linux was so great was that it supported all that old, lovely hardware that the manufacturers forgot about. Well, it seems that because of the supersonic DKI Linux has as well.
(3) Separating the kernel totally from the drivers means both can concentrate on what they do best.
OK, so what would separating logically the driver and the kernel mean?
Well, firstly, with a fully engineered interface the kernel can interface with all the drivers in a sane and virtual way. The drivers are a black box, the kernel doesn't know and shouldn't know how a disk drive works, just that every disk drive looks like any other disk drive. In that way the kernel developers can stop worrying about those trivia and worry more about how they may optimise moving data around the kernel better or scheduling the reads etc. Why should the kernel care if it's an IDE disk on its own motherboard or a virtual disk held on a server the other side of the world as long as when it requests something to happen it happens?
Secondly, if the kernel is a black box to the device driver author then he/she doesn't need to care what the kernel does, as long as it performs to the tight specification and the driver is written to that specification then it will work. If it doesn't then there's a bug in the driver code and he/she knows that they have to fix it. It also means that the kernel can vet the arguments and data it's given to make sure that the driver isn't insane and trying to do nasty things to it.
(4) But we need supersonic goal posts because we need to be flexible and make things better!
How many times have I heard that one? Far too many.
If a kernel/driver interface is properly engineered there should never be a need to change it other than to maybe add functionality in a structured and backwardly compatible fashion for new types of device which were not envisioned when the original specification was produced.
ie. if the specification has to be changed incompatibily then whoever engineered the original needs a kick up the backside for not doing his/her job.
The problem with trying to produce such an interface specification is that it takes a great deal of effort and thought for somerthing which in the short term will only produce pain. Most developers of free software are unlikely to either put the effort in or have the political power to make it happen in the first place.
Long ago, in a time before Adware there once was a wonderful medium called IRC.
People used to talk inanely for days on it and, as long as you could find a server which was on the right network, wasn't full and hadn't split itself from the rest of the IRC network you could happily chat with your friends on #dl-bar or #gb or whatever (until someone decided that their ego was too great and booted most of the residents off it).
Today, however, the dreaded robot revolution has arrived. Hords of robotic critters are being controlled by a few, evil people in attempt to make money and destroy the world. That's where IRC is these days. There is no signal left, it's all noise and automatic control.
Just a minor correction to item (2) where you say:-
Or, conversely, if I own an iPod I can't play music downloaded from anyone other than Apple on it.
My iPod shuffle plays MP3s fine.
Though I guess that you're talking about other online vendors' DRM'd music files and no unencrypted MP3s.
Surely EMACS stands for Eventually Malloc's All Computer Store? :-)
If a file can't be created with cat(1) then it's not worth creating.
But, of course, the manufacturers will need to make two versions: US-Letter sized for the USA and A4 for the rest of the world. :-)
Actually, maybe a third version for the legal industry as well.
Oh, I missed that bit. Even so, there is, of course the chance that the bug which killed the driver the first time will trigger its replacement's demise because of the same conditions applying.
:-)
Of course, the OS could have two different drivers for each critical bit of hardware which were independently developed so that if one crashes the other gets loaded... but that silly.
Oh yes, I agree. I'm not saying that it's a bad idea, merely that the way it was presented was a misreprisentation of the benefits.
It's always a good idea to compartmentalise code as much as possible so as to try to prvent bugs in one part killing the whole thing.
Oh, indeed, but the quote given gave the impression that it was a magic bullet which would stop device drivers bringing a system to its knees.
Now, as a friend pointed out to me, having the device drivers as user-mode processes allows for easy maintenance and upgrade of the system on the fly. That's just one advantage (as well as enforcing a standard, thought through binary programming interface for drivers which Linux sorely lacks).
By the way, please ignore the attrocious spelling and typing today.
:-)
Here's how to patch my posting...
s/ on / in / if (/denial.$/);
s/qestion/question/
s/denigh/deny/
For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs.
This is all well and good until the crashing device driver locks the system bus or grams an NMI etc. And what if the device driver in qestion is the one accessing the disk? How does the microkernel recover from that one when it can't access the drive the device driver is sitting upon?
I can see where his thought processes are coming from, but I still think he lives in Computer Science Heaven, I'm afraid, where all hardware is mathematically perfect and I/O never happens (as it's not mathematically provable).
In the real world device drivers hardly ever crash the system 'cos they're kernel mode, they crash it because the hard-hang the system or denigh the kernel the resources to dig itself out of the hole. Neither of these change by moving the code into user space.
The test you saw was the emergency deployment when all hydraulic power has been lost and not normal deployment.
In the case of a complete hydraulics failure the crew can actuate a manual lever which unlocks the undercarrage and deploys it using only gravity to do so. This is what you saw.
Normally, the doors and the undercarrage itself are driven fully by the hydraulic system and the doors are never touched by the wheels or anything else.
That episode aired in the UK.. in fact we got all the episodes, in order. Firstly on Skay One and recently on UK SciFi (which no-longer has links with the US SciFi channel, unfortunately).
In fact, this weekend UK SciFi channel are having a marathon showing with Joss and the crew introducing the whole event. This probably isn't surprising as UK SciFi channel is owned by Universal Studios.
KDE Version 1 was nice, lean, clean and fast. It worked wonderfully on old kit such as Sun SPARCstation 2s etc.
KDE version 2 started eating memory and resources because it added a whole lot of underlying engineering, most of which a technical user who doesn't use it as just a desktop to manage xterms and other X programs doesn't use. You needed at least a Sun Ultra 1 with 256MB of RAM for it to be useful.
KDE version 3 increased the overhead quite a bit and increased the disk usage a lot. Unless you had a 440MHz Sun Ultra 10 with half a gig of RAM it's painful.
I'm guessing that KDE 4 won't even run on platforms which don't use an X server without the new Xorg server extensions and a gigahertz processor or two.
You may ask yourself why I'm not talking about the power of PC's running Linux as a comparison against which to judge the different versions.. well, firstly, KDE is supposed to be fully cross (unix-like) platform. Secondly, we're a mostly Sun shop for the research side of things here, with Linux increasing in number, but because of the extended nature of machine replacement in academia I still have to support and run 8-10 year old machines. To me, being able to run a reasonably modern desktop for my users is important. KDE used to be the ideal replacement for the really increadibly crummy CDE which comes with Solaris.. it's getting harder and harder to keep it running on the old hardware.
Would that second item be the same as "Safe Mode with Command Prompt"? If it is then it's already too late.
I'm guessing that because the only way the NT kernel know how to ready the filesystem is by loading the ntfs drivers it'll also load the nasty drivers installed by the root kit.
Am I right in thinking that the recovery console is specific to each machine?
If it is then it's unmanagable for anything other than a very few machines managed by a single person, rather than the various user machines which I first see when they turn up with their laptop with a problem.
The main problem when trying to get rid or detect rootkits on Windows XP/Server 2003 is that the "Safe Mode" is not at all safe at all.
By the time the system has booted far enough to get into "Safe Mode" it's already loaded so many DLL's, including the obfucating rootkit ones, that there's no way of accessing the filesystem to see the malware.
Now, if Microsoft had added a single-tasking, statically linked command line emergency system which would allow you to just manipulate an NTFS filesystem this would be the greatest step forward in rootkit/malware removal.
Alternatively, "Safe Mode" should load only those DLL's which are hard coded into the kernel to load, along with signatures and checksums to make sure (as much as you can) that those files haven't been tampered with.
As it is, the only way I've found of de-rootkitting machine is using Knoppix 3.6 and captive-NTFS!
Yes, it's only pointers (plus the extra data transfer upon process context switch due to the extra size and number of registers) which changed size.
However, the program code itself will have a lot more 64bit addresses in it (which means that the "instruction cache" size is effectively reduced) plus as soon as you start using linked lists or function look-up tables you're into lots of pointer work, which effectively reduces the "data cache". (I'm using quotes as the cache is unified on the AMD64 processors, but the effect is to for all intents and purposes to reduce the effective cache size.)
Myself, I've not seen a great number of x86_64 binaries go quicker at all. This is both under Linux with GCC and Portland C compilers with all the optimisations I can throw at it switched on and under Solaris x86 with GCC and Studio 10 compilers.
For purely integer code on our v40z's, v20z's and W2100z machines there seems to be a 50% drop in speed, for floating point scientific code generally a bit less. This is the same for FORTRAN as well. These are all Opteron with dual channel memory.
I've tried similar on an Athlon64 machine with single channel memory and the performance drop is far greater.
All the advantages of the extra registers seems to be offset by the extra memory overhead at the moment, at least on the codes we run.
Of course, when you port the application to a 64bit environment you have to start worrying about data type sizes and the way the application reads and writes the files stored on disk.
There's always the problem of having to do type conversions so as to make sure that the data types in the files are the same size as the other architectures produce. Admittedly, it helps that GCC on x86 and x86_64 both use the same sizes for native integer types (short, int, long) but this isn't always the case. (DEC Alpha OSF/1 used 64 bit longs which messed up a lot of programs.) However, there is still the problem of data alignment and padding in structures.
Unless you want to have a document which uses more than about 3GB of memory, what's the point of building it 64bit?
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Seeing as the Opteron/Athlon64/Turion64 run 32bit applications fast natively there's no actual point (other than religious) to build and run an office product (or, indeed, most other applications) in 64bit mode.
The problems with New Orleans runs far-far deeper than polluting etc.
New Orleans is placed on a river delta. After the sediments in a delta are deposited they are guaranteed to subside. It's a consiquence of compaction, de-watering and the isostatic response of the lithosphere below the basin to the extra load. Unless more sediment is added continuously the delta will eventually (and quite quickly in geological and indeed historical terms) sink beneath the sea.
When New Orleans was founded a few hundred years ago it was above sea level. (after all, who would found a town on a salt marsh?) Since then it's subsided continuously until today a great deal of the city is now below sea level and a great deal lower than the river (which has since built up its base by depositing sediment).
When the corps of engineers stopped the river naturally switching its channel (which it does around once every 1000 years) and straightened the current channel they put in motion a set of events which meant that the delta lost its sediment load to further out in the Gulf of Mexico as the river is flowing at a greater rate. This has caused the coastline (and all the natural defences) to not be replenished and go below the sea.
You may like to see this google cached article from a Baton Rouge newspaper in 2002. It gives a decent overview of the situation.
As a geologist, I would be in the camp which suggests that the government take this as an opportunity to move the city to higher and more stable ground and abandon the old city to be an archaeological curiosity and tourist attraction. Rebuilding it would merely prime the charge for an even bigger loss of life when, not if, the river breaks its banks. This time only the low-level lake to the north broke through which soon equalised its level.. this wouldn't happen with the great river.
How long do you want to fight a losing battle with the planet? How high do you eventually want the levees to be before you give up? When the city's subsided to the point where it's an isolated bowl in the ocean?
I know it's not going to be abandoned, there are too many politicians who have staked their carreer on the "we will rebuild it" bravardo and a King Kanute attitude.
(Before anyone corrects me about King Kanute, I know that the popular story is wrong, the King was trying to show how impotent he was rather than believing that he could actually stop the sea.)
Windows can authenticate with a NIS server and mount users' home directories via NFS.
Though I might have to wait until the genetic engineers manage to fit wings onto pigs first.
Well, that reminds me of the old emacs joke:-
--:-- *scratch* (Lisp Interaction)--L5--All--
Loading vmunix.el... Done.
It is rather impressive to have an OS in a web browser though.. even if it's not exactly that useful.
And once that's done and a problem is found in the interface (which will always occur), what do you do then?
Then it's fixed in the next major release of the ABI specification. It's standard software engineering best practise. Poorly documented interfaces with super-sonic goalposts are a recipe for long-term disaster and/or stability. It also disuades people from contributing driver code because by the time they've developed their code the interfaces have changed or they have to keep re-engineering their code (which costs time/money) every couple of months.
For Linux, where the vast bulk of drivers are maintained in the kernel, by the kernel people, alongside the rest of the core kernel code, it doesn't make sense to spend time guaranteeing interfaces for a very few 3rd party drivers.
And the reason for this is....? The only people who can keep up to date with the kernel/driver interface or who can work out what that interface is are the people who know the insides of the kernel. If there were a standardised API even which was scrupulously documented it would be far easier for people who are not kernel developers to develop drivers.
- lobby your vendor for open-drivers and/or programming specifications for your hardware (cause then it can be integrated into Linux kernel, the kernel people will help maintain it, and other kernel's can benefit from having source/docs to look at to help implement their own drivers).
Commercial companies won't do this is they have to spend resources rewriting their driver every couple of months 'cos the kernel's changed. They're also far less likely to do this if they have to generate a binary driver version for each build each distribution produces for the majority of real users who don't know what a compiler is let alone how to build anything. (This is the target audience for Linux on the desktop, isn't it?)
It seems from what you have said that you'd prefer people who don't share your point of view about the Linux kernel and want to express their view about how the status quo is not good for the long-term survival to just go elsewhere. Well, they might just do that, along with most of the computer using masses. It's a big-picture thing.
Wow, Linux is dying!!! That's a new one on slashdot.
I didn't say that at all. I'm sure it'll continue to be used for a long-long time.. but not by the masses.