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]
change - good & bad?
i can see good & bad points to this new development scheme:
- more evolutionary work
i'm still using 2.4 because some features are not available in 2.6 (specifically lvm snapshots, documented lvm2-on-root support, and virtual interfaces with native ipsec), though there are many new features i would like to try (interactivity work, packet writing, swsusp, io scheduler). yes, i'm using the lck patchset to get the previously listed interactivity work, but that prevents me from using packet writing and swsusp. if there was less difference between the stable kernel (torvalds) and the development kernel (morton), then maybe new features would be merged into the stable kernel quicker or at least new patches wouldn't conflict so badly with the stable kernel. essentially, the stable and unstable kernels wouldn't be so different as to preclude a user from using unstable patches in a stable kernel, as was the case for 2.4 and 2.5.
- less revolutionary work
i wonder if the revolutionary work that was done in 2.5 would have been discouraged if developers knew that their work wasn't going to be sandboxed for months in a development kernel. it seemed like at one time during 2.5 development no change was too big to be accepted. and that was fine because 2.5 had as much time as needed to get the bugs worked out. the -mm patchset doesn't seem to be as radical a departure as 2.5 (late in its life) was from 2.4.
anyways, i'm very curious about the different ways this new process will affect the development of linux.
Ya know, some of us still use vanilla
Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly.
That's great and everything, but myself and a good deal of people continue to use the vanilla tree. Destabilizing it, or having to play patch-o-matic to get stablity probably isn't going to endear many people.
Totally agree
I totally agree... many of us use vanilla environments and want then 'just' to be STABLE and COMPATIBLE with the software we use.
I'm experiencing a lot of problems when trying to compile any 2.01 version of the cdrtools. YES, the cdrtools, nothing exotic (I hope).
All the problems I'm experiencing come from things like the caotic use of
typedef unsigned char __u8;versus
typedef unsigned char u8;and some features from . This file should be #included by the kernel headers themselves, but in this instance it isn't and that breaks the cdrtools.
Is this enough reason to go for another Open Source Unix for my laptop? Maybe YES. Unless someone does a full audit of the kernel header files and fizes all kinds of inconsistencies,,,
cdrtools vs kernel
So what does cdrtools compiling problem have to do with the kernel?
Oh, are they using kernel headers instead of userspace (libc) headers? File a bug against cdrtools.
a lot of GNU's libc headers i
a lot of GNU's libc headers include the kernel's (eg linux) headers so that they can be compatible no matter what kernel you happen to be running.
stdint.h
In this case, shouldn't they use
no
stdint.h is a userspace header. Requiring libc to build the kernel would introduce a circular dependency, because the kernel is a prerequisite for building libc.
uh....
... that and you cannot use userspace stuff in the kernel.
There is no circular dependency, because it would not work at all.
not really
It doesn't really have anything to do with circular dependencies. It's all circular anyway - what do you compile gcc with? :)
Cheeky answer
The vendor compiler. :-)
BTW, none other than Ken Thompson touched on this sometime back. He discussed the process of writing the C compiler, and how later C compilers were written in C themselves. There are some zen-like moments in the talk, entitled "Reflections on Trusting Trust."
2.6 kernel headers
Don't use the vanilla kernel headers for /usr/include/asm and /usr/include/linux, they aren't usable by userspace apps.
Unless someone does a full audit of the kernel header files and fizes all kinds of inconsistencies,,,
Someone did this external of the kernel tree, kernel headers for userspace apps can be found at http://ep09.pld-linux.org/~mmazur/
Re: Totally agree
Use a vendor kernel which will also come with the header files.
cdrtools is exotic
The developer has been infected with SCSI and Solaris.
Anything else, like IDE on Linux, gets contorted to
fit the cdrtools model. Round pegs will be gleefully
pounded into square holes, files will be used to saw,
and hammers will be used everywhere.
Do not ever install kernel headers, or a link to them,
in /usr/include/asm or /usr/include/linux. This will
break your system. You need special cleaned-up headers
that come with your C library.
The real problem is cdrtools
The real problem is cdrtools inserts a -I/usr/src/linux/include onto the gcc command lines. Many users still have some ancient time symlink out there to the (probably not) current running kernel sources (often mandated by the distro #@$%^$#).
Cdrtools is broken because it tries to fetch headers directly from the kernel tree while it has nothing to do with it, the user above most likely has a system with so called 'sanitised headers' in /usr/include/*
Remove the unneeded symlink /usr/src/linux and cdrtools will compile (because gcc will fallback to /usr/include when it doesn't find anything in the -I specified location).
1) much easier then hacking in Schilly's makefile disaster
2) The link ought to be not there anyway
2a) If one needs the sources of the running kernel you look in /lib/modules/`uname -r`/build
2b) the symlink is more likely outdated then up to date.
Thanks a lot
Thank you, thank you, thank you. You see, the problem is _not_ the cdrtools, it definitely is this /usr/src/linux symlink. So yes, it's a distro ~#@$%&#"!!
It's interesting (and encourgaing) to see that other people who are way wiser than I am didn't resort to going that way either! Look at cdrdao. They resorted to patch Schily's library in order to make it compile in 2.6 systems.
I'd like to know if any of the migration guides to 2.6 identifies and/or explains this problem and I would encourage all migration guide authors (thanks people, you helped me a lot) to include this issue in their guides. Less intrepid users might succumb to their curiosity, try a migration to a 2.6 environment and be frustrated by this kind of quirks.
BTW, cdrtools might be exotic. But it's the way of taosting CD's and DVD's many people know and love.
> Thank you, thank you, thank
> Thank you, thank you, thank you. You see, the problem is _not_ the
> cdrtools, it definitely is this /usr/src/linux symlink. So yes,
> it's a distro ~#@$%�"!!
No it is not a distro problem.... those are kernel headers! They should not be used by a userspace program!
Actually, for DVDs...
dvd+rw-tools is much nicer than cdrecord -- which, btw, doesn't really work with DVDs, you need cdrecord.prodvd (which doesn't include source because schilly apparently suddenly got greedy).
Well, maybe someone will step up and offer a truly stable branch
One option would be to use Debian's kernel patches. But maybe someone will step up and offer a stable branch starting from whatever 2.6.x is current at the time and only adding in security and stability fixes from the mainline. Seems like if there is truly a need, someone will want to fill it.
Then you're clever enough to live on your own
If you use "vanilla" and compile your own kernel and stuff like that, then that means you know what you're doing and you are able to deal with whatever problems arise. It probably means you should report any crashes :-) to LKML and help the development process.
The rest of users, the ones who want a system that Just Works, will use a distribution-provided kernel. As simple as that. End of story.
Not always true
I use vanilla, but reason is my distro. It's RH based and doesn't work with my hardware. I did try build from RH SRPM, but have no luck with default setup. My distributor doesn't hurry to fix problem, so I have to use vanilla at work. I just wish it to work and nothing more, because I don't have time to sped on the another OpenSource project. I don't have this time. I'll choose kernel stable for me and stop on it, but with unfrequent updates.
I like how current kernel development process goes, but don't mind against new process cause I was using 2.5.60-2.6.3 at home and it was stable enough for me. ext3 had fail sometimes :) it's not a problem with backup. I think new model would be OK. I hope it'll speed up things a lot. If some distro is not ready to live without devfs it would be maitain patch.
Re: Ya know, some of us still use vanilla
> > Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly.
> That's great and everything, but myself and a good deal of people continue to use the vanilla tree. Destabilizing it, or having to play patch-o-matic to get stablity probably isn't going to endear many people.
I agree completely.
Ever since I switched to Red Hat (4.0 days, maybe 3.0) I _always_ ended up swapping out their custom kernel for a clean kernel, as the clean kernels were _always_ more stable. It's hard to believe that every single computer I've had in the last decade is _that_ unusual that a vendor's "cleanup" actually breaks things, but it did and still does (I'm running 2.6.7 on my dual-processor Fedora Core 2 boxes now, and will be putting it on my freshly rebuilt notebook soon).
If I have to rely on Red Hat to "stabilize" my kernels... stability problems will likely rival my girlfriend's Redmond-powered box.
(don't bother with the "change distros" comments, I'm exploring Suse and considering Gentoo already, let's keep this on-topic)
Then don't use the new kernels
Sure, many people use completly vanillia software but in this case you need not install the latest kernel version. If you are in an enviornment where uptime is of primary importance nothing prevents you (and most probably are) from running a 2.4 kernel. These type of vanillia applications don't need the new features in 2.6 (and in those rare instances where both stability and performance are of critical import a proprietary option is probably still the best solution). Even simple desktop use doesn't require more than 2.6. Even the few individuals who feel some need to run 2.6 but aren't really interested in being on the relatively cutting edge can run a 2.6 kernel tested and patched by a distributor.
My uninformed view is that this is a really good thing. The only time it is appropriate to split off a stable kernel (assuming some system like that described is used to vet new code) is when you have a large percentage of users primarily interested in stability but critically dependent on improvements made since the last stable branch. For instance the 2.4 stable branch was warranted because a fair number of SMP server features were critically dependent on the improvements in the kernel SMP system since 2.2. At the moment those users needing 64 processor support aren't going to be running an unpatched kernel anyway (and probably will either be drawn to a ressearch or proprietary OS as linux still lags in some aspects here). Maybe I'm missing some critical improvement that does warrant branching into a new stable branch, however, the advent of distributors makes even this less necessery.
forward porting and random thoughts....
I've always wondered how the forward porting of fixes that goes into the stable tree while there is a development tree open is managed...
From what I've seen it seems like it happens randomly. If someone spots a fix in the old stable tree that hasn't been included in the new stable tree it gets forward ported, else it's just forgotten....
So this non-stable/development-tree could for sure bring something good.
I view this "2.7 throwaway" as linus opening a 2.6-linus tree... Hopefully then the experimental changes (if they are successful) will be merged back into 2.6 instead of trying to forward-port all the tiny fixes that has gone into 2.6 during that time...
If my prediction of the future actually happens, then just one problem remains.... will we ever get a stable kernel past 2.6 ?
Maybee the stable version number changing needs a thought or two also. Maybee every time there's a "ripping out stuff frenzy" like alot of developers seems to be waiting for then there should be a new stable tree opened?
Stable branches besides 2.6
If you pay attention to Jonathan Corbet's e-mail on the LKML you'll see that
So yes, when 2.6-mm is too distant to 2.6 itself it will be called 2.7, and then you have the usual development model, that states that when 2.7 gets stable enough it will be the new stable kernel, 2.8. This model only makes that 2.7 (and 2.8) will come a lot later than it would normally come (too late, in my oppinion), but there will be stable kernels past 2.6 (unless you predict that Linux will soon die, which I don't believe... :P )
Does Linux just not _want_ to succeed in the corporate world ?
I know that Linux doesn't feel beholden to corporates or anything like that, but it has recently started to do quite well in this market-space, despite some brain damaged actions.
Major changes in the middle of a stable tree are just not sane! Things like the change of the threading solution to NPTL broke quite a few applications that had already been certified by their vendors as working on 2.4 kernels.
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.
What has made the Linux community suddenly decide that vendors should be the only ones to provide a STABLE tree ? What if your vendor has locked you in to certain restrictions in the kernel that they ship? Simply up and changing vendors for an entire data centre is flat out NOT an option, so you compromise by building your own kernel with the features you want / need. Now we are told that if we go this route, we may have to sacrifice stability ? That seems insane! What happened to choice ? What happened to Linux being a stable alternative to certain other operating systems ?
As it is, vendors have a lot to do besides just maintaining the kernel. This places a huge burden on both new and existing vendors in that they now _have_ to have kernel skills in-house, or rely on another vendor. A large part of the community support that they trusted will be removed with this new methodology. :(
I'm sad :(
Who is Linux?
If you want to use Linux in the corporate world you should try and use a commercial distribution that does provide a stable environment. For example, Red Hat Enteprise Linux. It comes with support and updates. It also provides a stable 2.4 kernel. They work very hard to keep the EL line compatible within a release cycle.
This provides other developers a stable platform to shoot for as well.
I see the stock kernel and being bleeding edge development. I think it should stay that way. Red Hat is better off focusing on the corporate environment.
thats nice and all
alot of people use linux for the price. redhats enterprise linux is NOT cheap. so all of a sudden its time to forget about the little guy?
sounds like people are beginning to get greedy.
no, this is just an attempt t
no, this is just an attempt to get the kernel to develop faster. 2.6 is still stable. and basically, 2.6.x-mm is working as 2.7.x
nothing weird is going on here, except that the 2.6.x-mm kernel will be far more in sync with the stable branch.
And if you're here reading this, you can probably figure out how to patch the kernel yourself (to fix teh security vulns), and otherwise, you're not going to know enough to fix the kernel yourself anywho (or build one), so you'd use your developer's kernel.
He has a point
No, he has a point here. When Andrew thinks that
he's just saying that "don't expect the stable branch to be stable", which is obviously bad. Notice that he isn't talking here about 2.6-mm but about 2.6 itself.
No point, just a dull end.
"..the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable.."
"If the mainline kernel doesn
"If the mainline kernel doesn't work for you, it's your problem."
And that's the problem. Now anyone who ever recommended an OS that uses Linux with the promise that there was this helpful community of developer, now looks like an idiot.
The user support community has already been having problems of vendor forks causing problems, but now that the mainline developers are giving up on stability these problems now cannot get any better.
At least, until we get a major fork from the current linux-kernel community...
Just filesystem layout ?
That's interesting... Because a lot of the compatibility problems I've seen come down to different versions of glibc, minor differences in library versions installed (due to availability of vendor packages), etc.
Linux 2.6.7-redhat vs. Linux 2.6.7-suse
Another disadvantage I can think of with the new development model is the possible tendency to have incompatible distros. I can imagine that the patches to gain stability in a vanilla kernel by a distro vendor would likely be much more extensive under this new development model possibly leading to more incompatibilities between distributions.
One thing I like about linux as it currently exists is that regardless of the 'flavor' of linux you install (Redhat, SuSE, Slackware, etc) you pretty much have compatibility between distributions (I know this isn't always the case, but generally seems to be). Would this hamper that compatibility? Will I find that some cool new program I got for linux only works on RedHat?
Just food for thought.
Hmmm...
...only if the distributors were foolish enough to ignore the license terms of the kernel. Which wouldn't be to their advantage.
alot of people can't spell.
alot of people can't spell.
RHEL is free(speech)
> alot of people use linux for the price. redhats enterprise linux is NOT cheap. so all of a sudden its time to forget about the little guy?
Well Red Hat Enterprise Linux(RHEL) is NOT free(like beer) but it's free(like speech). Try any RHEL clones:
Red Hat costs and development cycle
Red Hat is VERY expensive. We're talking around $1000 per server expensive here, and the support you get is more limited than MS or Solaris for the same kind of money. You also don't get lots of tools that other operating systems throw in for free such as patch management solutions unless you're ready to stump up another $8000.
As for their release cycle, yes they do try to maintain stability, but at the end of the day, there are times when they are forced to break it to go to a version with various kernel fixes, etc. Look at Websphere MQ - It _only_ runs on Red Hat Enterprise Linux AS Update 1 and above, and even then you need to get a currently unpublished patch from IBM to get it to work right.
And quick as they would like their release cycle to be, they still can't include important technologies like EVMS within a release lifecycle - you have to wait for the next release (in this case, AS 4, sometime next year) if you want those tools.
With that kind of cycle and those kinds of costs, you're better off sticking with your current vendor.
I'm currently doing a TCO study, and the ONLY way that Linux is cheaper with Red Hat is if you're getting significant performance increases on x86 kit over sun kit, and there are still large scaling issues with single applications and x86 kit.
redhat alternative
whitebox linux. google it.
better alternatives
Tao Linux and CentOS are better than White Box; sometimes White Box lags by a week or two in terms of security updates.
"Stable environment"?
RHEL, stable? HAH! I'll take Debian unstable over RHEL any day...
That being said, stability there is more like distro stability, not so much actual software stability...
OK, their stability is not terrible, but it could certainly be quite a bit better...
Sad.
This is really sad.
It seems to me that Linux kernel has reached midlife crisis.
I would love to see reaction on this from Gentoo/Debian/Slackware people.
P.S. In view of this events (and overall development of Linux last 2 years), my deflection to Mac OS X seems to be not that bad move. I'm still use Linux at work - but at home it is not worth the trouble.
Reaction from a Slackware user
This is the first time I think Linus has made a bad call. I am a trust the vanilla kernel to be dead stable. Most of my projects only build of a vanilla kernel becuase to many of the vendor patched kernels are tp big a moving target to keep up with and break all kinds of stuff.
That's Slackware's problem. T
That's Slackware's problem. The kernel is not supposed to bend over backwards to please the distributions. It's quite the other way 'round. It is perhaps the first clear proof that obsolete, marginal, minuscule distros such as Slackware have a development model problem.
It's probably a sign that Linux is truly getting mature now, and the useless lumber must be thrown out. Survival of the fittest and so forth...
That's Slackware's problem. T
That's Slackware's problem. The kernel is not supposed to bend over backwards to please the distributions. It's quite the other way 'round.
Couldn't have said it better myself :)
Slackware doesn't even have a real problem here
If the upstream kernel becomes too unstable for Slackware to use it as the default kernel (and I'm not even convinced that's going to happen), Slackware can just use a Red Hat or Debian or SuSE patched kernel. Or Pat Volkerding may even just apply backported security fixes (in fact he's occasionally done that in the past).
That has to be the most arrog
That has to be the most arrogant comment I think I've ever seen here. Yes, lets throw all the slackware, debian, and LFS people to the wind and see what happens to the OS. That "marginal, minuscule" distro existed long before most people had even heard of Linux.
Enjoy your trolling.
I personally totally agree.
I personally totally agree. I find that 2.6 has been nothing to the small average user, but everything from a corporate view. I recently (finally) upgraded from 2.4.26 to 2.6.7 and in all honesty there's no need - I have noticed *NONE* of the much vaunted speed increase. In fact in many ways, 2.6 has went backwards imho - things that worked with 2.4 don't with 2.6.
What i'm seeing is the Linux kernel has started to take off from a corporate point of view, but lacked some features that corporates wanted. 2.6 was a kernel tree designed to nab them and win corporates over from other Unices or Microsoft Windows servers. Plain and simple. The small end user doesn't generally buy Linux and therefore isn't a viable monetary option and therefore very few features were included to cater for them. Granted, 2.4 does most of what I need anyways without any issues. Don't get me wrong, 2.6.7 seems stable enough, I just can't justify using it over a 2.4 series kernel in all honesty. The improvements to the end user are negligible. This being said, it makes me question why it's taken nearly 3 years to go from 2.4 to 2.6. Better to fork the kernel - one for endusers and one for developers/corporate environments.
Whilst I think Andrew has done an excellent job of maintaining the kernel, I think he's more focussed on the corporate environment than the average user, and it's the average user base that has built Linuxs reputation. To ignore the end user is rather brazen and very dangerous. If people feel that the Linux kernel is starting to become 'unstable' in stable releases they simply will migrate to easier solutions - Mac OS X springs to mind. A lot of unix users haven't migrated to Linux, but instead have migrated to Mac OS X. Why? Unix like o/s and stability and user friendly. I don't see the bsd style unices grabbing much more of the limelight in all honesty, in fact I expect to see them shrink their userbases.
RHEL is not what I consider value. It's bloody expensive. I've used Redhat before, and i've found their support good, but still - for the money that RHEL costs...I can go an Apple agreement. Having distributions 'stabilise' the kernel is not their job! Period. I'm starting to get VERY worried...
Dave W Pastern
Nature of RHEL
RHEL is not what I consider value. It's bloody expensive. I've used Redhat before, and i've found their support good, but still - for the money that RHEL costs...I can go an Apple agreement.
But as has been pointed out by others, you can effectively get RHEL
without the price tag by using one of the RHEL clones. I am pretty
happy with White Box Linux, which is actually better than RHEL in that
it is a "union" of all the RHEL variants and adds some tools that
the real RHEL misses from some reason. And it is also surprisingly non-bloated. I succeeded running in on a laptop with a 166 Mhz
Pentium MMX in 1.5G disk space.
The real RHEL is strictly for corporations that want a well-supported
brandname distro and don't mind paying for peace of mind. Ditto for
the SuSE enterprise Linux.
A Gentoo perspective
Being a gentoo user I don't see how this has much of an effect on me either way. Gentoo seems to keep up fairly well with new kernel releases and apply patches as needed. And while I do not currently use any of the gentoo patched kernel packages if the vanilla 2.6.x series were to become unstable or a burden I could easily switch.
Chill out
The corporate world doesn't use the vanilla kernel. Distro-provided kernels are strong in that environment.