Slashdot Mirror


Linux 2.6.17 Released

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"

444 comments

  1. linux by Anonymous Coward · · Score: 2, Funny

    But does it run linux ???

    1. Re:linux by moro_666 · · Score: 2, Interesting

      Will ubuntu have it soon ?

      They have included much of the stuff into their version of 2.6.15.23,
      but ofcourse that doesn't have everything. The broadcom driver that came
      with ubuntu(same sources, maybe earlier version) has somesort of issues
      with my BCM4318 :( , so it just doesn't work, people claim it has something
      to do with soft interrupt stuff.

      ps. broadcom, next time make interrupts stiff.

      --

      I'd tell you the chances of this story being a dupe, but you wouldn't like it.
    2. Re:linux by ElleyKitten · · Score: 2, Informative
      The broadcom driver that came with ubuntu(same sources, maybe earlier version) has somesort of issues with my BCM4318 :( , so it just doesn't work,
      Try this.
      --
      "What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
    3. Re:linux by Anonymous Coward · · Score: 0

      More importantly, will it run on my machine?

      Probably not; damned ATI video card. I miss Linux, I loved Mandrake 6. It made me hate Windows even more, with Windows' "do it our way or you ain't gonna do it at all" and the features still missing in Windows (like having apps that were open when you shut the machine down still be open when you restarted it).

      If any of you can point me to any FMs that might tell me how to make an ATI (with S-video out, which is why I bought the damned thing) work in Linux (any distro) you'll have my appreciation.

      -mcgrew (MRC= "retarder" as in "why won't this work? I feel so retarded!")

    4. Re:linux by jdowland · · Score: 1

      Actually, yes. User-mode-linux was merged in mainline (although earlier than .17 I think)

    5. Re:linux by funfail · · Score: 1
      the features still missing in Windows (like having apps that were open when you shut the machine down still be open when you restarted it).

      Why don't you just hibernate?
    6. Re:linux by Eideewt · · Score: 1

      It probably depends on what card you have. My Radeon 9200 works well enough. I think what I had to do was install the fglrx driver (from my distro's reps.), make sure the modules agpgart, via-agp, and fglrx were loaded on startup, then, in xorg.conf, add the X.org module fglrx, select the fglrx driver, and set Option "UseInternalAGPGART" "no". I set its BusID too, although that may not be necessary. These steps may not work for you, but that got mine working.

      I haven't tried to use S-video out yet, but my guess is that you'll want to have two identical device sections, but with "Screen 1" added to the second and Option "ForceMonitors" "crt1,tv" added to the first, a monitor and screen section for each, and two screen lines in your ServerLayout (names will vary):
      Screen "Main Screen" 0 0
      Screen "TV Screen" RightOf "Main Screen"

      As best I can figure, that *should* the way to go about it. Whether it actually works remains to be seen. I've only ever tried to set up dual monitors on my laptop, which doesn't have an ATI chipset. Of course, this all assumes that your card is supported by the fglrx driver.

    7. Re:linux by Eideewt · · Score: 1

      Oh, and don't blame the kernel for ATI's poor driver support. The kernel itself doesn't have a thing to do with that.

    8. Re:linux by Anonymous Coward · · Score: 0

      Why would you use a binary blob when there's free drivers for R200s?

    9. Re:linux by Eideewt · · Score: 1

      I didn't think the free drivers had full 3d acceleration. If they do, I may switch.

      By the way, I forgot to mention above that the latest version of fglrx is missing a file (good grief!), but you can find it on the Internets. See http://fedoranews.org/cms/node/1014.

    10. Re:linux by Anonymous Coward · · Score: 0

      The free drivers, while generally good, do not support TV-out yet.
      I found Ubuntu pretty easy to get the fglrx drivers going on -- switch on the universe and multiverse repositories (either by using synaptic or just pointing a text editor at /atp/sources.list and removing a couple # signs) and then apt-get the "linux-restricted-modules-$KERNEL_NUMBER" and "xorg-driver-fglrx" packages. Or better yet, use the EasyUbuntu script. Check a box, hit apply, and away you go!
          If you decide to upgrade the driver later, remember to remove BOTH of those packages. The restricted modules package on breezy and later does this annoying thing where it copies the kmods into place on boot, so if you remove the current module from /lib/modules/$KERNEL_NUMBER and install a new one, the old one will reappear on the next boot. It did this to me with an nvidia card, about drove me nuts until I realized that package was still installed. ("What the hell? I thought I deleted that!")

        The "fglrxconfig" script can set up dual monitor for you. Back up your xorg.conf before you run that, of course. Me, I tend to be either/or with the S-Video vs VGA plug, so I currently have mine set up for a single auto display.

        One last warning for upgrades, though: I've had rather mixed results with the ati driver installer. What I usually did/do is just run alien on the redhat rpms. Works great 95% of the time, though on debian-based systems you have to be kind of insistent (via some command-line option that I always forget and just look up) or else the package manager will refuse to overwrite libGL.so.1, or whatever it is that fglrx needs to replace. I appreciate that apt doesn't want to wipe out system files on some crazy package's whims, but I wish it was a little easier to say "go ahead anyway, I've already backed up the damn thing" than it is.
        - mantar

  2. Really helped by drsmack1 · · Score: 4, Interesting

    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!

    1. Re:Really helped by A+Nun+Must+Cow+Herd · · Score: 1

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

    2. Re:Really helped by Anonymous Coward · · Score: 0

      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

    3. Re:Really helped by Toveling · · Score: 0, Troll

      Let me guess.. Snappier?

    4. Re:Really helped by Anonymous Coward · · Score: 1, Interesting

      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' ?

    5. Re:Really helped by jnik · · Score: 2, Insightful

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

    6. Re:Really helped by Anonymous Coward · · Score: 1

      Same here -- I don't know what they did (or it is just an coincidence?) but I have a few boxen using different archs (a Pentium 4, an old PII, a G5 and an Athlon 64), and modular X.org "feels" significantly faster on all of them but the P4. No hard figure yet, but for instance firefox on gtk2+/cairo backend is not jerky anymore on the PII (mouse-wheel scrolling is perfectly smooth, and very fast too) which is something I haven't seen in years. The kernel upgrade aside, nothing else changed. That's pretty impressive!

    7. Re:Really helped by shellbeach · · Score: 1
      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

      I can write CDs just fine with the recorder as a normal IDE device (i.e not using ide-scsi). This has been the case for a very long time ... is that what you're referring to?

      Growisofs (for DVD writing) works too, for that matter ...
    8. Re:Really helped by Anonymous Coward · · Score: 0

      cdrecord still shows the obnoxious error message though, and the documentation still contains lots of information that's totally out of date and incorrect, like "there is no DMA on Linux unless you're using ide-scsi".

      Oddly, distro-supplied versions of cdrecord seem to work a lot better than the official ones built from source code. I can't run the official one without setuid root, but Ubuntu's packaged version works fine.

    9. Re:Really helped by jmv · · Score: 1

      Care to mention what improvement (driver/scheduler/...) is responsible for the increased speed.

    10. Re:Really helped by jnik · · Score: 1
      Oddly, distro-supplied versions of cdrecord seem to work a lot better than the official ones built from source code.

      That would be because the distros apply the patches that Schilling doesn't want. Google for "cdrecord linux 2.6" and you'll get plenty of perspectives from all sides of the story. Here is a not-horrible introduction to the whole mess.

      If you want to rely on your distro, stick with your distro; if you're more of a roll-your-own and like to track the latest upstream, just move to dvdrtools. cdrecord and Linux have parted ways at this point, and both code and documentation are subject to bit rot.

    11. Re:Really helped by BrokenHalo · · Score: 1
      Slightly closer to "fact": DVD-R Tools works.

      Furthermore, dvdrtools are not developed by an arrogant prick who feels the need to insist that everybody uses SCSI devices on Solaris. Reading Schilling's documentation always makes me want to hit him.

    12. Re:Really helped by SphericalCrusher · · Score: 1

      So it's good that Linux is finally taking advantage of dual core processors and hyper-threading.

      --
      "Instant gratification takes too long." - Carrie Fisher
    13. Re:Really helped by Anonymous Coward · · Score: 0

      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

      This is not meant to be a troll, but simply a notification for those who haven't noticed... Joerg Schilling tends to have a bit of a stick up his ass when it comes to things not being designed the way he pictures them. He's also a bsd user who thinks Linux is inferior and should be dealt with only disparagingly.

      CD recording on Linux would benefit if someone were to fork cdrecord and take charge of the new project, but no one has stepped up to do so yet.

  3. what by Anonymous Coward · · Score: 2, Funny

    is this for computers?

    1. Re:what by Anonymous Coward · · Score: 0
      is this for computers?

      No, its for toasters ovens.
  4. Comment removed by account_deleted · · Score: 0, Flamebait

    Comment removed based on user account deletion

  5. Re:Video Editing? by Anonymous Coward · · Score: 2, Funny

    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.

  6. Re:Video Editing? by Anonymous Coward · · Score: 1, Insightful

    "Final Cut Pro on OS X is my guess"

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

  7. Question for the masses. by SynapseLapse · · Score: 3, Interesting

    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?

    1. Re:Question for the masses. by shird · · Score: 5, Informative

      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.

      --
      I.O.U One Sig.
    2. Re:Question for the masses. by Sancho · · Score: 1

      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.

    3. Re:Question for the masses. by DemonThing · · Score: 0, Redundant

      FreeBSD is not Linux.

    4. Re:Question for the masses. by akulbe · · Score: 1

      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.

    5. Re:Question for the masses. by reklusband · · Score: 0, Troll

      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)

    6. Re:Question for the masses. by grasshoppa · · Score: 1

      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.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    7. Re:Question for the masses. by caseih · · Score: 5, Interesting

      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.

    8. Re:Question for the masses. by hcob$ · · Score: 3, Insightful

      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.

      --
      Cliff Claven
      K.E.G. Party Chairman
      Founding Leader of: Koncerned for Egalitarin Governance
    9. Re:Question for the masses. by TheDreadSlashdotterD · · Score: 1

      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.

      --
      I have nothing to say.
    10. Re:Question for the masses. by Anonymous Coward · · Score: 3, Insightful

      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.

    11. Re:Question for the masses. by reklusband · · Score: 0

      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.

    12. Re:Question for the masses. by billstewart · · Score: 2, Informative
      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 not a microkernel architecture 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 and have fun learning lots more detail about Linux internals.

      --

      Bill Stewart
      New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    13. Re:Question for the masses. by WindBourne · · Score: 1

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

      --
      I prefer the "u" in honour as it seems to be missing these days.
    14. Re:Question for the masses. by drsmithy · · Score: 4, Interesting
      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.

    15. Re:Question for the masses. by Neptune0z · · Score: 1

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

    16. Re:Question for the masses. by x2A · · Score: 1

      I change the kernel more often than the hardware, to test the latest features, and compile all my drivers (network, filesystems etc) in, to make sure when the new kernel boots, I don't need to bother with my depmod / modules_install or anything like that. I even have enough memory to not notice a little bit taken up by a driver or two I'm not using. I like whatever I need to just be there, so whatever I'm doing with harddrives etc, doesn't matter. No more "crap, I can't access this filesystem without module x, which is -on- that filesystem" or anything like that. Simplicity.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    17. Re:Question for the masses. by professorfalcon · · Score: 1

      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.

      Open sourceness through obscurity.

    18. Re:Question for the masses. by Anonymous Coward · · Score: 1, Interesting

      The freedome doesn't ceom from "LInux does whatever you want", the freedom part comes from "You can do whatever you want". The source is yours to play with, lots of people have their own kernel branches and patchsets, and do things a little differently.

      A comparison might be, "It doesn't matter if a law is made for the right reasons, it's still made because at the end the laws are made by the House and Senate." Except Congress isn't elected, and anybody can be on it, Linus is the president for life and he also does whatever he wants.

    19. Re:Question for the masses. by layer3switch · · Score: 1

      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?

      No. If you compile your kernel the way it should; ie editing config before compiling by removing un-needed driver support and other things you do not need, you won't have to worry about compiling modules or loading modules you will not need.

      On the other hand, there are generally two ways to go about this. When compiling modules and vmlinuz, you can let kernel decide what to load (shotgun approach) or compile all as module and hand pick what needs to be loaded at init or in modprobe config. Later way is the preferred method for most cases since it's good way to trim the fat and reduce modules taking up the kernel memory space and at the same time, it's easier for hardware changes may take place later on such as USB devices and upgrade etc.

      Any correction on my above statement is always welcome.

      --
      "Don't let fools fool you. They are the clever ones."
    20. Re:Question for the masses. by dhalgren · · Score: 2, Insightful

      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.

    21. Re:Question for the masses. by Lobais · · Score: 2, Informative

      But on the other hand, there are nearly no drivers for FreeBSD and Solaris.

    22. Re:Question for the masses. by Anonymous Coward · · Score: 0

      Also it's worth noting that Linux supports much more hardware that those with stable binary APIs (with the exception of Windows, that is). The lack of stable binary API is more of a political stance than a technical challenge.

    23. Re:Question for the masses. by Nutria · · Score: 1, Informative
      just eat up a few megs of space in /usr

      /lib/modules/$(uname -r)
      but we know what you meant...
      --
      "I don't know, therefore Aliens" Wafflebox1
    24. Re:Question for the masses. by Overly+Critical+Guy · · Score: 1

      Can you cite a source for this? FreeBSD's hardware support is great.

      --
      "Sufferin' succotash."
    25. Re:Question for the masses. by Fweeky · · Score: 1

      That's a pretty trollish way of putting it. How many hundreds of drivers and thousands of devices do you need to support before you get past "nearly no drivers"?

    26. Re:Question for the masses. by BoaZaur · · Score: 1

      And Than you need the same device on a None i386 machine and you're stuck. Linux is so Popular and runs on more machines than all other OSs combined, Exactly for this Political decision. So I'd say it works.

      Think about it, Free is Free in any dimension. GPL(s) Freedom is noted for its Temporal property, Passed-Future freedom - Evolvement. But consequently it has Lateral freedom, free to run on any system.

      You don't believe the rush of adrenalin when you connect a USB cam to your Linux phone, and oops no Drivers. So you Just Grab the source from your Mandriva machine and cross-compiles yourself one.

    27. Re:Question for the masses. by Anonymous Coward · · Score: 0

      Yes, I've been using 2.6.17-rc3 for a while now because of the Broardcom driver, and have been following the project from early on. It really makes you appreciate open-source when you see something like this go from nothing to near-full functionality in such a short space of time.

      Also, the guys in #gentoo-ppc on freenode are gods.

            (/me hugs ibook)

    28. Re:Question for the masses. by HuguesT · · Score: 1

      Hello, I don't want to start a flamewar, I think FreeBSD is splendid, but for example it's not well supported on laptops :

      from the FreeBSD documentation

      4 Power management
      Unfortunately, this is not very reliably supported under FreeBSD. If you are lucky, some functions may work reliably; or they may not work at all.

      To make things a little more complex, there are two existing standards for power management: APM and ACPI, the latter superseding the former and including more features, but also introducing more problems.

    29. Re:Question for the masses. by BrainInAJar · · Score: 1

      You are free, is the thing.

      Don't like the lack of a stable ABI? fork the kernel. You have the source, to use any way you want (with the exception of making it less free). Some folks'll use your fork, I'm sure

    30. Re:Question for the masses. by Anonymous Coward · · Score: 0

      An alternative comparison might be one that I read about Hugh Hefner, however - back in the day, he used to put stuff in the magazine that he liked, and it became popular because everyone else liked the same sort of thing.

    31. Re:Question for the masses. by tolonuga · · Score: 1

      drivers and kernel core are combined, so they can be managed as one.
      look at external/unmerged drivers: everytime the kernel core is improved they
      need to be updated and usualy lack behind. while in kernel drivers are updated
      at the same time so the kernel as combination of core plus driver is in harmony.

      one alternative would be a stable driver api. that meant no improvements to drivers
      at all, which is not a good idea. or have several versions of such an api in parallel.
      look at windows and other operating systems - it is a maintenance nightmare to maintain
      several API in parallel. such an approach leads to much more code and much more bugs
      in the real world.

      linux is a first class operating system, no alternative has so much hardware support,
      both cpu plattforms and drivers. it only works because all of it is combined in one
      source tree, and can be developed and improved in parallel.

      and for runtime - simply use a modular kernel, it will load only the drivers you need.
      having extra drivers on hard disk is not a big problem (unless you care for those 80MB
      of modules, but then you are in an embedded world where you have much tighter requirements
      anyway).

    32. Re:Question for the masses. by Lefty2446 · · Score: 1

      Grab a tarball of the kernel, read the docs, print out a kernel compile howto - Dirty your hands!

      All drivers have the option of being compiled or not and there are many that you will NEVER use. Most have the option of being compiled a a module - it will unload itself from memory when not being used. It the case of network drivers esp PCI hardware most will be in use all the time so the difference between a module and being compiled into the kernel is very slight.

      Get in, get dirty and learn!

      Adrian

    33. Re:Question for the masses. by ookaze · · Score: 4, Insightful

      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.

    34. Re:Question for the masses. by MartinG · · Score: 1

      Why are the network drivers part of the kernel?

      Only the drivers you use will actually get loaded, so you don't need to worry about clogging up the kernel.

      As for why they are in kernel space, rather than user space, it makes sense for network drivers to live in kernel space with Linux since they have to handle hardware interrupts etc. Doing this in user space it beyond my knowledge, but probably involves a microkernel architecture which Linux does not have. (and does not want)

      --
      -- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz .@adgimnoprstu
    35. Re:Question for the masses. by Jester998 · · Score: 1

      Have you tried it on a laptop recently? That article is fairly old (only covering up to FreeBSD 5.1). I would suggest you review the changelogs for recent versions, as support has increased with every version...

      I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it, including laptops, except cutting-edge consumer-grade hardware (i.e. maybe the sound on a brand-new Dell Dimension might not work).

    36. Re:Question for the masses. by Phleg · · Score: 1

      ...get a copy of Gentoo Linux and have fun learning lots more detail about Linux internals.
      No, sorry. As much as I enjoyed Gentoo back in the day when I used it, it teaches you squat about Linux internals. Following a three-page command-line installation process verbatim does not teach you a thing about how Linux works, much less actual Linux internal algorithms and structures.
      --
      No comment.
    37. Re:Question for the masses. by Anonymous Coward · · Score: 0

      Too much audio hardware doesn't really work on *bsd.
      Too much already doesn't work on linux, but it's worse on *bsd.

      Free software is very bad in the "software sequencer, synthesis" level.

    38. Re:Question for the masses. by FireFury03 · · Score: 1

      I like whatever I need to just be there, so whatever I'm doing with harddrives etc, doesn't matter. No more "crap, I can't access this filesystem without module x, which is -on- that filesystem" or anything like that. Simplicity.

      Modern distros automagically load the right stuff into the initrd and load the right modules when they are needed. The only thing I've had to modprobe manually in ages is the sctp module, and even that can be fixed by adding the right magic to the modprobe.conf (no, I don't know why it isn't there by default).

      In my experience you're more likley to find yourself lacking the right drivers if you muck about with the kernel config yourself rather than just letting the distro do The Right Thing. There is a place for compiling stuff directly into the kernel, and that's embedded systems - for workstations running a standard distro you're far better off just letting the distro do it's thing.

    39. Re:Question for the masses. by Anonymous Coward · · Score: 0

      This is one of the things that makes Linux great when it comes to disaster recovery. By having the driver modules in the kernel one can create an image of a server that can easily be recovered onto different hardware! Try doing that on Microsoft Windows. Heck, if you did it with Windows 2000 and the machine had a different network card it would BSOD.

    40. Re:Question for the masses. by FireFury03 · · Score: 4, Insightful

      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.

    41. Re:Question for the masses. by Anonymous Coward · · Score: 0
      And Than you need the same device on a None i386 machine and you're stuck. Linux is so Popular and runs on more machines than all other OSs combined, Exactly for this Political decision. So I'd say it works.


      This is just wrong. Let:

      L = number of machines that run only Linux.
      LO = number of machines that run Linux and something else.
      O = number of machines that run only something else.

      For your statement to be true L + LO > O + LO. Which reduces to L > O. Which is plainly false.
    42. Re:Question for the masses. by DuckDodgers · · Score: 1

      Obviously the BSD Unixes, Mac, and Windows have good driver ABI models - they all work fine on their respective hardware.

      But the advantage of a changeable ABI model is that you can try new things. I'm not aware of any exhaustive benchmarks one way or the other, but it's at least possible that the changeable driver model for Linux gives superior performance or may some day give greater performance than the competition. If the Linux kernel team finds out that a particular change offers a performance advantage, they can make that change. The other operating systems can only do that for changes that dont' break the ABI.

    43. Re:Question for the masses. by DuckDodgers · · Score: 1

      In all seriousness, what would you suggest instead as a way to learn about Linux internals?

    44. Re:Question for the masses. by Sancho · · Score: 1

      For some reason the initrd system makes me uncomfortable. It's nothing I can explain, it just does. So I manage my own kernel, I keep backup kernels in case something gets really screwed up. So far, Gentoo hasn't complained and I haven't had to back out of a new kernel due to my own screwup, yet.

    45. Re:Question for the masses. by ptlis · · Score: 1
      In all seriousness, what would you suggest instead as a way to learn about Linux internals?

      LFS would almost certainly be a good place to start assuming you're meaning the whole GNU/Linux package and not just the Linux kernel.

      --
      There's mischief and malarkies but no queers or yids or darkies within this bastard's carnival, this vicious cabaret.
    46. Re:Question for the masses. by baadger · · Score: 1

      You don't use init? oO

    47. Re:Question for the masses. by Sancho · · Score: 1

      No, if you'll read more carefully, I said that I don't use initrd.

      http://en.wikipedia.org/wiki/Initrd

    48. Re:Question for the masses. by Eideewt · · Score: 1

      He meant that it is capable of running on more types of machines than other OSes, not that the number of installations is larger.

    49. Re:Question for the masses. by Eideewt · · Score: 1

      Is that working well for you? I heard it was still buggy, although it's great that it's finally in there.

    50. Re:Question for the masses. by BrokenHalo · · Score: 1
      For some reason the initrd system makes me uncomfortable.

      It's also usually unnecessary. Building your own kernel (apart from being fun) gives us the opportunity to simplify your setup without having to resort to arcane hacks, provided that your init scripts are up to the job. This is one of the (many) reasons why I still prefer Slackware over other distros; the BSD-ish init scripts are (IMHO) much simpler to deal with than SysVinit.

    51. Re:Question for the masses. by BoaZaur · · Score: 1

      I meant different type of machines. PC is only 1 type so Windows runs on 1.

      L > O is true
      L is huge look in MontaVista site and Linuxdevices for an example.
      O is actualy very small. there are not many machines that run an OS at all (VxWorks is marginal) that do not boot Linux. From iPods, through xBox and PC, to IBM mainframes.

    52. Re:Question for the masses. by BrokenHalo · · Score: 1
      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.

      Agreed (sort of), but my feeling is that nVidia still provide just about the best support there is for graphics cards on non-windows platforms, and I applaud their efforts at being inclusive rather than taking the snotty pro-windows stance that other developers assume. Sure, I would be even happier if their code was open-source, but by far the majority of users are not interested in hacking that code anyway.

    53. Re:Question for the masses. by BrokenHalo · · Score: 1
      In all seriousness, what would you suggest instead as a way to learn about Linux internals?

      You don't really have to look very far: Linux From Scratch.

      You can get the same experience over a much longer period of time by playing with Slackware or whatever, but Gentoo's cookbook approach (while possibly useful for generating a hardware-optimised system) will in all likelihood teach very little.

    54. Re:Question for the masses. by FireFury03 · · Score: 1

      my feeling is that nVidia still provide just about the best support there is for graphics cards on non-windows platforms, and I applaud their efforts at being inclusive rather than taking the snotty pro-windows stance that other developers assume.

      Certainly - I don't want to stop nVidia from supporting Linux, they do have about the best support at the moment. But I'm very wary of making it as easy and legal for people to produce binary drivers as it is for them to produce FOSS drivers.

      Sure, I would be even happier if their code was open-source, but by far the majority of users are not interested in hacking that code anyway.

      Ah, but this is missing the point entirely - you don't need the majority of users to hack it. Look at the Linux kernel, for example: the majority of users don't touch the code, but the few that do make it better for everyone. So even if you have no interest in hacking the code yourself, the very fact that it's open and other people can hack it can lead to improved drivers for you.

      People tend to put more effort into code if they are trying to fix a bug that's causing them problems rather than just because their boss told them to. :)

    55. Re:Question for the masses. by Anonymous Coward · · Score: 0

      Perhaps someone has mentioned already. Read: /usr/src/linux/Documentation/stable_api_nonsense.t xt

    56. Re:Question for the masses. by nuzak · · Score: 1

      Do you honestly believe that Linux not mentioning any problems in its documentation means it's free of them? Suspend and hibernate worked out of the box on the two laptops I ran FreeBSD on, while Linux actually corrupted the filesystem. Amazing. I run Linux at work and home both, but I'm hardly a devoted follower who believes it can do no wrong.

      The lack of a stable ABI would be fine by me but for the fact that Linus now feels the need to destroy the entire idea of a stable kernel version itself by hacking things into the supposedly "stable" series. Release engineering has apparently been pushed entirely to vendors who have to backpatch everything now.

      --
      Done with slashdot, done with nerds, getting a life.
    57. Re:Question for the masses. by DamnStupidElf · · Score: 2, Interesting

      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.

      This is why OpenBSD is having more success than Linux in getting specs from vendors, right? Because they just let BLOBs run in the kernel? Oh, wait...

      The only secure way to run binary drivers is to run them in usermode with ACLs on each hardware port and memory region they use, with safe wrappers around DMA. In fact, it's probably not even safe to trust binary drivers in this case. What if the hardware doesn't respect your computer and decides to snoop the bus on its own? It can leak information back to the driver through side channels, or worse act as a backdoor. Suppose your wireless chipset maker gets a visit from a TLA who wants immediate access to any wireless system. The driver is the place to do that, since it runs in kernel mode. Makes you wonder about all those "closed source wireless drivers are the *only way* to satisfy the FCC!" arguments.

    58. Re:Question for the masses. by object88 · · Score: 1

      I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it...

      Perhaps things have changed in the last few weeks, but last I checked, audio hardware was severely lacking in FreeBSD. Drivers for professional-grade audio hardware was almost nil. Not saying that FreeBSD is better/worse than Linux, just that your expirience is different than mine. :)

    59. Re:Question for the masses. by Anonymous Coward · · Score: 0

      That only shows that a stable ABI isn't a sufficient condition.

    60. Re:Question for the masses. by DuckDodgers · · Score: 1

      I did mean the whole package. Thank you. (and thanks BrokenHalo, who provided the same info.)

    61. Re:Question for the masses. by reklusband · · Score: 0

      The thing is...I can't fork the kernel. Nor can 99.9% of computer users. So we're stuck with what is given. In the case of Linux, it's Linus's world.

    62. Re:Question for the masses. by BrainInAJar · · Score: 1

      That's a problem of ability, not rights.

      I'm "free" in our society to become a professional athlete... Doesn't mean I'm able to

  8. Go Linux! by Umbral+Blot · · Score: 4, Insightful

    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.

    1. Re:Go Linux! by freralqqvba · · Score: 5, Informative

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

    2. Re:Go Linux! by Umbral+Blot · · Score: 1

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

    3. Re:Go Linux! by Sharth · · Score: 1

      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.

    4. Re:Go Linux! by freralqqvba · · Score: 1

      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.

    5. Re:Go Linux! by Mostly+a+lurker · · Score: 1
      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.
    6. Re:Go Linux! by bersl2 · · Score: 1

      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.

    7. Re:Go Linux! by ip_fired · · Score: 3, Informative

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

      --
      Don't count your messages before they ACK.
    8. Re:Go Linux! by Umbral+Blot · · Score: 2, Interesting

      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.

    9. Re:Go Linux! by TCM · · Score: 1

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

      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    10. Re:Go Linux! by TCM · · Score: 3, Insightful
      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..
      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    11. Re:Go Linux! by Umbral+Blot · · Score: 1

      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.

    12. Re:Go Linux! by ip_fired · · Score: 2, Interesting

      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.

      --
      Don't count your messages before they ACK.
    13. Re:Go Linux! by Jack_the_Tripper · · Score: 1
      The real question here then is: why isn't there a better language than C for creating OSs in?
      Perl?
    14. Re:Go Linux! by freralqqvba · · Score: 1

      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.

    15. Re:Go Linux! by r00t · · Score: 1

      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.

    16. Re:Go Linux! by WhatDoIKnow · · Score: 1

      How could anything be better than C for writing kernels?

    17. Re:Go Linux! by 19thNervousBreakdown · · Score: 1

      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.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    18. Re:Go Linux! by Umbral+Blot · · Score: 2, Insightful

      How could anything be better than flint for making arrowheads?

    19. Re:Go Linux! by pavon · · Score: 4, Informative
      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.

      That is exactly why it was done. More information about can be found at kerneltrap: here, and here. It was also previously on slashdot, although you would be best to skip that - it has more misinformation than the other kind.

      In short, all the known ways of implementing zero-copy within the existing API's cause the most common usage cases of those API to be slower than they are now. Therefore, it made more sense to export this new API for the applications where speed is critical.

      In the the first kernaltrap article, Linus also explains why splice is different from sendfile, contrary to the posts here claiming they are essentially the same.

    20. Re:Go Linux! by Not+The+Real+Me · · Score: 1

      A huge chunk of Perl is nothing more than a thin wrapper around C library calls. Other than that, great point!

    21. Re:Go Linux! by ArbitraryConstant · · Score: 1

      In this case, the new system call was to avoid ugly hacks like FreeBSD's Copy On Write system (which is transparent, but even harder to use because of that and frequently unhelpful in adding performance).

      Linus's take on the whole thing is that if you want portability, you should just use the read(), write(), etc system calls, since they perform pretty well anyway. If you absoloutely must do something platform-specific for every ounce of performance, you should have a clean API to do it with.

      --
      I rarely criticize things I don't care about.
    22. Re:Go Linux! by iabervon · · Score: 2, Informative

      In this case, the new syscall is because a specific situation can be optimized compared to using the existing functions, but the more efficient function only works at all for certain special (but important) cases. In this case, the optimization is that copying data from outside of the program to outside of the program is more efficient if the data doesn't have to go through the program; obviously, this can't be used for the common case where the program is trying to use the data. The case that it helps a lot is when a program is sending data from the disk to the video card, or network to the disk, etc. With the new syscall, the data doesn't have to be copied into the program's address space (or the program's page tables changed to bring it in, which generally costs a TLB flush).

      Programs that want to be backwards compatible can rely on getting an error result of ENOSYS when they try, and can then fall back to using the traditional method.

    23. Re:Go Linux! by jgrahn · · Score: 1
      How could anything be better than flint for making arrowheads?

      More people probably tried to replace flint arrowheads with compressed buffalo-dung, dried fish with pointy heads or discarded FireWire cables, than with something that actually would have been better ...

    24. Re:Go Linux! by Fweeky · · Score: 1
      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.
      K - a kernel metalanguage. Been a Summer of Code project twice so far.
    25. Re:Go Linux! by waveclaw · · Score: 4, Informative
      The kernel is written in C, and so are those system calls. I don't believe you can overload a C function.


      There is no overloading going on here. Overloading is to create a new function with the same name, but taking different parameters.

      Ahem. The original function, sendfile(2), was rewritten to call splice() instead of doing something else.

      Everybody that wrote code that used the old function now has to deal with splice() running instead of the old function's logic.

      Just to hammer it home:
      Old - app -> sendfile(2) -> some logic -> return to app
      New - app -> sendfile(2) -> splice() -> splice's logic -> return to sendfile(2) -> return to app

      With the Linux kernel, as this exepmlifies, you can improve the original code and get everyone (well, those to lazy to revert the changes) to use it. In this case you have a fixed API (sendfile(2) which is well known and published) so you don't just want to tell everybody to recompile with called to splice().

      See the difference? Feel the difference.

      The kernel is GPL and thus the actual source code used to compile the binary kernel you use is available to you. With a closed source kernel you might be able to purchase an SDK with linkable binaries and some (probably undocumetned) header files. Programmers in this situation need things like function overloading and class inheritence just to do anything. One way of looking at the history of languages like C++ is as a technical solution to the ethical problem of closed source programming. Those languages focus on extending on the outside. With OSS you can usually replace, fix and improve on the inside. BSD and GNU differ on a the point of GNU wanting everyone to share the source to those fixes if they share the resulting binaries. But I digress.

      And I can't wait to see if this breaks something.
      --

      "You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
    26. Re:Go Linux! by ceeam · · Score: 1

      Do it! There are oh so many things that you think are brain-dead and could be made better and slicker and everything... But once you try to do something, 99.99% of the time you just create your own mess. Not that you shouldn't try.

    27. Re:Go Linux! by jrockway · · Score: 4, Funny

      > A real macro system and overloading would probably be nice for kernel dev.s everywhere.

      Like LISP? That's what they used to use, but C was chosen for UNIX, and UNIX caught on big time, so C is the language now. I think it's about time to write an OS (kernel + tools) in LISP, so we can return to the good-old-days of Lisp machines.

      --
      My other car is first.
    28. Re:Go Linux! by Umbral+Blot · · Score: 1

      Hear hear!

    29. Re:Go Linux! by ObsessiveMathsFreak · · Score: 1

      I don't believe you can overload a C function.

      Ohhh, young man. Much have you to learn of the dark paths of C.

      --
      May the Maths Be with you!
    30. Re:Go Linux! by dodobh · · Score: 1

      Not all hardware has the oomph necessary to do the heavy lifting. And other constraints may force the hardware _not_ to have that oomph.

      Optimising later is always good.

      --
      I can throw myself at the ground, and miss.
    31. Re:Go Linux! by Paapaa · · Score: 1

      The question is: why didn't they just change the function sendfile(2)? Why did they create a new function that is called from the old function thus only increasing the overhead? (yes, I am a n00b)

    32. Re:Go Linux! by betterunixthanunix · · Score: 1
      The kernel is written in C, and so are those system calls. I don't believe you can overload a C function.

      You can. Remember how C allows functions to take a variable number of parameters? This is, in essence, how you could go about overloading. You don't even need a special marker parameter to tell you how many parameters there are, since the difference of EBP and ESP will. On the other hand, if the number of parameters does not differ, but the types do, then you will need a marker of some sort (think about printf/scanf).

      Saying you can't overload in C is like saying you can't do object oriented programming in C. You can, you just need to handle it yourself, rather than allowing your compiler to hold your hand.

      --
      Palm trees and 8
    33. Re:Go Linux! by Anonymous Coward · · Score: 0

      But then... is the overhead in the compiled kernel, or just more workload for the compiler?

    34. Re:Go Linux! by jez9999 · · Score: 1

      Couldn't you sort of emulate overloading by declaring a variadic function and checking the argument type and number passed to it?

    35. Re:Go Linux! by Ginger+Unicorn · · Score: 1
      because this way, no one who was calling sendfile(2) has to change their code to call splice() instead. It just happens automatically, since any calls to sendfile(2) are forwarded to splice(). anyone wanting the benefit of splice() without the overhead of calling it through sendfile(2) can simply change their code to call splice() directly.

      this way allows people to update their code to use the new faster routine, but also automatically picks up any stragglers that dont bother to update their code.

      --
      (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
    36. Re:Go Linux! by SpinyNorman · · Score: 1

      There's nothing wrong with using goto where there's no efficient alternative. What's bad is using goto for normal control flow (aka sphagetti code), but it's reasonable for example to use it for "exception handlng" in a laguage such as C that doesn't have the try.. catch mechanism of C++ (where throw() basically means "goto catch"). Another reasonable place, just as an example, to use goto is in implementation of a state machine where the states are labels in your code and you can then write "goto state_x" rather than the less efficient "state = state_x" and loop back to a "switch (state)" statement effectively that does the "goto" (but less efficiently via jump table or decision tree, depending on how sparse your case labels are). Of course you don't always care about this level of efficiency, but sometimes you do.

      The "goto considered harmfull" is basically true, and makes a reasonable edict for beginners, but goto still has it's place (especially in C for exception processing).

    37. Re:Go Linux! by SpinyNorman · · Score: 2, Informative

      Overloading is just syntactic sugar - it doesn't give you any fucntionality.

      There's no functional difference between using an overloaded name f(a), f(x, y), f(p, q, r) or three separate ones f_a(a), f_xy(x, y), f_pqr(p, q, r).

      If you want default arguments C has them, and if you want polymorphism then C has it too (function pointers).

    38. Re:Go Linux! by db32 · · Score: 1

      Absolutely, I don't want efficiency on older hardware. I have 1GB of RAM and a dual core system! I want to see every bit of my RAM in use at all times and my processor at 100% so I know I am getting my moneys worth!

      A computer that has faster and more efficient software can do more with its fancy new fast expensive hardware than one that relies on the hardware to carry the weight when the software can make it lighter. That lazy attitude of "let the hardware do it" brings us more and more bloatware and fewer and fewer programmers concerned with good coding practices.

      --
      The only change I can believe in is what I find in my couch cushions.
    39. Re:Go Linux! by xenocide2 · · Score: 1

      Functions serve both as code and entry formats to the kernel. A syscall is basically a strange hardware protected function call. The change was probably implemented by simply replacing a function pointer in the kernel, so that the handler for syscall number associated with sendfile(2) is instead passed to splice. No increase in overhead, and the interface for user programs (mostly libc) remains the same.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

    40. Re:Go Linux! by menace3society · · Score: 1

      Function overloading, like operator overloading, is a crutch for lazy people with little understanding of computers.

      Ignoring all the technical details as to why it's a bad idea, it serves no actual purpose as far as improving maintainability, speed, or code size. What the compiler has to do with shitty languages to support overloading is to translate each unique function name like do_stuff into a symbol like _Z8_do_stuffxyz, and creates a separate block of code to handle each separate case. This adversely affects compilation time and can only hurt the efficiency of the executable. As a programmer, you have to write separate functions for each overloaded case, so it doesn't save any development time. And finally, other people reading or maintaining the code have to figure out version of a given function is being called at a given time, what the types of the parameters are, what the namespace is, etc etc etc. When it's easier (or even necessary) to recompile the code with debugging symbols on, load it into a debugger, set a few breakpoints and execute just to figure out what function is being callled on a given line, you have a very shitty program. When you have a language that encourages that sort of thing, you have a very shitty language.

      I'm sure kernel devs thank whatever gods they may or may not believe in every day that they don't have to deal with function or operator overloading, and you and every other two-bit C++ hacker-wannabe that would try to contribute code.

    41. Re:Go Linux! by Matt+Perry · · Score: 1

      I don't think you understand what he is asking. What he means is, why create a new function call at all? Why wasn't the code that is now in splice() put into sendfile() in the first place?

      --
      Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
    42. Re:Go Linux! by Karma+Farmer · · Score: 1
      It was also previously on slashdot [slashdot.org], although you would be best to skip that - it has more misinformation than the other kind.
      Inconceivable!
    43. Re:Go Linux! by pclminion · · Score: 2, Insightful

      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.

    44. Re:Go Linux! by dasunt · · Score: 1

      Linux kernel C is GCCisms C. There might be someway to accomplish it without too much difficulty. I don't know.

    45. Re:Go Linux! by Procyon101 · · Score: 1

      Idle proc cycles are the devil's playground

    46. Re:Go Linux! by iggymanz · · Score: 1

      The LISP machines had issues, not the least of which is being designed for running for one user. The full protection, access control and process isolation expected of a modern operating system isn't going to happen on a LISP machine. Those who wanted that had to run a virtual LISP machines on a real operating system.

      Besides, while armchair OS coaches may say, "Let's write an OS in high-level langauge X", the majority of real OS in actual use aren't written that way, they're in C (a high low-level language) or lower level.

      Funny also these Ivory Tower types who say "we just finished our OS project, which needs to run on Linux/Unix/BSD"

    47. Re:Go Linux! by pooly7 · · Score: 2, Insightful

      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.

    48. Re:Go Linux! by arodland · · Score: 1

      Except for one thing. Calling system calls directly from your apps is a very rare occurrence. With any luck, it never happens. Which So what needs to be updated to reflect the new kernel interface? Glibc. Upgrade that, and it's possible for everything on your system to feel the benefit. In some cases, anyway. For the file-flushing bits obviously this doesn't apply because you still need to explicitly use those calls in your app. But you can't really do anything about that.

    49. Re:Go Linux! by Breakfast+Pants · · Score: 1

      2>>x... come on man.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    50. Re:Go Linux! by pclminion · · Score: 1

      Don't you mean x << 1?

      It's not the best example anyway, since the compiler will usually do that sort of strength reduction for you. But there are other kinds of reduction that the compiler isn't smart enough to figure out, yet can be done by the programmer without making the code harder to read or introducing "hacks."

    51. Re:Go Linux! by TCM · · Score: 1
      That lazy attitude of "let the hardware do it" brings us more and more bloatware and fewer and fewer programmers concerned with good coding practices.
      It looks like you caught my quip from the wrong angle. I'm all for good coding practices. At the same time, I'm all against optimizations that introduce side effects or break the general design of a system. I wasn't saying that's the case with Linux in particular. I just rephrased an expression because I thought it came from someone who would still code everything in assembler in order to squeeze every bit of speed out of a system while neglecting maintainability and correctness.

      Let me quote one of NetBSD's goals to make my intent more clear:

      Microoptimizations can play a part in any system, but design is even more important. Rewriting a routine to speed it up by 80% may sound impressive, but that routine may have only been using 5% of the CPU time. Looking at the larger picture and saving 10% overall by redesigning the way an operation is carried out gives over double the benefit. There is room for both in NetBSD, but we prefer getting a design right to tweaking a poor implementation.

      Or in short:

      Some systems seem to have the philosophy of "If it works, it's right". In that light NetBSD could be described as "It doesn't work unless it's right".
      --
      Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
    52. Re:Go Linux! by db32 · · Score: 1

      I think any optimization that isn't just some quick hack is probably a good thing. Your comment does make more sense now though. I kinda read the article as the section was a redesign type optimization, and not some quick hack, and that this plan had been some years in the making.

      --
      The only change I can believe in is what I find in my couch cushions.
    53. Re:Go Linux! by jrockway · · Score: 1

      Here's an OS written in C++ that boots by itself and is generally a functional OS:

      http://sourceforge.net/projects/ekp/

      Complete? No, but it's written in a high-level language, and it doesn't need a "host OS" to boot.

      --
      My other car is first.
    54. Re:Go Linux! by MK_CSGuy · · Score: 1

      I think it's about time to write an OS in LISP

      It's called emacs...

    55. Re:Go Linux! by Ivan+Todoroski · · Score: 1

      Well obviously because 'splice' is a more general function that can be used in other contexts besides 'sendfile' (which is just one special case where 'splice' helps things).

    56. Re:Go Linux! by Ginger+Unicorn · · Score: 1

      i really dont know the specifics, but perhaps sendfile performs other operations if you give it other parameters. or perhaps it is purely just about naming.

      --
      (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
    57. Re:Go Linux! by iggymanz · · Score: 1

      very cool! maybe we'll finally see more efforts such as this

  9. Re:Video Editing? by Anonymous Coward · · Score: 0

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

  10. Re:Why support Apple hardware? by FragInc · · Score: 0

    "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!

    --
    Get your FRAG on!
  11. In case of slashdot, break mirror by TrueKonrads · · Score: 4, Funny
    --
    Lone Gunmen crew.
    1. Re:In case of slashdot, break mirror by notanatheist · · Score: 1

      Right, how often does kernel.org get /.'ed? They've got some serious bandwidth. Maybe if the posted some photos of the new kernel we could bring them down.

    2. Re:In case of slashdot, break mirror by XMode · · Score: 1

      They put a 40Meg file on there, what else did you want?

  12. Re:Wow by Anonymous Coward · · Score: 0

    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.

  13. Diversity in advocacy by Anonymous Coward · · Score: 0, Offtopic

    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.

    1. Re:Diversity in advocacy by x2A · · Score: 1, Insightful

      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.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    2. Re:Diversity in advocacy by Anonymous Coward · · Score: 1

      Go and tell gay people that men and women are "programmed to be into each other," they'll be more than happy to laugh at you. Things aren't that simple...

    3. Re:Diversity in advocacy by x2A · · Score: 1

      I didn't say "men and women are programmed to be into each other", dumbass, I said "we" are. For most of us, that's across gender, but for some, it's within the same. Your point?

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    4. Re:Diversity in advocacy by cab15625 · · Score: 1

      I'm the only gay in the village!

      Actually, I'm not gay, I just think this whole line of conversation is silly. Linux isn't about being PC, it's about using your computer the way you want to. If you want to be a puritan and shun all things vile and disgusting (in your eyes) then, well, don't put naked/scantily clad women/men as your wallpaper. Outreach and advocacy are one thing, pandering to oversensative ludites is another.

      Keep your hands off my computer and I'll keep my hands off yours.

    5. Re:Diversity in advocacy by cab15625 · · Score: 2, Insightful

      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.

    6. Re:Diversity in advocacy by Eideewt · · Score: 1

      I think most gay people are *fairly aware* that people are usually attracted to persons of the opposite sex. This is not laugh-worthy, and it will not come as a shock. Not that there's anything wrong with being gay, but anyone laughing at you for making that statement is more worried about asserting their gayness than listening to what you mean.

  14. some highlights from the changelog by doti · · Score: 5, Informative

    Some stuff I found interesting on the human-friendly changelog.

    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.

    --
    factor 966971: 966971
    1. Re:some highlights from the changelog by mazarin5 · · Score: 1
      Monitoring block device traffic?

      I wonder what effect this will have on the difficulty of hacking DRM?

      --
      Fnord.
  15. Re:Video Editing? by gid13 · · Score: 1

    Transcode maybe? Shrug.

  16. Where is 2.7? by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:Where is 2.7? by Anonymous Coward · · Score: 0

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

    2. Re:Where is 2.7? by WindBourne · · Score: 1

      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 prefer the "u" in honour as it seems to be missing these days.
    3. Re:Where is 2.7? by Anonymous Coward · · Score: 0

      Unfortunately, this new convention of identifying kernel stability doesn't work too well. For example, it appears that a major bug was introduced in the 2.6.16.17 kernel which affects some users of VIA chipsets. The effect is stuttering audio. According to the current process, the kernel 2.6.16.17 kernel is a mature kernel. This bug still exists as of the 2.6.17 release. Honestly, I don't know which process is better, though.

    4. Re:Where is 2.7? by 0racle · · Score: 1

      IIRC, the idea was to do away with the idea of a stable kernel, do all the development in one place and let the distro maintainers deal with stability issues. You're not really supposed to be building your own kernel anymore.

      --
      "I use a Mac because I'm just better than you are."
    5. Re:Where is 2.7? by x2A · · Score: 5, Informative

      The stable/development branches might be a nice idea in theory, but in practice it doesn't work. Distros would ship, for example, a "stable" 2.4.xx kernel, except it wouldn't actually be that. They would spot nice features in the 2.5 kernel that they wanted to offer their users, and so back-port them... and any other nice patches floating around the net while they're at it. The result being that the kernels that ship with distros were so heavily modified, that stability (from one machine to another) went right out of the window. You couldn't go to kernel.org and download an updated kernel, as without all the patches, it wouldn't work. So you had to stick to the distro's kernels.

      So instead, the 2.6 goal is to have development/stable parts of the cycle, rather than seperate branches. Roughtly: patches that could break things get submitted at the beginning of the cycle, and -pre1/-pre2 tarballs are released. If you want bleeding edge, you go here. Release candidates are released, where developers get chance to fix bugs etc in the code. Then, any code that's still [known to be] buggy gets dropped for the final release (eg, 2.6.17). The developer can work on it, and try add it again during subsequent cycles. When it works, it can be included in a final release.

      During this cycle, security and other urgent bug fixes take place in the ultra-stable branch, with version such as 2.6.16.1, 2.6.16.2.

      (This is the rough idea I believe, there could be some slight inaccuracies in how it actually takes place, I haven't followed it 100%, but this should be close enough to get the right idea).

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    6. Re:Where is 2.7? by RedBear · · Score: 1
      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 ...


      The way I understand the situation is that some people were concerned that the kernel was starting to get too long in the tooth between development versions, what with technology moving along so quickly. So they decided to move some of the development stuff into the mainline kernel in order to be more flexible. There are still a lot of more dangerous experimental things going on in special branches elsewhere, but what you get in the "official" kernel should be fairly stable at any release point.

      I think.

    7. Re:Where is 2.7? by iabervon · · Score: 5, Informative

      That was the theory. But in practice, if Y was even, the kernel was obsolete, while if Y was odd, the kernel was broken. Except, of course, 2.even.0, which was actually stable, but broke compatibility with the previous kernel that worked. And occasionally, 2.even was kept up-to-date because nobody could use 2.odd for development, because it didn't work at all. You could tell that the old model didn't actually work, because no distribution shipped any kernel that used that model; they all shipped 2.even with an arbitrary set of patches (generally hundreds) from 2.odd and elsewhere. With the new model, distros are shipping kernels with only a few patches, and those patches are getting merged upstream.

      The stable kernels aren't remotely on the bleeding edge; they contain only features which have been tested over the past three months, after being filtered out of the bleeding-edge development as being things that have already stabilized and stand a good chance of being proven in three months. It's effectively very similar, except the development series isn't left known-broken and the stabilization process happens on a quick schedule, with stuff that isn't ready pushed off to the next cycle rather than delaying the current cycle. Also, the version numbers change by less (development gets -mm, -rc, or -git; stable series change the third digit by one instead of the second by two; and bugfix releases change the fourth digit instead of the third).

    8. Re:Where is 2.7? by Anonymous Coward · · Score: 0

      You're not really supposed to be building your own kernel anymore.

      Says who?

      Thats a load of FUD if I ever heard it.

    9. Re:Where is 2.7? by smittyoneeach · · Score: 1
      You're not really supposed to be building your own kernel anymore.

      Aw, c'mon.

      If using your personal hardware (not that of your employer, mind you) is about doing what you're told, sell your soul to Redmond.

      You do your best learning by tearing stuff apart, re-compiling it, and saying "I wonder what all those warnings wer"--kernel panic!

      Back up your data and play ball, say I.

      This is a great moment to offer props to the fellows behind busybox, and switch_root, in particular: by the time I understood WTF and had my kernel booting, I was quite amazed I hadn't melted down the / partition.
      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    10. Re:Where is 2.7? by 10Ghz · · Score: 4, Interesting
      This was a major boon for Linux


      Or bane. The "old way" meant that the vanilla-kernel (kernel offered by kernel.org) was stable. But new features took a LONG time to appear in the vanilla-kernel. But users and distros still wanted those advanced features that were not part of the kernel (yet). What happened was that distros offered their own vendor-kernels, that were VERY different from vanilla-kernel. Distros then spent their time and energy fixing their own vendor-kernels, instead of vanilla-kernel.

      This new system changes things so that new features are added to the vanilla-kernel, which means that the difference between vanilla and vendor-kernels is not that big. The distributors can focus on stabilizing the kernel, instead of adding new features to it. And porting those fixes to vanilla is a lot easier than porting changes in the old system. This means that if you want to use REALLY stable kernel, you should use the vendor-kernel.

      In short: this new system means that things progress a lot faster for everyone, with new features appearing in the kernel. And we can still have the stability we want if we use the tested and patched vendor-kernels.
      --
      Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
    11. Re:Where is 2.7? by Overly+Critical+Guy · · Score: 1
      You couldn't go to kernel.org and download an updated kernel, as without all the patches, it wouldn't work. So you had to stick to the distro's kernels.


      What's wrong with that? The job of the distro is to keep all that taken care of for you.
      --
      "Sufferin' succotash."
    12. Re:Where is 2.7? by Anonymous Coward · · Score: 0

      > whilst
      >Please stop using this word.

      Wait...I changed my mind. You can keep on using that word.

    13. Re:Where is 2.7? by M1FCJ · · Score: 1
      Ok, fair enough. Let's try to "git" the official kernel from one of the git repos. Errrm.. I have to admit that the days I used to compile a new version of the kernel almost daily from the sources are now in way back and I no longer do it as a matter of fact (compiling occassional released kernel or from a distribution's source and/or modules is fair game) but if I wanted to use something out of the release candidate, which one would it be? There's only (almost) a couple of hundreds of kernel branches there! Surely I'd like to use Linus's branch probably but it is not strictly clear.

      On the other hand, this obscurity probably prevents the newbie compiling a crap and buggy kernel and destroying his/her system and serves a purpose. Who knows?

    14. Re:Where is 2.7? by tolonuga · · Score: 1

      2.7 was 2.6.17-rc*, so this is 2.8.

      wait actually 2.7 was 2.6.16-rc* and 2.8 was 2.6.16 and 2.6.17-rc* was 2.9 so 2.6.17 is 2.10.

      if you do not like stable and well tested released every 3 months with lots of improvements,
      then you can simply use your distributions kernel, they maintain one kernel for years.

    15. Re:Where is 2.7? by x2A · · Score: 1

      "What's wrong with that?"

      What... what's wrong with being locked into a distro so you can't move in your own direction should you wish? Are you really asking me that question?

      "The job of the distro is to keep all that taken care of for you"

      Great, if you need someone else to take care of it for you, but one of the whole points of this open source malarkey is that you can have total control over your machine and the code it runs. Using a distro shouldn't mean signing over that control. Some people like to try the latest kernel, develop using it, or apply patches themselves without having to try get their distro to do it for them. Basically, different people have different needs and desires than you do, and while a distro lock-in might suit you, it doesn't everyone.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
    16. Re:Where is 2.7? by octopus72 · · Score: 1

      Current model is much better than 2.4/2.5 branching. Kernel development is faster and better controled, there is no more long and empty period as during the 2.5 development. Distributions can have up to date features (recent kernel allows them to more easily follow usability projects like udev/HAL, etc.). Developers take much more time to stabilize features for inclusion and this pays back, although they have insane amount to work for keeping it in sync with main tree until anyone stops complainig (suspend2 is a good example of such horror).

      Main drawback is that you can never have really rock-stable code like for example 2.4 kernel and out of tree drivers often become out of sync.

    17. Re:Where is 2.7? by gral · · Score: 1

      From what I can understand about the decision, it was decided that distro maintainers would deal with stability issues, as you said, but if everything was done inline as has been for the 2.6 kernel, then people were more apt to install the new kernel and test. Thereby proving the stability earlier.

      With a 2.7 kernel, most people would "Hold off" installing until the 2.8 release. Granted there are more "Issues", but they tend to get fixed faster now because the developers are working in a HAS TO WORK state, instead of oh that can be worked on the next release in couple months.

      It seems to be working so far, afaict.

      --
      Scott Carr
    18. Re:Where is 2.7? by Anonymous Coward · · Score: 0

      In a few days/weeks/months we'll have 2.6.17.2 or .3

      It could also be in a few hours. I believe the shortest I've seen between releases of the 2.6.x.y numbering was just slightly more than an hour.

    19. Re:Where is 2.7? by x2A · · Score: 1

      I think people just want a kernel called 2.7... cuz they think incrementing the minor version one would make it cool again. I think for so many people, it's a name thing more than anything else.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
  17. Linux is for other devices too by EmbeddedJanitor · · Score: 4, Insightful

    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.

    --
    Engineering is the art of compromise.
    1. Re:Linux is for other devices too by jrockway · · Score: 1

      > Nobody wants a cell phone with a 2 pound battery that only runs for 1 day.

      Somebody wants one, probably. A friend of mine has a phone that's three pounds and runs for MAYBE 1/2 day :) So he would probably want a 2 pounder with a 1 day battery life :)

      --
      My other car is first.
  18. Re:Video Editing? by Anonymous Coward · · Score: 0

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

    me and jesus pity you..

  19. Re:Video Editing? by daft_one · · Score: 1, Funny

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

  20. I have compiled by Anonymous Coward · · Score: 0

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

  21. Re:Video Editing? by Anonymous Coward · · Score: 1, Informative

    Like using MOL (Mac-On-Linux)?

  22. Microkernel anyone? by argoff · · Score: 4, Informative
    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/ 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 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

    1. Re:Microkernel anyone? by ArbitraryConstant · · Score: 4, Insightful
      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.
      --
      I rarely criticize things I don't care about.
    2. Re:Microkernel anyone? by droopycom · · Score: 1

      "The truth is that the Microkernel model probably is a better design"

      Yeah right... the truth is probably something like an opinion.

    3. Re:Microkernel anyone? by argoff · · Score: 2, Insightful
      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)

    4. Re:Microkernel anyone? by ArbitraryConstant · · Score: 1
      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.
      Compiling a driver against the current kernel is not prohibitively difficult (eg, VMWare does this for kernels they don't support out of the box).

      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)
      This is solely a matter of policy. Linus doesn't want a stable API, so they don't have one. It has nothing to do with the fact that it's not a microkernel. A stable API is equally possible with a monolithic kernel or a microkernel, and drivers that work across different versions are equally impossible without a stable API.
      --
      I rarely criticize things I don't care about.
    5. Re:Microkernel anyone? by Nutria · · Score: 1
      "The truth is that the Microkernel model probably is a better design"

      Yeah right... the truth is probably something like an opinion.


      The microkernel is a better design... for certain problem sets.

      Ultra-high reliability real-time systems comes first to mind. QNX and Green Hills have shown that microkernels work great there.

      Hypervisors are another good fit for microkernels and "millikernels".

      OTOH, workstation and server loads run perfectly well on macrokernels.

      --
      "I don't know, therefore Aliens" Wafflebox1
    6. Re:Microkernel anyone? by Frightening · · Score: 1

      *sigh*
      I was just about to post the Tannenbaum song.

    7. Re:Microkernel anyone? by EvanED · · Score: 1

      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.

      But same deal with a microkernel if you don't have a stable ABI. You'd still have drivers that work under one versoion not work under another because the interface changed.

      Now, I don't know enough to make a statement regarding this either way, but it's possible that having the drivers in userspace might make it easier to have a stable ABI, but to frame the debate as between uKernels and non-microkernels (and as a side note, it's no longer really micro vs. monolithic) is skirting the real issue which is the ABI stability.

    8. Re:Microkernel anyone? by 10Ghz · · Score: 1

      "Microkernel anyone?"

      Thanks, but to thanks.

      --
      Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
  23. support for the h.323 protocol, quite unlikely by rodac · · Score: 1, Interesting

    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?

  24. Had to exchange a motherboard by kbahey · · Score: 1, Offtopic

    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.

    1. Re:Had to exchange a motherboard by Anonymous Coward · · Score: 0

      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.

    2. Re:Had to exchange a motherboard by Anonymous Coward · · Score: 0

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

    3. Re:Had to exchange a motherboard by notanatheist · · Score: 1

      Why not try an Intel board? Not to be a fanboy or anything but their linux support is good. Intel NICs can't be beat for support and performance either.

    4. Re:Had to exchange a motherboard by corychristison · · Score: 1
      I had the exact same problem! Except I went ahead and bought the nForce version of the board [ASUS A8N-VM CSM] it's just a home testing server that I didn't want to put too much money into. Things seem to be running smoothly since the 1st.

      P.S. - Anyone in Canada looking for a motherboard? I still have the board that did not work. Heard it works okay with Windows or use an IDE drive... Asking $50 canadian dollars + shipping used for about a day.. Socket 939.

    5. Re:Had to exchange a motherboard by Anonymous Coward · · Score: 0

      Jesus... what is this, LiveJournal? "Couldn't get MOBO to work. Mood: depressed."

    6. Re:Had to exchange a motherboard by Osty · · Score: 2, Informative

      Why not try an Intel board? Not to be a fanboy or anything but their linux support is good. Intel NICs can't be beat for support and performance either.

      One may find it difficult to fit an AMD CPU on an Intel motherboard. Pesky competition.

      As the grand-parent said, he had to exchange a motherboard. That means he wasn't intentionally upgrading, thus expecting to continue to use the rest of his hardware (memory, disk, CPU). Were this a system upgrade rather than a replacement of a faulty part then it may be useful to suggest he look at an Intel-based solution. As it is, he obviously already had an AMD CPU and so he needed another motherboard that would work with said CPU.

    7. Re:Had to exchange a motherboard by layer3switch · · Score: 1

      I ran into similar issue, but I had a workaround to make it work by using AHCI and knocking down USB to legacy mode, hence kernel to recognizing SATA as IDE. Well, but I guess it's a pointless now since you got a new mobo and all.

      I hope, someone finds this helpful at least.

      --
      "Don't let fools fool you. They are the clever ones."
    8. Re:Had to exchange a motherboard by kbahey · · Score: 1

      That was the reason: I wanted to go AMD this time. I run Ubuntu server 64-bit and I am very happy with the mobo and the PC all in all.

      Sensors all work (fan, CPU temp, mobo temp), as well as hddtemp. However, S.M.A.R.T. does not work with that particular disk fr some reason.

      I have Cool N Quiet enabled and the system is really quiet and temperature is 23C these days or thereabouts. Goes up to 33C when I intentionally stress the system (try several instances of : dd if=/dev/sda | bzip2 -c > /dev/null)

    9. Re:Had to exchange a motherboard by kbahey · · Score: 1

      Not an option if you want to go with a cheaper, more power efficient and quieter, 64-bit processor.

      I agree that the Intel mobos are nice though. They work flawlessly with Linux too. My wife's PC has an Intel motherboard.

      What I do not like is the heat and power consumption for the Intel P4. AMD has the edge in this area hands down.

    10. Re:Had to exchange a motherboard by kbahey · · Score: 1

      Can you explain that in more detail?

      Is this the A8V-MX, or another motherboard?

    11. Re:Had to exchange a motherboard by Anonymous Coward · · Score: 0

      You use Gentoo as a server? Are you fucking stupid?

      So you run updates, right? How do you feel about recompiling 12 interdependent programs just to update one library?
      How's it feel to update your conf files 8 times a week?

    12. Re:Had to exchange a motherboard by wolverine1999 · · Score: 1

      You should connect it to the Promise SATA ports - they should be more reliable too. I've never had problems under Linux with those.

    13. Re:Had to exchange a motherboard by layer3switch · · Score: 1

      Lookup the SATA setting in BIOS. The A8V model has SATA settings that can be RAID or AHCI setting which will let OS to detect SATA drive as IDE drive.

      ftp://dlsvr03.asus.com/pub/ASUS/mb/socket939/A8V-M X/e2337_a8v-mx.pdf

      Look at the 2-26 or page 68 where it shows you how to set the SATA mode as AHCI. This is the only work-around I've found so far.

      http://www.intel.com/technology/serialata/ahci.htm
      http://linuxmafia.com/faq/Hardware/sata.html

      This should be suffice to gather enough info on the workaround. I had a bitching time setting up the SATA on mobo (although it wasn't A8V-MX but with same chipset and bios) until I found out my mobo accepts AHCI standard for SATA controller.

      --
      "Don't let fools fool you. They are the clever ones."
    14. Re:Had to exchange a motherboard by layer3switch · · Score: 1

      RAID or AHCI setting which will let OS to detect SATA drive as IDE drive.

      correction, i mean, AHCI compliant drive.

      --
      "Don't let fools fool you. They are the clever ones."
    15. Re:Had to exchange a motherboard by kbahey · · Score: 1

      The A8V-MX does not have a Promise chipset, only the VIA. I think the A8V Deluxe has them.

      The older VIA chipset works fine (as in my new A8V), it is just the newer one that are unrecognized. There is a patch in the queue already for it, but when you need a disk to install to so you can patch the kernel so you can see the disk, it becomes tricky.

    16. Re:Had to exchange a motherboard by kbahey · · Score: 1

      Thank you for the details.

      I think I tried this before exchanging the motherboard, and it did not work.

      Regards

    17. Re:Had to exchange a motherboard by kbahey · · Score: 1

      Details and links are on my web site, since people are asking me about it.

  25. Missing driver? by Anonymous Coward · · Score: 1, Interesting

    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?

    1. Re:Missing driver? by WhodoVoodoo · · Score: 5, Informative


      try hitting '/' on make menuconfig, type ov511 hit enter. That's a hot tip that's saved me quite a bit of time...
      It'll find it if it's there.

    2. Re:Missing driver? by Anonymous Coward · · Score: 0

      Thanks so much! Turns out, this driver, along with all the other USB multimedia/webcam drivers, were moved, so they are now sitting under the V4L (video for linux) category. This actually seems to be a much better place for these drivers than where they were before. This is a great tip, and I am not sure why, after a year and a half of using Gentoo and rolling my own kernels, I haven't found this feature. It will be quite handy in the future!

    3. Re:Missing driver? by Bent+Mind · · Score: 1

      I have a OV511 camera as well. Searching my memory and as I recall, the old driver under USB support was quite obsolete. It was supposed to be replaced with a new driver under a new name. Looking at 2.6.16, it's ovcamchip under Video for Linux. From the kernel:

      CONFIG_VIDEO_OVCAMCHIP:

      Support for the OmniVision OV6xxx and OV7xxx series of camera chips. This driver is intended to be used with the ov511 and w9968cf USB camera drivers.

      --
      Request a Linux Shockwave player here: http://www.macromedia.com/support/email/wishform/
    4. Re:Missing driver? by goaty_the_flying_sho · · Score: 1

      Or they could just use the updated driver.

    5. Re:Missing driver? by WuphonsReach · · Score: 1

      try hitting '/' on make menuconfig, type ov511 hit enter. That's a hot tip that's saved me quite a bit of time... It'll find it if it's there.

      Very handy tip, in the past I've resorted to grep'ing the kernel source code tree to find drivers.

      --
      Wolde you bothe eate your cake, and have your cake?
  26. Broadcom 43xx by atomic-penguin · · Score: 1

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

    --
    /^([Ss]ame [Bb]at (time, |channel.)){2}$/
    1. Re:Broadcom 43xx by Dhar · · Score: 1

      I very recently (last week) tried the native bcm43xx drivers as an alternative to my current ndiswrapper setup. For the record, this is with a Motorola WPCI810G PCI Adapter using the BC4306.

      It was a bigger pain to set up than ndiswrapper was, and once it was running would only go up to 11Mbit (my ndiswrapper setup could use the full 54Mbit). I stayed with ndiswrapper.

      So, personally, unless your goal is an untainted kernel I'd wait until the bcm43xx driver is more mature. You can always pitch in development effort, tho... :)

      -g.

    2. Re:Broadcom 43xx by atomic-penguin · · Score: 1

      I tried it a couple months ago. I got it to associate, but had no traffic.

      --
      /^([Ss]ame [Bb]at (time, |channel.)){2}$/
    3. Re:Broadcom 43xx by Dhar · · Score: 1

      I found that using bcm43xx, my card wouldn't work (I forget if it would associate or not) until I manually set the SSID, WEP, etc. I've seen on some discussion boards information about putting these commands into bootmisc.sh or what have you, so it seems to be a known, ongoing thing.

      -g.

  27. module shotguns by SuperBanana · · Score: 1, Interesting
    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."

    1. Re:module shotguns by Anonymous Coward · · Score: 0

      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.

    2. Re:module shotguns by l3v1 · · Score: 1

      it's pretty clear now that Linux's niche is, and perhaps always will be, the server market, where that's not as much of a concern (since hardware doesn't change a lot anyway)

      There are a lot of us out there who really don't mind comiling a new module when a new hardware finds its way into our computers. On decent hardware that usually doesn't take much time (yes, one could start arguing about what "decent" hardware is). I don't find that nor embarrasing, nor painful, it's something you have to do. On some other OS if you change video cards you have to uninstall the old driver, reboot, install new driver, reboot and almost done. I find this procedure more painful and more embarrasing.

      --
      I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
    3. Re:module shotguns by BrainInAJar · · Score: 4, Insightful

      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

    4. Re:module shotguns by Mintrubber · · Score: 1

      When was the last time you have used a Linux distribution? The ones I am currently using, including Debian, are capable of properly detecting the installed hardware and loading the appropriate modules. On Debian the service is called "discover", on Fedora it is "kudzu". No shotgun to be seen.

    5. Re:module shotguns by wertarbyte · · Score: 5, Informative
      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.
      Obviously you haven't used Linux for a long time. Modules are not loaded to detect hardware, instead the hardware acquires the driver module: The kernel identifies hardware via PCI or USB device ids, which are also stored in the modules. So Hotplug (and newer versions of udev) can load the appropiate module once hardware is added to the system.
      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."
      The driver will not be loaded if there is no hardware, unless you explicitly tell your system to do so.
      --
      Life is just nature's way of keeping meat fresh.
    6. Re:module shotguns by stsp · · Score: 1

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

      Better yet, print nothing. Linux is quite noisy while booting as is. Canned distribution kernels often print lots of messages from drivers that are not related to any hardware in the box. This is just annoying. It is solved much better in *BSD, where drivers seem to only print something once they've initialised their hardware.

    7. Re:module shotguns by Anonymous Coward · · Score: 0

      hm, is that why Linux starts up 2x as slow compare to WindowsXP now? I tried FC3, it's about 2x slower; and tried the new Ubuntu, it's about 3x slower.

      I had used FC1 on the same machine and it starts up faster than XP.

    8. Re:module shotguns by Anonymous Coward · · Score: 0

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

      Oh? If you're never had to wait for driver development to catch up with Linux development, it most likely just means you only use in-kernel modules. Two examples are alsa and ivtv (both open source). If you say they'll work fine without modifications with more recent kernel versions than their devs use, you're crazy, because a simple look at the history (for ivtv even the current releases, for alsa I'm not sure) shows you're wrong.

    9. Re:module shotguns by someone300 · · Score: 1

      I've nearly finished creating my own livecd from Debian unstable packages, and getting the hardware detection working reliably and fast was just a matter of enabling the modules in the kernel and starting udev/udevtrigger at boot with the appropriate permissions.rules and any custom rules installed.

      With the later kernels and udevs, you don't even need to have hotplug or tell the kernel what hotplug program to execute, as it uses a netlink socket. I was surprised at how reliable and easy it's become.

    10. Re:module shotguns by Anonymous Coward · · Score: 0
      When was the last time you have used a Linux distribution? The ones I am currently using, including Debian, are capable of properly detecting the installed hardware and loading the appropriate modules. On Debian the service is called "discover", on Fedora it is "kudzu". No shotgun to be seen.
      I belive it was discover+hotplug for woody. AFAIK it's hotplug for sarge (discover being used only to identify gfx cards matching them with the appropriate driver during the install), and it's udev in etch as it has now assimilated hotplug.
    11. Re:module shotguns by Anonymous Coward · · Score: 0

      FYI, ALSA is now the official sound system in Linux, and has been for the past few kernel revisions. It's not some separate project any more, which in some ways is a shame because it doesn't seem to be any better than OSS when it comes to being crap.

    12. Re:module shotguns by Lukey+Boy · · Score: 1

      It periodically uses rmmod to unload all unused modules too though, so after the "shotgun method" is used on the next run of rmmod your kernel will be smaller again.

    13. Re:module shotguns by Anonymous Coward · · Score: 0

      alsa is still developed as a separate project. You can use the kernel drivers, but often you can also use external drivers, even with kernels that can provide built-in alsa. Some people actually recommend you do so, as the in-kernel alsa is often buggy, apparently. (I never had problems with it myself, though.)

    14. Re:module shotguns by FireFury03 · · Score: 4, Informative

      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.


      Untrue I'm afraid. If your modules aren't in-tree then they *will* break every so often because the kernel API is not stable. Especially under the 2.6 development model - under the previous 2.4/2.5 model you were pretty much guaranteed that API breakages would only be happening in the 2.5 tree, now they happen at any point in the 2.6 tree. (Yes, I do know this stuff - I work on out-of-tree kernel code).

      There is some arguement that all drivers should be in-tree, and for common hardware it is definately a Good Thing to have the drivers in the tree - as the API changes then the person implementing the API change will fix up all the in-tree code that uses that API.

      For very specialist and expensive hardware it poses a problem though: the person who does the API change won't have the hardware to test with, and probably all the people who use that hardware are using enterprise distributions so breakages to the module won't be spotted for a long time. It's hard for the hardware vendor to track these kinds of updates and perform the necessary regression testing.

    15. Re:module shotguns by ragefan · · Score: 1
      Things like that are what I consider one of the more embarrassing things about the design of Linux. In fact, it really surprises me that in 2006, there is still not a true, separate driver interface API. It's pretty backwards that device drivers are a part of the kernel source tree, to be frank. However, it's pretty clear now that Linux's niche is, and perhaps always will be, the server market, where that's not as much of a concern (since hardware doesn't change a lot anyway).

      As opposed to when doing a new install of WS2k3, it tries to load every RAID and SCSI driver it has (especially, after I already told it I have a floppy for it).

    16. Re:module shotguns by Viol8 · · Score: 1

      "PCI or USB device ids"

      Fine if its a PCI or USB device. If its not its back to the
      old method of chucking modules at it and seeing what sticks.

    17. Re:module shotguns by rainman_bc · · Score: 1

      On some other OS if you change video cards you have to uninstall the old driver, reboot, install new driver, reboot and almost done. I find this procedure more painful and more embarrasing.

      What a load of crap.

      1. You turn your computer off to remove video card anyway. Either way you have to reboot unless you've got hot plug pcix and a lot of luck.
      2. You don't need to uninstall old drivers. If you replace an old video card, and your system finds a new one, it'll install the default drivers for the new one (same as Linux does), until you install the vendor's drivers. Linux doesn't include the nVidia drivers any more than "Some other OS" does.
      3. That "Some other OS" will then need a reboot after installing the new grpahics card driver. On Linux, it's pretty damned close - you need to restart X server. I realize the difference is an important one, but it isn't that different - something needs to be restarted either way.

      Not that I want to chime into the Linux vs. "Some other OS" debate, but c'mon... They just aren't as different as you are leading on....

      (Written by me on my FC4 laptop btw - I'm just not a fanboi)

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    18. Re:module shotguns by CastrTroy · · Score: 1

      Many modern distros also just display a nice splash screen with a progress bar (kind of like windows XP), and a message saying "Press ESC to show more information". It makes the boot-up process a little nicer for people who wouldn't know what the messages mean anyway. Actually I like the old style boot-up, because seeing all those "OK" messages lets you know that stuff is working.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    19. Re:module shotguns by Tweekster · · Score: 1

      Too bad for people still using ISA i guess

      --
      The phrase "more better" is acceptable English. suck it grammar Nazis
    20. Re:module shotguns by baadger · · Score: 1

      My guess would be too much junk compiled into the default kernel and a huge init script.

      For example, the Gentoo wiki page on speeding up boot time mentions switching to a different init script .

      Even on gentoo with all this taken care of however, my boot time to a shell prompt is slower than all the way to desktop on XP x64.

    21. Re:module shotguns by Viol8 · · Score: 1

      I was thinking more of standard parallel and serial port devices.

    22. Re:module shotguns by Anonymous Coward · · Score: 0

      About thirty minutes ago. Fedora Core 5 fucked up the detection of my DEC Tulip network card, didn't bother to tell me and left me with half a network. I had to manually fuck about with modprobe.conf to get it to load the "tulip" module instead of the "de2104x" module (Guess which one doesn't work with me card, then guess which one Fedora was loading) Then I had to manually fuck about with scripts in /etc/sysconfig, including manually changing the MAC address that is included in ifcfg-eth0

      Go Desktop Linux.

    23. Re:module shotguns by Eideewt · · Score: 1

      I'm with you most of the way, but restarting X is nowhere close to rebooting. Maybe if you're running some bloated desktop environment, but dropping back to my virtual terminal and typing "startx" just takes seconds.

    24. Re:module shotguns by BrokenHalo · · Score: 1

      Linux is quite noisy while booting as is.

      You can shut it up somewhat by adding "append = "quiet"" to your lilo.conf file.

    25. Re:module shotguns by Procyon101 · · Score: 1

      Yes, but booting up the OS on Gentoo is maybe a monthly task, whereas you are going to be taking a reboot required update on XP more frequently than that... so in total time spend booting during the life of a machine... :)

    26. Re:module shotguns by runderwo · · Score: 1

      Parallel devices that are IEEE1284 compliant have an identification string that can be used to automatically load modules. Serial devices have no standardized method of byte-wise bidirectional communication so such a scheme is impossible for a standard RS232 serial port. You will find that in Windows, the only "Plug&Play" serial devices are modems, and the reason why is that modems have identification strings, built into the modem firmware and accessed via the Hayes command set (ATI*), that can be used to identify them.

    27. Re:module shotguns by runderwo · · Score: 1

      Even ISA-PNP devices are handled like this. No, there is no such thing as the Win95 "Add New Hardware" scan, and for good reason - it is an unreliable way to detect hardware and can also crash the system or corrupt data. So yes, if you have a non-PNP ISA device, or serial device, or some other device that does not provide the system with a way to passively observe its presence and resource requirements without requiring the system to know how to access it, then you are out of luck with respect to automatic module loading. Fortunately, such hardware is usually quite obsolete by now.

    28. Re:module shotguns by runderwo · · Score: 1
      Sure there is. There's just not a consistent ABI, and that's on purpose.
      What in the world are you talking about? The Linux ABI is EMINENTLY stable, and *that* is on purpose. See Documentation/ABI. Application binaries compiled for Linux 1.x still run today, that is a testament to its ABI stability like no other.
    29. Re:module shotguns by HeroreV · · Score: 1

      Not if you have your computer in your bedroom, you don't want it buzzing away while you're trying to sleep, and you can't figure out how to enable sleep mode. Many people would just give up after not finding a stand-by button.

    30. Re:module shotguns by Viol8 · · Score: 1

      Sending ATI* to anything connected to a serial port doesn't seem like a very
      clever idea since it could possibly have wierd effects on non modem hardware.

    31. Re:module shotguns by shellbeach · · Score: 1
      My guess would be too much junk compiled into the default kernel and a huge init script.

      It's not the kernel - that takes all of a few seconds to load. It is indeed the init scripts, many of which you're probably not using, and many of which are serial (i.e. not backgrounded) and cumbersome. On my old desktop, I tweaked the init scripts to remove all the useless crud and to background the important stuff that didn't need to be loaded in serial. The result was a boot time of 12 secs from power on to gdm.

      However, on my laptop I haven't bothered - thanks to swsusp2 I hardly ever reboot so it's not worth worrying about ...
    32. Re:module shotguns by Procyon101 · · Score: 1

      You're just not conditioned enough. I am lulled to sleep by the sound of whirring, healthy servers :)

      Unfortunately though, My girlfriend is not, so the servers now sleep outside the bedroom.

  28. Quota BUG() fixed? by Anonymous Coward · · Score: 1, Interesting

    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!

    1. Re:Quota BUG() fixed? by layer3switch · · Score: 1

      What version of RHEL4 kernel are you using?

      --
      "Don't let fools fool you. They are the clever ones."
  29. get with the program by r00t · · Score: 0, Redundant

    Dude, Linux makes everything better!

  30. Re:Video Editing? by Anonymous Coward · · Score: 5, Informative

    Insightful? How about Kino or Cinelerra or Lives or Mainactor?

  31. Re:Obligatory. . . by Slashcrunch · · Score: 1

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

  32. Sounds good by goodenoughnickname · · Score: 4, Funny

    Sounds good -- how much does it cost?

    Sincerely,
    The New Guy

    1. Re:Sounds good by debiansid · · Score: 1
    2. Re:Sounds good by Anonymous Coward · · Score: 1, Funny

      Not much, only all your social life :D

    3. Re:Sounds good by Khaed · · Score: 1

      This is not true. Since I started using Linux my social life is just fine, sort of.

      I can't figure out why everyone I know is now male and owns 2d20 dice, though.

      Maybe that'll change with 2.6.18. We need a "girl" module...whoops, gotta go, Leroy's glasses broke and he needs me to drive him to get some duct tape.

  33. Great, how about stable firewire support someday? by Anonymous Coward · · Score: 0

    Firewire still sux on linux.

    When will it work?

  34. Re:Nice by Frogbert · · Score: 5, Funny

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

  35. How many Network Adapter Cards in a server? by billstewart · · Score: 1
    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.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    1. Re:How many Network Adapter Cards in a server? by layer3switch · · Score: 1

      I agree, but you are counting out RMI like HP iLO and Dell DRAC which are over ethernet. So it's easy to spot at least 3 to 4 NIC on E class servers. However you are right, as far as NIC drivers is concern, the most 2 drivers will suffice since RMI hardware abstraction is separated from OS.

      --
      "Don't let fools fool you. They are the clever ones."
  36. Re:Video Editing? by Anonymous Coward · · Score: 0

    Ever heard of a little program called Avid?

  37. Re:Nice by x2A · · Score: 1

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

    --
    The revolution will not be televised... but it will have a page on Wikipedia
  38. "splice" - because Microsoft did it? by Animats · · Score: 4, Interesting

    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.

    1. Re:"splice" - because Microsoft did it? by Frater+219 · · Score: 2, Informative
      "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.
      On the contrary, there are many cases in a dynamic serving system where you can determine that, after some point, the rest of the operation merely involves copying data from a file or buffer out to the network. Or, similarly, that a large portion of the operation involves such copying.

      So even though the whole operation can't be reduced to a splice() or sendfile(), a substantial portion of it can. And the speed improvement you take isn't just that you avoid copying -- as "zero copy" implies; you also avoid unnecessary cache dirtiness.

      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.
      I wonder what your sample size is for "usual" there. As far as I can tell, you discuss only one case where this is so: Windows. And since we know that Windows has lots of other architectural problems leading to crashes, and in any event has an architecture entirely different from Linux's, we know that case to be irrelevant.

      All in all, your analysis is critically, embarrassingly bad. There is no "serving Web pages from the kernel" going on here. There is simply an optimization for a common case, with no degradation to the less-common cases -- that's why it's implemented as a separate system call.

    2. Re:"splice" - because Microsoft did it? by Anonymous Coward · · Score: 0

      The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel.

      I'm SO glad that httpd is just a figment of my imagination then. Funny, if it were to exist it would do exactly the same things as Microsoft's http.sys that you're crying about. Oh wait...

    3. Re:"splice" - because Microsoft did it? by ookaze · · Score: 2, Informative

      The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel

      WHat is this nonsense ? The khttp in-kernel web server was implemented on Linux first, then copied by MS.
      IIRC it isn't even in 2.6 kernels anymore.

      So now Linux has a comparable "zero copy" facility

      Linux already had a zero-copy facility, splice is just a new improved one.
      What are you talking about ?

      "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 in this case. Linux made it right.

    4. Re:"splice" - because Microsoft did it? by diegocgteleline.es · · Score: 1

      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.

      Splice is not about serving web pages from the kernel, the in-kernel web server was removed years ago. I don't know where did you get that idea...

    5. Re:"splice" - because Microsoft did it? by CrayzyJ · · Score: 1

      > The "splice" system call seems to be an answer to one of Microsoft's bad ideas - serving web pages from the kernel.

      Linux did this as well. See the Tux web server.

      >"Zero copy" tends to be overrated.

      no No NO! Zero-copy has been proven as a good thing several times over by top researchers in top conferences. Get your facts straight dude. Zero-copy is a Good Thing across several real-world workloads. Web servers using sendfile outperform those that use copies. Viewing the cache profiles from each explains why.

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

      Performance goes up a lot. The number of crashes is a result of poor programming. The Linux version of SendFile is (was) very stable under massive send-heavy workloads. The number of crashes was not increased in the slightest.

      --
      Holy s-, it's Jesus!
  39. Re:You're such a square. by pembo13 · · Score: 1

    Interesting comment. I hope you don't reproduce.

    --
    "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
  40. OK, so where are they? by phorm · · Score: 1
    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?
    1. Re:OK, so where are they? by narfbot · · Score: 1

      It's tagged experimental. The driver is not stable enough though works for some people.

    2. Re:OK, so where are they? by Anonymous Coward · · Score: 0

      Is your cpu multi-core? That's what the new scheduler is for.

    3. Re:OK, so where are they? by tomstdenis · · Score: 4, Interesting

      You listed I/O schedulers. I think the multi-core bit talks about a PROCESS scheduler. Two different things. Linux already has specific support for Intel's HTT bullshit and understands NUMA. Understanding multi-core is a good move up.

      If you have a 2P dual-core setup the best performance for two independent tasks would be spread to both chips. Specially in the AMD camp. That means each task gets a full memory bus to themselves. The trick is to pick up when two tasks have shared memory between each other and schedule that for one chip. Specially on the Intel side of things with their massive shared L2 cache.

      Tom

      --
      Someday, I'll have a real sig.
    4. Re:OK, so where are they? by timbo234 · · Score: 1

      Am I missing something here?

      Yes, you have to enable the PCI, IEEE80211, IEEE80211_SOFTMAC, NET_RADIO, EXPERIMENTAL options if they aren't already enabled (see drivers/net/wireless/bcm43xx/Kconfig). I just went through the same confusion this morning, I was only missing the IEEE80211_SOFTMAC thing.

      Now when I get home from work I can reboot into the new kernel and see if those drivers actually work. It'll save me having to pay for Linuxant's DriverLoader when the trial period runs out.

      --
      Pre-canned Evolution Links for all those Slashdot holy wars.
    5. Re:OK, so where are they? by Anonymous Coward · · Score: 1, Informative

      Networking -->
           <M>   Generic IEEE 802.11 Networking Stack
           [*]     Enable full debugging output
           <M>     IEEE 802.11 WEP encryption (802.1x)
           <M>     IEEE 802.11i CCMP support
           <M>     IEEE 802.11i TKIP encryption
           <M>     Software MAC add-on to the IEEE 802.11 networking stack
           [*]       Enable full debugging output

      Device Drivers --> Network device support --> Wireless LAN drivers (non-hamradio) & Wireless Extensions
           <M>   Broadcom BCM43xx wireless support
           [*]     Broadcom BCM43xx debugging (RECOMMENDED)

  41. not like that by r00t · · Score: 4, Informative

    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.

    1. Re:not like that by master_p · · Score: 2, Informative

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

      I think you are wrong. Splice'd data are not processed by userland at all: they are piped from one file to the other at kernel level by page copying.

    2. Re:not like that by cnettel · · Score: 2, Informative

      Your parent is right. The user mode code can control what happens to data, without ever mapping it to its own memory. You are right in that it's not processed, but that's not what the original post said.

    3. Re:not like that by master_p · · Score: 1

      I think the term "manipulate data" applies more to process data and not simply redirect data. Splice simply redirects data from one file to another, from my understanding so far.

    4. Re:not like that by r00t · · Score: 1

      "manipulate data" == tell the kernel where it goes and when to duplicate or discard it

      "have it copied" == run the kernel's copy_to_user function so the app can directly examine the data

      Page copying is avoided, as is page remapping. Linux adjusts pointers to the beginning and end of the data. It can be that the CPU never touches the data.

  42. NTFS by wolf369T · · Score: 0

    A better NTFS write suppport will be greatly appreciated...

    1. Re:NTFS by Anonymous Coward · · Score: 1
    2. Re:NTFS by Ruie · · Score: 1
      A better NTFS write suppport will be greatly appreciated...

      Have you tried asking Microsoft about this ? Perhaps, while they are writing a Linux patch they could also stop Windows from fragmenting files so much.

      :)

  43. Re:support for the h.323 protocol, quite unlikely by nick+this · · Score: 4, Informative

    I read that as ip conntracking to allow videoconferencing devices that follow the h.323 standard to be natted.

    obtw: your pedant bit is apparently stuck high. just a fyi -- didn't know if you realized it. :)

  44. Glad for AirPort Extreme support by dn15 · · Score: 1

    OK, so I use Linux on a PC desktop but I don't actually run it on my Mac. That said, I'm glad support for AirPort Extreme has finally come. It has long been impractical to run Linux on Mac laptops without an extra wireless USB dongle for 802.11 due to the lack of driver for that Broadcom chipset. This update is a huge deal for anyone interested in running Linux on a Mac made in the last few years.

  45. Re:Video Editing? by Anonymous Coward · · Score: 0

    So... Avid on OS X? What's your point?

  46. Re:Video Editing? by inflex · · Score: 1

    Mm....wonder if this would work on my dual-CPU Opteron 248 (Running Slamd64).

    I'm currently using MainActor 5.5 (for linux).

  47. Re:Nice by BEHiker57W · · Score: 1

    Move on up to 2.4.10 now! 2.4.9 had serious problems. Journaled filesystems rock; especially if you ever have the misfortune to need to reboot. And 2.4.9 supports only resierFS and it has giant data-losing bugs in the 2.4.9 integration. Reiser works great in 2.4.10. 2.6 adds XFS and JFS, too.

  48. Re:Video Editing? by Anonymous Coward · · Score: 0

    The Penny Arcade guys have a different idea.

  49. Re:support for the h.323 protocol, quite unlikely by rodac · · Score: 1

    "I read that as ip conntracking to allow videoconferencing devices that follow the h.323 standard to be natted."

    Still pretty unlikely. The only thing that differs between say H.323 and SIP initiated voip or videoconferencing or the others is how the signalling works.
    After all signalling is done, the actual voice or video is just normal standard RTP traffic anyway.

    H.323 differs from SIP in that the signalling is performed through two main protocols h.225 and h.245 which are both encoded using asn1 aligned-PER. This is a really compact encoding and it does require a massive amount of code in order to implement decoders for. I know because I have written aligned-PER decoders. We are talking about many thousands on lines of code just to unmarshall the packets.

    SIP on the other hand is just implemented as additional methods for HTTP and is encoded in simple ascii text. A SIP decoder can be written in 100 lines or less and is trivial.

    Why is signalling important? Signalling is where tou actually handshake end to end which ports to use for the RTP session. A h.323 connection tracking module for h.323 would therefore require unmarshalling of h.225 and h.245 something i think would be very very very unlikely to include inside the kernel.

    For the other responder to my initial post. I have taken your offer into consideration but have decided to decline.

  50. Re:Great, how about stable firewire support someda by Solra+Bizna · · Score: 5, Funny

    The above comment has been marked WORKSFORME, and is now closed.

    -:sigma.SB

    --
    WARN
    THERE IS ANOTHER SYSTEM
  51. There are plenty. by Inoshiro · · Score: 1

    The thing is, there aren't too many people who would consider the performance trade off worth it. Spin is written in Modula-3 and goes under the idea that you can have compile-time memory checking, among other things, to certify that the code is complete & correct without having to do dynamic analysis.

    How many programmers know Modula-3? How many commercial companies are going to be willing to back Modula-3 because of this? How many hobbyists can contribute?

    There are, essentially, 3 operating system groups: The Windows family (written in C/C++), the Unix family (written in C, although members like MacOS X use C++ for kernel extensions), and everybody else. No one really cares about the final group, but it includes a lot of non-C kernels and libraries. I've generalized the everybody else because they're a fraction of a percent of OSes running on computers everywhere.

    NASA would only use OSes written in ADA for reasons of completeness and correctness, for example, but you won't find that on anyone's desktop.

    --
    --
    Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
  52. infrared for IBM thinkpads by Rizzer · · Score: 2, Interesting

    I think they've added the driver to support the IR infrared port on IBM (Lenovo) thinkpads, at last!

    1. Re:infrared for IBM thinkpads by Anonymous Coward · · Score: 0

      huh? i've been using my IR port (x41) for ages...

  53. Re:support for the h.323 protocol, quite unlikely by nick+this · · Score: 3, Informative

    Unlikely or not, that's what it appears to be. h.323 conntrack nat helper

    This patch (or module, actually) comes with an H.323 decoding library that is based on H.225 version 4, H.235 version 2 and H.245 version 7. It is extremely optimized for Linux kernel and decodes only the absolutely necessary objects in a signal. ... The total size of code plus data is less than 20 KB.

    Doesn't look like a gatekeeper or anything, that looks like an honest-to god ipconntrack nat implementation.

    For the other responder to my initial post. I have taken your offer into consideration but have decided to decline.
    lol.

  54. Re:Video Editing? by Anonymous Coward · · Score: 0

    Gimp - frame by frame editing!

  55. Re:Reality by x2A · · Score: 1

    "After only 3 months how can so much software be reliably tested?"

    Which software exactly has only been tested for three months?

    "I thought there was a bunch of static flying around about version 2.5 of the kernel"

    The 2.5 kernel was a developers playground, experimentation etc, not meant to be a stable can-run-life-support OS. A place for the open exchange of ideas, that's all.

    "If you build software on a broken foundation you will only get broken software"

    Well what we're talking about here is people improving the quality and efficiency of the foundation, and releasing their work. This is a Good Thing(tm).

    --
    The revolution will not be televised... but it will have a page on Wikipedia
  56. Re:Video Editing? by Bent+Mind · · Score: 3, Informative

    I've been doing video editing with Avidemux. It's a nice little program for Windows, OSX, and Linux.

    --
    Request a Linux Shockwave player here: http://www.macromedia.com/support/email/wishform/
  57. Re:You're such a square. by Pink+Tinkletini · · Score: 0, Troll

    Nothing personal, I mean, unless you share the sentiments expressed by the original poster. It sounded like he could use an ass-ramming more than anyone else I know.

  58. Indeed, Airport Extreme support is HUGE by RedBear · · Score: 5, Insightful
    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.

    1. Re:Indeed, Airport Extreme support is HUGE by Anonymous Coward · · Score: 0
      This driver will open up several million possible new computers for Linux to be installed on
      and then ten minutes later be reformatted and and have osx reinstalled :P
    2. Re:Indeed, Airport Extreme support is HUGE by bh_doc · · Score: 1

      I was wanting to install Linux on my iBook for a few months now. This driver was one of the reasons I finally did it (the other being the way MacOS X works was really starting to piss me off).

      Unfortunately the only time in a while where I'll have an opportunity to give the wireless a go, last night, it wasn't behaving. It dropped out somehow, and then couldn't get any DHCP offers. Not sure where the problem lies, but new drivers are always a prime suspect.

      Anyway, it's cool that with bcm43xx and r300, all the hardware on this machine is driven by open source! (Except maybe a firmware or two...)

  59. suggestions for a laptop by Anonymous Coward · · Score: 0

    Hoping for some suggestions for a laptop. I'm wanting to buy at 64 bit something, with nvidia (so graphics have a chance to work).

    I'm willing to pay for a good machine, and I'm currently thinking of the http://www1.ca.dell.com/content/products/productde tails.aspx/xps_m1710?c=ca&l=en&s=dhs&cs=CADHS1

    If anyone has had experiences using linux on this, or on another similar beasty I'd like to know about it.

    1. Re:suggestions for a laptop by devlp0 · · Score: 2, Interesting

      Looks a good laptop. The only trouble I have ever had with laptops/Linux are: 1) internal modem doasnt work (M$ modems - who cares anyway) 2) might need to disable apic at boot time (will be obvious - machine just wont boot. Add "noapic" to you kernel boot parameters if this is the case) Nvidia drivers can be downloaded from their web site - not open source though :(

      --
      >/dev/null 2>&1
    2. Re:suggestions for a laptop by cab15625 · · Score: 2, Interesting

      Wow, looks like a sweet machine.

      My advice, if you really want to be sure, take the time to go through the hardware specs and check the kernel source for drivers for each thing you definitely want to have running (be careful of versions)

      You could also check out the linux on laptops site

      Finally, I've noticed that the biggest problems for me in the past have always come in with ACPI support. This is where the most noticable improvements(*) in the kernel have come for me lately. You might want to check out the ACPI4Linux site to see if there's anything special that's been discovered about your system yet.

      * It's actually not a problem with Linux, it's a problem with the way some OEMs do ACPI using tools from M$ that the kernel guys have been doing a better and better job of working around. Who needs standards when you think you pwn the world.

    3. Re:suggestions for a laptop by dogmatixpsych · · Score: 1

      I'm not sure if you realize that that Dell is not 64 bit. Maybe you do, but I'm not sure so I'm just letting you know. If you want to go with Dell then you should wait a few months until the Core 2 Duos come out (they are 64 bit).

  60. Mod parent up by jb.hl.com · · Score: 1

    FreeBSD's driver support has been perfect for me, and nowhere near as painfully inadequate as that of Linux. A working OSS implementation comes in handy too.

    --
    By summer it was all gone...now shesmovedon. --
    1. Re:Mod parent up by Anonymous Coward · · Score: 0


              Because I could not stop for Death,
              He kindly stopped for *BSD;
              The carriage held but just our bad code
              And Immortality.

              We slowly drove, he knew no haste,
              Passing Linux, we dared salute, a foe superior
              My coding work was but a-waste,
              Doomed OS a triviality.

  61. That and by Sycraft-fu · · Score: 4, Informative

    For kernel operations, you want everything pretty efficient. You want it as fast as possible and you don't want a lot of extra code hanging around. Unfortunately, the higher level a language you use, the more inefficency there is. For most programs it doesn't matter. They are either not the sort of thing that needs speed (like a word processor) or one where you can optimize the small part of the code that takes most of the time (like a game). However the kernel is a little different. Everything in there is time critical essentially.

    C is the best compramise. While assembly might give you the theoritical best code, it'll big a giant mess to try and totally unmaintainable. Might actually be slower and larger for it. C is pretty good because it's easy enough to generate deceant code in, but it isn't much higher up the abstraction chain so it compiles quite efficient.

    You have to remember that object orientation and such are all human creations. Processors don't think in objects, for that matter they don't really even think in functions. They think in memory locations, and jumps to those locations. Doing OO code means a whole messy layer the compiler has to go through to translate that in to something the processor actually understands.

    1. Re:That and by molarmass192 · · Score: 1

      Also debugging more than a few lines of assembler code is a f-ing nightmare. The again, I've never gotten a kernel patch accepted, so, maybe I'm just skilled enough! ;)

      --

      Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
    2. Re:That and by menace3society · · Score: 1

      The advantage to C is primarily not that's it's readable (C can be pretty arcane, and assembler for a given hardware platform is easy to follow once you've familiarized yourself with the basic instruction formats), but that it's portable (in fact, one of the best quotes I've heard about C is that it combines all of the power and flexibility of machine code with all the elegance and readability of machine code). The readability is largely a side effect of choosing a good base of common syntax objects (loops and operators), with a not-too-large and completely separable library for all the complex tasks like I/O.

      Remember, for years people wrote all their operating systems in assembler--until late '73 the Unix kernel was still all-assembler, and if DMR had developed a low-level language with ugly syntax but all the other good characteristics of C, we'd probably be using that instead.

    3. Re:That and by joib · · Score: 1


      You have to remember that object orientation and such are all human creations. Processors don't think in objects, for that matter they don't really even think in functions. They think in memory locations, and jumps to those locations. Doing OO code means a whole messy layer the compiler has to go through to translate that in to something the processor actually understands.


      That being said, Linux is written in a somewhat object-oriented style. Structs with pointers to functions and so on. It's just that some of the OO stuff is done manually by the programmer (setting up the pointers during init and destroy, calling functions via pointers instead of member functions etc.), and not automatically by the compiler.

      I guess if one were to start a kernel project today, C++ would be a serious option. But when Linus got started in 1991 (?), there was no C++ standard, and g++ was crap.

    4. Re:That and by k98sven · · Score: 2, Insightful

      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.

    5. Re:That and by Anonymous Coward · · Score: 0

      I agree completely, however, when you said "A higher level language is only as inefficient as the compiler and/or libraries used.", you left out the inefficiency of the developer. Nearly every language has the potential for efficency and legibility, just as they have for inefficiency and messy code.

      I think hardware advancement and rediculously forgiving languages lead way for this kind of thing though. Take the concept of the garbage collector, for example; a good idea for those really tricky situations, but it leads to lazy and inefficient code. "cool, it works! so what if it consumes 80% resources to do a simple task... I wasn't using it anyway." ...a few months later people wanna buy faster computers. It's not the hardware's fault its overloaded with pointless and bloated software... its Microsloths :)

    6. Re:That and by BalkanBoy · · Score: 1

      C is like assembly on steroids ;). (sorta like VI on steroids = emacs - ok, well maybe not quite a good analogy, but you get the point). C is going to stick around for as long as we are going to write operating systems (IMHO).

      --
      'A lie if repeated often enough, becomes the truth.' - Goebbels
  62. Broadcom 43xx HOWTO: by cbhacking · · Score: 5, Informative

    Haven't tried the release of 2.6.17 yet, but rcX versions required extracting the firmware for your Broadcom card from a binary such as bcmwl5.sys (Windows driver). The tool bcm43xx-fwcutter does this.

    I'm not an Ubuntu guy, but this reference might be useful to anybody trying to make the new Broadcom Wifi driver work in Linux. Very easy steps, and most non-Ubuntu users should find it easy to adapt for their specific distros.

    --
    There's no place I could be, since I've found Serenity...
    1. Re:Broadcom 43xx HOWTO: by t35t0r · · Score: 1

      Stop right there. I'm not cutting any firmware and I don't care what it does. I want to just modprobe it and it should just work. Anything else is a broken driver.

      I like ndiswrapper because currently it just works and it doesn't break anything in windows.

    2. Re:Broadcom 43xx HOWTO: by Anonymous Coward · · Score: 0

      No. Not a broken driver. A broken device.

      Remember that firmware runs IN the device, and not in the driver. Instead of having a $0.15 or $0.50 EEPROM for the firmware on the device, Apple and others decided that they can have it loaded from the host by the OS.

  63. Re:support for the h.323 protocol, quite unlikely by rodac · · Score: 3, Interesting

    Bloody hell!

    They managed to squeeze both PER and also H225/235/245 into just 20kbyte of object code?!
    (why implement h235? thats crypto and wouldnt work unless you know the keys?)
    That is VERY impressive.

    My PER decoder alone ( http://anonsvn.wireshark.org/wireshark/trunk/epan/ dissectors/packet-per.c ) is way larger than that, and that is just aligned PER decoding (ok with some unaligned PER additions recently) and that one itself is >>20kbyte. Adding 225/245 into the mix. Impossible!


    I am very impressed. Very impressed.

  64. Re:support for the h.323 protocol, quite unlikely by aXis100 · · Score: 1

    nick_this said: I read that as ip conntracking to allow videoconferencing devices that follow the h.323 standard to be natted.
    rodac said: Still pretty unlikely

    I agree with nick, even before seeing the description. There used to be an experimental patch for h.323 netfilter connection tracking, which is now included with the kernel.

    Oh, and I also agree with nick about the Pedant bit.

  65. Re:support for the h.323 protocol, quite unlikely by Anonymous Coward · · Score: 1, Informative

    With this module you can support H.323 on a connection tracking/NAT
    firewall.

    This module supports RAS, Fast-start, H.245 tunnelling, RTP/RTCP
    and T.120 based data and applications including audio, video, FAX,
    chat, whiteboard, file transfer, etc. For more information, please
    see http://nath323.sourceforge.net/.

  66. Re:Video Editing? by rasjani · · Score: 1
    --
    yush
  67. A little OT by castlec · · Score: 1

    GOTO statements have their place. They should only be used by people who know what the hell they're doing. GOTO statements are faster; however, they violate the models used for function calls. Mixing GOTOs with function calls can reak all kinds of havok in running code and you won't be able to see it without looking at the assembly. We are all taught to not use GOTO out of safety. When possible, a compiler will replace standard function calls(stack pushes and pops with a jump at each side) with just two jumps. Once the mechanism is fully understood and carefully coded it can be a powerful ally.

    --
    When I tell an object to delete this, am I killing it or telling it to kill me?
  68. Re:support for the h.323 protocol, quite unlikely by pembo13 · · Score: 1

    And this is why it is suggested that everyone builds their own kernel at lest once. Nick is exactly right.

    --
    "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
  69. Server by Anonymous Coward · · Score: 0

    Server patched from 2.6.16.17 running, 2.6.16.20 installed, to 2.6.17 installed.
    Now let's see how long it takes before I have to reboot to try this new thing. ;)

  70. Re:Video Editing? by Anonymous Coward · · Score: 0

    Umm, why hasn't anyone mentioned Shake?

  71. Re:Video Editing? by KayosIII · · Score: 1

    In the OS corner there is Cinelerra, Kino & Lives

    For home use (commercial) there is MainActor.

    For compositing there is just about all of the major apps including smoke,shake,nuke3.

    Also Blender makes a fairly decent Compositor (more so in the soon to be released version).

  72. a new bug... by Anonymous Coward · · Score: 0, Funny

    ... has been released! btw, i thought they were gonna release 2.6.16.61.23.2344_34.

  73. Re:support for the h.323 protocol, quite unlikely by rodac · · Score: 1

    I stand corrected and am very impressed with the fact they managed to implement this in so little code.

    My doubts were based on having first hand experience implemented PER/H225/H245 myself and knowing how huge and complex they are. That they managed to squeeze even the smallest required subset of the problem space into a 20kb object module to just extrack the ipaddress/portnumbers is very very impressive.

    As someone that knows PER/h225/h245 really well I say : very impressive!

  74. SPIN is still around? by tap · · Score: 1

    I take it it's been ported to non-Alphas? All the device drivers still written in C? I wrote the IP fragment reassembler and NFS filesystem for SPIN years ago. Didn't know modula-3, but I managed to make the my code work anyway.

  75. noticable vs. measured by CarpetShark · · Score: 1

    Sounds like you have a bad case of upgrade infatuation ;)

  76. Re:Question for the masses. module2kernel? by Anonymous Coward · · Score: 0

    cannot module everything first? then have the system look in the mirror;
    see is looking good (shaved and combed) then have it (automagically)
    compile a kernel from working/needed module situation *shrug*

  77. SCO's drained... by vingt · · Score: 0, Offtopic

    SCO knows that this update was released only to make their Caldera announcement look bad. Just when they got a handle on the 2.5 codebase, the 2.6 has been advanced yet further. Their lawyer-by-day, codemeister-by-night personnel can't keep up. The hide-from-it-by-day, suck-at-it-by-night schedule is killing their undead.

  78. Re:Video Editing? by peterpi · · Score: 2, Funny

    split, cat and sed.

  79. Re:Video Editing? by zsau · · Score: 3, Funny

    Using a graphical editor? I edit my videos by converting them to a series of jpeg images (one per frame) and using ed to edit them! Damn efficient, quality results.

    --
    Look out!
  80. DCCP by caluml · · Score: 2, Interesting

    DCCP - a kind of UDPv2
    Any applications out there using it yet?

    1. Re:DCCP by Fzz · · Score: 1
      Any applications out there using it yet?

      Not much yet - there's a bit of a chicken-and-egg issue. You need stable implementations of a transport protocol before anyone will use it, but there's not much demand for the implementations before applications are asking for it. So, these sort of changes deploy rather slowly. We'll get there though - the Linux DCCP code is just starting to get stable now.

      Lets of information about DCCP is here if you're interested.

      - Mark (one of the author of DCCP)

    2. Re:DCCP by caluml · · Score: 1
      Not much yet - there's a bit of a chicken-and-egg issue.

      Like IPv6 too then. I've been v6 enabled and hooked up for ages. Can't believe Google and Slashdot don't do v6 yet.

      I'm going to write an IPv6 DCCP webserver. That'll never get slashdotted!

  81. What is the klibc for? by Marc+Tanner · · Score: 2, Interesting

    Does somebody know for what purposes the klibc which is now in -mm will be used for? I guess this implementation will only provide a subset of the features found in uclibc, but i am not sure about that. Will it even be possible to link userspace programs against it?

    I am a little confused right now, have to read up on it.

    1. Re:What is the klibc for? by diegocgteleline.es · · Score: 1

      As I understand it, the goal of klibc is "replacing" and extending the idea of initrd. Yes, you can link userspace programs against it. It's a library used by userspace, not by the kernel. The kernel boots, then it runs kinit, which is a userspace program linked against klibc. From the documentation, It currently replaces the kernel's ipconfig and nfsroot code. It does all this before loading your root filesystem - in fact, it looks like it will be those userspace programs who mount your root filesystem, moving even more kernel code to userspace. I remember reading emails about moving things like ej: partition detection or volume discovery, or even scanning SCSI/IDE busses to klibc (so it can be done in parallel and bootup can be faster), but don't take my word seriously at all.

  82. Re:module shotguns AKA the windows way.... by Nichole_knc · · Score: 0, Flamebait

    Windows kernel = about a gig these days loads... EVERYTHING you can imagine.... Why anyone with a modern machine with XP would want to run something from windows 95/98 era is beyond me.... Come to think of it anyone who would want a windows machine as a full time machine is too beyond me.... But give a hand to the noobs at least they are trying... Now get off the distro candy kernel and build your own....

  83. Re:Video Editing? by miracle69 · · Score: 3, Informative

    I recently ran across jashaka which is also cross-platform.

    --
    Linux - Because Mommy taught me to Share.
  84. Re:Great, how about stable firewire support someda by CoonAss56 · · Score: 1

    Never. Firewire is dead even on OSX.

    --
    Won't Bow.....Don't Know How
  85. Re:Nice by Anonymous Coward · · Score: 0

    No problem, just take your box down to the gas station and blast it with compressed air.

  86. Broadcom 57xx by phrostie · · Score: 1

    what about the Broadcom 57xx?

    1. Re:Broadcom 57xx by LinuxOnEveryDesktop · · Score: 2, Informative

      what about the Broadcom 57xx?

      That's Broadcom's wired gigabit interface. Has been *long* supported by the tg3 driver. Heck, Broadcom even has an alternative GPL'd driver for this interface downloadable from their website.

    2. Re:Broadcom 57xx by phrostie · · Score: 1

      i've tried both.

      both compiled without a hitch.
      modconf will load either without a hitch.

      but iwconfig still shows no wireless devices.
      i probably need to feed it some addresses, but i'm just not sure what.

    3. Re:Broadcom 57xx by LinuxOnEveryDesktop · · Score: 1



      both compiled without a hitch.
      modconf will load either without a hitch.

      but iwconfig still shows no wireless devices.
      i probably need to feed it some addresses, but i'm just not sure what.


      You're confused. The 57xx is a hard-wired gig-ethernet port.

      The 43xx is a wifi card.

      If you want 43xx drivers, try the latest linux kernel (2.6.17), which now has support for those devices it seems - not yet tried it though.

  87. S-ATA hotplug by Dolda2000 · · Score: 2, Interesting

    Looking through the ChangeLog, I still see no S-ATA hotplug. I've been waiting more or less since the day S-ATA support was introduced in Linux to be able to add new drives without rebooting, and I just cannot understand how such a thing can take so long. I mean, I'm sure that the kernel developers have priorities and stuff, but I would think that adding S-ATA hotplug ought to be simple and important enough not to take more than a year to even get started...? I don't mean it as a complaint, I just find it really weird. Is it just much harder than I think, or is there no particular reason for it not having been done?

    1. Re:S-ATA hotplug by The_Morgan · · Score: 2, Informative

      I setup a backup system using DAR and SATA hard drives, since they are a fairly cheap backup medium. I wanted hotplug, really just hotswap so I could take out the full drive and put in an empty one. The commands I found after searching went along the lines of:

      echo "scsi remove-single-device 3 0 0 0" >/proc/scsi/scsi
      echo "scsi add-single-device 3 0 0 0" >/proc/scsi/scsi

      It has to be watched through dmesg, sometimes the drive migrates from /dev/sdX to the next unused letter. The other thing I noticed is that the drive has to be online while booting up to be available, it wouldn't find a new drive. It has been a while since I set the system up so I should upgrade to find out if this still applies.

    2. Re:S-ATA hotplug by labratuk · · Score: 2, Informative

      http://linux-ata.org/software-status.html#hotplug

      It's not just a matter of enabling it, it's about making it reliable.

      More here: http://linux-ata.org/features.html

      --
      Malike Bamiyi wanted my assistance.
    3. Re:S-ATA hotplug by Ender+Ryan · · Score: 1
      It would certainly be a huge boon for users using Linux-raid. I switched to using Linux' built-in software raid after having had far too many hardware raid controllers fail. I'm sure more expensive controllers are probably still reliable(ie., $1,000+ SCSI controllers), but these $400-$600 SATA HW Raid controllers are absolute junk.

      --
      Sticking feathers up your butt does not make you a chicken - Tyler Durden
    4. Re:S-ATA hotplug by Dolda2000 · · Score: 1
      That's very interesting. FYI, I looked through the kernel sources a bit, and there is an equivalent way to do it through sysfs (might be interesting, since /proc/scsi is on its to deprecation). To delete a device, do e.g. "echo anything >/sys/block/sda/device/delete", and to rescan a host, do "echo channel id lun >/sys/class/scsi_host/host0/scan" (where channel, id and lun are 0 0 0 for S-ATA devices, but a dash can be used as wildcard as well).

      Unfortunately, I don't have any disks to try it on right now, since they are all in active use.

  88. Oh Pu-leaze. +4 and funny by doodlebumm · · Score: 1, Insightful

    Mod me -4 and informative for trying to open the moderator's eyes, but this isn't even funny. Just trite!

    1. Re:Oh Pu-leaze. +4 and funny by MLease · · Score: 1
      I found it mildly amusing. I think +1 (where it is as I write this; looks like it's suffered a bit of down-modding since you posted) is about right. +4 is too much, I agree.

      -Mike

      --
      I'm sorry; I don't know what I was thinking!
  89. Re:Really helped video editing? by Lumpy · · Score: 1

    I also have to ask....

    I tried desperately to get video editing and composting to work under linux, I even purchased the commercial stuff available and it does not work for a professional environment.

    Cinerella is still unuseable to me (wierd file formats no support for DV2 standard file formats that are recorded on Hard drive based professional DV camcorders or from a backpack Hard drive firewire unit.) and Cinerella crashed all the time for me.

    Also important apps that mimic the capabilities of apps such as shake and After effects or Boris Effects do not exist at all under linux.

    Are you simply doing home movies or pro video editing and what in the world are you using to edit with?

    --
    Do not look at laser with remaining good eye.
  90. Re:Great, how about stable firewire support someda by shippo · · Score: 1

    Utter rubbish!

  91. Re:Video Editing? by Lumpy · · Score: 1

    Ok now how about one that is useable.

    Cinerella does not use normal file formats for pro editing, Main actor is out of date by 5+ years and is 100% un-useable (I know I paid money for mine and no updates have been released for nearly 5 years now. Kino is a nice toy and Lives suffers from the same problem as Cinerrela.

    If your video editing app does not support using DV2 file formats from pro hard drive recorder cameras or the HD firewire recording backpacks then it is not useable.

    If you are talking toy apps like DVD-IT or MyMovie on Windows for home users to edit their kids birthday parties then, OK I see those apps useable for that.

    They certianly are not useable for professional work... I know I tried on several occasions and they always fail driving me back to windows and then soon to a mac based editor to completely get away from the mess.

    and dont get me started about the huge lack of composting apps in linux.

    --
    Do not look at laser with remaining good eye.
  92. Linux could already "serve files" in the kernel by Nurgled · · Score: 1

    sendfile already allowed in-kernel copying from a disk file to an arbitrary file descriptor; Apache does this when serving static files. splice seems to generalize this to allow this transfer to be between two arbitrary file descriptors, which would be useful for things like load balancers that just want to make the initial connection to the backend node and forget about it, since they can now just splice two sockets and have done with it.

  93. Whoo! Un-broken stuff! by mixonic · · Score: 1

    I've been waiting to get ACPI cpu-scaling un-broken, In theory this release provides that fix. Any other popular/big fixes out there?

    -mix

  94. Re:Video Editing? by Khuffie · · Score: 2, Informative

    Spoken like a true mac fan boy. Final Cut Pro is great, but Premiere Pro really cuts the gap. And After Effects still remains one of the better compositing tools out there.

  95. Thats why I use Slackware by Viol8 · · Score: 1

    I want the genuine kernel , not some hacked about fuckup of a kernel that
    may or may not be stable just because Charlie Coder at Deadrat who whoever
    thought it would be "kool" to port some bleeding edge code back into because
    1 in a million people may have found it useful. With slackware you get the
    stock kernel. End of. And its always worked for me.

    1. Re:Thats why I use Slackware by bogie · · Score: 1

      "I want the genuine kernel , not some hacked about fuckup of a kernel that
      may or may not be stable just because Charlie Coder at Deadrat who whoever
      thought it would be "kool" to port some bleeding edge code back..."

      Nice Troll. Yea who wants a hack from "Deadrat" like Alan Cox screwing with their kernel? There is a huge difference between joe user making up his own distro and backporting whatever the hell he wants and professional companys who often have kernel devs working for them back porting important features. Stock doesn't always mean best or most stable.

      --
      If you wanna get rich, you know that payback is a bitch
    2. Re:Thats why I use Slackware by Viol8 · · Score: 1

      Heres a tip little boy: Just because someone disagrees with the prevailing view
      of you teenagers doesn't make it a troll.

      I've been working with linux since 1994 and I've had just about enough of the
      "special" kernels that ship with various distributions having spent many long
      days trying to solve issues with the bleeing edge garbage they shove in.

      Go play poke-the-dog with someone else moron.

  96. Re:Great, how about stable firewire support someda by CoonAss56 · · Score: 1

    Sez u

    --
    Won't Bow.....Don't Know How
  97. There are valid uses for a GOTO by Dan+Ost · · Score: 4, Informative

    I agree that using GOTO is a bad idea when another control structure is adaquate,
    but, at least in C, there are times when using GOTO is the most natural and,
    unequivically, the best choice.

    Off the top of my head, I can think of two situations where using a GOTO is
    the best solution:

    1. breaking out of nested loops. In C, the break command can only break
    out of a single loop level. If you need to break out of 2 or more loops, you
    can play an ugly game of setting and checking state flags at each level
    of looping or you can simply create a label at the exit point and use
    GOTO to get there. (sometimes you can wrap your loops as a function call,
    but that's often the ugliest solution)

    2. shared cleanup code. In a function with multiple exit points, instead
    of doing cleanup at each exit point, it is often clearer to set your
    return value and then GOTO a label that handles all cleanup before
    returning.

    Be cautious when using GOTO, but don't be afraid of it. Learn to
    recognize when GOTO is appropriate and when it should be avoided.

    --

    *sigh* back to work...
    1. Re:There are valid uses for a GOTO by bmalia · · Score: 1

      There is no situtation you should ever use a GOTO in C in.

      In your examples.
      1) If you can create a condition where a goto is to be placed, you can add that same condition to the top loop in the nest and let it exit out gracefully.

      2) Use a clean-up function. It will return to the correct place without all the spagetti code.

      NEVER USE A GOTO!

      --
      There's no place like ~/
    2. Re:There are valid uses for a GOTO by Dan+Ost · · Score: 5, Informative

      1) If you can create a condition where a goto is to be placed, you can add that same condition to the top loop in the nest and let it exit out gracefully.

      If that leads to clearer code, then in the cases where you can do that, fine. Do that.

      However, there are situations when a condition doesn't make sense until you've already
      entered the nested loops at least once (for example, when allocating lots of chuncks of memory,
      you can't test to see if you've successfully allocated memory until after you've tried to
      allocate memory). Also, if there are several conditions that might require a break, but
      they can all be handled the same (at least until after you break out of your loops),
      do you really want each one to be tested at every loop test? Think how big and confusing that
      would make your continuation test for your outer loops.

      2) Use a clean-up function. It will return to the correct place without all the spagetti code.

      There's nothing wrong with using cleanup functions if they are convienent for your
      particular purpose, but if you have to free 11 objects before returning, then you'll
      need to pass all 11 to the cleanup function each time you call it. I don't know about
      you, but I usually find functions with 5+ arguments to be ugly. I would rather simply have
      a 'goto cleanup' that jumps to a label that does all the cleanup in place. An acceptable
      compromise would be to define a macro that does the cleanup in place but hides it from casual
      code inspection, thus keeping the code clear, but avoiding the use of GOTO.

      Using GOTO in the manners I've described will not lead to speghetti code since the flow of control
      will be clear and uni-directional (the antithesis of speghetti code). In case (1), the use
      of GOTO is equivalent to raising an exception in Java, C++, or Python from within the loop and
      capturing the exception outside the loop (idioms commonly accepted in all three communities).
      In case (2), the use of GOTO maps multiple exit points to a single exit point. If you feel
      that these techniques qualify as speghetti code, then I would suggest that you've never
      seen real speghetti code.

      When Djikstra wrote "Goto considered harmful", he was talking about using GOTO to jump outside
      the scope of the current function, something not possible in with C's goto (C's goto can only
      jump to a label within the current function). See BASIC and PASCAL (I think) for examples of GOTO that
      can jump anywhere in the program.

      --

      *sigh* back to work...
    3. Re:There are valid uses for a GOTO by Jester99 · · Score: 1

      shared cleanup code. In a function with multiple exit points, instead
      of doing cleanup at each exit point, it is often clearer to set your
      return value and then GOTO a label that handles all cleanup before
      returning.


      There's actually a simple way of doing this without goto's. Put the main body of your code in a do { ... } while(false); block. Then for all the exit points, write in 'ret = exit_code; break;'. Put your finalization code after the do { } block. No goto's. :)

    4. Re:There are valid uses for a GOTO by Procyon101 · · Score: 1

      That's an obfuscated goto, and IMHO worse.

    5. Re:There are valid uses for a GOTO by Procyon101 · · Score: 2, Insightful

      For the record though, these are *BAD* habits in C++. Use the destructor, Luke.

    6. Re:There are valid uses for a GOTO by barawn · · Score: 1

      1) If you can create a condition where a goto is to be placed, you can add that same condition to the top loop in the nest and let it exit out gracefully.

      Isn't that slower, though? A normal infinite loop is just a jump, with no branch prediction issues. Adding in a conditional jump to each one could add a slew of branch mispredicts into the code as the predictor fails for each conditional jump.

      As in

      int ok = 0;
      while (ok) { // loop A
            do_something();
            while (ok) { // loop B
                        for (i=0;i != 100;i++) { // loop C
                                if (!(ok = do_something2())) break;
                        }
            }
      }


      When do_something2 returns 0, the break is just a jump, so there's no mispredict penalty there. But loop B will likely be mispredicted, and then loop A will be mispredicted as well, which gives you two pipeline stalls right in a row. Whereas if you just had a goto in the end, it'd just be a jump, with no mispredict
      penalty at all.

      Of course, basically the only time I ever consider using gotos is nested loops. Which means gee, it'd be nice if C had a mechanism for specifying a break level (i.e. break(2), break(3), etc.).

    7. Re:There are valid uses for a GOTO by Dan+Ost · · Score: 1

      Is there some advantage that I'm missing? Or is this just a way
      to partially reinvent the utility of the goto statement?

      It seems to me that this would reduce the clearity of the code
      (code clearity is paramount!) and consume a level of indentation.

      Am I missing something?

      --

      *sigh* back to work...
    8. Re:There are valid uses for a GOTO by Breakfast+Pants · · Score: 1

      That will only get called each time the top loop executes! We are talking about a deep nest here!

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    9. Re:There are valid uses for a GOTO by Jester99 · · Score: 1
      From a completely performance-based point of view, no, there's no extra gain; they'll compile down to effectively the same assembly.

      But there are subtle syntactic cues that imply the flow of the function.

      The indented block inside the do { ... } deliniates the region of code which can can "fall down" to the finalization block. You know that nothing's going to enter the finalization block from above the do-"loop", as it were.

      Furthermore, there are syntactic delineations between the 'main body' and finalization. Finalization is after the closing '}'. Main body is when the braces are open. It's impossible to stick code above the line-label for finalization without indenting, thus forcing you to realize that it's in the main block.

      Otherwise it's possible to do this:
      if ( something )
        goto finalize;
      ...
      if ( something_else )
        goto finalize;
       
      new_Finalization_call(); //this should be one line lower!
      finalize:
      old_finalization_calls();
      retu rn ret;
      But with the loop, it's more obvious:
      do {
        if ( something )
          break;
      ...
        if ( something_else )
          break;
       
        new_Finalization_call(); //obviously out of place, given its indentation.
      } while(false);
       
      old_finalization_calls();
      return ret;
      To each his own, I guess. But programmers are used to dealing with 'break' and intuitively know how to read code that includes a loop and break statements. People have to stop and think about where a goto leads to. Kind of like how you /can/ read text where there is no capitalization and no punctuation, but it's much easier if these implicit cues are inserted. I think it just increases overall readability/maintainability.

  98. I've been using IR in thinkpads forever... by r_cerq · · Score: 1

    ... including in the latest 2 laptops, a T40 and T41. What are you talking about?

  99. OS X supports what my Mac sports by jdbartlett · · Score: 1

    Although newer Apple laptops including MacsBooks don't have Firewire '800' ports they still have FireWire 400 ports. FireWire devices (most camcorders since 1995) are supported very well. I doubt Apple will drop Firewire 800 in the Mac Pro (note: I'm talking about Apple's confusingly named the Power Mac replacement, not the current PowerBook replacement!)

  100. Re:Really helped video editing? by FueledByRamen · · Score: 1
    Also important apps that mimic the capabilities of apps such as shake and After effects or Boris Effects do not exist at all under linux.
    Well, if you want an app that mimics the functionality of Shake and runs under linux, perhaps you should try Shake? I hear it's quite good.
    --
    Every cloud has a silver lining (except for the mushroom shaped ones, which have a lining of Iridium & Strontium 90)
  101. Re:Video Editing? by bhirsch · · Score: 1

    XPM is a lot easier to use with ed.

  102. Debian user? by Anonymous Coward · · Score: 0

    You must run Debian.

  103. That's great, but... by cafucu · · Score: 1

    ...when will Linux Vista be released?

    --
    :%s:work:/.:g
    1. Re:That's great, but... by Anonymous Coward · · Score: 0

      Still wiating for Linux to stop being a Beta OS myself.

  104. Re:Nice by Anonymous Coward · · Score: 0

    I just upgraded from 2.4.x to 2.6.13 yesterday (Slackware just added it to the install, and I'm really just too lazy to compile the latest kernel, but slackware 11 is on its way and it looks like more regular releases, wow this is quite a long parentheses). I'm happy to know my upgrade was quickly outdated. Most of the changes between 2.4.10 and 2.6.x have been for the home user (i.e. wireless card support stuff like that), correct me if I'm wrong.

  105. Re:Why support Apple hardware? by Anonymous Coward · · Score: 0

    "BTW: We're all laughing at you."

    ROFL, I wasn't until I read this.

  106. Re:Really helped video editing? by BrokenHalo · · Score: 1
    I tried desperately to get video editing and composting to work under linux

    You don't need any OS to composting, you know. You can just dig a hole in the ground and chuck in your left-over food scraps, and that will work.

    ;-)

  107. Re:Video Editing? by Eideewt · · Score: 1

    I know what you mean. I'd love to transition my garden over to Linux, but without composting apps I could never get decent performance.

  108. Linuxant? by phorm · · Score: 1

    For the broadcomm chipset (Wireless B) on my HP laptop, I've been using ndiswrapper up to this point. It's better than nothing, free ($$$ wise), and works for me.

    Of course if the native driver now work I'll probably be switching, but you could at least get away from Driverloader's pay system if it doesn't.

    1. Re:Linuxant? by timbo234 · · Score: 1

      Yeah I've been using ndiswrapper when I was on Kernel 2.6.12 and 2.6.13 but I can't get it working properly with 2.6.14 and above. It compiles and everything and appears to load the drivers I give it but there is no device created. I've also found it to be unstable in that too much fiddling around with the wireless settings, even switching networks too many times sometimes, will freeze the machine and force a hard reboot. Also the signal strength indicator doesn't work - it always stays on low.

      So far Linuxant seems stable and the signal strength works properly and it works fine on the newer kernels. Hopefully the new bcm43xx driver will be good enough to dump both Linuxant and ndiswrapper. If I'm successful I'll post it here: http://linuxonacer5020.sf.net/

      --
      Pre-canned Evolution Links for all those Slashdot holy wars.
  109. Secure Digitial (SD) Card Reader Support by Anonymous Coward · · Score: 0

    From the change log:
    * Secure Digital Host Controller Interface driver: Driver for the Secure Digital Host Controller Interface specification

    Great! Now, when will I see this in Ubuntu??? (So I don't have to hunt for the USB cable for my digital camera)!!!!

  110. Re:Video Editing? by Salsaman · · Score: 1

    LiVES (http://lives.sourceforge.net) is designed for neither accountants or squares !

    It is designed for digital video artists and VJ's.

    The same tool will allow you to work both in real time (for VJing and presentations), and in non-real-time (video editing). It can encode to over 50 different formats/quality levels, and can be controlled remotely via UDP.

  111. Re:Really helped video editing? by Lumpy · · Score: 1

    Shake and runs under linux, perhaps you should try Shake? I hear it's quite good.

    Yup if you have a MAC to create in because the linux version is a renderer only and costs more than buying a pair of G5 dual processor towers with Mac OS and 2 copies of Shake for MacOS.

    been down that road, Apple discourages using Shake on Linux with pricing.

    --
    Do not look at laser with remaining good eye.
  112. Halting process changed by Anonymous Coward · · Score: 0

    Anyone notice the difference in the halting process? Usually when I run 'halt', as soon as my drive powers off, so does my system. Now, Linux seems to wait until my drive powers off, and also stops spinning, and then shuts off.

    I've got a water-cooling setup, and I'm so used to unplugging my water-pump at the exact moment, and I unplugged it to early. :D

  113. Re:Video Editing? by zsau · · Score: 1

    Yeah, I kinda wasn't going for the "easy to use" aspect.

    --
    Look out!
  114. Take me to the source by x2A · · Score: 1

    "Modern distros..."

    Yeah... no. I like to work close to the source, as then it's more intuitive. If I change something, or want to compile something, it's exactly as the base system is, I don't have to figure out how this distro's decided to do thing this time.

    So all packages I have to maintain (eg, on webservers) are compiled from source with the compile flags I need, into seperate directories to keep it tidier and... yeah, seperate. My kernel is compiled from source, and ready to load by itself (so I can jump between kernel versions without having to worry about keeping modules ready to be loaded for each one), and without having to keep some initrd updated for each kernel too.

    Distros get in my way. Take me to the source.

    --
    The revolution will not be televised... but it will have a page on Wikipedia
    1. Re:Take me to the source by FireFury03 · · Score: 1

      So all packages I have to maintain (eg, on webservers) are compiled from source with the compile flags I need, into seperate directories to keep it tidier and... yeah, seperate.

      If you can afford the time to recompile every piece of software when you need to do a security update then you've got a helluva lot more time to burn than me. I suspect that instead, you're just not keeping ontop of the security updates. For me I'm quite happy with "yum update" happening regularly to keep my packages up to date.

    2. Re:Take me to the source by x2A · · Score: 1

      ever heard of scripts? As soon as there's a new version of say, apache out, I just run

      dinst apache install

      on each of the servers. It downloads, configures, compiles, and installs. It's a few more keypresses than 'yum update', but I'm a fast enough typer for that to be negligible. I also have clients who need apache/php/etc compiled with different flags, so my script remembers these and configures accordingly. It also does CPU detection to set cflags etc optimally, and after installing, restarts the services it needs to to put it into effect. I'm able to upgrade as soon as new versions/security fixes come out, without having to wait for the distro to make their own version and spread to mirrors etc. It's really not difficult, or time consuming, and when you need things set up your own way (such as when you offer custom services to your clients), distribution packages just don't work.

      Just to point out tho, on the servers I do this for the larger packages. Stuff like bash or ncurses, there's little room for customising, and little need for up-to-the-second updates, so the distro does handly most of these.

      --
      The revolution will not be televised... but it will have a page on Wikipedia
  115. BCM43XX driver no good w/ 1GB RAM by bmarklein · · Score: 1

    Unfortunately the BCM43XX driver causes a kernel panic with > 1GB of RAM:

    https://lists.berlios.de/pipermail/bcm43xx-dev/200 6-May/001840.html

    I ran into this over the weekend when trying to switch my Dell Latitude D400 to Ubuntu Dapper, after a 10-year hiatus from using Linux as my desktop OS. As of today, looks like there isn't even a working patch available:

    https://lists.berlios.de/pipermail/bcm43xx-dev/200 6-June/001975.html

    I had to go back to using an external wifi card. Yech.

  116. Re:Video Editing? by Anonymous Coward · · Score: 0

    Whoever rated the GP post flamebait or troll is oversensitive. The GGP said that 'video editing stuff' was faster. That is a very vague statement; why shouldn't one request more information?

    OTOH, details of the particular video editing software in addition to the information already provided by GGP would still be so little as to be pretty well useless.

  117. Re:Video Editing? by bhirsch · · Score: 1

    Could've fooled me.

  118. Re:BCM43XX driver no good w/ 1GB RAM by alyandon · · Score: 1

    I don't get kernel panics but after dumping the firmware from various versions of the windows drivers I still can't get my built-in bcm4306 wireless adapter on my pavillion zv5000 laptop working correctly (behavior from hard locks all the way up to dhcp working but not passing any packets afterwards). However, ndiswrapper has always worked flawlessly for me on this laptop.

    Hopefully, we'll see better support in future.

  119. OS X is much cheaper. by Anonymous Coward · · Score: 0

    Linux is not even CLOSE to "free" if you value your time. Compare for example the time a moron Linux luser will spend downloading, configuring and installing this kernel to the time it would take an OS X to simply turn on his Mac and use it. Lin-sux users are either masochists or are stupid... meh, probably both.

  120. Re:Go Fanboy! by Anonymous Coward · · Score: 0

    Can't say the same thing about seeing that the anonymous cowards here are still pricks.

    Crap, now I fed the troll, so he'll keep coming back for more food. Sorry guys.

    Oh, wait: Click 'Post Anonymously', and Submit... heheh, now nobody knows who I am.

    Hmm. Now I can be a prick too:

    Mac users are TUUURDS!!!!

    Nope, it doesn't ring my bell.

    Maybe I don't have what it takes to be a troll.

  121. very specialist and expensive hardware by John_Sauter · · Score: 1

    For very specialist and expensive hardware it poses a problem though: the person who does the API change won't have the hardware to test with, and probably all the people who use that hardware are using enterprise distributions so breakages to the module won't be spotted for a long time. It's hard for the hardware vendor to track these kinds of updates and perform the necessary regression testing.
    Why is it hard? I would think that the vendor of “very specialist and expensive hardware” would have the resources to test each new kernel as it came out, and fix any problems that turn up in the device driver. Since kernels are released about once a week, that should require only a small fraction of a developer. You could even have a low-level support person do the testing, and involve the developers only when it doesn't work.

    I am assuming, of course, that the vendor is serious about supporting Linux, and has a sample of his hardware to test on.

  122. Not true by axboe · · Score: 1

    sendfile is not yet a call to splice, it will be a little later. It was deemed too risky for 2.6.17. The point of doing it, btw, is not to increase sendfile() performance which is already as good as it can be - it's a specialized case and not very powerful, hard to make faster. So you wont get a performance increase from that. The perfomance increase will have to come with a program designed around splice.

  123. Keyboard and Mouse still disrupted cyclicly by Quietti · · Score: 1
    Where do I begin?
    • They messed up the Mach64 framebuffer driver a couple of releases ago; it paints garbage during the early stage of the boot process and flashes red on UTF-8 characters.
    • USB keyboard and mouse jam in a cyclic way that eats keystrokes and makes the mouse cursor freeze momentarily. I tried every elevator and preemptive mode, to no avail; something is definitely borked in the HID driver since about 2.6.4.
    That might not amount to much on a server, but it's one heck of a way to disturb desktop usage.
    --
    Software is not supposed to be about how to work around a useability issue. - Ken Barber
  124. [OT] Linux Video Editing by TheoMurpse · · Score: 1

    What program do you use for video editing in Linux? I've been hoping to do some video editing in Linux because Adobe Premiere keeps crashing in XP while trying to import huge DV AVI files.