Slashdot Mirror

• Who was it that said, "99% of science fiction is crap, but 99% of everything is crap."

Theodore Sturgeon: "Sure, 90% of science fiction is crud. That's because 90% of everything is crud." This has become know as Sturgeon's Law.

Who was it that said, "99% of science fiction is crap, but 99% of everything is crap."? I think it applies here too.

That's Sturgeon's Law...

Whatever happened to a little depth in journalism? You would think that before someone would undertake writing an article like this, they might actually do a little research...!

It seems patently obvious to me that the writer has neither heard one of Eric Raymond's recent talks, nor read the essay Homesteading the Noosphere -- or at least if he did, he completely missed the part about "cultural taboos in the hacker community." As a writer myself, I'm completely put off by this shoddy, "let's get a few sound bites" type of work trying to pass itself off as print journalism: if you want to write news that way, get a job in television, where depth and research quality always play second fiddle to the terse and pithy.

Oh, and a little technical competence is probably in order too: Linux is a kernel. Library layouts are a feature of a particular distribution (although the LSB is trying to fix that) -- different distributions can do whatever they want with them without forking "Linux". If the article was supposed to be about incompatibilities among distributions, write about that... but a little checking among sysadmins would reveal how easy many of those issues are to overcome; and if there really is a compatibility problem running Legato on Debian, how about actually talking to someone from, say, either Legato or Debian about it instead of a third-party admin having a problem using it?

I'm really surprised actually; Charlie Babcock has some of the best print credentials of anyone writing for ZDNet, yet this article read like something written by a fresh journalism school graduate writing TV news in Missoula. <CONSPIRACY>It almost makes me wonder if there is an agenda of some sort in play here.</CONSPIRACY>



This is my opinion and my opinion only. Incidentally, IANAL.

Whatever happened to a little depth in journalism? You would think that before someone would undertake writing an article like this, they might actually do a little research...!

It seems patently obvious to me that the writer has neither heard one of Eric Raymond's recent talks, nor read the essay Homesteading the Noosphere -- or at least if he did, he completely missed the part about "cultural taboos in the hacker community." As a writer myself, I'm completely put off by this shoddy, "let's get a few sound bites" type of work trying to pass itself off as print journalism: if you want to write news that way, get a job in television, where depth and research quality always play second fiddle to the terse and pithy.

Oh, and a little technical competence is probably in order too: Linux is a kernel. Library layouts are a feature of a particular distribution (although the LSB is trying to fix that) -- different distributions can do whatever they want with them without forking "Linux". If the article was supposed to be about incompatibilities among distributions, write about that... but a little checking among sysadmins would reveal how easy many of those issues are to overcome; and if there really is a compatibility problem running Legato on Debian, how about actually talking to someone from, say, either Legato or Debian about it instead of a third-party admin having a problem using it?

I'm really surprised actually; Charlie Babcock has some of the best print credentials of anyone writing for ZDNet, yet this article read like something written by a fresh journalism school graduate writing TV news in Missoula. <CONSPIRACY>It almost makes me wonder if there is an agenda of some sort in play here.</CONSPIRACY>



This is my opinion and my opinion only. Incidentally, IANAL.

Here's a point-by-point dissection:

Microsoft Corp. is contemplating giving Windows CE to some developers for free.

The keyword is "some". And by developers, they mean the developers they recognize as developers. That is, friends. There is nothing wrong about doing it. Nor is there anything new about it.

Microsoft's revenue comes, instead, on development tools and maintenance contracts, sources said.

The open source OSs, Linux, *BSD, and Hurd, come with all of the development tools bundled. You can get them from the same sources that you got the OS and all of the applications from. If you have the program, you can get the source and the tools to compile it. Every user is a potential developer, or more to the point, every potential developer can become an actual developer for the cost of downloading and installing the tools.

For now, developers say, Microsoft isn't contemplating going so far as to turn Windows CE into an open-source project, which would allow developers to make changes to the source code and share their work with Microsoft and others in the development community.

So they are not creating any potential developers.

Why now? Microsoft is considering the move to stave off competitive embedded Linux products.

The bottom line is that Linux is more portable. For embedded systems, having a portable OS means that your code can outlive the hardware it originally ran on. Oh wait, that is true of any kind of code. It also means that your choice of hardware is not limited by the OS as much. I'd say that constitutes substantial pressure.

