osdlab.org · Domains · Slashdot Mirror

Re:question by tuxgeek · 2009-03-01 12:36 · Score: 5, Informative · on Analyzing Microsoft's Linux Lawsuit

OSDL has implemented a legal defense fund for this purpose.
http://www.osdlab.org/en/Linux_Legal_Defense_Fund

I'm not sure how it works but I believe you can make donations to them (tax deductible?) specifically for the purpose of defending OSS developers against lawsuit from litigious douche bag companies such as M$, SCO, and various other patent trolls.

Kernel Testing Tips by goingware · 2002-05-19 13:41 · Score: 4, Interesting · on Linux Beta Kernel 2.5.16 Out

If you are new to compiling your own kernel, or you would like information on how to more effectively test development kernels (or stable kernels, before putting them into production), these two articles may be helpful to you:

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

Kernel Testing Tips by goingware · 2002-05-19 13:41 · Score: 4, Interesting · on Linux Beta Kernel 2.5.16 Out

If you are new to compiling your own kernel, or you would like information on how to more effectively test development kernels (or stable kernels, before putting them into production), these two articles may be helpful to you:

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

Re:What's good about 2.5 by Alphix · 2002-02-11 03:01 · Score: 4, Informative · on 2.5.4 Kernel Out

Check out this link. It's a list of stuff to expect in 2.5
Follow the link to the posts if you want the details and discussions, if you don't, the items and a more human-readable explaination is below:

2.5.x API change summaries
o Shouldn't matter much as far as I could tell, mostly "heads up" to people writing programs that mess with the kernel.

o Block I/O layer changes:
The goal seems to be a more generic i/o scheduler while at the same time making it more efficient.
Typical "dont-understand-exactly-what-they-are-doing-but-g lad-they-do-it" stuff.

o initrd / initramfs:
initramfs is intended as a replacement for initrd. The basic idea seems to be to tack a .tar archive of modules and programs to the end of the kernel image, make a basic boot, unpack the tar file to a ram-based root filesystem then everything goes from userspace. If it's true that 2.5 will move to a completely modular kernel (as Alan Cox has hinted), this would be a much friendlier system than initrd.

o SCSI changes
As always?

o driver model: driverfs
Driverfs seems to aim towards merging all bus-type weirdness that lives under /proc and building one big tree with all bus:es in it. Most comments I've seen circle much around how much easier it would be to implement a proper ACPI power management system with this and that it clears up /proc.

o reworking major/minor system
The currrent model of drivers having major/minor numbers is going to change to allow larger numbers (and therefore, more devices). May be some hairy details involved in changing such a "standard" size. Consent seems to be that apps that depend on a specific size are broken anyway.

o USB and WireLess API changes
I don't use any of these so I haven't got much to say, anyone with more interest/info?

o kbuild and CML2
The new configuration language and makefiles, these have been discussed earlier on slashdot (see here).

My Effort at Organized Linux QA by goingware · 2002-01-17 17:52 · Score: 2 · on 2.4, The Kernel of Pain

A few months before 2.4.0 was released, I inquired on the linux-kernel mailing if there was any organized QA effort for the new kernels. Read my post Organized Linux QA?

The response I received from a number of kernel developers was that there wasn't such a thing really but it would be great if I did the work of organizing it.

SunSITE.dk seemed to be the best site of the many kind folks who offerred to host it, and so was born The Linux Quality Database.

What my plan was, and is, to organize serious QA efforts among people other than the normal kernel developers, in support of the developers, so they can get faster and more thorough feedback on their code.

Unfortunately, my consulting work has always been very hectic, and so I have not been able to do the work on this that I want to, at least not yet. Things are getting a little more rational in my business, so I have high hopes for resuming my work on it sometime soon.

There is something of value on the site that can help everyone though, I wrote a few articles on the topic of linux kernel and web application quality. The articles of interest to kernel testing are:

I placed these under the GNU Free Documentation License in hopes that they would get widely distributed, perhaps included with distros. I plan to write a lot more articles - I like to write when I have the time.

I was happy to see that the Open Source Development Lab took advantage of the GFDL on the articles and reproduced them at its own site here.

Some might ask why I don't use an existing bug database such as bugzilla. I may well adapt bugzilla, I'm still trying to figure out what to do, but a central part of what I plan is a bug database optimized for tracking kernel bugs.

A database user will be able to enter in the configurations of the machines they have at their disposal, drawing on a database of known hardware, and give names to particular configurations.

When they report a bug, they can report the bug against selections from a list or menu of the configurations they have previously configured.

Also, they can upload the kernel .config file used in the kernel build.

Doing this will allow developers who are researching bugs to determine whether their code has been used on certain hardware, or to do boolean searches on both hardware and .config options to find out about interactions of kernel code with hardware.

I think bugzilla could be expanded to do this, or another bug database, but this is not a capability in any bug database I've used so far, either open source or proprietary ones at companies I've worked for.