Slashdot Mirror

I'd agree abiout emacs, and indeed tried to convince ESR that emacs goes against the Unix philosophy for his TAOUP book, although he wasn't having any of it.

Why not just wait for this to come out?

The Art of Unix Programming

You're right, newbies do tend to get treated somewhat harshly. But they need to ask a good question.

I wouldn't say that this would be the end of free software. Remember, there is more than one way to do this. The copycenter method, among others, comes to mind immediately.

Isn't something from the OS itself, but the "1337" attitude from the users. "Use a different distro!", "RTFM!", "l4m3r!"

I don't know where you've been looking, but I never see any of that. Not even here. And really, if you are told to RTFM, perhaps you really should have. Very few people want to provide a free helpdesk for people who can't be bothered reading the manual. Most people consider themselves to be worth more than a bit of paper.

How about, instead of asking "how to", you read the manual, and if that confuses you, ask about the bit that confuses you. If you don't know where the documentation is, ask for that. Ask questions the smart way.

Microsoft--for better or for worse--wants to open Usenet to a more mainstream audience.

As CmdrTaco noted in the original news post, Usenet is to a point that it can't really get much worse.

I can't take the credit for that, it's hacker slang. If you don't know the jargon file yet, click the Home link on that page and enjoy. There are lots of awesome and/or funny annectotes in it too, like the story of Mel.

I can't take the credit for that, it's hacker slang. If you don't know the jargon file yet, click the Home link on that page and enjoy. There are lots of awesome and/or funny annectotes in it too, like the story of Mel.

Actually, modern shorthand derives in large part from the old Morse networks, where low bandwidth constraints and high information density requirements made abbreviations not just commonplace, but necessary. This link has been noticed and documented.

I strongly reccommend that you read The Case of the Quake Cheats. It's a very good read :)

One of the key points is that very few developers are involved in developing "commercial" software. The vast majority (maybe 95% or more) do implementation and custom development for in-house projects.

If OSS were to eliminate "commercial software" completely, these jobs would still need to be filled, and since less budget would be spent on licensing, more money would be available in corporate budgets to fund custom development.

ESR -> Eric S. Raymond, the guy who is a megalo gun-nut and happens to be the president of OSI.

Let's also keep in mind that 17 is the least random number.

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 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.

BTW, this is not a good idea reinstall your system every year. Even if you have to (usually IT people in the company I work for have to reinstall many Win2k workstations every year because of weird problems).
The idea of enterprise versions of RedHat or UnitedLinux is to support a version for at least 5 years. And Debian don't use to release new versions every day.
There is a reason for it: increased support costs (for both sides).
Ok, you should care about corrections and updates, even upgrades, but in a controlled and VERY WELL TESTED way.

Maybe I want to change versions of apps or even change the distribution I use just for fun, but enterprises don't like it. They want a stable, reliable environment, not only the servers but the workstations too (even if their wishes don't come true ;). You may change a version of an application because there is a correction or a new feature you really need, but not because it's there! And do it carefully, testing it, using in a small group before releasing it. With enterprise versions or Debian this is already done before new releases are avaiable, but you should do it in the company environment.

But keep looking new "unstable" and poorly tested releases There are a lot of good stuff in those distros ;-)

There is an Eric conspiracy!

This room is fullfilled mit special electronische equippment. Fingergrabbing and pressing the cnoeppkes from the computers is allowed for die experts only! So all the "lefthanders" stay away and do not disturben the brainstorming von here working intelligencies. Otherwise you will be out thrown and kicked anderswhere! Also: please keep still and only watchen astaunished the blinkenlights.

To wit, while this may not totally *disinfect* your gear, this will most certainly decruft it.

Sometimes he writes well. CatB is good. I also really like his rebuttal to SCO, although it benefited from other contributors.

His detractors make fun of stuff like this.

I like STFW better. *g*

-uso.

And the key phrase is "Other People's Software".

His contribution to nethack is a badly written out-of-date manual and, by his own admission "blindfolds" (woop-de-doo) -- all about 10 years ago.