Now, why could this help them anyway? Is there anyone inside Microsoft or out who believes that the open source community is Microsoft's friend? Okay, there are many people in open source who also use Microsoft products and are happy with them. But alienating the open source community is not exactly something Microsoft loses sleep over. This gesture doesn't mean much, but the people it is meant to impress are people who have heard the words "Linux" and "Open Source" only in connection with business news about the Redhat and VA Linux IPOs. They haven't read The Cathedral and the Bazaar and they don't know what makes open source work.

The fact that they included this bit of information is a sure sign that this is a hoax.

At least I was instantly reminded of another product that accelerates the growth of plants:

http://www.tuxedo .org/~esr/jargon/html/entry/SNAFU-principle.html

Coincidence?

Cheers,
-j.

On slashdot, it's quite obvious that the standard dictionary doesn't apply. Try the New Hackers' Dictionary (The jargon file, eh?):

troll v.,n.

2. An individual who chronically trolls in sense 1; regularly posts specious arguments, flames or personal attacks to a newsgroup,
discussion list, or in email for no other purpose than to annoy someone or disrupt a discussion. Trolls are recognizable by the fact that the have no real
interest in learning about the topic at hand - they simply want to utter flame bait. Like the ugly creatures they are named after, they exhibit no
redeeming characteristics, and as such, they are recognized as a lower form of life on the net, as in, "Oh, ignore him, he's just a troll."

Ya just gotta use the right tool for the job.

HAND.

-Ed

What he probably meant is OSI-approved. ESR is the chairman of the OSI, but they don't always agree with him; he thinks the ASPL should be approved, but it isn't.

The real question here is, I think, "How do you run a successful open-source software project." The answer is that running a successful open-source project isn't much different than running a sucessful closed-source project. From a programming & leadership standpoint, there isn't really much difference between the two.

Actually I think there is a lot of difference. In an OSS project you cannot force anyone to do anything, and it would be very hard to lead a project without doing a lot of coding yourself.

You must stay polite at all times, and make sure to acknowledge everyone's contribution. After all the developers aren't getting paid to code.

In my experience the best programmers on any team are not motivated by money or the threat of losing their jobs. The portrait of a hacker from the Jargon File is very accurate in describing what motivates good programmers. Let's face it, any halfway talented code-jockey can quit his job and get one paying the same (or more) quite easily; this has been the case for several years at least, and probably will remain so in the forseable future. If you don't keep your hacker happy, she'll walk, regardless of what you're paying her. If you have to hold a gun to your programmer's heads to get work out of them, you need to take a serious look at your corporate culture.

I've been programming professionally for nearly 12 years, and have worked on a lot of different projects in that time. Without exception, the projects that had an opressive enviornment worked slave-driver hours, and produced crappy, bug-ridden, ugly software. The projects that produced good results were the teams that fostered a fun working enviornment. In my experience at least, productivity and quality of work are directly proportionate to team morale.
"The axiom 'An honest man has nothing to fear from the police'

The real question here is, I think, "How do you run a successful open-source software project." The answer is that running a successful open-source project isn't much different than running a sucessful closed-source project. From a programming & leadership standpoint, there isn't really much difference between the two.

Actually I think there is a lot of difference. In an OSS project you cannot force anyone to do anything, and it would be very hard to lead a project without doing a lot of coding yourself.

You must stay polite at all times, and make sure to acknowledge everyone's contribution. After all the developers aren't getting paid to code.

In my experience the best programmers on any team are not motivated by money or the threat of losing their jobs. The portrait of a hacker from the Jargon File is very accurate in describing what motivates good programmers. Let's face it, any halfway talented code-jockey can quit his job and get one paying the same (or more) quite easily; this has been the case for several years at least, and probably will remain so in the forseable future. If you don't keep your hacker happy, she'll walk, regardless of what you're paying her. If you have to hold a gun to your programmer's heads to get work out of them, you need to take a serious look at your corporate culture.

I've been programming professionally for nearly 12 years, and have worked on a lot of different projects in that time. Without exception, the projects that had an opressive enviornment worked slave-driver hours, and produced crappy, bug-ridden, ugly software. The projects that produced good results were the teams that fostered a fun working enviornment. In my experience at least, productivity and quality of work are directly proportionate to team morale.
"The axiom 'An honest man has nothing to fear from the police'

OTOH, you gotta give props to RMS for his work founding the FSF and his contributions to it. How far along would be be w/o GCC?

