Slashdot Mirror
Linux Kernel to Fork?
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? "
← Back to Stories (view on slashdot.org)
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
"Paul Krill, Infoworld" seems to specialize in breathless, high-anxiety stories about rather ordinary events.
InfoWorld
PC World
Trusted by cats.
assert(expired(knowledge));
The first digit is the major version; aka 1.x, 2.x. The second digit is known as the minor version. From your examples, you appear to be asking for a consistent driver API across each minor version.
HTH, HAND.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because installers for Windows programs silently replace DLLs with the versions they require... which can and does cause earlier programs to suddenly fail, because they depended upon a particular DLL's quirks. It's called "DLL Hell".
Linux programs are more proactive about checking library versions. But, you can install multiple versions, because the shared libraries usually have different names. 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. If that version fits your program, life is good; if not, well...
The first thing that disappears when you don't get paid as a developer is backwards compatibility. It's the type of thing only paying users (vs casual users and developers) care about.
I completely agree and wish the kernel API were kept more stable. Which is saying a lot, as the Linux kernel API is currently way more stable than glibc, GCC, and most user-space libraries. Virtually all of my Linux trouble-shooting time over the last few years has been caused by API versioning issues in glibc and/or GCC.
Journalists tend to be ignorant, so a little education can come in useful. Here's my letter to the editor:
s ID=2648&Page=1&pagePos=2
Re: Is Linux about to fork?
Dear Kieren McCarthy,
I cannot believe this article:
http://www.techworld.com/opsys/news/index.cfm?New
The Linux kernel has historically alternated between stable
(even-numbered) sets: 2.0, 2.2, 2.4, 2.6, and odd-numbered development
sets. For this to be cast as a major disaster now that the next
development kernel is expected to be starting up is extremely odd. If
this is forking, it is forking only in the most pedantic sense, and yet
Paul Krill's article paints this as a major problem. This portrays a
simple lack of understanding of the Linux development process. The
article is therefore more confusing than informative.
Yours sincerely,
Wikileaks, no DNS
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
Software distributed on Windows are either compiled statitically or ship with their own kit of .dll. It's necessary because Windows does not have *any* dependency resolution facility and, up until recently, had no library versionning mechanism either. There are drawback of shipping "ready-to-run" software : waste of disk space (static executable are larger, and duplicate .dll take up room), having library spread all over your disk instead of having them in a central location, potential library overwriting (aka "DLL Hell") and no way to update library centrally (witness the recent security hole with GDI+; you had to run an utility that scan your entire disk in search of vulnerable application). The Windows way *do* work, but it is certainly not the optimal way. People have gotten used to the drawback thus they don't complain.
Just for fun, search for files named "mfc42.dll" on your disk (or any other common Windows dll; I'm not very up-to-date on these). How many are there ? Are all of these up-to-date ? Does any of them have security issues (known buffer overflow, for example) ? How much disk space do they use collectivelly ?
You could distribute application the same way on Linux, but people don't because it would break the architecture of having your libraries centrally stored and managed. The Linux architecture to libraries management is much superior but have the drawback that it require that you use a dependencies-aware package manager correctly. Apparently, you don't.
:wq
Dear Anonymous Coward,
apt will not put you into 'dependency hell' unless at least one of the following preconditions is met:
1) You are running debian/unstable
2) You are overriding warnings (using the --force switch)
3) You are doing something stupid, as root
sincerly,
the truth
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]
PJ at http://groklaw.net/ has a comment on the forking. Seems like the fork rumor is due to a misunderstanding. The forking in the talk was about 2.7 being a fork off of 2.6
The compatibility problem is due to glibc. glibc is the software developer's worst compatibility nightmare. Code compiled under one version won't work under another version, regardless of whether you use dynamic or static linking. This problem is so severe that even different minor versions of glibc don't work together. They are continually changing their symbol names. It's gotten so bad that we write our own versions of c libary calls so we can have some minimal level of compatibility. By way of contrast, most proprietary unix operating systems (such as Solaris or Tru64) make a huge effort to ensure compatibility. Code I've compiled ten years ago under SunOS or OSF still runs on the latest versions of those operating systems.
Groklaw clears this mess up. Turns out someone doesn't understand the word "fork."