Slashdot Mirror

You're talking about the gronk noise - its got its own entry in the jargon file.

gronk

I think it has more to do with the fact more Amiga's used Chinon floppy drives which are noisy as it is, but also most amigas don't have that sringly door flap on them - which just makes them noisier.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncovr a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

http://slashdot.org/comments.pl?sid=34159 &cid=3695 039.

Thanks for the pointer--backronym is now added to my vocabulary :).

The same reason the computing press, which should know better, spells FORTRAN Fortran, BASIC Basic, and COBOL Cobol.

I see your point for COBOL (Common Business Oriented Language), but Fortran and Basic didn't start out strictly as acronyms. Fortran is a "formula translator" (two words not five or seven); Basic is a "basic" programming language. (The "Beginner's All-purpose Symbolic Instruction Code" expansion is considered by some to be a backronym.)

One of these days, nVidia will ship a GPU whose functionality is a proper superset of that of a traditional CPU and then we can ditch the CPU entirely. Just like MMX, but backwards. This is a a recognized law of engineering. At that point, Cg will have to become a "real" compiler. Let's hope nVidia is up to the task...

1. write a little test
2. think a little about the design of the code that the test implies
3. write code until the test passes
4. look again at the design and notice what is wrong with it
5. refactor until your design is good

Defenestration, as defined by the jargon file:

...
5. The act of completely removing Micro$oft Windows from a PC in favor of a better OS (typically Linux).

Perhaps you mean: Imminent Death Of The Net Predicted!

One of these days, nVidia will ship a GPU whose functionality is a proper superset of that of a traditional CPU and then we can ditch the CPU entirely. Just like MMX, but backwards. This is a a recognized law of engineering. At that point, Cg will have to become a "real" compiler. Let's hope nVidia is up to the task...

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The filure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BS had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

With insecure X permissions, you can use xwd to dump images from a remote xserver. With a short script you can also grab remote keypresses and events for logging.

It reminds me about OS (Output Spy, not Operating System) from many, many years ago. Here's an OS and JEDGAR story from the Jargon File:

This story says a lot about the ITS ethos.

On the ITS system there was a program that allowed you to see what was being printed on someone else's terminal. It spied on the other guy's output by examining the insides of the monitor system. The output spy program was called OS. Throughout the rest of the computer science world (and at IBM too) OS means `operating system', but among old-time ITS hackers it almost always meant `output spy'.

OS could work because ITS purposely had very little in the way of `protection' that prevented one user from trespassing on another's areas. Fair is fair, however. There was another program that would automatically notify you if anyone started to spy on your output. It worked in exactly the same way, by looking at the insides of the operating system to see if anyone else was looking at the insides that had to do with your output. This `counterspy' program was called JEDGAR (a six-letterism pronounced as two syllables: /jed'gr/), in honor of the former head of the FBI.

But there's more. JEDGAR would ask the user for `license to kill'. If the user said yes, then JEDGAR would actually gun the job of the luser who was spying. Unfortunately, people found that this made life too violent, especially when tourists learned about it. One of the systems hackers solved the problem by replacing JEDGAR with another program that only pretended to do its job. It took a long time to do this, because every copy of JEDGAR had to be patched. To this day no one knows how many people never figured out that JEDGAR had been defanged.

Interestingly, there is still a security module named JEDGAR alive as of late 1994 -- in the Unisys MCP for large systems. It is unknown to us whether the name is tribute or independent invention.

With insecure X permissions, you can use xwd to dump images from a remote xserver. With a short script you can also grab remote keypresses and events for logging.

It reminds me about OS (Output Spy, not Operating System) from many, many years ago. Here's an OS and JEDGAR story from the Jargon File:

This story says a lot about the ITS ethos.

On the ITS system there was a program that allowed you to see what was being printed on someone else's terminal. It spied on the other guy's output by examining the insides of the monitor system. The output spy program was called OS. Throughout the rest of the computer science world (and at IBM too) OS means `operating system', but among old-time ITS hackers it almost always meant `output spy'.

OS could work because ITS purposely had very little in the way of `protection' that prevented one user from trespassing on another's areas. Fair is fair, however. There was another program that would automatically notify you if anyone started to spy on your output. It worked in exactly the same way, by looking at the insides of the operating system to see if anyone else was looking at the insides that had to do with your output. This `counterspy' program was called JEDGAR (a six-letterism pronounced as two syllables: /jed'gr/), in honor of the former head of the FBI.