Of course, GNU/Linux is a stretch -- I've never heard someone say they use Adobe/MacOS or Lotus-OS/2...

Now, what is the FSF model of making money from writing documentation?

Consider this: Many companies (I don't think I need to name Red Hat here) pay people to write code that's to be released under the GPL. It doesn't seem too unreasonable to me to assume that they would pay people to write the free documentation (under the FDL) the same way that they pay people to write free software. It's rather complementary, IMO.

Something else: What about documentation that's been languishing for several revisions of the software? If this license becomes widely used (which I suspect it will, eventually, because of the reputation of RMS), then it would be no problem to just hire somebody to modify the documentation, much the same way as, say, ESR became the maintainer of popclient. (In fact, you wouldn't need any permission; ESR sought this from popclient's previous maintainer out of tact.) This could also simplify matters for the LDP if they decide to standardize on this license (much as they standardize on the file formats they accept).

You give the documentation away, and you make money by...? By what? Support of the documentation? That is, you get paid for adapting, modifying, and or re-writing the documentation? I don't think this works.

However, I don't know how this will fare up against other free-documentation licenses, such as the OPL. I guess we'll have to wait and see.

--

Now, what is the FSF model of making money from writing documentation?

Consider this: Many companies (I don't think I need to name Red Hat here) pay people to write code that's to be released under the GPL. It doesn't seem too unreasonable to me to assume that they would pay people to write the free documentation (under the FDL) the same way that they pay people to write free software. It's rather complementary, IMO.

Something else: What about documentation that's been languishing for several revisions of the software? If this license becomes widely used (which I suspect it will, eventually, because of the reputation of RMS), then it would be no problem to just hire somebody to modify the documentation, much the same way as, say, ESR became the maintainer of popclient. (In fact, you wouldn't need any permission; ESR sought this from popclient's previous maintainer out of tact.) This could also simplify matters for the LDP if they decide to standardize on this license (much as they standardize on the file formats they accept).

You give the documentation away, and you make money by...? By what? Support of the documentation? That is, you get paid for adapting, modifying, and or re-writing the documentation? I don't think this works.

However, I don't know how this will fare up against other free-documentation licenses, such as the OPL. I guess we'll have to wait and see.

--

I have a question for you:
You seem to assume (old-world) that it's capitalism vs. socialism. I believe that OSS and the Net in general defies that simplicity. I also make a (pretty) decent living. I'm getting married in August and will have a wife and (eventually) family to support. I'm no great fan of a money-centric society, but I have to live in it. Like you, I have responsiblities.
I find the word "normal" to be very dangerous. It's the kind of emotive word most people use to mean "people like me" - I dread a world of NORMAL PEOPLE.
This is the C21st. A new order comes. It's not capitalism, socialism, nor nettism. It's just different. People incl. RMS, ESR and others have failed, so far, to define it. But I like it and I use it because it works for me. If "Modern Society" is M$, then Modern Society is not for me. If the future lies in OSS, I'm with it.

So in summary, you accuse me of being a naive Marxist. I'm neither. I want the best for my customers, who include Major financials, Mils (unfortunately), and .COMs. I believe that for me, and for certain customer requirements, OSS is the current best answer. Where it's valid, I say so. Where it's not, the same.
Balance is the key.
(This is getting somewhat off-topic from the original message posted here, but seems to be on-topic for the discussion sparked by this article.)
This response isn't perfect, but I'd like a response so I can talk to you...
Steve.

If you need one overseeing brain to create a GUI, then you need a communistic state to build an OS which is more dificult on all standards...

I am typing this message right now in Linux (at work!), an OS that was built/created/born from the open source world, where there can be no one "overseeing brain". But in your world this can not exist.

To really understand this subject try reading The Cathedral and the Bazaar br Eric S. Raymond. He has explained how open source works better than any of us here can.

P.S. And the goal is not to build a GUI half as good as Windows, nor is it to have just one choice of GUIs. The goal is to build something better, in ordr to give you naysayers no reason to doubt your choice of Linux as an OS.

Though actually I got the term from a Stewart Brand book on the MIT Media Lab. The idea is that as a speaker goes beyond his actual research and begins talking to try to sway people and overreaching himself, he begins waving his hands and talking louder and going "Obviously this is the next paradigm for interface design!" and all that rot. Handwaving is when you can't back it up with real data, real benefits or real examples. It's empty argument, best done with Lots Of Big Words, best kept as general as possible so nobody can call you on factual errors. You gloss over implementation and realities and try to build the biggest concept you can without quite defining it, really. David Gelernter is the best handwaver I have ever seen in my life, and I will never forget his book "Mirror Worlds". However, about the only useful idea I found in it was an idea that generalises to being able to keep an eye on say, 307200 processes at a glance by colorcoding them and assigning each a pixel on a 640x480 display. This, of course, assumes you're only watching for 'danger signs' like a red pixel in a sea of dim green, or that you are looking for physical relationships like a cluster of a particular color that should be more diffuse and scattered (i.e. if the values need to be varied, you could spot a localised area of solid color as it built up).

Even here, the book handwaved off in a useless direction, suggesting physical levers _lifting_ the colored dot up out of the field of background values, and totally failing to come up with applications. Such applications might be watching a display of users with red signifying a request for assistance and the red increasing with time-on-hold, or for the localised area case it might be the modelling of a polyglot city's acts of violence, in which you would be monitoring gang violence by seeing if there was a pattern to the acts committed in a given geographical area. If a particular type of act became very localised, you would know that you had a gang laying claim to an area, and could see the area visually, with the outskirts represented by a diffuse area of the color.

Gelernter didn't even bother coming up with decent examples like that. He was too busy handwaving to think of the implications of any of the ideas he put out there, and the final chapter of his book was a fairly artistic parable that served as the complete and total disclaimer of any consequences deriving from his work.

I didn't like his book.

boxen

you're welcome.

I've written a project (20,000 lines of Delphi code) that's been pretty well received; and I can tell you that if your company's product, whatever it is, is something I end up using under an open license, I would love to submit bugfixes and such, time permitting. Thus one potential big benefit of open-sourcing a project: more robust code.

No guarantees of course. The product would have to appeal to developers (not just your ordinary users) somehow, because they're the ones who would want to "scratch an itch" and have the wherewithal (sp?) to do so.

Your company should also have a system, an infrastructure in place, so that the eventual code contributions result in some positive feedback to the contributors. I.e., you should treat your code contributors as part of a "community", whatever that means.

As to the question "how to make sure the contributions get back to the company" for inclusion in future releases, the answer IMHO would be: gratify the ego of your contributors. The section on code forks in The Cathedral and the Bazar is also good reading.

In fact, all of The Cathedral and the Bazaar is recommended reading for your bosses. Good luck.

The Magic Cauldron is also available on the web: http://www.tuxedo.org/~esr/w ritings/magic-cauldron/

The Magic Cauldron is also available on the web: http://www.tuxedo.org/~esr/w ritings/magic-cauldron/

Just a clarification: It may be difficult to *require* that improvements be sent back to you, but most open source licences are designed to ensure that you can have source access to derivative works.

As to the hows, whys, dos & don'ts: Read ESR's stuff

http://www.tuxedo.org/~esr/writ ings/cathedral-bazaar/

Jeff

With all that talk about Arkanoid toward the end there, I have to ask: has anyone else seen a 3D version? I got a crippled (limited to first four levels) version of a Mac game called (I think) "Diamonds 3D" in the shareware bundle that came on a hard drive I bought a while ago. It's basically an expansion of the Arkanoid concept to three dimensions, and it's good enough that I'll probably buy the full version if I ever get around to it.

The three-dimensionalization is done in basically the same way as the various 3D Tetrises that I've seen (3Tris, Block-Out, etc.): you are looking straight down (or forward, or up, if you prefer, but "Remember, the enemy gate is always down.") into a rectangular space, with bricks in various formations that you need to break by hitting them with the ball. At the top is your (conveniently transparent) paddle, which tracks your mouse. You drop the ball down, it bounces around, hits bricks, and comes back up at you, and you need to hit it. The ball's speed and angle are controlled by how fast the paddle is moving when you hit it, and if you were moving too fast, it becomes a blur that you have no hope of catching the next time. When you miss it, it escapes with a sort of neat broken-glass effect, apparently meant to indicate that it shot through your screen. There are various special things, e.g, special diamond bricks that can only be broken after all the normal ones are gone, and different color bricks that can only be broken after you've hit a switch to turn your ball the same color.

By the way, wasn't it a bit weird to describe Arkanoid (as if anyone worthy of reading Slashdot, let alone listening to GiS, would not remember it) with "It's like 'Breakout'."? I remember Breakout as one of the audio-tape-loaded games on the 16K Commodore Pet that used those weird PETSCII graphics and had no physics whatsoever, so the ball would only move at 45-degree angles and could only hit odd- or even-numbered bricks on the respective parity lives. It just seems that that is a bit more obscure than Arkanoid, and therefore doesn't help much as an explanation. Or is "Breakout" also the name of some more recent and/or popular game that I should know of?


David Gould

1. Chips don't have a near-zero replication cost
   • With software, 99+% of the cost lies in the development and documentation of a software package. Distribution is virutally free, and the economies of scale are pretty ideal. This is not the case in hardware, especially on high-end chips; Many of these chips cost $50-$150 each to fabricate, when die size, yield, package, etc. are factored in. So the development costs for leading edge technology is an extremely small chunk of the overall cost of the chip.

   • Compare this to software, where the bandwidth cost of transmitting a new linux kernel tarball or the presseing cost of a distro CD is pennies or less, and that's a very significant difference. The lack of a significant replication cost is a key reason free software works; there's no real monetary risk involved in distributing CD's.

2. Chip design is not terribly modular
   • Yes, you can seperate the areas of a chip out into different boxes and define interfaces, etc., but even the best writting verilog is still fairly spaghetti-like. There are global signals that run everywhere, small changes can affect timing in many, many different areas, and it generally takes a pretty good knowledge of an entire chip to be able to make modifications without breaking things

   • Contrast this with (well-designed) software, in which there are generally interfaces and black boxes. In a free software project, I can usually go in and make edits relatively easily; the assumption that changing the internals of a black box without changing an interface won't break anything generally holds true. This is an important point that makes improvement by the masses feasible.

     In every verilog or vhdl-based project on which I've worked, a small group of coordinated, very closely communicating engineers was critical to ending up with a good design.

3. Circuit design has a much steeper learning curve
   • To create a good VLSI project, you need to have quite a bit of training/experience under your belt. It's relatively easy to start programming and gradually learn what works and what doesn't. As a result, the pool of available programming talent dwarfs the pool of available circuit design talent.

4. Revisions are expensive

   • Referring back to ESR's C&B, releasing often is critical to the success of a free software project. Hardware doesn't afford that luxury, especially chip design. You can see the results in simulation, and possibly in some sort of FPGA emulation rapidly, but the end results are on VERY long term cycles. Software allows you to incorporate changes and include them in the end release product in minutes. Chip revisions cost thousands and thousands of dollars for new mask sets, which make frequent revisions pretty much impossibly for even the big corporations, much less the little guy.

5. Moore's law hurts
   • There are two major spectrums to address here.

   • For high end chips (Your Athlons, Coppermines, Alphas, etc.), the design deadline is absolutely critical. The luxury of "Being done when it's done" that is a central tenant of free software development doesn't work in chip design. There's a window of opportunity for a fabrication process that you have to hit, otherwise you'll either miss the process completely, or you'll be slower and more expensive than someone that did hit it. And what makes free software really cool is that it's often higher quality than the closed equivalents.

     The other major area of chip design is embedded processor design. Here the argument is very similar, but performance/cost is king. Competing here is even harder, because the demand curve for these kinds of devices is so nearly horizontal that any cost increase really hurts.

6. Product lifetimes are generally short
   • This is related to the Moore's law point. Look at the linux kernel. It has been under active development for upwards of 10 years now, and it's just in the last year started to make a significant dent in the marketplace. With a hardware cycle, you typically have to scrap what you have at the moment every few years and start over, just to take advantage of the improving fabrication processes.

   Free software is not a panacea for all processes in the world. There are very few, if any, solutions that are universal. On the other hand, I may eat my words later as problems have a way of being solved in unexpected ways. There are no intractable problems in the points I've listed, but there may be better solutions to the overal problem than open source.

   Finally, a quick disclaimer. I work for a company that does MIPS-based chip design. So take everything I say with a grain of salt. :)

Come on, people. Do you really think a group like this is going to decide (almost) overnight to do something like this just because some Linux developers won an award from some Linux site?[1] Decisions like this are argued, debated, and voted upon, not made on a lark.

I think we may have to come up with a new strain of Amiga Persecution Complex. We could call it "Slashdot Persecution Complex." The tendency of Slashdot readers to assume that anything that might negatively impact Linux is the result of a vast Microsoft conspiracy. I thought we had gotten past that, now that Linux is actually succeeding on its own merits. But I guess not. *sigh*

[1] Don't give me any "This isn't just any Linux site, this is Slashdot" crap, either.

"It's a well known technology truism that all of the smart people don't work for you, and that one of the surest ways to success is to get more ideas and more work out of people outside your own fences."

Proof positive that Tim O'Reilly knows from whence he speaks. That's got to be one of the most effective and concise explanations of the philosophy behind open source development I've ever read.

S13. How can I use fetchmail with Novell GroupWise?

The Novell GroupWise IMAP server would be better named GroupFoolish; it is (according to the designer of IMAP) unusably broken. Among other things, it doesn't include a required content length in its BODY[TEXT] response. Fetchmail works around this problem, but we strongly recommend voting with your dollars for a server that isn't brain-dead. If you stick with code as shoddy as GroupWise seems to be, you will probably pay for it with other problems.

Do we need Groupwise on linux ??

S13. How can I use fetchmail with Novell GroupWise?

The Novell GroupWise IMAP server would be better named GroupFoolish; it is (according to the designer of IMAP) unusably broken. Among other things, it doesn't include a required content length in its BODY[TEXT] response. Fetchmail works around this problem, but we strongly recommend voting with your dollars for a server that isn't brain-dead. If you stick with code as shoddy as GroupWise seems to be, you will probably pay for it with other problems.

Do we need Groupwise on linux ??

Start with a four year degree course in Computer Studies ... study the fundamentals of computer hardware ... then pick the "Advanced" book for whichever language you choose, because _everyone_ knows the easy stuff.

Recognise this: "Perl makes easy things easy, and hard things possible"? Don't start with a regular expressions tome or an advanced manual, start with a friendly, accessible book that will tell you what you want to know to get you started. Learning Perl is ideal.

Your code might not pass muster with the Self-Important Pseuds (whatever happened to the real gurus who knew how to be humble?).

But hell - your script will work, and you won't be scared off by people fearing for their jobs.

Enjoy Perl - it's great!
--

wwwwwwwwwhhhhhhhhiiii iIIIIIRRRRRRRRR!!!!!!!! (rumble*rumble*rumble*BrRrRrRrRrRrRrRr...)

And the pc case (before I glued the rubber feet back on) would actually start moving towad the edge of the desk!

Rob, I know you do a lot of perl stuff; wouldn't it be great if they created a keyboard for perl hackers? The punctuation and symbol characters would be the default and you would have to use shift keys in order to type letters, rather than the other way 'round!

This makes sense because the only time you use letters is when you're calling a function, naming a function, or commenting your code. And who comments perl code anyway? And you really don't need user-def functions either. Most of the things that require calling functions in other languages are done with arcane operators in perl.

By the way guys, voice recognition is out unless you never do anything but word processing and email. Can you imagine trying to code perl with voice recognition? Unless perhaps you memorized and were able to use all the INTERCAL names for the characters :-) (spark, crunch, flatworm, half-mesh, etc.)

