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."
The new numbering scheme seems to be designed to give various junior-Linus types the chance to run the show, if only for a .short time.
The *.x.y kernels are unstable.
The *.x only kernels are stable.
Won't there be a 28 day cycle for
stability on the *.x only kernel?
How *DO* you write a Linux device driver in C#?
fifth sigma, inc.
You can find it in his own subdirectory on kernel.org at:
g kh/v2.6.11/
http://www.kernel.org/pub/linux/kernel/people/gre
It includes tiny fixes such as a Dell laptop keyboard fix and a raid6 compilation fix for ppc.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
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.
2.6.x...
2.6.x.y...
2.6.x.y.z...
Kind of a Zeno's Paradox, isn't it?
The coolest voice ever.
And all bets are off if you try compiling more than one *.x.y kernel on the same computer ...
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.
"Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable."
Thank you.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
What was wrong with .4 being stable and .5 being test? Why not start a .7?
I haven't been following the kernel mailing list, but as a regular linux user from way back, I'm not clear on why the old way was dropped. This way seems a lot more confusing to me.
...welcome our new many.version.levels.over.lor.ds.
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.
is this why we learn calculus for software engineering?? see what number we're approaching in the infinite series
just like the humble blood clot... turboporsche@telus.net
FYI, Andres Salomon's patchset provides the foundation for Debian's kernels and has been discussed recently on kerneltrap here and here.
Best regards, A.C.
I'd have preferred r-theta polar coordinates.
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
/me anxious awaits the release of kernel 3.14.1.59.265.35.897.93238462643383279...
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.
Yeah, I agree, Linus kernel is not good for production use. Give Linus a good thwack on the forehead and he may die. Or he may not. It's unpredictable and unacceptable.
Now back in my day, kernels were only found in nuts.
The preceding post has been brought to you by the Automated Joke Destroyer 5000.
It would be cool if it didn't suck.
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).
I just have finished compiling this 2.6.11.0.0.0.0.1 kernel. Damn 2.6.11.0.0.0.0.2 is out, time to recompile.
So when you're following the stable 2.6.x.y and 2.6.(x+1) comes out, you potentially have to immediately switch trains to get security patches. Doesn't sound stable to me.
For this idea to work, more than the current 2.6.x needs to be supported as stable.
Linus Tourvalds keeps insisting he's just a coder and nothing more, and Alan Cox and everybody keep insisting he's just a coder and nothing more, but watching him in situations like this... he really is is disturbingly competent as a project manager. Like, to a degree that betrays a large amount of talent. I think he and others really sell him short... but of course one of the reasons he's so effective is because the relatively unassuming way in which he approaches things means people's attention is diverted elsewhere, thus allowing him to actually get stuff done :P
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Okay, you've got your x.0 release. These are for major releases of the software. 1.0, 2.0, etc.
Then you've got your x.x.0 release. Basically, you subdivide your release schedule according to the major tasks needed to get there. So, for instance, if you're creating a video player, 0.1.0 would be to get something proof-of-concept running some basic video codec. 0.2.0 would be for major GUI additions, 0.3.0 would be for extra codeces, etc. These should adhere to a strict roadmap.
Next, you've got the x.x.x release. So, let's say that you're at the GUI stage above, if you've added the player buttons, you're at 0.1.1 (0.2.0 should be reserved for completion of the GUI stage -- are you writing this down?). A menu means 0.1.2, a status bar, 0.1.3 etc. Once more, this should also adhere strictly to the roadmap.
However, you might run into situations where a bug might creep up, and you want to do an extra release between x.x.x releases. This is where you incorporate the a/b/c etc. releases -- for minor changes that occur between the smallest parts of the roadmap. So, if you had an eject button that wasn't working, and you wanted to fix that before moving onto the menu bar, you release 0.1.1a. Small video glitch that arose because of this? 0.1.1b.
But then there are situations in which, well, if you're like myself and consider CVS use to be a waste of time, you'll need to upload release candidates on the above. Hence, the need for a "_rc" suffix. So, if you're checking to see if the fix you made to the eject button is working, you'll have to upload 0.1.1a_rc. If someone wants to add a small change, you get 0.1.1a_rc2, and so on. You might find it easier to add the initials of the developer just so you know who is doing what. So, a 0.1.1a_rc2_fg might not be out of the question.
(By the way, it's a good time to mention that it's best to have any project you're working on include the year that it was started. Why? Just because. Trust me. With all the projects out there right now anyway, we're starting to have to recycle names. So anyway, we're working on vid2004-0.1.1a_rc2_fg at this point.)
Now, and most developers will agree with me on this, every now and then you're going to get sick of the roadmap and want to deviate from it. Maybe add a feature or something ahead of time, just because you find that more motivating than doing extra testing on some module that's probably going to be obsolete by version 0.3.4a_rc3_fg_rt anyway. For these special instances, a descriptive "_plus" is in order.
If you want to see this versioning system in action, check out the latest release of my own project: dml2xml2004-0.4.12aq_plus_rc3.5_a_mdc_ls.tar.gz.
What? Too confusing you say? Just try it. I've found that all three users of my project have no trouble following this extremely clear numbering system.
Linus only wants to put security patches and patches to bugs which cause a kernel hang or oops or compile failure to get into the 2.6.x.N patches:
Andres also patches things that are plain broken, e.g. "sound doesn't work any more". By the law Linus established above, those kind of patches are forbidden to go into 2.6.x.N.
So the 2.6.x.N patches are extremely minimalistic. They are not sufficient for the average joe who wants to run a vanilla kernel. Those of us who want to run a vanilla kernel (with official patchset) and maybe some self chosen patches still need the -as patches badly! There are many people out there who are their own kernel distributors (i.e. have their own personal patchset and want to apply it to the latest stable kernel.) It does not make sense that thousands of kernel distributors are all trying to do the job Andres does now for all of them officially.
So I hope Andres will keep up with his good work.
I think Linus is very right that it will create a lot of headache for a lot of well-meaning people. It will also create a bunch of little dictators whose mark in Linux history will be more important to them than the continual growth and evolution of the one main kernel progression.
I think instead, it is better to identify any kernel branch by the maintainer or distribution it comes from... pretty much as it already is. When I first started using Linux, I thought nothing of compiling a new kernel and getting things all tweaked out, installing patches and stuff like that. But lately, I see value in following structure in systems such as seeking out RPMs rather than compiling new things. It is far more simple and a lot less frustrating at times trying to keep up with my own set of kernel patches. (Oh, I cannot upgrade to the newest kernel because the So-n-so patch hasn't been updated yet) While the same is true or even slightly worse when it comes to RPM dependency, there is at least some structure and predictability to be found.
I predict that the change will be short lived as it will be found that people will become frustrated with keeping up with all these kernel revisions.
This was fixed recently in 2.6.11
1) Some people might suggest that it's a good idea to put the md5 sum in the version. I couldn't agree more. In these days of rip-offs and trojans, you can't be too careful. I haven't been doing this with dml2xml2004 just yet, but it should become standard in one of the upcoming 3 1/2 releases.
2) Others might think that based on the way debian does things, you might want to put "stable" or "unstable". With all due respect to the folks at debian, I personally find this overkill.
or do I take a chance and mangle my current stuff? hello 2005 calling!!!
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
You have a girlfriend, ha, that's a good one. Man keep those joke commin'!
$
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!"
Honestly, the 2.6 series has been one of the worst, most unstable "production" series kernels ever. Now we we're changing the numbering scheme AGAIN? I'm sorry, but it feels like this project doesn't know what it's doing. What a mess!
Their goal is to write a complete operating system in Java.
So you're saying that OpenBSD isn't dead, but that it will probably not procreate after it becomes legal for it to marry a same-sex operating system?
Because he proposed (or accepted a proposed) numbering scheme? One that merely uses all the same techniques everyone else has always used (bugfixes get a .X added). One we don't even know is going to work well, let alone solve the problems of the current system?
It'd be one thing if you said this in a year after all this went really smoothly.
Can't the current version of the Kernel always be called 1.0 with future verions called 2.0 depending on how many revisions into the future they are and, conversly, have past verions called minus x.y.z depending on how far in the past they are??
So that everyone knows that the current stable version of the Kernel is 1.0 while any number plus 1 is alway a beta verions and any number minus one is always a past verion??.
Or better yet have the kernel alway at 0 with a minus being past version and a plus being a beta - with the unfortunate consequence of sounding a bit communist.
IMHO - This linear progression of version numbers is stupid; since, it implies an end to development - being; not a realistic paradigm for an open-source effort (since it is always an ongoing effort and as such best represented by a curve), While a commerical project, as a counter example, has to be finished by a certian date (even if that date is constantly pushed back - hense being the orginal reason for using version's). And the, obvious, problem of running out of version numbers like Apple have done with OSX. Or Skipping verion numbers just to be a version ahead or equal to another projuct, like Netscape did. Or just giving up and using dates with funny code names.
Just a thought...
Was your naming convention inspired by tla (Tom Lord's Arch)?
a inline--0.1/ for the 0.1 version of the trunk of project "foo" as developed in 2005. Version 0.33 of the experimental gui branch would be {archives}/2005-foo/2005-foo--expgui/2005-foo-expg ui--0.33/
etc.
There, you get {archives}/2005-foo/2005-foo--mainline/2005-foo-m
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?
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.
I have the same philosophy regarding kernel stability, yet I've been running comping and installing 2.6, in the manner you describe, since 2.6.0, and have had no issues at all. No patches, purely the major 2.6 releases.
If you aren't running it, and aren't even trying to, what criteria are you using to judge that 2.6 isn't stable enough for you ?
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
If you give your nuts a good thwack, you'll find those kernels are equally unstable.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
+1 old school reference
Any given 2.6.x.y tree is going to be stopped as soon as 2.6.x+1 comes out. If there's enough spacing between the 2.6.xs it will work, but we could have the same situation as now when there are pretty much no stable 2.6 kernels because there are new features being introduced before all the bugs have been squashed. I think there should be separate maintainers for each 2.6.x.y and they should carry on for as long as it takes until that version is stable.
I am trolling
I assume by update process, you want a button you can click which upgrades you from one kernel version to the next?
The kernel doesn't need an update function. That is the responsibility of the OS. I think most (all?) OS's provide an update function for the kernel.
What are you using?
I'll probably be modded down for this...
What is with people. Most open source projects seem to be scared of the number 1 so every piece of software is 0.x.y.z now the kernel people have become afraid of 3 (or maybe 7) either way this is just silly. I can see it now, in twenty years time we will be up to 2.9.9.9.9.3.8.1 because nobody will take the plunge and call it 3. At least the emacs people got a grip and just dropped the 0.
I used to have a better sig but it broke.
See this.
Seriously. A 4-tuple version number? Geez. Yes, okay for an internal CVS version reference, NOT okay for a release.
I always maintain two trees with COMPLETELY INDEPENDENT integer version numbers. For a given tree, name the tree stable or unstable, and just freaking use an increasing integer sequence. Upgrade problems between stable versions are treated as bugs (documented migration processes can be considered bugfixes). End users only ever need to track "stable".
So - gronky-stable-1, gronky-stable-2, gronky-stable-3
gronky-unstable-34, gronky-unstable-35, gronky-unstable-36
I've reached the conclusion classification is one of the biggest wastes of time. We spend more time deciding how to nest folders within folders within folders, classifying people by numbers and race and social bracket, and now giving meaning to digits in a kernel number.
Why?
Who really cares if a kernel is a major rewrite or not? What's wrong with a single number? In theory you would have development kernels labelled with a timestamp and then only release the stable ones publicly with a regular version.
kernel 0
kernel 1
kernel 2
etc.
The strange numbering schemes and now the stupid debates over how to re-number future kernels is such a waste of time! Linus and friends could actually be fixing the 2.6.x CD burning fiasco instead.
well, i'm not a big fan of prescriptive labeling in general.
I'm trying to think of how many potential 'stable' branched versions there will end up being
- mmx
2.6.x
2.6.x.y
2.6.x-rcx
2.6.x-mmx
2.6.x-rcx
2.6.x-as
2.6.x-gk
2.6.x-ac
Personally, I think that is ludicrously too many branches to have co ordinated development done.
In my mind and I accept I may be _mad_, it would seem to make sense to have a
release, stable and testing branch... and that's it.
I _thought_ that 2.6.x was supposed to be 'stable' and that -mm was supposed to be the equivalent of 2.7... but, now it looks as if 2.6.x will be a kind of 'beta' stable... with 2.6.x.y being the 'real' stable branch.
But, then there are all the other little patchsets from -** to contend with, also...
I think the versoning model is becoming highly unwieldly.... which is sad, because I consider myself a Linux zealot... so I don't like coming to this conclusion..
I hope I'm wrong.
o/~ Join us now and share the software
That was the parent's joke you fucking moron.
The kernel is a small (but important part) of a working and usable Operating System. But I assume from your username that you already knew that, and that your question is just pedantic.
...)? If not, I will continue to use 'Operating System'.
If you are only talking about Linux, change 'OS' to 'distribution' and my comment should make more sense.
Confusion over what an Operating System is and what a kernel is causes many of the arguments between Linux and Windows fanatics, when really they are agreeing, but using different terminology.
http://en.wikipedia.org/wiki/Operating_system discusses the different meanings of 'Operating System'.
Can you suggest a better phrase than 'OS' to refer to a working, usable system, consisting of a kernel, shell and applications, and which applies both to Linux and other 'Operating Systems' (Windows, Mac OS,
I'll probably be modded down for this...
Yeah, I remember hearing about this AJD5000 version, this one is the ID 10-T release.
You can't handle the truth.
Erm... when I do something like 1.x to 1.x.y, it means a branch version.
I used to do 1.x to 1.x.y meaning that it was a small increment, until I had to fix bugs in previous releases and ended up with 1.x.y.z. This is so impractical so I scrapped the whole concept.
1.x.y means a branch. That's it.
Is this how it works with the Linux kernel development?
Y
Maybe now is the time to drop the leading "2." in the kernel release number, as Sun did with Solaris after 2.6...
, rather a new method of creating frozen (bugfix only) kernels. IMHO it's a good idea, but I do have two questions:
1. Who's going to do it ? (ok that's redundant).
2. How long would they keep a frozen kernel updated ? You have to come up with some way to mark a final 2.x.y.z to show that it's the last of that line, and it's no longer maintained. Maybe have 2.x.y.finish, or 2.x.y.dead ? I feel you gotta draw the line somewhere, cause there won't be enough people to do it.
bye, krajo
Learn to separate truth from illusion. Because in this world, it's the hardest thing to do.
No, I'm not kidding. I am surprised nobody brought this up but I'm tired of recompiling and trying to make all the odd things work (binary drivers from ATI/NVidia as well). Why can't I compile a driver once and just use it after that with each successive kernel? It works for Mac OS X. Drivers compiled for 10.1 work fine with 10.3, don't they? Before I get flamed to death I'll say that Linux needs more modularity and flexibility with drivers. Why is it that all the drivers for every odd piece of hardware are bundled with each kernel ?
The whole issue is around stability. If you mark a particular kernel tree as "stable" and apply only security and other "trivial" patches, people will loudly complain if something breaks.
To be able to call something "stable" you must test it, and test it A LOT. Testing a Linux kernel is not a trivial thing as it can run in a myriad of kernel configurations and on zillions of hardware configurations. So only the users can test it, it's just too much for the developers. But users won't test an unstable kernel.
So whenever you release a kernel as "stable" then the real testing will only begin!
IMHO maintenance of a "stable" tree should be left to the distributions. Almost all of them already roll their own kernels. And some have certified hardware they use to thoroughly test the beast before releasing it to the public.
> Now back in my day, kernels were only found in nuts.
No corn back then?
I was making a "generalization"; a general but personal opinion based on a number of events I had witnessed in the past, and with the manner, seen in the linked article, in which the parallel tracks / X.X.X.X discussion was managed being used as a specific example as partial justification for that opinion.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
The Mac's version numbering system isn't quite as wonderful a model as Apache's APR or some other better adherent to the Major.Minor.Patch version numbering scheme. When you start mixing end user expectations and marketing dictives with the numbers you'll wind up with a confusing system. Mac OS X may have started with sane motives, but it's started mixing policy with numbering and that is starting to cause erroneous expectations and possibly confusion down the line.
The first integer (the major release number) is about incompatibility. Data structures, file formats, programs, plug-ins, and hardware are all possibilities. Other things have been added or stabilized, but it's only with the major release number changing does a user have to worry about converting all of his data or find that programs have stopped working. 10.0.0 was an unexpectedly major change from 9.x. for many users. Incompatability infuriated the Mac marketplace. Line endings in text files. International support standards. Font libraries. Disk formatting schemes. Whole classes of programs that stopped working. The end of extensions and control panels. This scale of "incompatibility" could not be hinted at again in future releases. As a result you won't see that first version number change for marketing reasons for a long time to come.
Originally, when the minor revision number changed the end user might have some new functionality, speed increases, or new improvement possibilities to take advantage of, but barring unexpected stability issues, you don't need to worry about backward compatability issues. It is important to pay attention to forward compatability issues if you're looking to install new software or make changes to what you have, your old stuff will still work but lusting after new programs may mean you need to upgrade to a newer version. When Puma (v 10.1.x) came out, there were major improvements, but other than some inadvertant bugs no compatibility issues. It was a free upgrade and many say it was significantly improved to be the first usable version of Mac OS X. Unfortunately that didn't continue to hold. Upgrading the minor revision number was a postive thing in terms of market expectations, just as the major number meant icky problems with incompatibility and lower expectations. With Jaguar (10.2.x) and Panther (10.3.x) Apple has been using the second number as "major release" number where they'll change backward compatibility and now it's even more obvious since Apple was now marketing and charging for these minor revision number upgrades in just as big a spectacle as the upgrades to Mac OS 7 and 8 and 9 before. (though there use of older version numbers pre-OS X had even more marketing influence).
When the third number (the patch number) changes that was only supposed to say that the set of bugs and stability of the version has changed. Whether customers and developers have found them or not, a release has a set of bugs and errors. The patch number simply says that this set has changed. Hopefully for the better, but making changes can sometimes cause things to become more unstable. No features should be intentionally added or removed. During the release of Cougar (10.0.x) and Puma (10.1.x) there were some major bugs and fixes would often bring increases in functionality when a whole technology or sub-system started working or had huge speed boosts. Now the third number says nothing about bugs and stability but due to marketing use of the first and second numbers has become the feature release number.
So what happened to that third number as a marker of the bugs and stability? This is now pushed down into the Build number. Do 9 out of 10 Mac users know what the build number is or how to find it? Click on the version number in the "About This Mac" dialog box (or look at the System Profiler app). This probably isn't a bad decision on the part of marketing: "Obfuscate the level of instability" but it does make it harder for support people to diagnos
Then you've got your x.x.0 release. Basically, you subdivide your release schedule according to the major tasks needed to get there. So, for instance, if you're creating a video player, 0.1.0 would be to get something proof-of-concept running some basic video codec. 0.2.0 would be for major GUI additions, 0.3.0 would be for extra codeces, etc. These should adhere to a strict roadmap.
Next, you've got the x.x.x release. So, let's say that you're at the GUI stage above, if you've added the player buttons, you're at 0.1.1 (0.2.0 should be reserved for completion of the GUI stage -- are you writing this down?). A menu means 0.1.2, a status bar, 0.1.3 etc. Once more, this should also adhere strictly to the roadmap.
However, you might run into situations where a bug might creep up, and you want to do an extra release between x.x.x releases. This is where you incorporate the a/b/c etc. releases -- for minor changes that occur between the smallest parts of the roadmap. So, if you had an eject button that wasn't working, and you wanted to fix that before moving onto the menu bar, you release 0.1.1a. Small video glitch that arose because of this? 0.1.1b.
This sounds all well and good for development pushing toward a major release, but what about changes/enhancements beyond 1.0? What's a 1.x, and what's a 1.x.y in this case? When the main features are already in place, it's not as clear what's a feature vs. an enhancement of a feature.
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
28 day instability occurs once a month for y chromosomes, I mean kernels.
Organization: alphabetical, sometimes numerical or messy
I'm currently adminning several Linux boxes that we keep pretty current: they're running the 2.6.10 kernel.
Yes, that's right. The kernel version numbers can get bigger than nine.
Also, there's no reason to go to three: have you read about the version numbers? It goes Major.Minor.Revision.
Have you ever run a 1.x.y kernel? It's, shall we say,... slightly different.
In a massive, let's-rewrite-half-the-operating-system kind of way.
Have you ever run 2.4.x and 2.6.y close enough to tell the difference? It's about the minor changes (thus, minor version number change); mostly feature enhancements. Some extremely cool stuff, but nothing to get too excited over.
Revision used to be what Linus is moving to two numbers. I don't agree with the change, but then I haven't read the article yet. Considering this man is slightly more intelligent than I, I'm pretty sure that by the end of the article, I'll agree with him.
On that note, a lot of open source programs DO have a problem with moving the major version number, because they haven't defined when it should change. You get programs that say "it'll be 1.0 when it's FINISHED," and if you're a coder, you know that it's hard to say when you're really finished with anything - always a little more feature creep that wants out.
People should hit 1.0 when the required functionality is there and works. Look at Firefox. Don't look at Google's services...
They seem really scared to leave beta with anything...
I [may] disapprove of what you say, but I will defend to the death your right to say it.
10.0.0 was an unexpectedly major change from 9.x. for many users.
For what it's worth, I have some packing list somewhere that lists the contents as "Mac OS X 1.0," as opposed to "Mac OS X 10.0."
With Jaguar (10.2.x) and Panther (10.3.x) Apple has been using the second number as "major release" number where they'll change backward compatibility
Not sure I follow here. 10.2 and 10.3 are entirely backwards-compatible with 10.0 and 10.1. There is new API in each 10.x release, however.
So what happened to that third number as a marker of the bugs and stability?
This is very much still the case. I'm surprised you even bring it up. 10.3.8 is a bug fix release. 10.4 (Tiger) will be a feature release.
This is now pushed down into the Build number. Do 9 out of 10 Mac users know what the build number is or how to find it?
I'm not sure what you mean by this, unless you're referring to the occassional security fixes?
Apple hasn't had great use of version numbers in the past, but I do hope that if they do ever take the opportunity to revise the major version number that they will also take the opportunity to remove the marketing influence on the Minor and Patch numbers in the version numbering scheme.
It doesn't seem like that big of a problem to me. Take 10.3.8.
10 = signifies difference from Mac OS 9 branch. This could probably be 1 instead. Marketing had a hand here, as you say.
3 = the major feature release number, Panther
8 = the minor version number, or "patch level" if you want to think of it that way. There are rarely features introduced at this level. Any that are introduced tend to address a usability bug.
- Scott
Scott Stevenson
Tree House Ideas
From my experience they don't just dump every patch into the 2.6 tree. That's what the -mm tree is for; that's the real mass. Take a look at reiserfs4, for example; even after Namesys's own QA process, it still hasn't made it into the main tree.
There is a difference between new features which add functionality to the old ones, and major changes that break compatibility. Besides, for mission-critical systems you would never use something recently released, even if it was tested vigorously; you would wait until it worked in the real world for a while. That's why you run something like Debian stable, which uses two-year-old+ software with all the latest security fixes; very stable, very tested, very slow release cycles (several years).
Anton Markov
*** Linux - May the source be with you! ***
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.