Slashdot Mirror

Emphasis mine.

(From How to Ask Questions the Smart Way: Before you Ask)
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:

1. Try to find an answer by searching the Web.
2. Try to find an answer by reading the manual.
3. Try to find an answer by reading a FAQ.
4. Try to find an answer by inspection or experimentation.
5. Try to find an answer by asking a skilled friend.
6. If you're a programmer, try to find an answer by reading the source code.

When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time. Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.

Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying "I googled on the following phrase but didn't get anything that looked promising" is a good thing to include in e-mail or news postings requesting help.

Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.

Beware of asking the wrong question. If you ask one that is based on faulty assumptions, J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking "Stupid question...", and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.

Never assume you are entitled to an answer. You are not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question -- one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.

On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. "Would someone provide a pointer?", "What is my example missing?", and "What site should I have checked?" are more likely to get answered than "Please post the exact procedure I should use." because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.

(From How to Ask Questions the Smart Way: RTFM and STFW: How To Tell You've Seriously Screwed Up

There is an ancient and hallowed tradition: if you get a reply that reads "RTFM", the person who sent it thinks you should have Read The Fucking Manual. He or she is almost certainly right. Go read it.

RTFM has a younger relative. If you get a reply that reads "STFW", the person who sent it thinks you should have Searched The Fucking Web. He or she is almost certainly right. Go search it. (The milder version of this is when you are told "Google is your friend!")

In Web forums, you may also be told to search the forum archives. In fact, someone may even be so kind as to provide a pointer to the previous thread where this problem was solved. But do not rely on this consideration; do your archive-searching before asking.

Often, the person telling you to do a search has the manual or the web page with the information you need open, and is looking at it as he or she types. These replies mean that he thinks (a) the information you need is easy to find, and (b) you will learn more if you seek out the info

Emphasis mine.

(From How to Ask Questions the Smart Way: Before you Ask)
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:

1. Try to find an answer by searching the Web.
2. Try to find an answer by reading the manual.
3. Try to find an answer by reading a FAQ.
4. Try to find an answer by inspection or experimentation.
5. Try to find an answer by asking a skilled friend.
6. If you're a programmer, try to find an answer by reading the source code.

When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time. Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.

Use tactics like doing a Google search on the text of whatever error message you get (searching Google groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying "I googled on the following phrase but didn't get anything that looked promising" is a good thing to include in e-mail or news postings requesting help.

Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.

Beware of asking the wrong question. If you ask one that is based on faulty assumptions, J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking "Stupid question...", and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.

Never assume you are entitled to an answer. You are not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question -- one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.

On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. "Would someone provide a pointer?", "What is my example missing?", and "What site should I have checked?" are more likely to get answered than "Please post the exact procedure I should use." because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.

(From How to Ask Questions the Smart Way: RTFM and STFW: How To Tell You've Seriously Screwed Up

There is an ancient and hallowed tradition: if you get a reply that reads "RTFM", the person who sent it thinks you should have Read The Fucking Manual. He or she is almost certainly right. Go read it.

RTFM has a younger relative. If you get a reply that reads "STFW", the person who sent it thinks you should have Searched The Fucking Web. He or she is almost certainly right. Go search it. (The milder version of this is when you are told "Google is your friend!")

In Web forums, you may also be told to search the forum archives. In fact, someone may even be so kind as to provide a pointer to the previous thread where this problem was solved. But do not rely on this consideration; do your archive-searching before asking.

Often, the person telling you to do a search has the manual or the web page with the information you need open, and is looking at it as he or she types. These replies mean that he thinks (a) the information you need is easy to find, and (b) you will learn more if you seek out the info

Of course it's also more likely to fail from schroedingbugs, because it's more likely that someone actually reads the code and thus finds the bug. :-)

Translation: RMS believes in Free Software. ESR believes in Open Source.

I can't see how this is worse than what Apple did for its WebKit contributors. Except here they're mentioning that there's a prize beforehand, rather than retrospectively deciding to award one.

In fact, I can't see how this is worse than open source development in general, which in your words is "free labor in exchange for no chance at a contest prize". I'd like to refer you both to the keilinw's earlier comment about funding innovation, and Eric S. Raymond's Homesteading the Noosphere for an explanation of why people create open source software. Then remember that those reasons still apply, plus they stand a chance to benefit financially from it, and try to maintain it's a bad thing.

If you use DVD-Shrink at maximum compression, reauthor to remove most of the alternate languages, menu chrome, and other bonus features, you can sometimes squeeze a regular release DVD down to a single 1.4GB 80mm DVD-R. Sometimes not, if the movie runs a little long, but OTOH it's usually quite practical if you're only taking a single TV episode from a collection that puts several on each retail disk.

Of course, one could use a different codec besides VOB/MPEG2... but that loses compatibility with many non-computer DVD players. And, of course, many codecs are covered by patents, which adds to the costs if you want to make a retail product, and there are definite trade offs with the video quality. But if the whole problem was easy, someone would have solved it by now.

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 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://www.catb.org/jargon/html/Q/Quirk-objection. html

Allow me to introduce you to the Quirk Objection

I guess he never heard of Godwin's Law.

Yeah, but then you'd have to deal with gorilla arm. Could you imagine spending 8 hours with your arms raised and moving within the area of your monitor? Besides which, I have my doubts that this kind of method would be any more beneficial than the current setup with mice and keyboards. The reason it works so well in movies is that they use CinemaOS, where hitting the space bar repeatedly lets you zoom in to a single pixel on a digital image, all passwords are "password", and "self destruct" is a command line option. Biggest problem with CinemaOS is that by default it renders in ugly neon-green 72-point font.

What's so hard about using touch screens for the average consumer?

If you actually want to read something interesting, try The Art of Unix Programming or Forensic Discovery.

Precedent? Interesting how you immediately jumped on Firefox and didn't consider any other possible causes, of which there are many, such as spyware inserted as a layer between the system and TCP/IP.

Why didn't you tell the original poster to just try the page with Internet Explorer? I mean, their system is otherwise clean, and while I too would hesitate to get them to open a suspicious site with it, they could simply crank the security to full and be equally protected, assuming they had all their patches.

Sounds like you had a solution waiting for a problem, and this one didn't quite fit but you threw it in anyway.

To the original poster: What are the sites showing this issue? It might be that they are actually using Unicode characters that your system isn't setup to recognize. In any case, try reinstalling Firefox. If that doesn't resolve the issue, try reinstalling TCP/IP; try the easy way first, and if that doesn't fix the issue, try the harder way. Being that you're running AOL, you will probably have to reinstall that as well for both of these methods, as it sometimes uses its own drivers.

PS: You should post messages requesting help in a forum appropriate for them. Slashdot is not a good place to request support, usually (as evidenced by your 100% Off Topic moderation). Check out Experts Exchange for one such forum, though you may have to pay for the points to ask questions. You should also take a look at How to Ask Questions the Smart Way by ESR, as posting questions on the internet (esp. to volunteers) is somewhat different from calling technical support.

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.

If they're really that bad (and I CAN believe it) AND you have management support, you have a few options. For Test servers, set them up in your own department on a private lan. Do what you want with them.

Talk with some of the actual techs in IT. Find out what the problem is. It could be truly miserable managers in their department, it could be upper management pressure on IT leading to the ultimate in CYA, perhaps a CIO with a tinfoil hat collection. They might be seriously understaffed and use the paperwork as a way to eliminate frivolous requests.

Or they could just be ID10Ts.

If none of that works, resign yourself to resigning. But before you do, order 100 Signetics 25120s. Be sure to fill out the paperwork in exacting detail. If they can't seem to find them, print the datasheet for them (page 2). Insist that any other part will allow Chinese companies to sniff all your data.

Then resign, QUICKLY

Some would disagree with you that the tragedy of the commons applies in this case:

"When people reflexively apply this model to open-source cooperation, they expect it to be unstable with a short half-life. Since there's no obvious way to enforce an allocation policy for programmer time over the Internet, this model leads straight to a prediction that the commons will break up, with various bits of software being taken closed-source and a rapidly decreasing amount of work being fed back into the communal pool.

In fact, it is empirically clear that the trend is opposite to this. The trend in breadth and volume of open-source development can be measured by submissions per day at Metalab and SourceForge (the leading Linux source sites) or announcements per day at freshmeat.net (a site dedicated to advertising new software releases). Volume on both is steadily and rapidly increasing. Clearly there is some critical way in which the ``Tragedy of the Commons'' model fails to capture what is actually going on." -- Eric Raymond

You can't believe it because you (1) are making up an argument for the aim to refute it, commonly called a strawman, and (2) treat a collection of people as an individual. (Is there a fallacy name for this too?)

ad (1)
Mitnick did not say "it's easier to hack" (I assume TFA/you mean "crack" here) which would mean that it's easier to get unauthorized access.

In fact TFA quoted Mitnick as saying that finding vulnerabilities in OSS code is easier, since it's easier to analyze for holes. This is true for both black-hats and white-hats, so it gets evened out somewhat. On the other hand, finding holes in closed source is harder for black-hats, but fixing them is impossible for white-hats, so overall this might put black-hats at an advantage.

And you leave out that OSS is not just "GPL the source and put it on a server". Mature OSS projects generally are modularized well, because parallel development is greatly hampered otherwise. Closed projects tend to be much dirtier in this respect.
Incidentially, this separation also helps secure coding.

ad (2)
It should not be a surprise that among > 1,000,000 /. users, you find both people who say "duh" in the one, and others who say "Stop Fudding" in the other story.

Actually, what happens is this:
Some people say "duh", because, well, duh, but you leave out the supporting argument that while Mitnick's assertion is obviously true, TFA left out the fact that it is easier to fix also.
Other people say "FUD", because they forget that Allchin is somewhat right: putting Windows in the open now, necessarily with insufficient preparation and code cleanup, would make it more insecure. But that does not mean that it couldn't be more secure had it been constructed in the open from the beginning.

And I can't believe there are idiots who modded you +5 Insightful.

The modular intentions of Asterisk are great though there is no structure there either.

There is plenty of structure, here, and while in the past some of the lines between different concepts have been blurry, we are continually improving the definitions and coming up with yet better core structures. We're improving. Anthony even made some of these contributions, but we have rejected some of his more radical patches (mostly implementing the idea that everything, even the module loader itself, should be able to be unloaded). While we agree with modular design, there should be a limit; something has to be core, or all your product is is a module loader.

The other problem with Asterisk modules are that many of the in-tree modules carry cross dependencies that make it impossible for the core to function without them.

This isn't true. I'm not sure where he got this idea, but certainly some modules depend upon others. That should be a given, but the idea that the core depends upon a module isn't true. Perhaps we modularized something that he thought should be core?

The first experience for most Asterisk newcomers is an IRC channel where people fight for supremacy like information hungry pirates hording what they know and then sticking it to people for being so "stupid".

We cannot control how other people act in public. Certainly we have a very vibrant community, but the first experience for Asterisk newcomers is generally the mailing list, not the IRC channel. While we certainly try not to feed the trolls, anybody who has been reading Slashdot for more than a week knows that the trolls stick around. And while we might rebuke others for being cruel on IRC, we cannot control how our users interact. For one thing, we cannot monitor the IRC channel 24/7; for another thing, our work is on Asterisk, not on controlling other users.

I would defy anyone to find a vibrant open source software community that does not have people who will respond in sometimes nasty ways to people who have not yet learned to ask Smart Questions.

Submissions will generally be ignored for months then a one sentence overview will command the developer to fix minor issues and resubmit.

I'll admit that this has been a problem in the past, but we are working hard to correct it. Bugs filed are generally addressed the next day or at least within 7 days of them being posted. While there are certainly bugs that we reject, quite frequently patches go into SVN within hours of them being submitted. There are also complex patches that require more thought and careful consultation with other developers, to ensure they take the code in directions that we wish to go. These are generally the types of bugs which remain open the longest -- not because we're ignoring them, but because we are carefully considering them.

soon all the developers will be nothing but users who have no other choice but to try and be developers

It's unfortunate to hear such an elitist attitude. We all were only users once. Those of us who were interested enough learned and progressed and became developers. It's terrible that some people have forgotten this.

I could go on for ages documenting more issues but they tend to fall on deaf ears.

They actually didn't fall on deaf ears. Many of anthm's criticisms were taken quite seriously and have been addressed. It's sad to see another developer take his ball and go home, but we continue to move forward, with or without him. We aren't his keeper, and it's certainly his right to develop whatever he likes.

"Steve Jobs said that he was talking about the processors being faster...and he specifically said not everything is going to be faster like the hard drives and memory etc etc. Just the processors which is why he showed the SPECmarks or whatever this phantom benchmark that, to my knowledge, isn't a free download from anywhere. Or was I the only one that heard him prefacing the results?"

"Oh well, let the Mac bashing continue, blood is in the water."

I don't think most people are bashing Macs here, just misleading sensationalism in marketing. What he said is basically akin to my saying "Bogo-sort beats the pants off quicksort! It gets the right answer in just one iteration! Well, sure, there are cases where it's a little slower than that."

Touting the best case of something while totally ignoring the average- or worst-case is almost always going to be misleading. Sure, the best-case performance of bogo-sort is excellent (if it randomly hits the correct order on the first try), but the average case performance is pretty miserable and in the worst case it never finishes. The same goes for the new Macs. Sure, in a particular canned set of circumstances I don't doubt for a second that it's twice as fast. It sounds like in the "average case" (if there is such a thing for computer usage patterns) it's more along the lines of 20% faster (which is still pretty respectable). It strikes me that this would be a far less misleading basis to market your hardware on.

So is Steve Jobs "lying" to us? No, but the "4x Faster" logo plastered all over the macbook pro page is certainly rather misleading.

Actually, the whole article is worth reading, but that section is particularly relevant here. He goes on to say that expressing yourself "clearly and well is important. If you can't be bothered to do that, we can't be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal -- in fact, hacker culture values informal, slangy and humorous language used with precision. But it has to be precise; there has to be some indication that you're thinking and paying attention."

'Nuff said, I think.

No programming language is truly complete without "PLEASE GIVE UP" and "DO COME FROM" (you think ordinary goto's are evil? Try reverse goto...) commands.

http://www.catb.org/~esr/jargon/html/G/geek.html I cant belive no one have mentioned the Jargon files.

Magic smoke

$5 says that your escort was being ha-ha-only-serious.

feature : n.

2. [common] An intended property or behavior (as of a program). Whether it is good or not is immaterial (but if bad, it is also a misfeature).

feature : n.

2. [common] An intended property or behavior (as of a program). Whether it is good or not is immaterial (but if bad, it is also a misfeature).

Did you ever read the Halloween documents? Microsoft actually thinks Open Source is a threat! Since those documents were written, Linux has gained a boatload of ground in market share, so I'm sure the threat is even greater in their minds today.

So the manager of their Open Source lab is going to be the best guy to strategize about how to beat Open Source. Makes perfect sense.

Seems like you've got your answer from the other replies; yes python is a perfect place to start. The best reason is the interactive interperter; this is useful even after you've "learned" the language. Python is also able to help you learn coding methods, like Test Driven Development. Web, GUI, Networking, all in python, so when you're ready for those concepts, the stuff to do them is there.

Eric Raymond wrote in How to be a Hacker (http://www.catb.org/~esr/faqs/hacker-howto.html) that you should learn Python first, then Java or C/C++ depending on where you want to go. He also recommends perl, because so much of it is out there, and LISP, because it will teach you to think differently.

Eric also has some other python info on his site.

Real Men code html by hand, in a text editor.

This gets modded Informative? What crack are the mods on and please cant I not have any of it?

This gets modded Informative? Oh, the irony... it hurts.

Mods, just bogart that joint! My post (above) wasn't Informative . At best it was (dubiously) Funny . Arguably it was either Flamebait or Troll ; and it is now certainly Overrated .

See, these funny little words in the moderation menu, they all have semantic content, you know? Like, they actually mean something... Oh, never mind. As you were.

Real Men code html by hand, in a text editor.

This gets modded Informative? What crack are the mods on and please cant I not have any of it?

This gets modded Informative? Oh, the irony... it hurts.

Mods, just bogart that joint! My post (above) wasn't Informative . At best it was (dubiously) Funny . Arguably it was either Flamebait or Troll ; and it is now certainly Overrated .

See, these funny little words in the moderation menu, they all have semantic content, you know? Like, they actually mean something... Oh, never mind. As you were.

I remember! I remember! It is The Missing Matter by Thomas R. McDonough. The key plot element was that there is this rogue planet that wanders between universes. You just catch a ride on it.

Why the ISP and not the people who got the spam...

While I'm sure it's annoying and possibly inconvenient for the individual recipients to receive spam, there is relatively little economic impact (don't blather at me about the time spent cleaning inboxes...) for them. For the ISP, on the other hand, there is a huge economic impact as a result of dealing with spam. Think of all the extra bandwidth, disk space, CPU cycles, and man-hours spent just on dealing with your normal, every-day spam. Then think about what happens when spammers decide to do a spam run against your servers... Or when spammers joe-job your domain... etc. etc.

Fighting spam isn't just about keeping v1gr4 ads out of the inboxes of kids, it's about punishing the jackasses who ruin the Commons (the public Internet), and waste resources.

Working in Linux support for customers I can just give you a hint. The first step toward a successful problem solution is that the one who wants to solve the problem understands the problem. You can achieve this goal by learning How To Ask Questions The Smart Way.

Another important thing that other people want to know if they have to solve your problem is all available information about your environment. Tools like hwinfo or sysreport can be of great help to the supporter.

I for one, am at least erudite enough to know that those pesky commas go inside the quotation marks.

Not on an info-tech discussion site they don't. For example, what is the difference between the following lines?

1. Then delete a line from the file by typing "dd".
2. Then delete a line from the file by typing "dd."

I mostly use KMail at home for the same reasons. Though i use fetchmail to retrieve the mails and procmail to pipe them thru ClamAV and SpamAssassin and finally sort them with some scripts of my own.

The fact Kmail use mail dir format, as mutt, let me also check my mail from a remote ssh session.

Some people might want to have a look to AMaVIS or check SWiK about
- emails
- fetchmail
- procmail
- ClamAV
- SpamAssassin
- KMail (nothing really here)
- mutt

Paul Graham and company did a fine job on that language.

I sincerely hope you're not implying that Paul Graham (& co.) invented LISP...

I'm only 23 years old ... I think that makes Java a little more accessible to me than LISP.

Eh? I didn't know there was an age limit. "LISP: Adults Only. Contains content that is suitable only for persons aged 25 and older. Content rated by ESRB." :)
Or maybe you don't want to use any language older than you are, in which case may I recommend the Io programming language, invented in 2002?

(By the way, I'm 21, and I find languages like LISP, Smalltalk and ML fascinating.)

AOL!

When RMS came to speak here at Cal I was not too impressed. He was interesting, entertaining, but the guy seemed (this especially came out in the Q&A session at the end) like a ranting madman rather than a proper spokesman for GNU. ZD must have REALLY edited the interview's transcript to get it into the form that's been put up on the site.

I am not trying to just get points by being the odd one out here, but seriously - do you really expect the general public to accept free software let alone programmers? Given the shaky prospect of let's say...making a living, for example, I doubt it will be accepted broadly.

I agree that the FLOSS model has led to much innovation. But the story ends there - I for one, won't be spending my life without a job, contributing to free software (although I might do it as a side-hobby). The argument that one can 'modify' software or do custom jobs to make money is idiotic. Do you seriously think there is a market there? Often, people claim that (as pointed out in 'The Magic Cauldron' by ESR) over 95% of software is not for sale (so called 'custom' jobs), but it is ridiculous to expect programmers to bank on the availability of such jobs, especially because they don't get much attention. Also, how is that figure calculated? Total number of lines, discrete tasks, etc. Furthermore, most freelance work or custom applications don't pay well compared to salaried jobs.

There are strengths to OSS, as well as weaknesses. I find Linus's view of OSS much more acceptable than those of the Stallman (GNU).

I honestly don't remember any real bias against the females in our CS classes, although it probably helped that almost every one of them was extremely attractive, so they never lacked for people wanting to help. *sigh* Now Short Christy ran into troubles, but that was due to her standing about 5 foot and having the general appearance of a vapid 14-year-old at first glance. Once she got people listening, they took her seriously, but it took some work getting them to listen.

You'll hear lots of people talking about how you should use XHTML. Ignore them. You'll hear lots of people talking about how you shouldn't use XHTML. Ignore them too.

There's little practical difference between the two languages. Browser support isn't quite there for XHTML, so the chances of there being any practical benefit to you using it are small. People will say that the added strictness will help you learn, but you aren't going to notice that strictness unless you serve it in a special way or validate, and you can validate HTML 4.01 just as you can with XHTML.

A much more important distinction to be made is the difference between Strict and Transitional. Transitional includes all kinds of old-fashioned crap that you shouldn't be using. You should use Strict.

After every edit to a document, run it through a validator. The W3C has free validators that you can use. If you do it this way, you will quickly notice when you are doing something wrong.

Ignore all the buzzwords like Ajax for now. Most buzzwords are things you can learn afterwards and use to enhance what you already know; you should learn the foundations first. You need to have a good working knowledge of HTML, CSS, URIs, and HTTP. Javascript, a server-side language and SQL will come in handy later; PHP is far from ideal, but it's easiest to get hosting with it. Same goes for MySQL.

Remember that the foundation for a website is its HTML. Everything else is an optional extra. Don't write Javascript that breaks things for non-Javascript users, write good alt attribute text so that people with images unavailable can read your pages, etc.

There's a hell of a lot to learn, but don't be intimidated, because most of it's simple, and most of it you can learn piece-by-piece.

Lurk on the relevant Usenet newsgroups: comp.infosystems.www.authoring.*, comp.lang.javascript, etc. Read their FAQs. Read the specifications for things like HTML, CSS, etc - they aren't that hard to read. Use Google before asking anybody anything. Ask smart questions.

When debugging something, save it to a temporary test page, and reduce it to the smallest amount of code possible that reproduces the bug. Nine times out of ten, you will find the bug by doing this. The rest of the time, you have a testcase to show people on the newsgroups.

Learn to hate Microsoft in advance. It saves time. You will wish you could travel back in time to kill Internet Explorer's dev team before they release it. It's that bad.

de-commoditiz[ing] protocols & applications.... OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.

Nor is MS the only company to use this strategy. The record companies with their SACD and DVD-audio formats (as if 24-bit audio weren't trivial to implement! O yeah, they're charging us customers for those despised copy protection methods.). Creative uses this strategy with their high-quality Audigy SoundBlaster ZS2 cards. The internal audio pin-header is not compatible with the standard format. Thus, I cannot connect the card to my case's front-panel audio inputs/outputs. If I want easy headphone access, I have to pay extra for a huge Creative-made bay & special connector. Creative will not succeed in their efforts, I surmise, despite their persistence; they don't have a strong enough hold on the sound-card market. I wouldn't buy from them again, unless the re-commoditize this protocol. As for MS & the record companies, they may be able to shove these formats down our throats. It certainly doesn't help that the mass of Americans are ignorant of these problems. And you can bet the MPAA can't wait for HD-DVD.

Have a koan.

Good thoughts. I'd also recommend that the study leader take a good look at Eric Raymond's famous rants about open source interfaces, covered here at Slashdot some time ago and readable at http://www.catb.org/~esr/writings/taouu/html/ch05s 01.html. Eric makes a lot of good points about where open source interfaces often fail to actually be useful without reading the source code or for new users, as opposed to experts.

This is just another example of a cumbersome commercial developer chasing Free/Open Source Software developer's tail lights.

-Peter

I guess the lack of class must not extend to using slang and shorthand such as '/.' and 'n00bs' then.

How very convenient for you.

...especially for something as petty and inane to a technical discussion as prose...

"My machine won't work. Here's no relevant details. What's wrong, and how can I fix it?"

Cliff, if this is the best you could find for an Ask Slashdot, it's time to decommission the category.

The only answer this deserves is this. Why don't you read it too, Cliff?

I find it suprising nobody has mentioned The Cathedral and the Bazaar by Eric S. Raymond. Such a great book about open source and its benefits, it should be on everyones bookshelf.

The technical term is that GETs are idempotent - "acting as if only used once, even when used multiple times" (from the jargon file http://catb.org/~esr/jargon/html/I/idempotent.html - although I disagree with the comment about C header files, I've never heard the term used in connection with them...).

GETs (according to the spec) aren't supposed to change anything (significant) on the server, just retrieve information, and so are safe to bookmark, refresh, etc.

POSTs on the other hand are potentially more "dangerous", which is why your browser warns you about resubmitting them - they're designed to be used for things that cause changes, and so should only be repeated with care. Examples being submitting orders in ecommerce sites, deleting content or changing its live/visible status in a content management system, etc.

You'd be surprised how many people I come across in the web industry who don't know the difference. It's one of the interview questions I use; if you get it wrong, you're not likely to get the job (I forgive not knowing the word "idempotent" though).

I think that was intentional.

Im sure a large group of people on slashdot would also like to see Microsoft be brought down by their TrackChanges feature also.

It's already happened.

It seems, after looking at the files directly, the "Halloween" memos were started at the bottom of Microsoft's employee pool and went upwards. The document was a rant about how great Linux and the entire open source movement around the GPL was. Before they were sent to Eric Raymond there are drastic edits to the memo by a user known only as SBallmer. Somehow we got this.