vc-mode for emacs, (that he calls his "biggest hack till fetchmail") is nice (I use it often) but amounts to about 5 (count 'em) shortish lisp files, and that includes many contributions from the present maintainer and others. And it was so brilliantly and artfully designed, that it contained a Y2K bug, and again was 10 years ago. (Nice engineering, Eric.)

His development on NCurses came long after the bulk of the work was done (version 1.8.1 and onwards).

He's not a bad programmer, but his gift for self-promotion far outweighs anything else he may have contributed... Except, perhaps, the unintentional laugh-fest that is Sex Tips For Geeks

But what exactly has he hacked? [ ... ] Essentially, a bunch of applets.

Interesting that you provide a link to his "software" page and yet you still claim that all he's worked on is a "bunch of applets". Wow. Way to trivialise someone's work. *roll of eyes* How long did it take you just to read through and comprehend that list of software? Note especially the stuff under the heading "Other People's Software", indicating major projects he's contributed to.

I wrote a comment a little while ago for someone else like you who seemed to enjoy trashing (or at least trying to talk down) Raymond's contributions to opensourcedom, for no easily apparent reason. Mind you, that thread was on a topic that seemed devoted to ESR-bashing... :-)

BTW, you might want to take a note of ESR's projects page as well as the more specific software page. He's produced a lot of worthwhile stuff that can't just be categorised as software.

Anyway, completely offtopic. Feel free to mod away, moderators. :-)

But what exactly has he hacked? [ ... ] Essentially, a bunch of applets.

Interesting that you provide a link to his "software" page and yet you still claim that all he's worked on is a "bunch of applets". Wow. Way to trivialise someone's work. *roll of eyes* How long did it take you just to read through and comprehend that list of software? Note especially the stuff under the heading "Other People's Software", indicating major projects he's contributed to.

I wrote a comment a little while ago for someone else like you who seemed to enjoy trashing (or at least trying to talk down) Raymond's contributions to opensourcedom, for no easily apparent reason. Mind you, that thread was on a topic that seemed devoted to ESR-bashing... :-)

BTW, you might want to take a note of ESR's projects page as well as the more specific software page. He's produced a lot of worthwhile stuff that can't just be categorised as software.

Anyway, completely offtopic. Feel free to mod away, moderators. :-)

> Larry Wall is everything that Eric Raymond
> believes himself to be.

Oh yeah, what about good in bed...

*shudder*

"senior cadre with established public reputations for excellence across the entire Unix community will be directly quoted in the body of the book."

"senior contributors must not only be the best, but be known to be the best."

"I have done the heavy lifting in the writing and research department"

but stills seems to know his place in the greater scheme of all things hacking

It's a common hackish overgeneralization. Look at the bottom of this page.

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 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.

...Also note that the info version has been phased out; it's an HTML world now.

...So one use of *TeX (book typesetting) is sort of deprecated, maybe. BTW: Latex doesn't breathe.

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 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.

Do I know more economics than Ganesh Prasad? Tough question. Is he supposed to be some sort of economics guru? The bottom line is that he failed to address how a group of developers can take OSS from a hobby into a stream of wealth one can feed oneself and one's family with.

Look at the section under "Open Source is not economically viable." He says that everyone's focusing on the supply side too much to see that demand will inevitably force suppliers into adopting OSS. The problem is that if you start selling GPL'd software, anyone can jump in. He calls this commitization, but doesn't make the connection that if anyone can distribute the software then you won't be able to make money in the long run distributing the software.

The idea of expensing software development doesn't negate the opportunity costs of the investment.

Unfortunately, software has befallen an uncorrected market failure that dominates nearly the entire business. Because the Justice Department has elected not to punish and correct Microsoft, the market for Operating Systems is through the roof, and the barrier to entry is even higher. In this situation, economic models of competition break down, as vendors who should be trying to reduce costs and diversify their product are essentially locked in.

Open source is not an viable economical model to sell software. Period. End of story. Thats not to say that open source doesn't have a home, which it clearly does. The author fails to mention a single way that OSS can survive, and instead gives us a nice rant about capilistic views of property

What are those ways? Well, I believe ESR himself has a piece discussing the various ways in which one can earn a living writing OSS. Probably one of the most long lived methods is writing software to sell hardware. ESR mentions others and you should give it a read, and maybe a simple economics textbook, available at a number of collegiate textbook retailers online.

