Slashdot Mirror

Try either
MuLinux
or
PicoBSD
to get started with a minimilist distro. Pico BSD runs on a single floppy, and I think MuLinux requires at least two. Onoe advantage of MuLinux is that it can actually run X after a few more floppys. I had both of these running at one point on a Laptop w/ 8 megs of ram.

Enjoy.

The game's main site features icons for several languages. The Korean icon features the flags of both North and South Korea.

Now I know this has nothing to do with the game, but somehow the probability of this site being accessed by a North Korean RPG fan strikes me as slightly lower than the possibility of it being accessed by an Afghani teen using a Babbage's Analytical Engine built from spare AK-47 parts and pigeons.

For inmates of the People's Republic of Korea, it is probably even illegal to know there is such a thing as the Internet.

Enjoy!!!

http://mirrors.sunsite.dk/collegelinux/

On a slightly related note - can anyone recommend a tiny Linux distribution that runs off floppies? I am hoping to run an X server, icewm, PPP and ssh.

download-only policies (ie. just like HTTP)

That was also what I thought until I read section 9.6 in the HTTP/1.0 specification about the PUT method. If that method is not intended for uploading files, what is the purpose? Of course many HTTP servers does not allow you to use that method.

Did you Google?

Let your fingers do the walking...

I forgot to mention Emacs and JDEE. :-)

Setting up JDEE to get all the features can be somewhat intimidating, but worth it. You'll get features like intelligent code completition, easy lookup in the jdk or your own documentation, integration with ant (jdee can parse build.xml and provide completition on build targets etc.) etc. For modelling, I'm trying out Poseidon UML, which is, AFAIK, based on ArgoUML. (And it is a java app, so it runs on Linux, which I use on my workstation)

My article Why We Should All Test the New Linux Kernel gives some tips on how to get started building new kernels (although it emphasizes testing the development patches).

The #kernelnewbies IRC channel has a website at www.kernelnewbies.org that you will find helpful.

And finally there is of course The Linux Kernel HOWTO.

One of the most important things that you need to do to make a website accessible is to use valid markup. This is also important to allow interoperability with standards-based browsers like Opera and Mozilla.

You can ensure your site has valid markup by using a validator to check your HTML. You will find that you have an easier time writing valid markup after working with a validator for a few pages, after that you'll find very few mistakes, and they will be easy to fix. Don't let the validator's complaints about your first attempts scare you.

Maintaining server responsiveness while under heavy user load is important for basic usability for any user. You can test how your application responds to heavy traffic by testing with a load generator.

Please read:

• Use Validators and Load Generators to Test Your Web Applications

A while back I wrote a couple articles on Linux kernel testing:

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

(The articles are under the GNU Free Documentation License. I would be quite stoked if you copied or translated them. There are articles on other quality topics here.)

A while back I wrote a couple articles on Linux kernel testing:

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

(The articles are under the GNU Free Documentation License. I would be quite stoked if you copied or translated them. There are articles on other quality topics here.)

A while back I wrote a couple articles on Linux kernel testing:

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

(The articles are under the GNU Free Documentation License. I would be quite stoked if you copied or translated them. There are articles on other quality topics here.)

She can't stand Mozilla. She understands very well why she should avoid IE. But she only uses Mozilla when she absolutely has to, for example to check for interoperability after completing a web page that she wrote while using mostly using IE.

Why? Because she experiences so many bugs with it. The bugs make Mozilla unusable to her. She's not a software developer. She's a regular user of the sort that applications like this are targeting.

She understands very well that her machine can get hacked if she uses IE. But crashes and usability problems happen to her several times a day when she uses Mozilla. The risk of getting hacked seems somewhat theoretical and remote. The crashes and loss of data (for example, forum postings being composed in web forms) are frequent and completely intolerable.

Today I sent her a link to that BBC article that said you shouldn't use IE because of the security holes that are used by spyware and adware. I had observed her using IE a lot lately and wanted her to really understand why she should avoid it. Unfortunately I didn't anticipate how she would react.

She was completely distraught. I looked over at her sitting at her computer this evening and she had tears running down her face, quietly crying. The reason was that she didn't know how she was going to be able to browse the web anymore, because I had just told her in quite a loud way (using the BBC article) why she shouldn't use IE, but she also finds Mozilla completely useless.

I had put her in a bind. She didn't see a way out.

The way I consoled her and resolved the bind was to tell her to go ahead and use IE. She doesn't have much data on her drive that would be a problem if someone stole it, and if she gets hacked I'll reformat the drive and reinstall Win2k.

Meanwhile I told her I would download the new mozilla and test it for her. I was pleasantly surprised to find 1.2 released tonight - I hadn't wanted to give her a beta. So I got it downloaded before the rush.

My fear, though, is that her bugs are not fixed. There are just a few bugs that give her repeated trouble. Tonight she had a repeated crash, one time when she had sixteen windows open while researching medical journal literature, and she had hard time finding her pages again.

Talkback kept popping up and made her really upset because it made it so she couldn't just relaunch Mozilla. I knew that the talkback logs would help the developers get the bugs fixed, but if my wife was to use Mozilla at all I had to show her how to disable talkback.

I'd like to make the polite suggestion that the Mozilla developers focus somewhat less on flashy features and somewhat more strongly on stability and basic usability.

I've got lots of bugs in both reliability and usability on the Linux mozilla I use on my Mac, but I have a greater tolerance for it because I'm a developer, and I'm committed to making open source work. My wife, on the other hand, uses Mozilla because I plead with her to do so. It would be nice if Mozilla didn't make her life miserable.

I convinced her recently to make a serious try at switching from windows to Linux. That's a big step - I've been trying to do that for several years. She hasn't tried it yet because I'm going to have to spend some time configuring a system with the right setup to be able to accomplish all the tasks she wants while also being very usable and reliable. I'm going to really spend some time trying to make her transition as comfortable as possible.

While she was upset tonight she told me that the reason she said she would try Linux was to make me shut up about IE vs. Mozilla, and it hadn't worked - I kept pushing her to use open source tools, and they are unusable for her.

Bonita did file one actual bug report with bugzilla. That's the last she'll ever do, because she found the whole process extremely confusing. I think the big problem is that if you try to file a bug, and don't have a bugzilla account, after your account is created, you're presented with the expert interface and not the simplified one.

