Slashdot Mirror

Here are some good places for newbies to start with Linux...

Hope this helps!

om were businesses, .org were non-profit orgs and individuals, and .net were ISPs. *sigh* The good old days 10 years ago.

Sorry, that "ideal" never existed (fortunately). You obviously don't understand the original intentions behind each of the original gTLDS.

Read the RFC. .net was intended for services necessary to the internet - things like the root servers and internic. .org was "intended as the miscellaneous TLD for organizations that didn't fit anywhere else.", not, as it is so often claimed, for non-profits.

Where did the myth of the non-profit .org come from? It has no basis in reality, as anyone who had bothered to read the standards would know.

JDE.

That's available in emacs with JDEE ("Java Development Environment for Emacs"), in Eclipse, in JEdit, and I suspect in many other editors and IDEs besides.

It comes with the JDEE.

You can help the kernel developers immensely by testing your kernel methodically and thoroughly rather than just casually trying it out.

It's also important for you to test new kernels, even stable kernels, before putting them to use on a production machine. Even if they work well for everybody else, you may be blessed to discover your very own bug.

Also realize that because Linus can issue a new kernel anytime he feels like it, there is no particular requirement that a kenel be tested before its released. It's happened a number of times that "stable" kernels have been released that have turned out to be quite broken, especially on non-x86 architectures.

So please read, enjoy, and put to good use:

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

There are other articles on web application quality and C++ programming, with more to come. So far they are all under the GNU Free Documentation License.

I am actively seeking more translations if you want to help out.

You can help the kernel developers immensely by testing your kernel methodically and thoroughly rather than just casually trying it out.

It's also important for you to test new kernels, even stable kernels, before putting them to use on a production machine. Even if they work well for everybody else, you may be blessed to discover your very own bug.

Also realize that because Linus can issue a new kernel anytime he feels like it, there is no particular requirement that a kenel be tested before its released. It's happened a number of times that "stable" kernels have been released that have turned out to be quite broken, especially on non-x86 architectures.

So please read, enjoy, and put to good use:

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

There are other articles on web application quality and C++ programming, with more to come. So far they are all under the GNU Free Documentation License.

I am actively seeking more translations if you want to help out.

You can help the kernel developers immensely by testing your kernel methodically and thoroughly rather than just casually trying it out.

It's also important for you to test new kernels, even stable kernels, before putting them to use on a production machine. Even if they work well for everybody else, you may be blessed to discover your very own bug.

Also realize that because Linus can issue a new kernel anytime he feels like it, there is no particular requirement that a kenel be tested before its released. It's happened a number of times that "stable" kernels have been released that have turned out to be quite broken, especially on non-x86 architectures.

So please read, enjoy, and put to good use:

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

There are other articles on web application quality and C++ programming, with more to come. So far they are all under the GNU Free Documentation License.

I am actively seeking more translations if you want to help out.

zsh is great in other ways, too - I for one wouldn't be without its wonderful recursive file completion.

• articles by MichaelCrawford at Kuro5hin
• GoingWare's Bag of Programming Tips (note - they cover a lot more than programming by now)
• Articles at The Linux Quality Database
• Musings on Good C++ Style - published at K5 under my old username
• Links to Tens of Thousands of Legal Music Downloads
• Writing Cross-Platform Software - Getting Started
• Freeing the Developer from OS Vendor Shackles

I write about the importance of speaking your mind, and give some tips on how I am able to write so well on this page.

• articles by MichaelCrawford at Kuro5hin
• GoingWare's Bag of Programming Tips (note - they cover a lot more than programming by now)
• Articles at The Linux Quality Database
• Musings on Good C++ Style - published at K5 under my old username
• Links to Tens of Thousands of Legal Music Downloads
• Writing Cross-Platform Software - Getting Started
• Freeing the Developer from OS Vendor Shackles

I write about the importance of speaking your mind, and give some tips on how I am able to write so well on this page.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.

You should also be aware the Linus gets to release a new kernel whenever he wants. He does this when he thinks its the right time, for reasons that don't always involve reliability. He posts a new kernel release when he feels its ready, often without testing it particularly rigorously, and it has happened quite a few times that Linus has released a new "stable" kernel that turns out to be quite broken. It is actually quite common for the stable releases of the non-86 architectures to be quite buggy.

