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)
They just got too many weird patches, and had to put them somewhere.
Business as usual.
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.
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.
I second that. After having the nvidia driver broken four times I'm starting to get frustrated.
And, besides, we're approaching the time Linux kernel's typically fork: a few versions into to the series, the developers are starting to feel restricted by what they can't change in a stable kernel.
I just want to know how crap like this makes it to Slashdot. You'd think Taco would know better.
I want my Cowboyneal
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!
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.
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
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
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"
.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).
.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).
.DLL it is calling, first
.exe files for finding DLLs to load -
.exe location folder
.DLL extension, then search order becomes:
.exe file folder.
.exe file directory.
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
This is a 128-bit UNIQUE generated number in the registry that summons the CORRECT build the calling program requires by internally checking the
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
Order of seeks used by Win32 Portable
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.
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/
aa. %SystemRoot%\SYSTEM32.
bb.
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
f. The directories in your Path.
With
That's why a bunch of guys are assembling a new project to embrace as many Linux distributions as possible, adding FreeBSD and Windows to the mix.
Oops! The link: http://elektra.sourceforge.net/
Please, have a look at it. Its perspective is smarter than it seems at a first glance, and very promising as well.
If we want to maintain the quality and stability that the Linux kernel has, we need to resist binary drivers.
Firstly, I agree. BUT if need to allow third party vendors to ship binary drivers (and maybe we do, in the IP crazy world) then a QNX user-space driver model might be smarter?
Forget thrust, drag, lift and weight. Airplanes fly because of money.