Linus claims that Linux has no guided direction and developes purely through evolution and luck. First off, I would view this as highly insulting if I was a major player like IBM, or even someone who has only minimally contributed. He is basically saying that these people are as useful as a random code generator. Even more importantly, his statement is not true. Linus guides the developement of Linux through his decision to accept and integrate patches. If it were truely evolutionary, Linus would set up a SourceForge project for Linux where anyone could check in changes. That still wouldn't totally eliminate direction, because someone would have to make the decision of when to cut new releases.
The analogy to selective breeding is wrong. Yes, we can speed up evolution through selective breeding, but we are only changing minor traits. Sure, you can breed a dog with long hair, a short snout, and good temperment, but what if you want to breed a dog with feathers, or a fifth leg? At the very best, that would take an incredible amount of time. The better solution is to research and apply genetics. Lets apply that to the kernel... we can either let the scsi mid layer slowly evolve into something useful, or we can sit down and give it a good design phase and have something that works in a much shorter period of time.
Windows does not succeed because of evolution and a deep gene pool. Windows succeeds because of 1) marketing, 2) aggressive business tatics against competitors, and 3) it's not so buggy that it's totally unusable.
I seem to remember an article in Doctor Dobb's Journal from this era that described PNG. It was in the graphics issue, which is published in the summer. I can't remember if it was 1992, 1992, or 1993 though.
3) "New implementation of the TCP/IP stack... replace from the 4.3.xx series". No, the TCP/IP stack was not replaced, and there was no 4.3.xx series. I won't even quote the rediculous crap at the end of that line.
The guy also claims that he is an ex-core team member. This is a highly dubious claim given the junk contained in the post and screename of "Bob Abooey". So in short.... there's nothing to see here, folks. Move along.
My complaint with CVSup is that there's no commandline client! Since I often do work on remote servers with X ports firewalled, this is a bit of a problem for me.
/me looks around for crack pipes
You can either pass cvsup the -g flag as anothre poster noted, or just not have your DISPLAY environment variable set. This is not obscure knowledge... it is clearly documented in the man page and various tutorials.
Moreover, the GUI for the client is just *ugly*. It's this really bad pink colorscheme with Motif style widgets.
Um...excuse me. CD-Rs don't have an aluminum layer.
[snip]
CDR work by having a laser burn a shiny substance sandwiched between two layers of plastic (Both sides are generally clear, but this is because it's cheaper to keep one type of plastic on hand.) When you burn the shiny stuff, it don't shine no mo'.
Um... no. CD-R media does have a reflective aluminum layer. What you 'burn' is a die coating that obscures the aluminum. Burn through the die, and the laser can reflect off of the aluminum behind it. The previous poster might have been thinking of CD-RW media, which uses a layer of amorphorous crystals that change their reflective properties when hit by the 'burning' laser.
I know adaptec has taken over this driver, but what kind of improvements are in this kernel?
1. Active maintainership by the vendor. The author of the previous driver is no longer maintaining it.
2. More robust. This is not meant as a sleight again Doug. This driver has more bugs fixed. That's the one of the advantages of the previous point.
3. True U160 support. The old driver only worked with some U160 configurations, and didn't support U160 transfers.
4. Shared codebase with FreeBSD. This shouldn't surprise anyone, as Justin is a FreeBSD developer. And before you get your panties in a bunch, please remember that the old driver was a port of Justin's work.
Nobody drives a Yugo once and then
decides all cars must suck because they don't steer themselves.
These co-workers of mine weren't looking for a car that could drive itself, they were looking for a tool that could be reliably installed. Look people, the point is being missed here. It's not about how cool Linux is because you have the souce and can fix/improve/etc, it about having a tool for a job (an in, an OS to run a server on) that works. Corporate executives don't give a rats ass that thier junior sysadmin can fix a bug in Linux. They care that the bug had to be fixed in the first place, and that the person who fixed it had to use company money (i.e. his wages during the time that he worked on it) to fix it. Companies don't budget their IT department to be kernel hackers and beta testers.
"I shoulda never sent a penguin out to do a daemon's work."
Why blame the Linux kernel for bugs in Red Hat admin utilities? You did explain to these guys that Red Hat
is neither the only nor the most robust GNU system distribution, right?
Yes I did. It still doesn't change the fact that the first experience with "Linux" for these people was negative. And don't forget that the corporate world by-and-large doesn't understand the whole "distribution" thing. To the CFO's and CEO's of the world, Redhat=Linux. The "distribution" model is crazy, too. It's like saying, "I'm going to buy Oracle Windows NT with the 4.0 kernel", or "I'd like a hammer with a Craftsman head and a Stanley handle". But I rant...
"I shoulda never sent a penguin out to do a daemon's work."
I can find the vast
majority of my bugs by reading the code carefully, thinking about what's going on as it is being executed, and
inserting a few strategically-placed "printfs"
Well, by this logic, why would you need the printf's at all? I mean, if code inspection is the best way to find bugs, then isn't resorting to printf's the second refuge of the incompetent? We all know this argument is foolish, though. Why? Because knowing intermediate values in a method saves time. Why waste time manually iterating through a loop when the computer can do it for you, right? So why shun debuggers when they can help the process out even more? Instead of placing printfs, why not set a breakpoint and examine any piece of data (in scope) that you wish? No edit-recompile is needed. It's a time saving tool, and any practical programmer should recognise that. We don't see anyone in the binutils group saying, "We're wasting out time on gdb, let's can it."
"I shoulda never sent a penguin out to do a daemon's work."
My co-workers and I gripe about the same thing: lack of quality and discipline in Linux. Sure, it's a good OS that has many good merits, but it is seriously mared by it's flaws. Here's an example: two weeks ago I had to train a half dozen non-unix people (all from a software testing lab) in installing RedHat. After explaining how the installer in 6.2 won't partition the hard drive correctly (forcing us to install 6.1 then upgrade), then explaining how X had to be configured after installation because the configurator built into the installer doesn't treat the mouse correctly (an Intellimouse), then explaining how to edit/etc/hosts and/etc/resolv.conf because linuxconf badly mangles them, not a single person was the least bit impressed with RedHat. Sure, it had flashy and cool things, but the bugs are what left the permanent impression in thier minds. The argument of, "Well, you have the source, so go fix it!" doesn't fly for these people; thier job responsibilities do not include debugging the tools needed to do thier job. Until the Linux community can understand this and get quality and professionalism into their products, they will always be second tier.
This is were BSD will win. It may not be as flashy, but it is quality. Each release is integrated from the start and well tested. It is written by software engineers and computer scientists with strong philosophy of quality before quantity. Many, many proposed features in each project have been axed becuase either the risk to stability is too high, or that the feature was not consistent with the whole, or that the result was poorly architected and/or buggy. Yes, there is a bit of a snobish attitude in BSD. That's because the measure of quality is higher than in Linux. The goal is not to take over the world with cool things, it's to provide a quality, dependable, coherent OS.
"I shoulda never sent a penguin out to do a daemon's work."
I highly doubt that 'porting' would be an option. I imagine that Zero Copy requires some rather intimate changes in the TCP stack. Since the Linux and BSD stacks are completely different animals, a major rewrite is the only sensible thing. Besides, the GPL nature of the Linux kernel precludes incorporating BSD code into the 'official' code base.
"I shoulda never sent a penguin out to do a daemon's work."
If I remember correctly, the word here in the Denver area is that the top people in US West will stay at the top after the merge. Oh well. Having lived many places, I can say that US West is by far the worst major telco out there.
"I shoulda never sent a penguin out to do a daemon's work."
I totally agree that the hardware should be fixed. Having Palm provide a "fix" that actually reduces the capability of the device is a sham in my opinion. I paid good money for 8 full megabytes and good battery life. I smell a lawsuit. Oh well if they were sold defective chips. Responsibility to the consumer starts with them; if they want to pass the pain onto the chip maker, that's their perogative.
"I shoulda never sent a penguin out to do a daemon's work."
If the BSDs had a king like Linus to resolve disputes, things would be quite a bit different now. There would be one BSD and it would probably have more marketshare than Linux.
Two things hampered the BSD marketshare: 1) The infamous lawsuit. That scared away the investors and corporations. 2) The GPL jihad. Certain loud voices in the Linux community used it to convince the geek crowd that the only thing worse than acne, the Borg, and dating was having your code 'stolen' by an evil corporation and used to nefarious ends. So, you have the high and low ends of the mindshare market cut out of BSD.
Trust me, you don't want a core team. Well the FreeBSD core team seems to be a heck of a lot better at settling ego disputes than the benevolent dictator model. Yes, two ego disputes ended in a split. It can be argued, though, that three BSD's is less fragmented than 40 or so Linux's.
"I shoulda never sent a penguin out to do a daemon's work."
I have do different questions relating to the who 'Music-Cops-On-The-Net' thing.
1. Very little mention has been made of mp3 (or any file for that matter) distribution over IRC. It certainly is easy enough to locate your favorite music on various channels. So is it trackable? If it is (it would have to be because of the peer-to-peer nature of DCC), why has IRC slipped through without being part of Lar's wrath?
2. What if I put up a file called 'Metallica - They've sold out, man.mp3' that consist of me ranting into a microphone about how Metallica has sucked since the 'Black' album. My name/IP could be snatched up by this software, right? So I get taken down by Napster, or hauled to court... what kind of recourse would I have? Heck, for even more fun, I take my rantings, but call it 'Metallica - Unforgiven.mp3'. How would that affect my legal standing?
"I shoulda never sent a penguin out to do a daemon's work."
Slashdot Mirror
Let's go through Linus' claims:
I seem to remember an article in Doctor Dobb's Journal from this era that described PNG. It was in the graphics issue, which is published in the summer. I can't remember if it was 1992, 1992, or 1993 though.
T WARNER dont feed trolls K PLS THX };-)
Wow, this post most looks most informative, maybe even insightful, doesn't it? In fact, There is very little true about it. Lets take a look here...
...prior backdoors". Bzzzt. Wrong.
... replace from the 4.3.xx series". No, the TCP/IP stack was not replaced, and there was no 4.3.xx series. I won't even quote the rediculous crap at the end of that line.
1) "POSIXX" (sic) "IEEE 811.2b", "Level 4 security". What the hell? It sounds like these were pulled out of the guy's arse.
2) "Hash implementation
3) "New implementation of the TCP/IP stack
The guy also claims that he is an ex-core team member. This is a highly dubious claim given the junk contained in the post and screename of "Bob Abooey". So in short.... there's nothing to see here, folks. Move along.
My complaint with CVSup is that there's no commandline client! Since I often do work on remote servers with X ports firewalled, this is a bit of a problem for me.
/me looks around for crack pipes
You can either pass cvsup the -g flag as anothre poster noted, or just not have your DISPLAY environment variable set. This is not obscure knowledge... it is clearly documented in the man page and various tutorials.
Moreover, the GUI for the client is just *ugly*. It's this really bad pink colorscheme with Motif style widgets.
Umm... it uses TCL/TK IIRC.
Um...excuse me. CD-Rs don't have an aluminum layer.
[snip]
CDR work by having a laser burn a shiny substance sandwiched between two layers of plastic (Both sides are generally clear, but this is because it's cheaper to keep one type of plastic on hand.) When you burn the shiny stuff, it don't shine no mo'.
Um... no. CD-R media does have a reflective aluminum layer. What you 'burn' is a die coating that obscures the aluminum. Burn through the die, and the laser can reflect off of the aluminum behind it. The previous poster might have been thinking of CD-RW media, which uses a layer of amorphorous crystals that change their reflective properties when hit by the 'burning' laser.
You silly, silly person. I know that you're a troll, but I hate to see misinformation spread around.
http://linux.adaptec.com
I know adaptec has taken over this driver, but what kind of improvements are in this kernel?
1. Active maintainership by the vendor. The author of the previous driver is no longer maintaining it.
2. More robust. This is not meant as a sleight again Doug. This driver has more bugs fixed. That's the one of the advantages of the previous point.
3. True U160 support. The old driver only worked with some U160 configurations, and didn't support U160 transfers.
4. Shared codebase with FreeBSD. This shouldn't surprise anyone, as Justin is a FreeBSD developer. And before you get your panties in a bunch, please remember that the old driver was a port of Justin's work.
Man, I bet that Philipino script kiddie is just drooling at the thought of sending I Love You to 2^128 computers.
"I shoulda never sent a penguin out to do a daemon's work."
Nobody drives a Yugo once and then decides all cars must suck because they don't steer themselves.
These co-workers of mine weren't looking for a car that could drive itself, they were looking for a tool that could be reliably installed. Look people, the point is being missed here. It's not about how cool Linux is because you have the souce and can fix/improve/etc, it about having a tool for a job (an in, an OS to run a server on) that works. Corporate executives don't give a rats ass that thier junior sysadmin can fix a bug in Linux. They care that the bug had to be fixed in the first place, and that the person who fixed it had to use company money (i.e. his wages during the time that he worked on it) to fix it. Companies don't budget their IT department to be kernel hackers and beta testers.
"I shoulda never sent a penguin out to do a daemon's work."
Why blame the Linux kernel for bugs in Red Hat admin utilities? You did explain to these guys that Red Hat is neither the only nor the most robust GNU system distribution, right?
Yes I did. It still doesn't change the fact that the first experience with "Linux" for these people was negative. And don't forget that the corporate world by-and-large doesn't understand the whole "distribution" thing. To the CFO's and CEO's of the world, Redhat=Linux. The "distribution" model is crazy, too. It's like saying, "I'm going to buy Oracle Windows NT with the 4.0 kernel", or "I'd like a hammer with a Craftsman head and a Stanley handle". But I rant...
"I shoulda never sent a penguin out to do a daemon's work."
I can find the vast majority of my bugs by reading the code carefully, thinking about what's going on as it is being executed, and inserting a few strategically-placed "printfs"
Well, by this logic, why would you need the printf's at all? I mean, if code inspection is the best way to find bugs, then isn't resorting to printf's the second refuge of the incompetent? We all know this argument is foolish, though. Why? Because knowing intermediate values in a method saves time. Why waste time manually iterating through a loop when the computer can do it for you, right? So why shun debuggers when they can help the process out even more? Instead of placing printfs, why not set a breakpoint and examine any piece of data (in scope) that you wish? No edit-recompile is needed. It's a time saving tool, and any practical programmer should recognise that. We don't see anyone in the binutils group saying, "We're wasting out time on gdb, let's can it."
"I shoulda never sent a penguin out to do a daemon's work."
Amen!
/etc/hosts and /etc/resolv.conf because linuxconf badly mangles them, not a single person was the least bit impressed with RedHat. Sure, it had flashy and cool things, but the bugs are what left the permanent impression in thier minds. The argument of, "Well, you have the source, so go fix it!" doesn't fly for these people; thier job responsibilities do not include debugging the tools needed to do thier job. Until the Linux community can understand this and get quality and professionalism into their products, they will always be second tier.
My co-workers and I gripe about the same thing: lack of quality and discipline in Linux. Sure, it's a good OS that has many good merits, but it is seriously mared by it's flaws. Here's an example: two weeks ago I had to train a half dozen non-unix people (all from a software testing lab) in installing RedHat. After explaining how the installer in 6.2 won't partition the hard drive correctly (forcing us to install 6.1 then upgrade), then explaining how X had to be configured after installation because the configurator built into the installer doesn't treat the mouse correctly (an Intellimouse), then explaining how to edit
This is were BSD will win. It may not be as flashy, but it is quality. Each release is integrated from the start and well tested. It is written by software engineers and computer scientists with strong philosophy of quality before quantity. Many, many proposed features in each project have been axed becuase either the risk to stability is too high, or that the feature was not consistent with the whole, or that the result was poorly architected and/or buggy. Yes, there is a bit of a snobish attitude in BSD. That's because the measure of quality is higher than in Linux. The goal is not to take over the world with cool things, it's to provide a quality, dependable, coherent OS.
"I shoulda never sent a penguin out to do a daemon's work."
"I think Bush is a rotten candidate, and while I don't like Gore, I would vote for a malignant carbon rod for president before I would vote for GWB"
Amen.
A bit off topic, I know, but I had to say it.
"I shoulda never sent a penguin out to do a daemon's work."
I highly doubt that 'porting' would be an option. I imagine that Zero Copy requires some rather intimate changes in the TCP stack. Since the Linux and BSD stacks are completely different animals, a major rewrite is the only sensible thing. Besides, the GPL nature of the Linux kernel precludes incorporating BSD code into the 'official' code base.
"I shoulda never sent a penguin out to do a daemon's work."
COngrats to Ken Merry, Justin Gibbs, et al for this task. Just one more example of the quiet superiority of FreeBSD.
"I shoulda never sent a penguin out to do a daemon's work."
If I remember correctly, the word here in the Denver area is that the top people in US West will stay at the top after the merge. Oh well. Having lived many places, I can say that US West is by far the worst major telco out there.
"I shoulda never sent a penguin out to do a daemon's work."
I bought a 3 year warranty/service plan with my Palm from Best Buy. I wonder if I could return it for a new one....
"I shoulda never sent a penguin out to do a daemon's work."
I totally agree that the hardware should be fixed. Having Palm provide a "fix" that actually reduces the capability of the device is a sham in my opinion. I paid good money for 8 full megabytes and good battery life. I smell a lawsuit. Oh well if they were sold defective chips. Responsibility to the consumer starts with them; if they want to pass the pain onto the chip maker, that's their perogative.
"I shoulda never sent a penguin out to do a daemon's work."
If the BSDs had a king like Linus to resolve disputes, things would be quite a bit different now. There would be one BSD and it would probably have more marketshare than Linux.
Two things hampered the BSD marketshare:
1) The infamous lawsuit. That scared away the investors and corporations.
2) The GPL jihad. Certain loud voices in the Linux community used it to convince the geek crowd that the only thing worse than acne, the Borg, and dating was having your code 'stolen' by an evil corporation and used to nefarious ends.
So, you have the high and low ends of the mindshare market cut out of BSD.
Trust me, you don't want a core team.
Well the FreeBSD core team seems to be a heck of a lot better at settling ego disputes than the benevolent dictator model. Yes, two ego disputes ended in a split. It can be argued, though, that three BSD's is less fragmented than 40 or so Linux's.
"I shoulda never sent a penguin out to do a daemon's work."
Pretty big words for an anonymous poster
"I shoulda never sent a penguin out to do a daemon's work."
AFAIK the only performance-related problems in 2.4-test is I/O and VM related.
Um, aren't those some of the most important areas in regards to performance on any OS?
"I shoulda never sent a penguin out to do a daemon's work."
And in other news, more fixes and features were added to Free|Net|OpenBSD last night, bringing them one step closer to their next release.
"I shoulda never sent a penguin out to do a daemon's work."
I have do different questions relating to the who 'Music-Cops-On-The-Net' thing.
1. Very little mention has been made of mp3 (or any file for that matter) distribution over IRC. It certainly is easy enough to locate your favorite music on various channels. So is it trackable? If it is (it would have to be because of the peer-to-peer nature of DCC), why has IRC slipped through without being part of Lar's wrath?
2. What if I put up a file called 'Metallica - They've sold out, man.mp3' that consist of me ranting into a microphone about how Metallica has sucked since the 'Black' album. My name/IP could be snatched up by this software, right? So I get taken down by Napster, or hauled to court... what kind of recourse would I have? Heck, for even more fun, I take my rantings, but call it 'Metallica - Unforgiven.mp3'. How would that affect my legal standing?
"I shoulda never sent a penguin out to do a daemon's work."
Every day I thank my lucky stars that I found a job in sunny Colorado, rather than resigning myself to the rat-race that is Silicon Valley.
"I shoulda never sent a penguin out to do a daemon's work."