Finally, Linus announced on linux-kernel that the reason he released the first 2.4 stable kernel (2.4.0) was because he wanted more widespread testing, not because he felt it was ready to use. I wouldn't be surprised if he does this with 2.6. Both 2.2 and 2.4 went through several releases before they were really stabilized, and 2.4 has never been as reliable as the later 2.2 versions.

That's why I ask you to read:

• Why We Should Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel

I am actively seeking further translations of these and the other articles that are at The Linux Quality Database. The articles are all under the GNU Free Documentation License so you can just grab them and translate away.

Thank you for your attention.

Here's another link to free sheet music:

http://icking-music-archive.sunsite.dk/

So far the articles are:

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

The articles are all under the GNU Free Documentation License. However, Debian has decided the GFDL is non-free according to the Debian Free Software Guidelines. I plan to change the license to one that satisfies Debian's requirements, but haven't settled on one yet.

Any non-freeness of the GFDL shouldn't prevent you including it in your distribution, the issue is that invariant sections forbid some kinds of modifications. I discuss this further in Which License for Free Documentation?

No, muLinux with fvwm95. The distribution is an amazing collection of tight packages, scripted equivalents and even hand coded assembly language replacement utilities. It really is responsive (much more so than my Pentium-133 with 80MB RAM running a minimal Redhat 9 with X (used as an X-terminal, no local wm or apps). Picking the right tools really makes all the difference.

But wait, there's more! With eclipse the EMACS work style that I use is even better than in EMACS because dabrevs (alt-/) work much better. In eclipse dabrevs are not just a textual expansion as in EMACS, rather it is context sensitive based on the jars you have in your class path as it should be in an Jave IDE.

Well, if you want that in Emacs, just install JDEE. That gives you Code Completion with a default binding of C-c C-v C-. (and, yes, you can easily change that if you want) Screenshot. Of course, now you have the option in Emacs of hitting the keys for either, depending on what you need at the moment. I know I usually use abbreviation more that code completion.

But wait, there's more! With eclipse the EMACS work style that I use is even better than in EMACS because dabrevs (alt-/) work much better. In eclipse dabrevs are not just a textual expansion as in EMACS, rather it is context sensitive based on the jars you have in your class path as it should be in an Jave IDE.

Well, if you want that in Emacs, just install JDEE. That gives you Code Completion with a default binding of C-c C-v C-. (and, yes, you can easily change that if you want) Screenshot. Of course, now you have the option in Emacs of hitting the keys for either, depending on what you need at the moment. I know I usually use abbreviation more that code completion.

I have to wonder why so much perfectly good equipment goes to waste, while people lust after new machines, so that their CPU idle time can go from 99% to 99.5%. Especially among the ./ geeks, who probably have top end machines already.

Seriously people, if you want to play a game, get a game console. If you want some REAL fun, install Linux with just a floppy drive. :-)

As a general rule, I don't believe that it is essential for people to have permission to modify all sorts of articles and books. The issues for writings are not necessarily the same as those for software. For example, I don't think you or I are obliged to give permission to modify articles like this one, which describe our actions and our views.

However, this has caused friction with the Debian community, because they feel that the fact that the GNU Free Documentation License provides for Invariant Sections and mandatory Cover Texts makes it non-free. They're working on a policy statement to this effect, and getting ready to move all the GFDL'ed documentation from main to non-free. You can find out more about that in Why You Shouldn't Use the GNU FDL.

I observed some of the debate between the Debian developers and RMS on the debian-legal list, and while there are other significant issues, the main sticking point seemed to come down to whether or not political activism had any place in technical documentation. You can imagine Stallman's position on that. I come from way before "Open Source" was ever heard of, so I personally share Stallman's position.

It's an issue for me because I have some articles which use the GFDL, so I discussed the issue at some length in Which License for Free Documentation? The followup discussion has been very helpful.

Now why is this relevant to music?

