Forgot your password?
typodupeerror

Linux 2.6.17 Released 444

Posted by ScuttleMonkey
from the spit-shine dept.
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"
This discussion has been archived. No new comments can be posted.

Linux 2.6.17 Released

Comments Filter:
  • Re:Video Editing? (Score:1, Insightful)

    by Anonymous Coward on Monday June 19, 2006 @12:05AM (#15559951)
    "Final Cut Pro on OS X is my guess"

    uh... How on earth would a linux kernel upgrade improve OS X performance?
  • Go Linux! (Score:5, Insightful)

    by Umbral Blot (737704) on Monday June 19, 2006 @12:07AM (#15559954) Homepage
    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.
  • by hcob$ (766699) on Monday June 19, 2006 @12:36AM (#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.
  • Where is 2.7? (Score:5, Insightful)

    by Anonymous Coward on Monday June 19, 2006 @12:36AM (#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 ...
  • by EmbeddedJanitor (597831) on Monday June 19, 2006 @12:36AM (#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.
  • by Anonymous Coward on Monday June 19, 2006 @12:49AM (#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:Go Linux! (Score:3, Insightful)

    by TCM (130219) on Monday June 19, 2006 @12:53AM (#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:Really helped (Score:2, Insightful)

    by jnik (1733) on Monday June 19, 2006 @01:21AM (#15560148)
    My opinion: Linus has; Schilling refuses. Slightly closer to "fact": DVD-R Tools [arklinux.org] works.
  • by ArbitraryConstant (763964) on Monday June 19, 2006 @01:24AM (#15560152) Homepage
    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:Go Linux! (Score:3, Insightful)

    by Umbral Blot (737704) on Monday June 19, 2006 @01:26AM (#15560159) Homepage
    How could anything be better than flint for making arrowheads?
  • by x2A (858210) on Monday June 19, 2006 @01:55AM (#15560227)
    What a load of crap. Firstly, the female form is a work of art (when things haven't gone horribly horribly wrong) that females can appreciate too. Secondly, unlike the things you bring issue with, the belief that women need to be sheltered, that they some how couldn't cope with a world not contrived to protect their fragile selves actually *is* sexist.

    Guys will have female wallpaper because the female form is what they like to see. In the same way, girls will often like to see a bit of masculinity (granted most of slashdot and the like is more snide bitchiness than masculinity, which maybe has more to do with it). We're programmed to be into each other, it's natural, it's normal, and despite what religious teachings would have you believe, it's not dirty or wrong. Don't treat it as though it is.

  • by argoff (142580) on Monday June 19, 2006 @02:08AM (#15560254)
    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.

    The point is not a resource usage point, but a flexability point. If you want to add a new driver or even change one, it pretty much takes co-opting the entire kernel tree, or compiling the driver live against the current kernel, or having pre-compiled modules against every possible kernel out there.

    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.

    The driver API wouldn't need to be as stable in a Microkernel design. (I'm not a kernel guru, so you may know better)

  • by dhalgren (34798) on Monday June 19, 2006 @02:10AM (#15560256)
    It is freedom. Freedom does not mean "the developers accept every suggestion and all criticism". You are free to use it, use something else, dig in there and change what you don't like, and even fork it and publish it the way you think it should be. That's freedom.

    And of course, Linus is free to do what the hell he wants. He doesn't owe us a thing.
  • by RedBear (207369) <redbear.redbearnet@com> on Monday June 19, 2006 @02:48AM (#15560332) Homepage
    Woohoo, Broadcom 4300 drivers! I hope they work. ...I wish this had been brought to my attention before 1 A.M.

    I'm somewhat shocked that nobody else has pointed out the new Broadcom 43xx/Airport Extreme support. That's the one thing that grabbed my attention in the whole paragraph. Not having support for Apple's built-in wireless hardware has been a showstopper for a lot of people to even consider trying out Linux on a Mac, especially the portables. This driver will open up several million possible new computers for Linux to be installed on, since at this point the wireless hardware was about the last incompatible piece of hardware on the Mac side. This is a very big deal for anyone with Mac hardware or anyone planning to buy a Mac, and for all the geeks who are already running Linux on their Mac.

    Very cool.

  • Re:module shotguns (Score:5, Insightful)

    by BrainInAJar (584756) on Monday June 19, 2006 @04:16AM (#15560479)
    there is still not a true, separate driver interface API.

    Sure there is. There's just not a consistent ABI, and that's on purpose.

    If you're contributing a driver, GREAT. It'll compile against the currently installed kernel just fine.

    If it's closed-source, go die. The kernel's GPL, not lGPL
  • by ookaze (227977) <ookaze@mail.ookaze.OPENBSDfr minus bsd> on Monday June 19, 2006 @06:06AM (#15560633) Homepage
    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.

    FreeBSD example then just proves that a stable ABI won't bring more drivers to Linux, thus destroying the GP argument that Linus needs to stabilize the kernel driver ABI.
  • by cab15625 (710956) on Monday June 19, 2006 @07:20AM (#15560733)
    Yeah, everybody knows that it's those lewd Sports Illustrated swimsuite calendars and foul language that keep women from becoming automotive mechanics. It has nothing to do with generations of parents/teachers/preachers telling children "boys do these jobs and girls do those."

    If you want to carry out advocacy of linux to women, then it will take more than just "clean" screen backgrounds and coming up with new terms for male and female plugs to clean up the industry language. What you should really be worried about is a society that still tries to raise it's children to think that only boys can do certain things and only girls can do certain others. What are you teaching your children to think of their abilities?

    If pictures and language are what you think deeper problems are, you should probably petition slashdot to make the pinkified april fools theme the default and then go do some ladies things.

    As for profesionalism, different industries/companies have different standards irrespective of gender. At work, I keep a blank background because that is what is acceptable where I work. At home, I put whatever I feel like. It doesn't have to become a gender issue.

    I really must learn to leave these offtopic threads alone.
  • by doodlebumm (915920) on Monday June 19, 2006 @08:39AM (#15560888)
    Mod me -4 and informative for trying to open the moderator's eyes, but this isn't even funny. Just trite!
  • by FireFury03 (653718) <slashdot.nexusuk@org> on Monday June 19, 2006 @08:39AM (#15560889) Homepage
    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.

    Also worth pointing out that much of the stability trouble in Windows is caused by shoddy drivers - FOSS drivers are traditionally more stable than closed drivers (not least because when bugs are found, people with a vested interest in fixing them will often do so rather than waiting for the manufacturer to get their finger out).

    Whilest a stable ABI may result in more drivers being made available, I fear it could lead to a lot of "Windows quality" drivers. And if closed drivers are officially legitimised, many companies will refuse to release open drivers since there is very little in it for them. At the moment, many of the open drivers are there because the vendor believes that releasing a binary driver is legally dubious at best - legitimise binary drivers and this motivation goes away.

    Anyone who's dealt with bugs in the nVidia drivers will know of the problems of closed development - I've reported bugs that have taken years for nVidia to fix which I would've been happy to try and fix myself if only the code was open.
  • Re:That and (Score:3, Insightful)

    by k98sven (324383) on Monday June 19, 2006 @12:44PM (#15562349) Journal
    Unfortunately, the higher level a language you use, the more inefficency there is.

    That's complete nonsense. What do you support that on? A higher level language is only as inefficient as the compiler and/or libraries used. Which is just as true for a low-level language.

    C is the best compramise. While assembly might give you the theoritical best code

    As someone who's actually spent some years coding assembler, I'll tell you this: Hand-coded assembler is rarely ever better. And with the developments in processors today, it's not even theoretically better. If the Linux kernel had been written in assembler, then , besides being completely unportable they'd have to rewrite the whole thing to take advantage of the 486 instruction set. Then the Pentium instruction set, then MMX and so on. Unless you're going to provide hand-coded routines for every single processor out there, hand-coded assembler is never better.

    And the whole basis of your argument is just wrong. You're assumimg that a human will always produce better assembler code than a compiler. That is not true. That's not even true most of the time.

  • Re:Go Linux! (Score:3, Insightful)

    by pclminion (145572) on Monday June 19, 2006 @01:09PM (#15562531)

    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.

    Why do you assume that all optimizations are hacks? Lifting an invariant calculation out of a loop can potentially make things MUCH faster, yet is hardly a "hack." Or how about strength-reducing "2 * x" into "x + x," is that a hack? Same goes for a change of data structures (say, switching from a linear search in a linked list to a constant-time lookup from a hash table). Are hash tables "hacks?"

    Man, I can't wait for the day when the hardware is smart enough to morph my linked lists into hash tables for me!

    I think you have no clue what you're talking about.

  • by Procyon101 (61366) on Monday June 19, 2006 @02:31PM (#15563099) Journal
    For the record though, these are *BAD* habits in C++. Use the destructor, Luke.
  • Re:Go Linux! (Score:2, Insightful)

    by pooly7 (892966) on Monday June 19, 2006 @03:05PM (#15563383) Homepage
    Actually if you are thinking about high-end server, the few % you get with optimized calls, can be translated in $ with several digits. So if you paid someone less than that number, everybody wins.

You can observe a lot just by watching. -- Yogi Berra

Working...