But there's more. JEDGAR would ask the user for `license to kill'. If the user said yes, then JEDGAR would actually gun the job of the luser who was spying. Unfortunately, people found that this made life too violent, especially when tourists learned about it. One of the systems hackers solved the problem by replacing JEDGAR with another program that only pretended to do its job. It took a long time to do this, because every copy of JEDGAR had to be patched. To this day no one knows how many people never figured out that JEDGAR had been defanged.

Interestingly, there is still a security module named JEDGAR alive as of late 1994 -- in the Unisys MCP for large systems. It is unknown to us whether the name is tribute or independent invention.

Consulting The Jargon File entries for
bogosity and micro-Lenat,
we see that the uLenat is the everyday unit of bogosity,
and that it is named for Doug Lenat, whose project Cyc is.

I tend to agree with Reid, myself.

ob book: For a literary treatment of a connectionist machine
that may or may not resemble Cyc,
see Richard Powers _Galatea_2.2_

Consulting The Jargon File entries for
bogosity and micro-Lenat,
we see that the uLenat is the everyday unit of bogosity,
and that it is named for Doug Lenat, whose project Cyc is.

I tend to agree with Reid, myself.

ob book: For a literary treatment of a connectionist machine
that may or may not resemble Cyc,
see Richard Powers _Galatea_2.2_

According to the Jargon File, "the agreed-upon unit of bogosity is the micro-lenat." I wonder where Cyc would rate on the bogometer?

Micro$oft today announced the introduction of I#, a port of the intercal programming language. Said chief architect Bill Gates "The syntax of Intercal forms a perfect synergy with the way Micro$oft apps are designed. I predict that I# will overtake C# in being the most important development language in the World"

If you haven't read it before, I recommend you check out Eric Raymond's The Case of the Quake Cheats. You don't need source to come up with the kinds of cheats you're describing. Remember the story of how the bnetd people reverse engineered blizzard.net. They weren't trying to cheat, but people can and will go to these same lengths for cheating.

Open source security assumes that the people working together want access to each other, but want to keep others out.

I program every day with the assumption that I want to grant users only a limited set of permissions and nothing else and that abrupt and awkward program termination even in some acceptable cases is better than accidentally allowing unexpected actions. Open source gave me this mentality, and I use it on the job. Open source has produced some highly secure systems (such as OpenBSD). Knowledge of algorithms does not imply ability to defeat them, nor does lack of knowledge imply increased security.

From the Jargon File:

UN*X n.

Used to refer to the Unix operating system ... in writing, but avoiding the need for the ugly (TM) typography. ... Ironically, lawyers now say that the requirement for the trademark postfix has no legal force, but the asterisk usage is entrenched anyhow. It has been suggested that there may be a psychological connection to practice in certain religions (especially Judaism) in which the name of the deity is never written out in full, e.g., `YHWH' or `G-d' is used.

Source: http://www.tuxedo.org/~esr/jargon/html/entry/UNX.h tml

Bastard Operator from Hell

look here

I think God thinks like a hacker, according to ESR's definition..."No problem should have to be solved twice."

I mean, if you were creating a million species of beetle, which would you rather do - handcode the DNA of each one, or implement an algorithm that does the work for you.?

Oh, I'm unimpressed.

For some reason geeks have a bad habit of criticizing everything. It goes with the culture. See definition 4 of this entry in the jargon file for more information.

My favorite example of this is: whenever I explain *anything* that I've done to a coworker, the first thing they always say is "Why don't you just..."

Yes, that's just the way geeks are. I'm waiting for Katz to pick up on this!

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

I was hoping to see this!

This is the corporate Linux community's response to the recent paradigm shift from new software development --> increased security.

If "Unbreakable Linux" can get 'there' first, Microsoft is going to remain behind Linux in terms of security.

By 'there', I mean achieving a state where the OS is inherently *very* secure.

"Unbreakable"? Not really. But hey, it's marketing spin, and the Linux community is entitled to do some too. Hell, isn't that what we have this guy for?

The companies have the potential for a proprietary extension into the Linux environment (GPL/LGPL) to a degree not seen. How do I say this?

• RedHat is the provider of the Linux OS and has the ability to ship anything that they want with it, including proprietary packaging if they wanted to. This is contrary to the philosophies of the non-profit distrobutions like Debain and Gentoo among others.
• Dell controls the hardware source that goes into these machines, allowing the focus to concentrate on one product line and de-focus on everything else
• Oracle is a highly proprietary 800-pound gorrilla that already has interests in keeping in that way.

