Slashdot Mirror

Ok, I think I can keep that.

markw@osdl.org
markw@osdl.org
markw@osdl.org
markw@osdl.org

Oh, perhaps we should confuse the spambots a bit:
markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org

Ok, I think I can keep that.

markw@osdl.org
markw@osdl.org
markw@osdl.org
markw@osdl.org

Oh, perhaps we should confuse the spambots a bit:
markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org markw@osdl.org

He's no longer working for Transmeta.
He's getting paid to write the kernel, paid by OSDL, more info here.

Do some searching around (linux-kernel mailing list archives, the bugzilla for linux-kernel) and try to work out whether it has already been reported.

Ensure that you can reproduce the problem on the latest kernel.

If the bug has only just appeared, it is very useful for the developers to know which kernel version it appeared in. The best way to find this out is to do a binary search between the working and non-working kernel versions.

If it has been reported, you might be able to contact the relevant maintainer (check the bug details or the MAINTAINERS file for details) and get a "possible fix" patch to try out.

If it hasn't been reported, I guess the best way to report it is to use the bugzilla. Please read and follow the advice there for how to report a bug, but again common sense applies.

Depending on the bug and your level of interest and ability, it can be really fun to try and work out a fix yourself.

(Sometime you can do this even if you aren't a great coder

e.g. Once I couldn't mount a CD and had a kernel message error about a 2k block size. I knew nothing about the driver, but grepped for the message, found it was bracketed by a "is it 1k or 4k" test. Simply adding 2k as another option to the "if" test and recompiling/rebooting allowed the CD to mount. That ruled.)

If you do produce your own fix, sending it to the relevant maintainer as a suggested change may be helpful, but please don't be upset if your fix isn't used. There are many reasons (some good, some bad) why something which works for someone isn't a good thing in general. (If you do send a patch, use 'diff -u oldfile.c newfile.c' to generate the patch file)).

Good luck

Ummm, the Kernel Bug Tracker as previously discussed here?

Here:

Position paper from an attorney over at OSI.

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 are right. HP, IBM and are just too small, to open a LAB to test the merits of Open Source software right? Have you seen OSDL: Open Source Development Lab?

I realize it only has some small companies supporting it like....

Computer Associates
Fujitsu
Hitachi
Hewlett Packard
Dell
Cisco
Intel

just to name a few.

OSDL has been doing heavy duty testing of the kernel 2.4, 2.5, and 2.6 on 1, 2, 4, and 8
processor systems, for the past 2 years. See
its Kernel
Testing website and tools. The particular tool
that does this is the Scalable Test Platform.

Bryce

OSDL have produced Positional Paper on the SCO issue.

It's a very well written 5-page document by FSF General counsel Eben Moglen, and can be found here.

Ciaran O'Riordan
--

Hi,

I'm the Bob Goatse, can you add me to your mailing list. Thanks.

My name is GoatSe.CX my e-mail is GoatSe.CX.

I protested the release of 2.4, saying its inclusion in distros would cause users to unknowingly run a poor quality kernel, but Linus said the reason he wanted it released was so that it would get more widespread testing.

The "stable" branch of the kernel is perhaps misnamed. Linus gets to release a new kernel whenever he wants, and I imagine he does some testing, but I don't think he puts a stable release through any kind of rigourous qualification, I think it's more like when the complaints about his pre- versions die down a little.

I know it's common for Linus to release stable kernels that are actually quite broken on some non-x86 architectures. People who run Linux on PowerPC use a branch that's extensively patched from Linus' releases.

Both the 2.4 and 2.2 kernels went through a number of releases before they were really usable. I think the reason 2.2 became reliable was that it was smaller and simpler, and fewer people were working on it.

I'm pretty sure a good part of the reason behind the establishment of the Open Source Development Lab and their hiring of prominent kernel developers like Linus and Andrew Morton is to make sure that 2.6 actually does turn out to be enterprise quality. IBM is a big backer of OSDL, and I don't think they want the billion dollar investment in Linux in general to go to waste.

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

OSDL, a non-profit, global consortium of leading technology companies dedicated to accelerating the adoption of Linux

Daily build results of Linus' linux-2.5 bitkeeper tree

defconfig allmodconfig Makefile
bzImage modules bzimage modules version

Date: 2003-06-30 (18:30): 0w,0e 0w,0e 8w,9e 1335w,39e (2.5.73)
Date: 2003-06-29 (18:30): 0w,0e 0w,0e 8w,9e 1335w,39e (2.5.73)
Date: 2003-06-28 (18:30): 0w,0e 0w,0e 8w,9e 1338w,39e (2.5.73)
Date: 2003-06-27 (18:30): 0w,0e 0w,0e 8w,9e 1338w,39e (2.5.73)
Date: 2003-06-26 (18:30): 1w,0e 0w,0e 8w,9e 1341w,39e (2.5.73)

OSDL is dedicated to enabling Linux and Linux-based applications for data center and carrier-class deployment. We provide the crucial hardware for testing and development at this level, giving open source developers around the world the resources needed to bring Linux further into telecommunications and the enterprise. We are an independently governed, non-profit organization supported by 21 industry leaders.

Sounds cool

I wonder if this [PDF!] cool new feature will help there.

Sounds a lot like "micro-rebooting" to me...

What's Bellingham got? It's not nearly as large as Tacoma. I was at Conifur Northwest last year, a small furry convention. It took the entire Tacoma Convention Center and part of the adjoining Tacoma Sheraton. The convention center was a concrete bunker and basically the ass end of the hotel. Tacoma also lacks restaurants, or even fast food, within walking distance of the convention center (unless you don't get sick of stale delis). I'm not holding out hope that Bellingham's any better since it's even less major than Tacoma, and you'd think being in the largest of the Seattle suburbs that Tacoma might have something.

Check out the OSDL Data Center Linux project, as well as the Carrier Grade Linux projects.

Some good info about specific kernel changes can be found in the DCL Road Map.

OSDL has been *great* with regard to bringing companies and kernel hackers together on this subject. Gathering specs, performing QA, and allowing use of hardware. I had talked with Timothy Witham at Linux World about database performance, and he said he's seeing dramatic speed improvements on a 2.5 kernel over 2.4 (20%->30%, using standard TPC benchmarks). Though I don't remember the database he was using (not MySQL or Postgres, but it was open source I believe).

Check out the OSDL Data Center Linux project, as well as the Carrier Grade Linux projects.

Some good info about specific kernel changes can be found in the DCL Road Map.

OSDL has been *great* with regard to bringing companies and kernel hackers together on this subject. Gathering specs, performing QA, and allowing use of hardware. I had talked with Timothy Witham at Linux World about database performance, and he said he's seeing dramatic speed improvements on a 2.5 kernel over 2.4 (20%->30%, using standard TPC benchmarks). Though I don't remember the database he was using (not MySQL or Postgres, but it was open source I believe).

one, two (looks interesting), three (looks interesting and authoritative).

Sort of like mentioned here?
Or found here?

For whatever it's worth, if you're looking for
work in the Beaverton, Oregon area, the
Open Source
Development Lab today posted a req for a
Perl/MySQL developer. They do 100% non-profit,
open source work on the Linux kernel and open
source in general.

So, anybody gonna be hiring in the Portland area in a couple months?

Oh, you want a high-paying IT job? Better start thinking about your own business, and I don't mean consulting. It's death valley for IT in Oregon right now. The

Open Source Development Lab in Beaverton is hiring - in fact, they just posted a new job req for a Perl software developer _today_. Decent pay, non-profit, Linux, 100% IT-focused, well-supported by IBM, Intel, HP, et al., and you get to keep copyright on what you write if you want, so long as you also give it away under the GPL. If you're in Oregon, why *aren't* you trying to get hired by these guys??? There's few such companies anywhere else in the US, after all.

I think the 2.5 kernel is about ready for launch.

Just need to clear up this last bug.

Bug 30 Owner: mbligh@aracnet.com (Martin J. Bligh)

Please enter
Exact Kernel version: 2.5.7
Distribution: red hat
Hardware Environment: pc
Software Environment: linux
Problem Description: RMS is too smelly - What do I do?

Steps to reproduce: No god no!!!

check out CGL

Well, these guys seem to think Linux in telecom is a good idea...

Well, these guys seem to think Linux in telecom is a good idea...

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

are you sure that he doesn't mean STP - the linux kernel scalable test platform?

Thanks! Be certain to post this via the award nomination form. (We ask for phone numbers and such, in case we need to gather additional info about the nomination.)

From the link: "The target storage subsystem is a 10-drive RAID-1 array of 169 GB that is connected via a Qlogic IPS2200 fibre channel controller."

Not exactly the system I'm using... I have to admit that ext2 seems to be pretty fast with that kind of hardware.

Here's a report on performance of some of these file systems: http://www.osdl.org/reports/journal_fs/. Obviously, performance is only one factor to consider when choosing a file system, so YMMV.

Here's an analysis report on some of the various file systems, graphing the results for easier digestion. :-)

http://www.osdl.org/reports/journal_fs/