I think it would be helpful if there was a dead-simple bug report form that just had a couple lists for the platform and version, and one free-form text input field where the reporter could describe their problem. Then the person who fields the bug reports could translate this into a proper bugzilla report. Don't present people who aren't developers with the bugzilla query page - like Bonita, that will be the last report you ever get from a regular user.

It would also be very helpful if the very first page of the talkback wizard presented the option of disabling it and making it just go away. Having to click through several pages before being allowed to quit talkback is really frightening for someone who just lost all their windows and just wants to launch it again so they can find the pages that just disappeared from their screen.

Read more of what I have to say about the importance of quality in Free Software.

Unfortunately, the dot-com crash ensued just as I was getting started, and things have been a little too hectic since then for me to do much about it.

A number of people suggested I use bugzilla, and I thought a lot about it, but didn't want to use it, at least not in its current form, because it lacks a feature that I feel is critical for a bug database that is to be used to track operating system development: storage of preset machine configurations.

Perhaps the people with the new kernel bugzilla can put this in.

What I envisisioned was a way for the user to specify the hardware configuration of their machines by drawing on a database of all known hardware. (Just making that database would be a big job in itself). The user could give a name to each configuration.

Then when reporting a bug, the user would be presented with a popup menu or scrolling list of their configuration presets. There would be a way to make variations for a particular bug report, to indicate that a board had been added or removed from the stored preset.

Then the user would upload their kernel .config file.

This would allow the kernel developers to search for combinations of hardware that is or isn't installed along with kernel config options that are selected or not set.

This would help a lot to identify situations where FooBar Corp's ethernet board doesn't work when you've got a WhizzyVideo card installed.

I would also encourage people to report the configurations for successful kernel tests. That would help to build confidence as well as to identify untested areas so more attention could be paid to them.

Unfortunately, I'm just a guy working alone and although some have offerred to help, I have been working too hard just to survive to even coordinate the development of such a database.

However, I have found some time to write some articles on various aspects of Linux and web software quality and post them at the site. Writing is what I like to do to relax when I'm not programming - I write articles like these whenever I can, despite despite what the anklebiters have to say about them.

The OSDL was kind enough to mirror my two kernel testing articles and even translate them into Japanese. You can mirror or translate them if you like, as they are under the GNU Free Documentation License. I would be particularly pleased if any of my articles were translated into more languages.

The two kernel testing articles are:

• Why We Should All Test the New Linux Kernel ( Japanese translation)
• Using Test Suites to Validate the Linux Kernel ( Japanese translation)

But I found the OSDL's interest in my articles quite encouraging.

A lot of people are griping about not being able to file bugs anonymously with bugzilla. I had always intended to allow anonymous bug reports, although I would encourage users to log in so we could follow up with them.

Also some people are saying in other comments that bug reports that aren't emailed to the linux-kernel mailing lists won't be as good as the traditional ones. But I'd like to point out that linux-kernel is one of the highest traffic mailing lists around, and the discussions are extremely technical and often heated. Patches also fall on the floor all the time, as I found when someone posted a patch that fixed the problem I reported when I first subscribed.

I felt then and still feel that linux-kernel is too intimidating for the average linux user, so most will choose not to partipate in kernel QA. A bug database with a nice web interface where the reporter doesn't have to participate in the mailing list traffic can only encourage more people to post bugs. And a bug database would make it possible to log successes without overwhelming the list.

It would also be possible to publish an XML interface to the database, so people could log reports programmatically. That would help for identifying configuration information, for example you could run a program that would do what lspci does and upload it to your account at the bugbase.

Unfortunately, the dot-com crash ensued just as I was getting started, and things have been a little too hectic since then for me to do much about it.

A number of people suggested I use bugzilla, and I thought a lot about it, but didn't want to use it, at least not in its current form, because it lacks a feature that I feel is critical for a bug database that is to be used to track operating system development: storage of preset machine configurations.

Perhaps the people with the new kernel bugzilla can put this in.

What I envisisioned was a way for the user to specify the hardware configuration of their machines by drawing on a database of all known hardware. (Just making that database would be a big job in itself). The user could give a name to each configuration.

Then when reporting a bug, the user would be presented with a popup menu or scrolling list of their configuration presets. There would be a way to make variations for a particular bug report, to indicate that a board had been added or removed from the stored preset.

Then the user would upload their kernel .config file.

This would allow the kernel developers to search for combinations of hardware that is or isn't installed along with kernel config options that are selected or not set.

This would help a lot to identify situations where FooBar Corp's ethernet board doesn't work when you've got a WhizzyVideo card installed.

I would also encourage people to report the configurations for successful kernel tests. That would help to build confidence as well as to identify untested areas so more attention could be paid to them.

Unfortunately, I'm just a guy working alone and although some have offerred to help, I have been working too hard just to survive to even coordinate the development of such a database.

However, I have found some time to write some articles on various aspects of Linux and web software quality and post them at the site. Writing is what I like to do to relax when I'm not programming - I write articles like these whenever I can, despite despite what the anklebiters have to say about them.

The OSDL was kind enough to mirror my two kernel testing articles and even translate them into Japanese. You can mirror or translate them if you like, as they are under the GNU Free Documentation License. I would be particularly pleased if any of my articles were translated into more languages.

The two kernel testing articles are:

• Why We Should All Test the New Linux Kernel ( Japanese translation)
• Using Test Suites to Validate the Linux Kernel ( Japanese translation)

But I found the OSDL's interest in my articles quite encouraging.

A lot of people are griping about not being able to file bugs anonymously with bugzilla. I had always intended to allow anonymous bug reports, although I would encourage users to log in so we could follow up with them.

Also some people are saying in other comments that bug reports that aren't emailed to the linux-kernel mailing lists won't be as good as the traditional ones. But I'd like to point out that linux-kernel is one of the highest traffic mailing lists around, and the discussions are extremely technical and often heated. Patches also fall on the floor all the time, as I found when someone posted a patch that fixed the problem I reported when I first subscribed.

I felt then and still feel that linux-kernel is too intimidating for the average linux user, so most will choose not to partipate in kernel QA. A bug database with a nice web interface where the reporter doesn't have to participate in the mailing list traffic can only encourage more people to post bugs. And a bug database would make it possible to log successes without overwhelming the list.