The issue of whether it is moral (from Stallman's perspective) to forbid alteration of a work I believe comes down to whether the work is primarily functional in nature, or expressive of a personal opinion. The obvious utility of software, and the ability to combine code from different packages into new programs tips the balance heavily towards the side that says one must allow software to be altered. But that's not so clear with writing, which may be either unexpressive technical documentation, or impassioned political expression.

Music is much more like writing than software. Someone who is not a musician might not see it this way, but I feel that my music is an expression of my opinion. I can well see that there is other music that could not possibly be considered that way, and so I would support Stallman's position that not only copying but modification of such music must be permitted.

However, I don't think Stallman has completely thought this through when considering music explicitly. Have a look at his piece Regarding Gnutella.

I realize there is little I can do to stop someone from cheating, but I expect that as long as I'm providing the downloads, most people will respect my wishes.

I feel it is important to maintain the proprietary copyright and proprietary licensing to my music because it is something that I feel to be a deep expression of who I am. I don't think it's the same as software at all, and in fact I do try to contribute to Free Software when I can, for example by writing about how to create better Free Software as well as by contributing to Free Software projects.

If, say, RedHat were to come out with a copylefted music download service, and lots of people started providing altered versions of my music, I would feel personally violated. It's not simply that I want to keep all the money my music might ever generate.

However, there are people who do as you request, who write, record and distribute Free-as-in-Freedom music. I have read about them online, but I'm afraid I don't know where to find any. Perhaps someone who does can post a link in response.

• Why We Should All Test the New Linux Kernel - Japanese
• Using Test Suites to Validate the Linux Kernel - Japanese

I am looking for translations into other languages for all my Linux Quality Database articles - there are other articles on web application quality and C++ programming, and more will be posted from time to time.

They are all under the GNU Free Documentation License, but for reasons explained in Which License for Free Documentation? I am planning to change the license soon to another one.

• Why We Should All Test the New Linux Kernel - Japanese
• Using Test Suites to Validate the Linux Kernel - Japanese

I am looking for translations into other languages for all my Linux Quality Database articles - there are other articles on web application quality and C++ programming, and more will be posted from time to time.

They are all under the GNU Free Documentation License, but for reasons explained in Which License for Free Documentation? I am planning to change the license soon to another one.

• Why We Should All Test the New Linux Kernel - Japanese
• Using Test Suites to Validate the Linux Kernel - Japanese

I am looking for translations into other languages for all my Linux Quality Database articles - there are other articles on web application quality and C++ programming, and more will be posted from time to time.

They are all under the GNU Free Documentation License, but for reasons explained in Which License for Free Documentation? I am planning to change the license soon to another one.

I understand that this version has a much-needed upgrade to the subliminal messaging system.

Is it RFC 1097 compliant now?

AWeb-II is Opera fast and then some, wayyyy too old (seems like no JavaScript support), and about as ugly as IBrowse. I never tried the Amiga ports of Lynx, but the gui browsers were all shareware.

No, AWeb is now free and open source (the licence is similar to the GPL I believe). I couldn't find it on Aminet, but you can download it from the website.

Also it appears to have some Javascript support (don't know how good it is though).

RFC 1924 - A Compact Representation of IPv6 Addresses

The problem of overly-long IPv6 addresses has already been, um, addressed.

You may be interested in perusing RFC 1924, "A Compact Representation of IPv6 Addresses", from April 1996.

Second, it's intended for use for single big flows on gigabit networks with long latency. You have to be pumping a few hundred megabits per second on a single TCP connection over a link with 100ms latency before it really pays off. It won't do a thing for your DSL connection. It won't do a thing for your LAN. It won't do a thing for a site with a thousand TCP connections on a gigabit pipe.

Third, unlike some previously hokey attempts to modify TCP, this one has what looks, at first glance, like sound theory behind it. There's a stability criterion for window size adjustment. That's a major step forward.

(I first addressed these issues in RFC 896 and RFC 970, back in 1984-1985. Those are the RFCs that first addressed how a TCP should behave so as not to overload the network, and what to do if it misbehaves. So I know something about this.)

Second, it's intended for use for single big flows on gigabit networks with long latency. You have to be pumping a few hundred megabits per second on a single TCP connection over a link with 100ms latency before it really pays off. It won't do a thing for your DSL connection. It won't do a thing for your LAN. It won't do a thing for a site with a thousand TCP connections on a gigabit pipe.

Third, unlike some previously hokey attempts to modify TCP, this one has what looks, at first glance, like sound theory behind it. There's a stability criterion for window size adjustment. That's a major step forward.

(I first addressed these issues in RFC 896 and RFC 970, back in 1984-1985. Those are the RFCs that first addressed how a TCP should behave so as not to overload the network, and what to do if it misbehaves. So I know something about this.)

Don't forget about the JDEE!

You can get a pre-packaged (unofficial) binary for RedHat 9 here: http://newrpms.sunsite.dk/.

Or install from source.

Or even switch distro :) (says while writing this on his RH8 box and as a packager of Wine for RH8 on sf.net).

Against my better judgement, I'll bite. You really do seem like you're trolling, but I have a few minutes to kill this morning. In fact, because I'm in such a good mood, I'll even explain why so many people are giving you flack in this thread, just in case you don't already know. Then I'll include a few reasons to consider a linux platform.

First, the flack: You're asking a robust community a very simple question to which you could easily get a plethora of answers. This is akin to asking every professor in the math department of a university what 2+2 is.

This is actually one of the more annoying characteristics of many (but not all) windows users, not to mention non-geeks in general: an overall lack of resourcefulness. You want the answers to all of life's questions handed to you. When something doesn't work, you steadfastly refuse to think beyond "I clicked here and it didn't work. I clicked here again, and it still didn't work. It must be broke!

For the record, the bullets that I'm copying and pasting from http://linux-newbie.sunsite.dk are from the first search result on a google search for "linux benefits". With that, here are a few reasons to consider a linux platform:

A modern, very stable, multi-user, multitasking environment on your inexpensive PC hardware, at no (or almost no) monetary cost for the software. Linux is a rich and powerful platform--don't think of it as a "poor people" operating system. Out-of-box Linux has as much capability as MS Windows NT with $5000 in software add-ons, is more stable, and requires less powerful hardware for comparable tasks.

Standard platform. Linux is VERY standard--it is essentially a POSIX compliant UNIX. (Yes, Linux is a best-of-the-breed UNIX. The word "UNIX" is not used in conjunction with Linux because "UNIX" is a registered trademark.) Linux includes all the UNIX standard tools and utilities.

Unsurpassed computing power, portability, and flexibility. A Linux cluster recently (April 1999) beat a Cray supercomputer in a standard benchmark. Linux is most popular on Intel-based PCs (price of the hardware), but it runs very well on numerous other hardware platforms, from toy-like to mainframes. One distribution (Debian) expresses the idea like this: "Linux, The Universal Operating System." Linux can be customized to perform almost any computing task.

Advanced graphical user interface. Linux uses a standard, network-transparent X-windowing system with a "window manager" (typically KDE or GNOME).

Dozens of excellent, free, general-interest desktop applications. This include a range of web browsers, email programs, word processors, spreadsheets, bitmap and vector graphics programs, file managers, audio players, CD writers, some games, etc.

Thousands of free applets, tools, and smaller programs. "Small is beautiful" goes well with Linux philosophy. The small Linux tools and applets often work in tandem to perform more complex tasks.

Hundreds of specialized applications built by researchers around the world (astronomy, information technology, chemistry, physics, engineering, linguistics, biology, ...). In many fields, Linux seems like "the only" operating system in existence (try to find out what your friend astronomer runs on her computer). The software in this category is typically not very easy to use, but if you want the power, it is the best software that humanity has in these areas. Doubtful? Have a look at: http://SAL.KachinaTech.COM/Z/2/index.shtml for examples.

Scores of top-of-the line commercial programs including all the big databases (e.g., Oracle, Sybase, but no Microsoft's). Many (most?) of these are offered free for developers and for personal

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.

I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.

When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.

• Why We Should All Test the New Linux Kernel
• Using Test Suites to Validate the Linux Kernel
• Use Validators and Load Generators to Test Your Web Applications
• Free Hosting Service HTML Validation Test Page
• Pointers to C++ Member Functions

Thank you for your attention.

mms is a menu system for playback of music and movies. It supports framebuffer/dxr3 and lircd/keyboard.

gzip or equivalent of the HTML

In fact gzip is already an optinal part of the HTTP/1.1 specification. So if people use this, there wouldn't be much to win from adding compression above or below this layer.

If you use bash, switching to zsh is very easy. If you are a power bash user, you might have some problems getting reoriented, but will love the power of zsh. If you use tcsh, it will take a little getting use to all the sh-like things, but the transition is not too bad, since many csh features are still available.

Another poster listed three criteria to use to pick an interactive shell. (I've used bash, but not extensively, and I haven't used tcsh for 3 or 4 years....)

• Interactive usage This is the most important to me, since this is 97% of time how I use the shell. In addition to the basics like interactive editing that both bash&tcsh have. Some of the extras in zsh I really like:
  • Completion Zsh does this much better than bash&tcsh. Zsh comes bundled with many completion functions, and they are much more through than any available for tcsh/bash. Plus they provide descriptions/help text, which no other shell can do. Bash's completion is based on a earlier version of the current zsh completion system. Zsh can run bash completions... There is a conversion script to convert tcsh completion commands to zsh.
  • Matching specs Allows for smart case-insensitive completion, abbreviations, etc. The ability to type "read{Tab}" and get "README" or type "m.1{Tab}" to get "messages.1" is really great. Tcsh has something like this if you set completion to enhanced. I'm not sure if bash has this, but I believe not...
  • Correction Zsh can correct typos during completion. Wonderful for a bad typist like myself. I don't believe bash or tcsh can do this. Tcsh has some correction code but only after hitting "Enter".
  • Great globbing In addition to the standard globbing *,?, {}, and []. Zsh has extended globbing which let's you emulate the find command within a glob pattern. The big one for me is **, which is a recursive *. So, **/file.c will find all the files named "file.c" in current directory tree. Also it has number ranges (e.g.photo<10-33>.jpg)
  • Configurability Zsh has zstyle configuration command, which while complex, does provide a lot of control.
  • Command line editing The zsh line editor can be scripted (new keyboard commands). Bash is based on readline, and provides some configuration to change which keys do which command, it doesn't provide a way to script AFAIC determine. I don't believe tcsh has this either.
• Scripting There are times you want to improve your shell experience with scripts that need to be written in the script of your shell. But for other tasks, use a portable scripting language (e.g. Bourne shell, perl, python, etc.) Though zsh is POSIX compliant, and the scripting language is as useful as bash. Zsh has my csh favorites like foreach, and variable modifiers (e.g.$file:r). Also, zsh does a great job at editing multiline commands.
• Availability This can be an issue w/zsh. Zsh is not as widely available as bash. Though most free versions of *nix like Linux and *BSD have zsh available, (though not always the latest or by default installed). I typically build from the latest CVS sources, it's almost always stable. And the process is very easy (configure/make/make install). There are many platforms where bash or tcsh

If you use bash, switching to zsh is very easy. If you are a power bash user, you might have some problems getting reoriented, but will love the power of zsh. If you use tcsh, it will take a little getting use to all the sh-like things, but the transition is not too bad, since many csh features are still available.

Another poster listed three criteria to use to pick an interactive shell. (I've used bash, but not extensively, and I haven't used tcsh for 3 or 4 years....)

• Interactive usage This is the most important to me, since this is 97% of time how I use the shell. In addition to the basics like interactive editing that both bash&tcsh have. Some of the extras in zsh I really like:
  • Completion Zsh does this much better than bash&tcsh. Zsh comes bundled with many completion functions, and they are much more through than any available for tcsh/bash. Plus they provide descriptions/help text, which no other shell can do. Bash's completion is based on a earlier version of the current zsh completion system. Zsh can run bash completions... There is a conversion script to convert tcsh completion commands to zsh.
  • Matching specs Allows for smart case-insensitive completion, abbreviations, etc. The ability to type "read{Tab}" and get "README" or type "m.1{Tab}" to get "messages.1" is really great. Tcsh has something like this if you set completion to enhanced. I'm not sure if bash has this, but I believe not...
  • Correction Zsh can correct typos during completion. Wonderful for a bad typist like myself. I don't believe bash or tcsh can do this. Tcsh has some correction code but only after hitting "Enter".
  • Great globbing In addition to the standard globbing *,?, {}, and []. Zsh has extended globbing which let's you emulate the find command within a glob pattern. The big one for me is **, which is a recursive *. So, **/file.c will find all the files named "file.c" in current directory tree. Also it has number ranges (e.g.photo<10-33>.jpg)
  • Configurability Zsh has zstyle configuration command, which while complex, does provide a lot of control.
  • Command line editing The zsh line editor can be scripted (new keyboard commands). Bash is based on readline, and provides some configuration to change which keys do which command, it doesn't provide a way to script AFAIC determine. I don't believe tcsh has this either.
• Scripting There are times you want to improve your shell experience with scripts that need to be written in the script of your shell. But for other tasks, use a portable scripting language (e.g. Bourne shell, perl, python, etc.) Though zsh is POSIX compliant, and the scripting language is as useful as bash. Zsh has my csh favorites like foreach, and variable modifiers (e.g.$file:r). Also, zsh does a great job at editing multiline commands.
• Availability This can be an issue w/zsh. Zsh is not as widely available as bash. Though most free versions of *nix like Linux and *BSD have zsh available, (though not always the latest or by default installed). I typically build from the latest CVS sources, it's almost always stable. And the process is very easy (configure/make/make install). There are many platforms where bash or tcsh

If you use bash, switching to zsh is very easy. If you are a power bash user, you might have some problems getting reoriented, but will love the power of zsh. If you use tcsh, it will take a little getting use to all the sh-like things, but the transition is not too bad, since many csh features are still available.

Another poster listed three criteria to use to pick an interactive shell. (I've used bash, but not extensively, and I haven't used tcsh for 3 or 4 years....)

• Interactive usage This is the most important to me, since this is 97% of time how I use the shell. In addition to the basics like interactive editing that both bash&tcsh have. Some of the extras in zsh I really like:
  • Completion Zsh does this much better than bash&tcsh. Zsh comes bundled with many completion functions, and they are much more through than any available for tcsh/bash. Plus they provide descriptions/help text, which no other shell can do. Bash's completion is based on a earlier version of the current zsh completion system. Zsh can run bash completions... There is a conversion script to convert tcsh completion commands to zsh.
  • Matching specs Allows for smart case-insensitive completion, abbreviations, etc. The ability to type "read{Tab}" and get "README" or type "m.1{Tab}" to get "messages.1" is really great. Tcsh has something like this if you set completion to enhanced. I'm not sure if bash has this, but I believe not...
  • Correction Zsh can correct typos during completion. Wonderful for a bad typist like myself. I don't believe bash or tcsh can do this. Tcsh has some correction code but only after hitting "Enter".
  • Great globbing In addition to the standard globbing *,?, {}, and []. Zsh has extended globbing which let's you emulate the find command within a glob pattern. The big one for me is **, which is a recursive *. So, **/file.c will find all the files named "file.c" in current directory tree. Also it has number ranges (e.g.photo<10-33>.jpg)
  • Configurability Zsh has zstyle configuration command, which while complex, does provide a lot of control.
  • Command line editing The zsh line editor can be scripted (new keyboard commands). Bash is based on readline, and provides some configuration to change which keys do which command, it doesn't provide a way to script AFAIC determine. I don't believe tcsh has this either.
• Scripting There are times you want to improve your shell experience with scripts that need to be written in the script of your shell. But for other tasks, use a portable scripting language (e.g. Bourne shell, perl, python, etc.) Though zsh is POSIX compliant, and the scripting language is as useful as bash. Zsh has my csh favorites like foreach, and variable modifiers (e.g.$file:r). Also, zsh does a great job at editing multiline commands.
• Availability This can be an issue w/zsh. Zsh is not as widely available as bash. Though most free versions of *nix like Linux and *BSD have zsh available, (though not always the latest or by default installed). I typically build from the latest CVS sources, it's almost always stable. And the process is very easy (configure/make/make install). There are many platforms where bash or tcsh

• Pointers, References and Values
• Properly Managing Memory Returned by transcode() in the Xerces XML Library (really about refactoring)
• Pointers to C++ Member Functions

i was convinced by adam spier's page and the zsh faq to give zsh a try - it was even a netbsd system that prompted it. i got sick of administering freebsd/opensbd/netbsd with different shells and i wanted to standardize on something with the features i wanted.

bash was tried first, but when i started playing with misc options like vi mode, got deeper into completion, etc i realized that bash/ksh weren't appropriate long-term choices for me. auto cd to directories, amazing completion options, typo correction, shared history, and a proper vi mode (see this for the confession from gnu's docs).

'knowing' zsh will largely translate to bash/ksh systems when you use them and zsh is not available - you'll just be reminded of their shortcomings :) the basics are largely identical.

the new unix power tools book also makes much mention of zsh.