Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel to Fork?

Posted by CmdrTaco on from the remember-when-the-kernel-spooned dept.

Ninjy writes "Techworld has a story up about the possibility of the 2.7 kernel forking to accomodate large patch sets. Will this actually happen, and will the community back such a decision? "

13 of 578 comments (clear)

  1. From the article... by Anonymous Coward · · Score: 5, Insightful

    > Each version of the kernel requires applications to be
    > compiled specifically for it.

    FUD FUD FUD. No. no no no. NO!. Who writes this generic shit?. There's no truth behind the above statement and it just implies something that is not a problem.

    1. Re:From the article... by DanTilkin · · Score: 5, Insightful

      FUD generally implies deliberate disinformation. All I see here is a clueless reporter. To anyone who knows enough about Linux to make major decisions, Linus Torvalds will fork off Version 2.7 to accommodate the changes should make it clear what's going on, then the rest of the article makes much more sense.

    2. Re:From the article... by elendril · · Score: 5, Interesting

      You're right: Each version of the kernel doesn't requires applications to be compiled specifically for it.

      Yet, where I work, the applications have to be specifically recompiled for each of the three versions of the Linux distribution currently in use.

      While it may be mainly the in-house distribution designers fault, it is a real mess, and a major reason for many of the engineers staying away from Linux.

    3. Re:From the article... by Anonymous Coward · · Score: 5, Interesting

      WoodstockJeff - "Not so under Windows, and windows will only load the first version of a named DLL it finds, and hang onto it until you reboot"

      Untrue - there are SEVERAL rulesets that allow side-by-side loading of DLL's in Windows ever since Windows 2000 in fact.

      Ruleset for library loading underneath Windows2000/XP/2003 (assuming developer/oem of the software didn't "hardcode" his library path define or LoadLibrary API call with a path to a file), is as follows:

      "DLL HELL" may occur on Win32 OS when 2 of SAME named "Dynamic Link Libraries" (.dll extension, executable with no loader header that cant self initialize) exist on a system and are accessible to a program. Since same name it can cause a program to "grab hold" of wrong version build to init for call functions it uses from it!

      Can be problem that causes crash in programs because program expects function it calls to return integer return from a function but latest build of DLL of same name sends back pointer data instead!

      Microsoft overcame a great deal of "DLL Hell" using ActiveX controls (OLE Servers, which have .DLL extensions also), that have .OCX extensions too. These are "marshalled" (loaded) not by name, as is done with older .DLL file types using the LoadLibrary call, but via a thing called a "GUID" (Globally Unique Identifier).

      This is a 128-bit UNIQUE generated number in the registry that summons the CORRECT build the calling program requires by internally checking the .ocx or .dll file being called for its internal version information (using the functions this program uses on Version checking no doubt, std. Win32 API call method).

      Microsoft has also put in "Side-by-Side" loading in their newer Operating Systems (2000/XP/2003) which can load the older type DLLs technically by name but into RAM separately, where they can be accessed separately by programs (the program that calls and finds the one it loads) so no "collisions" occur.

      This is a GOOD move, but still can be problematic if the program finds the wrong version build of the .DLL it is calling, first

      Order of seeks used by Win32 Portable .exe files for finding DLLs to load -

      NT based Os by default, use different approaches for 32-bit vs. 16-bit apps:

      1.) For 32-bit apps, NT/2000/XP/2003 search for implicitly loaded DLLs at:

      a. .exe location folder
      b. Current folder
      c. %SystemRoot%\SYSTEM32 folder
      d. %SystemRoot% folder
      e. %Path% environment variable

      * BUT if a DLL is listed as a KnownDLLs here in registry:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Cont ro l\Session Manager

      As REG_SZ entry type & Value of DLL name w/out the extension + data value of DLLname w/ .DLL extension, then search order becomes:

      aa. %SystemRoot%\SYSTEM32.
      bb. .exe file folder.
      cc. Current folder.
      dd. %SystemRoot% folder.
      ee. %Path%.

      KnownDLLs are mapped at boot time. Rernaming or moving during a session has no effect.

      You can alter this behavior by including the 8.3 DLL name in the ExcludeFromKnownDlls entry, a REG_MULTI_SZ value, & one per line in that comma delimited listing.

      (This makes NT believe that the DLL is not listed in KnownDLLs.)

      2.) For 16-bit apps, Windows NT uses KnownDLLs for both implicitly and explicitly load DLLs. The value is at:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Cont ro l\WOW.

      Here in that key, KnownDLLs is a REG_SZ value that lists 8.3 DOS formatted DLL names, & is separated by spaces. Without a KnownDLLs entry, WOW searches:

      a. The current directory.
      b. The %SystemRoot% directory.
      c. The %SystemRoot%\SYSTEM directory.
      d. The %SystemRoot%\SYSTEM32 directory.
      e. The .exe file directory.
      f. The directories in your Path.

      With

    4. Re:From the article... by Etyenne · · Score: 5, Informative
      Oh, man. You hit a button... I F-ING HATE PACKAGE MANAGERS UNDER LINUX. I try and update program X. Oh oh, dependency. Chase that down. That creates two more dependencies. Chase those down. Soon it cascades into a total nightmare. And then, I frankly give up, and just download the source, recompiled it in parallel to the package, and just delete the package.

      You don't understand. A package manager is a piece of software that does resolve dependency, download packages (from the Internet or local media) and install them for you. That is why they are called package manager. Using these, you never have to "chase" down package, it's all automated. There are many of them : apt, yum, up2date, urpm, emerge, etc.

      Please get current instead of making a fool of yourself on the Web; this problem have been solved a few years ago. Your favorite distro probably use one, and you don't even know. Which one is it, anyway, so I can give you the executive summary on it's usage ?

      --
      :wq
  2. Utter bunk by Rysc · · Score: 5, Informative

    The Linux kernel forks all the time. 2.5 was a fork of 2.4 when big patches couldn't be merged otherwise. This is all terribly normal, the article was obviously written by an uninformed outsider. 2.6 will fork into 2.7, which most people wont use while big changes are made, and eventually 2.7 will become 2.8, and then for a while there will be one version. Until the next "fork," also known in Linux land as a "development version."

    --
    I want my Cowboyneal
  3. New linux development process by Anonymous Coward · · Score: 5, Insightful
    It strains credulity to call the 2.7 linux kernel a "fork" of linux. Every new development version of linux always starts out by forking the old stable kernel. This is how linux 1.3, 2.1, 2.3, and 2.5 all started. It is quite irresponsible for a journalist to proclaim all this doom and gloom over what is in fact a normal development fork in a proven development process.

    In fact, out of all the news articles out there about linux 2.7, it seems (not that this surprises me) that slashdot went out of its way to pick one laden with the most possible negative FUD and the least possible useful information about what really is news with 2.7. A much better writeup can be found at LWN. In summary, the present situation is:

    • The -mm tree of Andrew Morton is now the Linux development kernel, and the 2.6 tree of Linus is now the stable kernel. This represents a role reversal from what people were expecting last year when Andrew Morton was named 2.6 maintainer.
    • Andrew Morton is managing the -mm tree very well. Unlike all the previous development kernels, the -mm tree is audited well enough that it is possible to remove patches that prove to have no benefit (and this does often happen). Bitkeeper is to some degree contributing to this flexibility, although not every kernel developer uses it.
    • The development process is going so smoothly that there may not need to be a 2.7 at all; for the first time in linux development history the developers are able to make useful improvements to linux while keeping it somewhat stable. If there is a 2.7 at all, it will be used for major experimental forks and there is no guarantee that the result will be adopted for 2.8.
    There is a story here, but you could easily be forgiven for missing it if you follow the link. The story is that linux development has changed, it is better than ever, and if (not when) 2.7 shows up, it's not gonna be the 2.7 that you're used to seeing.
  4. Idiot. by lostlogic · · Score: 5, Insightful

    The writer of that article is an idiot. The linux kernel forks after every major release in order to accomodate large patches. How did we get to where we are today? Linux-2.4 forked into 2.4 and 2.5 to allow the major scheduler and other changes to be made on a non-production branch. Then 2.5 became 2.6 which was the new stable branch. Currently there are 4 maintained stable branches that I am aware of (2.0, 2.2, 2.4, and 2.6), having a new unstable branch is just the same path that Linux has been following for years. That writer needs to STFU and get a brain.

    --
    --Brandon
  5. Pretty baseless article. by mindstrm · · Score: 5, Interesting

    No details, no important names.. no nothing.

    There are plenty of forked kernel trees out there. Most continually merge in changes from Linus' tree, though.

    A fork doesn't matter. What matters is what it represents. If there is enough popularity that the Linux community ends up using incompatable forks, then yes, we have a problem.. but forking in no way necessarily leads to this.

    As always, the available kernels in wide use will reflect what people actually want to use.

  6. Re:I'd Like to Run Linux -- Just No Time by asciiRider · · Score: 5, Insightful

    Why is it that every Windows XP user thinks the goal of the Linux community is to convince windows user to make the switch?

    Dude - just stick with Winblows. You have no time to "know linux", as you put it, so just stick with what you know. You can post on Slashdot either way.

    Please, developers, don't dumb Linux apps/distros down so much that it looks and feels like Windows.

  7. Wow, this article is pure uneducated guesswork... by discord5 · · Score: 5, Insightful

    Well, this was fun to read. This article is about as educated about the subject as the average donkey.

    In a worrying parallel to the issue that stopped Unix becoming a mass-market product in the 1980s - leaving the field clear for Microsoft

    Uhm, what gave MS the edge in the 80s was cheap i386 (well, actually 8088) hardware, and a relatively cheap OS (MS-DOS). Unix servers cost an arm and a leg in those days, and many companies/people wanted a pc as cheap as possible. Buying an i386 in those days meant running DOS, and the "marketplace" standardized around MS-DOS.

    Each version of the kernel requires applications to be compiled specifically for it.

    Utter bull. Upgrade kernels as much as you like, it won't break software unless you change major/minor numbers perhaps. The same thing will happen to windows if you start running stuff for win2k on win'95. But this is rather a matter of features in the kernel, not compilation against the kernel.

    So at some point, Linux founder Linus Torvalds will fork off version 2.7 to accommodate the changes, Morton said at the SDForum open source conference.

    And the big news is? This happens every couple of years, with stable versions having even minor version numbers and unstable versions having odd minor version numbers. This helps admins and users to effectively KNOW which versions are good for everyday use, and which versions are experimental and for developers.

    He cited clustering as a feature sought for Linux.

    Well, imagine a Beowulf cluster... How long have those patches existed? There's several ways to build a cluster as long as you patch your kernel.

    OSDL does not anticipate, for example, having to ever rewrite the kernel, which would take 15 years, Morton said.

    And why on earth would they want to do that? Linux is on the right track, so why bother with an entire rewrite of good functional code with good design.

    Open source has focused on software such as the operating system, kernels, runtime libraries, and word processors.

    It's also focussed on multimedia (xmms, mplayer, xine), webservers (apache), mailservers (sendmail, qmail, postfix)... I'd rather have people say that open source has focussed on internet servers than stuff it needs to make an OS run and wordprocessors. This like saying that an oven is primarily being used for making toast, while actually it also bakes cake, pizza and whatever you toss inside.

    I'm sorry, this kind of article belongs in the trashbin. Either the journalist doesn't know what he's writing about, or he's being paid to know nothing about the subject. One of the things that keeps suprising me in business IT journalism is the lack of knowledge these people have about the subjects they're writing about.

  8. Kernel forking by YetAnotherName · · Score: 5, Funny

    For the kernel itself to support fork(2), you'd have to have a meta-OS running the kernel, similar to a supervisor OS running as a user task in Mach.

    But I can see things deteriorating rapidly: someone will want vfork for kernels, someone else will implement kernel-to-kernel pipes, someone else will make vfork obsolete, someone will complain about kernels not getting SIGCHLDs from their child kernels, etc.

    What? No, of I course I didn't read the fsck'n article ... not even the summary!

  9. Kernel Fork by loconet · · Score: 5, Informative

    I notice a number of posts indicating that this is just pure uninformed journalism but is it? Or is he actually just blowing up a different related issue out of proportion.

    In the Linux Kernel Development Summit back in July, the core developers announced they weren't creating a 2.7 development kernel any time soon (discussed here and here).

    Developers liked the way things were going with the new BitKeeper in use by Linus and at the time, they didn't see the need to fork a 2.7.

    Traditionally before BitKeeper, kernel maintainers would send Linus 10-20 patches at once, then wait for him to release a snapshot to determine whether or not the patch made it in. If not, they would try again. During the 2.5 development cycle, problems started over dropped patches and that is when Linus decided to try BitKeeper.

    According to Greg Kroah-Hartman, kernel maintainer, Bitkeeper has increased the amount of development and improved efficency. From 2.5 and 2.6, they were doing 1.66 changes per hour for 680 days. From 2.6.0 to 2.6.7 they were at 2.2 patches per hour thanks to the ability of wider range of testing of patches that went into the tree. The new process is - 1) Linus releases a 2.6 kernel release. 2) Maintainers flood Linus with patches that have been proven in the -mm tree 3) After a few weeks, Linus releases a -rc kernel 4) Everyone recovers from a load of changes and starts to fix any bugs found in the -rc kernel 5) A few weeks later, the next 2.6 kernel is released and the cycle starts again.

    Because this new process has proved to be pretty efficient and is keeping mainters happy, it was predicted that no new 2.7 kernel was to be forked any time soon unless a set of changes appeared big enough and intrusive that a 2.7 fork is needed. If that is the case, Linus will apply the experimental patches to the new 2.7 tree, then he will continue to pull all of the ongoing 2.6 changes into the 2.7 kernel as the version stabilizes. If it turns out that the 2.7 kernel is taking an incorrect direction, the 2.7 will be deleted an deveryone will continue on the 2.6. If 2.7 becomes stable, it will be merged back into 2.6 or will be declared 2.8.

    In conclusion, there was no plan for a 2.7 any time soon thanks to maintainers working well in the current setup but this was not carved in stone. It might just be that big enough changes are calling for a fork.

    --
    [alk]