It would also be possible to publish an XML interface to the database, so people could log reports programmatically. That would help for identifying configuration information, for example you could run a program that would do what lspci does and upload it to your account at the bugbase.

Unfortunately, the dot-com crash ensued just as I was getting started, and things have been a little too hectic since then for me to do much about it.

A number of people suggested I use bugzilla, and I thought a lot about it, but didn't want to use it, at least not in its current form, because it lacks a feature that I feel is critical for a bug database that is to be used to track operating system development: storage of preset machine configurations.

Perhaps the people with the new kernel bugzilla can put this in.

What I envisisioned was a way for the user to specify the hardware configuration of their machines by drawing on a database of all known hardware. (Just making that database would be a big job in itself). The user could give a name to each configuration.

Then when reporting a bug, the user would be presented with a popup menu or scrolling list of their configuration presets. There would be a way to make variations for a particular bug report, to indicate that a board had been added or removed from the stored preset.

Then the user would upload their kernel .config file.

This would allow the kernel developers to search for combinations of hardware that is or isn't installed along with kernel config options that are selected or not set.

This would help a lot to identify situations where FooBar Corp's ethernet board doesn't work when you've got a WhizzyVideo card installed.

I would also encourage people to report the configurations for successful kernel tests. That would help to build confidence as well as to identify untested areas so more attention could be paid to them.

Unfortunately, I'm just a guy working alone and although some have offerred to help, I have been working too hard just to survive to even coordinate the development of such a database.

However, I have found some time to write some articles on various aspects of Linux and web software quality and post them at the site. Writing is what I like to do to relax when I'm not programming - I write articles like these whenever I can, despite despite what the anklebiters have to say about them.

The OSDL was kind enough to mirror my two kernel testing articles and even translate them into Japanese. You can mirror or translate them if you like, as they are under the GNU Free Documentation License. I would be particularly pleased if any of my articles were translated into more languages.

The two kernel testing articles are:

• Why We Should All Test the New Linux Kernel ( Japanese translation)
• Using Test Suites to Validate the Linux Kernel ( Japanese translation)

But I found the OSDL's interest in my articles quite encouraging.

A lot of people are griping about not being able to file bugs anonymously with bugzilla. I had always intended to allow anonymous bug reports, although I would encourage users to log in so we could follow up with them.

Also some people are saying in other comments that bug reports that aren't emailed to the linux-kernel mailing lists won't be as good as the traditional ones. But I'd like to point out that linux-kernel is one of the highest traffic mailing lists around, and the discussions are extremely technical and often heated. Patches also fall on the floor all the time, as I found when someone posted a patch that fixed the problem I reported when I first subscribed.

I felt then and still feel that linux-kernel is too intimidating for the average linux user, so most will choose not to partipate in kernel QA. A bug database with a nice web interface where the reporter doesn't have to participate in the mailing list traffic can only encourage more people to post bugs. And a bug database would make it possible to log successes without overwhelming the list.

It would also be possible to publish an XML interface to the database, so people could log reports programmatically. That would help for identifying configuration information, for example you could run a program that would do what lspci does and upload it to your account at the bugbase.

Unfortunately, the dot-com crash ensued just as I was getting started, and things have been a little too hectic since then for me to do much about it.

A number of people suggested I use bugzilla, and I thought a lot about it, but didn't want to use it, at least not in its current form, because it lacks a feature that I feel is critical for a bug database that is to be used to track operating system development: storage of preset machine configurations.

Perhaps the people with the new kernel bugzilla can put this in.

What I envisisioned was a way for the user to specify the hardware configuration of their machines by drawing on a database of all known hardware. (Just making that database would be a big job in itself). The user could give a name to each configuration.

Then when reporting a bug, the user would be presented with a popup menu or scrolling list of their configuration presets. There would be a way to make variations for a particular bug report, to indicate that a board had been added or removed from the stored preset.

Then the user would upload their kernel .config file.

This would allow the kernel developers to search for combinations of hardware that is or isn't installed along with kernel config options that are selected or not set.

This would help a lot to identify situations where FooBar Corp's ethernet board doesn't work when you've got a WhizzyVideo card installed.

I would also encourage people to report the configurations for successful kernel tests. That would help to build confidence as well as to identify untested areas so more attention could be paid to them.

Unfortunately, I'm just a guy working alone and although some have offerred to help, I have been working too hard just to survive to even coordinate the development of such a database.

However, I have found some time to write some articles on various aspects of Linux and web software quality and post them at the site. Writing is what I like to do to relax when I'm not programming - I write articles like these whenever I can, despite despite what the anklebiters have to say about them.

The OSDL was kind enough to mirror my two kernel testing articles and even translate them into Japanese. You can mirror or translate them if you like, as they are under the GNU Free Documentation License. I would be particularly pleased if any of my articles were translated into more languages.

The two kernel testing articles are:

• Why We Should All Test the New Linux Kernel ( Japanese translation)
• Using Test Suites to Validate the Linux Kernel ( Japanese translation)

But I found the OSDL's interest in my articles quite encouraging.

A lot of people are griping about not being able to file bugs anonymously with bugzilla. I had always intended to allow anonymous bug reports, although I would encourage users to log in so we could follow up with them.

Also some people are saying in other comments that bug reports that aren't emailed to the linux-kernel mailing lists won't be as good as the traditional ones. But I'd like to point out that linux-kernel is one of the highest traffic mailing lists around, and the discussions are extremely technical and often heated. Patches also fall on the floor all the time, as I found when someone posted a patch that fixed the problem I reported when I first subscribed.

I felt then and still feel that linux-kernel is too intimidating for the average linux user, so most will choose not to partipate in kernel QA. A bug database with a nice web interface where the reporter doesn't have to participate in the mailing list traffic can only encourage more people to post bugs. And a bug database would make it possible to log successes without overwhelming the list.

It would also be possible to publish an XML interface to the database, so people could log reports programmatically. That would help for identifying configuration information, for example you could run a program that would do what lspci does and upload it to your account at the bugbase.

which is already set up to run on old hardware, has some really great configuration tools, but really outdated software (2.0.x kernel, libc5, X 3.3.1), such that I shuddered when connecting it to the internet.

