Slashdot Mirror

Perhaps you'd wish to appreciate Ingo Molnar's work? Robert Love's work has been to make the kernel mostly preemptible, rather than to make its scheduling algorithm more efficient.

Actually, their new scheduler (SCHED_ULE) for example was copied almost verbatim from Linux's O(1) scheduler. Sure, change words around and claim its only vaguely based on Linux, but believe me as someone who has read both sources - its a blatant rip off.

Wrong. Linux ripped the ULE from FreeBSD. Proof Here NOT the other way around.

I'm QUITE sure the code you read on your Linux box is very nearly identical to that of the code in FreeBSD, BECAUSE IT WAS RIPPED FROM FREEBSD BY Francesco Sportolari.

Jeffrey Roberson wrote FreeBSD's ULE, and I'M QUITE sure he'd be rather bothered by your accusations. ULE was designed as an improvement for SMP based systems, yet FreeBSD's scheduler is, and has been 0(1). Perhaps read This sometime. Also ULE is *NOT* the default scheduler, it's still SCHED_4BSD, atleast up until 5.1.(I don't run any 5.2 boxes, my only 5.x boxes are non-production)

Be sure you get your facts straight before you go off making false accusations against FreeBSD, and it's extremely talented and hard-working developers.

I love Linux for what it's accomplished, and I love *BSD for the same reason.
My personal preferance is FreeBSD, trying to change that is like trying to tell me that Chocolate Ice Cream is better than Vanilla.

-mpf

and quit marking me off-topic, I'm not! :)

Baaahhhh haaaaaaa haaaaaa haaaaa.

FreeBSD has about 350 active developers. The Linux Kernel alone would have that many.

Linux is more stable than FreeBSD for servers or anything else.

Most Linux drivers are nicer.

Linux is more secure.

Oh no! It scales better, does it? Oh damn, I guess you must be right. Hey everybody, FreeBSD scales better than Linux. This guy really showed me a thing or two.
What?
You're a moron?

Baaahhhh haaaaaaa haaaaaa haaaaa.

FreeBSD has about 350 active developers. The Linux Kernel alone would have that many.

Linux is more stable than FreeBSD for servers or anything else.

Most Linux drivers are nicer.

Linux is more secure.

Oh no! It scales better, does it? Oh damn, I guess you must be right. Hey everybody, FreeBSD scales better than Linux. This guy really showed me a thing or two.
What?
You're a moron?

SuSE 9.0 is supposed to be ready for kernel 2.6 as far as the necessary tool versions are concerned (listed at Kerneltrap).

SuSE keeps unofficial RPMs on their ftp server but will probably wait for their next distro release until they upgrade). Currently the server only lists test kernels. They have done a lot as far as backporting features of the 2.6 kernel are concerned, so the incentives for switching to 2.6 are not as numerous as for other distro users).

Well, I know /. readers do not like SuSE, but anyway... :-)

That was the point of the whole 2.6.0 test series. The reason they did that was because it was likely that someone who wouldn't touch 2.5 with a ten foot pool would run 2.6 text X, and they did. 2.6.0 probably had more testing than any other kernel. I've been using it on two machines ince test1, the only problem I encountered was that DRI was broke in 1 release.

Have there been any articles or reviews comparing the performance of various kernel versions? I'd find it interesting how much progress has been made in areas such as network throughput, disk access, etc. I guess its possible there isn't any more room for progress in some areas, I would find that interesting too.

There are many benchmarks that illistrate how much better 2.6.0 is than 2.4. You can always boot to it and see for yourself and then switch back to 2.4 if you have problems. Just make your old kernel the second option in Grub/Lilo so you can go back and remove 2.6. You might be able to find more info on Kerneltrap.org

I'm not how how important network throughput and disk access are since they don't have much to do with the kernel and more to do with the network interface and filesystem respectively.

everyone knows macros are hard. Linus admits to getting is_digit wrong in his origional ctype.h.

The problem lies in still unmerged code for highmem and slabcache reclaim (check /proc/slabinfo or use slabtop), which is in the -aa tree for ages.
I reported that to Marcello, but he seemed very uninterested in tracking down (many, many thanks to Andrea and Rik, who helped) and applying those particular fixes in the -aa tree.