In looking at the linked site I noticed that their port includes a "Quake 2 Radar". This is actually constitutes a new cheat. Unfortunately "Cheating" with a GPLd client game is not new nor has to be considered as an issue. Eric S. Raymond has a really nice essay about what happened the day that ID released the Quake 1 sources to the world, and what happens constantly to every damn online game out there. Anyway, someone even thinks as going far as making you voluntarily install spyware on your pc in order to "certify" that you are not an online cheater :(. (If that's the added cost, no online games for me, thankyou).

Basically the inability of the US courts to stop Microsoft from doing what they continue to do is the same as the south winning the civil war.

I invoke Colonel Sanders' Corollary to Godwin's Law!

You must now eat fried chicken 'till doomsday.

Anyone remember Core Wars?

Linux definition: On most hardware platforms, a jiffy is 10 milliseconds in duration.

In other Engineering and science diciplines there are other definitions of "jiffy".

In English, it means "a short amount of time" as in "I'll do it in a jiffy".

C is the biggest problem child. There's a whole lot of implications, but here's the most common ones:

• Endianness. If you're reading and writing ints (or anything longer than a char) from a file or network socket, use the ntohl and family to make sure the external format is always consistent. (This only applies if your external data has a chance of moving across architectures, so temp files are fine to ignore this on, but save files aren't.)
• Struct padding. The padding requirements of different architectures varies. If you are storing or sending structs, do so element by element rather than a struct at a time.
• Pointers. Don't assume that all pointers are equivilent, so don't stuff something as a char* and read it as an int*, unless you do appropriate casts.
• Pointer size. Don't store pointers in ints or vice versa. The most common problem with this is forgetting to prototype your functions.
• Chars. They may be signed on some architectures, and unsigned on others. Always use 'signed char' or 'unsigned char' if you care, or are using an external file or network socket.
• Read/write alignment. Don't expect to be able to store ints, pointers, etc. in arbitrary places. (This is rarely a problem.)
• Size of ints. Make no assumptions.

Most of these are implicitly used without the programmer realizing it, for example, by forgetting to #include prototypes, or by storing a long in an int variable.

See also the Jargon File entry for vaxocentrism.

It's also frequently easy to get access to different machines. Check with your friends (hobbyists often have old Alphas or Suns, and PPCs are becoming more common), check at work, use a build farm like Sourceforge's, etc.

• The Cathedral and the Bazaar
  
• Homesteading the Noosphere
  
• The Magic Cauldron
  

• The Cathedral and the Bazaar
  
• Homesteading the Noosphere
  
• The Magic Cauldron
  

• The Cathedral and the Bazaar
  
• Homesteading the Noosphere
  
• The Magic Cauldron
  

Just tell them to go here: The Jargon File.

I think you'll have to give them directions. I think it's past the petrol station, left at the McDonalds, just beyond the church?

hmm, funny how the original message didn't display as a link while it did when i quoted it.

well, it's all laid out for anyone with an internet connection to read! i am referring to esr's jargon file (for the lazy, the lexicon is here)

well, it's all laid out for anyone with an internet connection to read! i am referring to esr's jargon file (for the lazy, the lexicon is here)

Just tell them to go here: The Jargon File.

Just tell them to go here: The Jargon File.

Old-timer humour. You yunguns ain't been around long enough to get that. :) See Appendix A of the Jargon File for a reference.

I'm not so sure. Jobs is obsessed with making great things. If he chose to use open source software it was because he believed that with it could produce a great product. If he didn't think he could then no amount of money would have changed his decision.

You're kidding, right? The open source software community existed *well* before Jobs left Apple Computer sometime in the late mid-to-late 1980s. If Jobs thought open source was such a great idea *then* why didn't he use it in the creating of the original Macintosh?

The original Macintosh was one of the most proprietary, closed platforms that ever existed, a distinction that earned it the nickname 'beige toaster' by the open source hacker community in the 1980s. Apple patents were closely guarded, even then -- especially then.

Jobs wouldn't have *dreamed* of using open source then.

Yes, Jobs is in someways obsessed with making 'insanely great' products. But Jobs is also first and foremost a businessman and always has been. He's not a hacker, he's not an engineer. That's why he teamed up with Woz in the first place... Woz had the mad skills, but Jobs had the business vision. Don't forget that.

Eric Raymond and The Cathedral.
Now I know what it means.

At least make sure you've read smart questions FAQ

Kind of like the IETF's philosophy has been famously summarized as "We reject kings, presidents, and voting. We believe in rough consensus and running code."

And Linus to add, "I have the numbers for the current practice being BAD. You show me yours to back up YOUR claims. Until you do, you're just spouting opinions and hot air."

I like both very much. I'd love to see it when it's done, but until then it's just hot air.

Historically that's true. But reading Eric Raymond's The Art of Unix Programming I realized that at the moment the Unix family and the Windows family are the only realistic OS's left.
And pardon me for saying so, but the Unices covered in thick crusts of 30 years of sediments.
If I login to my Linux box with a shell it doesn't recognize (Interix) it asks me to specify my terminal type. WTF, why not ask me what kind of punch cards I'd like to send?
From ESR's book I understood that some people are carrying on the BeOS open-source. Which should be interesting since it was built completely anew.
Does anybody have any experience with this? Is it alive and kicking?

groeten uit Nederland,
Joost