Those who claim to be something often aren't:

• How many dishonest salesmen haven't told you how honest they were?
• "It is better to be described as a hacker by others than to describe oneself that way." (From the hacker Jargon File entry.)

And i'm beginning to think people who really are Christians don't say so.

But bashing everyone to whom that label could be attached is like bashing...

• all *BSD users because of the Linux haters among them.
• all Linux users because of the MS haters among them.
• all competent sys-admins who check their networks with nmap because of the script kiddies who use it.

cheers,
sklein

(For the record, the day my library installs filtering software is the day they loose my services as volunteer technical coordinator.

I'm going to share an experience I had an year or two ago, when I was interviewing for a job at a local high circulation newspaper. It is illustrative of how a book like this can cause great missunderstanings.

In the course of the iterview I used the sentence "Which is something that I, as a self-respecting hacker, would never do". This was followed by a pregnant silence and "significant looks" being exchanged between by employers-to-be.

This led to a quick explanation, a frantic search for The Jargon File and, believe it or not, a short article in the "Computers" part of the paper regarding the difference between hacker and cracker. All in all, it was a Good Thing (and I got the gig, too).

I was lucky, I had a chance to "defend myself" and managed to get the point accross, but I suspect that any person describind him/herself as a hacker will face much the same reaction - and will likely face unwarranted negative reactions. I realize that the meme is widespread, but it must be fought somehow.

There is a pretty good letter and other suggestions here. Has your local newspaper received one yet ?

I'm going to share an experience I had an year or two ago, when I was interviewing for a job at a local high circulation newspaper. It is illustrative of how a book like this can cause great missunderstanings.

In the course of the iterview I used the sentence "Which is something that I, as a self-respecting hacker, would never do". This was followed by a pregnant silence and "significant looks" being exchanged between by employers-to-be.

This led to a quick explanation, a frantic search for The Jargon File and, believe it or not, a short article in the "Computers" part of the paper regarding the difference between hacker and cracker. All in all, it was a Good Thing (and I got the gig, too).

I was lucky, I had a chance to "defend myself" and managed to get the point accross, but I suspect that any person describind him/herself as a hacker will face much the same reaction - and will likely face unwarranted negative reactions. I realize that the meme is widespread, but it must be fought somehow.

There is a pretty good letter and other suggestions here. Has your local newspaper received one yet ?

.....

For those all-night hacks, pizza and microwaved burritos are big. Interestingly, though the mainstream culture has tended to think of hackers as incorrigible junk-food junkies, many have at least mildly health-foodist attitudes and are fairly discriminating about what they eat. This may be generational; anecdotal evidence suggests that the stereotype was more on the mark before the early 1980s. (Italics mine.)

Geeks' affinity for junk food is a stereotype that has its roots in reality but doesn't stretch its branches far enough to cover us all.

I think the choice of language matters less than the programmer who speaks it.

Generally if you become truly proficient in one programming language, it is not that hard to pick up another. They are all tied to machine code, and in some fundamental sense, are the same. The only attempt I've seen to make a language that is different is Intercal. Try comparing that to any other language out there, I dare you.

Try to be the best programmer you can be, and let the others argue over which ice cream flavor is best.

Pejorative name for some versions of the GNU project copyleft or General Public License (GPL), which requires that any tools or apps incorporating copylefted code must be source-distributed on the same anti-proprietary terms as GNU stuff. Thus it is alleged that the copyleft `infects' software generated with GNU tools, which may in turn infect other software that reuses any of its code. The Free Software Foundation's official position as of January 1991 is that copyright law limits the scope of the GPL to "programs textually incorporating significant amounts of GNU code", and that the `infection' is not passed on to third parties unless actual GNU source is transmitted. Nevertheless, widespread suspicion that the copyleft language is `boobytrapped' has caused many developers to avoid using GNU tools and the GPL. Changes in the language of the version 2.0 GPL did not eliminate this problem.

Pejorative name for some versions of the GNU project copyleft or General Public License (GPL), which requires that any tools or apps incorporating copylefted code must be source-distributed on the same anti-proprietary terms as GNU stuff. Thus it is alleged that the copyleft `infects' software generated with GNU tools, which may in turn infect other software that reuses any of its code. The Free Software Foundation's official position as of January 1991 is that copyright law limits the scope of the GPL to "programs textually incorporating significant amounts of GNU code", and that the `infection' is not passed on to third parties unless actual GNU source is transmitted. Nevertheless, widespread suspicion that the copyleft language is `boobytrapped' has caused many developers to avoid using GNU tools and the GPL. Changes in the language of the version 2.0 GPL did not eliminate this problem.

Pejorative name for some versions of the GNU project copyleft or General Public License (GPL), which requires that any tools or apps incorporating copylefted code must be source-distributed on the same anti-proprietary terms as GNU stuff. Thus it is alleged that the copyleft `infects' software generated with GNU tools, which may in turn infect other software that reuses any of its code. The Free Software Foundation's official position as of January 1991 is that copyright law limits the scope of the GPL to "programs textually incorporating significant amounts of GNU code", and that the `infection' is not passed on to third parties unless actual GNU source is transmitted. Nevertheless, widespread suspicion that the copyleft language is `boobytrapped' has caused many developers to avoid using GNU tools and the GPL. Changes in the language of the version 2.0 GPL did not eliminate this problem.

How come all the fuss when 4.2.0 has been out for a couple of weeks already?

Matt.

List of Jargon Resources Mirror Sites USA:

• http://www.akrotech.com/~darkstar/jargon
• http://memes.org/jargon
• http://www.journalism.wisc.edu/jargon/
• http://www.mindspring.com/~li mbert/hacking/jargon.htm
• http://www.iscvt.org/jargon/jargon.html
• http://www.babcom.com/jargon/index.html
• http://www.hackboy.com/jargon
• http://www.pulhas.org/
• http://www2.netdoor.com/~lhand
• http://avatar.deva.net/
• http://www.blee.net/jargon
• http://www.fortuneci ty.com/skyscraper/jolt/15/jargonindex.html
• http://www.jargon.8hz.com/
• http://culture.0wnz-u.org/
• http://www.houseofhack.com/jargon
• http://jollyrogers.com/jargon/
• http://handel.math.psu.edu/jargon

• http://celestrion.totalaccess.net/do cs/jargon/
• http://www.pir.net/pir/jargon/
• http://www.technozen.com/tetsuo/jargon/
• http://ude.org/jargon
• http://web.chad.org/usr/doc/jargon-file/

• http://karnak.nmc.siu.edu/jargon/

Australia:

• http://ecco.bsee.swin.edu.au/text/jargon/

• http://ecco.bsee.swin.edu.au/text/jargon

Czechoslovakia: ttp://www.instinct.org/texts/jargon-file/

Finland: http://zone.pspt.fi/jargon/

Germany:

• http://www.ude.org/jargon
• http://www.ghks.de/computer/jargon/
• http://www.math.fu-berlin.de/~rene/jargo n/
• http://hex.rz.ruhr-uni-bochum.de/jargon/
• http://www.informatik.hu-berlin.de /~bergt/jargon

Gret Britain: http://jargon.strugglers.net

Greece: http://www.hack.gr/jargon

Italy: http://beatles.cselt.stet.it/mirrors/jargon

Japan: http://www.vacia.is.tohoku.ac.jp/jargon/

Norway: http://www.pvv.ntnu.no/misc/jargon/ Poland: http://www.uci.agh.edu.pl/jargon/

Spain: http://www.undersec.com/jargon

Sweden: http://ftp.sunet.se/jargon/

U.K.:

• http://www.new.ox.ac.uk/admin/jargon/
• http://g.pet.cam.ac.uk/g/jargon/

Here's the main site: http://www.tuxedo.org/~esr/jargon/

1. Also spelled "/. effect"; what is said to have happened when a website being virtually unreachable because too many people are hitting it after the site was mentioned in an interesting article on the popular Slashdot news service. The term is quite widely used by /. readers, including variants like "That site has been slashdotted again!" 2. In a perhaps inevitable generation, the term is being used to describe any similar effect from being listed on a popular site.

• http://www.snafu.priv.at/jargon/jargon. html
• http://www.tuxedo.org/~esr/jargon/jar gon.html

Have you read ESR's latest essay The Magic
Cauldron? He looks closely at a lot of different kinds of
projects, especially ones like the one's I suppose that you are
talking about: infrastructure projects used mostly internally. I
think for a lot of such programs, open source will work. ESR doesn't
say open source is always right, but rather open source is right much
more often than people think.

Pranks are included in "hacks", at least according to the Jargon File. The canonical example would be the Cal Tech Rose Bowl Hack.

--

Pranks are included in "hacks", at least according to the Jargon File. The canonical example would be the Cal Tech Rose Bowl Hack.

--

Pranks are included in "hacks", at least according to the Jargon File. The canonical example would be the Cal Tech Rose Bowl Hack.

--

No, bypassing security is a 'crack'.

A hack *can* be bypassing security. But the term covers a lot broader range of activities than that. It certainly covers what Wankel did in my book.

In fact, seeing as a lot of cracks are probably just 5kr1pt k1ddi35 messing around, they don't qualify as hacks.

Check The Jargon File for the definition of 'hack'.

No, it's not a hack. A hack would be bypassing some sort of security. In this case there was none. Combined with the server crashes, it was much more a race than a hack.

You might want to take a look at http://www.tuxedo.org/~esr/j argon/html/entry/hack.html. Particularly sense 5.

Although, the AP article i read in the local paper was pretty funny Friday. "A trojan program, known as a daemon, ..." "The daemons arrive at the victim with a fake return address." And i thought 'daemon' was a generic name for a program in the background providing a service, not a specific term for a DDoS tool or synonym for a 'packet'...

Anyone who doesn't understand 'hack' as defined in The Jargon File please stop reading now. Thank you. This just might qualify under sense 5, being a practical joke taking advantake of shortcomings in the CNN chatserver...

-----

1. a form of socialism that abolishes private ownership