Actually, I'm not talking about hinting. Hinting is another possible solution to the same problem. The one I'm talking about is having a set of fonts specifically for screens. The fonts that M$ created are only being used in a few applications, I believe, and aren't widely known (I don't know their names). But this is definitely different than hinting. Hinting modifies the display of _existing_ fonts, it does not create new ones.
I'm not arguing that source distribution is a bad idea. I think its great. I'm probably close to RMS on this one. However, the idea that you can build a source driver from one kernel version to another is just not entirely true. One of the reasons that ReiserFS hasn't made it into the kernel is because it doesn't follow the API as well as it should. However, the reason that it doesn't follow the API is because the kernel API has not been stable enough to follow closely. Semantics of certain kernel function calls change even within minor releases of the kernel. In these cases, in order to work 100%, all drivers using these functions have to be updated to use the new semantics. Now, even with such changes, many source compiles will compile, build, and even work for a time, but if they aren't following Linus's changing semantics exactly, there could be a number of race conditions that result.
In addition, having a stable API forces you to examine the API in detail beforehand. Thus, you are probably more likely to come up with a reasonable, sensible API.
From an engineering perspective, stable APIs are always the best, because, even if you have to work around certain things, you always know what they are. Now, just because you have a stable API, doesn't mean that you can't come up with a new one. A kernel could have two separate APIs (I don't know if the HURD allows this, but it is possible) - one for old drivers and one for new. "But what about bloat". Well, its just like LIBC - if you want compatibility, build the old library too, if you don't, leave it out. With LIBC, you have 2 stable APIs, but you can junk either of them if you want to. The same could be done with a kernel.
If you don't have a stable API, a simple recompile does _not_ work. Even if it compiles, there is no guarantee without a stable API that it will work. Stable APIs have a number of advantages - the biggest of which is the further parralellization (I think I messed that word up) of development.
Also, remember that recompiling is something hackers, not users, do - even in free software.
You're missing the point. In HURD, the servers are in virtual memory, not physical memory. Therefore it _can_ write random chunks of memory.
Also, I think you're missing another point. In HURD, the kernel/user distinction is not very big. Each server is only given certain permissions, and it only has rights within that. Therefore, if you write and load kernel code, it still only operates within your permission set. I think the main difference between kernel/user code is the communication method.
Someone at microsoft implemented a better way than anti-aliasing. The problem with current fonts is that they are not made for the screen. When they are anti-aliased, they look fuzzy. You _can_ design fonts that don't need anti-aliasing, its just that they won't look like the fonts we're used to. Anyway, that seems like a great idea to me. I don't know if M$ is implementing it or not, but I do believe they figured it out. Could be the first real improvement they've made.
They didn't just compile it. The have internal versions of just about every package they ship. They keep track of patches for every package. If you look at the source RPMS, you will notice that there are several patches in there - certain ones are from the devel mailing lists, certain ones are from RH themselves. This is an _enormous_ job. They patch everything from the kernel to the C library, to the compiler, to X, to GNOME - EVERYTHING. So, its more than just packaging. They have to know how the whole thing works - every linker flag that could bite you in the butt, every bug for every package, all that stuff. And that makes them _very_ valuable.
X is a _great_ idea for businesses, even if it doesn't offer a lot of advantages for the home user. It certainly doesn't hurt them any. HURD actually is kind of revolutionary in OS design. The fact that it emulates UNIX is more of a compatibility deal than a design issue. The overall design of HURD is extremely modern. There are many reasons why it would be useful. And of course there are no guarantees about its usefulness (how many projects have usefulness guarantees attached?).
You mentioned security exploits. The reason that there are "more exploits for UNIX than Windows", is that people don't usually even look for console exploits on Windows, since they assume the console operator will be trusted. In UNIX, since it has the additional feature of allowing so much to be done through remote logins. If I wanted to make my OS a featureless as Windows, I would make it more secure as well.
Anyway, don't flame an OS just because it doesn't give _you_ any advantages. That's the beauty of the open source movement - there is such diversity. If something doesn't appeal to you, don't use it! But there are many people (including myself) anxiously awaiting HURD to emerge because it offers us a lot of useful features. Maybe HURD isn't for the desktop, maybe it is. So what! Not every OS is for the desktop. Some are for servers, some are for mainframes, some are for graphic designers, some are for home desktops. If you go to a "one size fits all" mentality, then the OS chosen will suck for everyone.
Data and code are separate in just about every current environment. The problem is the 1) the stack, and 2) that executable pages are marked as writeable. You can get rid of most buffer overflows by compiling everything with a program I believe is called StackGuard, or something like that.
I'm sorry, RMS has little to do with this. "Tell RMS to scrap it". Yeah, why don't we tell one of the current desktop projects to do the same (obvious sarcasm). The fact is, a number of people are working on the HURD, and its because they want to, not because RMS told them to. The HURD has a number of advantages over Linux. Let's look at a few
1) There are "servers" instead of "drivers". Why is this important? Servers have their own address space. So, what happens if my network driver decides to go ballistic? Just restart it. If that happens in Linux it's bye-bye system.
2) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
3) Much more flexible authentication system
4) The ability to emulate multiple environments (the current HURD has several servers that implement UNIX services (process list, scheduling, etc), but all of those are pluggable and/or removable. So, you can have as much or as little UNIX as you want, and you can have it on a per-process basis.
5) The HURD is much more extensively multithreaded, and _should_ scale better to multiple processors (note the _should_ - I'm kind of skeptical here. I think it'll take them a good amount of time to remove the bottlenecks).
6) Stable Kernel API. This is something that Linus has said he will _not_ do.
7) I _believe_ (please correct me if I'm wrong) that the HURD is being developed using CVS. Now, this isn't really a technical issue, but a management issue. Linus still maintains the kernel using his INBOX. That has worked well, but as the kernel grows in size, it works less and less well. HURD's development process allows for more distributed maintenance, rather than a single point. Using CVS also allows developers to get patches into the tree for multiple kernel versions. For example, if Linus had a CVS server, he'd open up a 2.5 branch now, so all new stuff can be put into 2.5, and bug fixes into 2.4. This sounds petty, but project management is a real issue, and I think the Linux kernel is reaching its limits in this area.
So, there you have it. Don't call something you don't understand a bunch of bunk. It really sounds lame.
The idea is consultancy. RedHat, being one of the biggest developers of Linux, is probably one of the best places to go to get developers for a Linux system. For example, anyone who buys Oracle Applications is free to modify the system themselves, yet Oracle has a huge business contracting out consultants for $500/hour to do modifications. The reason? Oracle built it, and they know best how to modify it. RedHat recently got a $1 million dollar contract to port the GCC/binutils/etc to a new platform. Why did they get the contract? Because they are _the_ people to go to. Its not about buying licenses, its about expanding technology, and noone can do it better than the ones who made it. I'm not saying that RedHat is the only one making Linux technology, but the more development time a company puts in, the better position they are in to say that they can handle extensions.
I know, I should read the Don't Feed the Troll signs, but I'll bite.
America was born on the subversion of intellectual property. We went from third-world to first-world because someone stole the plans to Britain's factories and built them here
In Linux, not everything is copied, but a lot is. That actually makes it better. For example, if I want to make an innovative OS in open-source-world, you can just take GNU/Linux and make your modifications, you don't have to start from scratch. In the closed-source role, if you want a new OS, you have to write everything from scratch or buy it - the C library, the compiler, interpreted languages, everything. That's a task no one company can really accomplish anymore (except M$). So, contrast the difference in development time through OSS and closed source, and you see immediately the benefit. Almost everything in life is copied, and simply altered a little. Even most great "inventions" are really that inventive.
The performance of Linux companies has to do more with the fact that this is such a new ball game than anything else. People simply haven't figured out that the way you make money here is not the same as elsewhere. The performance of Linux stock prices have nothing to do with reality.
OSS is actually more capitalistic than closed-source, because it honors physical property over intellectual property. Closed-source software tries to deny a user the right to his physical property based on vaporous claims of intellectual property. OSS is a remedy to that situation. Things can be sold because they are in limited supply, ideas shouldn't be because they can be copied without diminishing supply. Closed-source is trying to switch that around.
There isn't complete agreement in the scientific community that the ozone hole is different than usual. It could just be part of a cycle of openings and closings. However, there is one thing to take into consideration - who is behind outlawing CFCs. Turns out it is DuPont. They are one of the biggest backers of the CFC ban. Interestingly enough, they started this when their patent on CFCs was about to expire, and, lo and behold, they patented the alternative as well. So, the whole CFC scare is based on DuPont wanting to keep a monopoly on the freeon market. See
http://www.sweetliberty.org/issues/un/environmen t. htm under the section "Campaign Against CFCs"
and
http://www.junkscience.com/news/iccp.html
I think the point was, users shouldn't be doing any of these things anyway, whether using Windows or Unix. You don't have to train them to do these things because it isn't their job.
You're missing the point. Its not just that they are saying they won't provide an ISO, they are saying that others can't make it available for download (legally) themselves.
Why not use X terminals. Its the best way (TCO-wise) to handle large installations. It even makes it easy if someone needs a special installation, because they can just have a Windows box for their stuff, running Xceed or whatever to connect to the standard apps.
Actually, the post was about quality, not features. However, since you asked, I will give you features of Linux that I _think_ aren't in Windows (I know, I should check my facts, but I don't have an NT box anywhere near).
1) Logical Volume Management - The ability to
a) have "virtual" partitions that span disks
b) be able to grow or shrink these while the system is running
c) be able to make a "snapshot" - this allows you to make a copy of the system as it stands on a particular second, while the rest of the system keeps running. For example, the "tar" command will back up files as it comes across them, and if there are interfile dependencies - these will be toasted. But the snapshot feature allows you to back up everything simultaneously without stopping your system. This is actually a 2.4 feature, but it is very spiffy.
2) Standards-compliant and pluggable authentication. If I understand correctly, the only way Win2000 computers can authenticate is to other Windows servers. With Linux, the authentication methods are entirely pluggable, so you could come up with your own authentication method if you wished.
3) Ability to run without the GUI. I've actually heard of being able to do this with NT4 (by setting shell to explorer.exe in win.ini), but I imagine that you can't do much once you're there. No matter what kind of machine you are running on, it will run faster without a GUI, and will run much stabler (or whatever that adjective is) because graphic drivers cause much of NTs problems.
4) Run diskless X-terminals. As far as manageability and TCO, nothing beats terminals. Windows has started to have this, with Windows Terminal Server, but I'm told that there are lots of problems. X was made to run this way, so you don't run into the same problems (until you start doing games with sound or 3-D graphics, but then you wouldn't care about TCO in those situations anyway). Also, note that it doesn't take a lot of horsepower for Linux to do this. I do this on my home computer, where the server is a PII-200 with 64M, where it is running both my wife's stuff (the server is actually her desktop), and my stuff that I'm running on a diskless machine.
Windows has some advantages, too. For example,
1) They've made it easier to manage the network from a single console. Netware actually has had this forever, but I'm told that Microsoft's has started to work well.
2) It is easier to set up the most common case. However, this has a converse, in that slightly more complicated cases are a real pain to set up. With Linux, in just 3 days I was able to set up a system for my boss that did Web hosting for multiple domains that he could run himself (no experience except Win9x). In fact, I've been gone from the company for over a year, and he hasn't had to find a sysadmin yet.
Anyway, I'm probably missing arguments from both sides, so please add your responses with the stuff I missed!
The same arguments have been made against free software for a long time. Why do you think its any different for documentation? There are many people who enjoy writing documentation (including myself). The arguments that you put forth are the same ones that were put forth a few years ago against free software. Free things use a different dynamic than non-free things. I'm guessing that in the next few years, several teachers will post their lecture notes on line in a free way. Someone else will correct problems, edit them for their own needs, etc. Just because _you_ would not participate in free documentation does not mean that others wouldn't.
Actually, a lot of GPL software has _great_ documentation. The GCC manual has about 600 pages of great material, covering a lot of the compiler's internals. The GNOME project likewise has wonderful documentation, including Havoc's book. I don't see where you get the idea the GPL discourages documentation
Most of your points are correct, though not all. Device drivers going berserk isn't really a problem, unless its your root hard drive. That's one of the big differences. If my Linux network driver starts doing random things, that's all she wrote. When HURD is finished, that driver can muck up all it wants, and all it will hurt are my network services. In addition, I can probably just unload and reload the driver to get it working again. This actually works in Linux if the problem is that a driver stops functioning (not if it tries to randomly write memory pages it doesn't own). Unloading and reloading drivers have fixed many network problems in my day. One of the goals of HURD is to reduce the dependencies on each component, so this will be even more true (for example, you might be able to have multiple process servers).
If all you're going for is modular, then Linux is a microkernel. The distinction is, "what happens when a kernel service goes beserk?". In monolithic kernels, the kernel goes "Oops". In a microkernel, nothing really happens to the other kernel services.
The difference with HURD is that regular users can run kernel servers without causing security problems.
Also, most microkernel architectures simply have a single server running on top of the microkernel (like mkLinux). However, even though they are using a microkernel, all of the pieces are very tightly bound together. The idea behind HURD is to come up with services that are generic enough that any of them can be easily replaced/substituted/whatever not only system-wide, but per-application as well. With Darwin, even though it is microkernel based, I believe you still have to go through the UNIX subsystem. With HURD, you can go through any subsystem you want, even create your own.
While many people claim that free software is simply re-implementing someone else's software, the HURD seems to be pretty original.
Microsoft holds no one anymore hostage than Standard Oil. You want to drive a normal car, you buy gasoline. You want to operate a normal business computer, you run Office. Heaven forbid
anyone pays $10/month for productivity software! There goes the EverQuest budget!
Software is not like gasoline. Microsoft does not have to do more production to give me another year's use out of my software. With gasoline, standard oil has to produce every single bit of gas I use. With software, its totally different.
If you truly think this is a bad model of doing business, please don't pay that cable/dss bill this month.
Yet again, this is totally different. A valid comparison would be "if you think this is a bad model, don't pay for watching videos you've previously recorded". I record T.V. shows. If I cancelled my subscription to cable, I would still have all of my existing T.V. shows, and be able to fully use them. Making faulty comparisons is at the heart of the current problem with software an "intellectual property" in general.
Slashdot Mirror
Actually, I'm not talking about hinting. Hinting is another possible solution to the same problem. The one I'm talking about is having a set of fonts specifically for screens. The fonts that M$ created are only being used in a few applications, I believe, and aren't widely known (I don't know their names). But this is definitely different than hinting. Hinting modifies the display of _existing_ fonts, it does not create new ones.
I'm not arguing that source distribution is a bad idea. I think its great. I'm probably close to RMS on this one. However, the idea that you can build a source driver from one kernel version to another is just not entirely true. One of the reasons that ReiserFS hasn't made it into the kernel is because it doesn't follow the API as well as it should. However, the reason that it doesn't follow the API is because the kernel API has not been stable enough to follow closely. Semantics of certain kernel function calls change even within minor releases of the kernel. In these cases, in order to work 100%, all drivers using these functions have to be updated to use the new semantics. Now, even with such changes, many source compiles will compile, build, and even work for a time, but if they aren't following Linus's changing semantics exactly, there could be a number of race conditions that result.
In addition, having a stable API forces you to examine the API in detail beforehand. Thus, you are probably more likely to come up with a reasonable, sensible API.
From an engineering perspective, stable APIs are always the best, because, even if you have to work around certain things, you always know what they are. Now, just because you have a stable API, doesn't mean that you can't come up with a new one. A kernel could have two separate APIs (I don't know if the HURD allows this, but it is possible) - one for old drivers and one for new. "But what about bloat". Well, its just like LIBC - if you want compatibility, build the old library too, if you don't, leave it out. With LIBC, you have 2 stable APIs, but you can junk either of them if you want to. The same could be done with a kernel.
If you don't have a stable API, a simple recompile does _not_ work. Even if it compiles, there is no guarantee without a stable API that it will work. Stable APIs have a number of advantages - the biggest of which is the further parralellization (I think I messed that word up) of development.
Also, remember that recompiling is something hackers, not users, do - even in free software.
You're missing the point. In HURD, the servers are in virtual memory, not physical memory. Therefore it _can_ write random chunks of memory.
Also, I think you're missing another point. In HURD, the kernel/user distinction is not very big. Each server is only given certain permissions, and it only has rights within that. Therefore, if you write and load kernel code, it still only operates within your permission set. I think the main difference between kernel/user code is the communication method.
Someone at microsoft implemented a better way than anti-aliasing. The problem with current fonts is that they are not made for the screen. When they are anti-aliased, they look fuzzy. You _can_ design fonts that don't need anti-aliasing, its just that they won't look like the fonts we're used to. Anyway, that seems like a great idea to me. I don't know if M$ is implementing it or not, but I do believe they figured it out. Could be the first real improvement they've made.
They didn't just compile it. The have internal versions of just about every package they ship. They keep track of patches for every package. If you look at the source RPMS, you will notice that there are several patches in there - certain ones are from the devel mailing lists, certain ones are from RH themselves. This is an _enormous_ job. They patch everything from the kernel to the C library, to the compiler, to X, to GNOME - EVERYTHING. So, its more than just packaging. They have to know how the whole thing works - every linker flag that could bite you in the butt, every bug for every package, all that stuff. And that makes them _very_ valuable.
X is a _great_ idea for businesses, even if it doesn't offer a lot of advantages for the home user. It certainly doesn't hurt them any. HURD actually is kind of revolutionary in OS design. The fact that it emulates UNIX is more of a compatibility deal than a design issue. The overall design of HURD is extremely modern. There are many reasons why it would be useful. And of course there are no guarantees about its usefulness (how many projects have usefulness guarantees attached?).
You mentioned security exploits. The reason that there are "more exploits for UNIX than Windows", is that people don't usually even look for console exploits on Windows, since they assume the console operator will be trusted. In UNIX, since it has the additional feature of allowing so much to be done through remote logins. If I wanted to make my OS a featureless as Windows, I would make it more secure as well.
Anyway, don't flame an OS just because it doesn't give _you_ any advantages. That's the beauty of the open source movement - there is such diversity. If something doesn't appeal to you, don't use it! But there are many people (including myself) anxiously awaiting HURD to emerge because it offers us a lot of useful features. Maybe HURD isn't for the desktop, maybe it is. So what! Not every OS is for the desktop. Some are for servers, some are for mainframes, some are for graphic designers, some are for home desktops. If you go to a "one size fits all" mentality, then the OS chosen will suck for everyone.
Data and code are separate in just about every current environment. The problem is the 1) the stack, and 2) that executable pages are marked as writeable. You can get rid of most buffer overflows by compiling everything with a program I believe is called StackGuard, or something like that.
I'm sorry, RMS has little to do with this. "Tell RMS to scrap it". Yeah, why don't we tell one of the current desktop projects to do the same (obvious sarcasm). The fact is, a number of people are working on the HURD, and its because they want to, not because RMS told them to. The HURD has a number of advantages over Linux. Let's look at a few
1) There are "servers" instead of "drivers". Why is this important? Servers have their own address space. So, what happens if my network driver decides to go ballistic? Just restart it. If that happens in Linux it's bye-bye system.
2) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
3) Much more flexible authentication system
4) The ability to emulate multiple environments (the current HURD has several servers that implement UNIX services (process list, scheduling, etc), but all of those are pluggable and/or removable. So, you can have as much or as little UNIX as you want, and you can have it on a per-process basis.
5) The HURD is much more extensively multithreaded, and _should_ scale better to multiple processors (note the _should_ - I'm kind of skeptical here. I think it'll take them a good amount of time to remove the bottlenecks).
6) Stable Kernel API. This is something that Linus has said he will _not_ do.
7) I _believe_ (please correct me if I'm wrong) that the HURD is being developed using CVS. Now, this isn't really a technical issue, but a management issue. Linus still maintains the kernel using his INBOX. That has worked well, but as the kernel grows in size, it works less and less well. HURD's development process allows for more distributed maintenance, rather than a single point. Using CVS also allows developers to get patches into the tree for multiple kernel versions. For example, if Linus had a CVS server, he'd open up a 2.5 branch now, so all new stuff can be put into 2.5, and bug fixes into 2.4. This sounds petty, but project management is a real issue, and I think the Linux kernel is reaching its limits in this area.
So, there you have it. Don't call something you don't understand a bunch of bunk. It really sounds lame.
The idea is consultancy. RedHat, being one of the biggest developers of Linux, is probably one of the best places to go to get developers for a Linux system. For example, anyone who buys Oracle Applications is free to modify the system themselves, yet Oracle has a huge business contracting out consultants for $500/hour to do modifications. The reason? Oracle built it, and they know best how to modify it. RedHat recently got a $1 million dollar contract to port the GCC/binutils/etc to a new platform. Why did they get the contract? Because they are _the_ people to go to. Its not about buying licenses, its about expanding technology, and noone can do it better than the ones who made it. I'm not saying that RedHat is the only one making Linux technology, but the more development time a company puts in, the better position they are in to say that they can handle extensions.
There isn't complete agreement in the scientific community that the ozone hole is different than usual. It could just be part of a cycle of openings and closings. However, there is one thing to take into consideration - who is behind outlawing CFCs. Turns out it is DuPont. They are one of the biggest backers of the CFC ban. Interestingly enough, they started this when their patent on CFCs was about to expire, and, lo and behold, they patented the alternative as well. So, the whole CFC scare is based on DuPont wanting to keep a monopoly on the freeon market. See
n t. htm under the section "Campaign Against CFCs"
http://www.sweetliberty.org/issues/un/environme
and
http://www.junkscience.com/news/iccp.html
for more information
I think the point was, users shouldn't be doing any of these things anyway, whether using Windows or Unix. You don't have to train them to do these things because it isn't their job.
You're missing the point. Its not just that they are saying they won't provide an ISO, they are saying that others can't make it available for download (legally) themselves.
Why not use X terminals. Its the best way (TCO-wise) to handle large installations. It even makes it easy if someone needs a special installation, because they can just have a Windows box for their stuff, running Xceed or whatever to connect to the standard apps.
That's strange... my company only pays about 30k/year for Unix admins.
Actually, the post was about quality, not features. However, since you asked, I will give you features of Linux that I _think_ aren't in Windows (I know, I should check my facts, but I don't have an NT box anywhere near).
1) Logical Volume Management - The ability to
a) have "virtual" partitions that span disks
b) be able to grow or shrink these while the system is running
c) be able to make a "snapshot" - this allows you to make a copy of the system as it stands on a particular second, while the rest of the system keeps running. For example, the "tar" command will back up files as it comes across them, and if there are interfile dependencies - these will be toasted. But the snapshot feature allows you to back up everything simultaneously without stopping your system. This is actually a 2.4 feature, but it is very spiffy.
2) Standards-compliant and pluggable authentication. If I understand correctly, the only way Win2000 computers can authenticate is to other Windows servers. With Linux, the authentication methods are entirely pluggable, so you could come up with your own authentication method if you wished.
3) Ability to run without the GUI. I've actually heard of being able to do this with NT4 (by setting shell to explorer.exe in win.ini), but I imagine that you can't do much once you're there. No matter what kind of machine you are running on, it will run faster without a GUI, and will run much stabler (or whatever that adjective is) because graphic drivers cause much of NTs problems.
4) Run diskless X-terminals. As far as manageability and TCO, nothing beats terminals. Windows has started to have this, with Windows Terminal Server, but I'm told that there are lots of problems. X was made to run this way, so you don't run into the same problems (until you start doing games with sound or 3-D graphics, but then you wouldn't care about TCO in those situations anyway). Also, note that it doesn't take a lot of horsepower for Linux to do this. I do this on my home computer, where the server is a PII-200 with 64M, where it is running both my wife's stuff (the server is actually her desktop), and my stuff that I'm running on a diskless machine.
Windows has some advantages, too. For example,
1) They've made it easier to manage the network from a single console. Netware actually has had this forever, but I'm told that Microsoft's has started to work well.
2) It is easier to set up the most common case. However, this has a converse, in that slightly more complicated cases are a real pain to set up. With Linux, in just 3 days I was able to set up a system for my boss that did Web hosting for multiple domains that he could run himself (no experience except Win9x). In fact, I've been gone from the company for over a year, and he hasn't had to find a sysadmin yet.
Anyway, I'm probably missing arguments from both sides, so please add your responses with the stuff I missed!
The same arguments have been made against free software for a long time. Why do you think its any different for documentation? There are many people who enjoy writing documentation (including myself). The arguments that you put forth are the same ones that were put forth a few years ago against free software. Free things use a different dynamic than non-free things. I'm guessing that in the next few years, several teachers will post their lecture notes on line in a free way. Someone else will correct problems, edit them for their own needs, etc. Just because _you_ would not participate in free documentation does not mean that others wouldn't.
Actually, a lot of GPL software has _great_ documentation. The GCC manual has about 600 pages of great material, covering a lot of the compiler's internals. The GNOME project likewise has wonderful documentation, including Havoc's book. I don't see where you get the idea the GPL discourages documentation
Most of your points are correct, though not all. Device drivers going berserk isn't really a problem, unless its your root hard drive. That's one of the big differences. If my Linux network driver starts doing random things, that's all she wrote. When HURD is finished, that driver can muck up all it wants, and all it will hurt are my network services. In addition, I can probably just unload and reload the driver to get it working again. This actually works in Linux if the problem is that a driver stops functioning (not if it tries to randomly write memory pages it doesn't own). Unloading and reloading drivers have fixed many network problems in my day. One of the goals of HURD is to reduce the dependencies on each component, so this will be even more true (for example, you might be able to have multiple process servers).
Point of clarification. I'm not saying Linux is a microkernel, I'm just saying that you can't judge being a microkernel on modularity alone.
If all you're going for is modular, then Linux is a microkernel. The distinction is, "what happens when a kernel service goes beserk?". In monolithic kernels, the kernel goes "Oops". In a microkernel, nothing really happens to the other kernel services.
The difference with HURD is that regular users can run kernel servers without causing security problems.
Also, most microkernel architectures simply have a single server running on top of the microkernel (like mkLinux). However, even though they are using a microkernel, all of the pieces are very tightly bound together. The idea behind HURD is to come up with services that are generic enough that any of them can be easily replaced/substituted/whatever not only system-wide, but per-application as well. With Darwin, even though it is microkernel based, I believe you still have to go through the UNIX subsystem. With HURD, you can go through any subsystem you want, even create your own.
While many people claim that free software is simply re-implementing someone else's software, the HURD seems to be pretty original.
Software is not like gasoline. Microsoft does not have to do more production to give me another year's use out of my software. With gasoline, standard oil has to produce every single bit of gas I use. With software, its totally different.
If you truly think this is a bad model of doing business, please don't pay that cable/dss bill this month. Yet again, this is totally different. A valid comparison would be "if you think this is a bad model, don't pay for watching videos you've previously recorded". I record T.V. shows. If I cancelled my subscription to cable, I would still have all of my existing T.V. shows, and be able to fully use them. Making faulty comparisons is at the heart of the current problem with software an "intellectual property" in general.
The source and binaries are easily downloaded here:
d .html
http://www.OpenOffice.org/dev_docs/source/downloa
These are the source and binaries for StarOffice 6 (devel version, but very stable).