SCO's sales have not "really" increased dramatically recently. What you are seeing is the final retirement of many older SCO Unix systems, which are having to be upgraded to SCO OpenServer or UnixWare because they were not Y2K compliant. A lot of people, unlike my former employer, left that Y2K upgrade until the last minute, leaving them no time to change to Linux or some other platform before the stroke of doom hits. Thus SCO is smiling all the way to the bank.
In addition, SCO has some additional revenue due to their 64-bit port that is being done to Merced under contract to Intel (and somebody else, but I don't remember who, was it HP?). But this does not really count as sales, even though it is a big boost to their bottom line.
I have a hunch that if you take out the Y2K stuff, SCO's sales are actually stagnant. SCO's problem is that their entire VAR network was set up around SCO Unix feeding a multi-port serial card feeding dumb terminals, and that paradigm isn't going to take them far into the next century. If they had expressed an interest in Internet serving earlier, they could have jumped onto that bandwagon, but they let Linux and the BSD's (including BSDI) and Sun go after that market for some reason. Reading SCO World back in the mid 90's, you would have thought that the Internet did not exist. About the only thing they do have going for them is big name databases running on SCO Unix already, stable and proven. That will take them a little bit further and is, in fact, the primary reason SCO Unix is still alive -- until recently, your choices in the big name database market for a reasonable price were NT, SCO Unix, and RISC Unix, and if you wanted x86 platform on a non-MS OS, SCO Unix was it. But as database vendor support for Linux solidifies that's going to become less and less a factor. I would not invest in SCO right now (grin).
There are a lot bigger fish to go after in terms of lawsuits. Why should Bob Young waste time, money, and anguish over something said by the CEO of a dying company that his company is in the process of driving out of business the old-fashioned way, by having a better product for a better price? Bob's revenge is going to be when SCO declares Chapter 7. Beside that, a lawsuit would blatant overkill.
My employer at the time made the transition in spring of 1996. SCO had discontinued Xenix by then, and our customers were VERY unhappy about the thought of paying massive per-user fees when we upgraded their old Xenix servers (Xenix was unlimited user). I tried running our database engine under iBCS2 on Linux and guess what? It actually ran FASTER than on SCO Unix!
When the bid season started, my boss looked at the per-user charges for Linux, looked at the per-user charges for SCO Unix, asked me what the downside was, and all I could do was shrug and say "I don't know, I've been doing my development under Linux for the last three months and then porting it to SCO, everything seems to work right and work faster."
One trial school district later, and it was official: Linux was more stable and more feature-ful than SCO Unix, and ran like a scalded cat even on lowly IDE drives (SCO Unix runs like a bored tortoise on IDE). Porting our SCO Unix application to Linux was basically a case of re-compiling and fixing some minor printer issues in our code (since Linux uses the BSD print spooler while SCO uses the Sys V print spooler).
Y2K hurried the move to Linux too, since all the older SCO boxes had Y2K issues.
I know for a fact that SCO lost over $250,000 in sales from that single move to Linux. Multiply that by every other SCO VAR that is looking at Linux or has switched to Linux, and you can only conclude that SCO would have at least twice the revenue that they have today, if not for Linux.
It's interesting that Slackware originated because SLS did the same thing as SuSE: they copyrighted their installer/configuration tool as non-free software. Thus Pat Volkerding could not distribute a "fixed" SLS with all the patches he wanted in it, so he had to re-write the installer from scratch.
SLS is long gone, and Slackware still remains. Who gets the last laugh?
Now you know why I no longer run SuSE on my machines. Don't get me wrong, it's a great distribution. But until the YaST license is freed, I intend to avoid it. After all, the whole point of free software is to get away from restrictive licenses.
Please read the license agreement you agree to in order to run Windows NT, Solaris, or etc. It specifically states that if you run this software, you are agreeing to this license. And it specifically says that this software comes with *NO WARRANTY* and that the OS vendor is not responsible for any losses that occur due to its use.
Find me *ONE* instance of a business suing Microsoft because of losses caused by problems with Windows NT. ONE instance. I bet you won't find one, because any lawyer on the planet would laugh you out of their office if you walked in and said "I want to sue Microsoft because Windows NT ate my company's payroll." It just can't be done, because you signed away your right to sue when you agreed to the NT license. A contract is a contract, bud, and if you don't want to abide by your side of the contract, then don't enter into it.
Which, of course, is where Linux comes in. If there's a bug in Linux at least you can fix it yourself. In the meantime, my brother's company is spending large sums of money due to NT crashes and reboots. Every time NT crashes out on an oil rig out in the Gulf of Mexico, they have to spend close to a thousand dollars flying somebody out there on a helicopter to fix it. The biggest problem, memory leaks in the DCOM stack, recieves a big "that will be fixed in Windows 2000" response from Microsoft. That doesn't help him now!
Yeah. Accountability. Sure. What you REALLY mean is that Microsoft provides an excuse. Can't get your network to work properly? Blame it on Microsoft instead of getting off your fat overpaid bum and fixing it!
He may be talking about the (currently non-existent) Linux Standard Base, and the question of whether Red Hat will comply with it or not (Red Hat says "yes, with caveats", from what I can tell -- i.e., if it is a totally brain dead standard, they reserve the right to say so and opt out).
As far as the FSSTAND goes, Red Hat does quite well at complying with the major portions of it. The only thing I can think of that they don't do correctly is that print filter configuration stuff is in/var/spool/lpd along with spool files, rather than being somewhere under/etc like the FSSTD says all config files should be. Still, that's not as non-compliant as some of what SuSE was doing last time I checked (*THEY TOUCHED MY/USR/LOCAL! THE CADS!!!*).
Really, I think Red Hat is attacked not because of what they've done, but, rather, because they are successful. There's always a fringe around that is ready to attack anybody who is actually doing something. Usually these are 16 year old script kiddies who have opinions about everything, know it all, and believe they are God's gift to programmers because they figured out how to compile "hello.c" last week (you know, the one that prints "Hello World!" on the screen?).
>What is really interesting are the comments like I have been using LINUX since (insert year here), but (insert bad comment here)
Ah yes, ye old "false sincerity" distraction method. Usually used when you're lying through your teeth.
The funny part is when these supposed "experts" make newbie factual errors in their so-called "arguments". Then it becomes obvious to any Linux user that they don't know what they're talking about. Alas, a Microsoft user doesn't know any better...
I recently upgraded my computer at home from a Cyrix 166 (not even MMX) to a Celeron 300A. Not by choice, but because I left the case off one night and one of my cats decided that all those pretty wires blowing in the breeze inside the machine were pretty colored twine to play with, and he managed to fry my motherboard. Anyhow -- if it hadn't been for that, I'd still be running the Cyrix, because it was plenty fast for surfing the net and running Applix. The only time I ever wished it was faster was when doing kernel compiles, and how many kernel compiles does the average (non-kernel-hacker) do? --
The cause of Commodore's horrible death was Commodore, not Microsoft.
As a former Amiga developer I could go on, but it disgusts me too much to think about it. Let's just say that through most of the Amiga's lifetime, it faced no real technical challenge from MS-DOS or MacOS. The basic problem was one of marketing -- Commodore was handed a graphics workstation on a silver platter, and all they knew how to do was sell game machines. And they weren't too good even at that.
To come up with benchmarks that fairly measure a platform's capabilities (as vs. Mindcraft benchmarks!) is hard. It is especially hard if you are doing network benchmarks (file serving, web serving, etc.) and you want the numbers to be meaningful -- very few people have a gigabit Ethernet and a hundred client machines in their back room!
The only way I can see to do it is a group effort via user groups and Linux vendors. I cannot think what form that effort would take, though.
I guess part of it is that it's always fun to second-guess and pick nits with what a big company is doing. I don't think anybody seriously thinks that Compaq is going to go out of business. Rather, they are hitting a rough patch like IBM did ten years ago, for much the same reason -- too much proprietary stuff in their computers.
Compaq has great servers. Compaq has great laptops. They have great engineers working on those servers and laptops. (There's more that I can't say there, but you'll understand that later). Their mid-range desktop machines, on the other hand, have (or used to have, anyhow) entirely too much proprietary stuff in them. The question is whether Compaq can rein in their vaunted engineering department and focus their efforts towards bringing out good product in a timely manner, rather than spending months after the competition has come out with "generic" stuff in order to come out with their proprietary stuff.
Anyhow: It's fun second-guessing Compaq. But let's not attach too much importance to it. Compaq isn't going anywhere anytime soon. Hopefully, with renewed focus from corporate management and renewed attention to pruning their management bureaucracy, they will soon be once again turning the kinds of numbers that people expect from them.
I certainly hope that university students are not developing parts of Linux on university equipment. According to the terms & conditions that I had to sign to get a university account when I was in college, everything that I wrote on university equipment was university property.
One of the most shameful things happening at America's universities right now is that large amounts of the research being done will never see the light of day because either a) the university takes control of it and licenses it to a commercial party for money, or b) it's being done under contract to a commercial party in the first place.
I do agree that the major vendors' donations have been well appreciated by the smaller universities that have a need for them. I know that at the university that I graduated from, the computer science department sneered at PC's (they were Unix all the way, with a Sun workstation on every professor's desk), but the engineering department definitely didn't sneer at their lab-full of donated Zenith machines (whoops, I'm showing my age!).
For those of you who are DELL employees and who disagree with my thesis:
I am not trying to slam DELL. I admire DELL greatly.
I agree that Compaq is not going away. At the very low and at the high end, their approach works. What they need to do is get away from the proprietary crap in the $1K-$2k range (my opinion -- computers w/proprietary floppy drives?! Sheesh).
For those slamming VA Research, LHS, etc.: if you can build a better machine, DO IT. Nobody forces you to buy one from these guys. All I'll point out is that these guys have been supporting Linux from the beginning, rather than piddling silliness on Slashdot the way some people do. It wasn't DELL that donated the server that Slashdot is running on. It wasn't DELL that donated the servers that Debian's web and FTP sites are running on. Understand?
Regarding these folks being scared of DELL: You betcha. VAR, LHS, etc. are going to either have to staff up SWIFTLY and pour in a lot of venture capital money in order to match Dell's marketing reach, manufacturing and design ability, and quality, or else find a niche that Dell doesn't market into and quietly live a small life there. VA Research is taking venture capital, so I have a suspicion that I know which route they're taking. I won't comment on any other vendor's plans, for obvious reasons (conflict of interest, or etc.).
You may not care where I work, but others in the past have cared and have mistaken my views for those of my employer. Perhaps I should change my signature to simply say "These opinions are not my employer's" without mentioning a name, but on the other hand, it's not as if my EMAIL address and web site URL aren't a clue there (DUH!). I suspect in the future I'm going to have to purchase my own domain name and host my web site and EMAIL elsewhere, but at the moment I'm lazy and poor so I'm not doing it.
I usually don't respond to Anonymous Cowards for obvious reasons (they are usually trolls tossing out flame bait like yours). But so it goes.
This is to all those computer companies out there that are wanting to be "the next Compaq": Don't. If you want to be "the next" anything, be "the next Dell".
Compaq's problems stemmed from the same basic flaw as Apple's problems: they engineered too much of their own hardware. That is acceptable for high-volume low-cost widgets like the $500 eMachines units, where scraping 15 cents off the cost can be millions in extra profits, but it is not acceptable in the $1K-$2K market. In that market, every Joe Consultant in Hoboken is building computers out of "white boxes" in their back room, and according to at least one survey that I saw, as much as 50% of the personal computers sold may be going through that channel.
Compaq's engineers have always laughed at Dell. They have sneered at Dell's "white boxes" (Dell does very little of their own design work, mostly re-packaging generic commodity components). Dell laughs all the way to the bank.
Apple is doomed, in the end, because they cannot compete on a cost-basis with equivalent Intel boxes. One company engineering all of their own hardware cannot compete with companies that outsource commodity hardware from specialists in that particular type of hardware. Apple cannot build a motherboard for as cheap as ABIT or some other company that specializes only in motherboards, for example.
Lessons learned: Engineering your own hardware works only for ultra-low-cost-high-volume work, or for stuff there isn't enough volume for "generic" hardware. In the vast middle of the road, using commodity components gets you a better computer for a lower cost.
Why this is important to us:
Microsoft is like the Apple of the operating systems world. They engineer all of their own components in-house so that they can have "total control".
Linux, on the other hand, is the "white box" operating system of the new era. Linux vendors collect commodity software components from various locations, integrate them, and release the result as a single product. Much like a "white box" manufacturer looks through the available video cards to decide which one to put into his computer, the "white box" Linux vendor looks through the available 'lpd' daemons to decide which one to put in his distribution, for example. Then, like the 'white box' computer manufacturers, the 'white box' Linux vendor then differentiates himself from his competitors through a) the choice of components that he uses (e.g., glibc? libc5?), b), the kind of service he offers, c) "widget frosting", such as a nice installer, better config tool, or whatever, d) advertising and image. Part of which may be releasing software created internally as Open Source... for example, Red Hat gained much of their mind share in the early days by releasing things like 'rpm' as Open Source.
The value of this "white box" paradigm for creating operating systems is that it inevitably adds to the supply of commodity components for building operating systems, and thus will inevitably result in better operating systems components, much like having multiple video card vendors has resulted in better video cards. Bill Gates views the GNOME vs KDE thing as a weakness. I view it as a strength, much like nVidia vs. 3dfx. Just as having two 3d video card giants helps drive innovation in the 3d video card industry, having two desktop environment giants will inevitably help drive innovation in the desktop environment industry... and thus add to the supply of commodity components that we put together on a CD and call "Linux" (GNU/Linux, for you purists out there!).
The semi-official position at LHS is that if you're using Red Hat 5.2, you should use the 2.0.36-3 kernel from updates.redhat.com. The only exception is if you are doing SMP, where the performance advantages of 2.2 far outweigh the disadvantages of using software that is still in active development.
Of course, I had downloaded and installed 2.2.6 here on my personal machine at home within 12 hours of its release (grin). (And found a few glitches in it, but that's another story).
If I recall correctly, to go from 2.0.0 to 2.0.18 took two months. Some of those early 2.0 kernels didn't last 2 days before the next patch came out.
The 2.2 patch cycle is moving MUCH more slowly than that. At the current rate, I suspect that we'll end up at around 2.2.10 before Linus declares 2.2 to be "finished" and opens up 2.3. After that, you should see a new patch every 3 to 6 months, depending upon what bugs are found in the new kernel and what features have been back-ported from the 2.3 series.
1) VA may be thinking of coming out with a competitor to the Cobalt Qube. Think Netwinder except perhaps Intel-powered (considering VA's connections with Intel).
2) VA may be thinking of coming out with their own motherboards for (choose one) laptop, high-end server, or diskless workstation, and needs someone expert in BIOS issues to make the BIOS part work.
Please note that I have no real idea what VA is up to, for obvious reasons (I don't work for them!). Just that those would be why *I* would want to hire him, if I had the R&D budget to do so.
Our web server has been up for 167 days without a reboot. Our EMAIL server has "only" been up for 122 days (somebody kicked the cord loose one day, argh!).
But, of course, that's all just stories. Actually measuring reliability is a difficult task. How do you tell how reliable an OS is? Can't run it in a laboratory setting, it'll never crash there, it's in the real world that systems crash. Yet it's in the real world, doing real work, that it's hardest to monitor enough systems doing enough work to get statistically significant numbers.
Agree, DH Brown was basically accurate. The only thing that I disagree with was their wording on the state of Linux SMP. From talking with one of their people, it appears that what they meant was that Linux SMP was still immature and unproven and thus they would not yet bet an enterprise on it, but it came out unduly harsh in the paper.
My only real complaint is that they said NT is enterprise-ready, when it so obviously isn't!
On the other hand, Mindcraft "study" was either the most inept piece of work that I ever saw, or a deliberate hack job. (And if it's a deliberate hack job, it's the most inept hack job I've ever seen!). The best thing that Mindcraft could do to salvage their reputation would be to withdraw the report "for further study" until its deficiencies are resolved, but I frankly suspect it'll be a cold day in hell first -- they've been paid for it already.
One thing that I had been discussing with a representative of D.H. Brown was the need for good testing of high-end Linux configurations vs. equivalent NT configurations. One thing that frustrated them, and led to their downgrading of Linux at the high end, was the lack of good objective data to work with (D.H. Brown does not do testing, they do executive analysis, i.e., they read the tests already published so that executives don't have to).
I can't say more along those lines, but: My first instinct, upon seeing Mindcraft's report, was "Wow, that Dell sucks! I wonder how much they'd charge to benchmark our Linux Hardware Solutions quad-Xeon against that box? We'd SLAUGHTER Dell!" But then the realization struck: If these people showed such a lack of professionalism as they did in this report, would we WANT to pay them money? I.e., why in the world would we pay people who have already demonstrated that they are a laughingstock by releasing a report such as this which can be viewed, at best, as unprofessional, and at worst, as an amateurish attempt at dissing Linux? Needless to say, any testing done in the future on our behalf will be done by someone OTHER than Mindcraft.
1) As someone pointed out to me via EMAIL, Apache actually opens most of those file handles prior to forking. Thus most of them are shared between the various Apache processes. In actuality, you'll eat up at least two file handles for each Apache process.
2) The 2.2 kernel defaults to 4096 file handles, as vs. the 1024 default for the 2.0 kernel, so it's unlikely that he was running out of file handles.
Still, obviously he did something wrong, because Apache usually does not collapse like that. It simply degrades gracefully, assuming max_clients is set so that you don't thrash the machine to death (and his message says he wasn't thrashing). See what happened when the Slashdot Effect hit the Linux Counter... once he brought down his max, it simply got slow but kept chugging out the requests. Puzzling. Without access to the server logs and httpd.conf files, it's unlikely we'll ever know what or how he did it, though.
It's a little late to sponsor such a contest. It takes a week to ship something via motor freight from either coast to Chicago. Believe me, a 200-pound server is *NOT* shipped via Federal Express Overnight Air!
Hard to get newsgroup support for that sort of stuff? You bet!
I know that I had no incentive to go dig this "will @ whistlingfish" out of his hole. I couldn't make heads nor tails of that posting when it was new, and there's too many other postings to reply to where people actually give useful information about their problem for me to bother with something like that.
Slashdot Mirror
SCO's sales have not "really" increased dramatically recently. What you are seeing is the final retirement of many older SCO Unix systems, which are having to be upgraded to SCO OpenServer or UnixWare because they were not Y2K compliant. A lot of people, unlike my former employer, left that Y2K upgrade until the last minute, leaving them no time to change to Linux or some other platform before the stroke of doom hits. Thus SCO is smiling all the way to the bank.
In addition, SCO has some additional revenue due to their 64-bit port that is being done to Merced under contract to Intel (and somebody else, but I don't remember who, was it HP?). But this does not really count as sales, even though it is a big boost to their bottom line.
I have a hunch that if you take out the Y2K stuff, SCO's sales are actually stagnant. SCO's problem is that their entire VAR network was set up around SCO Unix feeding a multi-port serial card feeding dumb terminals, and that paradigm isn't going to take them far into the next century. If they had expressed an interest in Internet serving earlier, they could have jumped onto that bandwagon, but they let Linux and the BSD's (including BSDI) and Sun go after that market for some reason. Reading SCO World back in the mid 90's, you would have thought that the Internet did not exist.
About the only thing they do have going for them is big name databases running on SCO Unix already, stable and proven. That will take them a little bit further and is, in fact, the primary reason SCO Unix is still alive -- until recently, your choices in the big name database market for a reasonable price were NT, SCO Unix, and RISC Unix, and if you wanted x86 platform on a non-MS OS, SCO Unix was it. But as database vendor support for Linux solidifies that's going to become less and less a factor.
I would not invest in SCO right now (grin).
There are a lot bigger fish to go after in terms of lawsuits. Why should Bob Young waste time, money, and anguish over something said by the CEO of a dying company that his company is in the process of driving out of business the old-fashioned way, by having a better product for a better price?
Bob's revenge is going to be when SCO declares Chapter 7. Beside that, a lawsuit would blatant overkill.
My employer at the time made the transition in spring of 1996. SCO had discontinued Xenix by then, and our customers were VERY unhappy about the thought of paying massive per-user fees when we upgraded their old Xenix servers (Xenix was unlimited user). I tried running our database engine under iBCS2 on Linux and guess what? It actually ran FASTER than on SCO Unix!
When the bid season started, my boss looked at the per-user charges for Linux, looked at the per-user charges for SCO Unix, asked me what the downside was, and all I could do was shrug and say "I don't know, I've been doing my development under Linux for the last three months and then porting it to SCO, everything seems to work right and work faster."
One trial school district later, and it was official: Linux was more stable and more feature-ful than SCO Unix, and ran like a scalded cat even on lowly IDE drives (SCO Unix runs like a bored tortoise on IDE). Porting our SCO Unix application to Linux was basically a case of re-compiling and fixing some minor printer issues in our code (since Linux uses the BSD print spooler while SCO uses the Sys V print spooler).
Y2K hurried the move to Linux too, since all the older SCO boxes had Y2K issues.
I know for a fact that SCO lost over $250,000 in sales from that single move to Linux. Multiply that by every other SCO VAR that is looking at Linux or has switched to Linux, and you can only conclude that SCO would have at least twice the revenue that they have today, if not for Linux.
-- Eric
It's interesting that Slackware originated because SLS did the same thing as SuSE: they copyrighted their installer/configuration tool as non-free software. Thus Pat Volkerding could not distribute a "fixed" SLS with all the patches he wanted in it, so he had to re-write the installer from scratch.
SLS is long gone, and Slackware still remains. Who gets the last laugh?
Now you know why I no longer run SuSE on my machines. Don't get me wrong, it's a great distribution. But until the YaST license is freed, I intend to avoid it. After all, the whole point of free software is to get away from restrictive licenses.
Please read the license agreement you agree to in order to run Windows NT, Solaris, or etc. It specifically states that if you run this software, you are agreeing to this license. And it specifically says that this software comes with *NO WARRANTY* and that the OS vendor is not responsible for any losses that occur due to its use.
Find me *ONE* instance of a business suing Microsoft because of losses caused by problems with Windows NT. ONE instance. I bet you won't find one, because any lawyer on the planet would laugh you out of their office if you walked in and said "I want to sue Microsoft because Windows NT ate my company's payroll." It just can't be done, because you signed away your right to sue when you agreed to the NT license. A contract is a contract, bud, and if you don't want to abide by your side of the contract, then don't enter into it.
Which, of course, is where Linux comes in. If there's a bug in Linux at least you can fix it yourself. In the meantime, my brother's company is spending large sums of money due to NT crashes and reboots. Every time NT crashes out on an oil rig out in the Gulf of Mexico, they have to spend close to a thousand dollars flying somebody out there on a helicopter to fix it. The biggest problem, memory leaks in the DCOM stack, recieves a big "that will be fixed in Windows 2000" response from Microsoft. That doesn't help him now!
Yeah. Accountability. Sure. What you REALLY mean is that Microsoft provides an excuse. Can't get your network to work properly? Blame it on Microsoft instead of getting off your fat overpaid bum and fixing it!
He may be talking about the (currently non-existent) Linux Standard Base, and the question of whether Red Hat will comply with it or not (Red Hat says "yes, with caveats", from what I can tell -- i.e., if it is a totally brain dead standard, they reserve the right to say so and opt out).
/var/spool/lpd along with spool files, rather than being somewhere under /etc like the FSSTD says all config files should be. Still, that's not as non-compliant as some of what SuSE was doing last time I checked (*THEY TOUCHED MY /USR/LOCAL! THE CADS!!!*).
As far as the FSSTAND goes, Red Hat does quite well at complying with the major portions of it. The only thing I can think of that they don't do correctly is that print filter configuration stuff is in
Really, I think Red Hat is attacked not because of what they've done, but, rather, because they are successful. There's always a fringe around that is ready to attack anybody who is actually doing something. Usually these are 16 year old script kiddies who have opinions about everything, know it all, and believe they are God's gift to programmers because they figured out how to compile "hello.c" last week (you know, the one that prints "Hello World!" on the screen?).
-- Eric
Do a webcrawler or yahoo search for "mouse balls" (grin).
>What is really interesting are the comments like I have been using LINUX since (insert year here), but (insert bad comment here)
Ah yes, ye old "false sincerity" distraction method. Usually used when you're lying through your teeth.
The funny part is when these supposed "experts" make newbie factual errors in their so-called "arguments". Then it becomes obvious to any Linux user that they don't know what they're talking about. Alas, a Microsoft user doesn't know any better...
-E
I recently upgraded my computer at home from a Cyrix 166 (not even MMX) to a Celeron 300A. Not by choice, but because I left the case off one night and one of my cats decided that all those pretty wires blowing in the breeze inside the machine were pretty colored twine to play with, and he managed to fry my motherboard. Anyhow -- if it hadn't been for that, I'd still be running the Cyrix, because it was plenty fast for surfing the net and running Applix. The only time I ever wished it was faster was when doing kernel compiles, and how many kernel compiles does the average (non-kernel-hacker) do?
--
The cause of Commodore's horrible death was Commodore, not Microsoft.
As a former Amiga developer I could go on, but it disgusts me too much to think about it. Let's just say that through most of the Amiga's lifetime, it faced no real technical challenge from MS-DOS or MacOS. The basic problem was one of marketing -- Commodore was handed a graphics workstation on a silver platter, and all they knew how to do was sell game machines. And they weren't too good even at that.
To come up with benchmarks that fairly measure a platform's capabilities (as vs. Mindcraft benchmarks!) is hard. It is especially hard if you are doing network benchmarks (file serving, web serving, etc.) and you want the numbers to be meaningful -- very few people have a gigabit Ethernet and a hundred client machines in their back room!
The only way I can see to do it is a group effort via user groups and Linux vendors. I cannot think what form that effort would take, though.
-- Eric
I guess part of it is that it's always fun to second-guess and pick nits with what a big company is doing. I don't think anybody seriously thinks that Compaq is going to go out of business. Rather, they are hitting a rough patch like IBM did ten years ago, for much the same reason -- too much proprietary stuff in their computers.
Compaq has great servers. Compaq has great laptops. They have great engineers working on those servers and laptops. (There's more that I can't say there, but you'll understand that later). Their mid-range desktop machines, on the other hand, have (or used to have, anyhow) entirely too much proprietary stuff in them. The question is whether Compaq can rein in their vaunted engineering department and focus their efforts towards bringing out good product in a timely manner, rather than spending months after the competition has come out with "generic" stuff in order to come out with their proprietary stuff.
Anyhow: It's fun second-guessing Compaq. But let's not attach too much importance to it. Compaq isn't going anywhere anytime soon. Hopefully, with renewed focus from corporate management and renewed attention to pruning their management bureaucracy, they will soon be once again turning the kinds of numbers that people expect from them.
-- Eric
I certainly hope that university students are not developing parts of Linux on university equipment. According to the terms & conditions that I had to sign to get a university account when I was in college, everything that I wrote on university equipment was university property.
One of the most shameful things happening at America's universities right now is that large amounts of the research being done will never see the light of day because either a) the university takes control of it and licenses it to a commercial party for money, or b) it's being done under contract to a commercial party in the first place.
I do agree that the major vendors' donations have been well appreciated by the smaller universities that have a need for them. I know that at the university that I graduated from, the computer science department sneered at PC's (they were Unix all the way, with a Sun workstation on every professor's desk), but the engineering department definitely didn't sneer at their lab-full of donated Zenith machines (whoops, I'm showing my age!).
-- Eric
For those of you who are DELL employees and who disagree with my thesis:
I am not trying to slam DELL. I admire DELL greatly.
I agree that Compaq is not going away. At the very low and at the high end, their approach works. What they need to do is get away from the proprietary crap in the $1K-$2k range (my opinion -- computers w/proprietary floppy drives?! Sheesh).
For those slamming VA Research, LHS, etc.: if you can build a better machine, DO IT. Nobody forces you to buy one from these guys. All I'll point out is that these guys have been supporting Linux from the beginning, rather than piddling silliness on Slashdot the way some people do. It wasn't DELL that donated the server that Slashdot is running on. It wasn't DELL that donated the servers that Debian's web and FTP sites are running on. Understand?
Regarding these folks being scared of DELL: You betcha. VAR, LHS, etc. are going to either have to staff up SWIFTLY and pour in a lot of venture capital money in order to match Dell's marketing reach, manufacturing and design ability, and quality, or else find a niche that Dell doesn't market into and quietly live a small life there. VA Research is taking venture capital, so I have a suspicion that I know which route they're taking. I won't comment on any other vendor's plans, for obvious reasons (conflict of interest, or etc.).
You may not care where I work, but others in the past have cared and have mistaken my views for those of my employer. Perhaps I should change my signature to simply say "These opinions are not my employer's" without mentioning a name, but on the other hand, it's not as if my EMAIL address and web site URL aren't a clue there (DUH!). I suspect in the future I'm going to have to purchase my own domain name and host my web site and EMAIL elsewhere, but at the moment I'm lazy and poor so I'm not doing it.
I usually don't respond to Anonymous Cowards for obvious reasons (they are usually trolls tossing out flame bait like yours). But so it goes.
-- Eric
[Not speaking for my employer.]
This is to all those computer companies out there that are wanting to be "the next Compaq": Don't. If you want to be "the next" anything, be "the next Dell".
Compaq's problems stemmed from the same basic flaw as Apple's problems: they engineered too much of their own hardware. That is acceptable for high-volume low-cost widgets like the $500 eMachines units, where scraping 15 cents off the cost can be millions in extra profits, but it is not acceptable in the $1K-$2K market. In that market, every Joe Consultant in Hoboken is building computers out of "white boxes" in their back room, and according to at least one survey that I saw, as much as 50% of the personal computers sold may be going through that channel.
Compaq's engineers have always laughed at Dell. They have sneered at Dell's "white boxes" (Dell does very little of their own design work, mostly re-packaging generic commodity components). Dell laughs all the way to the bank.
Apple is doomed, in the end, because they cannot compete on a cost-basis with equivalent Intel boxes. One company engineering all of their own hardware cannot compete with companies that outsource commodity hardware from specialists in that particular type of hardware. Apple cannot build a motherboard for as cheap as ABIT or some other company that specializes only in motherboards, for example.
Lessons learned:
Engineering your own hardware works only for ultra-low-cost-high-volume work, or for stuff there isn't enough volume for "generic" hardware. In the vast middle of the road, using commodity components gets you a better computer for a lower cost.
Why this is important to us:
Microsoft is like the Apple of the operating systems world. They engineer all of their own components in-house so that they can have "total control".
Linux, on the other hand, is the "white box" operating system of the new era. Linux vendors collect commodity software components from various locations, integrate them, and release the result as a single product. Much like a "white box" manufacturer looks through the available video cards to decide which one to put into his computer, the "white box" Linux vendor looks through the available 'lpd' daemons to decide which one to put in his distribution, for example. Then, like the 'white box' computer manufacturers, the 'white box' Linux vendor then differentiates himself from his competitors through a) the choice of components that he uses (e.g., glibc? libc5?), b), the kind of service he offers, c) "widget frosting", such as a nice installer, better config tool, or whatever, d) advertising and image. Part of which may be releasing software created internally as Open Source... for example, Red Hat gained much of their mind share in the early days by releasing things like 'rpm' as Open Source.
The value of this "white box" paradigm for creating operating systems is that it inevitably adds to the supply of commodity components for building operating systems, and thus will inevitably result in better operating systems components, much like having multiple video card vendors has resulted in better video cards. Bill Gates views the GNOME vs KDE thing as a weakness. I view it as a strength, much like nVidia vs. 3dfx. Just as having two 3d video card giants helps drive innovation in the 3d video card industry, having two desktop environment giants will inevitably help drive innovation in the desktop environment industry... and thus add to the supply of commodity components that we put together on a CD and call "Linux" (GNU/Linux, for you purists out there!).
-- Eric
The semi-official position at LHS is that if you're using Red Hat 5.2, you should use the 2.0.36-3 kernel from updates.redhat.com. The only exception is if you are doing SMP, where the performance advantages of 2.2 far outweigh the disadvantages of using software that is still in active development.
Of course, I had downloaded and installed 2.2.6 here on my personal machine at home within 12 hours of its release (grin). (And found a few glitches in it, but that's another story).
-- Eric
If I recall correctly, to go from 2.0.0 to 2.0.18 took two months. Some of those early 2.0 kernels didn't last 2 days before the next patch came out.
The 2.2 patch cycle is moving MUCH more slowly than that. At the current rate, I suspect that we'll end up at around 2.2.10 before Linus declares 2.2 to be "finished" and opens up 2.3. After that, you should see a new patch every 3 to 6 months, depending upon what bugs are found in the new kernel and what features have been back-ported from the 2.3 series.
We'll see, though!
-- Eric
Looks like they contracted one instead. See the press releases earlier about VA outsourcing the manufacture of most of their systems.
-- Eric
I would suspect two things:
1) VA may be thinking of coming out with a competitor to the Cobalt Qube. Think Netwinder except perhaps Intel-powered (considering VA's connections with Intel).
2) VA may be thinking of coming out with their own motherboards for (choose one) laptop, high-end server, or diskless workstation, and needs someone expert in BIOS issues to make the BIOS part work.
Please note that I have no real idea what VA is up to, for obvious reasons (I don't work for them!). Just that those would be why *I* would want to hire him, if I had the R&D budget to do so.
-- Eric
Our web server has been up for 167 days without a reboot. Our EMAIL server has "only" been up for 122 days (somebody kicked the cord loose one day, argh!).
But, of course, that's all just stories. Actually measuring reliability is a difficult task. How do you tell how reliable an OS is? Can't run it in a laboratory setting, it'll never crash there, it's in the real world that systems crash. Yet it's in the real world, doing real work, that it's hardest to monitor enough systems doing enough work to get statistically significant numbers.
-- Eric
Agree, DH Brown was basically accurate. The only thing that I disagree with was their wording on the state of Linux SMP. From talking with one of their people, it appears that what they meant was that Linux SMP was still immature and unproven and thus they would not yet bet an enterprise on it, but it came out unduly harsh in the paper.
My only real complaint is that they said NT is enterprise-ready, when it so obviously isn't!
On the other hand, Mindcraft "study" was either the most inept piece of work that I ever saw, or a deliberate hack job. (And if it's a deliberate hack job, it's the most inept hack job I've ever seen!). The best thing that Mindcraft could do to salvage their reputation would be to withdraw the report "for further study" until its deficiencies are resolved, but I frankly suspect it'll be a cold day in hell first -- they've been paid for it already.
Of course, they could surprise me!
-- Eric
One thing that I had been discussing with a representative of D.H. Brown was the need for good testing of high-end Linux configurations vs. equivalent NT configurations. One thing that frustrated them, and led to their downgrading of Linux at the high end, was the lack of good objective data to work with (D.H. Brown does not do testing, they do executive analysis, i.e., they read the tests already published so that executives don't have to).
I can't say more along those lines, but:
My first instinct, upon seeing Mindcraft's report, was "Wow, that Dell sucks! I wonder how much they'd charge to benchmark our Linux Hardware Solutions quad-Xeon against that box? We'd SLAUGHTER Dell!"
But then the realization struck: If these people showed such a lack of professionalism as they did in this report, would we WANT to pay them money? I.e., why in the world would we pay people who have already demonstrated that they are a laughingstock by releasing a report such as this which can be viewed, at best, as unprofessional, and at worst, as an amateurish attempt at dissing Linux?
Needless to say, any testing done in the future on our behalf will be done by someone OTHER than Mindcraft.
-- Eric
1) As someone pointed out to me via EMAIL, Apache actually opens most of those file handles prior to forking. Thus most of them are shared between the various Apache processes. In actuality, you'll eat up at least two file handles for each Apache process.
2) The 2.2 kernel defaults to 4096 file handles, as vs. the 1024 default for the 2.0 kernel, so it's unlikely that he was running out of file handles.
Still, obviously he did something wrong, because Apache usually does not collapse like that. It simply degrades gracefully, assuming max_clients is set so that you don't thrash the machine to death (and his message says he wasn't thrashing). See what happened when the Slashdot Effect hit the Linux Counter... once he brought down his max, it simply got slow but kept chugging out the requests. Puzzling. Without access to the server logs and httpd.conf files, it's unlikely we'll ever know what or how he did it, though.
00 Eric
It's a little late to sponsor such a contest. It takes a week to ship something via motor freight from either coast to Chicago. Believe me, a 200-pound server is *NOT* shipped via Federal Express Overnight Air!
-- Eric
Hard to get newsgroup support for that sort of stuff? You bet!
I know that I had no incentive to go dig this "will @ whistlingfish" out of his hole. I couldn't make heads nor tails of that posting when it was new, and there's too many other postings to reply to where people actually give useful information about their problem for me to bother with something like that.
-- Eric