Slashdot Mirror
Linux Kernel 3.1 RC 2 Released
sfcrazy writes "Linus Torvalds has announced the release of Linux kernel 3.1 rc2. He said '300+ commits for -rc2 is good, but please make me even happier for -rc3 by ONLY sending me real fixes. Think of it as "fairly late in the -rc series," because I really want to compensate for the merge window being fairly chaotic.'"
I think he's got mozilla disease. 10 year at 2.6, then 3.0, now 3.1.
Looks like a party at the end of that submission.
What's with all of these software projects, especially open source ones, going fucking stupid with version numbers all of a sudden?
We get a new major version of Chrome every few weeks. Mozilla, apparently being unable to act individually, have decided to imitate Chrome as best as they can. Of course, they manage to fuck it up like they usually do, and now major Firefox releases are outdated mere weeks after they were initially released.
Now we see the same thing happening to the Linux kernel.
At least we have sensible projects like FreeBSD and Python, which only increment the major version number when there's a good reason to. Hopefully these other projects come to their senses soon enough, and return to version numbers that reflect actual major feature changes. Incrementing the version number for no good reason just causes confusion.
Will the kernel die with him ?? Just wandering !!
Problem solved.
We now return you to your discussion of version 322a8b034003c0d46d39af85bf24fee27b902f48, currently in progress...
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
What's with all the slashdot users recently, going fucking stupid about version numbering? Who cares what the versions are called: 3.10, 3.11.30 3.A03930. As long as the software works and the users (developers and end users alike) are able to interact with the software, what's the big issue?
Linux 2.6.1 was released only three weeks after 2.6.0. By my count there were 10 releases in 2004, and then 4-5 releases every year after that. This works out okay for the kernel since the "official" kernel is treated as the beta kernel for most distributions, which update less frequently and with more testing, and about once a year, they designate a kernel for long-term support, and it receives bug patches.
Firefox releases are user facing, however and I have yet to hear any plan for long term support of versions in this new scheme. Both those factors make it more problematic IMHO.
Secondly, the Linux version bump is a good thing. The first number in the version was meaningless anyway these days, so merging it with the second so it only has 3 parts, not 4 is just good house keeping. I would be fine with Firefox doing the same thing; many of their .5 releases in the past have had enough new features to justify a .0 release, and then the point releases could be reserved for bug-fixes only.
After a change, I'm either going to get a few "why don't we have the latest patches" or why did you install the latest major change without the proper approval. Teaching upper management is not easy and I've got a dozen reading summary reports daily and "know" what the monthly patch changes "look like"
FFS this site is getting pathetic with the whining about version numbers. Does it really matter that damned much if it's 2.26.41, or 3.1? Does it make any difference if it's called Firefox 3.8 or 6.0? I tell you, I wish I could get back to a place in my life where my biggest issue was worrying about what the version number on open source projects was.
I hate to break it to you, but there are many of us here who work professionally in the IT field. We don't have the luxury of being students such as yourself.
When you have to manage 80,000 or more desktops and servers, spread around the world, things like version numbers become very important. It's not so much the numbers themselves, but the expectations and facts that they should convey.
Responsibly using version numbers lets the software developers convey to us, the software administrators and users, important knowledge about the software they have created, and how it relates to earlier and future releases.
A major version number increase should signify massive changes. It should indicate to us that we should disregard any previous knowledge we have, and learn the software product from scratch. It indicates to us that we may need to provide extra assistance to the employees using the software we're tasked with administering. Do you get the idea? Are you beginning to follow what the real world is like? Yeah, it's not like what your computer science professors may have caused you to believe.
When projects start changing major version numbers without good reason, it makes us unsure about such projects. We lose the ability to predict how much of an impact upgrading will have, for instance. Worse, it gets executives asking questions. Even though Linux 3.0 is only slightly different from the last 2.6.39, the major version number jump makes some executives worry unnecessarily. They start to think that what's nothing more than a routine upgrade is more risky than it is.
I have colleagues in IT who have experienced similar problems with the recent Firefox debacle. They have to deal with users who don't want to upgrade from Firefox 4 to Firefox 5, thinking there will be major changes and adjustments, while there's almost no noticeable difference between the two "major" releases!
It hurts the adoption and acceptance of open source software when major projects start playing dumbass games like these with their version numbers. It does indeed create the so-called "FUD" for those who make decisions regarding the use of open source software.
ok to all the drama queens discussing that they changed the version numbers and whatnot, just remember to use kernels bigger than whatever you use now if available... who cares if they jump versions on increments of 0.00000001 or 1000000000 ... geez, if he wanted this could be kernel 398828811.000000002 and you would still use it and like it !
I'm waiting for the 3.11 release, just for shits and giggles.
then with 2 million of him linux really takes off
Okay. Cool. We get it. But you don't manage 80k Linux desktops. Get over yourself.
Did a quick scan, one of them is: "Update e-mail address of Jarkko Nikula". Also noted lots of work related to the gma500 driver lately, thanks Alan Cox.
Or perhaps ... just perhaps ... the many of you that work professionally in the IT field got lazy. Really, really lazy. Rather than actually evaluating the merits of a new software release for yourselves (as one would expect an actual professional to do), you lazily shirked your responsibility and expected someone else to do your job for you. For software you very likely didn't pay for, because it was provided to you free of charge, with full source code, access to the entire history of the code repository, development mailing lists, a detailed changelog etc. It doesn't get more transparent than this.
Quit whining. Seriously.
It sounds to me like the GP and his colleagues are trying damn hard to perform that evaluation themselves, but that these stupid version numbering games are preventing that from happening as easily as it should.
That post is full of quotes like:
Responsibly using version numbers lets the software developers convey to us, the software administrators and users, important knowledge about the software they have created, and how it relates to earlier and future releases.
A major version number increase should signify massive changes.
We lose the ability to predict how much of an impact upgrading will have, for instance.
They start to think that what's nothing more than a routine upgrade is more risky than it is.
That's not "shirking responsibility". That's due diligence. They're trying to judge the impact that upgrades will have, but doing a poor job using version numbers interferes with their evaluations.
If anyone isn't behaving professionally, it's those who are improperly using version numbers.
Obviously some are not as experienced as they pretend. Version numbering schemes vary wildly sometimes within the same product or project over time. If the above extremely condescending poster actually had the sort of experience they pretend they have they would know that versioning schemes vary very widely from place to place no matter what we would like to see as a standard.
Nearly every time somebody brings up "the real world" it's a sign they live in a insultated bubble themselves. A cube in a city office building is "the real world"?
Sorry kid, being a year or two out of school does not give you the right to bully the younger kids.
The procedures you're talking about aren't there for shits and giggles. They're in place to ensure that upgrades go smoothly, and that critical systems continue to function properly.
We aren't talking about some shitty PHP blog or some lousy Ruby on Rails site you made for your neighborhood hairdresser. We're talking about systems that are directly involved with allowing billions upon billions of dollars worth of business to occur each day. We're talking about real software systems here.
You are so ignorant you must be another student. Not the grand parent but some of us *do* pay for open source software. Out side of academia most people don't have the liberty of seat of your pants forum and IRC support when shit goes seriously wrong. Got a linux kernel bug? Your Redhat support contract may (if its serious enough) get Alan Cox on the phone (did some years ago, I realize he has now left Redhat). Got a table that is being completely mis optimized? Your Maria contract will get you Monty. I could go on and on. Open source software isn't just about free software for kids who think patents are yucky and everything should be free, its about quality software through open community development. Version numbers matter, they matter to executives, they matter to ignorant users who fear upgrades. They matter to those who pay those support bills and vendor contracts that fund open source software development.
-- Don't have 80k Linux desktops, but I do have 35k and growing Linux servers
I've got over 30 years experience working with various mission-critical systems in a number of industries. What the grandparent wrote is absolutely true, and what you've written in very short-sighted. When I compare the very real scenarios and problems that he describes, versus the idle speculation and insults that you've spouted out, the grandparent's post will win every time. What if you try replying again, this time arguing against the actual points in that comment, rather than tossing out one feeble ad hominem after another?
"fairly chaotic"
Pretty much sums up Linux kernel development. It's a wonder it's as good as it is (and it's damn good).
Care to point out where that comment says anything about "80k Linux desktops"?
It merely mentions "80,000 or more desktops and servers". If it's like most enterprises, it's probably a terrible mix of various versions of Windows, Mac OS X, Linux, HP-UX, Solaris, AiX, and maybe even legacy mainframe and microcomputer systems.
Managing a heterogeneous infrastructure like that does take many resources. Any confusion brought about by bad version numbering will have an impact. Work a few years in I.T. and you'll begin to see what he's talking about. He doesn't have to "get over" anything. It's children like you who need to realize how things actually work.
Question:
Why is it easier to manage them when theres an extra, superfluous, unchanging "6" in between the major and minor version numbers?
I mean, linux was at 2.6 for like 8 years. And the time difference between Linux 1.0.0 and 1.2.0 was a measly 1 year. Linus apparently concluded that hanging onto a number in the middle for several years makes no sense (which it doesnt), and that it makes even less sense to have the major version contain 2 numbers punctuated by a dot.
He has reverted to the exact same system that most other software has used for ages, MAJOR.minor. What is your beef?
Those procedures are in place because the vast majority of IT workers are simpering script-monkey morons laboring under bureaucracy put in place by self-important CYA management types who wouldn't know how to make an actual decision to save their kids' lives.
There just isn't enough actual talent to go around. You work in a system designed (poorly) to compensate for that fact. The fact that you posted AC tells me you already know to be ashamed of it.
Consider some examples on say ten different products/projects from various sources and you will see exactly what I mean if you have somehow managed to forget in those thirty years. Version numbering is all over the place whether we like it or not and it depends on trends, whims and changes of management more than any sort of standard.
As for "ad hominem", you are misusing it that term badly since it was instead a case of pointing out "a pot calling a kettle black". The GP post above was a pathetic attempt at bullying another poster over an issue they appeared to have no grasp of themselves - the final line of my post was to make that very clear to the casual readers here that may not have bothered to fully read or comprehend the lines above it.
Yeah the GP has a point when it comes to what Firefox has been doing but the new versioning for the Linux kernel isn't going down that route. As the parent said, it's just merging the first two numbers and there's no better time to do that then the next "major version" number switch (which would otherwise have been "2.8"). Even better in this case to start it at 3.0. So in reality this actually is a GOOD thing in terms of what the GP was posting about. It's a very clear line both in terms of when this change is taking place (3.x versus 2.6.x) and simplifies things going into the future.
It will be hard not to take this as negative, but I really mean it as an inquisitive question.
Shouldn't IT be looking at what's changing between patches and not worrying about version numbers? Also testing patches?
I've worked in IT, but not the part for the general day-to-day work, just the hard to solve problems. I know the other people at my work would test all Windows patches before pushing live.
Again, I haven't ever had to worry about these things, so I find it curious about "version numbers" being and issue.
In the past, I've had to explain to managers the difference between Solaris 7, Solaris 2.7, and SunOS 5.7 to PHB types.
Numbering schemes can be arbitrary, but it would be nice to see some consistency across the board. Major number means groundbreaking features and potentially face-shattering bugs. Minor numbers mean some new features added or revised, or some depreciated stuff dropped. Revisions mean bug fixes, security updates, etc.
I just don't get version number inflation. Even Windows doesn't do this on the internal level (do a "ver" for example.) Of course, the names of Windows can't really be put in order other than 3.11, 95, and 2000, but the Windows kernel has been relatively orderly and sane when it comes to updates on it.
This confuses me. Why would executives care about the Linux kernels version number?
Surely you are using Foobar Enterprise Linux 5.x and whatever kernel they are supporting as stable? And you and your executives only need to worry about big disruptive changes when you move to Foobar EL 6.0?
Isn't that the whole point of distros and support contracts?
Would your executives care what the NT Kernel version number is, or would they just look at the actual Windows version being released (2000, XP, Vista, 7 etc)?
Obviously that Windows versioning example is so much more helpful than these "dumbass games" (your words) the open source projects are playing. How about both Windows and SQL Server have had versions numbered 7 and 2000, but they both came out in a very different sequence.
Or when Solaris/SunOS dropped the first digit from its version number. Or how about Java? We have 1.6.0 meaning Java 6 or vice versa in different contexts - JRE vs JDK etc. And 1.2 being known as Java2, then subsequent versions being known as J2SE 1.3, 1.4 (is this still Java2?), then J2SE 5.0 (huh? Is this Java 2 still or Java 5? The internal bits are still 1.5.0_x), then Java SE 6 (no .0 anymore, and inside it is still 1.6.0_x) etc. Yikes - no wonder enterprises stayed away from Java.
Your company must really struggle with those kind of games going on with proprietary or 'enterprise' software version numbers. It makes most open source projects look far more meaningful. I'm not sure how this is an example of the importance version numbers are to an enterprise.
Anyway, the new Linux versioning is correcting the misleading numbering the previous system had. Each new release was in no way a very minor patch on the 2.6.0 release. 2.6.29 bears very little resemblance to 2.6.0, and large chunks of it have been rewritten in that time. So the kernel is moving towards the kind of system you want - not away from it.
I'd suggest that using version numbers for such a thing is an inherently poor way of doing it. I can't believe that someone in 'enterprise' would upgrade to a new Linux kernel without appropriate testing and fallback positions even if that kernel update was a same-version distro update that only contained a few backported security fixes. You don't look at a version number and guess, you assume an update will fuck things up until testing shows otherwise.
I think Mozilla can be faulted for not providing security fixes for relatively recent releases but I don't think their version numbering scheme matters at all.
The kernel version number matters even less. Most people will only come across a kernel version change when updating to a new distro version at which time the quantity of change must require a significant amount of testing even from lazy admins.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Extremely good points...except for the fact that almost no commercial software versions this way. Let's see....
Endnote 8 9 X X1 X2 X3 X4 X5 (all new major versions every year with mostly insignificant changes)
Office 2003 2007 2010 2011 (the 2003 -> 2007 was a pretty big UI bump, but otherwise mostly the same)
Photoshop CS3 CS4 CS5 (some significant new features for sure, but not "learn the software product from scratch")
Those are some examples I can come up with in five minutes, but there are lots more. Let's face it, version numbers are for marketing. If you want to actually know something about the software, you have to read the changelogs and/or install it on a pilot box.
If those procedures involve people making guesses based on version numbers then they are shitty procedures.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
He can start telling us kids (heh) to grow up when he manages 80k Linux desktops...
If you aren't going to have some consistency in terms of version numbering, why bother with point releases at all? If shit is just going to be a "whatever" situation, then why have a divided number? Just have a single number that gets incremented each time you release an update, for any reason. That'll work if you what to have an indicator of what is newer, but don't want to bother deciding what kind of release it is.
If you are going to do point releases, then make that shit mean something. Have some consistency as to what qualifies as what. It is up to you how big a change qualifies for various point releases, but whatever you decide, stick with it so that people can use them and understand them.
I'll give you a couple examples of it done right:
1) World of Warcraft. Each time a paid-for expansion comes out, that is a major version number, since they often make large changes to the function of the game. So currently it is on 4.X, meaning that 3 paid expansions have been released. The next numbers indicate patches that bring new content and/or major changes, but are not part of an expansion. So 4.2 means that since the 3rd expansion, there has been two major content updates. The final number, after another point, is for minor patches. Mostly just bug fixes and balance tweaks. Also sometimes you will get a letter release like 3.0.8a, that signifies a hotfix to the previous patch.
It is extremely easy to tell what kind of a change one can expect with that system, and it has been quite consistent. So the gamers know if "5.0" is coming out, that means huge changes in preparation for a new paid expansion. If 4.2.2a is coming out, they know that there will be no real changes, just a hotfix of something messed up in 4.2.2.
2) Windows internal versioning (not the marketing names). There isn't much to Windows versioning since customers want a release that doesn't change all the time. Major version numbers are reserved for big changes, like a rewrite to how the kernel works, new driver models, and so on. The last major version was 6.0, which is Vista and Server 2008. It got a major increment because of substantial changes to how things worked, like the WDDM graphics model, for example. Point releases are for new, paid, versions that keep the same basic low level as the previous version. Windows 7 and 2008R2 are examples of that, they are 6.1. While they introduce new features, make some changes, and are paid updates, they are fundamentally very similar to the previous versions. Drivers are almost always cross compatible and so on. There are then service packs, which are roll-ups of fixes, but also can introduce new functionality of a greater level than a normal patch.
Patches don't get versioning, because they are independent, you can apply them out of order (unless a given patch happens to require an earlier one) and not apply specific patches if there's a reason to not want a given one.
Again, very easy to tell what you are getting in to. If a new Windows release is a major number change, you can expect that some fundamental changes have been made. You will probably have to look at new drivers and so on so compatibility could be an issue. With a point release changes are more superficial. Good chance if something ran X.0, it'll run X.1 no problems. With Service Packs, it is not a big deal generally, you can expect everything to be the same, and just do a quick test to make sure no problems result with software compatibility.
Both are different in how they go about things (in part because of their different designs and markets) but both share the feature that they are real consistent in what their versioning means. I can look at either and tell what is going on easily, and it has remained consistent for a long time.
In the case of OSes, I really think MS has it right. Deploying a new OS, with big changes, can be a pain in the ass and enterprises are loathe to do it. So, keep big changes infrequent. Don't do a X.0 release unless there are changes to support that, and even then don't do one that often.
Ok, I'll pretty state the obvious. It was already told, but with different words and point of view - as end user, since IANAP (I am NOT a programmer).
1. Yes, software numbering matters. If consistent, it's a great way the end user can have some info about the version without even testing it.
IMHO, it should follow strictly the formula X.Y.Z, where:
* When X changes, it's telling the user - "Code was bleached, interface was throughly rethinked. It's brand new. You'll need to relearn how to use this software."
* When Y changes, it's telling the user - "Here are some small improvements. You'll notice them, but it's the same old software."
* When Z changes, it's telling the user - "You won't notice the difference, it's just some bug fixes."
THIS is what the user expects. [Or at least, what I expect.]
3. "Lets put soem big nunbars for teh marketin cuz ppl liek dem maeks feel moar modern" fever was already WAY BEFORE Mozilla caught it.
Slackware mocked it in 1999, jumping from 4.0 to 7.0. Yeah, 1999. This is as old as floppies, if not even older.
Who started it? I DON'T KNOW. I only know it's both in FOSS and proprietary software. Winamp, Firefox, Chrome, Windows, lots of GNU/Linux distros...
3. Now, about Linux. Obviously, you all noticed that kernels were being released with a #.#.##.## numbering pattern (like, 2.6.33.17).
Changes made from 2.4 to 2.6 were not just improvements, but weren't enough to make a major version.
The third number is a mix of improvements and bug fixes. The fourth is bug fixes that SHOULD be released with the third number.
As I told before, I'm not a programmer. But I've observed that every number in software versions "spawns" branches, except the last one.
Every number spawns branching, Linux included. I remember that 2.4 was STILL being maintained and branching until few time ago!
Does this works? Well, check kernel.org and see how much different kernel versions are being maintained at the same time.
They're reinventing the same wheel, like, 10 times?
Seems like Torvalds is, actually, trying to simplify this whole mess that became maintaining lots and lots and lots of Kernel versions.
If so, great, even 3.0 being almost identical to 2.6. It means less kernel upgrades while, at the same time, quicker improvements - since workforce isn't being wasted reinventing the 10th wheel.
Or Torvalds just got bored of the big numbers and decided to troll us.
Office 2003 2007 2010 2011 (the 2003 -> 2007 was a pretty big UI bump, but otherwise mostly the same)
Internally, version numbers are used:
Office XP = 10.0; Office 2003 = 11.0; Office 2007 = 12.0; Office 2010 = 14.0
There is no Office 13.0 (yes, superstition).
When the copyright term is "forever minus a day", live every day like it's the last.
I rather think the person you are replying to fully realises the importance of not "living by the seat of your pants" when it comes to upgrades. That's why he expresses his shock and alarm at a so-called professional who either takes his cues from the version number or takes his cues from someone in Management who misunderstands the version number. The AC evidently reads (and has time to read and comment on) slashdot, so it's not as if he isn't aware of the change to version numbering of the kernel. If Management or users are disquieted by the notion of an upgrade to another major version then it's his job to set them straight surely? Not to be hen-pecked into remaining on an insecure software version?
More importantly, why do you rely on something as specious, esoteric, and non-standardized as a version number instead of actually doing your job and researching/testing things before you deploy them?
A major version number increase should signify massive changes.
I think you really want the converse-- Massive changes should require a version number change.
You dont have to live like a refugee.
Just curious, how do you guys deal with Window's version system?
Fuck you, buddy.
Right. And by having the source code, scripts written for hundreds of use cases magically check and correct themselves.
The parent *is* right. It helps if the version numbering consistently indicates whats going on. Being lazy and trying to rely on this has means not consuming too much hours for getting things done. And its sad. If i would know that upgrading a linux machine or connecting new versions to a environment is unpredictable in a way which makes me consume too-many extra hours for nothing (instead of using these to check when the real changes arrive), then i would have to recommend Windows or Solaris.
Should i be expecting linux 7 by the end of the year?
If he's Lowe's, Lens Crafters or Taco Bell, just to name a few, he just may. A lot of retail is now using Linux for both POS, back office and servers.
-- I have a private email server in my basement.
No. The reheater system uses the waste heat from the AC to reheat the air back to reasonable indoor temperatures. There is no extra energy needed for heating, in fact less energy will be consumed if the output temperature is higher: The AC condenser will get better cooling and the efficiency will increase.
I understand where you're coming from, but I think it's more applicable to commercial closed-source software which usually justifies a major version upgrade (for which you have to pay) with new and exciting (?) features. IOW, the new features are a hook to get you spend money again for software you've already paid for. The changes have to be drastic otherwise you wouldn't pay, would you?
But free software is different. The changes are more incremental. In a way, it's like evolution. You don't go from ape to human in one step and, tada, it's a whole new species. Instead, small incremental changes add up to something different. The question then is, where do you draw the line?
Free Manning, jail Obama.
Bullshit.
When you manage 80K desktops (or 100s of servers, something that I have experience in), you buy a site license for RHEL/SLES/etc, keeping 99.9% of the distribution intact changing only packages that you really-really-really-really-really need changed;
You then keep using the old really until you really-really-really-really have to upgrade.
I doubt that you grasp how many of my clients/colleges still use RHEL 4.x (!!!!) for both application desktops and servers...
By the time RHEL and SLES release 3.x based distributions, Linux 3.0 will be a memory of the past.
(I would imagine that RHEL 6.2 will include a new version of FF as "technology preview" but will keep FF 3.6.x as the main browser)
- Gilboa
If those procedures involve people making guesses based on version numbers then they are shitty procedures.
Thank you, for putting my exact same thought into words.
Allegedly managing 80k+ machines and relying on textual patterns in version numbering schemes in order to predict/judge/assess the magnitude of any given upgrade is a lethally dangerous combination. Boasting about it in important sounding words makes it even more so.
Perhaps Linus is fed of listening this and has decided to change the versioning in a way more reflective of your expectations. As for Firefox & Chrome, yes I think it's really stupid to bump major versions like this. Perhaps the answer is a major.minor version followed by a datestamp and some form of commitment that the major version is only bumped when new protocols or standards are introduced and minor for new client side functionality.
> A major version number increase should signify massive changes. It should indicate to us that we should disregard any previous knowledge we have, and learn the software product from scratch
You said it: should. But it doesn't, since the eighties at least. So what do we do? skip useful software because of it? That would be even less professional than inflating version numbers.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Wow, "+5, insightful" for pretending IT professionals roll their own kernels or run the 'unstable' branch of $distro on 80,000 desktops or whatever. Slashdot truly has been taken over by gadget freaks and trolls.
It doesn't matter where he is. The OP isn't upgrading kernels, he's upgrading distributions. If his bosses care about kernel version changes, this idiot should be fired for making a mess of their systems.
A consistent bad versioning scheme is still better than an inconsistent versioning scheme.
Open source software isn't just about free software for kids who think patents are yucky and everything should be free
I know that money is not at all important, but in what country/planet do you live?
With a better password who doesn't create the ware anyhow)? You wouldn't install an RC on that many systems. You're also stupid to be managing Linux vs. Windows, because Linux's "large volume management" tools pale in comparison to those in Windows, period.
It is not as if they are ripping anyone off like that manufacturer that charged for System 8 which was only an upgrade of 7.5. Or was it that they went from 8.5 to 9 because they needed the money?
I hate to break it to you, but there are many of us here who work professionally in the IT field.
You're obviously not one of them.
THere was much, much bigger changes between Office 2003, 2007, and 2010 than just a UI bump, that was just the most visible. The Entire plugin structure has radically changed. I worked at a company that used literally hundreds of addins and macros (from tax calculating tools in excel, to enterprise email archiving tools in outlook). The sheer number of tools/scripts/apps that have had to be rewritten is about 10 times the cost of the actual licenses..
What are we going to do tonight Brain?
When you do a company wide deployment you modify an existing distro. The one I used to maintain for AT&T Cable was based on RedHat but it was not redhat by the time we got done with it adding our special parts.
So yes, whoever is in charge of the In house Distro will care greatly about the kernel.
Do not look at laser with remaining good eye.
I hate to nitpick, but I've yet to see anyone in IT actually upgrading a major version of the kernel. This is nearly unheard of except small, specialised Linux-shops. People tend to stick with whatever version came with their current version of Red Hat Enterprise Linux or whatever their vendor is (I'm going to assume RHEL for the rest of this post with little or no loss of generality).
Red Hat may issue small kernel upgrades, but they don't even change the minor kernel version, just the patch level version through the life cycle of that RHEL version. So the only time enterprise server customers update their major kernel versions are when they upgrade their version of RHEL. And even this is rare. The enterprises I've seen will commission a server rack with RHEL already on it and fully configured from their supplier. And they will stick with this until the rack is end of life, only installing service packs and security updates on it.
Because of this, the Linux kernel version matters very little to most enterprise customers. They care more about using an established well tested version of RHEL. I.e. not wanting a new version until it is at least a year old with new bugs ironed out. And the Linux kernel versions matter little to the Linux distributors, because they have all the inside knowledge to whether Linux version 3.1 is a major upgrade or not. This leaves me thinking that the kernel version number actually is actually ONLY relevant to students and hobbyists.
Please correct my reasoning here, because I struggle to see why you find the Linux kernel version so important. Firefox versions, fine, but why the Linux kernel version?
You are so ignorant you must be another student. Not the grand parent but some of us *do* pay for open source software. Out side of academia most people don't have the liberty of seat of your pants forum and IRC support when shit goes seriously wrong. Got a linux kernel bug? Your Redhat support contract may (if its serious enough) get Alan Cox on the phone (did some years ago, I realize he has now left Redhat). Got a table that is being completely mis optimized? Your Maria contract will get you Monty. I could go on and on. Open source software isn't just about free software for kids who think patents are yucky and everything should be free, its about quality software through open community development. Version numbers matter, they matter to executives, they matter to ignorant users who fear upgrades. They matter to those who pay those support bills and vendor contracts that fund open source software development.
-- Don't have 80k Linux desktops, but I do have 35k and growing Linux servers
You give some good examples, but people as paranoid as you will probably be sticking with the stock kernel that comes with the distro anyway, or at the very least, sticking with a stable series (2.6.32.x, 2.6.35.x etc.). When the distro bumps a version number, so does the kernel and if it's a major number, who cares?
Look, the USERS will notice the version number bump and it will make them all puckery, so there is ample reason to be sane with version numbers. Who is more retarded, someone who bumps a version number to get attention like a whore, or someone who wants the version number to mean something? I submit that the answer is you.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The current codename is "Wet Seal".
Extremely good points...except for the fact that almost no commercial software versions this way. Let's see....
Office 2003 2007 2010 2011 (the 2003 -> 2007 was a pretty big UI bump, but otherwise mostly the same)
Not that it completely disputes your point, but I want to point out that Office 2007->2010 brought the ribbon to Outlook, which is definitely a huge change, especially for Exchange-based organizations. It also made Outlook a hell of a lot better with large mailboxes, faster, and have a much smaller memory footprint.
Also, 2011 is the Mac version. 2008->2011 brought the ribbon to Mac, and brought Outlook to Mac to replace Entourage (thank god).
It's hilarious how Slashdot likes to complain about Apple daring to charge for "minor" OS updates (it's only a point release!) but then gets all antsy over Linux moving to a standard major.minor scheme.
"Open source software isn't just about free software for kids who think patents are yucky and everything should be free, its about quality software through open community development."
No, it really is. You just don't realise it because you're more interested in money than ethics.
When projects start changing major version numbers without good reason, it makes us unsure about such projects.
Only for as long as it takes you to get around to reading the changelist. For the amount you're harping on about being a professional, you would be reading the changelist regardless of the version number delta, right?
You shills really shouldn't echo the words of Balmer quite so closely. It tips your hand. Not that we wouldn't know who signs your paychecks anyway.
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
As far as I know, he hasn't actually said that hanging onto a number for years makes no sense. He's only said that he feels its time for a change, and trusts that feeling.
its simple, they dont release a major revision every week
It hurts the adoption and acceptance of open source software when major projects start playing dumbass games like these with their version numbers. It does indeed create the so-called "FUD" for those who make decisions regarding the use of open source software.
Bah.
IT organizations who have the sophistication required to manage their own kernel versions and seriously think about tracking the Linux releases have the sophistication and focus to understand what's really in the releases, regardless of the version numbers. Everyone else just uses the kernel version provided by their distro of choice, so it's the distro version numbers they care about.
Your uber-condescending post is drivel.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
...then i would have to recommend Windows or Solaris.
Because Windows version numbering is so much better... 2000, XP, Vista, 7.
Linus only changed the version scheme, after sticking with the previous one for the 2.6 kernel for seven years. There is no reason to believe he'll change it again in the next few years. Instead of 2.6.x.y it is now 3.x.y. Sure it is a bit of an adjustment, but only a minor one, one which shouldn't take someone competent more than 10 minutes with Google to find and read all they need to know the first time they find out it has changed from 2.6 to 3. And besides if you are running something like Red Hat, you're not likely to be upgrading kernel versions independently of Red Hat releases.
In your 30 years you never even came across Solaris/SunOS or Microsoft Windows and the inconstant version changes that sometimes had major meaning and sometimes not in those? That's two very large examples there without even getting into application space (eg. one application with version numbers, then later initally year, month, minor number (up to 2003.19.1 in 2008 or so where it no longer made any fucking sense), then all products stamped with R5000 and three minor numbers even when it was nothing but rebranding).
Yes, exactly. And often enough in the seven years things were breaking.
FF3.X doesn't have any more support. You're recommending to use a browser with known security holes? Just tell people to use IE6.
Enterprise Linux (E.g. RHEL, SLES, etc) maintain obsolete releases by back porting security fixes.
This is what they do best, and this is the reason why using RHEL and SLES with no support contract should be avoided.
I would suggest you take the time to do some research before posting!
- Gilboa
In some instances a corporation may want to lock-down their configuration and have an "approved software" listing, which can go all the way down to build number in some cases. This is done to maximize the ability for IT to support the employee base and minimize the potential security holes in the network. In this case, any new software added to the approved list must undergo rigorous testing, making sure it only behaves as advertized, doesn't intentionally cause any security risks (or can be mitigated somehow). In environments I've worked in, the move from 2.6.3 to 2.6.4 was seen as trivial and could easily be done, since it was understood that the underlying system didn't change significantly. However, a change from 2.6.38 to 3.0 would be seen as a significant change and could require all the testing and documentation, as well as any approvals to be redone. You may not consider this to be much of a problem, but consider that it took 2-3 years after the release of XP for some corporations to adopt it, and those same corporations are just now considering/testing Windows 7. If you have a 2-year window for approval, and a 6-month major version upgrade, your IT dept is in for a world of hurt.