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)
> 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.
They just got too many weird patches, and had to put them somewhere.
Business as usual.
Of course it will happen, whether it's now or later is a different matter. The problem this time is that several of the core kernel devs want to keep 2.6 under active feature development, and doing that in 2.7 means that they don't get nearly as tested.
But it will happen, and probably this year (or early next).
/* FUCK - The F-word is here so that you can grep for it */
I say its about time to get a real development branch going. I'm sick of 2.6 being less that optimally stable, its time for 2.7 to take the untested patches.
thisnukes4u.net
The kernel will fork to a new 2.7 branch. This is exactly what happens every iteration of kernel development. This looks like a case of poor journalistic understanding of the usual linux process and/or fear inducing sensationalist headlines.
Even if this was a more hostile type of fork it wouldn't matter. Some amount of forking is healthy in open source.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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
Im not sure if i like the idea. Developers have have lives, that's why the developement is moving at the pace it is. And i like the pace the developement is at. Forking another kernel tree will split the developers apart and slow down the developement of the 2.6 kernel.
What seems to me like a good idea is to modularize the code so that you can just plug things in and out. That way, if the kernel got forked it wouldn't be much work to remove and add support. I would also like to see projects dedicated to only certain parts of the kernel. For exampmle, one group does networking and another does video and maybe one that check and approves the code. From then on the code would be piecet together in whatever way it suits people and because there's ony one group working on a particular part of the kernel, there would be no repetition. "One fit's all" sort of spreak. One "driver" or piece of code to support some hardware would work an all forks. Then each fork would be kind of like a distribution of pieced together code.
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.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
I think that either the writers of this article, or myself are not getting something here.
A couple of months ago there was a general upheavel over the fact that Torvalds et al. had decided not to fork a developement tree of of 2.6.8, but rather do feature developement in the main kernel tree. The message of the article (brushing aside the compiling-applications-for-each-kernel-FUD) seems to be that they have made up their mind and fork an unstable kernel branch of anyway.
What am I missing?
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.
Firstly, the article is talking about linux itself, not linux distributions which are another issue and may or may not have "massive problems" of their own.
Secondly, linux (the kernel) already "forks" every time a new development version is opened. ie, 2.1, 2,3, 2.5 etc. All this is saying is that 2.7 is about to open.
"Fork" is not a dirty word.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Is this the beginning of FreeLinux, OpenLinux and NetLinux?
What about SCOLinux or MSLinux?
Grundgesetz * 23. Mai 1949 - 30. November 2007 - http://www.vorratsdatenspeicherung.de/
I imagine a future where I can download a copy of Linux and it would install on my system without any configuration
erm.. when did you last try installing linux, and which distro did you use?
I have recently installed ubuntu and fedora 3 on hardware ranging from a fairly old PII 400 with matrox gfx and scsi to an amd64 3000 with radeon 9200 gfx and serial ata, to an ibm thinkpad r40e.
All of these installed with almost no effort and Just Worked. (apart from power management on the laptop which took about 30 mins of googling to find a solution)
I even had hardware accelerated gfx on _all_ of the above machines with no extra configuration of drivers to download or install.
Really, if you want "easy to install and get running" give something like ubuntu or fedora a try. You might be pleasantly surprised.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Already there are massive problems with dependencies.
./configure won't be able to find the libraries because the version installed is too new.
Tell me about it. When I try installing older programs I get compile errors because the libraries aren't backwards compatible, or
I think at some point everyone needs to get together and say OK. Everything from this point on will be compatible with everything from this point on. No more of this crap. One standard installation procedure for every distribution (but each distribution does things its own way). If RPMs are so horrible, then stop releasing everything as RPMs!
Oh no! If this sort of thing is allowed to happen then before long we will start seeing seperate kernel forks for people like Alan Cox, Andrea Arcangeli and Hans Reiser. It could even lead to every major Linux distribution applying their own patches to their own forked kernels.
Then where would we be?
As a person with Linux, I just don't have time to know everything about Windows to install it and keep it running. To me, the amount of time required to know Windows is only one of the things keeping me away. On top of this is all the spyware, viruses, constant severe security flaws, instability and slowdowns that just don't make it a viable system.
I imagine a future where I can buy a copy of Windows and it would work just like Linux. If this could be a reality today, I would maybe consider Windows for some non-technical people.
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.
assert(expired(knowledge));
Hold on, take this into consideration before you hit that "flamebait" button. I'm responsible for a large number of Linux systems at a hosting center, and this is our single biggest complaint:
There needs to be a consistent driver API across each major version of the kernel.
A driver compiled for 2.6.1 should work, in its binary form, on 2.6.2, 2.6.3, and 2.6.99. If Linus wants to change the API, he should wait until 2.7/2.8 to do so.
The current situation is completely ridiculous. Anything which requires talking to the kernel (mainly drivers, but there are other things) needs either driver source code (watch your Windows people laugh at you when you tell them that) or half a dozen different modules compiled for the most popular Linux distributions. These days, that usually means you're going to get a RHEL version, and possibly nothing else. What happens when you're competent enough to maintain Fedora or Debian, but you don't have driver binaries? (Yeah I know, White Box or Scientific, but that's not the point.)
In fact, I recently had to ditch Linux for a project which required four different third-party add-ons, because I couldn't find a Linux distribution common to those supported by all four. We had to buy a Sun machine and use Solaris, because Sun has the common sense to keep a consistent driver API across each major version.
Yes, I've heard all the noise. Linus and others say that a stable driver API encourages IHV's to release binary-only drivers. So what? They're going to release binary-only drivers anyway. Others will simply avoid supporting Linux at all. LSB is going to make distributing userland software for Linux a lot easier, but until Linus grows up and stabilizes the driver API, anything which requires talking to the kernel is still stuck in the bad old days of 1980's-1990's. Come on people, it's 2004 and it's not too much to expect to be able to buy a piece of hardware that says "Drivers supplied for Linux 2.6" and expect to be able to use those drivers.
Tired of FB/Google censorship? Visit UNCENSORED!
We don't know why this reporter is spreading Fear, Uncertainty and Doubt. Maybe they were misinformed, and lack critical skills required to be a journalist. Maybe they were informed, but are looking for something sensational to get readers (it worked). Maybe they're trying to impress their mother somehow, without even realizing they're making up for a playground trauma from 1983. Who knows? Who cares? They're a FUDder - we're interested in the damage they cause, not the damage that was done to them. That's their problem, unless we propose a massive mental health makeover for the world's journalists. That would probably decimate the ranks of the industry, allowing them to get real jobs.
--
make install -not war
I believe that the strength of Linux comes from the fact that it has a central core, which is compatible with basically everything across distros. This makes faster development, and combined with a charismatic leader (Go Linus! :o) makes a very strong platform for an OS. These are my personal beliefs, so feel free to flame me if you disagree :)
-b0lt
got sig?
I'd imagine any article that talks about Linux Forking would have at the very least grabbed one or two quotes from Linus before going to print. Linus is only mentioned once in the article, and that is a passing reference as the owner of the Linux Kernel. And while Andrew Morton may have mentioned what was going on in the interview, the reporter made sure it didn't show up in the article. Irresponsible.
The reporter says that some developers have made big changes, in different directions, to their copies of the kernel source that Linus won't accomodate in a single encompassing kernel. Like desktop and server versions. So he'll have to fork it. Why forking the kernel, rather than just the magic "#ifdef DESKTOP_KERNEL_" that keeps all the manageability of a single kernel source version, is the solution, is not addressed. Combined with the rest of the bad logic and information reported in the article, this is just journalistic kernel panic, and probably not a real issue for the kernel. At least the fork - divergent execution scenarios are a valid issue for maintainers. But there are so many ways to manage source control that punting with a fork seems desperate, and unlikely.
--
make install -not war
What the fork?
I have gas, but my car uses petrol.
...
...
erm
"We all assume that the kernel is the kernel that is maintained by kernel.org and that Linux won't fork the way UNIX did..right? There's a great story at internetnews.com about the SuSe CTO taking issue with Red Hat backporting features of the 2.6 Kernel into its own version of the 2.4 kernel. "I think it's a mistake, I think it's a big mistake," he said. "It's a big mistake because of one reason, this work is not going to be supported by the open source community because it's not interesting anymore because everyone else is working on 2.6." My read on this is a thinly veiled attack on Red Hat for 'forking' the kernel. The article also give a bit of background on SuSe's recent decision to GPL their setup tool YAST, which they hope other distros will adopt too."
CC.
TaijiQuan (Huang, 5 loosenings)
I have read the article three times but still it looks to me like a random collection of irrelevant sentences unrelated to each other. Maybe it would make more sense if Paul Krill himself was written in lisp, or drank less if he's a real biological entity. This article looks like a random google cache copy and paste made in php.
There you are, staring at me again.
I imagine a future where I can download a copy of Linux and it would install on my system without any configuration and every option would be through an option menu, like our Slashdot prefs. If this could be a reality today, I would drop XP in a heartbeat.
Install SuSE, RedHat, or Ubuntu: they are easier to install than Windows XP and come with tons of applications. They even come with excellent printed documentation in case you do need to look something up.
Even easier, buy a PC with Linux pre-installed: you just plug it in and it works.
Someone decided that this is "bad" (and which finally opened the market for DOS/Windows), which I still don't fully get. If the software/system is still usable to me, I keep on using it (I'm still running my trusty old Atari in the studio for average MIDI sequencing). If I need to get a more powerful machine and/or the software will only be supported on this new machine -- what is this any different to todays Windows/Office situation?
With each new Windows the user interface changes (think of 3.11->95; XP anyone?), new data formats which are not backward compatible are introduced (.doc), and all they ensure is that you can load your old documents and please, please use the new formats as quickly as possible to make a lot of people buy the latest release...
If your Linux application breaks because it requires some stoneage whatever library, then just install it. For instance, people are used to carry a shitload of same-but-of-different-version DLLs on Windows systems and don't seem to object it.
With wide acceptance of RPMs we also accepted the breaks-if-lib-version-of-the-day-is-not-present kind of behavior... (The next logial step would be including required libraries in the RPMs just as every Windows program will come with all required DLLs.)
Well, this was fun to read. This article is about as educated about the subject as the average donkey.
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.
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.
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.
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.
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.
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.
you're placing the blame on linux. Windows doesn't create drivers for that fancy new camera you bought, the camera company does. Is the problem really linux, or is is the companies that don't release the drivers?
I think linux gets the blame, but you wouldn't expect microsoft to write drivers for your camera.
Case in point, I bought a HP scanner/copier/printer about a week ago, and it took about 2 hours of constant reboots, driver conflict errors, and other problems to get it to work correctly. The end result had me download almost 400MB worth of drivers from hp.com, uninstall the printer, and reinstall it with the new drivers. The drivers on the cd were bad. That's not an "everything works" scenario. Yeah, and that's with WindowsXPhome on a HP workstation connected to the printer with usb. A problem like that is NEVER a windows problem, it's always a problem with the device. If I were using linux, it would be linux's problem, and not the device.
Why read the article when I can just make up a snap judgement?
I thought it was all about the spoon and that there is no spoon...
Now I'm cornfused!
Kenny P.
Visualize Whirled P.'s
Knowing the Kernel developing community as I do, the threat of forking would result in a movement to unite in some way. Even if a fork occurrd, the population would essentially choose one and ignore the other leaving it to die.
The fact that patches exist, large or small, is what keeps the main kernel working. So for special implementations, patched kernels exist and everyone is cool with that. I have yet to see a patch that isn't from the main kernel and I don't forsee a situation necessitating that it not be.
I think we should look into the motivation of this article that cites no specific information or sources. It's pure speculation.
....But fail to realize that the spoon is like MS windows without competition... grows fat, bloated and contains the manifestation of the user frustration function so as to make people need to upgrade the spoon....and plug up holes in it...
Forking is a better evolution process as forking is only part the the process. The other part is re-integration of new and wonderful things resulting from forking..
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.
... not even the summary!
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
Because some people are overzaelous in their free software speeches to the masses. Linux users have a bad rep for a few bad elements.
Everyone should use what they want to use (at home at least). You like MacOS? Be my guest. Windows? Go right ahead. Linux? Hell yeah! People should be encouraged to try and use open source software, not forced. If people don't have the time to learn new things, let them use whatever they want.
Please, end-users, stop having this elitist feeling because you're running linux. If apps and distros want to dumb down their applications to increase the amount of users, let them. A good example is perhaps lprng versus cups. Cups is easy to setup and use, lprng is not that easy to setup and use. If normal users can setup their printservers using an easy tool, and power users can set it up with their favourite tool, who is going to complain? It's a matter of choice.
As soon as we make linux distributions easy enough for Joe Common to use, and decide that Random J. Hacker can't do things the way he wants to do them then we're in trouble. Then it's no longer a matter of choice, but a matter of locking in people to solutions that only work in 80% of all cases.
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
Apparently the author is entirely unfamiliar with the concept of creating a branch to isolate disruptive changes to a system.
Odd numbered kernels do not get released, only even numbered ones. The scheme in Linux development is odd = unstable, even = stable.
I won't be suprised to see something from OSDL calling this article a piece of crap by tomorrow.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Forking the kernel is a normal part of the development process. It's happened numerous times before, and it's the usual way of making significant leaps in functionality.
These guys are making it out like some majorly new thing's going to happen that's going to change everything. Did everyone suddenly forget about how 2.4 forked to 2.5 which became 2.6? Give me a break.
I agree. I recently installed Windows on an old laptop that I have. The laptop is old and slow so I installed Windows 98 on the machine. (Son needs it for writing papers in Word). The machine has a NetLux pcmcia ethernet card. Under Linux the network card worked out of the box, under windows it needs a driver disk. The driver disk doesn't exist anymore and neither does NetLux. So, no driver and not ethernet.
I am not a script!
Facts do not cease to exist because they are ignored. - Aldous Huxley
It's better to break binary drivers early than to
break them late.
If all 2.6.x. kernels supported a driver, you'd just
accept that driver... until the 2.8.0 kernel comes
out. Then what? The vendor doesn't care; they got
their money. They either want to sell you new
hardware, or they've gone out of business. So you'd
then expect Linus to add some serious bloat for
supporting a driver ABI translation layer to let you
run ancient drivers on modern kernels.
Then what if you upgrade to a 64-bit processor?
You want Linux to emulate the old stuff????
That's what made Windows 95 so lovely.
The way Linus does things, you and these corporations
can't ever forget that binary drivers are 2nd-class.
I've seen a lot of the flaws in the article pointed out, but I'd like to note this too:
"Top contributors to the Linux kernel have been Red Hat and SuSE, he said. Also contributing have been IBM, SGI, HP, and Intel."
Usually, when talking about the Kernel, it's valid to at least note some individuals, such as, say, Linus.
so if application I write took advantage of the say GDI bug in Windows, but my app was dependent on that bug being present, MS shouldn't fix the bug??
You see there's a flaw in your logic.
Not fixing a bug to allow some bad code that uses said bug to run is just plain ignorant.
"why don't you just slip into something more comfortable...like a coma!"
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]
I'm only really replying to give your comment a bit more weight -- that writer is as dense as lead.
I'm not sure he's ever actually followed kernel development before.
For all those wanting to know whats going on without reading the linux-kernel mailing list, just run over to Kernel Traffic -- a summary of the week's happenings on the list.
- Michael T. Babcock (Yes, I blog)
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
that the use of the pronoun "he" in the article in reference to Kim Polese's remarks was wrong - Kim is (very) female.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
I am not trolling nor do I disagree with the majority of your post. I am however a bit curious about this statement:
"It pisses me off that I can no longer use my webcam because the driver maintainer can't keep up with every variation of the kernel..."
Since this is a webcam I am making an assumption that this is more of a personal/desktop/workstation type role. With that in mind, is there any compelling reason that you must upgrade to the latest greatest kernel as opposed to sticking with a previous kernel that has worked along with your "webcam" driver that worked as well?
I am under the assumption that there are a lot of users that upgrade/acquire the latest greatest software and that in and of itself is not a bad thing but not always the smart thing. I'm referring to a "if it ain't broke, don't fix it" line of thinking.
Can you or someone else inform me what the other part of this issue is I seem to completely miss?
BSD is designed. Linux is grown. C++ libs
What you're referring to is a stable ABI, not API. A stable, locked-down binary interface.
Yes your right, my mistake.
strong bias toward requiring people and organizations to release their software in source form
And this is the childishness of Linux. My Linux system has a nvidia tnt2 card because thats what I had around when I put the system together. Now I have 2 choices of drivers, nvidias official one, or the barely works nv in X. Now if I felt like being a childish zealot, the nv driver would be a no brainer, however I like to use what works best, and thats the nvidia binary driver. Anywhere else, this is fine, but not with Linux because Linus and others have decided that I shouldn't use the best choice for my card, I should either use an inferior solution (nv), or bought another card, also an inferior solution (spent money I didn't have on an open card that doesn't exist). They seem to go out of there way to break every binary driver they can with every release without even considering that the open source alternatives range from almost alright to compleatly useless. Linux can be a little hobby or an actual, usefull OS product and at the moment the kernel dev's have gone with acting like children and developing Linux like a little hobby.
"I use a Mac because I'm just better than you are."
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.
Under Fedora (on the other hand), the NTFS driver (fully open, and PART OF the kernel) is not a default-included module (Fedora is not alone in this distinction) - so the module must be rebuilt (or wait for a new RPM, and download that). It's not the fault of 'Linux', per se, but the kernel developers could elliviate this problem by better structure versioning within the drivers - let the driver itself determine if the kernel is close enough.
On my RHEL 3.0/Oracle 9i server, you are certainly right - RedHat does a great job back-porting all 'patches' into the same build-number code base as the original release. This server was also purchased with RedHat in mind, and I had the freedom at the time to make sure that everything would be fully supported by the default 2.4 RedHat Enterprise kernel.
Finally, as a working manager - I'm happy when users can answer their own questions. On the other hand, I get a lot of technical respect from those who work with-me, and the requisite questions that go with that. It's too bad you don't have managers deserving of respect where you work.
In IT it's part of my job to know what is available, and how it works. I take that part of my job seriously.
Kinetic stupidity has a new brand leader: Allen Zadr.
Groklaw clears this mess up. Turns out someone doesn't understand the word "fork."