It's a great way to maximize the profits of the three corporations at the expense of the guy paying the bills at the other end. It starts with the support. If certain improvements are made to the system and are held under Oracle, then they are shipped as binaries and un-reviewable by the rest of the community.

There is some great potential here for one of the greatest supporters of the Linux OS to start edging themselves somwhere between the OS developers and OS movement and the proprietary foothold that forces payment

I don't know that RedHat is entirely like this, but I've heard comments from more and more people that they are becoming increasingly aggressive in their financial tactics to dictate payment schedules. What worries me about this is that Oracle is the next closest thing to Microsoft in their aggressive and morally questionable business practices.

Personally, I believe that the philosophy of Open Source, as outlines originally by ESR is more valuable socially and therefore economically than the stock option performance of these three companies and as such, this ideology needs to be preserved in the face of such movements. Not that they are bad, they are part of the migration process. But it is imparative that these migrations keep moving things forward in a constructive direction rather than becoming some instrument of code oppression that allow companies to exercise baseless claims (legally and advertising) and practice FUD tactics.

This could have two edges to the blade. Linux is recognized as a real enterprise level solution and can start being accepted into the Corporate IT fray, or only two companies can provide Linux (IBM and RedHat) and everything else belongs to the terrorists, crackers, child molesters, and dead-beat dads.

Yes, and I routinely do.

Build your own house?

It might take me awhile, especially since I would have a lot to learn, but Yes.

Hell, can you cook your own food?

Yes, and I often do. I point out in particular, that while I am not an expert at "house building" as you would put it, I would be willing to learn. All too often, people just want their hand held, and I don't mean a Palm Pilot. They want to be coddled and told how to do things. I can appreciate that maybe not everyone has the time to learn the ins and outs of computers. But not caring? Then why are they using a computer? If it's important enough that they NEED to use it, then it seems to me that it's important enough that they should learn something about it. Trying to get free technical support out of people whose time is already constrained will net you no new friends.

Don't just take my word for it, see what other people have to say about asking for help in a stupid way.

What did we expect, that the Mongolian Hordes technique actually works, or that Brooke's Law is purely theoretical? Lean really is mean, especially for the RAD category that a lot of open source falls into.

Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it. In fact, everyone who downloads, compiles and runs the source is testing the code to some extent.

In any case, I think you'll find tacit agreement that on most software projects (especially once the sales guys panic and start telling you what the customers actually want, halfway through development) that creationism is indeed a false ideal, and that it's a few dedicated (obsesses/fanatical/insomniac) individuals that do the vast bulk of the actual code development, while unseen teams break the ground in terms of hardware, requirement capturing and high level design, and clean up squads follow on to fix and maintain the stable versions. There's a lot of scope to be an unsung hero in development; I recently caught a bunch of minor memory leaks in a piece of software that had already been written, reviewed, fixed, and reviewed twice more (i.e. we're still catching bugs on the sixth iteration). And yet, because it's a single file controlled by one developer, it looks like only one person really ever worked on it.

Frankly, I think that for every developer who leaves his fingerprints on the code, there's room for at least three unseen backup guys and gals who do nothing but pave the way, clean up afterwards, and interdict management before they can distract the one productive guy. You just can't let management know that's actually the way it works, because it looks - on paper - like an inefficient process. That's quite apart from the testers, the technical writers, the people who do small parts of any GUI, the IT guys who keep the machines and servers running, the sales, marketing and customer support people who tell you varying shades of truth, and even the receptionist fielding calls for you. Even commercial enterprises don't tend to count these people; my current team has nine developers, but there at least another two dozen non-technical people who we absolutely rely on who aren't counted as part of our team. Open source seems to be similar, only with fewer people, and with even some technical people (like testers and casual bug fixers) not being captured in the team size statistics.

What did we expect, that the Mongolian Hordes technique actually works, or that Brooke's Law is purely theoretical? Lean really is mean, especially for the RAD category that a lot of open source falls into.

Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it. In fact, everyone who downloads, compiles and runs the source is testing the code to some extent.

In any case, I think you'll find tacit agreement that on most software projects (especially once the sales guys panic and start telling you what the customers actually want, halfway through development) that creationism is indeed a false ideal, and that it's a few dedicated (obsesses/fanatical/insomniac) individuals that do the vast bulk of the actual code development, while unseen teams break the ground in terms of hardware, requirement capturing and high level design, and clean up squads follow on to fix and maintain the stable versions. There's a lot of scope to be an unsung hero in development; I recently caught a bunch of minor memory leaks in a piece of software that had already been written, reviewed, fixed, and reviewed twice more (i.e. we're still catching bugs on the sixth iteration). And yet, because it's a single file controlled by one developer, it looks like only one person really ever worked on it.

