You know the Man I'm taking about. He's the Man who won't let a "TV-M" rated show play until after 10 pm.
He's the same man that says the word "fart" makes a formerly PG show get a TV-M rating.
Hmmm... so let me get your point straight... you are saying Parker's hands should be tied because ABC's hands are tied... because of The Man.
Yes, censorship does have it's place, but there's a subtle difference between playing pornography on prime time TV and "Blame Canada". Maybe this gives us the chance for Americans to question their (somewhat conservative) assumptions about censorship on television. As a Canadian, I find it funny at time just how overly prudent your networks are. Ah, but you can always blame me... I'm Canadian.
Re:What's wrong with reference counting?
on
The New Garbage Man
·
· Score: 1
Question: is this OpenStep or Objective-C? At any rate, you still aren't saved from circular references.
Let's say you had a function LinkedList *CircularLinkedList() that returns a circular linked list.
c = CircularLinkList();
OK. The count of the first element in the list is incremented. No problem. You do some processing, then you do
free(c);
the first element in the linked list has it's reference count decreased. It's count is now 1. And it will remain 1 even though the guy who is refering to him is unreferencable!!!
This is a general failure of reference-counting techniques. There are other shortcomings, including extra space to keep track of ref. counts, and keeping track of the counts them selves. Think about: every time a pointer is assigned, passed to a function, or returned from a function, you need to increment or decrement some counter *somewhere* in memory. And this can't be parallelized like mark&sweep can and run when your main process it waiting - it takes a hit on the main process itself.
It may work "OK", but better methods have long since been developed. I hope that I've explained this well, but if you still think reference counting is good, then obviously I haven't.... because this isn't a contencious point.
Re:What's wrong with reference counting?
on
The New Garbage Man
·
· Score: 1
if you had:
struct LinkedList { LinkedList *next; };
LinkedList *a, *b;
a = new LinkedList; b = new LinkedList;
a->next = b; b->next = a;
Then you never used a or b again, a reference-counting GC wouldn't be able to collect them: both have a non-zero reference count!
Considering that circular linked lists *do* happen, this is a BAD thing.
1) This *IS* a hardware solution - read the article before replying. 2) This doesn't counter RISC philosophy (ie many RISC chips have test&set bit instructions) 3) GC *IS* good. GC is for incompetant programms just like "High-level" languages such a C were for incompetant programmers in the 1970's and 80's.
A lot of the posters here don't seem to get it. Two things to keep in mind:
1) Garbage collection is good for two reasons: i) You simplify your interfaces. W/o garbage collection, your interfaces need to be designed to keep track of what has or hasn't been allocated. This makes programmer simpler. If you don't use GC, you essentially are "reference counting", which is one of the worst performing GC algorithms, in fact. ii) You'll have fewer memory leaks. Memory leaks are difficult, often impossible to detect in large applications. W/o GC, the amount of memory leaked is unbouded in the program size. With GC, you can formally prove that memory leaks will remain bounded.
So with all these good thing going for GC, why is it not commonly used?
1) It is often slower. 2) It's not a standard part of C/C++. (But it is in Perl, Java and just about every other "modern" language).
The hardware knows when a reference/pointer is used. Software often doesn't and has to rely on techniques like reference counting or mark&sweep. This would be a *lot* easier if a few simple hardware hacks were throw in (not too many transistors). Remember, b/c of Moore's Law, CPU makers have more transistors than they know what to do with. It's kind of like "test and set bit"... implementing this in hardware is waaay easier than implementing locks in software.
As for #2, well talk to Bjarne about that...apparently the man can do no wrong, if you ask him...
Yes, it is brain-dead. I could write a "C--" language which only used the "." operator. Using type analysis in my context-senstive analysis, I could replace the "." with a "->" when necessary, and output code that a normal C compiler could generate.
So why does C have a "->" operator anyways? Because it's brain-dead.
In my experience, much of the unavoidable complexity of C++ comes from the fact that you can use either pointers or references to refer to objects.
Note the distinction between "unavoidable" complexity and the avoidable complexity of templates and multiple inheritance - often you can't get around this.
References are nice because the "->" operator is brain-dead: why should the programmer keep track if something is a pointer or not when a type-safe compiler can figure out if "." or "->" is suitable.
But references, unforutnately, can't be used everywhere. The lack of an ABI might be one reason. The fact that Linux/Unix only has 'C' style interface is another, related reason. (NB: Windows _does_ have MFC to abstract OS functionality, if you want it. From what I hear, it doesn't abstract that functionality very well, though...).
But you sometimes have to mix pointers and references for the simple reason that you can't re-assign references. In code, this might be no problem, but what about classes?
Another unavoidable complexity deals with the language's decision not to have proper "interface"/"implmentation" files. On one simplistic level, it means I have to unnecessarily type in:
#ifndef __MY_HEADER_H__ #define __MY_HEADER_H__
...
#endif
But there are other annoyances. For example, you can't statically initialize static member variables! To be honest, you can, but not the way that a programmer would naively expect:
class { static int foo = {1,2,3,4}; };
just doesn't work.
Things like this are the gravest error a language designer can make: if the language doesn't work in the way a naive programmer would expect, you *need* to become experienced and learn the special cases.
Re: bloatedness. Stroustrup makes the assertion that if you use C++ right, you won't have bloated code. With G++ at least, it is difficult to use STL in *any* way without bloating your code. Perhaps this is a shortcoming of g++ rather than C++. However, I think that the design of C++ makes it difficult for compiler writers to make efficient STL code.
In some sense, I feel like C++ is like Windows: people use it because they have to, not because they want to. And "have to" doesn't mean it's imposed, sometimes it just means that tools have been developed for it that are unavailable elsewhere. In many languages, I simply can't use yacc, makedepend, the Unix API, etc, etc.
C++ does not have built-in support for multithreading. The unfortunate thing about this is that there are some threading features that can only be implemented by a compiler. In particular, I'll point to monitors - they can very neatly abstract away semaphores by implicitly placing a semaphore on methods. Nifty features like wait conditions can be a very useful tool. As multithreaded software becomes more common, will C++ be extended to include monitors as part of the language?
Hmmm... how can these be distinct when theyre is obviously an overlap between The Corporate Internet and BuyNet as well as BuyNet and CultureNet. Slashdot is really a CultureNet, not a TechNet. It just happens to be a CultureNet for TechNet-type people. Likewise, GameNet is a CultreNet for people who belong to the Game Culture. Similar to GodNet. Moreover Slashdot is a weblog, so by your definition that makes it a part of Undernet. But from what I understand CmdrTaco and Hemos live above ground, so it's not exactly subterranian, now, is it?
Oh, yeah, and hyperlinks join all of them together. Maybe "old media" transposed onto CorporateNet (or was that CultureNet?) hasn't quite figured out hyperlinks yet, that day is coming (or did come when CorporateNet/XNet/BuyNet AOL bought CultureNet/InfoNet/CorporateNet TimeWarnet).
History is re-written by the victors, and the victors have lied to you about why the console market crashed after the 2600.
Yup, it's because Atari decided to bet the future on desktops rather than consoles.
Yup, it's because console games started to suck - because developers were focusing their attention elsewhere. The question is where?
The answer that no one wants to tell you is that console gaming died because of one little thing:
LOAD "*",8,1
That's right. The Commodore 64 killed the Console Star. Here was a computer - with all the educational connotations that go along with it - that wasn't as high-priced as the expensive Apple II or luxurious Macintosh. It didn't cost that much more than a console, and parents got duped into thinking that it might be much more educational to their kids than a dummy console. By 1984, the Commodore 64 was the king of home computers.
Of course, little did the parents know that most kids wouldn't know how to do anything more than LOAD "*",8,1.
But Commodore failed to innovate the 64 line. It wasn't expandible. The 128 was a dud. Commodore US tried to position the Amiga as a business computer. By 1986 cheap PCs took out the 64 on the high-end and Nintendo was taking out the 64 on the low end.
Don't let the ignoramuses rewrite history. Atari died at the hands of Commodore long before Nintendo ever walked on the scene.
Have you done and Xlib programming? X is a bloated best!!!
To compare, on the Amiga GUI message passing was neatly handled by a small number of primitives:
PutMsg GetMsg ReplyMsg WaitMsg
To boot, these were also used for I/O, and most other inter-processes communication.
On X, there are something like 10 functions and macros to duplicate many (but not all) combinations of these primitives. I was hurt when I first started writing X windows programs.
Also, it isn't immediately obvious how X's message passing ties in with the rest of the system. There were more than a few X programmers who were surprised to hear they could get a file handle for the X message stream.
And I haven't even started talking about fonts, stored bitmaps or (ugh) colour-management.
If anything, I wouldn't be surprised if display PDF provided a much much cleaner interface than X.
As co-maintainer of the comp.ai FAQ, I've come across a number of different open-source speech-recognition products.
The ISIS group at Mississippi State have a DARPA grant to create a fully public domain speech recognition system. A pre-alpha version of the software is available from: this site.
A student in Quebec is also working on a speech recognition system, although it seems as if only some basic signal processing stuff is done at this point. Follow this link for more information.
When I said, "this isn't the first step toward capitalism," I meant communism. As another poster said, the proletariat may overthrow the bourgeousie for doing this.... but they'll do it by pointing their browser to yahoo.com or even (as I we) slashdot.org... not by overthrowing the capitalist state. Choices, my friend.
Now all I need is a DSL connection and digital satalite TV dammit!:)
Listen: DSL is *way* behind cablemodem, and MS and AT&T effectively blocked AOL out of the cablemodem market.
If AOL didn't have access to cablemodem, it wouldn't have access to broadband. If it didn't have access to broadband, it DIES.
Yes, I don't like concentration of services in a single firm as much as the next guy... but understand that it's more SCARY for AOL-Time Warner's shareholders than for consumers. Look at the executives: there's a Chairman & Vice Chairman and two Co-COO's. That's confusing - there are TOO MANY managers, and (I expect) the firm will compete poorly with smaller, nimbler rivals. No, this isn't the first step toward capitalism, it's the first step toward decreased revenue & profit growth for the combined firm. (BTW studies have shown time and time again that recently merged firms do worse than the individual firms did before the merger).
AOL *needed* to do this (and may try to buy it's way into more broadband). And no, I think we don't have anything to fear from the combined firm. With the exception of TW's cable customers, this firm isn't any kind of monopoly.
Bootstrapping is this: a group of researchers develop a set of tools designed to improve (er, "augment") human intelligence. This is equivalent to the economist-speak of "improving productivity."
These researchers then use the results of their research (an "augmentation system") to make them more efficient in doing their research!
The end result is that augmentation systems (what we now call "computers attached to the internet") that conform to information ergonomics (meaing easy-to-use and easy-to-understand) help us to spiral our intelligence upwards.
The results of the research can then be used by other groups (who may in turn make innovations that others again can use).
It's an interesting idea. I have two critiques, however. First, I think this already happens to some extent... but it's true that researchers are not focused on it. Hence the 20 year lag between Engelbart's augmentation system and the WWW. Hence, there haven't been any major breakthroughs in the way we use computers to store information for our use. (The WWW+search engines, or relational databases, or OO databases, or expert systems are all far from any kind of Nirvana of information storage).
Second, if Englebart really wants his ideas to change the business & social landscape, he needs to use language that is accessible (ie "ergonomically designed information").
Ah, there are a few more interesting things that I could go on talking about, but I'll leave it there:)
When they say Englebart invented "bootstrapping" I got the drift that they weren't talking about loading a kernel into RAM.
One of the sites I jumped to says bootstrapping is "finding what you need to know to innovate, learning it, then innovating." OK. Makes sense. But I think it goes deeper than that. Another site talks about how the idea of bootstrapping may fundamentally change our social institutions and allow greater social progress (that's when I clicked they weren't talking about booting a computer:). Yup, this will happen by boosting our collective IQ... but what exactly does that mean?
I can see broadly what they're saying on a general level, but, to use a technical term from mathematics... there seems to be a lot of arm waving going on. Can someone help me out here?
I don't think it has anything to do with the Great Jihad against Microsoft.
I'm now accustomed to thinking about everything like an economist, so here is my economic analysis (kinda summarizing what other posters have said).
Microsoft had a monopoly in operating systems. When you got a computer, there was DOS for "free". Of course, the OEM was paying for it, but you couldn't really tell.
The monopoly caused market failure. A competitive market would have seen many different OS manufacturers in a monopolistic competition. What monopolistic competition means is that each OS supplier tries to target a slightly different market. To some extent, this *was* true - you had MS going after the business market, Apple going after the home & publishing markets, Commodore not really going for anything, but somehow stumbling onto the desktop video, home & hacker markets.
Now, the thing is, Apple & Commodore machines were more expensive because they weren't based on "open standard" hardware. Apple kept the designs closed, and while Amiga designs were published, only Commodore could supply the Amiga chipset.
To make a long story short, there was a market failure in that no company supplied an OS as "cheap" as DOS for hackers to the "open architecture" x86 PC market.
Even if Mac was open & had a competitive hardware market, MacOS *does*not* target hackers!!!! There would be a few of us dicking around on DOS, Amigas, and, yes, I'd bet some insightful person would release a hardcore technically advanced OS for the open M68K Macintosh hardware market. (Heh but maybe it would have been "ARP":)
So no, I don't think hackers would flock to Mac OS if it was open.
According to the ACLU, enforcing gun control requires search-and-seizure. Check out http://www.aclu.org/library/aaguns.html
Search-and-seizure is exactly what happened here - it's breaking the same rights. And yes, I agree, anyone who mentions WWII *should* be spanked. Search-and-seizure is bad, but it isn't the same as death camps.
In labour markets in general, more labour regulation causes higher unemployment. This is the fundamental fallacy of many forms of labour laws: in an attempt to protect workers, many forms of labour policy actually end up hurting workers. (Many introductory microeconomic texts use minimum wage and labour unions fighting for higher wages as "textbook" examples... pick one up one if you want to find out more)
This is no different, but it has a twist. Employers have a choice between hiring an in-office worker, or a telecommuting worker. By increasing the regulations on telecommuting workers, the government is inadvertantly making it HARDER for people to telecommute.
It's important to understand *why* safety regulation on the workplace exist: before they were around, industrial jobs were unnecessarily dangerous. People would get mutilated or die due to avoidable accidents. Employees complained, but firms didn't listen well enough, so labour unions and governments rammed safety regulations down their throats.
The purpose was not to make firms "big daddy" it was to get them to listen to what everyone knew: the workplace could be made safe. If you're working at home, your employer does not control the safety of the environment, *you*do*. This is in stark contrast to the workplace the policy was designed to work in.
Also, please note, this *does*not* seem to be about giving employees ergonomic keyboards as it seems to be about legal liability. That's the real cost to employers, not the cost of funky keyboards.
In the end, all this policy will do is to deter firms from hiring telecommuting workers. It DOES NOT protect these workers. A better idea would be to allow these workers to deduct home workplace expenses off their taxes.
This is an interesting idea, but it has a few flaws that need to be worked out.
Just to clarify that I understand what you're saying: you state (correctly) that life increases the entropy (orderliness) of an open system, and heat can measure this increase in entropy.
First problem: you can't use heat to measure entropy in the way that you say.
What actually happens is that a life-bearing planet will give off *less* heat than a similar planet without life.
When plants capture the sun's rays and use that energy to photosynthesize, they are not *not* bouncing that energy back into space. Eventually, a chunk of that energy is radiated back out (body heat:), but a lot of the captured solar radiation is used to do things like grow the roots, branches, leaves, and seeds. Doing these things are all increases in local entropy. This is energy which will never make it back into the universe.
Give it to highschool teachers not to pick this up:) (It's not in their textbooks:)... you needed Steve Wozniak as a teacher:)
HOWEVER, this does lead to an alternate testing method: what if the planet is radiating *less* energy than expected? We could conclude then, that the rest of the energy is being trapped by life-as-we-know-it, or something other process which uses solar energy to increase entropy (because, what else are you going to do with energy?:)
This might work (pardon me if this is what you were suggesting), but it won't work for Europa. Why? Two reasons:
First, we already know life is *not* widespread on Europa (more on this below). This means that Europan (heh) life doesn't use very much energy - maybe small enough not to be detected using current technology.
Second, the kind of enery Europan life is beleived to use is volcano (internal) energy rather than solar energy.
We have to look for other methods. One method for checking entropy is rather easier than looking at the amount of heat radiated. It's the method that also tells us that life is not widespread in Europa.
This method is looking at the atmosphere. Most planets have a "chemically balanced" low-entropy atmosphere. Earth does not. Our atmosphere is >20% oxygen - a highly reactive gas. Were it not for trees replenishing the O2 in the atmosphere, the amount of O2 would decline rapidly.
This is not to say that we must look for O2 atmospheres for life as we know it, but rather, just look for any high-entropy chemically unstable atmoshere... this might be easier to detect than looking for heat radiated.
But this can only show us planets that are *teeming* with life. To find a few specks of life on Europa, we'd probably have to wait until we visit it....
I think the key point of this discussion is that few people disagree that *understanding* the human genome is a bad thing. The problem stems when we try to do something to it. And since chaning your genes really only has an effect before you're born (*grin*), the only real thing we can do with this knowledge is to genetically engineer children.
There are a couple of topics which Mr. Katz brought up in this discussion. One point of was whether genetic engineering is a good thing or not. I'll deal with that in a second.
What I'd like to talk about first is this: if we assume that genetic engineering is good, who will have the right to use this technology? Will it just be the rich? This is a question many Americans ask - not just Katz, but also the likes of Kim Stanley Robinson (the Mars trilogy) and to some extent the writers of Gattica.
I think the reason that only Americans are asking this question is that most of the developed world has socialized medicine. Genetically engineering children is a perfect example of the reason universal health care is a good idea... a free market will undersupply health services to the poorest portion of the population, or those most likely to not have healt insurance coverage. In addition to the philosophical problems associated with this, there are also economic externalities in this market - you and I have get *economic* benefits from the increased productivity of a healthy and fit population. Same goes with genetic engineering: in addition to the moral dilemma solved by government providing this, there is also the economic benefit which justifies the tax expenditure on it. I know all this in itself is quite contentious amoung Americans, so I won't try to build the argument any furthur, but I hope this makes some sense.
Now onto a more difficult topic - whether genetic engineering of our children is a good idea or not.
In the article, Katz quotes someone who states that "children are not 'our' possessions, etc." True. We're not talking about _running_ someone's life. But we are talking about changing the very nature of who someone is, which will no doubt change, in some way, every single thing which will happen or could happen in their life.
This doesn't trouble me. Let me explain why.
First, we already *are* genetically engineering our children. By deciding who we want to have children with. We're paiting when we have children, and we only have half the picture. In some sense, I see genetic engineering as touching up a painiting rather than doing one from sratch.
Katz brings up another point: what if everyone "touches up" their paintings in the same way? This is maybe a deep philosohpical disagreement between the two of us: I *don't* beleive that people are sheep.
Society, no matter how sheep-like it looks in the totality, is made of individuals. These individuals value different things in themselves, and different things in children. Because of this, I beleive that we'll continue to have a great variety of differnt people in the future, genetically modified or not.
Katz also discusses third-world nations: what if they can't afford this technology. This is a good and relevant point. But my beleif is that third-world nations have a lot of other problems, and they *all* need to be dealt with. These problems stem from one very basic cause: their governments are often corrupt and inept. I think many formerly poor countries have made great strides in getting over this (consider South Korea, or Indonesia as recent examples). While most have a long way to go, I'm an optimist, and I feel great progress is being made in this respect.
And if 3rd world countries manage to get the basic problems of government, they will get to where we are today. And if they get to where we are today, surely if genetic engineering is a viable option to us, it will be to them.
One last thing concerning the setting for debate about the subject: why does the debate need to be by politicians, or scientists, or human-rights orginazations, or lawyers, or accountants, or ANYBODY other than the people it will actaully affect?
I think governments should discuss whether they will subsidize it or not... but after this, the discussion ends. I beleive in personal freedom here: the debate should be between the parents and not some heavy handed government decision saying yes you can do this, or no you can't. The beleif that individuals can make the best decisions about their lives is the fundamental idea behind a consitutional democracy and a free-market economy: two things I beleive strongly in. (I should add, so you don't get confused: as an amateur student of economics, I beleive that there are times when markets fail, and governments must intervene... health care being one of these markets).
Yes, any decision can and probably will be influenced by corporations. But I beleive in people. I beleive that NO company can make a decision for you (except - occationally - for a monopoly providing an essential good or service, but even then only for a period of time. Nothing lasts forever.)
I do not beleive that people will let comapanies decide for them such fundamental question such as will they modify their childrens' genes or not.
The end of Katz's article breaks away from the discussion about genetic engineering to one about corporatism in general. Once again, there is maybe a philosophical difference between Mr. Katz and myself.
I once used to fear corporations, but now my fear is more muted. You know why? I think it's because I started reading business magazines. I started understanding the thoughts going on in most of these business leaders. And I started to understand that most of them *try*so*hard* to control their customers, but can't.
Sometimes, it works for a period of time, but these magazines pages are filled with the stories of sucky businesses or businesses that were sucky **until they started listening to their customers**. Not even Microsoft is above this - their success is in part due to them listening to, and delivering solutions for their *business* customers while other firms focused on what *technical* customers wanted. (for example, MS killing 1-2-3 and Wordperfect has more to do with things like MS being the first PC software company to support a mice in the DOS version of their software, or WYSIWYG displays, rather than hidden APIs or pulling the plug on OS/2).
Breifly skimming over what I've written, I think my arguments aren't as tight as they could be. Yes you could attack what I've written, but I don't think what I've written does complete justice to what I'm thinking. I think I'd need much more space and time than I actually have to acheive this justice... but I hope what I've written makes some kind of sense.:)
Sorry, no benchmarks, all I have is anecdotal evidance. calum.uwaterloo.ca moved from Solaris to Linux, and they noticed a speed up. Come to think of it, it might have been SunOS and not Solaris. However, this might make things worse - I'm not sure if OO "Spring" kernel Solaris will beat plain vanilla C kernel SunOS on single processor machines (higher overhead again).
Re: Assembly programmers rock compilers.
OK, technically you are right. You can look at the o/p of a compiler, and hand tune that. BUT when you're writing a large program from scratch in assembly, unless you have LOTS and LOTS of time, the compiler will beat you.
The reason is the compiler knows a hell of a lot about things like the number of functional units on a processor, and it can order instructions to take advantage of this. RISC architecture obsoleted full time assembly programmers (but yes, you have a point, on critical code there is always room to up the compiler). VLIW chips like those based on Intel's IA-64 or Sun's MAJC architecture make it even worse for asm coders. More of the optimization logic is put into the compiler. You have to do a hell of a lot of thinking about which instructions are parallel with which others later in the code, how long each takes to complete, which function unit is responsible for running it, etc. etc.
Yup, you could still view the ouput of the code and make it better, but it gets harder with each new processor technology that's out there.
BTW Mr. Coward: How much asm programming have you done recently?
Before there was Linux, there was GNU. What is GNU? GNU's not Unix. What is Unix? A castrated Multics. What is multics? An operating system. So GNU's not a castrated operating system.
Wait. That's not right. No, it is right, but it isn't what you're looking for, right? Right.
GNU was intended to be a castrated operating system, er, I mean operating system. The difference is that GNU was intended to be free to distribute and modify. When Richard Stallman set about to write the GNU system in 1984, he quickly saw that he couldn't get anywhere without a compiler.
Or tools.
Or libraries.
So the GNU project carried on for 7 years writing compilers, tools, and libraries, always psyching themselves up for writing the key part of the OS - the kernel. But Linus beat them to it. Linux, released under the same "GPL" liscense of the GNU System, starting getting acceptance amoung the so-called open source community (except it wasn't so-called at that time. It started being so-called in 1998. Back then it was so-called something else.).
But the GNU people never lost their dream of writing not-a-castrated-kernel for their system. And that's what HURD is. I mean HIRD. I mean... well, I know I don't mean herd.
The HURD kernel, technically, has one big advantage over the Linux kernel - it is microkernel-based.
As Linus continually points out, anything you can do to make a microkernel OS fast, you can do to a monolithic kernel (like Linux). All this is true - and the monolithic kernel wins because of lower overhead. That's why Linux continually beats out high-end rockin' Solaris on single-processor machines.
However, the overhead due to microkernels are only constant factors. Kinda like in the old days when you could write in assembler and beat the pants off of any compiler by a constant factor (depending on how good you were, and how bad the compiler was, that constant could be pretty high). But the problem with giving up a high-level language for assembly is the same problem with giving up microkernels for monolithic kernels - giving up the abstraction makes programming harder. (This might be kind of prophetic: these days compilers will beat assembly programmers almost every time)
Since programming is already so hard (grin), the development of new abstractions has been one of the key factors behind the advancement of computer science. All abstractions (think: high-level languages, structured programming, object-oriented programming, pure-OO programming, lambda-calculus programming) increasingly make programming easier at the expense of decreasing speed.
*But* Linux still has many more years of development behind it than HURD. Or HIRD. But not herds (some of them have been around for millenia... unfortunate about the Buffalo, though). And Linux still has more coders. So Linux will likely stay ahead of HURD for a while.... (at least until they have a stable release:).
How does this concern you? To finish this off, I must say that unless you happen to have a 16-processor box lying around, all this won't help. Linux still rules the day on single processor machines, and probably won't be over taken.
Since you probably don't have a massive SMP machine, everything I've written was a complete waste of time. So there.
Slashdot Mirror
You know the Man I'm taking about. He's the Man who won't let a "TV-M" rated show play until after 10 pm.
He's the same man that says the word "fart" makes a formerly PG show get a TV-M rating.
Hmmm... so let me get your point straight... you are saying Parker's hands should be tied because ABC's hands are tied... because of The Man.
Yes, censorship does have it's place, but there's a subtle difference between playing pornography on prime time TV and "Blame Canada". Maybe this gives us the chance for Americans to
question their (somewhat conservative) assumptions about censorship on television. As a Canadian, I find it funny at time just how overly prudent your networks are. Ah, but you can always blame me... I'm Canadian.
Question: is this OpenStep or Objective-C? At any rate, you still aren't saved from circular references.
Let's say you had a function LinkedList *CircularLinkedList() that returns a circular linked list.
c = CircularLinkList();
OK. The count of the first element in the list is incremented. No problem. You do some processing, then you do
free(c);
the first element in the linked list has it's reference count decreased. It's count is now 1. And it will remain 1 even though the guy who is refering to him is unreferencable!!!
This is a general failure of reference-counting techniques. There are other shortcomings, including extra space to keep track of ref. counts, and keeping track of the counts them selves. Think about: every time a pointer is assigned, passed to a function, or returned from a function, you need to increment or decrement some counter *somewhere* in memory. And this can't be parallelized like mark&sweep can and run when your main process it waiting - it takes a hit on the main process itself.
It may work "OK", but better methods have long since been developed. I hope that I've explained this well, but if you still think reference counting is good, then obviously I haven't.... because this isn't a contencious point.
if you had:
struct LinkedList {
LinkedList *next;
};
LinkedList *a, *b;
a = new LinkedList;
b = new LinkedList;
a->next = b;
b->next = a;
Then you never used a or b again, a reference-counting GC wouldn't be able to collect them: both have a non-zero reference count!
Considering that circular linked lists *do* happen, this is a BAD thing.
1) This *IS* a hardware solution - read the article before replying.
2) This doesn't counter RISC philosophy (ie many RISC chips have test&set bit instructions)
3) GC *IS* good. GC is for incompetant programms just like "High-level" languages such a C were for incompetant programmers in the 1970's and 80's.
A lot of the posters here don't seem to get it. Two things to keep in mind:
.apparently the man can do no wrong, if you ask him...
1) Garbage collection is good for two reasons:
i) You simplify your interfaces. W/o garbage collection, your interfaces need to be designed to keep track of what has or hasn't been allocated. This makes programmer simpler. If you don't use GC, you essentially are "reference counting", which is one of the worst performing GC algorithms, in fact.
ii) You'll have fewer memory leaks. Memory leaks are difficult, often impossible to detect in large applications. W/o GC, the amount of memory leaked is unbouded in the program size. With GC, you can formally prove that memory leaks will remain bounded.
So with all these good thing going for GC, why is it not commonly used?
1) It is often slower.
2) It's not a standard part of C/C++. (But it is in Perl, Java and just about every other "modern" language).
The hardware knows when a reference/pointer is used. Software often doesn't and has to rely on techniques like reference counting or mark&sweep. This would be a *lot* easier if a few simple hardware hacks were throw in (not too many transistors). Remember, b/c of Moore's Law, CPU makers have more transistors than they know what to do with. It's kind of like "test and set bit"... implementing this in hardware is waaay easier than implementing locks in software.
As for #2, well talk to Bjarne about that..
-Amit Dubey
Yes, it is brain-dead. I could write a "C--" language which only used the "." operator. Using type analysis in my context-senstive analysis, I could replace the "." with a "->" when necessary, and output code that a normal C compiler could generate.
So why does C have a "->" operator anyways? Because it's brain-dead.
(Refering to the post I'm replying to).
In my experience, much of the unavoidable complexity of C++ comes from the fact that you can use either pointers or references to refer to objects.
Note the distinction between "unavoidable" complexity and the avoidable complexity of templates and multiple inheritance - often you can't get around this.
References are nice because the "->" operator is brain-dead: why should the programmer keep track if something is a pointer or not when a type-safe compiler can figure out if "." or "->" is suitable.
But references, unforutnately, can't be used everywhere. The lack of an ABI might be one reason. The fact that Linux/Unix only has 'C' style interface is another, related reason. (NB: Windows _does_ have MFC to abstract OS functionality, if you want it. From what I hear, it doesn't abstract that functionality very well, though...).
But you sometimes have to mix pointers and references for the simple reason that you can't re-assign references. In code, this might be no problem, but what about classes?
Another unavoidable complexity deals with the language's decision not to have proper "interface"/"implmentation" files. On one simplistic level, it means I have to unnecessarily type in:
#ifndef __MY_HEADER_H__
#define __MY_HEADER_H__
...
#endif
But there are other annoyances. For example, you can't statically initialize static member variables! To be honest, you can, but not the way that a programmer would naively expect:
class {
static int foo = {1,2,3,4};
};
just doesn't work.
Things like this are the gravest error a language designer can make: if the language doesn't work in the way a naive programmer would expect, you *need* to become experienced and learn the special cases.
Re: bloatedness. Stroustrup makes the assertion that if you use C++ right, you won't have bloated code. With G++ at least, it is difficult to use STL in *any* way without bloating your code. Perhaps this is a shortcoming of g++ rather than C++. However, I think that the design of C++ makes it difficult for compiler writers to make efficient STL code.
In some sense, I feel like C++ is like Windows: people use it because they have to, not because they want to. And "have to" doesn't mean it's imposed, sometimes it just means that tools have been developed for it that are unavailable elsewhere. In many languages, I simply can't use yacc, makedepend, the Unix API, etc, etc.
Two questions:
C++ does not have built-in support for multithreading. The unfortunate thing about this is that there are some threading features that can only be implemented by a compiler. In particular, I'll point to monitors - they can very neatly abstract away semaphores by implicitly placing a semaphore on methods. Nifty features like wait conditions can be a very useful tool. As multithreaded software becomes more common, will C++ be extended to include monitors as part of the language?
Hmmm... how can these be distinct when theyre is obviously an overlap between The Corporate Internet and BuyNet as well as BuyNet and CultureNet. Slashdot is really a CultureNet, not a TechNet. It just happens to be a CultureNet for TechNet-type people. Likewise, GameNet is a CultreNet for people who belong to the Game Culture. Similar to GodNet. Moreover Slashdot is a weblog, so by your definition that makes it a part of Undernet. But from what I understand CmdrTaco and Hemos live above ground, so it's not exactly subterranian, now, is it?
Oh, yeah, and hyperlinks join all of them together. Maybe "old media" transposed onto CorporateNet (or was that CultureNet?) hasn't quite figured out hyperlinks yet, that day is coming (or did come when CorporateNet/XNet/BuyNet AOL bought CultureNet/InfoNet/CorporateNet TimeWarnet).
Thanks for your timenet.
Amitnet Dubeynet
History is re-written by the victors, and the victors have lied to you about why the console market crashed after the 2600.
Yup, it's because Atari decided to bet the future on desktops rather than consoles.
Yup, it's because console games started to suck - because developers were focusing their attention elsewhere. The question is where?
The answer that no one wants to tell you is that console gaming died because of one little thing:
LOAD "*",8,1
That's right. The Commodore 64 killed the Console Star. Here was a computer - with all the educational connotations that go along with it - that wasn't as high-priced as the expensive Apple II or luxurious Macintosh. It didn't cost that much more than a console, and parents got duped into thinking that it might be much more educational to their kids than a dummy console. By 1984, the Commodore 64 was the king of home computers.
Of course, little did the parents know that most kids wouldn't know how to do anything more than LOAD "*",8,1.
But Commodore failed to innovate the 64 line. It wasn't expandible. The 128 was a dud. Commodore US tried to position the Amiga as a business computer. By 1986 cheap PCs took out the 64 on the high-end and Nintendo was taking out the 64 on the low end.
Don't let the ignoramuses rewrite history. Atari died at the hands of Commodore long before Nintendo ever walked on the scene.
Time to stop linking to Yahoo! news, IMHO.
Time to stop linking to Yahoo! news, IMHO.
Have you done and Xlib programming? X is a bloated best!!!
To compare, on the Amiga GUI message passing was neatly handled by a small number of primitives:
PutMsg
GetMsg
ReplyMsg
WaitMsg
To boot, these were also used for I/O, and most other inter-processes communication.
On X, there are something like 10 functions and macros to duplicate many (but not all) combinations of these primitives. I was hurt when I first started writing X windows programs.
Also, it isn't immediately obvious how X's message passing ties in with the rest of the system. There were more than a few X programmers who were surprised to hear they could get a file handle for the X message stream.
And I haven't even started talking about fonts, stored bitmaps or (ugh) colour-management.
If anything, I wouldn't be surprised if display PDF provided a much much cleaner interface than X.
As co-maintainer of the comp.ai FAQ, I've come across a number of different open-source speech-recognition products.
The ISIS group at Mississippi State have a DARPA grant to create a fully public domain speech recognition system. A pre-alpha version of the software is available from: this site.
A student in Quebec is also working on a speech recognition system, although it seems as if only some basic signal processing stuff is done at this point. Follow this link for more information.
When I said, "this isn't the first step toward capitalism," I meant communism. As another poster said, the proletariat may overthrow the bourgeousie for doing this.... but they'll do it by pointing their browser to yahoo.com or even (as I we) slashdot.org... not by overthrowing the capitalist state. Choices, my friend.
:)
Now all I need is a DSL connection and digital satalite TV dammit!
Listen: DSL is *way* behind cablemodem, and MS and AT&T effectively blocked AOL out of the cablemodem market.
If AOL didn't have access to cablemodem, it wouldn't have access to broadband. If it didn't have access to broadband, it DIES.
Yes, I don't like concentration of services in a single firm as much as the next guy... but understand that it's more SCARY for AOL-Time Warner's shareholders than for consumers. Look at the executives: there's a Chairman & Vice Chairman and two Co-COO's. That's confusing - there are TOO MANY managers, and (I expect) the firm will compete poorly with smaller, nimbler rivals. No, this isn't the first step toward capitalism, it's the first step toward decreased revenue & profit growth for the combined firm. (BTW studies have shown time and time again that recently merged firms do worse than the individual firms did before the merger).
AOL *needed* to do this (and may try to buy it's way into more broadband). And no, I think we don't have anything to fear from the combined firm. With the exception of TW's cable customers, this firm isn't any kind of monopoly.
Now I finally understand. Check out:
e archCenter1968/ResearchCenter1968.html
:)
http://sloan.stanford.edu/mousesite/Archive/Res
Bootstrapping is this: a group of researchers develop a set of tools designed to improve (er, "augment") human intelligence. This is equivalent to the economist-speak of "improving productivity."
These researchers then use the results of their research (an "augmentation system") to make them more efficient in doing their research!
The end result is that augmentation systems (what we now call "computers attached to the internet") that conform to information ergonomics (meaing easy-to-use and easy-to-understand) help us to spiral our intelligence upwards.
The results of the research can then be used by other groups (who may in turn make innovations that others again can use).
It's an interesting idea. I have two critiques, however. First, I think this already happens to some extent... but it's true that researchers are not focused on it. Hence the 20 year lag between Engelbart's augmentation system and the WWW. Hence, there haven't been any major breakthroughs in the way we use computers to store information for our use. (The WWW+search engines, or relational databases, or OO databases, or expert systems are all far from any kind of Nirvana of information storage).
Second, if Englebart really wants his ideas to change the business & social landscape, he needs to use language that is accessible (ie "ergonomically designed information").
Ah, there are a few more interesting things that I could go on talking about, but I'll leave it there
When they say Englebart invented "bootstrapping" I got the drift that they weren't talking about loading a kernel into RAM.
:). Yup, this will happen by boosting our collective IQ... but what exactly does that mean?
One of the sites I jumped to says bootstrapping is "finding what you need to know to innovate, learning it, then innovating." OK. Makes sense. But I think it goes deeper than that. Another site talks about how the idea of bootstrapping may fundamentally change our social institutions and allow greater social progress (that's when I clicked they weren't talking about booting a computer
I can see broadly what they're saying on a general level, but, to use a technical term from mathematics... there seems to be a lot of arm waving going on. Can someone help me out here?
I don't think it has anything to do with the Great Jihad against Microsoft.
:)
I'm now accustomed to thinking about everything like an economist, so here is my economic analysis (kinda summarizing what other posters have said).
Microsoft had a monopoly in operating systems. When you got a computer, there was DOS for "free". Of course, the OEM was paying for it, but you couldn't really tell.
The monopoly caused market failure. A competitive market would have seen many different OS manufacturers in a monopolistic competition. What monopolistic competition means is that each OS supplier tries to target a slightly different market. To some extent, this *was* true - you had MS going after the business market, Apple going after the home & publishing markets, Commodore not really going for anything, but somehow stumbling onto the desktop video, home & hacker markets.
Now, the thing is, Apple & Commodore machines were more expensive because they weren't based on "open standard" hardware. Apple kept the designs closed, and while Amiga designs were published, only Commodore could supply the Amiga chipset.
To make a long story short, there was a market failure in that no company supplied an OS as "cheap" as DOS for hackers to the "open architecture" x86 PC market.
Even if Mac was open & had a competitive hardware market, MacOS *does*not* target hackers!!!! There would be a few of us dicking around on DOS, Amigas, and, yes, I'd bet some insightful person would release a hardcore technically advanced OS for the open M68K Macintosh hardware market. (Heh but maybe it would have been "ARP"
So no, I don't think hackers would flock to Mac OS if it was open.
According to the ACLU, enforcing gun control requires search-and-seizure. Check out http://www.aclu.org/library/aaguns.html
Search-and-seizure is exactly what happened here - it's breaking the same rights. And yes, I agree, anyone who mentions WWII *should* be spanked. Search-and-seizure is bad, but it isn't the same as death camps.
In labour markets in general, more labour regulation causes higher unemployment. This is the fundamental fallacy of many forms of labour laws: in an attempt to protect workers, many forms of labour policy actually end up hurting workers. (Many introductory microeconomic texts use minimum wage and labour unions fighting for higher wages as "textbook" examples... pick one up one if you want to find out more)
This is no different, but it has a twist. Employers have a choice between hiring an in-office worker, or a telecommuting worker. By increasing the regulations on telecommuting workers, the government is inadvertantly making it HARDER for people to telecommute.
It's important to understand *why* safety regulation on the workplace exist: before they were around, industrial jobs were unnecessarily dangerous. People would get mutilated or die due to avoidable accidents. Employees complained, but firms didn't listen well enough, so labour unions and governments rammed safety regulations down their throats.
The purpose was not to make firms "big daddy" it was to get them to listen to what everyone knew: the workplace could be made safe. If you're working at home, your employer does not control the safety of the environment, *you*do*. This is in stark contrast to the workplace the policy was designed to work in.
Also, please note, this *does*not* seem to be about giving employees ergonomic keyboards as it seems to be about legal liability. That's the real cost to employers, not the cost of funky keyboards.
In the end, all this policy will do is to deter firms from hiring telecommuting workers. It DOES NOT protect these workers. A better idea would be to allow these workers to deduct home workplace expenses off their taxes.
This is an interesting idea, but it has a few flaws that need to be worked out.
:), but a lot of the captured solar radiation is used to do things like grow the roots, branches, leaves, and seeds. Doing these things are all increases in local entropy. This is energy which will never make it back into the universe.
:) (It's not in their textbooks :)... you needed Steve Wozniak as a teacher :)
:)
Just to clarify that I understand what you're saying: you state (correctly) that life increases the entropy (orderliness) of an open system, and heat can measure this increase in entropy.
First problem: you can't use heat to measure entropy in the way that you say.
What actually happens is that a life-bearing planet will give off *less* heat than a similar planet without life.
When plants capture the sun's rays and use that energy to photosynthesize, they are not *not* bouncing that energy back into space. Eventually, a chunk of that energy is radiated back out (body heat
Give it to highschool teachers not to pick this up
HOWEVER, this does lead to an alternate testing method: what if the planet is radiating *less* energy than expected? We could conclude then, that the rest of the energy is being trapped by life-as-we-know-it, or something other process which uses solar energy to increase entropy (because, what else are you going to do with energy?
This might work (pardon me if this is what you were suggesting), but it won't work for Europa. Why? Two reasons:
First, we already know life is *not* widespread on Europa (more on this below). This means that Europan (heh) life doesn't use very much energy - maybe small enough not to be detected using current technology.
Second, the kind of enery Europan life is beleived to use is volcano (internal) energy rather than solar energy.
We have to look for other methods. One method for checking entropy is rather easier than looking at the amount of heat radiated. It's the method that also tells us that life is not widespread in Europa.
This method is looking at the atmosphere. Most planets have a "chemically balanced" low-entropy atmosphere. Earth does not. Our atmosphere is >20% oxygen - a highly reactive gas. Were it not for trees replenishing the O2 in the atmosphere, the amount of O2 would decline rapidly.
This is not to say that we must look for O2 atmospheres for life as we know it, but rather, just look for any high-entropy chemically unstable atmoshere... this might be easier to detect than looking for heat radiated.
But this can only show us planets that are *teeming* with life. To find a few specks of life on Europa, we'd probably have to wait until we visit it....
I think the key point of this discussion is that few people disagree that *understanding* the human genome is a bad thing. The problem stems when we try to do something to it. And since chaning your genes really only has an effect before you're born (*grin*), the only real thing we can do with this knowledge is to genetically engineer children.
:)
There are a couple of topics which Mr. Katz brought up in this discussion. One point of was whether genetic engineering is a good thing or not. I'll deal with that in a second.
What I'd like to talk about first is this: if we assume that genetic engineering is good, who will have the right to use this technology? Will it just be the rich? This is a question many Americans ask - not just Katz, but also the likes of Kim Stanley Robinson (the Mars trilogy) and to some extent the writers of Gattica.
I think the reason that only Americans are asking this question is that most of the developed world has socialized medicine. Genetically engineering children is a perfect example of the reason universal health care is a good idea... a free market will undersupply health services to the poorest portion of the population, or those most likely to not have healt insurance coverage. In addition to the philosophical problems associated with this, there are also economic externalities in this market - you and I have get *economic* benefits from the increased productivity of a healthy and fit population. Same goes with genetic engineering: in addition to the moral dilemma solved by government providing this, there is also the economic benefit which justifies the tax expenditure on it. I know all this in itself is quite contentious amoung Americans, so I won't try to build the argument any furthur, but I hope this makes some sense.
Now onto a more difficult topic - whether genetic engineering of our children is a good idea or not.
In the article, Katz quotes someone who states that "children are not 'our' possessions, etc." True. We're not talking about _running_ someone's life. But we are talking about changing the very nature of who someone is, which will no doubt change, in some way, every single thing which will happen or could happen in their life.
This doesn't trouble me. Let me explain why.
First, we already *are* genetically engineering our children. By deciding who we want to have children with. We're paiting when we have children, and we only have half the picture. In some sense, I see genetic engineering as touching up a painiting rather than doing one from sratch.
Katz brings up another point: what if everyone "touches up" their paintings in the same way? This is maybe a deep philosohpical disagreement between the two of us: I *don't* beleive that people are sheep.
Society, no matter how sheep-like it looks in the totality, is made of individuals. These individuals value different things in themselves, and different things in children. Because of this, I beleive that we'll continue to have a great variety of differnt people in the future, genetically modified or not.
Katz also discusses third-world nations: what if they can't afford this technology. This is a good and relevant point. But my beleif is that third-world nations have a lot of other problems, and they *all* need to be dealt with. These problems stem from one very basic cause: their governments are often corrupt and inept. I think many formerly poor countries have made great strides in getting over this (consider South Korea, or Indonesia as recent examples). While most have a long way to go, I'm an optimist, and I feel great progress is being made in this respect.
And if 3rd world countries manage to get the basic problems of government, they will get to where we are today. And if they get to where we are today, surely if genetic engineering is a viable option to us, it will be to them.
One last thing concerning the setting for debate about the subject: why does the debate need to be by politicians, or scientists, or human-rights orginazations, or lawyers, or accountants, or ANYBODY other than the people it will actaully affect?
I think governments should discuss whether they will subsidize it or not... but after this, the discussion ends. I beleive in personal freedom here: the debate should be between the parents and not some heavy handed government decision saying yes you can do this, or no you can't. The beleif that individuals can make the best decisions about their lives is the fundamental idea behind a consitutional democracy and a free-market economy: two things I beleive strongly in. (I should add, so you don't get confused: as an amateur student of economics, I beleive that there are times when markets fail, and governments must intervene... health care being one of these markets).
Yes, any decision can and probably will be influenced by corporations. But I beleive in people. I beleive that NO company can make a decision for you (except - occationally - for a monopoly providing an essential good or service, but even then only for a period of time. Nothing lasts forever.)
I do not beleive that people will let comapanies decide for them such fundamental question such as will they modify their childrens' genes or not.
The end of Katz's article breaks away from the discussion about genetic engineering to one about corporatism in general. Once again, there is maybe a philosophical difference between Mr. Katz and myself.
I once used to fear corporations, but now my fear is more muted. You know why? I think it's because I started reading business magazines. I started understanding the thoughts going on in most of these business leaders. And I started to understand that most of them *try*so*hard* to control their customers, but can't.
Sometimes, it works for a period of time, but these magazines pages are filled with the stories of sucky businesses or businesses that were sucky **until they started listening to their customers**. Not even Microsoft is above this - their success is in part due to them listening to, and delivering solutions for their *business* customers while other firms focused on what *technical* customers wanted. (for example, MS killing 1-2-3 and Wordperfect has more to do with things like MS being the first PC software company to support a mice in the DOS version of their software, or WYSIWYG displays, rather than hidden APIs or pulling the plug on OS/2).
Breifly skimming over what I've written, I think my arguments aren't as tight as they could be. Yes you could attack what I've written, but I don't think what I've written does complete justice to what I'm thinking. I think I'd need much more space and time than I actually have to acheive this justice... but I hope what I've written makes some kind of sense.
Re: Solaris on Sun hardware.
Sorry, no benchmarks, all I have is anecdotal evidance. calum.uwaterloo.ca moved from Solaris to Linux, and they noticed a speed up. Come to think of it, it might have been SunOS and not Solaris. However, this might make things worse - I'm not sure if OO "Spring" kernel Solaris will beat plain vanilla C kernel SunOS on single processor machines (higher overhead again).
Re: Assembly programmers rock compilers.
OK, technically you are right. You can look at the o/p of a compiler, and hand tune that. BUT when you're writing a large program from scratch in assembly, unless you have LOTS and LOTS of time, the compiler will beat you.
The reason is the compiler knows a hell of a lot about things like the number of functional units on a processor, and it can order instructions to take advantage of this. RISC architecture obsoleted full time assembly programmers (but yes, you have a point, on critical code there is always room to up the compiler). VLIW chips like those based on Intel's IA-64 or Sun's MAJC architecture make it even worse for asm coders. More of the optimization logic is put into the compiler. You have to do a hell of a lot of thinking about which instructions are parallel with which others later in the code, how long each takes to complete, which function unit is responsible for running it, etc. etc.
Yup, you could still view the ouput of the code and make it better, but it gets harder with each new processor technology that's out there.
BTW Mr. Coward: How much asm programming have you done recently?
Before there was Linux, there was GNU. What is GNU? GNU's not Unix. What is Unix? A castrated Multics. What is multics? An operating system. So GNU's not a castrated operating system.
:).
Wait. That's not right. No, it is right, but it isn't what you're looking for, right? Right.
GNU was intended to be a castrated operating system, er, I mean operating system. The difference is that GNU was intended to be free to distribute and modify. When Richard Stallman set about to write the GNU system in 1984, he quickly saw that he couldn't get anywhere without a compiler.
Or tools.
Or libraries.
So the GNU project carried on for 7 years writing compilers, tools, and libraries, always psyching themselves up for writing the key part of the OS - the kernel. But Linus beat them to it. Linux, released under the same "GPL" liscense of the GNU System, starting getting acceptance amoung the so-called open source community (except it wasn't so-called at that time. It started being so-called in 1998. Back then it was so-called something else.).
But the GNU people never lost their dream of writing not-a-castrated-kernel for their system. And that's what HURD is. I mean HIRD. I mean... well, I know I don't mean herd.
The HURD kernel, technically, has one big advantage over the Linux kernel - it is microkernel-based.
As Linus continually points out, anything you can do to make a microkernel OS fast, you can do to a monolithic kernel (like Linux). All this is true - and the monolithic kernel wins because of lower overhead. That's why Linux continually beats out high-end rockin' Solaris on single-processor machines.
However, the overhead due to microkernels are only constant factors. Kinda like in the old days when you could write in assembler and beat the pants off of any compiler by a constant factor (depending on how good you were, and how bad the compiler was, that constant could be pretty high). But the problem with giving up a high-level language for assembly is the same problem with giving up microkernels for monolithic kernels - giving up the abstraction makes programming harder. (This might be kind of prophetic: these days compilers will beat assembly programmers almost every time)
Since programming is already so hard (grin), the development of new abstractions has been one of the key factors behind the advancement of computer science. All abstractions (think: high-level languages, structured programming, object-oriented programming, pure-OO programming, lambda-calculus programming) increasingly make programming easier at the expense of decreasing speed.
*But* Linux still has many more years of development behind it than HURD. Or HIRD. But not herds (some of them have been around for millenia... unfortunate about the Buffalo, though). And Linux still has more coders. So Linux will likely stay ahead of HURD for a while.... (at least until they have a stable release
How does this concern you? To finish this off, I must say that unless you happen to have a 16-processor box lying around, all this won't help. Linux still rules the day on single processor machines, and probably won't be over taken.
Since you probably don't have a massive SMP machine, everything I've written was a complete waste of time. So there.