Just about

have to buy a piece of software that costs hundreds of dollars to be able to produce these documents

Your kidding right? Oh, Sorry, you must be using a Windoze box. I've been using ps2pdf for years. Also, any Mac OS X application that can "Print" can produce a PDF.

where the documents get positively huge (one of our clients insists on building pdf documents instead of html/php docs because of "better graphical formatting"

First of all, your client is right. Secondly, PDF documents can be down right tiny (unless your building them "without-a-clue"). For example, I just downloaded the zsh users guide this weekend in PDF format -- about 1100 Kb for 415 pages. A fully formatted and WYSIWYG'ed document for only 2.65 Kb per page. Here it is [1110 Kb PDF File]

never mind that a single one is 700Kb who's going to sit through downloading that???)

Yes, I remember fearing those dreaded 700Kb downloads .... in 1989.

Ok, having looked into this 1991 act it does look very relevant. In this address Bush takes credit for it, but perhaps that is just politics.

This page is pretty interesting, although it contains several obvious misunderstandings (understandable in a USDA statement about computer networks in 1991). It credits Gore as well as Bush. It is kind of quaint in that it has the whole "Japan and Europe are getting ahead" attitude that was the popular wisdom in the US during the last 80's and early 90's.

For an earlier look, see RFC 1167, authored by Vint Cerf. It's extremely impressive. It's not clear that he anticipated that ordinary people would actually use and do business on the Internet, but then, extrapolating from 1990 would not have suggested it.

Uhh, it looks fine to me.. Anyway, you can find more nifty things to try out here

Wget - wget.sunsite.dk I use it almost every day.

Analog - www.analog.cx Web server log parser. An absolutely essential tool for a webmaster.

It has already been done, at least for Emacs. Have a look at the OO-Browser and JDEE, plus all that comes with GNU Emacs like:

• Version Control
• compiling and debugging
• abbreviations/completion
• ...and a dozen or so of language-specific programming modes (with syntax highlinghting, auto-indentation, etc.).

Plus, creating your own elisp code to do whatever you want (not just silly keyboard macros) is quite simple, and there are already tons of useful snippets and code examples out there. This can hardly be said for other editors, except for Vim and JEdit (which I personally consider on par with Emacs, except it requires more resources to run).

I can't speak for Vim, since I use it just occasionally, but I'm confident that it provides equivalent functionalities.

Gatech Sunsite.dk Norweigen Mirror Another Norweigen Mirror

• Validate www.softwarechoice.org
• Validate sincerechoice.com

If you'd like to know more about how to use validators to make your websites interoperable, read my article Use Validators and Load Generators to Test Your Web Applications.

Thank you for your attention.

If it was that big of a deal, you could have emailed me privately.
You don't have to be facetious.

Maybe I'm just boycotting html.

Or read this, it explains how to copy and paste.

Where's the Source?

I've read many of them over the years too. Perhaps you missed some like RFC 3271, titled "The Internet is for Everyone", or ones like 1121, a collection of poetry about the net, or 3271, a memorial to Jon Postel.

The net was created by very intelligent people. Intelligent people tend to think about lots of things, including the importance of openness, sharing of knowledge, and keeping a very human perspective on the rigors of engineering a community.

--
Evan

Australia

ftp://ftp.planetmirror.com/pub/Mandrake/8.2/i586/ (Brisbane)
Austria

ftp://ftp.univie.ac.at/systems/linux/Mandrake/8.2/ i586/ (Vienna)

ftp://gd.tuwien.ac.at/pub/linux/Mandrake/8.2/i586/ (Vienna)
Belgium

ftp://ftp.belnet.be/packages/mandrake/8.2/i586/
Costa Rica

ftp://ftp.ucr.ac.cr/pub/Unix/linux/mandrake/Mandra ke/8.2/i586/
Czech Republic

ftp://ftp.cesnet.cz/OS/Linux/Mandrake/mandrake/8.2 /i586/ (Brno)

ftp://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)

ftp://klobouk.fsv.cvut.cz/pub/linux-mandrake/Mandr ake/8.2/i586/ (Prague)

ftp://mandrake.redbox.cz/Mandrake/8.2/i586/

ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Mandrake/m andrake/8.2/i586/ (Prague)

http://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)
Denmark

ftp://ftp.dkuug.dk/pub/mandrake/8.2/i586/ (Koebenhavn)

ftp://ftp.sunsite.dk/mirrors/mandrake/8.2/i586/ (Aalborg)
Estonia

ftp://ftp.aso.ee/pub/os/Linux/distributions/mandra ke/8.2/i586/
Finland

ftp://ftp.song.fi/pub/linux/Mandrake/8.2/i586/ (Espoo)
France

ftp://ftp.ciril.fr/pub/linux/mandrake/8.2/i586/ (Nancy)

ftp://ftp.club-internet.fr/pub/unix/linux/distribu tions/Mandrake/8.2/i586/ (Paris)

ftp://ftp.info.univ-angers.fr/pub/linux/distributi ons/mandrake/8.2/i586/ (Angers)

ftp://ftp.lip6.fr/pub/linux/distributions/mandrake /8.2/i586/ (Paris)

ftp://ftp.proxad.net/pub/Distributions_Linux/Mandr ake/8.2/i586/ (Paris)

ftp://ftp.u-strasbg.fr/pub/linux/distributions/man drake/8.2/i586/ (Strasbourg)

ftp://linux.ups-tlse.fr/Mandrake/8.2/i586/ (Toulouse)
Germany

ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandra ke/8.2/i586/ (Esslingen)

ftp://ftp.de.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.fh-giessen.de/pub/linux/mandrake/8.2/i58 6/ (Giessen)

ftp://ftp.fh-wolfenbuettel.de/pub/os/linux/mandrak e/dist/8.2/i586/ (Wolfenbuettel)

ftp://ftp.gwdg.de/pub/linux/mandrake/8.2/i586/ (Goettingen)

ftp://ftp.join.uni-muenster.de/pub/linux/distribut ions/mandrake/8.2/i586/ (Muenster)

ftp://ftp.leo.org/pub/comp/os/unix/linux/Mandrake/ Mandrake/8.2/i586/ (Munchen)

ftp://ftp.tu-chemnitz.de/pub/linux/mandrake/8.2/i5 86/ (Chemnitz)

ftp://ftp.tu-clausthal.de/pub/linux/mandrake/8.2/i 586/ (Clausthal)

ftp://ftp.uasw.edu/pub/os/linux/mandrake/dist/8.2/ i586/ (Wolfenbuettel)

ftp://ftp.uni-bayreuth.de/pub/linux/Mandrake/8.2/i 586/ (bayreuth)

ftp://ftp.uni-kassel.de/pub/linux/mandrake/8.2/i58 6/ (Kassel)

ftp://ftp.uni-mannheim.de/systems/linux/mandrake/8 .2/i586/ (Mannheim)

ftp://ftp.vat.tu-dresden.de/pub/Mandrake/8.2/i586/ (Dresden)

ftp://ramses.wh2.tu-dresden.de/pub/mirrors/mandrak e/8.2/i586/ (Dresden)

ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/ mandrake/8.2/i586/ (Aachen)
Greece

ftp://ftp.duth.gr/pub/Mandrake/8.2/i586/ (Thrace)

ftp://ftp.ntua.gr/pub/linux/mandrake/8.2/i586/ (Athens)
Hong Kong

ftp://ftp.wisr.eie.polyu.edu.hk/linux/mandrake/8.2 /i586/
Hungary

ftp://ftp.linuxforum.hu/mirror/Mandrake/8.2/i586/
Ireland

ftp://ftp.esat.net/pub/linux/mandrake/8.2/i586/
Italy

ftp://bo.mirror.garr.it/mirrors/Mandrake/8.2/i586/ (Bologna)

ftp://ftp.edisontel.it/pub/Mandrake_Mirror/Mandrak e/8.2/i586/
Latvia

ftp://ftp.latnet.lv/linux/mandrake/8.2/i586/
Netherlands

ftp://ftp.nl.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.nluug.nl/pub/os/Linux/distr/Mandrake/Man drake/8.2/i586/

ftp://ftp.surfnet.nl/pub/os/Linux/distr/Mandrake/M andrake/8.2/i586/

ftp://ftp.wau.nl/pub/Mandrake/8.2/i586/ (Wageningen)
Poland

ftp://ftp.ps.pl/mirrors/mandrake/8.2/i586/ (Szczecin)

ftp://ftp.task.gda.pl/pub/linux/Mandrake/8.2/i586/ (Gdansk)
Portugal

ftp://ftp.dei.uc.pt/pub/linux/Mandrake/Mandrake/8. 2/i586/ (Coimbra)

ftp://tux.cprm.net/pub/Mandrake/8.2/i586/
Russia

ftp://ftp.chg.ru/pub/Linux/mandrake/8.2/i586/ (Chernogolovka)
Singapore

ftp://ftp.singnet.com.sg/opensource/linux/Mandrake /8.2/i586/
Slovakia

ftp://spirit.profinet.sk/mirrors/Mandrake/8.2/i586 / (Bratislava)
Spain

ftp://ftp.cesga.es/pub/linux/Mandrake/8.2/i586/ (Galicia)

ftp://ftp.cica.es/pub/Linux/Mandrake/8.2/i586/ (Sevilla)

ftp://ftp.rediris.es/pub/linux/distributions/mandr ake/8.2/i586/
Sweden

ftp://ftp.chello.se/pub/Linux/Mandrake/8.2/i586/

ftp://ftp.chl.chalmers.se/pub/Linux/distributions/ Mandrake/8.2/i586/ (Gothenburg)

ftp://ftp.du.se/pub/os/mandrake/8.2/i586/ (Dalarma)
Switzerland

ftp://ftp.pcds.ch/pub/Mandrake/8.2/i586/ (Neuhausen)

ftp://sunsite.cnlab-switch.ch/mirror/mandrake/8.2/ i586/ (Zurich)
Taiwan

ftp://linux.cdpa.nsysu.edu.tw/pub/Mandrake/mandrak e/8.2/i586/

ftp://linux.csie.nctu.edu.tw/distributions/mandrak e/Mandrake/8.2/i586/

ftp://mdk.linux.org.tw/pub/mandrake/8.2/i586/
Turkey

ftp://ftp.ankara.edu.tr/pub/linux/dagitimlar/Mandr ake/8.2/i586/ (Ankara)
United Kingdom

ftp://ftp.mirror.ac.uk/sites/sunsite.uio.no/pub/un ix/Linux/Mandrake/Mandrake/8.2/i586/ (Canterbury)
United States

ftp://ftp-linux.cc.gatech.edu/pub/linux/distributi ons/mandrake/8.2/i586/ (Georgia)

ftp://ftp.cise.ufl.edu/pub/mirrors/mandrake/Mandra ke/8.2/i586/ (Florida)

ftp://ftp.cse.buffalo.edu/pub/Linux/Mandrake/mandr ake/8.2/i586/ (NY)

ftp://ftp.nmt.edu/pub/linux/mandrake/8.2/i586/ (New Mexico)

ftp://ftp.orst.edu/pub/mandrake/8.2/i586/ (Oregon)

ftp://ftp.tux.org/pub/distributions/mandrake/8.2/i 586/ (Virginia)

ftp://ftp.umr.edu/pub/linux/mandrake/Mandrake/8.2/ i586/ (Missouri)

ftp://ftp.uwsg.indiana.edu/linux/mandrake/8.2/i586 / (Indiana)

ftp://linux-cs.tccw.wku.edu/pub/linux/distribution s/Mandrake/8.2/i586/ (WKU-Linux, Western Kentucky University)

ftp://mirror.aca.oakland.edu/linux/mandrake/8.2/i5 86/ (Michigan)

ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrak e/8.2/i586/ (Wisconsin)

ftp://mirror.mcs.anl.gov/pub/Mandrake/8.2/i586/ (Illinois)

ftp://mirrors.ptd.net/mandrake/8.2/i586/ (Pensylvania)

ftp://mirrors.secsup.org/pub/linux/mandrake/Mandra ke/8.2/i586/

ftp://uml-pub.ists.dartmouth.edu/mirrors/ftp.mandr akesoft.com/pub/Mandrake/mandrake/8.2/i586/ (New Hampshire)

ftp://videl.ics.hawaii.edu/mirrors/mandrake/Mandra ke/8.2/i586/ (Hawaii)

http://mandrake.dsi.internet2.edu/Mandrake/8.2/i58 6/ (For Internet2 academic institutions only)

• ftp://gd.tuwien.ac.at/infosys/browsers/mozilla/sou rces/
• http://gd.tuwien.ac.at/infosys/browsers/mozilla/so urces/

• ftp://mozilla.mirror.pacific.net.au/mozilla/
• http://mozilla.mirror.pacific.net.au/
• ftp://ftp.planetmirror.com.au/pub/mozilla/
• http://planetmirror.com.au/pub/mozilla/

• ftp://ftp.belnet.be/packages/mozilla/

• ftp://ftp.ntrl.net/pub/mirror/mozilla/

• ftp://sunsite.ualberta.ca/pub/Mirror/mozilla/

• ftp://sunsite.cnlab-switch.ch/mirror/mozilla/

• ftp://ftp.ibiblio.org/pub/packages/infosystems/WWW /clients/mozilla/
• http://www.ibiblio.org/pub/packages/infosystems/WW W/clients/mozilla/
• ftp://ftp.tux.org/pub/net/mozilla/
• http://www.cise.ufl.edu/ftp/mirrors/mozilla/
• ftp://ftp.yggdrasil.com/mirrors/site/ftp.mozilla.o rg/pub/
• ftp://sunsite.utk.edu/pub/netscape-source/
• ftp://archive.progeny.com/mozilla/
• http://archive.progeny.com/mozilla/
• rsync://archive.progeny.com/mozilla/
• http://mirrors.xmission.com/mozilla/
• ftp://mozilla.teleglobe.net/ftp.mozilla.org/pub/

• ftp://ftp.cvut.cz/mozilla/
• http://ftp.cvut.cz/mozilla/

• ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.mo zilla.org/pub/mozilla/
• ftp://ftp.fh-wolfenbuettel.de/pub/www/mozilla/
• ftp://ftp.uni-bayreuth.de/pub/packages/netscape/mo zilla/
• ftp://sunsite.informatik.rwth-aachen.de/pub/mirror /ftp.mozilla.org/pub/
• ftp://ftp.leo.org/pub/comp/general/infosys/www/bro wsers/mozilla/
• ftp://ftp.rhein-zeitung.de/mirrors/mozilla.org/
• ftp://ftp.uni-erlangen.de/pub/mirrors/mozilla/
• http://ftp.uni-erlangen.de/pub/mirrors/mozilla/

• http://mirrors.sunsite.dk/mozilla/
• ftp://mirrors.sunsite.dk/mozilla/
• rsync://mirrors.sunsite.dk/mozilla/

• ftp://ftp2.mbp.ee/pub/mozilla/

• ftp://ftp.rediris.es/mirror/mozilla/
• http://ftp.rediris.es/mirror/mozilla/
• ftp://ftp.etsimo.uniovi.es/pub/mozilla/
• http://www.etsimo.uniovi.es/pub/mozilla/

• ftp://ftp.funet.fi/pub/mirrors/ftp.mozilla.org/pub /

• ftp://ftp.univ-lille1.fr/pub/mozilla/
• ftp://ftp.oleane.net/pub/mozilla/
• http://ftp.oleane.net/pub/mozilla/
• ftp://ftp.free.fr/pub/Networking/www/Mozilla
• ftp://fr2.rpmfind.net/linux/mozilla/
• http://fr2.rpmfind.net/linux/mozilla/

• ftp://ftp.ntua.gr/pub/www/Mozilla/ ftp://ftp.duth.gr/pub/mozilla -->

• ftp://ftp.comp.hkbu.edu.hk/pub/mozilla/
• ftp://sunsite.ust.hk/pub/mozilla/

• ftp://ftp.c3.hu/pub/mirrors/mozilla/
• http://mozilla.szentimre.hu/

• ftp://ftp.EUnet.ie/mirrors/ftp.mozilla.org/pub/

• http://mozilla.fresh.co.il/

• ftp://ftp.cin.nihon-u.ac.jp/pub/net/www/mozilla ftp://his.ktarn.or.jp/pub/mirrors/mozilla/ --->
• ftp://ring.aist.go.jp/pub/net/www/mozilla/
• ftp://ring.crl.go.jp/pub/net/www/mozilla/
• ftp://ring.etl.go.jp/pub/net/www/mozilla/
• ftp://ring.exp.fujixerox.co.jp/pub/net/www/mozilla /
• ftp://ring.nacsis.ac.jp/pub/net/www/mozilla/
• ftp://ring.so-net.ne.jp/pub/net/www/mozilla/
• ftp://ftp.jaist.ac.jp/pub/Mozilla/
• ftp://ftp.lab.kdd.co.jp/Mozilla/
• ftp://ftp.kddlabs.co.jp/Mozilla/
• http://mirror.nucba.ac.jp/mirror/mozilla/
• ftp://mirror.nucba.ac.jp/mirror/mozilla

• ftp://ftp.hpcnet.ne.kr/pub/Mozilla/
• ftp://linux.sarang.net/mirror/network/client/web/m ozilla/

• ftp://ftp.uninett.no/pub/network/www/mozilla/

• ftp://sunsite.icm.edu.pl/pub/mozilla/
• http://sunsite.icm.edu.pl/pub/mozilla/
• ftp://ftp.task.gda.pl/pub/mozilla/

• ftp://ftp.global-one.pt/pub/Packages/Mozilla/

• ftp://ftp.chg.ru/pub/WWW/mozilla/

• ftp://ftp.sunsite.kth.se/mirrors/ftp.mozilla.org/
• ftp://ftp.fredan.org/mozilla/

• http://mirror.averse.net/pub/mozilla/
• ftp://mirror.averse.net/pub/mozilla/

• http://www.mozilla.sk/pub/

• ftp://ftp2.sinica.edu.tw/pub3/www/mozilla/
• ftp://ftp.nctu.edu.tw/WWW/mozilla/
• rsync://ftp.nctu.edu.tw/ftp/WWW/mozilla

• ftp.mirror.ac.uk/sites/ftp.mozilla.org/pub/ ftp://ftp.gbnet.net/pub/mozilla/
• http://www.gbnet.net/public/mozilla/ -->
• ftp://mozilla.teleglobe.net/ftp.mozilla.org/pub/

• ftp://gd.tuwien.ac.at/infosys/browsers/mozilla/sou rces/
• http://gd.tuwien.ac.at/infosys/browsers/mozilla/so urces/

• ftp://mozilla.mirror.pacific.net.au/mozilla/
• http://mozilla.mirror.pacific.net.au/
• ftp://ftp.planetmirror.com.au/pub/mozilla/
• http://planetmirror.com.au/pub/mozilla/

• ftp://ftp.belnet.be/packages/mozilla/

• ftp://ftp.ntrl.net/pub/mirror/mozilla/

• ftp://sunsite.ualberta.ca/pub/Mirror/mozilla/

• ftp://sunsite.cnlab-switch.ch/mirror/mozilla/

• ftp://ftp.ibiblio.org/pub/packages/infosystems/WWW /clients/mozilla/
• http://www.ibiblio.org/pub/packages/infosystems/WW W/clients/mozilla/
• ftp://ftp.tux.org/pub/net/mozilla/
• http://www.cise.ufl.edu/ftp/mirrors/mozilla/
• ftp://ftp.yggdrasil.com/mirrors/site/ftp.mozilla.o rg/pub/
• ftp://sunsite.utk.edu/pub/netscape-source/
• ftp://archive.progeny.com/mozilla/
• http://archive.progeny.com/mozilla/
• rsync://archive.progeny.com/mozilla/
• http://mirrors.xmission.com/mozilla/
• ftp://mozilla.teleglobe.net/ftp.mozilla.org/pub/

• ftp://ftp.cvut.cz/mozilla/
• http://ftp.cvut.cz/mozilla/

• ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.mo zilla.org/pub/mozilla/
• ftp://ftp.fh-wolfenbuettel.de/pub/www/mozilla/
• ftp://ftp.uni-bayreuth.de/pub/packages/netscape/mo zilla/
• ftp://sunsite.informatik.rwth-aachen.de/pub/mirror /ftp.mozilla.org/pub/
• ftp://ftp.leo.org/pub/comp/general/infosys/www/bro wsers/mozilla/
• ftp://ftp.rhein-zeitung.de/mirrors/mozilla.org/
• ftp://ftp.uni-erlangen.de/pub/mirrors/mozilla/
• http://ftp.uni-erlangen.de/pub/mirrors/mozilla/

• http://mirrors.sunsite.dk/mozilla/
• ftp://mirrors.sunsite.dk/mozilla/
• rsync://mirrors.sunsite.dk/mozilla/

• ftp://ftp2.mbp.ee/pub/mozilla/

• ftp://ftp.rediris.es/mirror/mozilla/
• http://ftp.rediris.es/mirror/mozilla/
• ftp://ftp.etsimo.uniovi.es/pub/mozilla/
• http://www.etsimo.uniovi.es/pub/mozilla/

• ftp://ftp.funet.fi/pub/mirrors/ftp.mozilla.org/pub /

• ftp://ftp.univ-lille1.fr/pub/mozilla/
• ftp://ftp.oleane.net/pub/mozilla/
• http://ftp.oleane.net/pub/mozilla/
• ftp://ftp.free.fr/pub/Networking/www/Mozilla
• ftp://fr2.rpmfind.net/linux/mozilla/
• http://fr2.rpmfind.net/linux/mozilla/

• ftp://ftp.ntua.gr/pub/www/Mozilla/ ftp://ftp.duth.gr/pub/mozilla -->

• ftp://ftp.comp.hkbu.edu.hk/pub/mozilla/
• ftp://sunsite.ust.hk/pub/mozilla/

• ftp://ftp.c3.hu/pub/mirrors/mozilla/
• http://mozilla.szentimre.hu/

• ftp://ftp.EUnet.ie/mirrors/ftp.mozilla.org/pub/

• http://mozilla.fresh.co.il/

• ftp://ftp.cin.nihon-u.ac.jp/pub/net/www/mozilla ftp://his.ktarn.or.jp/pub/mirrors/mozilla/ --->
• ftp://ring.aist.go.jp/pub/net/www/mozilla/
• ftp://ring.crl.go.jp/pub/net/www/mozilla/
• ftp://ring.etl.go.jp/pub/net/www/mozilla/
• ftp://ring.exp.fujixerox.co.jp/pub/net/www/mozilla /
• ftp://ring.nacsis.ac.jp/pub/net/www/mozilla/
• ftp://ring.so-net.ne.jp/pub/net/www/mozilla/
• ftp://ftp.jaist.ac.jp/pub/Mozilla/
• ftp://ftp.lab.kdd.co.jp/Mozilla/
• ftp://ftp.kddlabs.co.jp/Mozilla/
• http://mirror.nucba.ac.jp/mirror/mozilla/
• ftp://mirror.nucba.ac.jp/mirror/mozilla

• ftp://ftp.hpcnet.ne.kr/pub/Mozilla/
• ftp://linux.sarang.net/mirror/network/client/web/m ozilla/

• ftp://ftp.uninett.no/pub/network/www/mozilla/

• ftp://sunsite.icm.edu.pl/pub/mozilla/
• http://sunsite.icm.edu.pl/pub/mozilla/
• ftp://ftp.task.gda.pl/pub/mozilla/

• ftp://ftp.global-one.pt/pub/Packages/Mozilla/

• ftp://ftp.chg.ru/pub/WWW/mozilla/

• ftp://ftp.sunsite.kth.se/mirrors/ftp.mozilla.org/
• ftp://ftp.fredan.org/mozilla/

• http://mirror.averse.net/pub/mozilla/
• ftp://mirror.averse.net/pub/mozilla/

• http://www.mozilla.sk/pub/

• ftp://ftp2.sinica.edu.tw/pub3/www/mozilla/
• ftp://ftp.nctu.edu.tw/WWW/mozilla/
• rsync://ftp.nctu.edu.tw/ftp/WWW/mozilla

• ftp.mirror.ac.uk/sites/ftp.mozilla.org/pub/ ftp://ftp.gbnet.net/pub/mozilla/
• http://www.gbnet.net/public/mozilla/ -->
• ftp://mozilla.teleglobe.net/ftp.mozilla.org/pub/

I've been using Debian for almost a year now, and I couldn't be happier. As for the article making it seem that you can't get the latest goodies from Debian, that may have been misleading.

The Debian team maintains 3 branches, Stable, Testing, and Unstable. While Stable uses Kernel 2.2 and XFree86 3, Testing gives you kernel 2.4.16, XFree86 4, and other, up-to-date goodies.

My only complaint about Debain is that the install can be painful, especially to those used to more graphical oriented tools. But the fact that you can burn a 30meg CD and do an install over the internet is very nice (netinst), and once you get used to apt-get, you'll wonder how you got by without it.

the electricity over IP rfc

RFC 1591
The country codes are 2 letters. The codes come from IANA which refers to ISC country codes, so complain to ISO. Besides .sa and .se are taken. They could go to .oc (ocean), but who'd want that?

Instead of boosting the pigeonrank of any page that doesn't validate, I think it makes more sense to list a bunch of competing sites and say how well each one validates. Here are some sites that I think do it right:

Search Engine HTML Validation Results - list of major search engines and web directories, showing how many HTML errors the W3C validator finds on both the front page and the results of a search for "mp3 rippers". The table was posted on June 29. One site (dmoz.org) made its front page validate by July 3.

Financial Institutions and Mozilla Operability - list of many banks, saying how well Mozilla works with each bank. By concentrating on the practical "Can I use this site with Mozilla" rather than the ideal "Does this site validate", this site is more useful to users trying to decide which competitor to choose. It is therefore more powerful for getting the sites to fix themselves.

and for contrast:

Free Web Hosts - list of free web hosts and whether the host makes an uploaded web page stop validating. Doesn't have enough data for a table yet, so there's not much pressure on hosts to change. Uploads XHTML test pages rather than HTML 4.01 test pages, which seems like an odd choice to me.

The most popular subjects there are "Science, Math and Computing" with 289 titles. There are quite a few other subjects covered there too.

The Assayer is more than just a list of books though - it has reader-contributed reviews. For example, here is the entry for DocBook: The Definitive Guide by Norman Walsh (available at www.docbook.org). There is a review at the bottom of the entry page.

I'm writing a Free book, although it is at a very early draft stage. The ZooLib Cookbook is a tutorial for the ZooLib cross-platform application framework.

I'm also slowly creating a copylefted collection of articles on software quality at the Linux Quality Database.

The most popular subjects there are "Science, Math and Computing" with 289 titles. There are quite a few other subjects covered there too.

The Assayer is more than just a list of books though - it has reader-contributed reviews. For example, here is the entry for DocBook: The Definitive Guide by Norman Walsh (available at www.docbook.org). There is a review at the bottom of the entry page.

I'm writing a Free book, although it is at a very early draft stage. The ZooLib Cookbook is a tutorial for the ZooLib cross-platform application framework.

I'm also slowly creating a copylefted collection of articles on software quality at the Linux Quality Database.

• Playing with Linux RAID
• The physical layout of the ext2 filesystem

Also, the Open Source Development Lab's Japan Development Center was kind enough to recently translate a couple of my Linux kernel testing articles into Japanese:

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

I would personally be quite stoked if anyone translated any of the articles to other languages. There is also an article on web server application testing as well as one on C++ programming. I have more planned and invite others to contribute articles that have the general aim of improving the quality of Free Software.

• Playing with Linux RAID
• The physical layout of the ext2 filesystem

Also, the Open Source Development Lab's Japan Development Center was kind enough to recently translate a couple of my Linux kernel testing articles into Japanese:

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

I would personally be quite stoked if anyone translated any of the articles to other languages. There is also an article on web server application testing as well as one on C++ programming. I have more planned and invite others to contribute articles that have the general aim of improving the quality of Free Software.

• Playing with Linux RAID
• The physical layout of the ext2 filesystem

Also, the Open Source Development Lab's Japan Development Center was kind enough to recently translate a couple of my Linux kernel testing articles into Japanese:

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

I would personally be quite stoked if anyone translated any of the articles to other languages. There is also an article on web server application testing as well as one on C++ programming. I have more planned and invite others to contribute articles that have the general aim of improving the quality of Free Software.

• Playing with Linux RAID
• The physical layout of the ext2 filesystem

Also, the Open Source Development Lab's Japan Development Center was kind enough to recently translate a couple of my Linux kernel testing articles into Japanese:

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

I would personally be quite stoked if anyone translated any of the articles to other languages. There is also an article on web server application testing as well as one on C++ programming. I have more planned and invite others to contribute articles that have the general aim of improving the quality of Free Software.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.

That's why I started The Linux Quality Database.

My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.

For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.

Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.

But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.

I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.

The articles available so far 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
• Pointers to C++ Member Functions

I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.

Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.

In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.

They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.

The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.

One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.

Actually it's not that hard.. You just need to have a boot disk that will allow you network support and some file transfer protocol. tomsrtbt and mulinux come to mind.
Instructions:
Mount the CD on some computer with a cd-rom and network support.
Follow boot disk instructions to get the computer that Gentoo Linux is going to be installed on running and the network up.
Look at Normal Instructions and Skip steps 1 - 5; Follow step 6 (partitions) and 7 (mounting); skip 8; and for step 9, instead of copying from cd-rom, copy stages from the network (using whatever protocol meets your fancy); then continue on with the rest of the instructions.

Stuff at home that should never be down goes on the Linux Samba server, my wife's pictures go on the dual boot Linux/Win98 workstation. My son's games go on the Win2K machine.

At work I put all my documents on the Win2K server except for stuff I'm working on in solid modelling, 100Mb isn't fast enough then.

I use VPND to join the two networks, so Samba, ftp, etc all work over the VPN. VPND is nice because it's a router-to-router VPN and I don't have to worry about configuring client computers to use it.

For backups, at work I don't have to worry, IS backs up my documents if I put them on the server. At home I just dump my data to a CD.

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

Also check out the Open Source Development Lab's Scalable Test Platform. You can use STP to run your kernel patches and test code that you upload to OSDL's big iron hardware, or you can download the STP source code so you can use it as a test harness on your own machine.

(I should add the STP to my article but haven't gotten around to doing so yet).