Frankly, I think that for every developer who leaves his fingerprints on the code, there's room for at least three unseen backup guys and gals who do nothing but pave the way, clean up afterwards, and interdict management before they can distract the one productive guy. You just can't let management know that's actually the way it works, because it looks - on paper - like an inefficient process. That's quite apart from the testers, the technical writers, the people who do small parts of any GUI, the IT guys who keep the machines and servers running, the sales, marketing and customer support people who tell you varying shades of truth, and even the receptionist fielding calls for you. Even commercial enterprises don't tend to count these people; my current team has nine developers, but there at least another two dozen non-technical people who we absolutely rely on who aren't counted as part of our team. Open source seems to be similar, only with fewer people, and with even some technical people (like testers and casual bug fixers) not being captured in the team size statistics.

What did we expect, that the Mongolian Hordes technique actually works, or that Brooke's Law is purely theoretical? Lean really is mean, especially for the RAD category that a lot of open source falls into.

Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it. In fact, everyone who downloads, compiles and runs the source is testing the code to some extent.

In any case, I think you'll find tacit agreement that on most software projects (especially once the sales guys panic and start telling you what the customers actually want, halfway through development) that creationism is indeed a false ideal, and that it's a few dedicated (obsesses/fanatical/insomniac) individuals that do the vast bulk of the actual code development, while unseen teams break the ground in terms of hardware, requirement capturing and high level design, and clean up squads follow on to fix and maintain the stable versions. There's a lot of scope to be an unsung hero in development; I recently caught a bunch of minor memory leaks in a piece of software that had already been written, reviewed, fixed, and reviewed twice more (i.e. we're still catching bugs on the sixth iteration). And yet, because it's a single file controlled by one developer, it looks like only one person really ever worked on it.

Frankly, I think that for every developer who leaves his fingerprints on the code, there's room for at least three unseen backup guys and gals who do nothing but pave the way, clean up afterwards, and interdict management before they can distract the one productive guy. You just can't let management know that's actually the way it works, because it looks - on paper - like an inefficient process. That's quite apart from the testers, the technical writers, the people who do small parts of any GUI, the IT guys who keep the machines and servers running, the sales, marketing and customer support people who tell you varying shades of truth, and even the receptionist fielding calls for you. Even commercial enterprises don't tend to count these people; my current team has nine developers, but there at least another two dozen non-technical people who we absolutely rely on who aren't counted as part of our team. Open source seems to be similar, only with fewer people, and with even some technical people (like testers and casual bug fixers) not being captured in the team size statistics.

This is what Steved means.

-- james
ps I am not trolling! I'm being serious

Nice bit of flamebait there. When I see something like this, the first thing I do is try to find out who is posting this kind of thing; there is certaintly something going on here which is causing you get get your panties bunched up. Don't feel bad about it; I posted the same kind of junk when I was new to the world of open source. We do things different here than what you may be used to. This may be a rude awakening; it certaintly was for me nine years ago.

OK, I went to your web site. I see you run a commercial porn site; the fact that you don't use your real name earns no respect from me, but I understand why you may wish to stay anonymous. Keep in mind that OSS people generally do not respect people who use anonymous identities unless they have good reason to do so. I am Sam Trenholme, for what it is worth, and you can find out a lot about me with a simple Google search.

I am sure that you are probably used to having the right to yell and being very discourteous when, say, your web site goes down. As well as you should have. However, acting like that with OSS developers can very quickly result in a flame war. It probably won't give you want you want; people will eventually killfile or ban you if you continue to behave like that.

Let me make one thing clear: No one is asking you to make your website compatible with Mozilla, per se. One thing that is very important in OSS is that standards are supported. OSS people who write code which does not respect the standards are put to task for their decisions. It's not like the bad proprietary world of software where IE (and Netscape, before) deliberately breaks the standards and all of the webmasters march to that drum.

What we believe in is having how, say, a web broweser renders web pages, be well documented, and that good programs follow those documents. For example, the AWK programming language has a POSIX standard which describes how an AWK interpreter should behave. When GAWK added some features which were not part of the standard, they got some heat for this. While the consensus was that the GAWK developers have a right to add features like there, there was some concern that this was a non-standard addition.

Likewise, we feel that it is important that there should be standards which web browsers follow which allow webmasters to write a single page which will render correctly on all standards-complient web browsers. We're not asking you to kiss our posteriors; we are just asking that you understand how we work and think, and how much effort it is to do what we do, effort we generally do not get paid for.

