Slashdot Mirror
Revamped Linux Kernel Numbering Concluded
kernel_dan writes "Following on the heels of a prior discussion about a kernel numbering scheme, KernelTrap has the conclusion. From summary: "Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable.'" Torvalds suggested specific guidelines to alleviate burn-out of the .y maintainer and Greg KH volunteered to begin maintainership."
Why not do 3.x, 4.x, ... like every other software developer in the world (well, except Microsoft and Apple...)?
Honestly, I don't understand the insistence on keeping everything at 2.x, 2.x.y, etc. If someone can explain the rationale to me, I'd be quite interested.
Right now, I consider 2.6 not stable enough for my own use. If I cannot compile and boot a Linus kernel on a simple install of GNU/Linux (whether SuSE or Debian) without major headaches and/or chasing down patches, well, that's not stable enough for me. YMMV.
Back in 2.4, I wasn't really happy until 2.4.18, and with all of the changes in 2.6, I won't be surprised to see it meet my definition of stable until 2.6.20 at the current pace.
So, I'm hoping that this new approach will really help.
You are being MICROattacked, from various angles, in a SOFT manner.
Besides, Mono can probably compile to machine code, just like anything else.
I don't know what's up with the kernel devs, but I for one just want a stable kernel without having to resort to specific distro kernel patches. They have not been able to provide that on the mainline since 2.6 has been released(in my opinion, from my observations). They should have forked 2.7 awhile ago if they were going to be pulling this and put the new code in there. Hopefully this new way of distinguishing between stable and unstable releases will help a bit, but I'm not keeping my hopes up. It may be time to switch to a BSD if they can't get their act together.
thisnukes4u.net
that i regularly have seen breakages with stable hardware upon upgrading from one "stable" kernel release to the next. Granted most of them have been ACPI .. which is just a joke. All I gotta say in 2.7 please.
There's nothing that wrong with depending on an organization (be it commercial like Mandrake or non-profit like Debian) to put together an appropriate Kernel for you. That's not to say you shouldn't give BSD a crack (diversity encourages vigour after all), but I don't think there's anything wrong with the way Kernel development is taking place. Those who needs a rock-solid unfliching kernel can always use a 2.4 series kernel, or use BSD (as you suggested).
Having been doing a lot of complex analysis lately, I enjoyed this comment! Totally off topic and all but cartesian coordinates are "overrated" granted they are the most "natural" but anyone doing any kind of math/science/engineering has no doubt seen the incredible usefulness of other coordinate systems. "Alternative" three dimensional coordinate systems prove very useful for lots of integrals becasue of the symmetry. Anyway yeah... moving on.
It takes all types in this world. I sincerely mean it... This is just my perspective.
No kidding, even Linus's most offhand comments are so well thought out and plain spoken that it's a pleasure to read. Wanna know why he's in charge of the Linux kernel? Just read. He's so common sense and matter-of-fact about everything that it's easy to see why everyone gravitates to him. And no, I'm no kernel hacker, just a Linux geek. But just reading his occasional emails is more than enough to make me want to convert everything on the network. Sometimes I get caught up in the issue du jour, but Linus's plainspoken sense of reality always reels me back in. Again, I'm no kernel hacker, but I'm constantly aware of the huge debt I owe to Linus, and every other open-source developer. You guys make things possible, I just use your work. Thank You.
"And now, Frank N. Furter, your time has come. Say 'goodbye' to all of this, and 'hello'... to oblivion!"
Their goal is to write a complete operating system in Java.
Does this mean that 2.6.x releases will actually be stable and reliable again? After getting burned by 2.6.8 and 2.6.9 (both of which had show-stopping bugs that, for instance, kept my CD burner from working or various USB-based devices, all of which worked again magically in 2.6.10), I'm now very wary of new "stable" kernel versions. On the one hand I'd like to stay up to date to get the latest security patches, but on the other I really don't need my USB ZIP drive to stop working every other kernel version. Handling individual security patch files is more trouble than it's worth for a home system, frankly (I'd rather have a life), so that's out. So what's a moderately security-minded user who wants a reliable system to do?
:-)
If going down another point level for bug fixes will help the problem, then I'm all for it. Just make it clear what people like me should be downloading.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Indeed, I feel that 2.6 was pushed out prematurely, but many features in it are desparately needed for publicity (for example, a working ACPI), so the kernel needs the "stable" status to give people incentive to use.
The fact that kernel developers are still adding new features suggest that it is still a development kernel. Stable kernels are for bug fixes. If they need new features to fix existing bugs, that's when they should bump up the stable version number.
However, I think version number is already obsolete for Linux kernels. We should be able to manage patchsets as if they're software packages, complete with dependency and conflict information that are automatically computed. When you want a "patch" to be included in your kernel, it looks for patches it depends on, checks to see whether it results in a conflict, and apply the patches. Periodically, "metapatches" are updated to depend on the most recent patches along some feature. More intricacies need to be worked out.
Assuming (0) that there is a demand for such a patch manager---I think the problem with developing it is that (1) it's difficult to develop a realistic test project from ground up using the patch manager, so the patch system can show that its design is useful, and (2) if we use an existing large software project (such as the Linux kernel), programmers for the patch manager would spend too much time following the development for that other project, rather than have useful work done; they might not want to do it. In general, we want to test the patch manager on a big project, but we also risk wasting too much time on the test project.
It would be best if the developers of a large project (can also think about the Linux kernel) will take the initiative into developing a patch manager, since they have a demand for it (or can be convinced to have a demand), already have a realistic software product, and are willing to follow the development of their own project.
I'm saying that there is a seed for an innovative patch management and revision control system from maintaining a Linux kernel. They should do something about it.
I once had a signature.
Arstechnica you say? -- isnt it ironic their site was down for atleast 5 hours about a week back?
Also, look at their uptimes on netcraft. There average uptime plummeted to about half since they switched to windows. Sure its still "good enough", but how can you possibly say 2003 is more stable that linux? - especially substantially more stable?
o/~ Join us now and share the software
"There's a reason Ars Technica switched from Linux to Windows, and stayed there. If anyone on the planet is competent, it's those guys."
From the sounds of things, everyone competent there was utterly against the WindowsNT switch, which was introduced by management, caused horrible delays in shipping all their products, and caused most of the technical guys to leave.
But it sounded so much better as a soundbyte
actually; with only one x-chomosome (45,X) the person is suffering from Turner syndrome and probably wont have any menstruation at all unless treated with hormones
Debian Stable is, indeed, very stable. It is also very difficult to use in real life, because virtually anything that's non-Debian-provided won't work on such old versions of libraries, and many developers simply refuse to work on such old versions of software. Every time I have tried to stick with Debian Stable, that decision has been overruled by management because the developers hate it.
All I'm fundamentally asking for is this: I want security fixes to Linux WITHOUT NEW FEATURES. I don't have time to study the new features with every kernel rev. I need drop-in-and-forget kernels. But I often don't trust the distributions to do it either, they're constantly adding all sorts of crap I don't want or need in my kernels.
Running a fairly secure Linux box means, among many other things, disabling all modules, but there are no vendor-supplied kernels I know of that don't use modules. If you want a monolithic kernel, you have to compile it yourself. And for that reason, I have tracked the 'stable' tree for years. And I am FURIOUS that the stable tree is no longer stable, that I'm getting new features with my security patches, like it or not. If I want new features with my service packs, why not run friggin' Windows again? Someone MAY backport the bug fixes, but then again, they may not. They're sure gonna have a damn hard time of it when Linus is silently fixing security problems WITHOUT TELLING ANYONE.
2.4 did add small things... new device drivers, that sort of thing. But they weren't doing the huge monkeying around with things that they continue to do with 2.6. They only put bugfixes in the core: the only things added were ancillary, optional, and easy to turn off. (well, since about 2.4.11, when Linus finally got sane and went off to 2.5)
2.6, on the other hand, has been a complete disaster from a security and administration viewpoint. Silent, unannounced security fixes to the kernel, new features rolled out constantly in a 'stable' series, instability on even small servers. (see my post above for how 2.6 sort of cost me $800.) One kernel dev said that it is acceptable for 1 kernel out of 3 in the 'stable' series to actually be stable!! This is not how to run a railroad.
People are saying 'you should be using 2.4', but 2.6 is STABLE, remember? I should be able to use it freely. People telling me not to use 2.6 yet are PROVING THE POINT, that it's NOT STABLE. I don't think it's going to get there until they stop adding features and branch off to 2.7.