When I buy something, I own it. I can take it apart and use its pieces to build other stuff, I can sell it to other people, I can give it to my grandchildren, whatever.
Unless: unless it is a piece of software, that is. Never mind that I walk into CompUSA and buy a piece of software the same way that I'd buy a rutabaga or cabbage at the grocery store. I'm not free to take it apart and use its pieces to build other stuff, and according to the 'shrink wrap license' that was put into my face when I tried to run the software (and remember, CompUSA will NOT take the software back, even if I say "Hey, I bought software, not a license"), I'm not free to sell it or give it to my grandchildren when I get tired of it ("This license is for a single computer").
I think this is what the original poster was talking about, not the whole notion of contracts. As far as contracts go, I'll note that the concept of "good faith" is important there. A contract signed at the point of a gun is not valid in a court of law because both parties were not operating in good faith. A 'shrink wrap' license where I've put out my money and then suddenly I'm told 'no, you didn't buy me, and you can't get your money back' is not good faith.
I've read the research paper on L4 (have they put the actual code back up for download?). It states that there is a performance penalty of 2% to 5% running the Linux service as vs. running a monolithic Linux. If the rest of the promised benefits of microkernels pan out, I agree that this is a quite acceptable penalty and not one that I would get uptight about.
On the other hand, to say that microkernels are faster than monolithic kernels is sheer stupidity. Microkernels add another layer, and no matter how efficient (and L4 is pretty darned efficient), they still require code in execution paths within the kernel that monolithic kernels don't require.
As for Mach, you are correct that it was a research project, but it was cancelled not because it was slow, but, rather, because its grant ran out. That is the typical fate of research projects -- they get cancelled because they're old hat and no longer producing research papers, not because they're lousy (and Mach IS lousy -- Linus commented once that Mach was the Emacs of microkernels, with everything but the kitchen sink in there! Linus likes L4, BTW, though not enough to dump the notion of a monolithic kernel).
As a former Multician (University of Southwestern Lousiana, '81-'82), I probably have more insight than the original poster about the origins of Unix as a reaction to Multics. Multics was all about segments. There was no such thing as file i/o in Multics, everything was a segment, though you could query the filesystem database for the address of a segment (give it a name, out pops a segment ID). File I/O was emulated by reading and writing to segmented memory. Incidentally, all of this made process creation overhead so intense that Multics did not have the concept of pipes or of sending the output of one command into the input of another command. The output of Multics commands were meant to be human-readable anyhow, and would not have been useful for doing that. I could sometimes do something useful by outputing to a file and then running the result through TED to get rid of the human-readable stuff before feeding it into another program, but that was hardly a useful normal thing to do, not like "ls -l | more".
Unix, by contrast, was built around two concepts: 1) Everything is a file. Self explanatory. 2) Many small tools, chained together to make bigger tools. This was a direct reaction to the Multics philosophy of "put everything into one big tool". These principles have been violated many times since the origins of Unix, but the fact remains that Unix had a design philosophy in the beginning, a design philosophy which can be read in the original Unix papers (go to your local library and I think it was what, CACM back in 1974?). Having a coherent design philosophy at the beginning is probably why it is still useful today, so many years later, whereas so many operating systems whose sole design principle was "put in whatever features we think will sell" have come and gone in the meantime.
I don't think so. According to benchmarks of MkLinux (the microkernel-based version),it was as much as 30% slower than 'monolithic' Linux. 'Real' BSD-based MACH showed the same kind of performance decrease as compared with 'real' BSD Unix.
What microkernels were supposed to do was not make kernel internals faster (a little thought will tell you that message-passing is more expensive than function calls), but, rather, make them easier to write, more reliable, and easier to write drivers for. Unfortunately their promise there does not seem to have worked. RMS, for example, blames HURD's stability problems on, quote, "a microkernel is harder to debug".
I personally still like a microkernel approach, and believe that if done properly it can get us the promised benefits (said after fighting a buggy device driver in Linux that managed to trash the TCP/IP stack even though it was a serial card driver... ARGH!). On the other hand, speed isn't one of those promised benefits, never has been, and to say so is silly.
True, Linux has never been submitted to a standards committee to certify it, but that means about as much as getting a college degree after you've done the coursework (I was just as smart ten minutes before I was granted my degree, as I was ten minutes afterwards). Linux has done the coursework, just hasn't bothered applying for the certificate.
"Anonymous Coward"'s credentials are obvious. His credentials are that he has an office in Redmond on the campus of a large OS vendor and thus is automatically smarter than the rest of us (sarcasm intended).
Actually, the Ethernet vs. Token Ring analogy is very useful in the Linux vs. Windows 2000 debate. Ethernet was an open protocol that anybody could license and tweak, while Token Ring was a proprietary standard that only IBM and a chosen few were allowed to sell and tweak. Similarly, Linux is an open OS that anybody can sell or tweak, while WIndows 2000 is a closed proprietary standard that only Microsoft is allowed to sell or tweak. Just as in the VHS vs. Beta war, where the open standard won, the open standard has an inherent advantage here. Unless Microsoft licenses the Windows source code to other companies for them to tweak and sell under their own brand name (Compaq Windows, anybody?), they will inevitably go the same way as Beta no matter how technically superior (or not).
To conclude: Whether or not Linux is technically superior (in some ways it is, in some ways it isn't) is irrelevant, as Petreley was trying to say. What it will come down to, in the end, is a matter of two questions: a) does it do the job? b) does it save us money?
Ethernet did the job, and saved money as vs. Token Ring, so it won. Petreley is saying that Linux meets those same criteria.
There will always be a place for closed source. ESR admits that, even if RMS never will.
I think the school consulting firm I once worked for is an ideal example: they had spent ten years and over a million dollars building up their software. They didn't make money off of the software itself, but the service contracts were lucrative (state and federal guidelines change yearly, sometimes monthly, and the software must be immediately updated to reflect those changes). Open Sourcing the project would have chopped the service contract money by allowing others to also offer service, while not adding any other forms of revenue. Closed Source was the right answer to that product, as it is for many other limited-use items.
Not true. When I was doing consulting work, we regularly could underbid proprietary solutions by using Linux, giving us a significant competitive advantage while actually maintaining a higher margin than our competitors. We used a 4GL under Linux, BTW, and served as the IT department for school districts too small/poor to have their own. We could whip out some software pretty quickly too -- for example, when the state of Louisiana changed reporting requirements for school discipline, it took me two weeks to write an entirely new discipline system to replace the old one that had collapsed under its own weight. (Well, it hadn't collapsed, but it had reached the limits of what could be done to it due to structural design limits built into it, sort of like trying to turn MS-DOS into a 32-bit OS, eh?).
So tell me: underbid the competitition, make more profit. If that's not competitive advantage, what is?!
For a paper that reads like a simplified version of the Other Eric's, you might want to wander by my home page to read something I did last year and sent to the Other Eric back in January for comment. (Please note that the Other Eric had parts of 'Cauldron' already up on his web site back then, so we sort of cross-pollinated, I think).
1) You are assuming that the proprietary-to-company stuff is open sourced, such as, e.g., the license key generator. This is a ridiculous assumption. Nothing requires you to distribute your software even if it is covered by the GPL. Not to mention that any competent project done in today's world is going to have a modular plug-in architecture, meaning that you don't even have to link your proprietary business practices into the code base as a whole (i.e., they don't have to be covered by the GPL just because the rest of the project is!).
2) Let's face it, most business process software has been hashed and rehashed until it's so old-hat that there's no competitive value in keeping it proprietary. How many #@%@ accounting systems are out there in the market anyhow? Why should I think that my own new accounting and inventory management software gives anybody any competitive advantage? There are industry and government standards that force any accounting or inventory software to be pretty much the same. By Open Sourcing it, I accomplish two things: a) I allow others outside of my company to take on some of the development costs. As my boss once told me, "nobody is ever going to buy us because we have a nifty internal accounting system, they're going to buy us because we have a nifty product." This, for example, is why ISP's use Apache. The bigger ISP's have the internal talent to write an HTTP server -- heck, I have enough talent to do that, HTTP is a dirt-simple protocol (though the 1.1 spec, thanks to Microsoft's help, is considerably nastier) -- but it makes more sense for them to all use Apache and individually contribute modules and improvements that fit their own needs. b) I get a larger debugging pool. In fact, I might release the GPL'ed version to the net first, before upgrading to it in-house, just to let others be my guinea pigs first. After all, if it turns out that my Accounts Recievable program is eating accounts, I'd rather that someone else discover it first!
One more thing: Once a project reaches a stage where any improvements will incorporate company-proprietary business methods rather than industry-standard or government-legislated business methods, there's nothing forcing you to continue distributing it. You've gotten help in building the basic framework, others can take that basic framework and do what they like with it, and you can happily use your own proprietary version in-house without ever releasing it to the general public. The GPL doesn't stop you from making your own proprietary version. It just says that IF you distribute it outside of your company, you have to make the source code available too and must allow the person who got it to distribute it too.
Of course it would not kill them to GPL the installer, but the founders of SuSE do not want competitors based upon their product. Remember, SuSE Linux exists because they took Slackware and translated it to German. They don't want anybody doing to SuSE what they did to Slackware.
My reading of the YAST license is that sharing is okay, selling is not. I.e., you cannot create "Sassy Linux" based on SuSE Linux and make money selling it. But you can install one copy on every workstation in your office if you want.
Still, the YAST license is the main reason why I am still running Red Hat on my machines. There are other reasons (Red Hat is more enterprise-friendly in the way they lay out their filesystem, for example), but the YAST license is the key.
Which is why my resume was in HTML when I was looking for a job. Strangely enough, I got a couple of replies back amazingly similar to the guy in question. The only question I can ask is: why? Why should I waste my time dealing with the clueless? If a company can't hire competent HR people, why should I assume that they have competent engineers or managers?
Of course all that resume shopping wasn't how I ended up getting a job in the end...
It's not just Linux that Bob 'doesn't get'. It's the Internet as a whole. Linux is just the latest Internet phenomenon to be the target of Bob's bile.
Bob doesn't like the Internet because it is anarchic, has no central point of control, and seemingly develops every which way without any rhyme or reason. This offends his sensibilities. Ethernet had a classic sensibility which reflects Bob's psyche. The Internet doesn't. Every year he predicts that the Internet will collapse under its own weight by the end of the year. Every year he is proven wrong. But that does not stop him from predicting, every year, that only per-minute charges will save the Internet from collapse.
This is the same guy who has said, for each of the last three years, that the Internet will collapse by the end of the year and that the only solution is to charge per-minute fees for Internet access.
So far he's batting.000 here. I suspect his annual "the fall of Linux" speech will start to acquire the same patina as his annual "the collapse of the Internet" speech, for the same reason -- Bob simply does not understand how an anarchic network of developers can keep something like the Internet or Linux going. Bob is the classic Cathedral guy in Eric S. Raymond's "Cathedral and Bazarre". The operations of a bazarre frighten him. Ethernet has a classic simplicity reflective of Bob's highly ordered personality. When he sees the Internet or Linux, he sees chaos, and cannot see why it does not collapse under its own weight.
At the time the Mindcraft paper came out, I was working for Linux Hardware Solutions. My first thought, upon looking at their numbers, was "man, that Dell SUCKS! I wonder how much they'd charge to benchmark one of our boxes against that Dell? We'll wipe Dell's rear!"
My next thought, however, after looking over the details of the "benchmark", was "man, I wouldn't want those incompetents near my computer." There are plenty of reputable benchmarking outfits. Giving Mindcraft more business is NOT a proper solution -- Mindcraft has proven that they are incapable of conducting themselves professionally. They poorly served Microsoft by doing a "benchmark" that had so many holes in it that even the press didn't believe it. Remember, their job was to generate numbers that would be believed -- and they failed miserably. Should we reward such failure with more money?!
Let me get this straight. Your idea for fixing the scalability problems of Sendmail is to create a config file format that takes MORE horsepower to parse (regular expressions)?
I'll agree Sendmail needs a major overhaul and that the config file format is a disaster, but let's face it, anything as flexible as sendmail will have the same scalability problems as sendmail. The only solution to those scalability problems is to go with a less flexible MTA. Sort of like in web server, where if you want flexibility you go with Apache, but if you want speed, you go with thttpd or Zeus.
My primary concern is that Red Hat appears to be forgetting the reasons for their success. Some reasons why, in the past, I standardized on Red Hat:
1) Large amount of contributed software on their FTP site. Now the/incoming directory has disappeared and there are no directions on any Red Hat web site on how to contribute to RHCN, the purported replacement. Don't believe me? Try http://developer.redhat.com and http://rhcn.redhat.com!
2) Swift bug releases. In the past, Red Hat swiftly released bug fixes. Today, go browse BugZilla on http://developer.redhat.com . Look for problems with, for example, the NIS daemon. Look at the "Resolution" box. I'll bet you that 99% of the bugs you find will have "WONTFIX" or "LATER" (fixed in later release, not in 6.0) in the "Resolution" box. For some things this does not matter. For others it does -- for example, the NIS password daemon dying is a major bug for those of us who use NIS, and it is marked as "LATER". It appears that the automatic response of the poor slob they have monitoring these hundreds of bugs is to automatically put "LATER" or "WONTFIX" into that box so that he won't have to actually do anything about them (work? gosh, what's that?!).
3) A coherent web site. In the past, Red Hat had the best web site of any distribution. It was chock-full of information, you could find out almost anything you needed to know about Red Hat Linux by following the links, it pointed you to their mailing lists, etc. Now it's a mess. You can't find anything, the links are all broken (like the one on how to contribute to RHCN!), and you can tell that behind the scenes, the thing is torn to pieces and the mechanics are scratching their heads trying to figure out how to put it back together again. In short, it's a mess.
These are growing pains, certainly. But unless Red Hat remembers why they got where they are, they're going to start losing market share -- and once that happens, they'll lose their luster of invincibility and end up being just another distribution.
When you buy a VA machine, you know you're getting components that run well with Linux (as vs. components that run well with NT, that might run crappy with Linux -- like the Dell that MindCraft used to out-benchmark Linux), and you know that you have access to big-name talent if you run into driver problems or something else of that nature. If you buy a Dell... well, Dell knows NT, but Dell doesn't know Linux.
This isn't enough to make VA a compelling buy at the low end, but for people wanting mission-critical Linux servers, they want to buy those from a company that has Linux expertise, not from Joe's Screwdriver Shop or Dell NT Systems.
Note: I don't work for VA or any Linux hardware vendor, and have no reason to hype VA (I'm now working for a software vendor as a database programmer and system administrator, my true love). That doesn't change the "facts on the ground", which is that when people want mission-critical Linux servers, they don't buy them from Bob's Screwdriver Shop.
I know for a fact that the ASUS P2BF has a "AC Power Fail Auto-Restart" BIOS option and the Intel Nightshade has a "Restore Power State" BIOS option that will turn the power on automatically if it was on when AC power was lost (i.e. power was not turned off via the front panel switch).
Note that the Constititution allows suspension of habeas corpus (i.e., things like the internment of Japanese-Americans) only when a state of war has been declared by the Congress of the United States of America. When we are official "at peace", such as today, those rights cannot be suspended on spurious "national security" grounds.
Even worse, if you're thinking about laptops. Right now the only low-power x86-compatible processor out there is the IDT Winchip, which is woefully underpowered for a Windows laptop (it does manage to keep out of its way with Linux, though -- that's what the Netiers use, due to its low power consumption).
Slashdot Mirror
When I buy something, I own it. I can take it apart and use its pieces to build other stuff, I can sell it to other people, I can give it to my grandchildren, whatever.
Unless: unless it is a piece of software, that is. Never mind that I walk into CompUSA and buy a piece of software the same way that I'd buy a rutabaga or cabbage at the grocery store. I'm not free to take it apart and use its pieces to build other stuff, and according to the 'shrink wrap license' that was put into my face when I tried to run the software (and remember, CompUSA will NOT take the software back, even if I say "Hey, I bought software, not a license"), I'm not free to sell it or give it to my grandchildren when I get tired of it ("This license is for a single computer").
I think this is what the original poster was talking about, not the whole notion of contracts. As far as contracts go, I'll note that the concept of "good faith" is important there. A contract signed at the point of a gun is not valid in a court of law because both parties were not operating in good faith. A 'shrink wrap' license where I've put out my money and then suddenly I'm told 'no, you didn't buy me, and you can't get your money back' is not good faith.
-E
I've read the research paper on L4 (have they put the actual code back up for download?). It states that there is a performance penalty of 2% to 5% running the Linux service as vs. running a monolithic Linux. If the rest of the promised benefits of microkernels pan out, I agree that this is a quite acceptable penalty and not one that I would get uptight about.
On the other hand, to say that microkernels are faster than monolithic kernels is sheer stupidity. Microkernels add another layer, and no matter how efficient (and L4 is pretty darned efficient), they still require code in execution paths within the kernel that monolithic kernels don't require.
As for Mach, you are correct that it was a research project, but it was cancelled not because it was slow, but, rather, because its grant ran out. That is the typical fate of research projects -- they get cancelled because they're old hat and no longer producing research papers, not because they're lousy (and Mach IS lousy -- Linus commented once that Mach was the Emacs of microkernels, with everything but the kitchen sink in there! Linus likes L4, BTW, though not enough to dump the notion of a monolithic kernel).
-E
As a former Multician (University of Southwestern Lousiana, '81-'82), I probably have more insight than the original poster about the origins of Unix as a reaction to Multics. Multics was all about segments. There was no such thing as file i/o in Multics, everything was a segment, though you could query the filesystem database for the address of a segment (give it a name, out pops a segment ID). File I/O was emulated by reading and writing to segmented memory. Incidentally, all of this made process creation overhead so intense that Multics did not have the concept of pipes or of sending the output of one command into the input of another command. The output of Multics commands were meant to be human-readable anyhow, and would not have been useful for doing that. I could sometimes do something useful by outputing to a file and then running the result through TED to get rid of the human-readable stuff before feeding it into another program, but that was hardly a useful normal thing to do, not like "ls -l | more".
Unix, by contrast, was built around two concepts:
1) Everything is a file. Self explanatory.
2) Many small tools, chained together to make bigger tools. This was a direct reaction to the Multics philosophy of "put everything into one big tool".
These principles have been violated many times since the origins of Unix, but the fact remains that Unix had a design philosophy in the beginning, a design philosophy which can be read in the original Unix papers (go to your local library and I think it was what, CACM back in 1974?). Having a coherent design philosophy at the beginning is probably why it is still useful today, so many years later, whereas so many operating systems whose sole design principle was "put in whatever features we think will sell" have come and gone in the meantime.
-E
I don't think so. According to benchmarks of MkLinux (the microkernel-based version),it was as much as 30% slower than 'monolithic' Linux. 'Real' BSD-based MACH showed the same kind of performance decrease as compared with 'real' BSD Unix.
What microkernels were supposed to do was not make kernel internals faster (a little thought will tell you that message-passing is more expensive than function calls), but, rather, make them easier to write, more reliable, and easier to write drivers for. Unfortunately their promise there does not seem to have worked. RMS, for example, blames HURD's stability problems on, quote, "a microkernel is harder to debug".
I personally still like a microkernel approach, and believe that if done properly it can get us the promised benefits (said after fighting a buggy device driver in Linux that managed to trash the TCP/IP stack even though it was a serial card driver... ARGH!). On the other hand, speed isn't one of those promised benefits, never has been, and to say so is silly.
-E
glibc is very very close to POSIX compliance.
True, Linux has never been submitted to a standards committee to certify it, but that means about as much as getting a college degree after you've done the coursework (I was just as smart ten minutes before I was granted my degree, as I was ten minutes afterwards). Linux has done the coursework, just hasn't bothered applying for the certificate.
-E
"Anonymous Coward"'s credentials are obvious. His credentials are that he has an office in Redmond on the campus of a large OS vendor and thus is automatically smarter than the rest of us (sarcasm intended).
-E
Actually, the Ethernet vs. Token Ring analogy is very useful in the Linux vs. Windows 2000 debate. Ethernet was an open protocol that anybody could license and tweak, while Token Ring was a proprietary standard that only IBM and a chosen few were allowed to sell and tweak. Similarly, Linux is an open OS that anybody can sell or tweak, while WIndows 2000 is a closed proprietary standard that only Microsoft is allowed to sell or tweak. Just as in the VHS vs. Beta war, where the open standard won, the open standard has an inherent advantage here. Unless Microsoft licenses the Windows source code to other companies for them to tweak and sell under their own brand name (Compaq Windows, anybody?), they will inevitably go the same way as Beta no matter how technically superior (or not).
To conclude: Whether or not Linux is technically superior (in some ways it is, in some ways it isn't) is irrelevant, as Petreley was trying to say. What it will come down to, in the end, is a matter of two questions:
a) does it do the job?
b) does it save us money?
Ethernet did the job, and saved money as vs. Token Ring, so it won. Petreley is saying that Linux meets those same criteria.
-E
There will always be a place for closed source. ESR admits that, even if RMS never will.
I think the school consulting firm I once worked for is an ideal example: they had spent ten years and over a million dollars building up their software. They didn't make money off of the software itself, but the service contracts were lucrative (state and federal guidelines change yearly, sometimes monthly, and the software must be immediately updated to reflect those changes). Open Sourcing the project would have chopped the service contract money by allowing others to also offer service, while not adding any other forms of revenue. Closed Source was the right answer to that product, as it is for many other limited-use items.
-E
Not true. When I was doing consulting work, we regularly could underbid proprietary solutions by using Linux, giving us a significant competitive advantage while actually maintaining a higher margin than our competitors. We used a 4GL under Linux, BTW, and served as the IT department for school districts too small/poor to have their own. We could whip out some software pretty quickly too -- for example, when the state of Louisiana changed reporting requirements for school discipline, it took me two weeks to write an entirely new discipline system to replace the old one that had collapsed under its own weight. (Well, it hadn't collapsed, but it had reached the limits of what could be done to it due to structural design limits built into it, sort of like trying to turn MS-DOS into a 32-bit OS, eh?).
So tell me: underbid the competitition, make more profit. If that's not competitive advantage, what is?!
-E
For a paper that reads like a simplified version of the Other Eric's, you might want to wander by my home page to read something I did last year and sent to the Other Eric back in January for comment. (Please note that the Other Eric had parts of 'Cauldron' already up on his web site back then, so we sort of cross-pollinated, I think).
1) You are assuming that the proprietary-to-company stuff is open sourced, such as, e.g., the license key generator. This is a ridiculous assumption. Nothing requires you to distribute your software even if it is covered by the GPL. Not to mention that any competent project done in today's world is going to have a modular plug-in architecture, meaning that you don't even have to link your proprietary business practices into the code base as a whole (i.e., they don't have to be covered by the GPL just because the rest of the project is!).
2) Let's face it, most business process software has been hashed and rehashed until it's so old-hat that there's no competitive value in keeping it proprietary. How many #@%@ accounting systems are out there in the market anyhow? Why should I think that my own new accounting and inventory management software gives anybody any competitive advantage? There are industry and government standards that force any accounting or inventory software to be pretty much the same. By Open Sourcing it, I accomplish two things:
a) I allow others outside of my company to take on some of the development costs. As my boss once told me, "nobody is ever going to buy us because we have a nifty internal accounting system, they're going to buy us because we have a nifty product." This, for example, is why ISP's use Apache. The bigger ISP's have the internal talent to write an HTTP server -- heck, I have enough talent to do that, HTTP is a dirt-simple protocol (though the 1.1 spec, thanks to Microsoft's help, is considerably nastier) -- but it makes more sense for them to all use Apache and individually contribute modules and improvements that fit their own needs.
b) I get a larger debugging pool. In fact, I might release the GPL'ed version to the net first, before upgrading to it in-house, just to let others be my guinea pigs first. After all, if it turns out that my Accounts Recievable program is eating accounts, I'd rather that someone else discover it first!
One more thing: Once a project reaches a stage where any improvements will incorporate company-proprietary business methods rather than industry-standard or government-legislated business methods, there's nothing forcing you to continue distributing it. You've gotten help in building the basic framework, others can take that basic framework and do what they like with it, and you can happily use your own proprietary version in-house without ever releasing it to the general public. The GPL doesn't stop you from making your own proprietary version. It just says that IF you distribute it outside of your company, you have to make the source code available too and must allow the person who got it to distribute it too.
-E
Of course it would not kill them to GPL the installer, but the founders of SuSE do not want competitors based upon their product. Remember, SuSE Linux exists because they took Slackware and translated it to German. They don't want anybody doing to SuSE what they did to Slackware.
-E
My reading of the YAST license is that sharing is okay, selling is not. I.e., you cannot create "Sassy Linux" based on SuSE Linux and make money selling it. But you can install one copy on every workstation in your office if you want.
Still, the YAST license is the main reason why I am still running Red Hat on my machines. There are other reasons (Red Hat is more enterprise-friendly in the way they lay out their filesystem, for example), but the YAST license is the key.
-E
Good ole' Gerald Holmes. You must admit that he's a mildly talented satirist (grin).
-E
Which is why my resume was in HTML when I was looking for a job. Strangely enough, I got a couple of replies back amazingly similar to the guy in question. The only question I can ask is: why? Why should I waste my time dealing with the clueless? If a company can't hire competent HR people, why should I assume that they have competent engineers or managers?
Of course all that resume shopping wasn't how I ended up getting a job in the end...
-E
It's not just Linux that Bob 'doesn't get'. It's the Internet as a whole. Linux is just the latest Internet phenomenon to be the target of Bob's bile.
Bob doesn't like the Internet because it is anarchic, has no central point of control, and seemingly develops every which way without any rhyme or reason. This offends his sensibilities. Ethernet had a classic sensibility which reflects Bob's psyche. The Internet doesn't. Every year he predicts that the Internet will collapse under its own weight by the end of the year. Every year he is proven wrong. But that does not stop him from predicting, every year, that only per-minute charges will save the Internet from collapse.
This is the same guy who has said, for each of the last three years, that the Internet will collapse by the end of the year and that the only solution is to charge per-minute fees for Internet access.
.000 here. I suspect his annual "the fall of Linux" speech will start to acquire the same patina as his annual "the collapse of the Internet" speech, for the same reason -- Bob simply does not understand how an anarchic network of developers can keep something like the Internet or Linux going. Bob is the classic Cathedral guy in Eric S. Raymond's "Cathedral and Bazarre". The operations of a bazarre frighten him. Ethernet has a classic simplicity reflective of Bob's highly ordered personality. When he sees the Internet or Linux, he sees chaos, and cannot see why it does not collapse under its own weight.
So far he's batting
-E
At the time the Mindcraft paper came out, I was working for Linux Hardware Solutions. My first thought, upon looking at their numbers, was "man, that Dell SUCKS! I wonder how much they'd charge to benchmark one of our boxes against that Dell? We'll wipe Dell's rear!"
My next thought, however, after looking over the details of the "benchmark", was "man, I wouldn't want those incompetents near my computer." There are plenty of reputable benchmarking outfits. Giving Mindcraft more business is NOT a proper solution -- Mindcraft has proven that they are incapable of conducting themselves professionally. They poorly served Microsoft by doing a "benchmark" that had so many holes in it that even the press didn't believe it. Remember, their job was to generate numbers that would be believed -- and they failed miserably. Should we reward such failure with more money?!
-E
Let me get this straight. Your idea for fixing the scalability problems of Sendmail is to create a config file format that takes MORE horsepower to parse (regular expressions)?
I'll agree Sendmail needs a major overhaul and that the config file format is a disaster, but let's face it, anything as flexible as sendmail will have the same scalability problems as sendmail. The only solution to those scalability problems is to go with a less flexible MTA. Sort of like in web server, where if you want flexibility you go with Apache, but if you want speed, you go with thttpd or Zeus.
-E
My primary concern is that Red Hat appears to be forgetting the reasons for their success. Some reasons why, in the past, I standardized on Red Hat:
/incoming directory has disappeared and there are no directions on any Red Hat web site on how to contribute to RHCN, the purported replacement. Don't believe me? Try http://developer.redhat.com and http://rhcn.redhat.com!
1) Large amount of contributed software on their FTP site. Now the
2) Swift bug releases. In the past, Red Hat swiftly released bug fixes. Today, go browse BugZilla on http://developer.redhat.com . Look for problems with, for example, the NIS daemon. Look at the "Resolution" box. I'll bet you that 99% of the bugs you find will have "WONTFIX" or "LATER" (fixed in later release, not in 6.0) in the "Resolution" box. For some things this does not matter. For others it does -- for example, the NIS password daemon dying is a major bug for those of us who use NIS, and it is marked as "LATER". It appears that the automatic response of the poor slob they have monitoring these hundreds of bugs is to automatically put "LATER" or "WONTFIX" into that box so that he won't have to actually do anything about them (work? gosh, what's that?!).
3) A coherent web site. In the past, Red Hat had the best web site of any distribution. It was chock-full of information, you could find out almost anything you needed to know about Red Hat Linux by following the links, it pointed you to their mailing lists, etc. Now it's a mess. You can't find anything, the links are all broken (like the one on how to contribute to RHCN!), and you can tell that behind the scenes, the thing is torn to pieces and the mechanics are scratching their heads trying to figure out how to put it back together again. In short, it's a mess.
These are growing pains, certainly. But unless Red Hat remembers why they got where they are, they're going to start losing market share -- and once that happens, they'll lose their luster of invincibility and end up being just another distribution.
-- Eric
I have an Integrated Development Environment. It is named /bin/bash (grin).
-E
Value Added.
When you buy a VA machine, you know you're getting components that run well with Linux (as vs. components that run well with NT, that might run crappy with Linux -- like the Dell that MindCraft used to out-benchmark Linux), and you know that you have access to big-name talent if you run into driver problems or something else of that nature. If you buy a Dell... well, Dell knows NT, but Dell doesn't know Linux.
This isn't enough to make VA a compelling buy at the low end, but for people wanting mission-critical Linux servers, they want to buy those from a company that has Linux expertise, not from Joe's Screwdriver Shop or Dell NT Systems.
Note: I don't work for VA or any Linux hardware vendor, and have no reason to hype VA (I'm now working for a software vendor as a database programmer and system administrator, my true love). That doesn't change the "facts on the ground", which is that when people want mission-critical Linux servers, they don't buy them from Bob's Screwdriver Shop.
I know for a fact that the ASUS P2BF has a "AC Power Fail Auto-Restart" BIOS option and the Intel Nightshade has a "Restore Power State" BIOS option that will turn the power on automatically if it was on when AC power was lost (i.e. power was not turned off via the front panel switch).
Note that the Constititution allows suspension of habeas corpus (i.e., things like the internment of Japanese-Americans) only when a state of war has been declared by the Congress of the United States of America. When we are official "at peace", such as today, those rights cannot be suspended on spurious "national security" grounds.
Even worse, if you're thinking about laptops. Right now the only low-power x86-compatible processor out there is the IDT Winchip, which is woefully underpowered for a Windows laptop (it does manage to keep out of its way with Linux, though -- that's what the Netiers use, due to its low power consumption).
-E