http://kerneltrap.org/node/view/3513
Maybe I will be switching my last Linux machine to BSD after all...
Maybe I will be switching my last Linux machine to BSD after all...
No Linux 2.7?
- Thread starter n0cmonkey
- Start date
It doesn't bother me at all. Their choice is mearly reflecting the natural progression of Linux and market forces.
In Linux you have two main groups of people:
1. Do stuff professionally with it, or value stability above all else. For these people you have Distros that choose and pick what features they want most out of the kernel and test for stability and performance. So for those people they will depend on a Distro to test and estabilish stability.
Which is what you depend on distro developers for anyways.
2. People who want to push the envolope, to have new features and support for new hardware quickly. For them, they deal with the same issues with kernel compiling and patches they've always delt with.
So now people deal with Fedora's kernel, with Suse's kernel. Standardize it inside each distro. The choice is up to the distro on how much they want to stick to compatability or whatnot.
Remember the mantra: "release early and release often". The users that like it, they help out with testing and whatnot, and the distros benifit from this experiance when they pick a kernel for their next release. The result will be a more stable and technically correct kernel for the average person or professional to use. It's benifiting from the natural way things work instead of trying to impose a artificial set of standards that just don't realy work out.
We all know what happenned with the early releases of 2.4. So now instead of saying "We made all our decisions last year on design. Even if they turn out to be mistakes, we won't fix them or replace them with something new because we want it to be stable.", the kernel developers are saying: "We tried our best and we are correcting any mistakes. Either you do some testing yourselves or simply use what was tested and worked in the past by your Distro. We will continue to crank out the best kernel we can."
As a developer you can never realy know what is correct or what is not correct until you have actual people use it. You can test and test and test. Set the design in stone, but that doesn't mean a whole lot until you get real world testing done.
At least thats how I see it. Anyways, they aren't saying their will be NO 2.7. It's just being delayed.
In Linux you have two main groups of people:
1. Do stuff professionally with it, or value stability above all else. For these people you have Distros that choose and pick what features they want most out of the kernel and test for stability and performance. So for those people they will depend on a Distro to test and estabilish stability.
Which is what you depend on distro developers for anyways.
2. People who want to push the envolope, to have new features and support for new hardware quickly. For them, they deal with the same issues with kernel compiling and patches they've always delt with.
So now people deal with Fedora's kernel, with Suse's kernel. Standardize it inside each distro. The choice is up to the distro on how much they want to stick to compatability or whatnot.
Remember the mantra: "release early and release often". The users that like it, they help out with testing and whatnot, and the distros benifit from this experiance when they pick a kernel for their next release. The result will be a more stable and technically correct kernel for the average person or professional to use. It's benifiting from the natural way things work instead of trying to impose a artificial set of standards that just don't realy work out.
We all know what happenned with the early releases of 2.4. So now instead of saying "We made all our decisions last year on design. Even if they turn out to be mistakes, we won't fix them or replace them with something new because we want it to be stable.", the kernel developers are saying: "We tried our best and we are correcting any mistakes. Either you do some testing yourselves or simply use what was tested and worked in the past by your Distro. We will continue to crank out the best kernel we can."
As a developer you can never realy know what is correct or what is not correct until you have actual people use it. You can test and test and test. Set the design in stone, but that doesn't mean a whole lot until you get real world testing done.
At least thats how I see it. Anyways, they aren't saying their will be NO 2.7. It's just being delayed.
No, not really. The reason behind this seems to be like they've got a pretty nice development model right now, where features can be tested by a large group of people fairly quickly.
What exactly bothers you?
Do you want a kernel thats been extensively tested, that has no new features and only bug-fixes? Then the vanilla-kernel is probably not for you. Of course then you'd probably also stick with a vendor-supplied kernel, since you're only looking for stability and not new features. Or if you dont like your vendor supplied kernel you could always stick to the 2.4 kernel series which is just bug fixes. I'm not totally sure what going to a *BSD would get you that switching 2.4 for 2.6 wouldnt.
Bottom line: does it affect your day to day running on your machine? Does the kernel that you use actually crash more frequently?
I don't rely on a distro to test the kernel. I use the kernels from kernel.org. So I guess I'm just _fucked_.
The point of the .evens is stability. NO NEW FEATURES. 2.4.10 was a fluke. Someone decided it would be a good idea to change the whole VM subsystem in midstream. Great. Now we're just getting something that is lightly tested in the -mm branch? Release early, release often is fine. In the DEVELOPMENT branch. But the STABLE branch shouldn't be getting anything beyond bug fixes.
If I'm using a .even, I don't want to be the beta tester. I want to be a user with a stable piece of software. Thankfully, I'm not in charge of maintaining the Linux boxes at work, so this shouldn't bite me too hard when they screw up.
The point of the .evens is stability. NO NEW FEATURES. 2.4.10 was a fluke. Someone decided it would be a good idea to change the whole VM subsystem in midstream. Great. Now we're just getting something that is lightly tested in the -mm branch? Release early, release often is fine. In the DEVELOPMENT branch. But the STABLE branch shouldn't be getting anything beyond bug fixes.
If I'm using a .even, I don't want to be the beta tester. I want to be a user with a stable piece of software. Thankfully, I'm not in charge of maintaining the Linux boxes at work, so this shouldn't bite me too hard when they screw up.
Ummm, yeah that's how it worked. .evens are stable and tested. .odds are development.
Slackware ships with a pretty vanilla kernel. You know, the stable ones, from kernel.org. The ones that only got bugfixes, and not new features. Like a stable kernel should.
2.4 is old. 2.6 is supposed to be the stable kernel right now. Or, atleast it was supposed to be the stable kernel right now.
Stability. Consistancy. Sane development model.
The one I use doesn't crash. It's stable. It's tested. It's vanilla.
Ya but when you make a stable branch and it turns out to be wrong choice, then your F*CKED anyways, because they aren't going to change it. Because it's stable. It can't be fixed.
If your right then everything that they picked for you from kernel 2.6.0 your just going to have to live with it until kernel 2.8 comes out in another 2-3 years or whatever. Because that's the stable branch and we can't do any fixes or improvements.
How often do you upgrade your kernel anyways? Do your production boxes get a new kernel everytime a update is released, wouldn't that be a bit stupid even if there was a seperate 2.7 branch?
I think you missunderstand. The developement branch isn't what is released in kernel.org, it's whatever the developers are working on. Whatever is in their CVS.
Whenever they get a snapshot they like, they make it a release canadate. Then they make another. And another, and another. Meanwhile anybody is free to back port and make patches. Distros use what they need to, and bugfixes still happen.
Just like any other free software software.
Then they release another 2.6.x kernel. Technology is progressing to fast to wait another 3 years for any new stuff.
Wouldn't it be stupid to ignore new ideas and better developements because you just decided that you can't change stuff, just because? Just automaticly have to dismiss everything because you deciced last year that you are not going to accept any new developements.
When their is actually a REASON for 2.7, then they will start on it. They aren't eliminating it forever and forever. Their just isn't any point for one right now.
If your right then everything that they picked for you from kernel 2.6.0 your just going to have to live with it until kernel 2.8 comes out in another 2-3 years or whatever. Because that's the stable branch and we can't do any fixes or improvements.
How often do you upgrade your kernel anyways? Do your production boxes get a new kernel everytime a update is released, wouldn't that be a bit stupid even if there was a seperate 2.7 branch?
I think you missunderstand. The developement branch isn't what is released in kernel.org, it's whatever the developers are working on. Whatever is in their CVS.
Whenever they get a snapshot they like, they make it a release canadate. Then they make another. And another, and another. Meanwhile anybody is free to back port and make patches. Distros use what they need to, and bugfixes still happen.
Just like any other free software software.
Then they release another 2.6.x kernel. Technology is progressing to fast to wait another 3 years for any new stuff.
Wouldn't it be stupid to ignore new ideas and better developements because you just decided that you can't change stuff, just because? Just automaticly have to dismiss everything because you deciced last year that you are not going to accept any new developements.
When their is actually a REASON for 2.7, then they will start on it. They aren't eliminating it forever and forever. Their just isn't any point for one right now.
Then they should have tested it better in development.
Fixes are fine. But major changes are not. Why? Because it is supposed to be stable.
And the 2-4 year development cycle is getting old. Can't they go with something sane?
When a new stable one comes out.
Why would it be stupid? The changes have been tested. They should be bug fixes.
No, I understand just fine. I can download a stable branch (2.2, 2.4), or I can download a development branch (2.1, 2.3, 2.5, 2.6). If I want stability, I stick with the stable branch. If I want new wizbang features with a good chance of prison butt, I get a development branch.
The backports don't typically make it into the vanilla kernel. Most of the backports I remember were included in the distro specific kernels. Like when the Linux kernel developers couldn't get USB working in a reasonable amount of time.
Except most FOSS projects have a stable and development branches. The Linux kernel no longer makes this distinction.
Then change the amount of time it takes to release a new stable kernel.
Yes. But keep development where it belongs.
There will still be development going on. It's just out of the way so that users that need stability don't have to put up with the great unknown and barely tested.
A new feature would be a reason for 2.7. But they're ignoring that.
If there wasn't a point for a development branch, we wouldn't be having this discussion. Active development should be going on in a development branch.
The developements all happen in 2.6.x-mm. Just like always.
Look, I'd be worried too, but what they've been doing has been a great thing. Each kernel release so far has been better then the last, and the first releases were mostly better then even the mature 2.4 versions.
Personally I like it when they get introduce things like the add the Prism54 802.11g drivers to the mainlain kernel. I used them before they were incorporated into the kernel, and they were stable. Adding them to the vanilla kernel was a good move.
Now if you don't think that they shouldn't of been added until 2.8, that's your business. But I liked that.
When they release 2.7 that will be because that will break backward compatability. That is were the experimental stuff is going to happen. Right now they are just going to keep doing what they have been doing since 2.6 was released. I liked it, they liked it. I don't see any problems with the way it has been going so far, have you?
edit:
Or are you saying that the kernel developers should continue to support DevFS for the forseeable future, even though nobody is using it or at least developing on it?
Look, I'd be worried too, but what they've been doing has been a great thing. Each kernel release so far has been better then the last, and the first releases were mostly better then even the mature 2.4 versions.
Personally I like it when they get introduce things like the add the Prism54 802.11g drivers to the mainlain kernel. I used them before they were incorporated into the kernel, and they were stable. Adding them to the vanilla kernel was a good move.
Now if you don't think that they shouldn't of been added until 2.8, that's your business. But I liked that.
When they release 2.7 that will be because that will break backward compatability. That is were the experimental stuff is going to happen. Right now they are just going to keep doing what they have been doing since 2.6 was released. I liked it, they liked it. I don't see any problems with the way it has been going so far, have you?
edit:
Or are you saying that the kernel developers should continue to support DevFS for the forseeable future, even though nobody is using it or at least developing on it?
Which could have easily been 2.7 without tainting the 2.6 tree.
I think backporting drivers is a bit different than other things. Mark them as experimental, and I would see no problem with it. Chances are, I'd take them out anyhow.
I'd just like to be able to move to a new stable kernel. 2.4 is getting boring. But from the looks of things here, there won't be another stable kernel for a while.
I haven't been paying a lot of attention to linux kernel development. So if there were problems, I wouldn't know about them. This just has that "changing too much too fast" feel.
Maybe that's one of the reasons I prefer BSD over Linux. The evolution instead of revolution development model, where we have stable and development trees clearly defined.
I don't care about devfs per say, but removing a potentially large chunk of code could cause some problems. Removing it in a development branch makes more sense to me instead of mucking with something that is known good.
The code isn't supported by anyone. Nobody wants to touch it and I don't blame them. It's pure luck that it works at all.
I think that the statement that said: "this will be the most feature rich... can't expect it to be the most stable" is just being honest about the state of affairs, moreso then a new policy statement.
You know that when ever new software is released, bugs are going to crop up no matter what. You can test and test and test, and bad things will still happen because you'll never be completely sure until it hits the real world.
There will be a 2.7, and when that does get started it I am supposing that it will be so different that back porting patches like what was done in 2.5 to 2.4 will be a thing of the past.
Maybe they are thinking that the next developemental branch will be eventually be 3.0, since they were talking about the possibility of 2.7 being a "throwaway" experimental branch....
I think that the statement that said: "this will be the most feature rich... can't expect it to be the most stable" is just being honest about the state of affairs, moreso then a new policy statement.
You know that when ever new software is released, bugs are going to crop up no matter what. You can test and test and test, and bad things will still happen because you'll never be completely sure until it hits the real world.
There will be a 2.7, and when that does get started it I am supposing that it will be so different that back porting patches like what was done in 2.5 to 2.4 will be a thing of the past.
Maybe they are thinking that the next developemental branch will be eventually be 3.0, since they were talking about the possibility of 2.7 being a "throwaway" experimental branch....
Maybe the next branch will be 3.0. But that just shows that Linux developers can't count.
They seem to be expecting the distros to do the cleanup work. That's not a good policy, IMO. devFS is gone? Fine. Let's see what the next big thing they add will be.
IMO, 2.6 will never be considered stable, as long as they continue to muck with it.
They seem to be expecting the distros to do the cleanup work. That's not a good policy, IMO. devFS is gone? Fine. Let's see what the next big thing they add will be.
IMO, 2.6 will never be considered stable, as long as they continue to muck with it.
I think I'll agree with n0c, I don't fancy this new development model.
I'd rather see them going to something like OpenBSD's model of one release every 6 months, though I guess maybe 12-18 months would make more sense for the Linux kernel.
But I'll wait it out, maybe it'll be a good thing in the end, wierder things have happened.
I don't mind running such a kernel on my workstation, since my important data is backed up, and a little downtime on my workstation is ok, but I wouldn't dream of putting such a kernel on any server-type system.
I'd rather see them going to something like OpenBSD's model of one release every 6 months, though I guess maybe 12-18 months would make more sense for the Linux kernel.
But I'll wait it out, maybe it'll be a good thing in the end, wierder things have happened.
Yeah, that's my opinion as well.
I don't mind running such a kernel on my workstation, since my important data is backed up, and a little downtime on my workstation is ok, but I wouldn't dream of putting such a kernel on any server-type system.
If you want to run a development kernel, then you should. But I don't want to on my Linux system. When something breaks, I won't know how to fix it.
But I'll be stuck with 2.4 on the Linux machine. I was looking forward to eventually trying out 2.6...
But I'll be stuck with 2.4 on the Linux machine. I was looking forward to eventually trying out 2.6...
Who cares about numbers and such silly semantics? Maybe .evens used to be the stable kernels, and maybe they want to change that. Isn't the code what matters? You used the vanilla .even kernels before because they were the stable ones. So find which ones are the stable ones now, and use them. I don't see why version numbers matter that much. I also don't see why downloading the source from debian, redhat, whoever is so horrible as opposed to downloading it from kernel.org. Yes, it is change. Change is sometimes good. But regardless of whether it's good or not in this case, you can't really control it -- so why not just find where you belong in the new scheme?
But regardless of whether it's good or not in this case, you can't really control it -- so why not just find where you belong in the new scheme?But what if 2.6.182 has an important bug fix that 2.6.181 doesn't, but it also has some barely tested feature I don't care about?
kernel.org source is the vanilla source. Debian, redhat, whoever may have changed things.
Yes, it is change. Change is sometimes good.
I know, but I felt like bitching.
I know where I belong in the whole scheme of things.Originally posted by: BingBongWongFooey
Who cares about numbers and such silly semantics? Maybe .evens used to be the stable kernels, and maybe they want to change that. Isn't the code what matters? You used the vanilla .even kernels before because they were the stable ones. So find which ones are the stable ones now, and use them. I don't see why version numbers matter that much. I also don't see why downloading the source from debian, redhat, whoever is so horrible as opposed to downloading it from kernel.org. Yes, it is change. Change is sometimes good.
I just don't like the idea of not having a stable branch.
Unless you count 2.4 as stable, in which case the stable branch will become horribly outdated soon.
Then you go "make menuconfig" and uncheck that new feature. I do it all the time.
Originally posted by: Sunner
Originally posted by: BingBongWongFooey
Who cares about numbers and such silly semantics? Maybe .evens used to be the stable kernels, and maybe they want to change that. Isn't the code what matters? You used the vanilla .even kernels before because they were the stable ones. So find which ones are the stable ones now, and use them. I don't see why version numbers matter that much. I also don't see why downloading the source from debian, redhat, whoever is so horrible as opposed to downloading it from kernel.org. Yes, it is change. Change is sometimes good.
I just don't like the idea of not having a stable branch.
Unless you count 2.4 as stable, in which case the stable branch will become horribly outdated soon.
Hm... Reminds me of a certian distro that still uses 2.2 kernel for their default install...
Originally posted by: drag
Then you go "make menuconfig" and uncheck that new feature. I do it all the time.
Originally posted by: Sunner
Originally posted by: BingBongWongFooey
Who cares about numbers and such silly semantics? Maybe .evens used to be the stable kernels, and maybe they want to change that. Isn't the code what matters? You used the vanilla .even kernels before because they were the stable ones. So find which ones are the stable ones now, and use them. I don't see why version numbers matter that much. I also don't see why downloading the source from debian, redhat, whoever is so horrible as opposed to downloading it from kernel.org. Yes, it is change. Change is sometimes good.
I just don't like the idea of not having a stable branch.
Unless you count 2.4 as stable, in which case the stable branch will become horribly outdated soon.
Hm... Reminds me of a certian distro that still uses 2.2 kernel for their default install...
Well, whenever I install a Debian/Stable, I go with the 2.4 kernel they also ship, so that's not an issue to me
Originally posted by: drag
Then you go "make menuconfig" and uncheck that new feature. I do it all the time.
And if that feature has little tendrils into other parts of the kernel?
Maybe this is just another reason Linux isn't for me.
Originally posted by: n0cmonkey
Originally posted by: drag
Then you go "make menuconfig" and uncheck that new feature. I do it all the time.
And if that feature has little tendrils into other parts of the kernel?
Maybe this is just another reason Linux isn't for me.
They rarely do. For instance You can give or take devfs, even when it was most popular. You can give or take SCSI subsystem or do with out even basic filesystem support, or IDE support. People are able to strip even 2.4 down enough to get decent linux functionality on just a floppy disk.
All in all it's pretty modular.
Originally posted by: drag
Originally posted by: n0cmonkey
Originally posted by: drag
Then you go "make menuconfig" and uncheck that new feature. I do it all the time.
And if that feature has little tendrils into other parts of the kernel?
Maybe this is just another reason Linux isn't for me.
They rarely do. For instance You can give or take devfs, even when it was most popular. You can give or take SCSI subsystem or do with out even basic filesystem support, or IDE support. People are able to strip even 2.4 down enough to get decent linux functionality on just a floppy disk.
All in all it's pretty modular.
And a new VM setup?
My policy has always been to use a .even until there was a .odd following it. I plan to continue to stick to this policy, even though I definetly want a lot of the features of 2.6.
From what I've read about the issue, Linus wants to continue making a bunch of small changes. That's fine with me, he should branch 2.7, and release 2.8 in 6 months. Then he can make big changes in 2.9 and release it as 3.0.
I wonder if this is a way to stick it to Hans Reiser, by delaying how long there is a developmental branch, he keeps Reiser4 out for longer.
From what I've read about the issue, Linus wants to continue making a bunch of small changes. That's fine with me, he should branch 2.7, and release 2.8 in 6 months. Then he can make big changes in 2.9 and release it as 3.0.
I wonder if this is a way to stick it to Hans Reiser, by delaying how long there is a developmental branch, he keeps Reiser4 out for longer.
I kinda see where you're coming from n0cmonkey. Example: I had 2.6.1 setup to use IDE-SCSI for my burner, then in like 2.6.3 or something, IDE-SCSI was officially flagged as deprecated in favour of using the regular IDE-CD driver for ATAPI CD-RWs. So I used that instead. Now I have issues where it complains of lost interrupts and failed command sends that do not exist if I load the IDE-SCSI module. This was a difference in the production stable kernel.
Sounds like something else causing the problem... Maybe, do you have APIC support in the kernel?
I've never had a problem with the extended ATA IDE stuff myself, could be a drivers issue. You know you still can use IDE-SCSI emulation if you want to.
I've never had a problem with the extended ATA IDE stuff myself, could be a drivers issue. You know you still can use IDE-SCSI emulation if you want to.
TRENDING THREADS
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 10K
-
Discussion Speculation: Zen 4 (EPYC 4 "Genoa", Ryzen 7000, etc.)- Started by Vattila
- Replies: 13K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 7K
-
Facebook
Twitter