login
Search
An interesting thread on the lkml began when Greg KH submitted a patch for the 2.6 kernel saying, "Ok, to test out the new development model, here's a nice patch that simply removes the devfs code." This was quickly followed with a comment by Oliver Neukum who said, "may I point out that 2.6 is supposed to be a _stable_ series?" In one branch of the thread, the usefulness of devfs was examined.
In another thread, discussion was focused on this "new development model". Jonathan Corbet explained that Linus Torvalds and Andrew Morton [interview] were very happy with the results of their recent teamwork, and saw no immediate pressure to fork a 2.7 development branch. On the contrary, they intend to keep at it as they've been, with things first going into Andrew's -mm patchset [story] for testing, then eventually being merged into the mainline 2.6 kernel. Jonathan went on to explain, "Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree." And he summarized:
"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."
Subscribers to LWN.net can find out all about this recent development and more on LWN's 2004 Kernel Summit coverage section.
From: Greg KH [email blocked] To: linux-kernel Subject: [PATCH] delete devfs Date: Wed, 21 Jul 2004 10:15:24 -0400 Hm, seems kernel.org dropped my big patch, so the patch below can be found at: www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/devfs-delete-2.6.... ----- Forwarded message from Greg KH [email blocked] ----- Date: Wed, 21 Jul 2004 02:49:37 -0400 From: Greg KH [email blocked] Subject: [PATCH] delete devfs Ok, to test out the new development model, here's a nice patch that simply removes the devfs code. No commercial distro supports this for 2.6, and both Gentoo and Debian have full udev support for 2.6, so it is not needed there either. Combine this with the fact that Richard has sent me a number of good udev patches to fix up some "emulate devfs with udev" minor issues, I think we can successfully do this now. Andrew, please apply this to your tree and feel free to send it to Linus when you think it should be there. thanks, greg k-h <PATCH SNIPPED> ----- End forwarded message -----
From: Oliver Neukum [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 16:26:55 +0200 Am Mittwoch, 21. Juli 2004 16:15 schrieb Greg KH: > Hm, seems kernel.org dropped my big patch, so the patch below can be > found at: > www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/devfs-delete-2.6.... May I point out that 2.6 is supposed to be a _stable_ series? Regards Oliver
From: Lars Marowsky-Bree [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 16:35:33 +0200 On 2004-07-21T16:26:55, Oliver Neukum [email blocked] said: > > www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/devfs-delete-2.6.... > May I point out that 2.6 is supposed to be a _stable_ series? Yeah, sounds like a good series to drop unsupported code from... ;-) Sincerely, Lars Marowsky-Brée [email blocked] -- High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs, Research and Development | try again. fail again. fail better. SUSE LINUX AG - A Novell company \ -- Samuel Beckett
From: Greg KH [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 10:52:08 -0400 On Wed, Jul 21, 2004 at 04:26:55PM +0200, Oliver Neukum wrote: > Am Mittwoch, 21. Juli 2004 16:15 schrieb Greg KH: > > Hm, seems kernel.org dropped my big patch, so the patch below can be > > found at: > > www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/devfs-delete-2.6.... > > May I point out that 2.6 is supposed to be a _stable_ series? You didn't pay attention to the first sentance that I wrote for the patch :) And as Lars points out, the code is unmaintained, unused, and buggy. All good reasons to rip out it out at any moment in time. thanks, greg k-h
From: Jesse Stockall [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 17:19:42 -0400 On Wed, 2004-07-21 at 10:52, Greg KH wrote: > > And as Lars points out, the code is unmaintained, unused, and buggy. > All good reasons to rip out it out at any moment in time. Unused? Since when does every Linux user use a vendor supplied kernel? I have no use for devfs, never used it in the past, and I'm a happy udev user now, but that doesn't change the fact that there are many devfs users out there. What does this gain us right now? Jesse -- Jesse Stockall [email blocked]
From: Greg KH [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 17:27:52 -0400 On Wed, Jul 21, 2004 at 05:19:42PM -0400, Jesse Stockall wrote: > On Wed, 2004-07-21 at 10:52, Greg KH wrote: > > > > And as Lars points out, the code is unmaintained, unused, and buggy. > > All good reasons to rip out it out at any moment in time. > > Unused? Since when does every Linux user use a vendor supplied kernel? I > have no use for devfs, never used it in the past, and I'm a happy udev > user now, but that doesn't change the fact that there are many devfs > users out there. > > What does this gain us right now? It fixes an obviously broken chunk of code that is not maintained by _anyone_. And it will clean up all device drivers a _lot_ to have this gone, which will benifit everyone in the long run. As for "right now"? Why not? I'm just embracing the new development model of the kernel :) thanks, greg k-h
From: Jesse Stockall [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 17:53:37 -0400 On Wed, 2004-07-21 at 17:27, Greg KH wrote: > > It fixes an obviously broken chunk of code that is not maintained by > _anyone_. And it will clean up all device drivers a _lot_ to have this > gone, which will benifit everyone in the long run. > Agreed, but this 'broken' chunk of code is 'working' for a lot of people (whether or not this is due to pure luck is not the point) > As for "right now"? Why not? I'm just embracing the new development > model of the kernel :) That's the point that Oliver and I raised, the "leave it till 2.7" (not breaking things for real world users) argument seems stronger than the "rip it now" (because it makes things cleaner, easier to code, etc) argument. Devfs should never have made it in the kernel in the first place, but ripping devfs out in the middle of a stable series does not solve any problems, it creates them. Is keeping devfs around for 2.6 really that much or a burden? When was the last time you saw any mails on lkml asking for devfs support? Jesse -- Jesse Stockall [email blocked]
From: Greg KH [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 18:05:29 -0400 On Wed, Jul 21, 2004 at 05:53:37PM -0400, Jesse Stockall wrote: > On Wed, 2004-07-21 at 17:27, Greg KH wrote: > > > > It fixes an obviously broken chunk of code that is not maintained by > > _anyone_. And it will clean up all device drivers a _lot_ to have this > > gone, which will benifit everyone in the long run. > > > > Agreed, but this 'broken' chunk of code is 'working' for a lot of people > (whether or not this is due to pure luck is not the point) Pure luck. > > As for "right now"? Why not? I'm just embracing the new development > > model of the kernel :) > > That's the point that Oliver and I raised, the "leave it till 2.7" (not > breaking things for real world users) argument seems stronger than the > "rip it now" (because it makes things cleaner, easier to code, etc) > argument. The kernel development model (the whole stable/development tree thing) has changed based on the discussions at the kernel summit yesterday. See lwn.net for more details. That is why I sent this patch at this point in time. thanks, greg k-h
From: Jesse Stockall [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 18:17:24 -0400 On Wed, 2004-07-21 at 18:05, Greg KH wrote: > > The kernel development model (the whole stable/development tree thing) > has changed based on the discussions at the kernel summit yesterday. > See lwn.net for more details. That is why I sent this patch at this > point in time. Got any other sources for the info that don't require a subscription? I even live in Ottawa, if you have something available :) Jesse -- Jesse Stockall [email blocked]
From: Adrian Bunk [email blocked] Subject: Re: [PATCH] delete devfs Date: Thu, 22 Jul 2004 00:02:38 +0200 On Wed, Jul 21, 2004 at 05:27:52PM -0400, Greg KH wrote: > On Wed, Jul 21, 2004 at 05:19:42PM -0400, Jesse Stockall wrote: > > On Wed, 2004-07-21 at 10:52, Greg KH wrote: > > > > > > And as Lars points out, the code is unmaintained, unused, and buggy. > > > All good reasons to rip out it out at any moment in time. > > > > Unused? Since when does every Linux user use a vendor supplied kernel? I > > have no use for devfs, never used it in the past, and I'm a happy udev > > user now, but that doesn't change the fact that there are many devfs > > users out there. > > > > What does this gain us right now? > > It fixes an obviously broken chunk of code that is not maintained by > _anyone_. And it will clean up all device drivers a _lot_ to have this > gone, which will benifit everyone in the long run. I wouldn't disagree with this statement. I'd be very surprised if 2.7.2 would still contain devfs. > As for "right now"? Why not? I'm just embracing the new development > model of the kernel :) Could anyone please explain this mysterious "new development model of the kernel"? Is this some personal fight from you against Linus or someone else you are trying to bring to linux-kernel, or WTF has happened??? > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
From: Greg KH [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 18:07:36 -0400 On Thu, Jul 22, 2004 at 12:02:38AM +0200, Adrian Bunk wrote: > > As for "right now"? Why not? I'm just embracing the new development > > model of the kernel :) > > Could anyone please explain this mysterious "new development model of > the kernel"? > > Is this some personal fight from you against Linus or someone else you > are trying to bring to linux-kernel, or WTF has happened??? No fighting is going on here. I know lwn.net has already reported about this, see there for details. I don't have the time to write it up right now due to being at OLS. thanks, greg k-h
From: Brian Gerst [email blocked] Subject: Re: [PATCH] delete devfs Date: Wed, 21 Jul 2004 18:31:24 -0400 Greg KH wrote: > On Thu, Jul 22, 2004 at 12:02:38AM +0200, Adrian Bunk wrote: > >>>As for "right now"? Why not? I'm just embracing the new development >>>model of the kernel :) >> >>Could anyone please explain this mysterious "new development model of >>the kernel"? >> >>Is this some personal fight from you against Linus or someone else you >>are trying to bring to linux-kernel, or WTF has happened??? > > > No fighting is going on here. I know lwn.net has already reported about > this, see there for details. I don't have the time to write it up right > now due to being at OLS. > > thanks, Ok, is there anywhere else that isn't subscriber-only that has the scoop? -- Brian Gerst
From: [email blocked] (Jonathan Corbet) Subject: New dev model (was [PATCH] delete devfs) Date: Wed, 21 Jul 2004 17:11:23 -0600 > Ok, is there anywhere else that isn't subscriber-only that has the scoop? For those who weren't here, the basic scoop is this: - 2.6 is doing great, despite the fact that (by Andrew's reckoning) some 10mb/month of patches are going into it. - Linus is majorly pleased with how the partnership with Andrew has been working, and few people feel that he shouldn't be. He is a little concerned about breaking a highly effective process when 2.7 forks. - There is not a whole lot of pressure to create a 2.7 now, but a lot of interest in getting patches into the mainstream quickly. The end result is that there may not be a 2.7 for a while. Instead, significant patches will continue to go into 2.6, after a vetting period in -mm. Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree. Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly. Anybody disagree with that summary? jon Jonathan Corbet Executive editor, LWN.net [email blocked]
Stability: 2.4 New Features: 2.6
Anyone running anything mission critical nowadays is sticking with 2.4. They decided that 2.6, though it has many awesome new features that will help it scale and use big systems efficiently, is not the most stable platform for their setup. They use 2.4 for production, and they are still evaluating 2.6 to see if itimproves in its ability to run their software how they want it to run without modifications up the ying-yang.
2.6 is fantastic as a novelty on the desktop and as a development platform for linux companies (like redhat) to eventually move thier line to 2.6. 2.6 is very different from 2.4 and most people migrating will find the differences very fast.
So why is everyone complaining that 2.6 will be the place for dumping new patches and not focusing on stability? There should be a period of furious additions and changes, then after a reasonable amount of time, we should focus on the stability of the 2.6 kernel and then branch to 2.7. I don't want small, incremental changes followed by interminable waits to get the new features into the mainstream. 2.6 is young and NO ONE running mission critical is upgrading every 2 weeks just to get bleeding edge features. Distros will fall slightly behind, but this is where the stability lies. They will pick up a current kernel and as they prepare and package everything the version numbers will keep going up. They will apply patches for stability, forgoing the newest stuff. This has always happened and will always happen with linux. Look at the distros that were hurried just to make sure they had the newest stuff when they wer thrown out the door. They were unstable and buggy. Distro people should not worry that they only packages 2.6.4 and there is already a 2.6.7 in the tree. The difference is negligible if their 2.6.4 kernel is running stably.
In conclusion, I welcome the new philosophy for the current kernel development. It cannot continue indefinitely, but once a satisfactory state has been reached in terms of features Linus will blow the whistle and do a meta-freeze on 2.6 moving the radical stuff to 2.7. This will then become the time for fine tuning 2.6 and make it the premiere platform for stability AND performance. Corporate folks will be waiting to upgrade to 2.6 until this period of calm happens anyway. No one except for people who recompile their kernels weekly will mind this rapid pace of development. This is our time to really shine and move ahead as the most advance, feature rich platform in all existence. Linus and Andrew are extremely smart guys and the last thing they want to do is stifle innovation at the pace which heretofore has occurred. Praise to them.
Exactly
Nothing really new. It's the same "the stable version is going to continue evolving on it's own for a while and after that we will fork the devel version" type of thing, except that now they want to keep the stable version in flux for a bit longer than usual.
That's ok, early versions of "stable" series are not really stable anyway. No problem with waiting a bit more for the devel version.
That being said, i'm currently using 2.6 for some quite serious video and music work and it's perfectly stable for me (the latency buglets are yet to be squished, but that's another story).
Anyway, whenever there's a change, the overexcited bunch is bound to leap up shouting bloody murder. That's fine, that's not new either. When the adrenalin wears off, they'll be quiet again.
The period of furious additio
The period of furious additions and changes was SUPPOSED to be 2.5. 2.2pre were very stable and usable. 2.4 took awhile after .0 to stabilize. I've been waiting for a 2.6 that I feel I can trust and it looks like it'll be a long time still.
stability vs. features
Linux should not go the way of Windows 95 by providing features with constent Blue Screens of Death interrupting the user. Also Linux should not leave its falts be, the developers should not be stoped from removing the major issues that keep Linux from succeeding. Providing distros and users with two sub patch sets for stability and the other for features for 2.6 would be a better solution to each problem. Let the users/distro maintainers decide if they want radical features or rock solid stability.
Is it much different?
Really I don't see a huge difference. Thinking back a few years ago you only had two trees to work with - Linus' and Alan's. Now you've got a ton of other patchsets out there and things get more widespread testing. We still have a "development" tree, Andrew's -mm. And Linus still blesses a stable kernel release from time to time. Without a major change that means developers get to maintain one patch against 2.6 instead of continuously forward porting to a 2.7 development and backporting to a 2.6.
I think evolutionary development is good for a while. It lets more changes percolate for a while instead of being a giant development kernel bomb that gets unleashed every few years on an unsuspecting world. With new distros being on the bleeding edge more than ever, things like Fedora Core will see a semi-stable/new kernel get more widespread testing than any development line.
As long as my data doesn't corrupt and the kernel doesn't steal my lunch money, I'm happy.
Is it much different?
and if it does corrupt your data, does your argument change?
No, because 2.6-mm corrupting
No, because 2.6-mm corrupting data is just like 2.5 corrupting data. Nothing new here folks, keep moving.
RE: Is it much different?
"As long as my data doesn't corrupt and the kernel doesn't steal my lunch money, I'm happy."
Keep an eye on your wallet.
Two trees?
Thinking back a few years ago you only had two trees to work with - Linus' and Alan's.
No, you had two "official" trees, the stable one and the unstable one. For instance, 2.0.* and 2.1.*. Alan Cox's tree was often a testbed for new ideas like Andrew Morton or Andrea Achangeli's are.
Now we have two unstable trees - 2.6.* since Greg KH's patch went in, and Andrew Mortons. The nearest we have to a stable tree is the 2.4.* one, which may not be appropriate for recent Linux distributions that are built on the previsously stable 2.6.* kernels.
One more reason (on top of the SysV style init and kernel module insanity) to switch to something that's actually designed rather than randomly thrown together.
Chris
One more reason (on top of th
Sure, it's called Windows XP and it's the most user-friendly operating system produced in this quadrant of the galaxy. :-P
OS
Windows XP?
I can see you never heard about the "University of Mars Operating System".
Actually, Windows XP already
Actually, Windows XP already is much more stable than 2.6 kernels.
Very very bad...
If they to this, I will switch to FreeBSD! I have always used vanilla kernel, vendor kernel are bloated and often not very stable...
Does Linux become more and more like Windows?
Hold on ...
While I'm in the "I think this is a bad idea for business Linux users" camp, I have to say that your "Does Linux become more and more like Windows" comment is inflammatory and wrong.
This change, if anything, takes Linux farther away from the Window model. Windows rarely if EVER updates the kernel for a product. If you want a new kernel, you wait years for the next product rev.
The only way this could be seen as being more like Windows is that Distributions are now expected to stabilize the kernel. However, from what I'm reading it doesn't sound like 2.6.7+ (not -mm) will be any less stable than 2.4 was ... does no one remember the massive changes that happened in 2.4 ... USB had major updates around 2.4.20 ... the VM got totally messed with ... etc. Sounds to me like Linus and Andrew are just formalizing a process that started in 2.4 and making it easier for people to keep track of the changes.
Plus, it still sounds like 2.7 will be the "this is so experimental it is almost certainly broken in places" release. They're just not branching out right now.
2.6 was not really stable when released anyway ... so it makes a lot of (programmatic) sense to not do a 2.7 right now. Fix 2.6 ... get it stable. Just as a lot of companies didn't move to 2.4 until after 2.4.17 or 2.4.20 due to changes, alot won't want to move to 2.6 until it is fully developed. Get it there sooner.
Vendor kernels aren't bloated
Vendor kernels aren't bloated, if anything they would be slimmer because of the heavier use of modules. Most users don't go to the trouble of setting up an initrd and modularizing everything like distro-kernel maintainers will so you end up with a lot more statically compiled into the kernel.
stability over speed
Call me crazy, but I'd pick stability over speed any day, for a kernel.
ok, don't upgrade
If you want stability over speed they why not stick with a kernel that is tried, tested and reliable. No-one forces you to upgrade to the latest 2.6.x kernel anyway?
I don't understand the complaints. Only people who like to live on the edge run the latest kernel, people who rely on stability shoudl have the common sense to wait until a kernel has been tested by these 'cannon fodder' types first (like me!)
What if you need to upgrade y
What if you need to upgrade your kernel to fix a bug or security hole in your current kernel? Now you will be forced to take on the new changes which may come with new bugs.
Let others do the testing
I personally support this change in the development model. I have full confidence in that the people involved will do the best thing possible at this moment, even if this must be an uninformed opinion because I can't see all things that those who made the decision did.
But seriously, if you need to have both stability and security, then use a distribution that commits to both goals. Why not try, say, Debian stable? Or some other distribution. You can't hardly find any more slowly-moving slug for a distribution than Debian, whose community even after years keep on patching software versions that anyone else thinks is completely out-of-date.
Terrible
I just want to join the chorus - terrible. Either the folks are
crazy or the situation has been misunderstood by the reporters.
If true this will slow or stop Linux propagation, a single
mainline stable kernel is more important than features.
Stability
The enterprise software community made exactly this case to Red Hat: that a 'stable reference kernel' was needed as certification target.
The proposed kernel release process endorses RedHat's segregation of stablity (RHEL, $$$) and development (Fedora, %@!), by creating a market for stable 2.6 trees.
Without a LinuS tree as visible stability nexus, RHEL inherits the 'most stable tree' mantle and solidifies its position as app certification target.
OSDL damage?
Would it be possible that this new model is a produced by the OSDL environnment?
Relying on the vendor to provide a stable kernel can be seen as a major customer lock in. Did Linus and Andrew suffer from OSDL pressure?
Re: OSDL damage?
OSDL is a consortium, it does not sell or endorses any linux distro or company. And Linus has total contractual protection against someone/anyone trying to make pressure on how Linux works.
Yes, consortiums are without blemish...
The MPAA is a consortium. As is the RIAA. They don't have what you call "motives" and "objectives", right? Dream on.
Re: Yes, consortiums are without blemish...
But you can't fork mp3s/dvds ;)
Knee Jerking
So many people are freaking out here.
All that is going on here is a formal recognition of a process that has been going on for quite a while now. This is not some new fangled kernel dev process that's going to break everything. When was the last time RedHat or Suse shipped a vanilla kernel as the default? I've been using 2.6 since 2.6.0, all vanilla kernels, and they have been "very" stable for me since 2.6.4 and thanks to this rapid development/patching model, that many have been oblivious too until now, many problems in the early kernel versions got fixed very quickly.
How about instead of immediately jerking back within hours of this announcement and blasting this as horrible move, which happened long go, we sit back in our kernel comfort zones for a while see what really happens before we start jumping ship, or worse, compare Linux to Windows.
Its not crash-free-ness they
Its not crash-free-ness they talk about, but not having too
many changes. Touching apis is damaging to anyone who builds
on top of the kernel (all of whom of course wants the fixes
too)
Wait for the ship to be sunk before voicing any concerns.
For lot of good *that* would do...
META: typo correction
"*Fat* lot of good", of course.
Not a big deal, perhaps a sign of maturity
Frankly, this doesn't appear to be such a big deal.
Indeed, it may be a sign of maturity in the kernel.
One of the reasons to do the odd/even split was so that
the source code could undergo radical architectural changes.
The kernel now has so much functionality that, for many people,
small incremental improvements seem to be all they need,
instead of radical architectural changes.
For many small incremental improvements, a small staging area
(-mm) followed by official inclusion is actually quite a reasonable
process. Many other projects do exactly the same thing.
I want to know something
I was using slackware 9.1 with the 2.4.22 kernel, and when I tried to upgrade to 2.4.26, I had all sorts of problems. The ACPI and APIC stopped working, and I have so many devices that I needed it. I couldn't work sharing IRQ's. The USB UCHI module didn't work anymore, and the TV application I had stopped working right. I had to drop out of Xwindows and restart to get it to work. Want changed between the 2.4.22 and 2.4.23 - 2.4.26 kernels? I don't like whats going on here if it means I'm going to have problems like this. I might as well use windows.
not relevant
The vanilla kernel is designed as a platform for distribution providers, not as something end-users should tinker with. If some distributions such as Slackware choose to ignore that and, instead, expose the end-users to whatever cutting edges and rough corners still lurk in the vanilla kernel, that's their problem and in fact it's a flaw in their design philosophy.
You wanna use Slackware and the vanilla kernel? Fine, that means you're willing to work closely with the people who write the kernel code, report crashes back to them, be ready to deal with whatever problems arise, etc. It also means you're not ready for mission-critical and corporate environment stuff - if the latter is your target, then distro-provided kernels are what you should use instead.
If anyone in their right minds had doubts that "slackware is one of the most stable distros" is a hoax and a lie and pure misinformed propaganda, now is the time to realise the truth.
it *is* relevant
For instance, I was maintainer of one small distro for embedded systems (used for internal purposes, never published unfortunately). We used to use vanilla kernels+ipsec. I would be in great trouble if I should do some real patching since I have written only about 100 lines of kernel code so far. I was able to rely on stable kernel. What to do when vanilla is not stable any more? Move to FreeBSD?
What's your problem with slac
What's your problem with slackware?
Slack 10 uses 2.4 by default and 2.6 is in testing/
oh maybe 2.4 isn't stable....
one word : BSD
if you want an _os_ with a _stable_ _well documented_ development procedure I have some sites for you :
openbsd
freebsd
netbsd
end of discussion.
don't get me wrong. I like and use GNU/Linux, but it is definitely less stable than some other _Free_ as in _no-bs_ alternitives, because it tends to go for the latest features over stability the majority of the time
BSD is dying
BSD is dying
Flame
I don't see any kernel developers complaining about this change, only "stupid" users.
Users often don't understand what "stable" means. If I add support for
hardware Y that dosent touch kernel-Y, the kernel will remain "stable".
If I add feature K that does not touch kernel-K, the rest will remain "stable".
Linux is better because its always evolutioning!
stupid users ?!
Yes, who needs stupid users. That sounds a lot like the elitism I heard from XFree86 not so long ago.
Re: stupid users ?!
Last time I heard about, XFree86 was against changes....you should know by now what happened..
MS driven changes to hardware
Maybe this is a start of something that needs to happen. Instead of MS driving hardware changes. Maybe with the quick advancements/feature changes and support may give Linux a chance to drive some of the hardware changes? By showing better support for the given hardware this may give linux vendors a advantage?
Personally I use the 2.6.x kernel since the test5 days. I have had no major problems other than other vendor(s), ie. Nvidia. Maybe with the advanced/feature changes this might show nvidia to support linux better.
features do drive the show
Theres a reason by Direct X (even though its a POS) dominates over OpenGL when it comes to media development. Direct X has more features, marketing and money then OpenGL. So having an impressive feature list would sway hardware vendors to pay more attention to this kernel.
DirectX != OpenGL
You're confusing DirectX with Direct3D (or DirectDraw, if it still exists.) DirectX is _much_ more than OpenGL and that fact, besides marketing, makes it more popular. You can think of DirectX as of more or less OpenGL+SDL.
BSD is not more stable
http://bulk.fefe.de/scalability/
OpenBSD's performance is eradic. And there is no proof to this. I would take Linux 2.6.7 over FreeBSD or any BSD anyday.
An older benchmark, just to demonstrate it was never as stable or fast, atleast sense 2.2.x series.
http://www.samag.com/documents/s=1148/sam0107a/0107a.htm
FreeBSD crashes.
Friendly reminder of the two meanings of stable
Stable = does not change
Stable = works
If you think about it, the latter kind of stability can never be guaranteed except by completely controlled testing, which is impossible for any real-world project. So, the latter kind of stability can only be given with time, in practice: you wait and see others using the thing, and if it doesn't blow up for them, then it's high chances that it won't blow up for you. Not quite coincidentally, this is what the distributions are asked to do, and what they have done, for a long time.
But, there's much more important thing: the former kind of stability would mean that you don't evolve!
When people say that 2.6-tree is not stable here, and talk about changes, they mean that they officially recognize that 2.6 tree is allowed to have api changes. Now, this is a bad thing for all sorts of closed-source offerings whose vendors aren't particularly quick in releasing drivers or fixing infrastructure changes etc. I personally think that it's probably a good thing to apply pressure against vendors to open-sourcing their drivers: if it's open, they don't need to fix it. It will get fixed as long as it has users who care.
And Linux is the open-source OS. I think this is as sensible a strategy to proceed as any. And no, you won't find your new kernel crashing on you any more than it has crashed in the past. Meaning sometimes it probably does crash, but sometimes not. Yes, it can take months between crashes but I've seen them happen. Their change in development policy isn't going to affect that kind of "stability". But it does affect the kind of stability where you find that an app that used to work now doesn't work, because it relied on something the kernel hackers thought too ugly for words.
Evolution, people. Vote for evolution.
Oh come on.. stable doesn't j
Oh come on.. stable doesn't just mean "works." It means "works reliably for long periods of time with no service disruptions."
Working installations don't need to "evolve." They need the occasional bugfix and that's it. They don't need a major new version with new features they're not using, APIs they are using ripped out from under them, and subtle changes in semantics that happen to break their old, working, "legacy" apps.
My experience with 2.6
Its rock solid for me sofar :) Most of the lockups i have are because of hardware or buggy userland software. Actualy i have not had a kernel crash or oops for months now. Linus/Andrew keep up the good work!
Having an oops means that a)
Having an oops means that a) you don't have stable software, or b) you have some kind of hardware malfunction.
Good
Does this mean that people like those at LSB are going to drop the pretense that all these different OSes that use Linux are all the same OS?
Can we finally have broad acknowledgement that Red Hat, SuSE, Slackware, and the rest all produce different OSes that just happen to be more source compatible than two randomly chosen Unixes?
Of course, it's easy for ME to say "good," because the last OS I ever used that included Linux was Slackware 8.1.
-mm is the new development tree
I believe the way to think of this new method is that -mm is the new development tree. Previously only some of the changes that had proved stable in the development series were backported to the stable series.
Now instead of only a few things being backported, almost everything that seems stable enough will be moved across.
Major Mistake
I've been a reader of LKML since 1994, and promoted linux to ~50 businesses resulting in supervising ~1,000 linux server deployments.
This is the first real decision, in all that time, that Linus has made that I really disagree with - in fact, it seems somewhat insane.
Distributions may help fund kernel development and play a role in determining future needs and/or write better front ends/package things differently, but they should have no special role in the development of linux as a whole. We should be able to run and develop the os w/o them.
As a user, I should not ever be forced to go to redhat, debian, suse, etc for a stable kernel. When and if that happens, much of the freedom of linux is lost. I never know when some new server project is going to require creating a mini-distribution that only gets deployed to ~50 boxes. I am not going to trust any commercial vendor for this. I don't even fully trust that gentoo and/or debian have the staff to do it. Marcello/et al have done an awesome job w/ 2.4. and that is where I would currently head.
This new move totally kills things going forward.
I am going to predict that what is going to happen is that some group of kernel developers will create a non-commercial branch of 2.6.x and this will become the defacto kernel branch, with future kernels released by linus/et al being treated as a 2.7.x release regardless of name. Linus has essentially dropped support for stability of the kernel and that is horribly sad.
Some group, non partial to any distribution, is going to have to pick it up. I just hope it doesn't take too long.