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
...someone really overused "said" in that article? It got really annoying from the middle of the article.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
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
You can get this today, with the possible exception of your "one big option menu." A big menu with all options doesn't even exist in XP, since the control panel does not control everything.
What you don't explain to my satisfaction is what accepting large patch sets into the Linux kernel has to do with easy Linux configuration.
Changes to the Linux kernel rarely require the user, or even the sysadmin, to learn anything.
I want my Cowboyneal
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/
as the author potrays it or greatest strength? (as id like to think) isnt the freedom (as in no constraints, ) to fork inherently a plus of open source? p.s. i hope 'fork' means what i think it means. :)
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.
It's open source. If someone wants to fork the kernel and maintain it, they can. If they maintain their fork in a way that pleases a set of end users, it will succeed. If it doesn't, it will just be another alternate patch branch like Alan Cox (used to?) produces.
Diversity is good. Nothing to be up in arms about at all.
Cheers,
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.
"Each version of the kernel requires applications to be compiled specifically for it. "
I'm sorry but that's utter bullshite[sic]. I've never had to recompile applications because I upgraded the kernel...... have you?
--buddy
Isn't a fork a little drastic just to get alsa working agian?
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!
Actually, you can get the "one big option menu" in SuSE's YaST. I've recently had experience installing that in a lab setting, and it was fairly mindless to install/set up (do you want to format? Yes. Do you want to install? Yep. *hour later* Okay, we're done, here's a big menu that configures everything from now on.)
I personally wouldn't run it (prefer the hands-on touch of Slackware on my own machines), but for use in a lab or for a new user it's quite nice.
A 2.7 kernel fork is something that is expected to happen and is natural for Linux.
Oh, no!!
We don't want to happen with 2.6 what happenned with 2.0 and 2.4 with the 2.1 and 2.5 kernel forks!!
Now for any Windows people that don't have much of a clue about how Linux works, here it goes:
You can tell what kernel you need to use by it's numbering sceme. It goes like this:
Linux X.X.XX
The first X is the current generation of kernels. The current generation is 2.
The second X is a series number. Even numbers indicate a "stable" kernel. Odd numbers indicate a "developement" kernel.
2.1 2.3 2.5 were all developement versions with lots of changes thru their lifetime.
2.0 2.2 2.4 2.6 are stable kernels and they are mostly static except for performance tweaks, bug fixes, and driver support.
2.7 kernel will be the new development kernel. By forking it the kernel developers would indicate that they have a idea of what they want from 2.8, are willing to start another stage of radical/fast developement, and considure 2.6 series kernel to mostly unchanging from here on out.
The fork would be a good thing.
The last XX's indicate a revision of that series of kernel and do not indicate anything beyond that.
2.6.9 is the later version of 2.6 compared to 2.6.2, that's all.
Of-course ... Windoz is much to difficult to use.
as a person stuck with XP because I just don't have time to know everything about Linux to install it and keep it running
/etc with some relevant word. In Windows, I have to Google for much longer until I find the correct checkbox in some obscure sub-menu of one of the numerous control panels.
Do you feel that with XP, you just install it and that's it?
Even though I'm quite experienced with Windows systems and with XP, it seems to always need at least about a day of clicking around to get something usable out of it. In fact, when setting up XP for clients, I do bill about a day to set up all the needed applications and do all the required configuration.
I'm not saying Desktop Linux systems are any better. I don't know, I only use Linux on servers, and have no real experience with desktop Linux systems.
For servers, I do feel them to be much easier to set up and configure than Windows servers. If I forget where some option is, I just grep the files in
erm.. when did you last try installing linux, and which distro did you use?
I've never tried, but I've been looking into it lately. It doesn't appear to be straight forward enough yet. Maybe I need to put a weekend asside to do it...
I don't like Microsoft's money grubbing attitudes towards users. I don't like the fact that an OS is going to run me $300 CAD.
Really, if you want "easy to install and get running" give something like ubuntu or fedora a try. You might be pleasantly surprised.
Thanks for the input. I'll look into both of these.
Why is it that every Windows XP user thinks the goal of the Linux community is to convince windows user to make the switch?
Try looking at all the other replies to GPs post, and you have your answer right there.
ooh, fork you!
We still haven't had Linux 4.3/Reno
Do daemons dream of electric sleep()?
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
Do you feel that with XP, you just install it and that's it?
Pretty much. There's also the fact I'm familiar with XP and the Windows way of doing things. I don't like most of the features with XP, and the ones I like could be more intuative.
In fact, when setting up XP for clients, I do bill about a day to set up all the needed applications and do all the required configuration.
I know a guy that does all my setup for me. $20-30 flat no matter what the problem. It's pretty cool actually to just drop my tower off and pick it up with everything done.
Maybe I should have them set up a copy of Linux for me!
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.
or is that article completely incoherent? It doesn't seem to match what Andrew Morton said.
As far I as understand, Xorg was a fork too right? I haven't seen anybody complaining lately.
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.
As many of you might have noticed I started a thread on LKML a couple of weeks ago(My thoughts on the "new development model"), so I am really hoping such a fork will happen. :)
Folks...don't freak!
All that's going on is that the 2.7 development kernel is going to be starting. This is the kernel that is going to be the future 2.8 kernel.
This IS NOT a fork like "I'm going to take my ball and play elsewhere and fork the project." This is "OK, there's a compelling reason to fork off a development kernel, let's do it."
Breathe, folks. Breathe.
Knowledge is power. Knowledge shared is power multiplied.
"In a worrying parallel to the issue that stopped Unix becoming a mass-market product in the 1980s - leaving the field clear for Microsoft."
As long as everything stays open source, this won't be a problem. When you get an application now it is likely as a binary for a particular distro. I don't see that changing. You will still run urpmi or apt-get and for most people, things won't change. Really, how would forking create a different situation than we currently have with Gnome/KPI?
Unix in the 80's was not open source and that makes all the difference.
...
...
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)
No, it's not it. I understand what he is telling. Although i'm mostly a window user, i've built LFS a couple times, and played with slackware and gentoo for a long time.
We all know distributions are very "smart" detecting hardware and auto-configuring the system. But it's far from what windows provides for the end user.
Take Knoppix for example... Run it in your computer today and it detects everything. Buy a new PCI card that doesn't have it's drivers already compiled on the CD and you are screwed. You have 2 choices: Try to understand how modules and kernel works and how to recompile and load them by hand or wait until the next version of knoppix that MAYBE has the new drivers.
Linux still has this problem: Download Mandrake and never step in the grass, follow all the instructions so you never hurt yourself, or take a full month of FAQs and a great tour at TLDP to understand how to make that sweet little camera you bought work with your distribution that doesn't come with gphoto precompiled.
Same problem for Apps. Wait until your distribution provide a precompiled package or learn to compile things (what is very frustrating for those who doesn't even know how a programing language works).
I know distributions like Gentoo or even Knoppix are doing a great job, but it's not what most "windows power users" want. They can learn how to compile stuff and make it work.
But when all you want is listen to music or see a movie and you discover that your version of "XXX" wasn't compiled with "--with-lib-yyy" and you must manually recompile the thing just because your distribution doesn't support "lib-yyy" by default... Well, you must agree that "download big codec pack -> click click click -> everything works" is a much better option.
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.
I don't think that's what it is. I think it's saying that they'll fork off versions for really big patchsets they don't want to merge into the main kernel. So there may be 2.6-hard-realtime, 2.6-reiserfs-v4, 2.6-ip-v9, etc. trees. Which is something to be concerned about, although not necessarily a bad thing.
I am trolling
Use GNU Mach and SFTU.
I put things where I want them, If I wanted things spread all over the filesystem I'm quite capable of doing that myself without RedHat and co standardizing it for me!
+5 do your own tech support from now on
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.
I really can't believe that even on slashdot people are posting about this subject who have not even the remotest unstanding about Linux (the kernel, which its name is) and its process.
I wouldn't even be brave enough to say something in a discussion, let alone an open board, if I didn't know enough about the topic (which I happen to know about pretty bad).
If you don't know exactly what you're talking about - wait and read (other comments e.g.)
And please don't get me started on the media and their Linux reporting.
"We have sufficient faith in the legal system because we're expecting it all to fall over because it has no basis"
Because, because, because, because, BECAUSE... because of the wonderful things he does.... we're off the to see the wizard...
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.
Er... because you call it Winblows?
....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..
In other news, the Linux Kernel will also "spawn" and "exec". Linus confirmed that the community will not have it any other way, so he *had* to do it.
This is not my sig.
It takes you a day?
It's never taken me more than 2 hours to fully configure an XP box, including whatever software and hardware people want.
I put it to you that you are ripping your clients off, down to either your incompetence or just greed.
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
All this is saying is that 2.7 is about to open.
"Fork" is not a dirty word.
Propbably, and this maybe all what Andrew Morton wanted to say. But obviously the writer absolutely did not get it, since he starts with:
"Linux could be about to fork. In a worrying parallel to the issue that stopped Unix becoming a mass-market product in the 1980s - leaving the field clear for Microsoft - a recent open source conference saw a leading Linux kernel developer predict that there could soon be two versions of the Linux kernel."
Obviously, the concept of a "development branch" and a "stable branch" is completely unknown to him.
Every development version (X.odd number) is basically a fork isn't it? I mean, this has been happening since the beginning. How is this news?
There is also a lot of different development forks (source trees if you will but they are basically forks) of the stable kernel. You can install the Gentoo sources, Redhat sources, mm sources, love sources, mosix sources,xbox sources, etc and so on.
I'm not understanding about how some people want to maintain their own kernel source tree is a big deal.
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.
i agree. it took me a while to figure out that they're just talking about splitting off the development branch (not fork, really) off the stable kernel.
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
That future is now - go try this. If you never used linux before, better try this first.
While you're at it, notice how many user-level apps come on the system CDs, and don't require a separate installation, which saves much time when you're setting up a usable system.
Why? XP has many apps that don't run, or run poorly, on linux. You can't expect every application developer to port their code to every OS out there, and many end up only supporting Windows. And many others only support UNIX variants. Set up a dual-boot system and use whatever OS better fits your needs for the moment.
Well sure I build things from source all the time (via make/make install), and sure their dependencies aren't backwards compatible. I often have several versions of many libraries installed at once (which is something that should almost never have to be done).
What I am saying is yes, give everyone a chance to wipe out all the mistakes of old and move on, but from that point on, to keep compatibility. When you release a library you are making a promise that any future version of the library will offer the same functionality. New functionality is just that-- new. Bug fixes? Well you shouldn't have released it yet. People may now use the bugs to serve another purpose and you can't go "fixing" them, as you are now breaking your software.
I'm not blaming anyone here, just exposing a fact. Don't get me wrong...
Microsoft doesn't need to make drivers for every hardware because they make it very easy for the manufacturers create and distribute them... API compatibility, standard library base. Some weeks ago I could make a video card work in Windows 2000 with win98 drivers. If i'm using linux 2.6.5 and switch to 2.6.8, many things stop working.
Many manufacturers doesn't make drivers for linux because it's hard to distribute, hard to mantain... or you release the source code or you have to compile one version of your driver for every version of the kernel * every kind of distribution.
Didn't say it's perfect. I said it's a better way to solve things for most user. Believe, most users will prefer to download 400Mb or to wait 1 weeks for a CD (you can call HP and ask for them) than downloading 4 or 5
Don't take critics as offense. Instead, try to understand why people complain about it and try to make it better. Apps like Gnome/KDE didn't get where they are by ignoring what users want...
I have little personal experience with YaST, but I doubt it can configure everything. For example, can it adjust swappiness? I'm not claiming it should, but it isn't "one big option menu" which controls everything if there are things you can't control with it.
If we're talking about one pretty comprehensive option menu, like the Windows collection of control panels, than many distros qualify.
I want my Cowboyneal
Don't get too happy. A lot of problems are solved, but there is a HUGE problem in the form of installing software.
Currently they are 4 'methods':
Compile from source
RPM/DEB
apt-get/yum
Custom installer
Compile from source is not going to work. Takes too long, requires too much knowledge, requires lots of source already on the system.
RPM/Deb is useless for anything but the most simple tasks, because of dependancy hell.
apt-get/yum is good, infact it's the closest we have at the moment. However, it's has 3 huge downsides:
1) it requires a central server that can go down, hacked, go offline due to financial issues, whatever.
2) it requires the central server organization to test and ensure the packages work, which really should be the packagers job. This results in it being slow, and can take weeks before new versions of software come onto the apt server.
3) Some packages due to their legal status cannot be hosted. Also, for commercial software it would require each company to host their own apt server as most distro's would not want to bear the costs of distrubuting their software.
IntechHosting - Free domain, 2GB, PHP, £4.95/$8.95
Maybe I should have them set up a copy of Linux for me!
Well yes. It does sound pretty ridiculous that you say first that you have no problem setting up XP and then one paragraph (maybe 5 seconds) later you admit that you get someone else to do it for you.
I gotta call bullshit here. I mean, I'm not saying that you're lying, just that this sounds like total bullshit to me since my experience has been the exact opposite. I have really never had a dependency problem in Linux. Ever. I keep getting them, over and over again, in Windows.
I'm the same way with drivers. I cannot get hardware to work in Windows. Take my girlfriend's computer: I've put in 3 different ethernet cards (a 3com, a SBC, and a Linksys) and Windows can't load the driver for any of them. I've reinstalled windows, and the installer can't find the driver for any of the ethernet cards. They will show up in the device manager with a question mark on top of them and refuses to locate a driver for them. The same computer, I boot with Knoppix and finds the ethernet cards fine.
Now, tons of people have the opposite problem apparently, but I've really never had problems with Linux hardware and I've always had problems with Windows hardware.
All's true that is mistrusted
It doesn't make any sense and the author clearly has no idea what a fork/branch/patchset is, or has explained it very badly.
Also, it would be a good thing if Linux had branches or at least config sets that target it at the different areas is exists in (e.g. the kernel config already has a section for removing things not needed by embedded kernels).
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net
"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."
The stability of the 2.6 kernel has thus far been terrible. I mean, really just horrible. Major bugs are introduced on a regular basis because the maintainers made the decision to leave testing up to the distros. Except for Debian, none of them are good at testing kernels, and as a result major bugs get shipped.
2.4 is obsolete, but 2.6 is unstable.
What do you expect people to think if they have a distro that's supposed to be easy to use, and you tell them "Oh, that version of the kernel has a bug, you can't burn CD's. Just download and compile the new one, it's easy.". It's been almost as bad as Windows.
I rarely criticize things I don't care about.
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.
Pinky: Developers want to implement backwards incompatible features into the stable kernel. What are we gonna do, Brain?
Brain: The same thing we always do, Pinky. We re going to take over the world with a new fork.
The article alludes to the historical fragmentation of the unix market back in the eighties, paving the way for windows to rule the small computer, and compares that to the emergence of 2.7... I don't understand. 2.1 branched from 2.0, 2.3 from 2.2, 2.5 from 2.4.. do we see a pattern here? Did the 'journalist' just miss the nuance in difference between a devel tree branching and a code system forking? I dunno. mountains. molehills. More stuff that will have to be explained the next time I propose a linux platform for a client problem. It's a drag man.
Too late. For example, Where have all my preferences gone?.
Or check out the open dialog used for importing bookmarks into the latest Mozilla.
Gnome2 is the epitome of this question, not necessarily in look/feel, but in abstracting things away, burying preferences in themes, oversimplifying, and removing options.
--
If R is the set of all sets which don't contain themselves, does R contain itself?
but how is this any different from when 2.4 forked off of the 2.3 dev tree, or when 2.2 forked off of it's dev tree, or when 2.6 forked off the 2.5 tree The way I see it is that they are forking 2.7 off the 2.6 tree possibly feature freezing 2.6 to allow new developments on the 2.7 tree hereby creating another "development" kernel.
The BSDs will all run Linux binaries too, as well as SCO UNIX and soon Solaris.
The important thing is stability (in the doesn't crash sense, in the no new major bugs in the main branch sense, and the changes slowly enough for people to maintain software for it sense (this applies to kernelspace stuff, not userspace stuff)), and Linux is currently bad at that because of the poor decisions made my the development team.
The distros are not up to the task of stabalizing the kernels they use.
I rarely criticize things I don't care about.
Just a tip : you should use Checkinstall. That being said, I never really understood the people that insist on compiling stuff themselve. Unless you are using Gentoo (ha ha Gentoo), most distribution today come with a plethora of packages, and there are plenty of third-party repositories for packages that are not included in the default install; for Fedora, check Livna, Freshrpms, DAG, NewRPMs and a few others. Is it because you enjoy watching compiler output scroll by ?
That is why library are versionned in Linux. Did you ever wondered what all these softlinks in /usr/lib where for ?
:wq
Windows will let you create dependency problems that will allow whatever software package you have just installed to work correctly, while breaking other things.
Can anyone give a suggestion for the distro with the most user-friendly package management? I've worked with UNIX since the late 80's and am far more interested in using Linux as a tool to do other interesting things than having to spend time making things work.
Of course he's going to fork off 2.7, whats the problem? The dev kernels have odd numbers and the stable ones even numbers... so yeah 2.7 is forked off for all the changes, while 2.6.x stay ABI stable... then later on 2.7 is stabilised into 2.8... what is the problem here, these people don't even research their articles, rediculous!
VMWare and just about anything that requires a kernal module does have to be recompiled, even if it is just the kernel modual parts, for every kernel release. So sorry, but yes the reporter is correct for somethings, but the ery broad statement is a little misleading.
"I use a Mac because I'm just better than you are."
QUOTE= "New functionality is just that-- new. Bug fixes? Well you shouldn't have released it yet. People may now use the bugs to serve another purpose and you can't go "fixing" them, as you are now breaking your software."
That has to be dumbest thing I have read all morning.
"why don't you just slip into something more comfortable...like a coma!"
Or at the very least a stable ABI for drivers. Sheesh.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
This article is contentless hyperbole
Kernel modules are part of the kernel, hence they have the word "kernel" in the name. Having to recompile kernel modules for VMWare does not in any way back up a claim that applications have to be recompiled for a kernel upgrade.
0 1 - just my two bits
Facts do not cease to exist because they are ignored. - Aldous Huxley
We already have nitro sources. Earlier we had love-sources. There will always be some fork that will patch the kernel to hell and some people will use for some reason or the other. But, many will stay away because, they prefer to use a mainstream kernel which is likely to be more stable and for which support is readily available.
Well if it isn't intrinsically obvious to you then there's no way I can convince you. I will try anyway.
When you release a standard of some sort you are promising a certain output for a certain input. Consider you are writing an ISA. You bungle up the instruction to exit from superuser mode. Heck you forget it entirely. However, there is a bug with a trap which if used from superuser mode returns you to regular user mode.
Now you are releasing your first update (which could easily be several months or over a year later). Do you (A) "fix" the bug in the trap and add an instruction to exit from super user mode, breaking every program written (and every compiler), or (B) fix/add an instruction to exit from super user mode, but keep the bug to maintain backwards compatibility. The answer is (B), because if you do (A), you significantly lower the confidence in your standard and companies/projects will shy towards another one. What other "bug" might surface in the future which you'll treat the same way?
Now in a system that isn't used as a library is, sure you don't have any responsibilities. Please realize I find your comment very silly and lacks thought.
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.
...is that they often incur some semi-useful packages, which cause a cascade. As in your example, nethack (or its documentation, logging which goes to a database or some other minor thing) is using the GTK toolkit, which causes it and every subdependency of it to install.
Usually, if you try to have a "lean" machine, you get two of these, GDK & Qt (or their respective WMs, Gnome and KDE). End result? Whether you like it or not, you basicly have most of Linux installed. Fun, yes?
Kjella
Live today, because you never know what tomorrow brings
Come on, guys. Go enjoy your Sunday instead of posting overblown non-issues like this...
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!"
If they are sticking a fork in it, is it done?
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]
People compile things themselves for all kinds of reasons, I tell users to compile from CVS if they encounter a bug in between releases. I compile almost everything myself, there's no reason not too and I configure/link only options/libs that I will use. I never seem to encounter dependancy problems, aside from library versioning, these can only be because people are trying to link against libraries that were installed via package management and they lack the required header files. Who do you think would compile these non standard RPM's you mention if nobody is supposed to compile their own software? Do you really trust a third party to compile your software for you? I'm surprised nobody set up a RPM site that bundles spyware with every binary! And yes, I do enjoy watching compiler output scroll by but I have an automated build machine spitting out CVS builds of a few projects for a development box at work.
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)
Here is a symptom. Program Y never works unless you first do X. Clear indication that X loads the proper dll and Y does not.
It also explains why you sometimes need to reboot to get a program to behave. Because you had a bad dll loaded. It is also a reason Tech Support always ask you to reboot. It cleans the system.
I helped far to many people who had this happen to them. They installed some old proggie from the net wich replaced a dll and BOOOM.
Your evidence seems to be outweighed by the amazing amount of work computer shops and relatives with a clue get fixing broken windows installations.
Exactly why do you tbink MS has introduced rollback and system files protection?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Oh, not trying to fight with ya on it. I agree as many bugs as possible shoudl be fixed prior to release, but to leave a bug in place for a third party app just doesn't make sense.
Then again it really depends on the severity of the bug.
risk vs. reward
"why don't you just slip into something more comfortable...like a coma!"
I know you're being vague on purpose. Now remember this bug is new functionality or else you already broke your promise as a library, and yes it should be fixed.
Now, given that this bug is in new unpreviously used code, so all code written around this functionality has taken the bug into consideration, it should not be fixed. Say the function "SetPixel()" or whatever had a bug. Let's say if you used it with an negative X location it took the int(x) pixel and inverted it instead of throwing an exception (or whatever). OR maybe if you run off the end of the screen it throws an exception when instead it should return an error value. It really doesn't matter. Maintain that functionality in that procedure, and add a (Gee, I dunno) "SetPixel2()" which fixes this problem.
An alternative to this is to write your library intelligently to begin with such that when you are compiling with it, it knows what version of its functions to use in the first place.
"This is, for example, why amaroK depends on such things as taglib - because there was no point in writing their own tag editing library when there was one already written they could use."
;) )
I was not aware that Linux had this install mechanism. It makes sense though, its kinda like CVS compiling one time where I had to get some code from this other project's tree since they used code from it. ( The first and currently the last compile I did
So these libraries are like DLLs in that they are required to make the program run? What was this recompiling stuff I heard?
Linux has already forked a bit with the embedded linux versions wich are designed to run on hardware without proper memory management. They probably added all sorts of code that will never make it back into the main linux because it ain't needed. Similar any enhancements made to the main linux related to memory management will not be taken up by the mobile versions. The closest I can think of as a fork.
As long as the PC linux continues to be done by the same people with the same end goal there is no fork.
Has this guy never heard of software development cycles? I never worked on a piece of software that did not have multiple versions. Development testing production.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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
Firstly, don't exaggerate, there is a reason you've been marked flamebait.
There is very little from a technical perspective stopping deltas being used to distribute updates. The #1 point is that mirros do not want to install new software, and the closest we have to no new software is a single extra apache module that automates the delta generation. However, that module is unmaintained and slowly suffering from bitrot. If you feel like doing something helpful, you could try bringing it up to date and getting it into a standard apache install.
However, the grandparent was discussing the problem that rpm has in handling dependencies. A problem that has since been resolved by apt years ago and later by both urpmi and yum. Your insight that upgrades require a lot of downloading is a red-herring in terms of dependency resolution. But, if it is something that bothers you then I'd be happy to work with you towards a solution.
One of the nice things about linux is that it just freaking works with no bs.
OMFG I am so sick of people saying this or that OS just works.
Windows does not just work. I installed Win2K on a laptop that was made in about 1998 and I still had to go and search down the approprate drivers because windows didn't include them even though the OS was released years after the laptop was manufactured.
Macs do not just work. I had to set up a couple G4's to be able to print to the networked printers at work and it was a nightmare that took hours to set up properly.
Linux does not just work. I installed SuSE Linux 9.1 on my computer and it would only recognize about half the USB devices that I plugged into it. After much frustration and failed attempts to get it to work I installed the latest version of RedHat only to find that it could see the USB devices that SuSE couldn't see but it couldn't see the USB devices that SuSE could see!!
Fuck all your operating systems!
Depending who your users are, I don't think your render them a service. Compiling is time-consuming and error-prone, not the kind of thing I am expecting a newbie to do.
It's fine if you have a lot spare time. I don't, unfortunately. Hopefully, all the software you install by hand have a nice make uninstall target, you keep a log of what you do to roll-back change when necessary.
Hopefully, you use a source-based distro such a Gentoo. I would not want administer the mess that would be a system half package-based, half-compiled by hand.
Not me, that's my entire point. Compiling is tedious, boring and time-consuming. Some people volunteered to do it in my place. Who am I to refuse the favor ?
Certainly could happen. That is why you configure only software repositories from reputable source and have your package manager validate GPG signature of packages (mine does by default). In practice, this is no more a problem than building trojaned source, for example.
Whatever float your boat.
:wq
I agree with you on all counts. Novell's acquisition of Ximian and SUSE should also help continue making package installation on linux easy and manageable. Of course the /. posting of the Computerworld article insinuated that Chris Stone single-handedly championed open source software, when the actual article suggested he only favored a certain approach, Etyenne. ;->
Ignore the fact that it is RM 101 who works at MS and is simply a MS stooge. To state that Linux has dependancy problems is like saying that ALL WATER WILL KILL YOU. Yes, enough water will kill, but too little will as well.
Plain and simple, all Linux handle updates in different fashions. Some are still using .tgz/compile/install. Others use RPM's which will have to deal with the issues (most of these problems are when doing binary installs). Debian introduced their approach(apt-get) to installing which solved all the library issues. This was something like 4 years ago. since then, other distros have also adapted shades of this.
BTW, there is a reason why this problem is called DLL-HELL. And it is not Unix, Linux, BSD, Mac, Mainframes, Super computers, micro computers, etc. that call it DLLs. It is just MS.
Am I misinformed, or is it not the case that if a kernel is changed to the point where executables from the previous version are no longer compatible it will get a major number? I was under the impression that when a change that disruptive was applied, we would be moving to Linux kernel version 3.0.
My hypothesis is that the author of this article has little to no knowledge of the kernel development process. Fortunately, other responses in this forum have tended to confirm this.
I for one will be glad to see a 2.7 fork, as when I was reading through the changelogs for the 2.9 kernel prereleases, I was amazed to find so many large patches and major bug fixes. I was almost surprised that when I started using it it ran so smoothly. Although I like having new features available, and indeed use many early on, I would like to have a choice between the newest features as opposed to only the newest bug fixes and patches.
I liked that Linus stuck with 2.6 for a while, but after about 2.6.7 it was time to start putting new features into a 2.7 fork, if indeed fork is even the correct term.
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
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.
The "clustering" feature that's in demand isn't Beowulf clustering. That's for distributed computability, and isn't applicable in most enterprises.
What enterprise uses demand is high availabiliy clustering. Sure there are userspace clustering implementations now, but truly advanced HA clustering offers things like shared filesystems which can be fairly invasive in the kernel.
Patching the kernel is not an option for enterprise users.
Yes, the GPL absolutely grants them the rights to do so, but distributions will not support homebrew kernels, not matter how small the change. There would be no QA testing on such patches, and support isn't the same as being an auxiliary development staff.
Now, since enterprise kernel feature lists are driven by user demand, once there is a stable implementation, it will likely be included in vendor kernels. Multiple distributions maintaining the same patch sets isn't a situation anyone likes, and at that point it may be considered for mainline.
I've never seen much of a dependency problem with debian/unstable, which I have been running continuously since 2000. About the worst thing along that line I have seen is the dist-upgrade uninstall problem - with a "apt-get dist-upgrade", apt can sometimes decide to uninstall packages. It becomes an issue when an upgrade of a major package or group of packages (say KDE) introduces a dependency on a newer version of a library than is currently available. When this happens, all of the dependent packages get removed. They generally can be reinstalled, with no harm done, within a few days when the required lib is updated.
The bottom line is not to use dist-upgrade on Sid (or testing, for that matter) without carefully assessing what is going to happen before you go ahead.
Forget the spoon.
Forget the fork.
It's all about the spork!
But not officially. We have Fedora's kernel, SuSE's, and Mandrake specific patches, etc.
I think it would be interesting if Linux became gnu/linux and actual linux distributions that include more than the kernel similiar to the BSD's.
I like the fact there are 3 different BSD's that are fully integrated and work as a whole system and include more than just the kernel.
This is why I do not call Linux gnu/Linux yet. Its just a kernel and nothing more.
http://saveie6.com/
Probably not going to happen if: /etc/passwd pre-shadow
1) uses setuid and/or treats
2) wants to use largefiles
3) uses threads or waits on child processes.
4) tries to use libtermcap
I can think of a couple other nasties...
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
But what about when the next kernel exploit surfaces? Should he be expected to backport the fix himself?
This post written under Gentoo-linux with an SCO IP license.
Female coders ? Yeah, right ! What next, female doctors ?
First, devices. There are several devices that only run with 2.6.x kernels. Yes, some of these are frivelous (D-Link web cam), some are not (Intel win-modem). This puts me in a position of running Fedora Core 3 on a couple of systems... This doesn't stop me from running stable operating systems on more important systems.
Second, security. Every couple of releases it seems there is a security update involved.
Finally, keeping up. I like to have at least one computer in the office running the bleeding edge. That way if one of the engineering users wants to run a particular version - I can give informed feedback.
Kinetic stupidity has a new brand leader: Allen Zadr.
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.
I'm not going to argue that in a "Perfect Code World" you are 100% right...
But it has to be case by case.
What if SetPixel() has a bug in it that could be exploited? Am I to leave SetPixel() and implement SetPixel2() until third party developers can get their act together and catch up? Or do I fix SetPixel() to remove the offending bug even if it means breaking certain third party apps? Where does one draw that line?
If the bug in SetPixel() can not be utilized in any malicious way I would agree with you. It's better to implement SetPixel2() and allow third party developers time to move their own codebase over to use SetPixel2(). Then one has to ask how long? What is a reasonable amount of time? Bugs are found. You can not escape that. I sure as heck am not going to litter my code with a million different duplicate functions just to keep a few deprecated third party apps running.
Perhaps in the cases where the fix must be done with haste, the third party developers should keep an eye out for notices from the library developer and be aware they need to move to a new version that could be supplied to them before it is released?
Trust me I know what you mean. I've been fighting with this situation the last few days myself (with a newer version of a lib that bugfixed an exploit, but the new version is currently incompatible with an important piece of software I use).
And honestly how many developers want to leave a known bug in their code whether useful to third party developers or not?
"why don't you just slip into something more comfortable...like a coma!"
Groklaw has an article up in response
to this one, including responses from Andrew Morton..
Time travel is possible. We are quickly heading for 1984.
I searched but I didn't find any dll's
.so, and some .a.
.png, which seemed to coorespond to the .jpg's that were also there. But the .png were down in /var/www/html .
.jpg's there.
I found a log of
There were a bunch of
There weren't any
But I didn't find any dll's
Oh, that's right, my Windows boot stoped working so I converted it to a vfat and started using it to store iso images of various Linux distros that I can test boot on my notebook.
It doesn't matter if "the community" supports a Linux fork. If a group of people decide their needs aren't being met by Linus & Co., they are free to start maintaining their own version. That's the "beauty of open source," IMHO.
or be logged in as root. . .
And you will have to explain this to him too.
I just google anything I don't get.
You are so right that yum or apt-get are very easy to use.
The only difficulty I have had is when I didn't check the lastest date on the release of glibc.
I tried an 'sudo yum update' the same hour that a new glibc version was live in the wild.
Things just didn't work until I changed my mirror from the default to a different one.
The way it is the developers get to focus on what they are good at, whether that's the kernel or applications. Integrating everything would make them lose focus and would serve no purpose other than to feed Stallman's ego.
Linux Kernel to spork.
Sorry. I couldn't resist. Spank me, oh baby. Yeah, bad Llama!!! Ouch!
It is a pain in the ass in certain situations.
/etc/inittab doesn't do shit to force
I installed the latest test Debian Sarge.
The install was smooth, the graphic and even
console were horrible. Just to make the pain
bigger grub didn't even provide to load nice fonts
like SuSE, Fedora, Red Flag or Mandrake does.
I could hardly see anything on the X environment
until I fixed the fonts. The default install, you
feel like perhaps braille might have worked better
as a default.
That actually wasn't the most annoying thing.
Changing
a boot on the console. Deleting the offending
gdm script for the boot works but makes it
impossible to load the graphic mode into gnome
while it is possible to load KDE.
The main reason not to use the graphic boot
is that it is an annoying piece of shit. One
other important factor in not wanting it, is
that it has a short memory.
It allows a miximum of 3 tries before denying
a boot on a user. The first time I mistype
and then it booted. The next time I type
correctly but somehow it didn't seem to
recognize either the login or my password.
I was able to boot under root. I changed the
maximum to a large number so I wouldn't be
annoyed anymore. I next rebooted and hoped
that it would either recognize my entries
or at least give me more chances. No go!.
I booted on root, changed the user password.
I was then able to login on that user.
Next time I rebooted I couldn't login anymore.
The funny thing is that I had no problem
login in on the console, once I added the
vga line into grub of course.
I'm sure that once the system is tamed to
behave correctly I would be happy with it.
For anyone to say that installing Debian
will solve problems, that person is either
drunk or on some funny stuff.
Debian is a system for people who don't
like easy linux distributions like slackware,
redhat or SuSE or for pananoid linux users.
If I had the need of a server that needs a
paranoid mode I might decide to use it, otherwise
it serves little to no purpose when there are
better distributions available.
So far I would say that the best distributions
are SuSE and Fedora Core 3. If you use ATI card
though Fedora Core 3 is useless since you can't
use 3D.
Can I get a witness?
Groklaw clears this mess up. Turns out someone doesn't understand the word "fork."
Personally I'm glad that this article was issued.
I have learnt more about the development of the kernel from the posted comments and replies than I would ever have. It is good to see intelligent, informed, and differing feedback. I can evaluate and learn. Thanks.
Did you SEE the M$ ad above the article. What about the one on the left? Did you catch the HUGE mother ad on the right?
Welcome to last decade.
I think that what happened is after hearing Ballmer and Gates say "f*** you, linux!" for years, Linus misunderstood what they'd been saying (accents and the distance from Redmond to Europe, etc.) and decided to take them up on it.
For your security, this post has been encrypted with ROT-13, twice.
Imagine the reliability of a commercialized UNIX operating system (like MacOS X, but likely better), but built upon the commoditized Intel/AMD H/W architecture. And the price is good too.
The fact that Sun makes a point in emphasizing that Solaris 10 guarantees backward binary compatibility will not be lost on hardware manufacturers. They can write their drivers once, and forget about it until Sun announces enhancements to the APIs which the manufacturer may (or may not) want to take advantage.
I honestly don't know exactly what kind of compatibility they'll gurantee at the driver level. But my guess is that Sun knows how to maintain backward-compatible APIs.
where's the story here...
Get your torrents...
Well, that's not true. At least all of the PCs I've seen yet have to be explicitly turned on after plugging them in.
The Tao of math: The numbers you can count are not the real numbers.
This article is about as educated about the subject as the average donkey.
You donkey slanderer!
Nonaggression works!
If you pay them $5 extra, they'll flip and glue the switch for you before shipment.
It shouldn't be possible to apply "overrated" to a comment that doesn't have a positive score. [overrated should also be subject to metamoderation]
We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
Just a thought, I'm probably just spreading FUD now...
Well now that's odd. Looking back at your post history you were an OS X and Slackware guy.
Tell us, how did you lose your memory and end up forced to migrate to XP?