I'd love to see more cross-pollination too. It won't happen. GNOME was started for ideological reasons (Qt wasn't GPL at the time), and then run into the ground for ideological reasons (refusal to do the right thing because KDE was already doing it, and this even after their own leader admitted that their own approach was faulty!).

Remember that there are people in this world who refuse to use 'make xconfig' in kernel 2.6 because it's Qt-based, and actually wasted time hacking up a GTK clone (one that keeps crashing at that).

There is probably some poetic justice to the fact that this mix of blind ideologism and idiocy would have been what ran GNOME into the ground until it had to resort to becoming a commercial product to simply survive, but I'd much rather live in a world where people aren't so dumb. :/

This thing is ripe with bad code (it's sprinked with gotos for error handling)

I think goto's are fine, and they are often more readable than large
amounts of indentation. That's _especially_ true if the code flow isn't
actually naturally indented (in this case it is, so I don't think using
goto is in any way _clearer_ than not, but in general goto's can be quite
good for readability).

If that's the case, check out this patch.

Forget dropping down to HZ=100 and take the leap up to HZ=10000! :D

This already exists - Ingo Molnar has written something called the exec-shield patch which implements this functionality in a slightly different fashion. Here is a link to one of Ingo's patch announcements.

Well, make IS much prettier now.

S

Try the first paragraph of this story for a bunch of technical links. Or this one from Linuxworld for a more introductory overview.

But probably what you really want is Joseph Pranevich's Wonderful World of Linux 2.6.

For those of us upgrading from 2.4 to 2.6 and don't know where to begin, you may want to check out an upgrade guide.

It's small but very helpful for someone that doesn't completely know what they're doing.

That's why I linked to the article where Linus Torvalds sets the record straight on binary modules.

OK -- this has the potential to open up a can of worms...and I don't care enough to have it out iwth anyone on this, but I'll open my yapper anyway -- cause I'm that kind of asshole ;)

I have a hard time believing that hardware drivers of any kind can be considered a derivative work. This is particularly if the hardware wasn't built for the express purpose of working with the Linux kernel (which I guess means that this point doesn't apply to TiVo). Alot of it goes back to Larry McVoy's point in this thread -- which I believe is correct (even if Linux disagrees).

My general feeling is that liberal consideration of applications (and modules) which interface with an OS as a derivative work is dangerous, particularly in the midst of the SCO v IBM lawsuit, where part of their claim is that Linux is a derivative work of SysV Unix. Furthermore, I'm especially surprised that Linus felt that way, since it causes some inflexibility in Linux's adoption into the marketplace. It seems more like something RMS would say to increase the spread of free software.

That being said, I'm not about to test any of it in court...I'm not (nor do I work for or represent) a major commercial hardware/software manufacturer. However, if a TiVo or nVidia wants to test it -- I'd bet that the law is on their side.

--Turkey

Perhaps. It's a subtle issue and one that does not have a clear answer, although a great many people argue passionately for one side or the other.

Part of the answer depends on header files. Usually, you include header files to reference the functions you call which make up the API. However, many header files are more than simply declarations of extern functions. They include macros and inline functions, which are inserted into your code and remain there after compilation. Thus you have GPL'd code in your application.

Another part of the answer depends upon the definition of "derived work." If you write a program which is dependent upon, and only works with, my specific framework, then quite arguably it's a derivative work of my framework. If you write, for example, a POSIX compliant app which runs on multiple OS's or *nixes, then quite arguable it's NOT a derived work.

See here for Linus' take on the issue.

For all those that are looking for a filesystem comparison, I found this story to be quite interesting...or go here for the test details and results.

Somebody has no sex life...

It'a called stable kernel series, you know. It's supposed to be stable. That's why they don't want to cripple the official tree it with (sometimes) broken stuff such as the pre-emptive patch.

According to this they are simply adding a README file but not removing SCO support. Has anything new happened since?

Or are you simply saying they aren't likely to actively maintain that part of the SCO against changes made elsewhere?

A full discussion of the pre-empt problem can be found here:
http://kerneltrap.org/node/view/1679

This is probably what has been happening to me.
I tried up to -test9, but after a few (2-10) hours, my cpu and disk access would shoot up and RAM usage would slowly increase. I dropped to a tty, typed the username "root", but the cpu load was so hight that login timed out before I was even prompted for a password!
So I had to kill the power on my machine while I could hear that my disk was fully active. I was not a happy camper.

it might very well help to give the kernels more market oriented names

Eh? What could be more Brand-Building than a name like Stoned Beaver?

I've been wanting to run the 2.6 on my Debian-unstable box, but I've been scared off by some of the negative reports I've heard so far. Some of them I've seen on comments from this article.

Most notably (for me) is devfs not being actively supported anymore (being shifted in favor of udev). That's sad, at least for me, because I've been using devfs since the early versions of the 2.4 kernel, it always worked well for me, and from what I've heard about udev so far, devfs seems like a more elegant and mature solution.

Then there are problems with USB devices, and others that, being narrowed down, comes down to problems on the APIC interface. From what I've heard so far, it doesn't look stable, so why ship it on linux 2.6?

There's also this problem with Kernel Preemption. I'm using it on my 2.4, and I don't want to go without it on 2.6. Of course I might just be lucky to no stumble on this problem, but the fact that it can trigger an oops on someone just scares the hell out of me.

Finally, there's a problem I've experienced myself, but didn't care to report at the time. It's quite old by now (I think it was around version 2.5.65~2.5.70). It has to do with software-raid. I've got a RAID-0 array with 3 SCSI Disks (6gb + 2x4gb = ~14Gb). The disks are old, I know, just like the controller (Adaptec AIC-7xxx). But they work just fine on the 2.4 kernel. So, at the time I decided to give 2.5 a try, just to find out that my array wasn't being detected/mounted. Googled around, found some similar reports and some possible workarounds, but none worked, so I switched back to the 2.4 kernel and haven't touched the development kernels since. It might just be resolved by now, I don't know... Anyway, I will soon replace these disks by a couple of IDEs, with no RAIDing, to save some CPU cycles, so this will not be such a big problem.

So, anyone care to give me one (or more) reason s to try 2.6 again?

A problem, potentially delaying release? Seems that they don't really know what causes it as of yet...

• Start by reading this article: http://kerneltrap.org/node/view/799 but don't follow those steps quite yet. You may not need to at all, depending on your setup and needs.
  
• Now go to http://people.redhat.com/arjanv/2.5/RPMS.kernel/ and download all necessary files as outlined in the previous document. Before you install the kernel RPM, make damn sure that you aren't missing anything or things break very fast. You should also take steps to backup as outlined in the first document. Now install the RPM and make any necessary bootloader changes/bootdisks. That may do it for you.
  
• If you have to make some changes (ie I needed ntfs), download the kernel source (I had trouble with the rpm on that site, ymmv) and do a make oldconfig followed by a make (x or g)config to get the small changes you need. Good luck!

Because in some cases , Linux is the better tool for the job. Thinking with your dick isn't going to help your computer.

Linux: Kernel "Back Door" Attempt.

Good try, there!

You have to register to get most papers from ACM (the Association for Computing Machinery who published "GOTO considered harmful"). However, the full text can be found free in their classics series.

Everybody should read this paper, then read Linus Torvalds et. al. discussing the matter on kernaltrap.org

First, I would like to thank you for keeping your patent issues separate from your copyright issues. Not enough people realize that copyright law is very different from patent law in many important ways.

In the case of his stance on patents, joking comments aside, I think it's pure pragmatism. The simple, legal fact is that researching patents to make sure Linux implementations were non-infringing would make hime more liable, not less.

I am not asking Torvalds to investigate specific patents that may or may not affect the development of the Linux kernal. What I'm talking about is the depth of understanding of the issues on how patent law hurts us as software developers, computer users, and citizens. Nothing Torvalds has offered on the subject of what are commonly called "software patents" comes close to the depth of understanding Stallman offers every time RMS gives his patent speech. Torvalds' apparent lack of understanding of the ethical and legal issues involved is profoundly impractical. Stallman's talk on the problems with software patents lists the reasons why it's not reasonable to ask anyone to search the patent database looking for possible infringements.

Torvalds has a golden opportunity to use his celebrity power to educate people about a common foe--the existence of software patents and how they hurt everyone except IBM. Or he could speak out on a number of other similar issues, like the ones Stallman talks about.

How about copyright? Again, pragmatism rules. How do you think SCO would have reacted if he'd gone to them a year ago and said "Hey, I'd like to compare Linux against the SysV source tree and see if there's any infringing code?"

It is SCO that is suing, not Torvalds. Torvalds' development strategy has lead to less than careful inclusion of non-free software into his branch of the Linux kernal and because this branch is so popular it is likely others have become dependent on the non-free software. As a result of not paying attention to the freedoms of Free Software and the license under which the Linux kernal is distributed, some have probably redistributed non-redistributable software. In the above link Stallman points out why this is:

"Linux, the kernel, is often thought of as the flagship of free software, yet its current version is partially non-free. How did this happen? This problem, like the decision to use Bitkeeper, reflects the attitude of the original developer of Linux, a person who thinks that "technically better" is more important than freedom.

"Value your freedom, or you will lose it, teaches history. `Don't bother us with politics,` respond those who don't want to learn."

However large book, music, and movie publishers have a lot of say in copyright policy and we're exporting our copyright policy to other countries through trade policies that don't benefit citizens. Stallman brings attention to our freedom to use, share, and modify software. Torvalds doesn't talk about freedom at all and is celebrated for not challenging the 'technically better' view of software.

cons:
generally slower, less scalable in terms of algorithms and how parellel the kernel is than Linux.

It is considered more stable than Linux by its proponents, but no studies have indicated one way or the other.

no

Sweet, we'll just tell these guys that FreeBSD 5 will be scalable enough to... err... be very scalable. Hah!

No, but if you need support for 512 CPUS, try Linux... Now I suppose someone is going to tell me FreeBSD 5 will scale better?

Drupal has had a book module in the core distribution for atleast a year. In drupal terms, this allows you to author any node (blog entry, forum post, image , story etc.) and attach it in relation to the book. (based on taxonomy). Each of these pages has revision control and can optionally go into the submission queue. It is possible to set it up even more extensively ... whereby you can use the groups module to give certain users different rights depending on which topic they are editing etc.

Some Examples :

• Drupal Handbook.
• ENC 1101-B3 & B4: Writing for Discovery.

Drupal is an incredibly well thought out content management framework that aims to be as extensible as possible. I use drupal to run several of my personal sites , and have been using drupal for more than a year now. The deanspace campaign makes use of it, aswell as several large websites such as kerneltrap and debianplanet

Read this article at KernelTrap . You'll probably need new modutils and may need new fs utilties. If you've never run ALSA before, there's a lib and some more utils.

Read this article at KernelTrap . You'll probably need new modutils and may need new fs utilties. If you've never run ALSA before, there's a lib and some more utils.

Make sure your X server is running at default priority (ie. 0). If that doesn't help, download Nick's scheduler here. Note, this one should be run with X at nice -10 or so. If Nick's fixes the problem for you, then report it to lkml, please.

Aparently this all started when a kernel developer (Rusty Russell) attempted to resolve some race condition in the module unloader and ended up porting all user space module loading stuff (insmod etc) into the kernel. Now insmod can be written in 20 lines of c (while it was over 2000 lines of code).

You can read all about this in an interview with Rusty Russell at Kerneltrap.org.

Take a look at How to install Andrew Morton's -mm kernel for some links and explanations of the issues that the -mm patchset is addressing.

Linus left Transmeta earlier this year

Rus

What about the ide layer rewrite which was started in early 2.5 but was later abandoned because of instability? story here If it was meant to be in 2.5 then it should shorly be in by 2.7.

OpenBSD is 8 years old, according to this post. And they've certainly done a lot of security auditing, but that was not the ONLY thing they worked on all this time.

Read the actual patch announcement from Linus Torvalds. Note, way down in the list, "selinux merge".

From the list of changes:

Make strncpy clear the unused part of the destination

This isn't a fix; it's a new bug. strncpy is not specified to do that.

Someone mod this down ... it is a troll that has been posted before. These are some 2.5.X patches that will be in 2.6, nothing that is in 2.4.22. Read the real changelog that was linked from the article. Moderators ... wake up!

Check out this great writeup by Con Kolivas on the subject. We've got a lot of really great minds looking to improve interactivity in the kernel. Great stuff, and no doubt more to come.

Ahh, but what about the ones that you don't forget? What about the ones that you *think* you'll never use again, but sometime down the road they pop up? When I was in college, I took an Operating Systems class. I never thought I would need that information. I have used that info many times in my career. Without having taken that class, I wouldn't have chosen to learn about how an OS works. I also had to take circuit design as part of my major. I never thought I would need it either, but I have. Maybe not so much in my career as in my personal life, but being interested in electronics does help me around the office. You never know what you'll use that information for in the future. In fact, the one class I took that taught mostly theory, a Software Engineering class my senior year, was the class that got me my job. I had brought in my final project when I interviewed at Motorola. Instead of just being a programmer, I had learned the basics of the software development lifecycle. You would be surprised how many programmers don't know anything beyond "code, compile, release". Requirements, design, coding, configuration management, stages of testing, development models, etc etc. You'd be really surprised how many people who have "real work experience" have no idea how the other parts of the lifecycle work.

The best way to learn to do something is to do it. In this case, "it" is working in IT. The best way to learn to work in IT is to work in IT. A college is a replication of an office environment also geared at making you more well rounded. Going to school teaches you broad concepts. Working in an office environment teaches you to work in an office environment.

Agreed. But if you don't understand those broad concepts, you are doomed to work in the same office environment. If you learn something in the office environment, you learn the way *that particular office* does it. You go somewhere else, they may do it differently. All I am saying is that you cannot learn everything you know from the experience of doing it. Yes, you have to get in there and "get your hands dirty" so to speak, but you need to learn the concepts first. Is a bachelor's enough to teach you that? Maybe, maybe not, depends on what you want to do. Is it *possible* to self-teach some of these concepts? Of course, but that isn't the norm.

Think of it like this: You want to be a network admin. You go get a job doing network admin stuff at a place that only has Windows. Are you really learning networking, or just the way Windows does networking? Wouldn't you be much better off if you had studied the concepts of networking first?

On an interesting note, I read this today:
http://kerneltrap.org/node/view/759
Here is the text:

Alan Cox [interview] posted a tiny patch to the lkml removing himself as maintainer of a couple of older/defunct drivers, adding, "Update other stuff because I will be away for a year". I scrambled for a Welsh translator to see what I'd been missing in his diary, but found no hints there. Fortunately a few minutes later he followed up with an explanation: "At the end of September I'm off back to University on a years sabbatical from Red Hat to study for an MBA. I've made the decision that I'm basically going to vanish for the year so I can concentrate on the course, and on the pet side project of learning Welsh." The 2.2 kernel that Alan maintained for several years now "needs a new maintainer, someone who can spend their entire life refusing patches, being ignored by the mainstream (because 2.2 is boring) and by vendors (who don't ship 2.2 any more)." In parting, he optimistically says: "A few years ago I'd have worried about doing this, the great thing is that with the kernel community we have today I know I'm not a critical cog in the mach

Find a complete mirror of the article here.

At the time, they didn't have an alternative. CVS has been stagnant for quite some time. Bitkeeper arose from conversations between the McVoy and Linus. McVoy wanted to help Linus (and probably himself) and had knowledge of SCM systems, so he built one.

I have no idea if BK is any good, but I do know there are flaws with CVS and it's free kin. Arch hasn't caught on, and Subversion development has been painfully slow (first release was in 2000/10) and it seems like a very heavy installation. Features like internationalization and supporting symlinks won't even make it into v1.0 (which should be out sometime shortly before duke nukem...)

I remember aegis from around 1995 or so when I read this report and it was free back then.