Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux 2.6.17 Released

ScuttleMonkey posted more than 8 years ago | from the spit-shine dept.

444

diegocgteleline.es writes "After almost three months, Linux 2.6.17 has been released. The changes include support for Sun Niagara CPUs, a new I/O mechanism called 'splice' which can improve the performance greatly for some applications, a scheduler domain optimized for multicore machines, driver for the widely used broadcom 43xx wifi chip (Apple's Airport Extreme and such), iptables support for the H.323 protocol, CCID2 support for DCCP, softmac layer for the wireless stack, block queue IO tracing, and many other changes listed at the changelog"

cancel ×

444 comments

Sorry! There are no comments related to the filter you selected.

linux (2, Funny)

Anonymous Coward | more than 8 years ago | (#15559926)

But does it run linux ???

Re:linux (-1, Flamebait)

RLiegh (247921) | more than 8 years ago | (#15560068)

Judgeing by my experience with the 2.6 kernel (on myriad machines) the answer would have to be...probably not!.

Linux has become crapware; I'm off to *BSD.

Really helped (4, Interesting)

drsmack1 (698392) | more than 8 years ago | (#15559927)

I have this now installed in my dual core AMD and the difference is noticable. X is noticable faster, as is my video editing stuff. Good work guys!

Video Editing? (0, Flamebait)

conner_bw (120497) | more than 8 years ago | (#15559938)

Video editing... using what application?

Re:Video Editing? (2, Funny)

Anonymous Coward | more than 8 years ago | (#15559947)

Final Cut Pro on OS X is my guess, at least if he's doing anything new and interesting. It's widely known that Windows- and Linux-based nonlinear editing tools are designed for accountants and squares.

Re:Video Editing? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15559951)

"Final Cut Pro on OS X is my guess"

uh... How on earth would a linux kernel upgrade improve OS X performance?

Re:Video Editing? (0)

Anonymous Coward | more than 8 years ago | (#15559959)

It would greatly improve performance (especially for a server) if you could get all the propriety OSX stuff to run on top of it.

Re:Video Editing? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15560049)

Like using MOL (Mac-On-Linux)?

get with the program (0, Redundant)

r00t (33219) | more than 8 years ago | (#15560097)

Dude, Linux makes everything better!

Re:Video Editing? (0)

Anonymous Coward | more than 8 years ago | (#15560122)

Ever heard of a little program called Avid?

Re:Video Editing? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15560010)

My guess is that the application was editing a video of him and his buddies fucking each other up the ass and other assorted fag happenings while talking up the praises for Linux Cornhole. At least that's my guess.

BTW: Linux is STILL for fags.

Re:Video Editing? (0)

Anonymous Coward | more than 8 years ago | (#15560038)

wow you have nothing better to do with your life......

me and jesus pity you..

Re:Video Editing? (1, Funny)

daft_one (532587) | more than 8 years ago | (#15560043)

*Jesus and I* pity your grammar. ;-)

Re:Video Editing? (1)

gid13 (620803) | more than 8 years ago | (#15560021)

Transcode maybe? Shrug.

Re:Video Editing? (5, Informative)

Anonymous Coward | more than 8 years ago | (#15560101)

Insightful? How about Kino [kinodv.org] or Cinelerra [cinelerra.org] or Lives [sf.net] or Mainactor [mainconcept.com] ?

Re:Really helped (1)

A Nun Must Cow Herd (963630) | more than 8 years ago | (#15559942)

With the video editing, is it just that the UI is more responsive?

Re:Really helped (0)

Anonymous Coward | more than 8 years ago | (#15559965)

Slightly OT, but have Linux and Schilling decided to let cdrecord work right when acting as an IDE device yet? Last I checked, it's still been broken since 2.6.8

Re:Really helped (2, Insightful)

jnik (1733) | more than 8 years ago | (#15560148)

My opinion: Linus has; Schilling refuses. Slightly closer to "fact": DVD-R Tools [arklinux.org] works.

Re:Really helped (0, Troll)

Toveling (834894) | more than 8 years ago | (#15559967)

Let me guess.. Snappier?

Great, how about stable firewire support someday? (0)

Anonymous Coward | more than 8 years ago | (#15560111)

Firewire still sux on linux.

When will it work?

Re:Really helped (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15560142)

Do you have dual graphics cards in SLI ? Does it place both cards in the correct
root PCI bridge when you do a 'lspci -t' ?

amazing this is quite good improvement (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15559929)

Wow this is quite amazing - first post on slashdot.org. I can't wait to try this kernel on my box

First (-1, Flamebait)

charles ester (983483) | more than 8 years ago | (#15559930)

First.

Re:First (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15559937)

First.
Fourth, actually.

Welcome to Slashdot! (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15559944)

First post on /. [slashdot.org] and get it marked as flamebait... I hope you learn fast. Anyway... Welcome aboard! :)

what (2, Funny)

Anonymous Coward | more than 8 years ago | (#15559936)

is this for computers?

Why support Apple hardware? (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15559943)

Are they supporting Apple hardware to try to win a few of the fag crowd over? Or is it just some PC bullshit to show that they can get along with homosexuals too?

Re:Why support Apple hardware? (0)

FragInc (931710) | more than 8 years ago | (#15559971)

"My computer sucks and I don't know how to fix it so let's redirect everyone's look somewhere else besides me." or maybe it is just, "Look at me, look at me!"... either way, you are pathetic... if it were not for the guys that continuously hack the code for this OS then we wouldn't continue to have this excellent OS, we'd all be M$ pawns. BTW, Mac OS X is a Unix-based OS so it really shows how well you know what you're doing. :-/ Great job Kernel hackers, the work is appreciated here, TY!

Re:Why support Apple hardware? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15559988)

if it were not for the guys that continuously hack the code for this OS then we wouldn't continue to have this excellent OS, we'd all be M$ pawns.

Oh, yes, if we didn't have another Unix ripoff we'd all have to run windows... go blow it out your ass. there are more than 2 choices in x86, beyotch.

BTW, Mac OS X is a Unix-based OS so it really shows how well you know what you're doing.

Fag, don't think for a second that I didn't know that. What does that have to do with Linux anyway? Frankly you're one of those Linux fags who takes themselves WAY too seriously, Look at the number of "off topic" modded posts... if you can't sit there and say (honestly) to yourself "damn, these people have no sense of humor" than it just goes to show you really need to get that bug out of your ass.

Get a fucking life you fucking bitch loser.

BTW: We're all laughing at you.

You're such a square. (-1, Flamebait)

Pink Tinkletini (978889) | more than 8 years ago | (#15560019)

Hey, PC user! If you're too uptight to enjoy the occasional cock in the ass, do the world a favor and kill yourself. I know I would if I were half as beige as you.

Re:You're such a square. (1)

pembo13 (770295) | more than 8 years ago | (#15560146)

Interesting comment. I hope you don't reproduce.

Nice (-1, Redundant)

agentdunken (912306) | more than 8 years ago | (#15559950)

Nice new update but i'm going to stay with 2.6.16.. Working great for me so really no need to upgrade.. I'll wait till 2.6.20 comes out then I will update.

Wow (-1)

Anonymous Coward | more than 8 years ago | (#15559956)

That is the dumbest comment I have ever read.

Re:Wow (0)

Anonymous Coward | more than 8 years ago | (#15559987)

Im guessing some kid from Neowin trying to play with the grown ups. Certainly reads a lot like the comments over there. Single line comments of 'Interesting..', or 'This sounds good, what is it?' etc.. dumbfucks.

Re:Nice (5, Funny)

Frogbert (589961) | more than 8 years ago | (#15560113)

2.6.16! You're crazy. I'm still holding back on 2.4.10 until the dust settles.

Re:Nice (1)

x2A (858210) | more than 8 years ago | (#15560136)

2.4.10... ahh, that brings back memories... that one rocked!

Question for the masses. (3, Interesting)

SynapseLapse (644398) | more than 8 years ago | (#15559953)

I'm still pretty new to the Linux scene (So far I've done a FreeBSD, Ubuntu and Fedora Core 4 installation.), but I do have a question.
Why are the network drivers part of the kernel? It seems like this would make it more difficult to adopt newer hardware types. Also, since most computers have 1-2 NICs at the most, wouldn't that clog up the kernel with tons of drivers for hardware you'll never use?

Re:Question for the masses. (5, Informative)

shird (566377) | more than 8 years ago | (#15559963)

Modules... Only the modules (read: 'drivers') that are needed are loaded. It needs to be in the kernel because it accesses the hardware (the net card) at a fairly low level.

module shotguns (1, Interesting)

SuperBanana (662181) | more than 8 years ago | (#15560088)

Modules... Only the modules (read: 'drivers') that are needed are loaded.

Many a linux distribution I've used (most noticeably Debian) applies the "shotgun" approach to module-loading because the hardware detection and hotplug methods are so convoluted and undependable. Kind of defeats the purpose of loadable modules if the distribution simply loads everything under the sun to see what sticks.

Worse, many modules aren't smart enough to determine "hey, I'm a driver for [some non-removable component]. If I can't find my hardware, maybe I should print an error to ksyslogd and unload myself."

Re:module shotguns (0)

Anonymous Coward | more than 8 years ago | (#15560116)

Do you even understand what you are talking about? The base kernel in debian is meant for a wide compatibility base.

Stop being a bitch and go compile your kernel for YOUR machine, it's pretty easy.

Re:Question for the masses. (1)

Sancho (17056) | more than 8 years ago | (#15559969)

First, I'll get a nitpick out of the way: FreeBSD is not Linux.

Second, usually you don't want to compile every driver into the kernel, so you wouldn't get that clutter. Best case scenario, you compile in only the specific driver you'll need. Worst case, you compile them as modules and load them at runtime.

Re:Question for the masses. (1)

grasshoppa (657393) | more than 8 years ago | (#15560009)

Best case scenario, you compile in only the specific driver you'll need. Worst case, you compile them as modules and load them at runtime.

I think you've got that mixed up. Unless you enjoy recompiling the kernel every time the hardware changes.

Re:Question for the masses. (3, Insightful)

Anonymous Coward | more than 8 years ago | (#15560059)

Okay, so how frequently do you feel the need to swap out NICs, sound cards, video adapters, or anything else?

In the grandparent's instance, his hardware may not change for months or years on end because, well, he dosen't want to shut his computers or servers down to experiment with random hardware... Because of this, it might make sense for him to compile the drivers directly into the kernel for a tiny boost in performance and memory utilization... That would make sense for embedded computers, too obviously, and it might be a desireable thing to do.

For everyone else there are modules, drivers that the kernel can load automatically for hardware that it automagically detected, and it won't load drivers for devices that aren't detected or drivers that the kernel wasn't specifically directed to load. From a user perspective, you can have ALL of the driver modules compiled and most will just eat up a few megs of space in /usr, and everything will work the way it's supposed to, so it's worth eating up a few megs of drive space to be compatible with most everything Linux supports.

Re:Question for the masses. (0, Redundant)

DemonThing (745994) | more than 8 years ago | (#15559986)

FreeBSD is not Linux.

Re:Question for the masses. (1)

TheDreadSlashdotterD (966361) | more than 8 years ago | (#15560029)

I suggest you look at the reply by Sancho in order to understand the fine art of "answering the f'ing question".

The poster said they were inexperienced to the scene, but that didn't stop you from posting the obvious and not answering the question. If the first response to people is "that is not this" and nothing follows after that fact, then please don't respond. It will help the community far more than your petty bull.

If you think I'm harsh, read my sig a few times.

Re:Question for the masses. (1)

akulbe (625876) | more than 8 years ago | (#15559990)

This is why you have the ability to recompile the kernel, and customize it for your hardware set. You are right, there are many drivers in the kernel. However, you can recompile the kernel and remove all the other stuff that you don't need.

Re:Question for the masses. (0, Troll)

reklusband (862215) | more than 8 years ago | (#15559996)

It's that way because Linus says so. No matter whether there are good or bad reasons behind that, Linus says so and because Linus says so, you're FREE (as in freedom)

Re:Question for the masses. (1)

reklusband (862215) | more than 8 years ago | (#15560066)

Hey mods, this is not trolling. This is the opinion of an experience user who has noticed that it doesn't matter whether a thing is done for the right reasons in Linux, it's still done because at the end Linux is directed by Linus. Which is NOT freedom, but close.

Re:Question for the masses. (5, Interesting)

caseih (160668) | more than 8 years ago | (#15560020)

Even under windows drivers load into the kernel and normally become part of the kernel proper. Things under linux are similar, but differ from Windows in very important ways. First of all, the overriding philosophy behind the linux kernel is the GPL (well a modified version of the GPLv2) license for the source code. This states that the source code for the kernel and parts of the kernel should always be available. Also, for philosophical reasons associated with the licensing issue, Linus has said that he does not care as much about a binary stable driver API (ABI) in the kernel. Since the source code to the kernel is always available, if you want decent drivers, they should be placed in the kernel source code tree, since drivers really ought to be free and open. Unfortunately this means that a binary kernel driver from one version of the kernel may not work on another. This is done partially to encourage open source drivers and partially to prevent the kernel developers from being tied to design decisions that later prove unwise. But this does pose a problem for folks that want to implement their own third-party drivers in a propriety fashion. NVidia writes a special open source driver that implements a special, stable ABI that it's proprietary, closed-source video driver talks to to overcome this.

Many have argued that Linus needs to stablize the kernel driver ABI. But on the other hand, by not doing so and encouraging drivers to be open source and in the kernel source tree brings us a large amount of stability that Windows just cannot achieve. Most windows stability problems are not caused by the kernel, which is as stable as Linux, but by third-party device drivers. Anyway it is a trade-off, and one that is hotly contested. Personally, everything I currently use has open source drivers that come with my kernel bundle (Fedora Core). They are loaded on demand, so they don't cause memory bloat. If I was to compile my own kernel, I could choose not to build many of the drivers, reducing the disk bloat too.

One of the biggest things for me in this kernel release is the Broadcom wireless driver. Kudos to the team that clean-room reverse engineered the driver.

Re:Question for the masses. (4, Interesting)

drsmithy (35869) | more than 8 years ago | (#15560093)

Many have argued that Linus needs to stablize the kernel driver ABI. But on the other hand, by not doing so and encouraging drivers to be open source and in the kernel source tree brings us a large amount of stability that Windows just cannot achieve.

It's worth pointing out that pretty much every remotely mainstream OS *except* Linux manages to work (and work well) with a stable kernel ABI. Including ones considered at least - if not more - stable than Linux, even by Linux zealots, like FreeBSD and Solaris.

Re:Question for the masses. (3, Insightful)

hcob$ (766699) | more than 8 years ago | (#15560023)

2 options:

1:
Compile everything you need for your machine to run into the kernel... no more, no less... then you're good to go. No clutter, no loading at runtime... nothing.

2:
You have no idea what you actually need past boot(and root) FS, cpu, and hard drives. Compile everything else as a module(driver) to be loaded when you need it, and voila, no bloat to the kernel, but a few dozen MBs taken up on the HD.

In the grand scheme of things, a few extra modules for network cards will cause you no trouble. And for reference, most Enterprise level computers have upwards of 4-6 network adapters. Wonderful for redundancy and resiliancy.

I'll leave you with one bit of parting advice:
Assuming a minimum configuration on any OS leads you down the path of Microsoft. Knowing your hardware and tweaking it yields unprecidented pride and performance... as well as a unwarrented self importance. The more you learn about OSes... the more you see they are all alike.

How many Network Adapter Cards in a server? (1)

billstewart (78916) | more than 8 years ago | (#15560118)

Most enterprise-class servers that have N network cards in them don't have N different _types_ of cards - they've got N cards of the same type, or maybe N-1 of the same and one of a different type (e.g. a GigE and N-1 100Mbps cards.) So you only need one or two different drivers.

Laptops these days usually have two types of network interfaces - one wired and one wireless. Occasionally you'll have different types of wireless cards to plug in, e.g. an 802.11a vs. .11g or something.

Microkernel anyone? (4, Informative)

argoff (142580) | more than 8 years ago | (#15560051)

Why are the network drivers part of the kernel? It seems like this would make it more difficult to adopt newer hardware types. Also, since most computers have 1-2 NICs at the most, wouldn't that clog up the kernel with tons of drivers for hardware you'll never use?

This is the essence of the Microkernel debate. http://en.wikipedia.org/wiki/Microkernel/ [wikipedia.org] The truth is that the Microkernel model probably is a better design, but in terms of when the Linux kernel was starting out - its implementation simply wasn't pratical. It didn't help that the people who thought they knew how to build a better kernel decided to try and intellectually brow-beat Linus into doing it instead of implementing it themselves and putting it under the GPL. This led to a lot of bitterness and resentment between the two camps. The HURD http://en.wikipedia.org/wiki/Hurd [wikipedia.org] project is a GPL microkernel project, but it simply wasn't managed as well as Linus managed Linux.

I think over time, things eventually will move to a microkernel model even though there are other ways to emulate some of their security and flexability benefits - like xen http://en.wikipedia.org/wiki/Xen [wikipedia.org]

Re:Microkernel anyone? (4, Insightful)

ArbitraryConstant (763964) | more than 8 years ago | (#15560152)

Why are the network drivers part of the kernel? It seems like this would make it more difficult to adopt newer hardware types. Also, since most computers have 1-2 NICs at the most, wouldn't that clog up the kernel with tons of drivers for hardware you'll never use?
This is the essence of the Microkernel debate.
It has nothing whatsoever to do with the microkernel debate. The two issues are completely orthogonal to each other. The microkernel proponents claim the driver should be a process running outside the kernel, which has nothing to do with the number of drivers you have sitting around, or how difficult it is to adopt newer hardware types.

Either way, you've got a ton of drivers sitting around that you'll never use. They don't clog up the kernel, since the kernel image rarely contains many drivers. Instead, most Linux distros use modules that get loaded as needed. On a microkernel, they would be driver binaries that would get run as needed. They clog things up to exactly the same extent; they sit around on the hard drive doing nothing.

Either way, it's hard to add new drivers to old kernels. This is not a result of the fact that drivers are in the kernel, but of the fact that Linus refuses to use a stable driver API. This would preclude driver compatibility between versions just as effectively on a microkernel as it does now.

As I said, the two issues are unrelated.

Re:Question for the masses. (2, Informative)

billstewart (78916) | more than 8 years ago | (#15560077)

So you've learned what RTFM means by now? :-) Ok, it's been a while since I've read up on kernel structure either.... but you _should_ do so. Linux is rather famously [coyotos.org] not a microkernel architecture [oreilly.com] that lets you partition off little pieces into user space - it's a big honkin' kernel plus loadable modules that let you add even more things. There are hardware-dependent and hardware-independent parts of the kernel. Device drivers inherently hardware-dependent, and sharing address space with the kernel makes it easier to do things like DMA without having to do a lot of data copying.

As far as network drivers in particular go, the layers that use them, such as IP, live in the kernel, so it's rather annoying for them to talk to drivers that are up in user space. Specific network cards, especially wireless, might have bits that live up in user space, such as user interfaces for loading in crypto keys, but the bulk data transfer applications normally belong down in or near the kernel.

Why are there a whole pile of network card drivers in the kernel when you'd normally use only one or two? Same reason there are a whole pile of drivers for other devices in the kernel, when you've normally only got one graphics card and one sound card. If you're shipping a pre-compiled kernel, you want it to support as many different users as possible, and all it costs you is some RAM to store the code you're not using, or if you can handle them as loadable modules, it only costs you the work to keep track of those. But if you want to compile your own kernel for specific machines, and leave out the drivers you don't want, and while you're at it compile all your applications programs with the level of optimization your hardware supports, get a copy of Gentoo Linux [gentoo.org] and have fun learning lots more detail about Linux internals.

Re:Question for the masses. (1)

WindBourne (631190) | more than 8 years ago | (#15560079)

Hold on there. First off, nearly all drivers are dynamically loadable or can be compiled staticly into the kernel. Offhand, I can not think of a general purpose set-up where they are compiled in EXCEPT for the initial loading (as well as the boot from a cd deals). That means that most of the running kernels use dynamic kernels. Now, which ones are loaded? those that are needed. Sometimes a few extra, but rarely.

Now, as to the network, it is divided into a number of sections (hardware drivers vs. logical handlers for various protocols (ethernet, arc, ipv4, ipv6, etc)). Generally, these are loaded as needed (normally based on boot-up info in /etc).

All in all, the running linux kernel is pretty skinny (WRT to modules).

Re:Question for the masses. (1)

Neptune0z (930626) | more than 8 years ago | (#15560098)

Basically...The reason is just because... This is the way it's pretty much always been done, it's called a monolithic kernel. In this type of OS design everything that's deemed important to proper functioning is all tossed together into basically one big area of memory. This has it's advantages (simplicity of code for one thing) and disadvantages (not very fault tolerant). The alternative is a microkernel. Where only bare essentials are part of the kernel, and everything extra runs in it's own low-privilaged virtual memory area...I know im probally gonna get flamed for this, but who cares it's just my opinion anyway, but I beleive that microkernels are the future of OS's everything else will just be crap...

Go Linux! (4, Insightful)

Umbral Blot (737704) | more than 8 years ago | (#15559954)

It's good to know that even in this day and age of faster and faster computers there are still people who care about speed and efficiency instead of simply waiting for hardware to solve their problems for them. I do have one tiny complaint though, and it is that some of the performance gains are only possible by using new system calls. This is bad for three reasons:
1- More work for developers, some of whom may never learn about these faster calls.
2- Old applications can't benefit
3- Applications that wish to be backwards compatible can't benefit
Obviously though it is necessary to write new functions on occassion; for example when the new function is worse than the old function is under some circumstances. It may be that all the new functionality is of this type, but I don't have enough information to know for sure.

Re:Go Linux! (5, Informative)

freralqqvba (854326) | more than 8 years ago | (#15559970)

sendfile(2) is now a call to splice() so programs that use the old syscall will benefit as well and without modificaiton.

Re:Go Linux! (1)

Umbral Blot (737704) | more than 8 years ago | (#15559975)

Why not just call it sendfile then? If it can take more parameters, well that is what overloading is for.

Re:Go Linux! (1)

freralqqvba (854326) | more than 8 years ago | (#15559985)

Y'know, I'm not entirely sure. I didn't follow the discussions very closely. I'm sure there's a good reason that you could find if you poked around the LKML a bit, though.

Re:Go Linux! (3, Informative)

ip_fired (730445) | more than 8 years ago | (#15560037)

The kernel is written in C, and so are those system calls. I don't believe you can overload a C function.

Re:Go Linux! (2, Interesting)

Umbral Blot (737704) | more than 8 years ago | (#15560052)

No you can't, although that fact had slipped my mind. How sad for C. The real question here then is: why isn't there a better language than C for creating OSs in? A real macro system and overloading would probably be nice for kernel dev.s everywhere.

Re:Go Linux! (2, Interesting)

ip_fired (730445) | more than 8 years ago | (#15560085)

Because C is fast, and there is so much already written in C, that it would be a pain to move over. There are a lot of hacks in the linux kernel (they actually use GOTO statements! *gasp*). I can tell you it was a real eye-opener for me when I started looking at things there. I'm sure the reason nobody has moved over to a better language though is because of the massive amounts of work that would have to be redone.

Re:Go Linux! (1)

Jack_the_Tripper (878546) | more than 8 years ago | (#15560086)

The real question here then is: why isn't there a better language than C for creating OSs in?
Perl?

Re:Go Linux! (1)

WhatDoIKnow (962719) | more than 8 years ago | (#15560130)

How could anything be better than C for writing kernels?

Re:Go Linux! (2, Insightful)

Umbral Blot (737704) | more than 8 years ago | (#15560159)

How could anything be better than flint for making arrowheads?

Re:Go Linux! (1)

19thNervousBreakdown (768619) | more than 8 years ago | (#15560156)

There are plenty, and I suppose you could write your part of the kernel in whatever language you want as long as you weren't worried about it being part of the official distribution. But even if they suddenly started allowing other languages in the kernel, and AFAIK they don't, you'd still have to write your interfaces in straight C. It's the only language that basically every other language has bindings for.

Re:Go Linux! (1)

TCM (130219) | more than 8 years ago | (#15560053)

So, will we see even more ugly hacks^W^Wapplications that won't build anywhere else than on Linux?

Re:Go Linux! (1)

freralqqvba (854326) | more than 8 years ago | (#15560108)

Well sendfile() itself has never been portable, so the situation hasn't gotten any worse with splice().

If you want to look at it negatively though, yes, non-portable syscalls will make programs that use them non-portable.

Re:Go Linux! (1)

Sharth (621005) | more than 8 years ago | (#15559982)

If a library like glibc upgrades to use the new libraries, then every program that uses that library as a non-static dependency will benefit.

Re:Go Linux! (1)

Mostly a lurker (634878) | more than 8 years ago | (#15559995)

There are two ways the new functionality can be used:
  1. by explicitly invoking the new calls directly in your program;
  2. indirectly, when the implementation of old calls changes to make use of the new functionality internally.
Thus, even old programs are likely to benefit to some extent because the efficiency of the system generally will improve.

Re:Go Linux! (1)

bersl2 (689221) | more than 8 years ago | (#15560000)

Yeah, but some are beginning to complain about stability and lack of code maintenance for parts of the kernel, due to the attention being given to new features but not old---bug fixes are less exciting and less likely to be addressed willingly.

Linux is for other devices too (4, Insightful)

EmbeddedJanitor (597831) | more than 8 years ago | (#15560026)

While the "who cares about software efficiency, the hw is getting faster" attitude might be OK for desktop PCs, it does not apply to handheld/mobile devices (which make up a huge, and ever growing, % of all Linux devices). Being able to use a slower CPU (or use a fast one very efficiently) makes for reduced power consumption == smaller devices == longer battery life. Nobody wants a cell phone with a 2 pound battery that only runs for 1 day.

Re:Go Linux! (3, Insightful)

TCM (130219) | more than 8 years ago | (#15560067)

It's good to know that even in this day and age of faster and faster computers there are still people who care about speed and efficiency instead of simply waiting for hardware to solve their problems for them.
Another way of saying this: It sucks to know that even in this day and age of faster and faster computers there are still people who cut corners and use specific hacks to gain speed instead of simply building clean and well-designed systems and let the hardware do the work.

Just saying..

Re:Go Linux! (1)

Umbral Blot (737704) | more than 8 years ago | (#15560078)

I really hadn't thought about it that way. I guess that without thinking I buy into the hacker ethic where speed and efficiency are valued above all else. However objectively you are probably right, and instead of celebrating speed I should be celebrating "today Linux reduced its code base by X-thousand lines and reduced its API by Y-hundred lines". Unfortunately no one ever seems to brag like that.

Re:Go Linux! (1)

r00t (33219) | more than 8 years ago | (#15560129)

It's a rather clean and well-designed interface. It was proposed back around the Linux 2.0 era (what, 5 years ago) but Linux wasn't ready for it yet. Over the years the idea has settled down. This isn't some off-the-wall quick hack that was dreamed up last week.

In case of slashdot, break mirror (4, Funny)

TrueKonrads (580974) | more than 8 years ago | (#15559983)

Changelog [mirrordot.org]

Diversity in advocacy (0, Offtopic)

Anonymous Coward | more than 8 years ago | (#15560002)

I've been hearing lately that there's some interest in advocating usage of open source and Linux to women. GNOME's encouragement for women coders, the Debian Women group and the currently proposed Gentoo Women groups are all a step in the right direction, but I wonder if there isn't a bigger issue to be dealt with.

For example, much of the computer wallpaper available out there contains blatantly sexist themes. Sadly, in many forums users choose avatars or use language that may make members of the fairer sex uncomfortable at best, and at worst drive them away to more professional and neutral platforms.

I can't help but wonder if the community would benefit more from passively discouraging these sort of things (by raising awareness of this issue and rejecting potentially divisive content) than it would by driving women out of the mainstream open source community into specially-marked pockets of the Internet. At least the issue is being discussed, which is certainly progress, but it will take much more time and effort to truly address the problem.

some highlights from the changelog (5, Informative)

doti (966971) | more than 8 years ago | (#15560005)

Some stuff I found interesting on the human-friendly changelog [kernelnewbies.org] .

Block queue IO tracing support (blktrace). This allows users to see any traffic happening on a block device queue. In other words, you can get very detailed stadistics of what your disks are doing. User space support tools available in: git://brick.kernel.dk/data/git/blktrace.git

New /proc file /proc/self/mountstats, where mounted file systems can export information (configuration options, performance counters, and so on)

Introduce the splice(), tee() and vmsplice() system calls, a new I/O method.
The idea behind splice is the availability of a in-kernel buffer that the user has control over, where "splice()" moves data to/from the buffer from/to an arbitrary file descriptor, while "tee()" copies the data in one buffer to another, ie: it "duplicates" it. The in-buffer however is implemented as a set of reference-counted pointers which the kernel copies around without actually copying the data. So while tee() "duplicates" the in-kernel buffer, in practice it doesn't copy the data but increments the reference pointers, avoiding extra copies of the data. In the same way, splice() can move data from one end to another, but instead of bringing the data from the source to the process' memory and sending back to the destination it just moves it avoiding the extra copy. This new scheme can be used anywhere where a process needs to send something from one end to another, but it doesn't need to touch or even look at the data, just forward it: Avoiding extra copies of data means you don't waste time copying data around (huge performance improvement). For example, you could forward data that comes from a MPEG-4 hardware encoder, and tee() it to duplicate the stream, and write one of the streams to disk, and the other one to a socket for a real-time network broadcast. Again, all without actually physically copying it around in memory.

Reality (-1, Troll)

gravy.jones (969410) | more than 8 years ago | (#15560011)

After only 3 months how can so much software be reliably tested? Is it really released or is it still beta? I thought there was a bunch of static flying around about version 2.5 of the kernel. If you build software on a broken foundation you will only get broken software. What if this software only works becuase earlier software is failing? That is a completely possible situation.

Where is 2.7? (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15560025)

A hell of a lot of this stuff seems to me to be the sort of code that should be going into the 2.7 stream, not 2.6. The earliest days of Linux had revisions X.Y.Z. If Y was even, it was a "stable" branch, and could generally be considered safe for production work. If Y was odd, it was a "development" branch, and could break things badly.

This was a major boon for Linux: if you needed the bleeding edge, you could get it, whilst acknowledging the risks in doing so. If you needed something stable, again, you could get it. Now? It seems that the supposedly stable kernel is right out there on the bleeding edge ...

Re:Where is 2.7? (0)

Anonymous Coward | more than 8 years ago | (#15560083)

That old model got dumped with 2.6.0. Instead of 2.7 and 2.6 at the same time, we now have 2.6.X-current and 2.6.X-yourdistrorelease, with 2.6.X.Y 'stable' releases trailing behind the point release, with bugfixes and cleanup, security ports etc.

So now 2.6.17.0 is unstable/dev/testing. This would be, say, 2.7.16 in the old numbering.

In a few days/weeks/months we'll have 2.6.17.2 or .3, which will have all sorts of fixes and security patches applied. This would correspond to the old 2.6.16.

This frees the developers to develop on a nice current codebase, but it also gets out to users for Real World testing in a timescale of weeks or days instead of months or years.

It's a Good Thing(tm).

Re:Where is 2.7? (1)

WindBourne (631190) | more than 8 years ago | (#15560087)

It was decided to hold off on doing a development branch. The thought was that developers would help stabilize the 2.6 work. In some areas, this approach has helped. In others, it has gotten worse.

I have compiled (0)

Anonymous Coward | more than 8 years ago | (#15560045)

the new kernel and everything feels much snappier. No spinning wheels of doom to be seen. Thank you iLinus.

support for the h.323 protocol, quite unlikely (1, Interesting)

rodac (580415) | more than 8 years ago | (#15560056)

1, there exists no protocol called h.323 There exists a h.323 standard that references protocols such as h.225 h.245 etc. but there is no h.323 protocol.

2, even more unlikely for h.323 support is that since all the important parts of h.323 such as h.225 and h.245 are all ASN.1 PER encoded.
Are they going to add a decoder for aligned-PER inside the kernel? yeah likely.

Whatever thay have added it is not support for h.323. Maybe they have added support for RTP?

Re:support for the h.323 protocol, quite unlikely (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15560073)

Wow, that's really insightful.

So you got any other things to bitch about you little whining fag?

Just go back to smoking dicks. We don't need your input here.

Had to exchange a motherboard (1, Offtopic)

kbahey (102895) | more than 8 years ago | (#15560061)

I settled on the ASUS A8V-MX as a nice inexpensive mobo for my home server.

In it I put a SATA disk. Linux would not see the disk at all, since this mobo uses a newer VIA chipset.

There is a patch for the VIA chipset in question (the forum on forums.viaarena.com has so many pages on that topic).

It was easier for me to exchange the motherboard with an ASUS A8V which works flawlessly, but require an add on video card (irrelevant for a server), 2 less SATA connectors, and a Gigabit ethernet.

Had to pay more for this one, but easier than putting in an IDE disk to build the kernel on, and then boot the SATA drive.

The patch will make it by 2.6.18.

Re:Had to exchange a motherboard (0)

Anonymous Coward | more than 8 years ago | (#15560117)

I also purchased an A8V-MX to run as a server, the soloution for me was to run Gentoo on it and compile the patch into the kernel myself. There's a link to a gentoo live cd somewhere on the VIA arena forum with support for the chipset. The Via patch had some problems apparently I tried for a long time to get it working in the Fedora kernel (so I could respin my own version of FC5) to no avail. When in doubt try Gentoo I guess.

Re:Had to exchange a motherboard (0)

Anonymous Coward | more than 8 years ago | (#15560134)

The via driver should work fine with your motherboard and HD.

Missing driver? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15560063)

I downloaded this kernel earlier in the day, and after having gone through the apparent changes, it seems like I cannot find the driver for my webcam. This webcam uses the ov511 driver - does anyone know if it was moved somewhere? In 2.6.16 (.11 is the last patch I have) it was in Device Drivers -> USB support -> USB OV511 Camera support. I'm reluctant to upgrade if this driver isn't in there - anyone have any idea where it might have gone?

Obligatory. . . (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15560071)

This article has been up for almost an hour and nobody
has posted the usual "But does it run Linux" joke?

Is this a slashdot record?

Re:Obligatory. . . (1)

Slashcrunch (626325) | more than 8 years ago | (#15560104)

Wow. Not only have you probabl not read the article, but you also have not read the comments at all before commenting?

Look right at the top... very first comment :)

Broadcom 43xx (1)

atomic-penguin (100835) | more than 8 years ago | (#15560082)

Woohoo, Broadcom 4300 drivers! I hope they work. ...I wish this had been brought to my attention before 1 A.M.

Quota BUG() fixed? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15560090)

It seems you can crash the box by hitting a race condition in the quota code. You get a "kernel bug in dquot.c" and the machine goes down - hard. One of the changelog entries seems to address this. The question is: will this get backported into the distro kernels? Red Hat, help!

Sounds good (4, Funny)

goodenoughnickname (874664) | more than 8 years ago | (#15560109)

Sounds good -- how much does it cost?

Sincerely,
The New Guy

"splice" - because Microsoft did it? (4, Interesting)

Animats (122034) | more than 8 years ago | (#15560139)

The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel. At one point, Microsoft was claiming that an "enterprise operating system" had to be able to do that. So now Linux has a comparable "zero copy" facility.

"Zero copy" tends to be overrated. It makes some benchmarks look good, but it's only useful if your system is mostly doing very dumb I/O bound stuff. In environments where web pages have to be ground through some engine like PHP before they go out, it won't help much.

The usual effect of adding "zero copy" to something is that the performance goes up a little, the complexity goes up a lot, and the number of crashes increases.

not like that (4, Informative)

r00t (33219) | more than 8 years ago | (#15560151)

This is really just a way for app code to manipulate data without needing to have it copied or memory-mapped.

Linus refused the FreeBSD-style zero-copy because it is often a lose on SMP and with modern hardware. Page table and TLB updates have huge costs on modern hardware.

If you do like the Microsoft way, use Red Hat's kernel. The in-kernel server works very well.

OK, so where are they? (1)

phorm (591458) | more than 8 years ago | (#15560147)

After reading the article, I just downloaded 2.6.17 from kernel.org (AMD64 processor desktop and a laptop with the a Broadcomm BCM4301 wifi card) I see neither a broadcomm driver in the kernel "Wireless LAN drivers" section, nor any scheduler other than:
  • Anticipatory
  • Deadline
  • Default I/O scheduler: Anticipatory, Deadline, CFQ, or No-Op


Am I missing something here? So are the mentioned changes part of a release-candidate (unstable is at RC-2) or am I missing something?

NTFS (1)

wolf369T (951405) | more than 8 years ago | (#15560155)

A better NTFS write suppport will be greatly appreciated...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>