if they want their product to succeed, then they need to listen to the users.

Open source is in a very difficult transition right now; we are finally getting to the point where 1.0 versions of applications for "end users" are coming out. Open source has a very long history of writing applications for computer experts; the programs have been meeting the needs of those users very nicly for quite some time now. There is going to be a lot of tension in this transition to open source applications "for the rest of us"; it is just as much a shock to the values of veteran OSS devlopers as it is a shock for end users who are used to having someone to yell at when something goes wrong.

- Sam

What We Can Learn From BSD

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureacratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

I guess, I should have pointed out the distribution that I tested this on. This is for Debian Linux. The current release of util-linux is 2.11n, but as far as I remember the -I option has been there for ever. I did check, and it seems that Debian's getty program is based on agetty; so there is a chance that there are other versions of getty that have different command line parameters.

Since you said that you have access to mgetty I can make a suggestion that might work for you (I haven't tested this myself). It seems that mgetty can take a -i option to override the /etc/issue file that is displayed before prompting for the user's id and password. If you create seperate issue files for each virtual terminal, you should be able to stick the different escape sequences into these files. This is admittedly not as elegant as the original solution, but it should achieve the same effect.

In the future, it might help if you didn't complain, but rather replied with a question asking why you had problems replicating the configuration on your system (and please tell us, which distribution you are using). Before your next post, you might want to consult the Smart Questions FAQ. Oh, and please do let us know if my suggestion for mgetty worked, or if you need additional assistance.

But I still find it inspiring he is sticking to his guns.

sPh

http://tuxedo.org/~esr/jargon/html/entry/film-at-1 1.html

They were ahead of time, again. Nowadays most processor manyfacturers announce some number of MIPS that is lots more than any practical code will ever obtain.

This has been in The Jargon Lexicon for ages. Don't all slashdotters know of it?

The spellings `nurd' and `gnurd' also used to be current at MIT, where `nurd' is reported from as far back as 1957.

So perhaps 'gnurd' is just the perfect name for a geek OS!

YHBT'd.

Everyone knows aboutBSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to void so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureacratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

So now it's hardware capacity *per dollar*? Moore's Law originally had information/silicon doubling every 12-18 months, then it was processor speed, now it has "per dollar" thrown in there. Moore wasn't just a visionary, but a scalable one at that.

Check out the Jargon File entry on this one.

This creates a self-fulfilling prophecy: you whine; we avoid you.

Ssshhhhh! Don't teach the whiny geeks how to date.

As if ESR's sex tips was not bad enough.

ESR Resigns from VA Board of Directors

--

VA Software Corp. (NASDAQ: LNUX) has silently severed
its ties with board member Eric S. Raymond, among others. No
mention of this was made on any of VA Software's OSDN news
sites.

Raymond, who was responsible for "[representing] the
interests and values of the open source community", confirms his recent change of status on his homepage.

ESR Resigns from VA Board of Directors

--

VA Software Corp. (NASDAQ: LNUX) has silently severed
its ties with board member Eric S. Raymond, among others. No
mention of this was made on any of VA Software's OSDN news
sites.

Raymond, who was responsible for "[representing] the
interests and values of the open source community", confirms his recent change of status on his homepage.

ESR Resigns from VA Board of Directors -- VA Software Corp. (NASDAQ: LNUX) has silently severed its ties with board member Eric S. Raymond, among others. No mention of this was made on any of VA Software's OSDN news sites.

Raymond, who was responsible for "[representing] the interests and values of the open source community", confirms his recent change of status on his homepage.

ESR Resigns from VA Board of Directors -- VA Software Corp. (NASDAQ: LNUX) has silently severed its ties with board member Eric S. Raymond, among others. No mention of this was made on any of VA Software's OSDN news sites.

Raymond, who was responsible for "[representing] the interests and values of the open source community", confirms his recent change of status on his homepage.

ESR's Removal from the VA Software Board of Directors!

In fact, that article on Linux Today is the only one you'll be able to find on the entire WWW.

ESR'S HOMEPAGE DOES CONFIRM THE STORY, THOUGH.

No more " [representation of] the interests and values of the open-source community [at VA Software -- owners of OSDN and Slashdot]" then, I guess!

Oh, and for further information about VA Software's demise, you may want to read this email.

Yeah, I guess this is THE question you should be asking. I am a 3rd year CS student, and the proportion in my class is 3/50. It's defenitely a Bad Thing when you step into the lab and see nothin but ugly geeks starring at their monitors. Sad, but true. I hope this changes some day...