The Linux 2.6 production kernel promises to be the most advanced open-source platform developed to date, according to computer scientists who have been putting the 2.5 development kernel through its paces. Read the article at eWeek.
2.6 Kernel to Push the Envelope
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
oh my god.
I was both suprised and amaised.
the improovments are asounding, it isalmost to the point of a total rewrite of the kernel. but at the same time I was very suprised to find all the horrable problems that existed before like the global locks on block devices rather than the new one lock per device which will allow concurent access to diffrent block devices.
another thing that suprised me was the terible threading. the 2.4 kernel tookj 15 min to create and destroy 100,000 threads the new kernel takes 2 seconds.
what excites me though is the perfect SMP scalability. each proc gets its own runqueue now rather than the global runqueue that existed before and actualy caused for lower performance with more procs.
then not to mention the new algorithms used to increase performance everywhere
and this just scratches the surface. I can’ wait to test out the finished product. multimedia performance here we come!!!
the article focuses on the highend world of IBM and corperations. I suggest that all desktop users go out and by Linux Journal this month to get a good perspective on what you will see when using 2.6
it is suprising though that Linus is so confident with this one that he expects to have 2.7 open buy Linux Summet!!!!!
that is only a few months away!!
2.5 did not open for almost a year or so after 2.4 was released!
In what other world would you have guys from Red Hat, IBM, and Oracle all working on the same product, trying to make it better?
And I hope that in 2.7 they will work in a new driver system, that will make easier to hardware vendors release drivers that will be compatible with any kernel of 3.x series… It will help the adoption of linux in desktops computers…
taht would be nice. at least an abstraction layer. and a stable driver interface would be nice as well.
“The 2.6 kernel, expected to be released by late next month”
I’m not sure where he gets his information from but I highly doubt it will be out in June. Doing everything listed in 2.6 To Do list will take several months. http://kerneltrap.org/node.php?id=642 There are still lot of seldom used drivers that don’t compile right now.
If I was to bet money on it, I’d put it on September… Maybe August if I’m in a gambling mood.
Xfree86 window resizing without tearing, here we come!
What makes the dev linux kernel’s so advanced? When people talk about features, I often hear a BSDer saying ‘that’s already been in *BSD for years’.
What makes the upcoming Linux 2.6 so special, other than the number of available drivers?
If Linux kernel makes such leaps in progress… might one expect a distro that is good to enter the market within the next couple of years then?
Do you believe everything you hear on the internet Chuck?
I won’t claim to know anything about BSD, but I do know that if you take a peek at some changelogs on linux.org you’re questions will be answered.
it will answer all your questions and excit you a lot…I read it twice already 🙂
well, there’s also the summer to consider – that’s normally developer downtime.. I would put my money on 2.6 in late August.
What makes the dev linux kernel’s so advanced? When people talk about features, I often hear a BSDer saying ‘that’s already been in *BSD for years’.
dont believe it, BSD is way behind linux in many areas. Its just now getting thread support! hahaha BSD folks would like you to believe, but just try BSD out yourself, then try linux out. You will notice a difference I guarantee it.
Want a list of features? Go http://kernelnewbies.org/status/latest.html>here HERE” rel=”nofollow”>http://www.codemonkey.org.uk/post-halloween-2.5.txt>HERE</a&g…
Its just now getting thread support!
I’ll just respond to this. FreeBSD has had thread support for a while, however, a thread can only run on the same processor as it’s parent (mysql on freebsd < 5.0 can only take advantage of one CPU at a time, regardless of how many the box actually has). This was meant to be fixed in 5.0 and I believe it has been (more or less).
no need to turn it into FreeBSD vs. Linux everytime there’s an article about either.
I’ll be happy to see 2.6 when it hits, sounds like it’s going to iron out a lot of the problems with 2.4 and advance the system to the next level. I’ll also probably continue to loove FreeBSD, because Linux’s major problem to me has never been the kernel… even though I’ve always felt the FreeBSD kernel is more responsive.
dunno, but it’s great that Linux is making such progress.
The FreeBSD kernel has in fact been far ahead of Linux in many areas for years. For some examples, FreeBSD has had a better VM implementation, better event notification, and better performance under load (not sure of the reasons). The FreeBSD VFS is also better in the sense that it supports extra filesystems with fewer work arounds.
Linux has historically had better SMP, I think it’s more modular in design, and of course has a larger set of drivers. However, BSD has had many drivers before Linux, such as USB (BSD had it long before Linux) and ATA raid (Linux only supports it via 3rd party drivers).
The recent FreeBSD 5.x kernel and the Linux dev kernel are about on par for most features. Linux has finally gotten a good VM, it has an O(1) schedular (FreeBSD already has this or soon will), both have much improved thread support, and the new FreeBSD SMP implementation is design wise on par or better than the Linux SMP implementation.
In any case, it’s great that Linux has gotten these new features, but calling it the most advanced open source kernel is just a bit too much chest beating in my opinion.
does it have perfect scalabiliy? Linux dev does.
if FBSD has that then the only way the can pull ahead is to have a better SMP afinity by making the spinlocks shorter in duration than Linux dev has but that will be hard to beat as the Linux system is pretty good since the rewrite.
Remember FreeBSD is the complete system not just a Kernel like Linux is. Both Kernels have their good points and bad points.
“if FBSD has that then the only way the can pull ahead is to have a better SMP afinity by making the spinlocks shorter in duration than Linux dev has but that will be hard to beat as the Linux system is pretty good since the rewrite.”
I think you missed my point. I wasn’t trying to say that FreeBSD is better than Linux in every respect. I was also not trying to say that Linux was better than FreeBSD in every respect. I was pointing out that both systems have merets, and both have been ahead in different areas at different times. It’s always good to look at new developments in perspective with existing technologies.
The new Linux kernel will be very good. I can’t comment on whether is will scale better than FreeBSD, it may well do. But it’s also not going to blow anything out of the water. FreeBSD was stronger many of the ways I pointed out. Linux will have caught up with FreeBSD in areas where FreeBSD happened to be ahead. It may even surpass it in some of these areas. In other areas such as kernel events and the VFS layer, FreeBSD will remain ahead. Maybe FreeBSD will catch up with Linux on the modularity front in the future. Who knows.
The new Linux kernel is a very good achievement. Linux users should look forward to this. It will make quite a difference to the feel of the kernel.
Someone in an earlier post mentioned device drivers. Are developers working on a uniform driver interface for Linux?
This is IMO the most important issue stopping Linux from being more widely adopted. We need to allow hardware manufacturers to write drivers that will work thro an entire kernel version (say all 2.6) and preferably into the next major version.Drivers should also work on older kernel versions so that users with say a 3 year old distro can use them.
We also need a standard,easy way for users to install drivers. Im not talking about automatic device detection here either. What i would like to see is a situation like the following.
*John Smith goes and buys himself a brand new ACME USB digital camera with built in toaster and DVD player.
*The device comes with a CD or floppy disk and some simple instructions
*The instructions tell him to install his new hardware,boot up his Linux system and insert the CD
*He then runs a command that reads the CD-the CD contains an information file that tells the Linux distro about the hardware and also contains the device driver file for the hardware.
*The setup file on the CD loads the module which then checks to see that the hardware is actually there and if so loads itself into memory,creates the appropriate device nodes and activates the hardware
*It also asks the user if they would like to load the device driver on startup and if so it makes the necessary changes to the startup files.
Is this all so difficult? I think not
I keep getting a 404 when clicking the link. Does anyone else?
I do too.
the second part isn’t really something the Linux guys can do, so that should be more or less directed to distributions, the LSB project and possibly freedesktop.org. fixing the first problem would probably help this a lot, though. most of this stuff could actually be done now, but the hardware vendors would have change the process for each distribution(possibly even the same distro, different version).
loading modules at startup alone is done quite a few different ways… /etc/modules, /etc/modules.autoload, /etc/rc.d/rc.modules, /etc/modules.conf, etc(I know there are more, haven’t touched a few distros in years.).
if LSB(or whoever) could get this type of thing hammered out, it would help out a lot. a common database for installed software(or even compiled software, if feasible) to be registered acrossed distros would be nice, too.
It works fine here, how about try the print version?
http://www.eweek.com/print_article/0,3668,a=41227,00.asp
>The FreeBSD VFS is also better in the sense that it supports >extra filesystems with fewer work arounds.
The FreeBSD VFS ? I suggest you thake a deep look in the FreeBSD sourcecode , look for the VFS. Then compare that to the Linux VFS, and tell the FreeBSD VFS is nicer.. i dare you..
But anyway, freebsd lacks heaps that’s in atleast linux 2.5 now.. FreeBSD It just got support for large memory, but what about NFSv4, huge pagetables, journaling filesystems . (_no_ soft updates is _not_ a replacement), the SCTP protocol, hotplug cpu and other devices. Real smb/cifs support, asynchronous io, ++. FreeBSD is better in IPv6 support, I’ll give it that, but that’s about it.
Did BeOS have a better interface for driver support ? If so why did it fail ? The problem as we all know it is not Linux as much as it is OEM’s who are to scared to jump ship out of fear of garnering the anger and wrath of MS ( akak 9000lb gorilla ). I only wish the DOJ was not so pussy whipped under this administration. MS and exec’s from WorldCom, Enron, etc.. are all very lucky.
Right, some binary compatibility would be cool… Heck even binary compatibility between _minor_ versions would be nice to have.
Seeing what kind of struggles Nvidia has to go through to support all distributions is quite discouraging.
Then again I understand that it isn’t a problem for most hardware, as most of it will be included in the kernel anyway so you just install a newer kernel/distribution if you need more hardware support… Nothing beats “start your computer and it runs” anyway. For example I can install a Linux distribution without configuring _any_ hardware. Upon boot my optical mouse will work perfectly, I can play sound, network is functional and X works well in 1600×1200 with millions of colors. The only thing I need to install a custom driver for is 3D acceleration using NVidia’s installation tool (and then change a line in XF86Config).
This is _much_ better already than Windows98 where I have to install countless of drivers before I can do all that. And there is no free version of Windows which I could download from the net to get better hardware support out of the box.
Both has pros and cons, it would certainly be cool to have only the pros…
I think the performance differences (from a desktop standpoint) was far more apparent before Linux 2.4. I’m sure that under stress and high loads FreeBSD will be more responsive, but the average desktop user rarely does anything more intensive then CD burning or a 3D game. Last time I used FreeBSD as a desktop (4.8, I also tried 5.0) it seemed very similar in performance to Linux. Some areas felt faster (disk i/o, apps launched slightly faster, etc) and others felt slower (scheduler, mouse stutters, etc) but really I think their a tie. Linux 2.6 may prove to be tremendously faster then *current* (not including 5.x) FreeBSD in many, many respects. The last 2.5 kernel I ran was 2.5.65 and I noticed a perkup in several key areas. The improved scheduler meant mouse-stutters were completely gone, disk i/o improvements were *very* noticable, even my downloads seemed zippier. All in all, it felt smoother.
Once 2.6 is finalized and the FreeBSD 5.x series is stabilized and SMPng is fixed up, then I think benchmarks will be very interesting indeed. As it stands now? Linux wins in some areas, FreeBSD in others – its largely a tie.
Again, this is all IMHO.
I think it’s a bigger problem than just having a binary interface. Some parts of the kernel can not be separated out into modules, so I kernel upgrade is necessary regardless. Take nforce2 support for example, when support for that comes out you will either have to apply a patch and recompile your kernel, or download one that somebody else has done for you. Even if there was a binary interface, Nvidia could not support that chipset with proprietary drivers.
One thing I think would help would be official kernel.org binary kernels. Instead of supporting 50 distros… a driver installer disk could support say 20 kernel versions (as it is with the current 2.4 tree)…
I think big projects producing official distro independent _binary_ packages would be great. Official GNU glibc, and official KDE… known to work with eachother…providing backwards compatibility when interfaces change… It would encourage people to work together for binary compatibility, as people would be attempting to grab packages from all different sources and trying to get them to work together. Then when a vendor releases a program for GNU/Linux, they can specify “compatible with offical GNU/Linux packages”.
Thanks. It turns out the site was down for maintenance.
The FreeBSD VFS is also better in the sense that it supports extra filesystems with fewer work arounds.
Really? From what I’ve read, the Linux VFS is in much better shape than that of the BSD-derived systems, mostly due to the work done more or less entirely by Linus’ favourite code monkey, Alexander Viro.
The recent FreeBSD 5.x kernel and the Linux dev kernel are about on par for most features. Linux has finally gotten a good VM, it has an O(1) schedular (FreeBSD already has this or soon will), both have much improved thread support, and the new FreeBSD SMP implementation is design wise on par or better than the Linux SMP implementation.
Uhm, you are overlooking one rather important point, namely that on the Linux side there are proven implementations _today_, whereas on the FreeBSD side it’s still work in progress (after several years, I believe work on both KSE and SMPng started in 2000), and nobody really knows how it will stack up when it finally gets done. I think that’s a significant difference.
[switching the order some]
> I use and love both. They are excelent products.
> If you don’t like linux, don’t use it.
> If you don’t like *bsd, then, don’t use *bsd. Period.
Agreed.
> Stop this freebsd vs. linux flamewar…
Hmm. Actually I thought we *wanted* competition. Even “my kernel is better than your kernel” isn’t totally wasted if the latter improves their kernel to compensate as a result of hearing the taunt. While constructive criticism is definitely better, I think there is plenty of evidence that alot of the linux “hype” (which hopefully pushes for better software) *is* due to anti-Any-Given-Other-OS sentiment.
Not that I’m encouraging useless flames. But since I found most of the “flame” comments here to be at least somewhat descriptive about what is good, bad, or different, I see no reason to stop it.
pj
(change spam@ to pj@ for email)
Hardware manufacturers have every opportunity to write drivers for the kernel and submit the patches to have them integrated into all Linux distributions world wide. Because of their ignorance of the GPL or the methods Linux uses to distribute software they are missing out and causing their customers a lot of undue stress and frustration.
That is no fault of Linux and I see no reason why Linux should cater to the needs of ignorant capitalists. However, since I’m sure all of you disagree, I’m sure they will give you a stable API to hold your hand and help you write your precious drivers.
I dislike any corporation today that does not give away code or documentation to the XFree86 or kernel projects to have their hardware supported by Linux. Specially when they complain about not having compatibility between kernels.
I mean, don’t you have a write a new driver for each release of windows? How is this any different? I’m sorry there are 4 or 8 times the number of releases. Learn how to keep up or get out of this fucking business.
I hate capitalism.
Like other people mentioned, the only good solution for OEM’s is to provide GPL or BSD source for their hardware (or docs at the very least).
Drivers get integrated very easily in Linus’s kernel, even when the code quality of the drivers isn’t up to par with the rest of the core kernel – the idea is that some crappy support is better than none.
Now a “stable ABI” people are clamoring for is a bad idea: whenever new tech come out for driver support, the driver gets altered. This happens more than you think – devfs, hotplug, sysfs, and other changes to the core kernel required the drivers to be rewritten. If you have no source you cannot do this.
A stable ABI is a promise you won’t make any major change to the ABI. It’s a promise they can’t and shouldn’t keep – it’s the mallability of Linux that is its greatest strength: I agree with Linus’s stance on “directed evolution”. They try _all_ (sane) approaches and see what works best – which is the one that survives and displaces the other solutions. See the VM stuff that happened, with the traditional VM vs rmap VM (vs some experimental stuff going on right now). See EVMS vs LVM. See devfs vs udevfs vs smalldevfs. Or even pcmcia-cs (the old hotplug system for PCMCIA) that got replaced with hotplug for cardbus AND for PCMCIA in 2.6.
If they did make the promise of a stable ABI, they’d have to drag cruft along, and would definately not be able to progress so quickly. Imagine someone had a binary-only driver from a HW manufacturer that’s now out of business, and expects it to work with the next version. the Linux devs would have to carry around alot of crufty infrastructure – bloat, extra complexities, untested code paths, and general crappiness ensues.
Binary-only drivers are a bad idea on Windows (you can’t believe how much hardware I found with no drivers for win2k+ because it’s “unsupported” or “end-of-life”) and it’s a bad idea on Linux too for that and more.
Really? From what I’ve read, the Linux VFS is in much better shape than that of the BSD-derived systems, mostly due to the work done more or less entirely by Linus’ favurite code monkey, Alexander Viro.
The Linux VFS code could quite well be nice. I’m only going by mailing list discussions. I was specifically refferring to the, I suppose you could all it an API. *Supposedly* it’s easier to port filesystems to the FBSD API. I understand SGI had to jump through quite a few hoops to get XFS running on Linux. From the discussions I’ve heard this would not have been the case if they had ported it instead to FreeBSD. Perhaps the Linux VFS has improved since then?
Uhm, you are overlooking one rather important point, namely that on the Linux side there are proven implementations _today_, whereas on the FreeBSD side it’s still work in progress (after several years, I believe work on both KSE and SMPng started in 2000), and nobody really knows how it will stack up when it finally gets done. I think that’s a significant difference.
That’s true, I’m not arguing that Linux has always had better SMP. It has, but FreeBSD is catching up. On the flip side the FreeBSD VM has always been better than Linux’s. Now Linux is catching up in that regard. But currently 2.6 is still a dev kernel.
I completly agree with posters here who want a stable kernel driver interface at least through say a 2.6.x branch. It would really allow companies with binary only drivers to start better supporting Linux. And let’s face it, if Linux is to become a mainstream desktop OS, it needs to support proprietary software equally with open source.
@Debman: There is no such thing as “perfect scalability.” Linux still can’t compare to Solaris and IRIX in this department, though it’s getting better. FreeBSD is a good deal behind Linux in the SMP department. It’s design is solid, but the implementation has a long way to go.
There will probably never be a stable binary kernel API. Why? Because it would stagnate the design. The kernel driver API changes dramatically every few releases. The Linux development process is just different than standard commercial development process. A company can go ahead and spend a given chunk of time to plan out a binary interface that they’ll maintain for a certain number of years. The Linux kernel follows a more evolutionary model, and can’t really afford to be tied down by backwards compatibility. The Linux model has the advantage that advances come very quickly (note all of the fundemental improvements in 2.5) but has the disadvantage of being rather hard to track.
You can’t just tie a brick to the kernel devs and blindly follow how everyone else does their driver model. The correct soluation involves taking into account the characteristics of the environment, and designing a solution around that. VMWare and NVIDIA’s soluation isn’t all that bad. Basically, they have an open source component to their drivers. At installation time, the installer automatically detects the kernel version, and recompiles the driver (without user intervention) for the running kernel. This keeps their maintainence to a minimum (source-level interface changes aren’t all that common) and keeps flexibility to a maximum (independent developers can patch the open source component for situations such as where the user is using an unsupported development kernel). Most of all, it’s not any harder for a user to run an installer that compiles something in the background than to run one that doesn’t.
The Linux VFS code could quite well be nice. I’m only going by mailing list discussions. I was specifically refferring to the, I suppose you could all it an API. *Supposedly* it’s easier to port filesystems to the FBSD API.
Ah yes, I’ve read exactly this as well, but the reasoning was that the Irix VFS is (supposedly) BSD-derived and not that the BSD VFS is inherently easier to work with.
Why can’t they stabilize the ABI periodically? Let’s say that from kernel 2.4.0-2.4.5 it doesn’t change? Six months or so of stability would be of great benefit to the suppliers of binary-only drivers or of modules yet it wouldn’t still allow for major periodic changes.
By the way, I can’t believe that someone said that vendors have to write drivers for every release of windows – yes, it’s true but major releases of windows are usually years apart and, with WDM ( Windows Driver Model), it’s possible to write certain types of drivers that run on XP, 2000 and 98/ME.