Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Linux Software

Vanishing Features Of The 2.6 Kernel 443

chromatic writes "Jerry Cooperstein has written an excellent article summarizing the features removed from the upcoming 2.6 kernel. One controversial change may be tightening restrictions on binary-only modules." And Lovechild writes with some more 2.6 news: "I recently did an inteview with famous kernel hacker extraordinare and all round nice guy Robert M. Love for Tinyminds.org, about kernel 2.6 and what can be expected for desktop Linux users, when the new kernel series is released.
This discussion has been archived. No new comments can be posted.

Vanishing Features Of The 2.6 Kernel

Comments Filter:
  • by rainman31415 ( 576575 ) on Monday December 16, 2002 @06:16PM (#4901790)
    hopefully there wont be anything in the kernel related to the advertising. M$ .net sdeems to be paying for this article....


    bite me
    rainman
  • They aren't gone! (Score:5, Insightful)

    by jlharris_50010 ( 529143 ) <jlharris_50010&hotmail,com> on Monday December 16, 2002 @06:20PM (#4901818) Homepage
    Nothing's vanished... just not included... now you too can learn to kernel hack!
  • Binary modules (Score:5, Informative)

    by IamTheRealMike ( 537420 ) on Monday December 16, 2002 @06:23PM (#4901835)
    Could somebody sum up the pros/cons of binary modules. I've been trying to understand this issue for some time, but it's nearly impossible to get technical reasons without ideological bias. So far I have:

    Pros:

    • Commercial interests are happy because they keep trade secrets they may need to stay in business
    • Better drivers (usually)
    • Patented tech can be used in Linux, like that nVidia texture compression thing (i don't think all patents are stupid).

    Cons:

    • Makes kernel harder to debug
    • Sticky GPL enforcenment issues
    • Some kernel developers don't like it
    • Often come with stupid licensing, ie nVidia - you can't distribute our drivers, only download them (and then no psyche rpms).

    Have the kernel devs decided whether they are good or not?

    • Re:Binary modules (Score:5, Informative)

      by Otter ( 3800 ) on Monday December 16, 2002 @06:36PM (#4901964) Journal
      Cons:

      As a PowerPC Linux user, I'd add that they're rarely made available for non-x86 architectures.

    • Re:Binary modules (Score:5, Interesting)

      by crow ( 16139 ) on Monday December 16, 2002 @06:37PM (#4901981) Homepage Journal
      You left off one major con:

      Binary-only modules must be updated by the vendor when the kernel interface changes.

      If we must have binary-only modules, I like how Cisco did it for their VPN software: you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.
      • Re:Binary modules (Score:5, Insightful)

        by IamTheRealMike ( 537420 ) on Monday December 16, 2002 @06:45PM (#4902059)
        Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver
        • Re:Binary modules (Score:5, Informative)

          by kasperd ( 592156 ) on Monday December 16, 2002 @07:01PM (#4902247) Homepage Journal
          Why does the kernel module interface change so often though? I mean, surely there are only so many ways to write a mouse driver

          The mouse driver is one of the simplest drivers, and most of the stuff is done in usermode anyway. But a changing interface doesn't mean that each and every piece of the interface changes, it just means that the overall interface has changed in some way.

          It doesn't take much to make a change in the binary interface, a small change of a .h file will do. In fact even changing just a kernel configuration option could change the binary interface. The API on source level is however more stable. It doesn't change that often, and it doesn't change in unpredictable ways by modifying something completely unrelated to what you are writing. This API has been kept almost unchanged all the way through the 2.4 series.
      • Re:Binary modules (Score:3, Interesting)

        by kasperd ( 592156 )
        You left off one major con:
        Binary-only modules must be updated by the vendor when the kernel interface changes.


        That is not just a major con, it is probably the most important of all cons.

        you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.

        Hasn't something similar been done for gfx drivers as well?
        • Re:Binary modules (Score:3, Insightful)

          by Vellmont ( 569020 )
          Yes. Nvidia did this for the Nforce drivers, and I believe for the GeForce drivers. This doesn't always solve the problem though. The RedHat 8 kernel (and I'm assuming other new distributions) was compiled with gcc 3.2, while the binary library Nvidia provides was compiled with gcc 2.95. Having kernel modules and the rest of your kernel compiled with major revision changes can cause problems, and inmod will refuse to load this module unless you use the force option. The end result is incompatibility until the Nvidia gets around to simply re-compiling the module with gcc3.2 (or you're technical enough to know to how to use the --force option with insmod, and are willing to take the risk it breaks something)

          It's true that providing a binary library and a wrapper is a better solution than a completely closed binary, but there are still some large problems with this approach.
    • Re:Binary modules (Score:4, Informative)

      by bbk ( 33798 ) on Monday December 16, 2002 @06:37PM (#4901982) Homepage
      I've always heard it stated as a debugging issue - if a bunch of people send in bug reports saying "Kernel 2.x.x is broken", and they're using a binary only module, how do the linux developers know the problem is with the kernel, and not with the binary module? To aid in debugging, they put limits on what binary only drivers can do, which narrows the range of problems.

      I think it makes a good deal of sense, from a linux developer standpoint - they all have their own reasons to work on linux, and answering bogus bug reports caused by faulty binary modules cuts time from other development tasks.

      BBK
      • It's certainly possible to make good interfaces to facilitate debugging binary-only code. Most likely the kernel developers have decided that their time is better spent in other places, rather than making life easier for the binary-only module developers. =That decision is made easier by open source bias, of course, and the lack of a large user constituency that would be intolerant of breaking old apps.

        If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.
        • Re:Binary modules (Score:5, Insightful)

          by __aaahtg7394 ( 307602 ) on Monday December 16, 2002 @08:39PM (#4903201)
          If you have 10k desktops and your IT guy/gal/team
          1. doesn't have an automated system to push updates, or
          2. decides you need to upgrade to a new kernel for no apparent reason (security updates are almost universally backported), or is unable to do the kernel patching to fix things themselves, or
          3. you have software that's somehow hacked into the kernel on desktops but you don't have the source to,

          you're fucked. Start writing your resignation letter, you totally blew it for anyone you're responsible to. Hope you weren't there too long so you can put it on your resume as a hiatus.

          Linux doesn't have to worry about backwards ABI compatibility because most vendors use the API instead...
    • At the risk of this sounding like flamebait, it's about power and control.

      There are people who think you should not be able to download a binary-only module and use it with a GPL program. Note that I say you, and not the creators of the programs themselves. The binary only creators are not using any GPL code. The GPL code is not using the binary. It's the combination of the two that many will tell you is a "sticky area".

      It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.

      I think a lot of people need to get a grip and just mind their own business. If you don't want binary-only software on your computer, then don't do it. But don't presume to tell me what software I can or can't run on my computer.

      Now, it's valid to worry about whether I'm redidistributing software according to the license. But if I follow each individual software's license, then leave me alone.

      • Re:Binary modules (Score:5, Informative)

        by vinsci ( 537958 ) on Monday December 16, 2002 @07:08PM (#4902333) Journal
        It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.

        Microsoft are busy working on just this and it's much worse than you would imagine. See the TCPA/Palladium FAQ [cam.ac.uk].

        Translations: German [hipjoint.de], Spanish [bulmalug.net], Italian [complessita.it], Dutch [wanadoo.nl], Chinese [ttv.com.tw], Norwegian [www.efn.no], Swedish [refactor.fi], Finnish [effi.org], Hebrew [penguin.org.il] and French [lebars.org]

        • Microsoft are busy working on just this and it's much worse than you would imagine.

          No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.

          There is a very simple reason for this: it would break backward compatibility. No backward compatibility, then no operating systems sold.

          Yes, there are people who are LYING about Palladium. Yes, LYING.

          And yes, Palladium can be used for digital rights management. But that is a completely separate issue from the idiots who assert that only Microsoft-signed software will be allowed to run, which is completely absurd.

          Palladium is nothing like this binary module issue.

          • Re:Binary modules (Score:5, Insightful)

            by vinsci ( 537958 ) on Monday December 16, 2002 @07:51PM (#4902747) Journal
            No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.

            So what if Palladium lets your GPL program run, it wouldn't matter at all. This is because your GPL program will not be able, or rather allowed to, access the Palladium infrastructure in order to get the needed cryptographic credentials to perform certain tasks. So yes, your program will run, but no, it won't be able to do anything useful for you, not for anything that requires access to Palladium. And that would be mission completed for Microsoft: GPL software rendered useless.

            The easily fooled will probably be glad to hear that the full source code to Palladium will likely be made available. Again, the source code is as powerless as your GPL program, and is of no use to you - even with the source, you can not make modifications to it and run the modified version in place of the version endorsed by Microsoft.

            Furthermore, Microsoft already has a license in place that exludes open source development and specifically GPL and LGPL open source, see this article by Bruce Perens [com.com]

            Yes, there are people who are LYING about Palladium. Yes, LYING.

            If you are aware of any lie in Ross Anderson's TCPA/Palladium FAQ, please state what it is.

      • The way I see it, the people who wrote the kernel have the control. If they choose to say that you can't run non-GPL'd drivers/modules with the kernel this way, it's their choice. They wrote the code, they have the power to make people conform. Any module/driver developers who don't agree with the kernel team can distribute their code seperately.

        Also, by the same token, Microsoft is well within their rights to say, "We will only allow you to run Microsoft sanctioned software under Windows". If you don't like it, you can either (1) stop using Windows, or (2) hope that the government strikes them down through the monopoly rules.

        If you don't like the terms, then don't use the software, or find a way to make it work yourself. Nothing says that I must allow your software to interoperate with mine.

        -- Joe
        • I didn't say they didn't have the legal right to do it. I'm just explaining that the root of this is people who can't mind their own business and want to control the computer choices of others. It's no different than if some programmer releases a utility with a requirement that only born again Christians can use it. Does he have the right to do it? Of course. But that doesn't make the decision less idiotic and wrong.

      • Now, it's valid to worry about whether I'm redidistributing software according to the license. But if I follow each individual software's license, then leave me alone.

        Wow, I can't think of a better way to put it. It's interesting that the GPL tries to tell you what you can do with the software, while the people who enforce it are now telling you what you cannot do. I honestly can't see any licensing reasons why I can't take two pieces of software and run them together on my computer (as you indicate).

        But then... the kernel has a table of system calls, and that table can be edited to effectively pipeline calls to the binary-only modules. So a binary-only module (with the older method) can effectively replace different kernel services (maybe?). Are there any licensing issues that occur with this?
      • Re:Binary modules (Score:4, Insightful)

        by Daniel Phillips ( 238627 ) on Monday December 16, 2002 @08:02PM (#4902855)
        It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system.

        No, it's not. There is no restriction whatsoever in running any kind of application you want under Linux. Did you ignore the distinction between kernel and user mode intentionally?

        It's more like Microsoft changing the Windows license to disallow any GPL code in the Windows kernel. Oh wait...
    • Better drivers (usually)

      I don't believe it. Assume a driver has been written and released in binary form. How could the driver become any worse by releasing the source? It couldn't, but more people might realize how badly it was written. And nVidia's is assumed responsible for a lot of the kernel crashes. If anybody reports and error on a system that has been using nVidia drivers, the kernel developers will tell the person to reproduce it without the nVidia driver or go bother nVidia.
      • Re:Binary modules (Score:2, Interesting)

        by Cid Highwind ( 9258 )
        If anybody reports and error on a system that has been using nVidia drivers, the kernel developers will tell the person to reproduce it without the nVidia driver or go bother nVidia.

        This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).

        (*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.
    • The only reason I am able to post this article right now is because Linux supports binary-only modules. namely, there is no interest in the free software community to develop a driver for the various Winmodems out there. I have a laptop with a built-in Winmodem. The only way I am able to use this modem is to use a binary module.

      On the downside, the module (for the Lucent winmodems) was originally released for the 2.2.x kernel. It was never updated by Lucent, but some people on the net figured out how to change the headers so it works with the 2.4.x kernels.

      If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible, I have a few choices:

      • Stick with an older Linux distro which uses a 2.4.x kernel.
      • Wipe Linux and use Windows. [1 [slashdot.org]]
      • Spend over $100 for an external modem (I'm a college student, so no).
      • Drop out of school for the next semester, and abandon my current open-source project [maradns.org] so I have the time to develop an open-source driver for win modems. I want to graduate ASAP, so alas no.
      - Sam

      Then again, Lucent may force people to use older drivers for newer versions of Windows, like XP. Then again, Windows 98 is still supported (name one Linux distribiution which came out in 1998 which is still officially supported), and it should be possible to use a Win98 driver with XP.

    • "Better drivers (usually)"

      I don't know where you getting your info from, but that's a myth. To follow that line of thinking, all closed source software is better then opensource software(usually).

      As we all know that's just not true. Being open or closed source isn't the determing factor for how good or bad a driver is. Its simple a development model. Its the actual code which determines how good or bad the driver is. I assume based on you mentioning Nvidia twice that your basing your opinion soley on their drivers from an enduser point of view. Rest assured that if Nvidia opensourced its drivers they would be just as good as the closed versions if not better due to peer review.
      • Re: Better drivers (Score:3, Insightful)

        by alannon ( 54117 )
        One thing I should point out:

        Most technology companies are constantly licensing other people's tech in order to make theirs better. NVidia does this in their video cards. These bits of technology come with restrictions on them from the company licensed. Usually they are either patented or considered trade secrets and a company like NVidia would be restricted from allowing a trade secret that they license from being revealed. Drivers can give you intimate details on how the insides of your hardware work. Many pieces of hardware even include microcode that can be updated when the driver is loaded, either to fix bugs or to provide new capabilities/performance. It's quite possible that NVidia's hands are tied when it comes to making Linux drivers. The alternative to revealing 'intimate' details of the hardware might be disappointing performance or missing features.

        Now perhaps NVidia COULD release their current binary drivers as open source ones, but simply choose not to. I think the above is a very real possibility, though.
        • Most technology companies are constantly licensing other people's tech in order to make theirs better. NVidia does this in their video cards. These bits of technology come with restrictions on them from the company licensed. Usually they are either patented or considered trade secrets and a company like NVidia would be restricted from allowing a trade secret that they license from being revealed. Drivers can give you intimate details on how the insides of your hardware work. Many pieces of hardware even include microcode that can be updated when the driver is loaded, either to fix bugs or to provide new capabilities/performance. It's quite possible that NVidia's hands are tied when it comes to making Linux drivers. The alternative to revealing 'intimate' details of the hardware might be disappointing performance or missing features.

          Now perhaps NVidia COULD release their current binary drivers as open source ones, but simply choose not to. I think the above is a very real possibility, though.


          If it was they case, then they could easily place those contractually-restricted bits in a binary module and open source the rest. They don't do this, so I presume the above isn't the reason.

          The following three letters may help you in your search for the real reason: PHB.
  • by Archie Steel ( 539670 ) on Monday December 16, 2002 @06:27PM (#4901869)
    Does that mean that NVIDIA drivers will no longer compile for the 2.6 kernel? Or am I totally besides the track, here? I'm not a developer, so I shouldn't even be in this thread...but as much as I want to try out the vaunted desktop responsiveness increase in the new kernel series, I'm not about to sacrifice Counter-Strike or WarCraft III for it...(yes, they run under Linux, with WineX)
  • What will we see? (Score:5, Interesting)

    by dirvish ( 574948 ) <(dirvish) (at) (foundnews.com)> on Monday December 16, 2002 @06:27PM (#4901873) Homepage Journal
    Will the distros just add the stuff they like back in?
  • by Anonymous Coward
    Just do what my company does, use an old ass (RH 6.2) distro.
  • by codepunk ( 167897 ) on Monday December 16, 2002 @06:29PM (#4901896)
    These things have bitten me twice in the last few weeks since vendors never keep up with the current releases. Redhat ships a new updated kernel with some security fixes and then I cannot update until the vendor gets off his ass and does a rebuild against the new source tree.
    • No nothing has to be locked up as a kernel module to implement use restritions, there are better ways to do it. We spend huge bucks for our linux server applications and will continue to do so, the binary modules are a horrible mess that needs to go away.
    • by FauxPasIII ( 75900 ) on Monday December 16, 2002 @06:59PM (#4902226)
      While I agree in principal that kernel mode needs to remain open, for practicality's sake I think another solution is in order... one of the biggest things holding linux back from more widespread acceptance is, imho, the fact that drivers must be updated with each point release of the kernel. This stings binary-only and out-of-kernel open source drivers alike.

      Windows XP, for all its faults, exports a very specific and small set of operations that a device driver is allowed to use to be 'certified', and as long as you stay within that sandbox, they claim your driver will stay compatible with subsequent releases. If Linux could make the same guarantees within, say, an even-numbered minor version release (2.2, 2.4, etc) I think you'd see a lot more vendors willing to make drivers, closed and open.
  • Arrogance (Score:5, Insightful)

    by rossz ( 67331 ) <ogre&geekbiker,net> on Monday December 16, 2002 @06:29PM (#4901902) Journal
    This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task.
    What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

    • Re:Arrogance (Score:4, Insightful)

      by pclminion ( 145572 ) on Monday December 16, 2002 @06:36PM (#4901972)
      What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts

      If you read over the LKML mailing list archives, it will become quite clear to you that the kernel developers don't give a cold shit in hell about user requests or complaints. They do what they want, and fuck everyone else.

      At least, that was the sense I got from the conversation..

      • Comment removed (Score:4, Insightful)

        by account_deleted ( 4530225 ) on Monday December 16, 2002 @06:57PM (#4902190)
        Comment removed based on user account deletion
      • You can use the old kernel, you can use the new kernel, you can use your own kernel.
        Everyone can make whatever they want.

        They don't owe you anything.
        • by pclminion ( 145572 ) on Monday December 16, 2002 @07:24PM (#4902487)
          You can use the old kernel, you can use the new kernel, you can use your own kernel. Everyone can make whatever they want.

          Untrue. Most people are incapable of hacking kernel code, or any kind of code.

          The kernel developers can use their abilities and positions to essentially blackmail the user base. New hardware drivers aren't usually backported to older kernels, so in order to get modern support for most things you have to run the latest. Want to run on modern hardware? You have to upgrade to a new kernel, with a new license, new restrictions, etc.

          They don't owe you anything.

          This is hilarious. You know, I once posted a rant on LKML about some particular issue (details unimportant). I essentially said that if it wasn't addressed, I might consider moving to BeOS (which was looking very good to me at the time). I have the freedom to make that choice, right? They don't OWE me anything, right? So clearly I most not owe THEM anything.

          But I got several responses accusing me of BLACKMAIL, saying that I was "threatening" to move to BeOS in order to force someone to do something.

          I could understand if there was some disagreement on a technical point, but by that point the conversation had degenerated into a flamethrowing competition between Andre Hendrick and the rest of the list. I was the only guy backing up Hendrick.

          Anyway, I know from experience that many kernel developers are elitist, arrogant people. I guess they think that because their code runs in Ring 0 they must be somehow superior to the rest of us.

    • Re:Arrogance (Score:5, Insightful)

      by silvaran ( 214334 ) on Monday December 16, 2002 @06:39PM (#4902008)
      How about you go branch your own Linux kernel tree and add code back in that better supports binary-only modules? It's their tree, they can do what they want. If Red Hat doesn't like it, they can maintain their own tree (which they do). If nVidia doesn't like it, they can do likewise.

      After all the hard work of the kernel folks, you seem to expect them to be perfectly happy with having to support binary modules that they can't debug, and that fall in a grey area of the GPL.

      How about you go create your own open-source project. Then I'll go create some hardware, and keep all the information proprietary. To tease you a bit, I'll keep all information about my hardware proprietary, so you have two choices:

      1) Reverse engineer my hardware and write your own software.
      2) Indicate to me that your software is valuable, and depends on my hardware, until you convince me to release sources so they'll work better with your software.

      That's the position nVidia's in. They've got one of the most widely-used video cards on the market. And the only way to use that video card effectively under Linux is to use their binary-only drivers. Get a clue. Linux doesn't belong to commercial entities any more than it belongs to Linus. What you do with your kernel tree is your own business.
      • Re:Arrogance (Score:3, Insightful)

        If Red Hat doesn't like it, they can maintain their own tree (which they do). If nVidia doesn't like it, they can do likewise.

        The problem is nvidia (and I use nvidia simply as an example, this applies to many others) WON'T, since unlike Red Hat, having a Linux kernel branch is very tangential to their real business. There are a number of companies that offer Linux support simply as a goodwill gesture, or at most for an extra bit of PR, despite the fact that the limited Linux support they do offer isn't really a good return on investment (just like id games for Linux aren't a good ROI but id releases them anyway for their own reasons). Anything the kernel developers do to make it harder for these folks to support Linux will mean less Linux support from hardware makers, which will make the much-vaunted Linux desktop push stillborn. If that's what the kernel developers want to do, that's fine. As you said, it is their code... But then they can't go crying later when everyone drops their Linux support.

      • After all the hard work of the kernel folks, you seem to expect them to be perfectly happy with having to support binary modules that they can't debug, and that fall in a grey area of the GPL.

        They don't have to be happy about it, but given how things work in the Real World, they damn well ought to learn to deal with it.
    • Re:Arrogance (Score:3, Insightful)

      by bbk ( 33798 )
      Last time I checked, linux was a homebrew project by Linus. He gets to do what he wants with it - he's not even paid to write it. His time is valuable, and wasting it debugging binary modules isn't productive.

      Corporations that write binary modules are only allowed to write them by Linus' good graces - normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code in the manner that kernel modules are added.

      Corporations should be happy they are allowed the level of integration that linux gives them, as they get an exemption (no-GPL) from the rules. They are also free to switch to the BSD's any time they want, which lacks many of the GPL's problems.

      BBK
      • Last time I checked, linux was a homebrew project by Linus.
        It's been a long time since you've checked, obviously. Linux has grown way beyond a homebrew project for Linus. It's a multibillion dollar business these days.

      • Re:Arrogance (Score:3, Insightful)

        by Waffle Iron ( 339739 )
        normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code in the manner that kernel modules are added.

        The GPL does not stop you from linking binary only code to GPLed code. Nor does it stop you from distributing your own binary-only code that can be linked to GPLed code. It only stops you from redistributing someone else's GPLed code which is linked to your binary-only code.

        This is because the GPL puts no restrictions on the use of GPLed code, only on the redistribution of it. If you don't distribute the GPLed code, you can't violate the GPL. As long as a company that writes binary modules doesn't distribute the Linux kernel, there is no way that they can be in violation of the GPL.

        The end user can link the binary module to the Linux kernel and use it. The end user can't redistribute this combo, however.

      • normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code

        It is a very grey area. The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.

        Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.
    • Re:Arrogance (Score:5, Insightful)

      by Subcarrier ( 262294 ) on Monday December 16, 2002 @06:55PM (#4902164)
      What an arrogant attitude.

      Arrogance indeed. Users are so used to being customers that they don't know when they are receiving a gift.

      It's weird how, after over ten years, many people still don't get Linux. Every single Linux developer does what he does does because he gets something out of it. Not because he want's you to get something out of it. That's the beauty of the GPL. It guarantees that everyone can do what they want with the code, as long as they give others the same courtesy.

      If you want something, just do it. If you can't, find a way to motivate someone to do it for you. You have the same rights as everyone else, no more, no less.
    • What an arrogant attitude. The kernel developers need to be reminded that widespread acceptance of Linux might very well require the support of big commercial enterprises, not just hobbiests and open source enthusiasts. Few companies are going to make major investments in Linux if they have to deal with prima donna programmers who love fucking with them.

      I see your point, but I respectfully disagree. Linux will ultimately be accepted or rejected by businesses based on the cost of running it versus the cost of running a competing OS. I do not believe that forcing commercial developers to evolve their products to match changes in Linux will increase the relative cost of running Linux, because commercial developers typically have to do this for other OS's anyway. Regularly paying for upgrades of your commercial software is standard practice.

      By indefinitely supporting obsolete (and potentially bad) features, however, the kernel developers could actually drive up the relative cost of running Linux. Why? Because there's less motivation for commercial developers to modify their products to utilize the new-and-improved features and, ultimately, make the system as a whole more robust and less costly to operate.

      Open source software already has the disadvantage of not necessarily being driven by short-term economic gain. I say disadvantage, because short- term economic gain is an easy thing to sell to people. Given this disadvantage, a little arrogance and strong-arming is not only justified, it's essential.
    • I guess I should have stated this in my original post. I don't necessarily object to the code changes (I'm not qualified to make that call, to be honest). If they are needed for the good of Linux, then I'm all for it, even if it does break expensive commercial programs.

      It's the arrogant attitude that I have a problem with. Working on open source means working with a community. Sometimes that community includes commercial operations. Messing with them just because "you can" just doesn't seem like good diplomacy.
      • Re:Arrogance (Score:3, Insightful)

        Messing with them just because "you can" just doesn't seem like good diplomacy.

        Is that what you think? That's hardly how things are, it's not like Linus sits in his dark tower, steeples his fingers and says "Today, I think I shall once again break binary compatability to screw over nVidia.. bwhahahahaha".

        When they break kernel interfaces, it's to make a better kernel. If they didn't, those parts of the kernel would effectively be frozen in time, and the kernel woudln't move forward, it'd get more crufty and less reliable. We'd all suffer, just so binary driver producers don't have to recompile their drivers. Doesn't sound like a good tradeoff to me.

      • It's the arrogant attitude that I have a problem with. Working on open source means working with a community. Sometimes that community includes commercial operations. Messing with them just because "you can" just doesn't seem like good diplomacy.

        The commercial operations are a part of the community as well, hence they must be contributing to the atmosphere of arrogance. Seriously, if they had a good standing in the community they would be less likely to be walked over. The Linux community tends to have little patience for would be members who want things but are reluctant to contribute. This, I think, is completely understandable.

        Let's see. How could my company, as a hardware manufacturer, get on the good side of the Linux community? How about we GPL our device drivers? What a great idea! It would work too.
        • Re:Arrogance (Score:2, Insightful)

          by sweede ( 563231 )
          Let's see. How could my company, as a hardware manufacturer, get on the good side of the Linux community? How about we GPL our device drivers? What a great idea! It would work too.

          Accountant: but Mr CEO person, our research shows that only 200,000 people use Open Source software that would have a use for our super-deluxe hardware. at the same time, 4.5 million Windows users have a potential need for our super-deluxe hardware. in addition to that, the cost of creating and maintaining and Open Source driver would cost us an extra 15% on the development of super-deluxe hardware. If we dont have OpenSource compatible drivers, we can lower the cost of super-deluxe hardware by 15% and still make profit on it.

          Mr CEO: Ok, that sounds even better.

  • Just great... (Score:5, Informative)

    by xchino ( 591175 ) on Monday December 16, 2002 @06:30PM (#4901909)
    I am an op in a Linux support channel on IRC, and I always dread new rleases of both kernels and redhat. It never fails.. some noobie comes in *demanding* we help him fix the production mail server he just trashed by installing RH8 or the newest kernel (dev or otherwise).

    For anyone out there who is just waiting and drooling on themselves over 2.6, unless you NEED one of the few features present in a new kernel, you have no need to upgrade. The latest isn't always the greatest, and even "stable" releases need to go through testing before you put them in production.
  • Good riddance (Score:5, Interesting)

    by jpmorgan ( 517966 ) on Monday December 16, 2002 @06:37PM (#4901979) Homepage
    I'm glad they're removing the kernel-mode webserver; that thing just offended the sensibilities. There always seems to be far too much temptation to solve problems in Linux by ramming things into kernel-mode, and I'm glad the kernel developers are interested in reversing this trend.

    Particularly when there's no demonstrably good reason for running a kernel-mode webserver; lots of recent development has shown that a well-written user mode webserver can easily match the speed of a kernel mode webserver on modern hardware (i.e., context switches are relatively inexpensive).

    As for further restrictions on binary-only modules... I forsee more arguments about which license is freer, the GPL or the BSD/MIT license.

    • Re:Good riddance (Score:2, Informative)

      by CrayzyJ ( 222675 )
      They are not removing both kernel-mode Web Servers - only kHTTPD. Tux will remain. The maintainers decided it was not wise to support both. (my information comes from the LKLM.)

      "lots of recent development has shown that a well-written user mode webserver can easily match the speed of a kernel mode webserver on modern hardware"

      Could you provide proof here? The research I have done shows kernel-mode servers beating the pants of user-mode servers, especially for static content.
  • by I Am The Owl ( 531076 ) on Monday December 16, 2002 @06:38PM (#4901999) Homepage Journal
    In what way could Linux possibly be helped by placing additional hurdles before companies which want to write binary modules for the kernel?

    Does anyone think for a minute that ATI and nVidia are going to release all their trade secrets under the GPL just so they can make Linux users happy? No way. More likely, they'll just port their stuff to FreeBSD and abandon Linux, driving all the serious graphics people (movie production companies, engineering firms, etc.) away from Linux. Great work guys. Guess that's what happens when you let RMS run the show...

    • In what way could Linux possibly be helped by placing additional hurdles before companies which want to write binary modules for the kernel?
      • Users of "alternate" architectures, for which binary modules are rarely released, will benefit by being able to compile (or port) the source code.
      • Users who would like to upgrade to a new version of the kernel or distribution will benefit by not having to wait for the vendor to release a new binary.
      • Kernel developers will benefit by being able to identify bugs by reading the source code, instead of having to reverse engineer binaries.

      These make the issue worth considering.

    • Re: (Score:3, Insightful)

      Comment removed based on user account deletion
      • by MisterFancypants ( 615129 ) on Monday December 16, 2002 @07:21PM (#4902461)
        I think you will find that Linux has more weight than those companies (at least with the visualization / graphics people I deal with) with the customers. Say nVidia stops making drivers for linux, all ATI has to do is open source their driver and boom, they have cornered the market on high end video cards for the fastest growing OS.

        You haven't done any driver development in the past 3 years have you? In many cases companies CAN'T release full open source drivers even if they wanted to because they are licensing technology from third parties for their hardware and/or driver software. The problem is a lot more complicated than 'boom, Open Source the drivers'.

    • Does anyone think for a minute that ATI and nVidia are going to release all their trade secrets under the GPL just so they can make Linux users happy? No way. More likely, they'll just port their stuff to FreeBSD and abandon Linux

      Actually, they'll probably just ditch Open Source altogether, since it is a liability for them. Why should they support FreeBSD, if the FreeBSD developers could pull the same stunt at any moment?

      No, the most likely scenario is that nVidia (and other companies like them) will start to see Open Source as an arrogant, elitist movement, and simply stop being nice to us. Which I would completely understand.

  • Yay! Fewer features! (Score:5, Interesting)

    by Mannerism ( 188292 ) <keith-slashdotNO@SPAMspotsoftware.com> on Monday December 16, 2002 @06:39PM (#4902002)
    I'll risk my karma for the sake of saying: Three cheers for those who decided to eliminate deprecated features instead of bloating the code and endlessly confusing us all by leaving them there forever.

    Thankfully, open source makes this a feasible thing to do: if your legacy apps won't run without the old features in the kernel, then change your legacy apps (or, hell, if you're brave, change the kernel).
  • by europrobe ( 167359 ) <(ten.purep) (ta) (leinad)> on Monday December 16, 2002 @06:42PM (#4902034) Homepage
    If non-GPL companies feel they can require users to install binary-only modules, why not simply requiring them to apply a kernel patch to remove this new limitation first?

    Or, better still, why not delivering the whole product with an installer doing all this for them? It's not going to break GPL, as long as they publish the source code for the patch itself, which should be trivial.

    I'm all for GPL, but this is not going to make that big an impact.
  • Are they nuts? (Score:5, Interesting)

    by I Am The Owl ( 531076 ) on Monday December 16, 2002 @06:44PM (#4902057) Homepage Journal
    This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers. Reminding the purveyors of binary modules that they continue to operate at the pleasure of the Linux kernel developers and their open-source licenses is seen to be a necessary (even enjoyable) task.

    See also: quickest way to discourage commercial development on your platform.

    Gee, do you think all these corporations who have been embracing Linux in these past few years will still be using it when they can no longer use their expensive software investments with it? I doubt there are reasonable open source alternatives for most of these applications, like video card drivers or movie production applications, for example. Good luck on getting more people to adopt your platform after that.

    I forsee a massive move to FreeBSD if this bullshit continues.

    • Best solution (Score:3, Interesting)

      by nuggz ( 69912 )
      The best solution depends on your point of view.

      For some technical correctness is a primary goal, in Linux this means that sometimes features and interfaces change.

      This may tend to piss of some, but you end up with a technically superior product.

      For others consistency of interfaces may be most important and technical correctness is secondary.
      This tends to generate lots of legacy crap, we see this in MS Windows. Now they're cleaning up, and we have the compatibility problems.

      There is always a tradeoff. But I think a well documented technically good solution is best.
    • Re: (Score:3, Informative)

      Comment removed based on user account deletion
    • Wow, I was amazed when some morons thought that just because binary-only drivers no longer have full access to the whole kernel (yes, there will be Linux 2.6 binary only kernel modules) but you seem to top them all by thinking that commercial *applications* are affected by all this.

      I wonder if the parent is a professional Linux-hater spreading FUD or just plain ignorant.

  • Reiser4? (Score:4, Interesting)

    by Dionysus ( 12737 ) on Monday December 16, 2002 @06:51PM (#4902128) Homepage
    Anyone know if Reiserfs4 got into the 2.6 release? I think I read Reiser had been pushing Linus to include Reiser4, and from what I've read in LinuxJournal, Reiser4 supposed to be 2-3 times faster than Reiser3.
  • That interview was interesting, but weird. I've just finished writing a tutorial introducing the Linux kernel [newtolinux.org.uk], and I had to scratch my head over some of the things mentioned in the Tinyminds article. I know they didn't exactly aim the article at complete newbies, but it'd be nice if hackers could make a little more effort to make what they say intelligible for the average human.

    A simple example might be where Robert Love mentions the need for a standard disk layer. What does that mean, to somebody who doesn't understand the way that the kernel in many areas creates a standard set of instructions (e.g. for disks, like "write", "access x data") and that he thinks this should be extended to disks, to take some of the bloated code that repeats all this stuff out of the SCSI codebase?

    I think hackers in general really need to work on getting their ideas across to the more average person, otherwise most people have no reason to get excited by new releases unless they enjoy growing numbers!

    • I think hackers in general really need to work on getting their ideas across to the more average person

      If everyone were to do that, nothing would ever get done because we'd all be writing tutorials (no offense). In any field--hell, in life--you learn to denote complex semantics with symbols so you can then refer to even more complex semantics. Those symbols might be words like "disk layer" or "dog" or "average person" or whatever. To have to constantly explain the never ending chain of meaning of the composite parts to the would be fruitless.
      • You make an interesting point. Maybe Tinyminds just chose the wrong person to ask, or maybe they should have tried to clarify his answers :) Either way, I think it's important that big changes like kernel 2.6 are explained to the whole community.

        Perhaps alongside the normal changelogs with major revisions, a layman-friendly changelog could be written, just describing the changes in easier terms (not laymans, you can always simply link to a useful tutorial (ahem, *grin*) which will explain the complete basics).

        Just imagine you're a manager, and your IT staff have converted your servers over to GNU/Linux. You read somewhere that kernel 2.6 is out, and you wonder "what does that mean?", and yet you can't find out, and perhaps even your IT staff can't find out (as kernel internals arent' exactly a prerequisite for every sysadmin) - will that impress you? I doubt it.
  • Derivative works. (Score:4, Insightful)

    by OoSync ( 444928 ) <wellsed&gmail,com> on Monday December 16, 2002 @07:07PM (#4902321)
    I think the position the kernel developers are in is determining exactly what is a derivative work. In any other GPL piece of code, if you muddle with the inner workings of the code, then your code is a derivative work and must also be GPL if you release it. Well, according to this article, most modules fiddle with the inner workings of the kernel in a very intimate way. The logic follows that such code is a derivative work (i.e. it has to use kernel code to do such things) and must be GPL, which binary-only modules violate. This isn't about doing away with binary-only modules, its about clarifying the Linux kernel's license and enforcing it. Binary-only modules can still run, they are just restricted in what interfaces they can use to communicate with the kernel instead of being on intimate terms with GPL modules. Sounds fair. Furthermore, its the *legal* thing to do.



    As other posters have already specified, you can distribute your own kernel or patch that doesn't enforce the GPL license, but in doing so you may indeed be violating the GPL yourself. Remember, the GPL is like any other license, you must abide by it or lose the privelidge of using the software.



    Also, this does not break userspace (i.e. proprietary and binary-only applications), unless such software is dependent on a binary-only module.



    I, for one, am curious to see how those people who really want to distribute binary modules will react. I think many have a market in Linux systems and will continue to provide their code. However, they may be well-served to develop a GPL module that provides very consistent interfaces for binary-only modules. The kernel developers don't want to do this, but if developers of binary-only modules develop it and apply it, well that's their business.

    • Remember, the GPL is like any other license, you must abide by it or lose the privelidge of using the software.

      Actually, no. GPL doesn't deal with use at all, only with distribution.
  • Drivers please (Score:5, Insightful)

    by visualight ( 468005 ) on Monday December 16, 2002 @07:12PM (#4902393) Homepage
    When a new product comes out on the market, the box almost always includes a cd with a windows driver on it. That driver is written and supported by the manufacturer of the product.

    I love linux but I want so bad to be able to buy the latest neates thing and have it just work right away in linux and not a year later. Right now I have a radeon 9000 pro and a wintv pvr 250 I'm struggling with.

    Drivers are the ONLY issue I have with linux and because of that I'm trying to learn C but I have so far to go and in the meantime I have to just be patient and wait for the vendor to produce a driver or for some linux developer go buy the same card I have and make it work. That's all fine and dandy except for this one thing: Some of these kernel developers are PAID to develop the linux kernel. That's right, it's their JOB. Not to show any disrespect to those kind hearted souls who sacrifice their spare time to do a community service, but as an enduser who has paid far far more for linux distro's than I ever would have paid if I was using Windows I have a right to insist on support for ME the end user. I have purchased Redhat 7.1, Mandrake 8.2,9.0 and every Suse since 6.2. It's my opinion that the kernel developer employed by the distro's have an obligation to develop the linux kernel with me in mind. And I want drivers. I don't care if they're GPL or not. I want hardware vendors to write the driver for the hardware they sell and distribute that driver WITH the hardware. And I want that driver to just work. That means the linux kernel must allow it to work. Politics and personal philosophy regarding open source have nothing to do with the discussion. I'm a paying customer and I should be treated that way.
    • Re:Drivers please (Score:4, Interesting)

      by mcelrath ( 8027 ) on Monday December 16, 2002 @08:58PM (#4903378) Homepage
      That driver is written and supported by the manufacturer of the product.
      This is almost universally a bad way to do it. It results in crappy drivers and poor user support (companies only want to sell you shit...after you buy it they don't really care if you can't get the driver to work). This is the source of 99% of the instability of Windoze...crappy drivers that bring the system down.

      Back in the day there was this company called WordPerfect. Their schtick was that there were thousands of printers, but no universal way to get shit printed. So they wrote printer drivers, for all of them, and they were fantastic. WordPerfect quickly took over the market because they wrote printer drivers. They knew how the printers would be used and figured the best way to access them, and were motivated to maintain the whole base of drivers.

      Open source drivers are much the same way. Owners of hardware have a pretty serious motivation to make the drivers work. You also get higher quality drivers because of the many-eyeball effect. The best situation for customers and companies alike is for the companies to release a "beta" driver, detailed specs, and hire one guy to coordinate work on the driver. Then let the thing evolve. It's the beauty of the source.

      "Source code is like manure, if you spread it around things grow. If you hoarde it, it just smells bad."

      -- Bob

  • Wow (Score:3, Interesting)

    by MeanMF ( 631837 ) on Monday December 16, 2002 @07:28PM (#4902518) Homepage
    Most observers foresee a tightening of the limits on binary modules. This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers.

    Can you imagine the magnitude of the sh*tstorm they would create if Microsoft tried to pull something like this?? That's a pretty ballsy move for people who rely on the good will of the companies developing software for their platform.
  • by cureless ( 35682 ) on Monday December 16, 2002 @07:34PM (#4902576)
    I've seen quite a few posts that seem to imply that binary modules cannot be used with the new kernel. That is not true.

    What is true is that they are doing things like not exporting the system call table so that any module can change it at their will. That is, a binary module can't replace the write call or fork call. There are other mechanisms like syscall registering for modules that need some new system call. (I haven't looked into that aspect yet).

    What they are doing is not encouraging binary only modules. (and by binary I mean non GPL). The example they use is the modification of work queues. Things like tainting the kernel (so the kernel knows when it's been tampered with by proprietary code (read loaded a non GPL module)) have been around for a while now. Kernel people will not give support to problems with tainted kernels.

    I use and nvidia driver in one of my computers, and that taints my kernel. I understand the implications. I also see no reason why nvidia has to modify my syscall table.

    In short, I don't think normal "drivers" need to modify the syscall table. You can add a new filesystem, network protocol, etc without the need to modify the syscall table. So stop complaining about no more binary only drivers.

    I agree with the developers in the choice. I also wish nVidia, along with the other companies, GPLed their drivers. After all, they are _drivers_ for the hardware I bought. And if they don't want to, they could at least release the complete specifications for the hardware so we can build our own 3D accelerated drivers.

    cl
  • Open discussion. (Score:3, Insightful)

    by OoSync ( 444928 ) <wellsed&gmail,com> on Monday December 16, 2002 @07:54PM (#4902778)
    Its also important to realize that the methods being used to enforce the GPL in the kernel have been developed completely in the open. If binary-only module developers are having problems with this, have they spoken out, have they said anything, does this really affect them much? I've not seen much of a discussion of this on Kernel Traffic, except that the Linux kernel developers don't feel its their business to make concessions for binary-only modules.

    As for arrogance, they're enforcing the license on their product. Microsoft would do the same for their products if your code massages their code without abiding by their license.

    BTW, this sounds like an idea for Ask Slashdot. Get someone developing the Linux/BSD drivers from nVidia to answer questions about this and find out if it really is a problem, or if /. readers are just gettting huffy for no real reason.
  • by karlm ( 158591 ) on Monday December 16, 2002 @08:05PM (#4902905) Homepage
    Each kernel module declairs what liscence it falls under. More symbols are exported for Free modules.

    Nobody is preventing NVidia from writing binary-only drivers, they just need to hook into the kernel at lower levels. Some kernel developers want the NVidia people to mooch less.

    They're tightening restrictions, not banning binary-only modules. Relax. They're just saying if NVidia wants to use binary-only modules, that's thier perogative, but it's a huge pain for the developers that become de facto support for those NVidia drivers. Basically "You want to be a pain in my ass, go ahead, but you're now getting less help from me to do it."

    The *BSD kernels are simpler and may not have equivalents to the special higher-level functions that are being hidden from non-Free modules. I don't know. In any case, it's unlikely NVidia is going to jump ship for one of the *BSDs. I'm not even surewhat companies hope to achieve by providing binary-only drivers. Thier competitors certainly have decompilers. If they really need to protect patented algorithms, that can be done in firmware/hardware and/or usermode drivers. Usermode drivers also prevent binary-only kernel instabilities and reduce kernel dependancies.

  • by Wateshay ( 122749 ) <bill@nagel.gmail@com> on Monday December 16, 2002 @08:41PM (#4903223) Homepage Journal
    A lot of people are complaining that the new binary module licensing changes are too restrictive, and reduce people's freedom when writing drivers (and I won't argue with that). Something else to think about, though, is whether the new changes are really the best thing to do from a purely GPL standpoint, where the end goal is to have as much software as possibly be free. As the GNU project [gnu.org] points out in their discussions on licenses [gnu.org], it is sometimes a better idea to allow binary software. There are other operating systems than Linux (I hear there's a company [microsoft.com] in Redmond that makes one that's quite popular). If Linux discourages or forbids binary only drivers, the driver manufacturers won't make drivers for Linux (since, in many cases, they are bound by licenses that won't allow them to release open source drivers). If Linux doesn't have hardware support, then fewer people will be willing to use it, and thus fewer software companies will release Linux versions of their software. So far, Linux hardware support has been very good, but slow. New devices are often poorly supported. However, commercial drivers (binary and open source) have been starting to gain momentum, new hardware is more likely to have support, often from the manufacturers of the hardware themselves. I hope that the new 2.6 kernel won't stall that advancement, and seriously slow widespread adoption of Linux as a viable OS.
    • >> If Linux discourages or forbids binary only drivers, the driver manufacturers won't make drivers for Linux (since, in many cases, they are bound by licenses that won't allow them to release open source drivers).

      Exactly. This is especially true with video cards.
  • by DeathPenguin ( 449875 ) on Monday December 16, 2002 @09:25PM (#4903579)
    No binary modules? What self-rightous idiot thought of that? That would alienate all major support for video cards. For all you purists, get it through your thick skulls: Patents exist on OpenGL and many other technologies (Such as S3TC) that are required for many applications (Such as Unreal Tournament 2003). Check other threads with nVidia-related information and you'll find more detailed information on nVidia / SGI / Microsoft / etc. patents on widely used industry standard OpenGL technologies.

    And besides, imagine the hypocrisy of the Linux kernel devs taking away choices from the people that use their kernel. I mean, I thought Linux was supposed to be for people who actually wanted control over what goes into their kernel.
  • by ender's_shadow ( 302302 ) on Monday December 16, 2002 @11:24PM (#4904387) Homepage
    "Fundamentally this is a simple change but it requires a large-scale reimplementation of code to protect concurrency. Thankfully, the kernel's SMP spin locks already provide the large majority of this protection. So these spin locks are used as markers of where to temporarily disable preemption, to avoid mangling shared data. It works and everyone is happy."

    Is this a hack? It sounds like a workaround, but maybe it's just creative use of existing tools.

    Can anyone tell me if this is how other systems do preemptive multitasking? I really don't know. Is this similar or analogous to Intel's new chip that acts like a multiprocessor?

  • Stable API (Score:3, Interesting)

    by guacamole ( 24270 ) on Tuesday December 17, 2002 @02:56AM (#4905541)
    Why can't Liunx kernel developers come up with an API for binary kernel modules and keep it stable at least between minor kernel releases so that users could use third party kernel modules withfout having to recompile them for each kernel upgrade?

    Look at Solaris. It's quite possible to take even certain kernel modules that were built for Solaris 2.6 and use them on Solaris 8 without recompiling. I am not even mentioning that kernel modules don't break at all between minor kernel releases (or patch levels) on Solaris.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...