×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Linux 3.12 Released, Linus Proposes Bug Fix-Only 4.0

timothy posted 1 year,25 days | from the in-time-for-guy-fawkes-day dept.

Operating Systems 274

An anonymous reader writes "Linus Torvalds announced the Linux 3.12 kernel release with a large number of improvements through many subsystems including new EXT4 file-system features, AMD Berlin APU support, a major CPUfreq governor improvement yielding impressive performance boosts for certain hardware/workloads, new drivers, and continued bug-fixing. Linus also took the opportunity to share possible plans for Linux 4.0. He's thinking of tagging Linux 4.0 following the Linux 3.19 release in about one year and is also considering the idea of Linux 4.0 being a release cycle with nothing but bug-fixes. Does Linux really need an entire two-month release cycle with nothing but bug-fixing? It's still to be decided by the kernel developers."

Sorry! There are no comments related to the filter you selected.

features can always be sold as bugfixes (-1)

Anonymous Coward | 1 year,25 days | (#45321793)

e.g., Fix for: need a semi-decent tool for monitoring such-and-such

Bugfix Pause always welcome (5, Insightful)

icebike (68054) | 1 year,25 days | (#45321847)

There have been so many fast and furious features added over the last couple releases, not only to the kernel but also the various and sundry major components (like systemd) that taking a breather isn't going to hurt anything. There is nothing huge waiting in the wings that everyone needs next week.

Take the time to fix everything you can find.

There is balls-to-the-wall competition right now! (5, Funny)

Anonymous Coward | 1 year,25 days | (#45321925)

I don't know how you can honestly say that there's "nothing huge waiting in the wings that everyone needs next week." You must not understand the current operating system market.

THERE IS BALLS TO THE WALL COMPETITION RIGHT NOW!

The moment the Linux community rests on its laurels, even if just to fix some "bugs" that don't even exist, the competition from Windows and OS X will intensify to an extent that we haven't seen in ages.

Look, Windows 8.1 was just released, and it's a game-changer. It makes the Windows 8 stream a viable option for businesses and home users alike. Windows 8.0 was like Vista was; Windows 8.1 is like Windows 7. Windows 8.0 tried some things out, and some of those were mistakes. Windows 8.1 remedies these, and the result is a powerful, usable operating system.

OS X 10.9 Mavericks was just released recently, too. It took what was perhaps the most popular and widely used Unix-like system and made it even more efficient and powerful.

Then there's Linux. There are major changes underway as we speak. The Ubuntu and GNOME 3 communities, which were once among the largest and most appreciated, shat upon the faces of their users, causing them to seek refuge in other distributions and desktop environments. Now we have Wayland on the way, and it's going to bring so much disruption that there may in fact be a civil war of sorts within the Linux community. X is not going to die easily! And then there's LLVM and Clang, which are kicking the living shit out of GCC. In fact, this is a revolution that we haven't seen the likes of in years.

With so much turmoil in the userland software, it's now up to the kernel to pick up the slack. We're going to need to see the kernel team at least double their efforts to make up for the stupidity of the GNOME crew, for example. We're going to need to see a kernel that offers greater power efficiency on modern systems. We need to see a kernel that'll offer even better process and thread scheduling. We'll need to see a kernel that can scale from the smallest cell phones to the largest clusters. We need to see the completion of Btrfs.

Never forget that when it comes to operating systems, the BALLS ARE TO THE WALL!. This is more true today than ever before. The competition is fierce, and prisoners will not be taken. When there is BALLS TO THE WALL competition, everybody involved needs to bring their best. This includes the Linux kernel developers. They need to be the best they've ever been. This is no ordinary situation; this is a BALLS TO THE WALL situation. And don't you ever forget that!

Re:There is balls-to-the-wall competition right no (0)

zippthorne (748122) | 1 year,25 days | (#45321951)

one could argue that Mavericks basically was a "bug fixes" release, though...

Re:There is balls-to-the-wall competition right no (4, Informative)

elfprince13 (1521333) | 1 year,25 days | (#45321985)

Not really. Mavericks did some really cool stuff under the hood. Timer-coalescing, "App Nap", and compressed memory are all pretty big. Take a look at the relevant sections of the Ars review to see what I mean.

RAM Doubler (3, Informative)

tepples (727027) | 1 year,25 days | (#45322085)

I had compressed memory on a Mac nearly two decades ago in the 7.5.x days with Connectix RAM Doubler. Did OS X just get native compressed memory after Connectix's patents ran out?

Compcache/ZRAM (5, Informative)

Jody Bruchon (3404363) | 1 year,25 days | (#45322141)

Linux has had compressed memory for quite some time, originally as Compcache and now as ZRAM. I have managed to use it on low-memory systems even today to get more work done faster. I'm not saying this to attack OS X, but rather to point out that equivalents already do exist. Also, I remember when a company (Quarterdeck?) offered a product for DOS/Windows called "RAM Doubler" that did the same kind of thing.

Re:Compcache/ZRAM (-1)

Anonymous Coward | 1 year,25 days | (#45322435)

Linux has had compressed memory for quite some time, originally as Compcache and now as ZRAM. I have managed to use it on low-memory systems even today to get more work done faster. I'm not saying this to attack OS X, but rather to point out that equivalents already do exist. Also, I remember when a company (Quarterdeck?) offered a product for DOS/Windows called "RAM Doubler" that did the same kind of thing.

It's like every time someone comes out and says they had a great steak dinner last night, someone else has to go on about how you can do that with chicken too... as if it matters.

Re:There is balls-to-the-wall competition right no (1)

Anonymous Coward | 1 year,25 days | (#45321991)

Nobody could seriously argue that. Mavericks is a major release adding major functionality. Sure, there are bug fixes (just like with every other release beyond the first), but they're minor compared to the new functionality.

The improved multi-display support is absolutely massive in terms of importance. The new Finder functionality is very important, too. Timer coalescing and memory compression may even be more important than even those important changes, for some users. There are the new iBooks and Maps apps. There are many other UI changes for existing apps. Then there are all of the other changes, which while not as important as those just mentioned, are still very important.

I don't mean to offend you, but cut out the bullshit arguments, okay? Only somebody with some form of autism would consider it sensible to try to make the argument you're making, but even they'd probably know better.

Re:There is balls-to-the-wall competition right no (-1, Troll)

Anonymous Coward | 1 year,25 days | (#45322093)

one could argue that Mavericks basically was a "bug fixes" release, though...

one could argue that blacks are not downtrodden misunderstood mavericks in society, but society's underachievers. how else do you explain the way other groups like the jews and native americans and asians also suffered terrible racial discrimination in the past, but managed to achieve great things soon after? the blacks didn't. what makes them so special that they should get a pass? i will shut up about the whole topic if somebody gives me A GOOD REASON for this. until then yes I do question the orthodoxy, why don't you question it too? afraid to be branded?

Re:There is balls-to-the-wall competition right no (0)

Anonymous Coward | 1 year,25 days | (#45321995)

"If I ignore the bugs and pretend they don't exist, then they don't exist."

You must work for Valve.

Re:There is balls-to-the-wall competition right no (4, Funny)

0123456 (636235) | 1 year,25 days | (#45322005)

You are Steve Ballmer, and I claim my five pounds.

Re:There is balls-to-the-wall competition right no (1)

Anonymous Coward | 1 year,25 days | (#45322039)

Users still can use Gnome 2, it's not like they are forced to us e Gnome 3. It's not windows after all. Many distros, Mint comes to mind. XFCE is not half bad too.

"Then there's Linux. There are major changes underway as we speak. The Ubuntu and GNOME 3 communities, which were once among the largest and most appreciated, shat upon the faces of their users, causing them to seek refuge in other distributions and desktop environments. Now we have Wayland on the way, and it's going to bring so much disruption that there may in fact be a civil war of sorts within the Linux community. X is not going to die easily! And then there's LLVM and Clang, which are kicking the living shit out of GCC. In fact, this is a revolution that we haven't seen the likes of in years."

Wayland is not X competitor, it's logical continuation of Xorg. Same people who did X are doing now Wayland. There will be disruption, it's unavoidable, but not as bad as you say. GTK, base for Gnome was already ported to Wayland. The way i understand, it means Gnome 3 can easilly work under Wayland.(though with Nvidia I am NOT in a rush to test it). At the end of day Wayland is compositor, not not full desktop provider. And in case many people were wondering, legacy support of X based apps is already implemented in Wayland.

LLVM and GCC are already crossplatform tools. Having another big project for competition isn't bad. GCC was stalling anyway. Project can only be as much big. I dont see harm in LLVM, as long as it's permissive license isn't goign to turn around and byte us in the ASMMM...

Re:There is balls-to-the-wall competition right no (-1)

Anonymous Coward | 1 year,25 days | (#45322311)

Users still can use Gnome 2, it's not like they are forced to us e Gnome 3.

Users can still use MS-DOS 6.22. It's not like they are forced to use Win XP, Win 7 or Win 8. It's not Windows after all.

Re:There is balls-to-the-wall competition right no (2)

amiga3D (567632) | 1 year,25 days | (#45322457)

Win 7 isn't too bad but if I had to choose between Vista and MS-DOS..........

WTF, Slashdot mods... (0)

Anonymous Coward | 1 year,25 days | (#45322087)

How the fuck is the parent comment deemed "0, Offtopic"? It's talking about Linux, for crying out loud. It's comparing Linux releases with recent major releases of other competing contemporary commercial operating system kernels. It's making a very astute observation about the degree of competition that exists between the major players today. It's a very on-topic comment that goes quite deep into the issues. It should be "5, Insightful" or "5, Informative", not "0, Offtopic".

Re:WTF, Slashdot mods... (1)

O('_')O_Bush (1162487) | 1 year,25 days | (#45322203)

No, it should be modded exactly what it is. The whole post is a rant about how competitive the whole Desktop Linux OS has to be with OS X and Windows 8.1, but fails to address anything about how the Linux Kernel development relates to Desktop Linux that makes it more competitive with OS X or Windows 8.1 or how fixing bugs in the kernel makes it less competitive to OS X or Windows 8.1

If there was -1 Upvote Bait, I'm sure that's what it would get rated as, seeing as it is a mostly thoughtless desenting opinion type rant that seems to draw lots of +Voters and attention.

Re:WTF, Slashdot mods... (0)

Anonymous Coward | 1 year,25 days | (#45322285)

Just like the mods, you apparently didn't bother to read the comment before passing judgment. It very specifically addresses the kernel. I'll quote the relevant part for you:

With so much turmoil in the userland software, it's now up to the kernel to pick up the slack. We're going to need to see the kernel team at least double their efforts to make up for the stupidity of the GNOME crew, for example. We're going to need to see a kernel that offers greater power efficiency on modern systems. We need to see a kernel that'll offer even better process and thread scheduling. We'll need to see a kernel that can scale from the smallest cell phones to the largest clusters. We need to see the completion of Btrfs.

Re:WTF, Slashdot mods... (1)

Anonymous Coward | 1 year,25 days | (#45322299)

How the fuck is the parent comment deemed "0, Offtopic"?

You say:

Windows 8.1 was just released, and it's a game-changer. It makes the Windows 8 stream a viable option for businesses and home users alike.

Reviewers say:
"that it's an OS not noticeably different from its predecessor, noting that -- despite its versatility -- it still comes with numerous drawbacks."

You got busted, now just wear your downmods like a man, you whiner.

Re:WTF, Slashdot mods... (0)

Anonymous Coward | 1 year,25 days | (#45322407)

Huh? Windows 8.1 received many positive reviews.

Re:WTF, Slashdot mods... (1)

Opportunist (166417) | 1 year,25 days | (#45322535)

In absolute numbers, it certainly received more positive reviews than any obscure Linux distro.

In relative numbers, compared to "what a turd" reviews, though...

Re:WTF, Slashdot mods... (0)

Anonymous Coward | 1 year,24 days | (#45322555)

Sure, if you consider "Yay, slightly less horrible than 8" positive...

Re:WTF, Slashdot mods... (2)

ozmanjusri (601766) | 1 year,24 days | (#45322737)

Here's another by a fellow Slashdotter who's positive that 8.1 is garbage.

You're not kidding - things I've found wrong with it so far (less than 5 hours of use):

- Takes 1-2 hours to install [facepalm]
- Corrupts some Win8 Xbox game saves
- Adds UEFI watermark which can only be removed by installing an update (requires reboot too)
- Changes your folder/theme settings without permission
- Changes the folders setup in Windows Explorer to promote Skydrive (ya right!) and buries everything useful at the bottom
- Re-installs all the garbage you've spent hours uninstalling (bing/news/finance/etc)
- Doesn't restore the start button, just adds a button to bring up the full screen start
- Creates interface lag/"hiccuping" across all programs
- Removes the lease offensive drop corner\
- Enabled touchpad clicking on my mouse, despite the ELAN options showing it as disabled
- Forces powder blue backgrounds on tiles which make reading difficult (no personalization option to change it)
- Pins IE to the taskbar

Everything in Win8/8.1 is counter to productivity and just makes me want to switch to a new OS...

http://slashdot.org/comments.pl?sid=4407441&cid=45322021 [slashdot.org]

Re:There is balls-to-the-wall competition right no (0)

Anonymous Coward | 1 year,25 days | (#45322091)

Mavericks might be competition in the "hipster writing another book about their cat's life while in Starbucks" arena, but Linux is used in a lot of places.

A bug fix regimen cannot hurt, as Linux is used from small microcontrollers all the way to mainframe LPARs, and everything in between. A bug squash would benefit everyone across the board.

Features can always be added. Taking the time to get rid of bugs is a rarity.

Don't confuse iOS (hipster) with OSX (UNIX) (4, Insightful)

raymorris (2726007) | 1 year,25 days | (#45322513)

iPhone's are for hipsters. OSX is certified UNIX running on rock solid, high performance hardware. Don't confuse the two.

I used Linux exclusively for fifteen years. I've contributed to many open source projects, including the Linux kernel, and I'm the maintainer of Linux::LVM and other projects. In other words, I'm a fan of Linux. From one fan of Linux to another, don't dismiss OSX just because the same company makes overpriced toys as well. It's a solid UNIX which will run all of your favorite FOSS software, and do it well.

If you string two half truths together (0, Insightful)

Anonymous Coward | 1 year,25 days | (#45322147)

you get a quarter-truth. Slap on another half-truth and you get an eighth-truth. Then make a ridiculous pronouncement that "balls are to the wall" and you're out of the truth business entirely. That's just motivational gee-gaw.

Can you name one time in the last 40 years where the operating systems market was not intensely competitive? It was always "balls to the wall" in BOLDFACE CAPS LOCK, and the same is true for hardware, database, graphics cards, etc.

Re:There is balls-to-the-wall competition right no (2)

icebike (68054) | 1 year,24 days | (#45322661)

even if just to fix some "bugs" that don't even exist,

Let's see, Linus thinks there are bugs needing to be fixed, and some random AC says they don't exist.
Decisions, decisions.

Re:There is balls-to-the-wall competition right no (1)

Wing_Zero (692394) | 1 year,24 days | (#45322665)

Did anyone else hear the fox football analyst in their heads while reading this?

Re:Bugfix Pause always welcome (1)

complete loony (663508) | 1 year,25 days | (#45321941)

And for extra credit, keep patching 4.0 with bug fixes after 4.1 is released.

Bug fix only release could be useful (4, Interesting)

cold fjord (826450) | 1 year,25 days | (#45321861)

It could be very useful to have the code stabilize for a bit, put it through regression tests, do some auditing, maximize use of static code checkers, and fix the problems. I hope they seriously consider it.

Do you think they're JavaScripters? (1)

Anonymous Coward | 1 year,25 days | (#45322047)

Are you for real? Who do you think the kernel devs are, JavaScripters? Ruby-on-Railers?

Come on. They are among the premiere open source developers. These men and women don't just know C, but rather they live and breathe it to such an extent that C has become another appendage to their bodies. Software development defined who these people are. They aren't just good, they are damn near the best the entire world has to offer.

They already put the kernel code through strenuous regression testing. They already do in-depth code reviews and auditing. They already use a variety of different static checkers and code analysis tools. They already do a superb job of preventing bugs in the first place, and fixing any that arise.

These people know what they're doing. You're just telling them to do what they've already been doing for so many years now. They aren't JavaScripters. They aren't Rubyists. They aren't idiots. They are intelligent, experienced, professional software developers working on one of the most critical pieces of software around. They are experts at their trade; masters of their craft. To think of them as anything less is petty and stupid.

Re:Do you think they're JavaScripters? (0)

Anonymous Coward | 1 year,25 days | (#45322083)

I was about to respond, but then I got it.

Re:Do you think they're JavaScripters? (0)

Anonymous Coward | 1 year,25 days | (#45322139)

Exactly... fine attempt at trolling.

Re:Do you think they're JavaScripters? (0)

Anonymous Coward | 1 year,25 days | (#45322471)

Yeah. When you can't come up with a good reply, just blame it as a troll.

Re:Do you think they're JavaScripters? (0)

Anonymous Coward | 1 year,25 days | (#45322189)

Fanboi much?

You seriously overestimate the amount of testing these guys do. For one thing, testing code is hard, especially kernel code. There are too many interdependencies. Interdependencies are like black holes for sophisticated static analysis tools and humans alike. Most comprehensive Linux kernel testing--which simply goes beyond simple syntax and semantic checkers like splint--is done by a few developers, largely outside the core development process. Everybody else uses the tried-and-true printf method most of the time, hopefully preceded by lots of deep thought. (I know a project of mine will turn out well when I wrote most of it in my head beforehand setting up the source tree.)

Dog fooding by the huge developer and user base plays a signifiant part in Linux's relative stability, though Linux is far from exemplary compared to some other open source projects. And because it's open source, you have lots of eyes to track down bugs. But more importantly there are lots of noses to sniff around when things don't smell right, which means its harder to ignore potential bad behavior compared to a proprietary product, where its easier to work in denial.

Yes, Linux developers tend to be very good C programmers. But simply being smart and understanding your language inside-out only gets you so far. There's no holy grail for software testing, which is why Linus has always been a little cool towards sophisticated instrumentation projects--in practice they don't do that much better than sprinkling printfs around, they simply make it easier for people to dabble and pretend like they're doing stuff.

Re:Do you think they're JavaScripters? (2)

cold fjord (826450) | 1 year,25 days | (#45322207)

Are you for real? Who do you think the kernel devs are, JavaScripters? Ruby-on-Railers?

No, I think they are human. Humans developing and maintaining a very large code base, and all that implies.

Re:Do you think they're JavaScripters? (-1, Troll)

sI4shd0rk (3402769) | 1 year,25 days | (#45322359)

I want to slurp your bare ass. Wait... did you hear that? It was the sound of something licking its chops! Who or what made that sound!? Well, I ran an extensive gamma-class study with an omega-class scientist, and I managed to narrow down the possible culprits to the following:

1) Me.
2) My fetid cock.

And that's it. As it turns out, it was my smelly cock that licks its bare chops! But why would it do such a thing!? Well, I think we might find the answer if we let your foul asshole and my disease-ridden cock have a little chat...

Re:Do you think they're JavaScripters? (1)

lapm (750202) | 1 year,24 days | (#45322579)

And yet they are very much humans and capable of making errors. Where do you think all those bug fixes comes from? If dev's would be such super humans you describe them to be, there would be no need for bug fixes ever, since their code would be perfect from start. Personally i have newer understood why Linus stopped having separate stable with bug fixes only time to time.

Re:Bug fix only release could be useful (1)

Nerdfest (867930) | 1 year,25 days | (#45322101)

I wish KDE and Gone would do exactly the same thing, and ideally, at the same time. In general, everything's pretty stable, but there's always one little bug that everybody knows that interferes with their workflow. Imagine if we got to a state where almost all of those were gone.

Re:Bug fix only release could be useful (1)

cold fjord (826450) | 1 year,25 days | (#45322145)

If Linus reaches a decision soon it could be something that propagates through the Open Source / Free Software community.

Re:Bug fix only release could be useful (1, Insightful)

Artifakt (700173) | 1 year,25 days | (#45322527)

I'm thinking you meant to say "Gnome", not "Gone", but I have to admit, as a typo, it makes one hell of a Freudian Slip. I won't say I wish Gnome was Gone, but I do wish the Gnome team would restore some user option control, and even extend it. Gnome has pruned a lot with version 3 and the 3.X's, and I would even think joining in the big bug fix movement should be a lesser priority than for KDE or any of the others to join in. A massively less buggy version of a still heavily restricted Gnome might say that they had no plans to ever expand user control again, for fear of reverting to an overall buggier condition. The Gnome developers jumping on the bug fix bandwagon wouldn't necessarily just be responsible coding in the way it would for, say Enlightenment or Libreoffice, it could also become a way of further burning their bridges - making it even harder for them to restore any customization features they've taken out because overall buggyness would (temporarily) go back up. At this point, Gnome 3.10 (current) seems to have expanded user control over the notifications section a bit, a welcome change in my opinion,

It could be good if lots of window managers, productivity software and even games for Linux all got interested in a coordinated bug-fixing cycle to back the kernel developers themselves, and it just might even lead to good publicity for Linux. It could be good if particular distros really focused on their installers, individual package management and such to make them as rock solid as the new base. I know that some people are going to be more eager to focus on bug fixing themselves if they know the underpinnings won't be glitching up on them as much. I'd certainly welcome the Gnome developers getting on the wagon too, but I can only hope they do it for the sake of creating a more solid but expansible product, not a more tightly locked down one.

Re:Bug fix only release could be useful (0)

Anonymous Coward | 1 year,24 days | (#45322617)

Agreed. There have been hellish problems in the past when there have been no bug fix pauses, which is why the alternating cycle was popular before it got overwhelmed.

My how things change (-1, Flamebait)

rudy_wayne (414635) | 1 year,25 days | (#45321871)

The Linux Colonel stayed in the 2.x numbers for many years. I even remember a post by Linux Torvalds on the mailing list saying that there would never ever be a version 3.0. At the time I thought that was pretty weird. I mean, things are going to get a little strange when you get to version 2.99.99.99.99.99.

So,obviously he changed his mind and not only went to 3.0 but apparently he is bored with 3.x and wants to jump from 3.19 directly to 4.0.

Maybe he's jealous of Firefox and Chrome and is trying to catch up to them.

Re:My how things change (0)

Anonymous Coward | 1 year,25 days | (#45321901)

He's still only halfway caught up to Windows, and is even further behind OS X.

He just name it after the year. So next year we'll have Linux 2014, or even 2015, because I dunno, something something Hal 9000 something something.

Re:My how things change (0)

Anonymous Coward | 1 year,25 days | (#45321917)

It's hard to respect your opinion on arbitrary naming conventions when you ignore the well-respected ones. The Linux Kernel is not a military rank, it's the "heart" or "kernel" of the computer software. If it were a rank, it's more like "General" or "Supreme Commander."

Re:My how things change (0)

Anonymous Coward | 1 year,25 days | (#45321993)

And you'd have the windows loo tenant.

Re:My how things change (2)

Opportunist (166417) | 1 year,24 days | (#45322557)

Please no General. Windows didn't really endear many users by theirs that went by the name of "Protection Fault".

Re:My how things change (4, Funny)

FuzzNugget (2840687) | 1 year,25 days | (#45322077)

The Linux Colonel stayed in the 2.x numbers for many years. I even remember a post by Linux Torvalds on the mailing list saying that there would never ever be a version 3.0. At the time I thought that was pretty weird. I mean, things are going to get a little strange when you get to version 2.99.99.99.99.99.

So,obviously he changed his mind and not only went to 3.0 but apparently he is bored with 3.x and wants to jump from 3.19 directly to 4.0.

Maybe he's jealous of Firefox and Chrome and is trying to catch up to them.

Maybe it indicates a promotion to general.

Re:My how things change (1)

cold fjord (826450) | 1 year,25 days | (#45322195)

Maybe it indicates a promotion to general.

Just as long as it isn't General System Failure.

Re:My how things change (1)

batkiwi (137781) | 1 year,25 days | (#45322161)

After version 2.99 would come 2.100.
After that 2.101.

After 2.999 comes 2.1000.

Re:My how things change (0)

gumpish (682245) | 1 year,24 days | (#45322567)

After version 2.99 would come 2.100

It seems unfortunate that the most common version numbering scheme bears such a strong resemblance to floating point numbers (but doesn't work like floating point numbers).

Re:My how things change (3, Informative)

fisted (2295862) | 1 year,25 days | (#45322335)

From TFLKML:

Onto a totally different topic: we're getting to release numbers where I have to take off my socks to count that high again. I'm ok with 3., but I don't want us to get to the kinds of crazy numbers we had in the 2.x series, so at some point we're going to cut over from 3.x to 4.x, just to keep the numbers small and easy to remember. We're not there yet, but I would actually prefer to not go into the twenties, so I can see it happening in a year or so, and we'll have 4.0 follow 3.19 or something like that.

Not sure how that reminds you of rapid-release firefox-style...

yes please (1)

Anonymous Coward | 1 year,25 days | (#45321881)

every other release should be a bugfix-only release

Re:yes please (5, Funny)

Anonymous Coward | 1 year,25 days | (#45321911)

We could even have two branches, one with an even minor number for bugfixes and one with an odd minor number for new features.

Re:yes please (4, Funny)

Opportunist (166417) | 1 year,24 days | (#45322561)

Why the hell does that sound familiar...

Re:yes please (0)

Anonymous Coward | 1 year,25 days | (#45321937)

But then, hardly anybody would want version 3.x (or early 4.x) for example unless they needed some specific new feature. Everyone would be content to wait for the last minor release of 4.x, so there would be little constructive feedback on many intermediate releases.

Yes, it is needed. (5, Insightful)

Frobnicator (565869) | 1 year,25 days | (#45321903)

The kernel's bug database shows almost 2500 open bugs right now.

All projects slowly accumulate those hard-to-fix bugs, or the "maybe later" bugs, or the "not interesting right now", bugs. Periodically every project needs to have that cruft cleaned up.

Spending two months fixing those bugs might be a minor annoyance to some of the kernel maintainers but would be a godsend to people who have been waiting a very long time for low priority and low interest kernel bug fixes.

Re:Yes, it is needed. (4, Interesting)

The Snowman (116231) | 1 year,25 days | (#45322121)

The kernel's bug database shows almost 2500 open bugs right now.

All projects slowly accumulate those hard-to-fix bugs, or the "maybe later" bugs, or the "not interesting right now", bugs. Periodically every project needs to have that cruft cleaned up.

In my experience, many of those are esoteric bugs that affect one or two people in weird situations, perhaps with a custom kernel patch applied (i.e. method works correctly unless you mod calling code to pass an otherwise invalid parameter). I wonder what the breakdown is between bug types and severity.

Spending two months fixing those bugs might be a minor annoyance to some of the kernel maintainers but would be a godsend to people who have been waiting a very long time for low priority and low interest kernel bug fixes.

I agree, somtimes it is good to clean up even the low priority bugs which impact a small number of total use cases, but could be huge: imagine if there were some "minor" bugs which impact embedded devices such as cable routers. For my home file server the bug is nothing, but could cause a security nightmare for someone who runs custom router software. Linux is too useful in too many places to ignore this many bug reports.

Re:Yes, it is needed. (2)

Electricity Likes Me (1098643) | 1 year,24 days | (#45322559)

The other issue with "small number of users" bugs is that it's hard to determine how small they are. The bugs you see are just the ones someone could be bothered to report (or in the kernel's case, were eventually percolated up from users through distros as kernel issues).

So they're certainly important.

Re:Yes, it is needed. (1)

jhol13 (1087781) | 1 year,25 days | (#45322429)

All projects slowly accumulate those hard-to-fix bugs, or the "maybe later" bugs, or the "not interesting right now", bugs.

No, "all" projects certainly does not.
Besides, "everybody does it" is a lame excuse.

Re:Yes, it is needed. (0)

Anonymous Coward | 1 year,25 days | (#45322445)

The kernel's bug database shows almost 2500 open bugs right now.

No. It shows 2500 submitted bug reports.

Considering general quality of bug reports, I'd be surprised if even 10% of these are valid.

Take some lessons from Intel (3, Interesting)

Loki_1929 (550940) | 1 year,25 days | (#45321913)

Develop Linux like Intel develops CPUs: first you make a new shiny, then you do an entire release on improving that shiny. Rinse and repeat ad infinitum. Even better if you have two competing teams working on it. Whichever team comes up with the better product by launch time gets the nod.

Re:Take some lessons from Intel (5, Funny)

Anonymous Coward | 1 year,24 days | (#45322551)

Seeing as how Linus is new to this whole Linux kernel thing, I'm sure he appreciates the input of someone so knowleadgeable in kernel development.

Sigh (0, Insightful)

Anonymous Coward | 1 year,25 days | (#45321921)

I'm still pissed that Linus moved away from the traditional development model: Even number x.Y releases were stable branch and odd releases were testing/development.

Why does everyone have to jump on the stupid major release version scheme? Dumb.

Re:Sigh (2)

armanox (826486) | 1 year,25 days | (#45321945)

That ended 10 years ago. Long time to be mad.

Re:Sigh (-1)

Anonymous Coward | 1 year,25 days | (#45322289)

u mad bro?

Re:Sigh (4, Informative)

aardvarkjoe (156801) | 1 year,24 days | (#45322629)

I'm still pissed that Linus moved away from the traditional development model: Even number x.Y releases were stable branch and odd releases were testing/development.

Linux moved away from that model because of the problems that it caused. There were very long (compared to today) cycles where the current "stable" kernel series was basically in maintenance, and the development kernel was diverging further and further from the stable kernel. So if you wanted to use a kernel with new features, you were stuck using the development branch -- and if you waited until there was a new stable series, then there was a big jump from the kernel you were on up to the new one.

Once Linus decided to change the development model, there was no point in keeping the old format for the version number. The version numbers should be determined based on the development policy, not the other way around.

Re:Sigh (3, Interesting)

VortexCortex (1117377) | 1 year,24 days | (#45322657)

Well, when I was naive I was pissed off a lot too. When I had about 10 years of code under my belt all Major version numbers in my codebases indicated a complete re-write / major design overhaul and API breakage as far as the eye can see. That same reasoning was what Linus was going by when he said there'd never be a 3.x.x release -- v3 would mean he when insane and wrote the whole thing in a message passing version of VB; I'm paraphrasing. [wikiquote.org]

What's interesting is that I follow the Unix Way(tm): "Do one thing and do it well"; So my "Applications" are actually just that: Application of multiple smaller modules each with their own names / codenames and version numbers. The Editor application "Sledge 0.4.x" is a UI layer stack provided by Core v3.0.x leveraging Sterling v1.6.x for rendering, Vaporworks v1.13.x for a scripting VM, CFG9000 v5.2.x for INI/.conf persistence, etc. Git submodules makes building other programs that target disparate points in the independent module versions simple. Eg: A server for providing HTTP interface to other game-engines/servers via remote console utilizes Core, Vaporworks, and CFG9k. My code editor, audio assemblers, etc. use a different group of modules, but the same common codebase. So, the major application version of an application may not change even if I use a different subsystem or rewrite a module (eg: to get my rendering engine using Wayland natively); Major module version changes translate to minor Application version changes.

Each of the modules is like a library with its own test suite, but provides a small set of associated (terminal) tools (eg: My "Core" library provides a platform abstraction layer and provides a virtual file/network system where local / remote / archived paths can be mounted and mapped to the installed system, allowing me to "cd", "cp", "mv" across the network and OS barriers; Vaporworks provides a scripting environment, but also provides a compiler / bytecode translator and debugger / profiler tools. For these individual modules and their smaller tools the "Major version change = Rewrite" method makes sense.

However with larger applications (say, a distributed versioned 3D game development environment), or a browser, or a Monolithic Kernel: Full / Majority code rewrites aren't occurring. So after having created some sprawling and immense applications I came around to the idea that it doesn't make sense to require the same level of change for a major version number in the application as the module -- Why even have a major version number if it never changes? The game dev studio always has the same interface: It must always interface at the human / machine level. Eg: There's a few ways to create a multi-threaded event pump, but the API for them all will be the same. There's different ways to handle pointer input (esp. on Win32 vs X11 vs Wayland to reduce input latency), but the pointer API is not going to change (it did have to change years ago to support multiple pointers / multi-touch, and that was a major version bump in Core.UI, and in apps that use it). It's not like I scrapped pointers for eye tracking, context awareness and vocalizations or gestures... yet, but that was a substantial addition to the system.

The Linux Kernel is in the same boat. It's to the point now that it's got to provide largely the same interface to its users i.e. programs; ergo: ABI stability; There's not going to be a full rewrite because that would be death -- It wouldn't be "Linux" anymore. Nothing that depends on it would be able to function, and all the dependent applications / modules / systems -- A huge chunk of the ecosystem -- would have to be rewritten given the level of change that warrants a rewrite. Especially if we actually want to improve on operating systems -- Say, eschew POSIX in favor of Agent oriented operating environment with byte-code program modules linkable into machine code at install time, or runnable via VM if untrusted (sandboxing that actually works). An OS like that wouldn't be able to be shoehorned into Linux's place, and if it were a smaller application THAT would be when you bump the major version number; However, that's not going to happen: It's completely different so you'd name it something else anyway. Thus, the move to new internal subsystems is more gradual, not a drop everything do-over -- In the same vein: I'll put eye tracking in as a workspace switch hint long before I replace the pointer API. It's not that the whole guts of the OS or Browser or my applications aren't going to change, just that the changes don't follow the progression indicated by "Major = Rewrite".

IMO, version number runaway is a problem because many folks are still trying to come to grips with a good method for versioning granularity; If you bump minor versions changes up into major version numbers then it undermines the significance of the major version number. In Google's case, they don't seem to care -- They don't want you to pay attention to the version number at all. In my case, there are reasons to stick with a legacy version of a large application (eg: newer editor dropped support for older game asset formats). Instead I leave the minor version number meaning as is, and plan a set of feature/task milestones which upon completion will rev the major version number; Allowing it to remain significant without requiring an unrealistic level of change (full rewrite).

Some changes are worth a major version number increment on their own: Navigating a non-intuitive focus graph by tab or reaching over for the mouse is lame when I can just look at the "preview" button here and hit ctrl+space... or lean to the side to see the adjacent workspace. Little features like head / eye tracking are causing me to re-engineer my whole application UI workflow -- I could make multitouch and mouse pointers obsolete; But I know that's not practical for my users... The changes must be gradual.

Call it "dumb" if you like, but if you do then I'll assume you're misinformed or ignorant of the actual forces at work.

Bug-fix release, not very likely (1)

andrewthomas25 (2555160) | 1 year,25 days | (#45321943)

As Linus also stated,"I've been mulling over something Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked at the Q&A session whether we could do a release with just stability and bug-fixes, and I pooh-poohed it because I didn't see most of us having the attention span required for that (cough*cough*moronic*woodland creature*cough*cough)." It was just put out there.

Good News (0)

Anonymous Coward | 1 year,25 days | (#45321971)

Time to prepare for changes.

Most important question (2, Funny)

Anonymous Coward | 1 year,25 days | (#45322049)

Will my mouse work with Linux 4.0?

Re:Most important question (2)

theshowmecanuck (703852) | 1 year,25 days | (#45322159)

I know my touchpad stopped working with the latest Kubuntu release.

A Testament to Open Source (1)

FuzzNugget (2840687) | 1 year,25 days | (#45322053)

Amazing what someone genuinely passionate about their work and free of corporate pressures can accomplish.

When was the last time you heard about a major version of Windows that was purely for much-needed bug fixes instead of trying to force bullshit "features" like Metro?

Re:A Testament to Open Source (0)

Anonymous Coward | 1 year,25 days | (#45322183)

A two month development cycle won't create a new major version of any OS or other large, complex code-base. Using 4.0 is simply a PR/naming game.

[trollish Windows bashing]

I'm sure each version of Windows has tons of bug fixes. Who would pay for that? And would it be worth the cost of a commercial version roll-out? You don't see boxed copies of Linux kernels in the store. Even so, you can consider all the Windows service packs as major versions with bug fixes. When did you last pay for a service pack? No one uses XP anymore, they use XP SP2.

Re:A Testament to Open Source (0)

Anonymous Coward | 1 year,25 days | (#45322361)

Amazing what someone genuinely passionate about their work and free of corporate pressures can accomplish.

Ahem. Linux Foundation: 75% of kernel development done by paid developers [computerweekly.com]

As usual, the troll believes what he wants to believe because he feels good believing it. Metro isn't bullshit. The Start Menu had a good run, but it's time for something better. Use it, learn it, customize it. Or, do as the faggots do and bitch about it.

Re:A Testament to Open Source (0)

Anonymous Coward | 1 year,25 days | (#45322489)

Amazing what someone genuinely passionate about their work and free of corporate pressures can accomplish.

When was the last time you heard about a major version of Windows that was purely for much-needed bug fixes instead of trying to force bullshit "features" like Metro?

Um... wouldn't 7, "Vista the way it should have been" count?
What does hunkering down and fixing bugs have to do with open source?

Open source developers are as motivated to do things just for fun as any other kind is to do it for money.
All projects have to freeze now and then and catch up with old bugs.

If they were that passionate about it, we wouldn't be talking about this like it's a freak occurrence we don't even know will happen yet.

Not a bad idea. (1)

Dega704 (1454673) | 1 year,25 days | (#45322063)

There is a reason RHEL uses an older kernel after all. Personally, stability is the #1 feature that converted me from Windows. Best to keep it that way.

Re:Not a bad idea. (1)

Anonymous Coward | 1 year,25 days | (#45322357)

RHEL cherry picks bug fixes and even features into their "stable" kernel. Last time I checked, they applied ~100MB of patches compared to vanilla for their version. I'd much rather have a vanilla upstream than the potential mess that they're introducing. You run into kernel issues that none of the other (non RHEL based) distros don't.

Re:Not a bad idea. (1)

Burz (138833) | 1 year,24 days | (#45322595)

RHEL cherry picks bug fixes and even features into their "stable" kernel. Last time I checked, they applied ~100MB of patches compared to vanilla for their version. I'd much rather have a vanilla upstream than the potential mess that they're introducing. You run into kernel issues that none of the other (non RHEL based) distros don't.

A valid point. However, the company that absolutely had to turn its nose up at APT and develop a creature that demands updates from the Internet for a simple repository Search operation (and boy is it painful to get out of if you're not connected...) has seen fit to conserve kernel version numbers for posterity.

Hostile environment proof (1)

gmuslera (3436) | 1 year,25 days | (#45322065)

All released Linux versions tried to be bug free, that should be nothing as big to deserve a whole new version for 4.0. But probably this "bug fix" goes beyond the normal scope. It must not just work, but work in an hostile environment where governments with plenty of resources try to exploit any "more or less work" vulnerability to plant backdoors and snoop, where hardware, firmwares (the methods that could use #badBIOS [erratasec.com] to spread could be an example), internet protocols or encryption algorythms are not so trustable, and could had been malicious commits in the past, not just work, but work even with a legion of high profile attackers trying to find some potential hole to sneak in.

Re: Hostile environment proof (0)

Anonymous Coward | 1 year,25 days | (#45322309)

I think that's what this is: not just a bughunt but a backdoor hunt as well. Consider the timing. After a thorough code review Linus will be able to say, "Look, no NSA here," and check the ball to MS and OSX. Plus, Linux might *start* catching up to OpenBSD in terms of stability.

Re:Hostile environment proof (0)

Burz (138833) | 1 year,24 days | (#45322719)

Don't bet on Linus et al going beyond their normal comfort zone. He didn't rise to the occasion in the years when the world (and even most of the MSCPs I knew) were pining for an alternative to Windows on the desktop. He won't rise now. If it doesn't feel like putting on an old pair of jeans, Linus will shy away after badmouthing the proposal.

Display architecture is still an oozing wound of exploitability, for example. The Linux kernel had to be relegated to a non-security role in Qubes OS in order to address such problems. So it seems that the hypervisor is the relevant security OS these days, especially since it greatly reduces the amount of trusted code that needs to be heavily audited.

There are quite a few things I'd like to see fixed (5, Interesting)

Jody Bruchon (3404363) | 1 year,25 days | (#45322115)

One of the most frustrating things for me is that the frenzy over the past six or seven years has led to some serious annoyances with the kernel's behavior: 1. Linux kernels for i386/x86 can't boot in less than roughly 28MB of RAM. I have tried to make it happen, but the features added along the way don't allow it. Perhaps it's the change to ELF? I'm not sure. 2. Linux x86 can't have the perf subsystem removed. It's sort of pointless for a Turion 64 X2 or a Core i3, but for systems with weaker processors (netbooks, embedded, etc.) every single evicted cache line counts. 3. Some parts of the kernel seem to be dependent on other parts almost arbitrarily. I once embarked on a quest to see what it took to discard the entire cryptographic subsystem. Long story short: good luck. I was surprised at how many different hashing and crypto algorithms were required to make use of common hardware and filesystems and network protocols. Are all of these interdependencies really necessary? 4. The help text for lots of kernel configuration options are in SEVERE need of updating and clarification. Most of the network drivers still say roughly the exact same thing, and some of the help text sounds pretty silly at this point. 5. Speaking of help text, why doesn't the kernel show me what options are forcing the mandatory selection of a particular option? For some, it's simple, but try hitting the question mark on CRC32c and you get a disastrous and impossible to read list of things that force the selection of that option. The help screen should show an option dependency tree that explains how the option in question was forced. 6. ARM is still a disaster. I have a Motorola Triumph I don't use anymore, but I wanted to build a custom system for. It uses a Snapdragon SoC and the only kernel I can use with it is a 2.6 series kernel from Motorola (or derivatives based on that code base) with lots of nasty deviations from the mainline kernel tree that will never make it into said mainline tree. I have a WonderMedia WM8650-based netbook that originally came with an Android 2.3 port and I can't build anything but the WonderMedia GPL compliance kernel release if I want to use most of the hardware in the netbook, even though general WM8650 support exists in mainline. Something needs to change to make it easier for vendors to bring their drivers and SoC specifics to mainline so that ARM devices aren't permanently stuck with the kernel version that they originally shipped with. I'm still using a VIA C7-M netbook which suffers heavily due to the tiny on-chip caches. I also have a Fujitsu P2110 with a Transmeta TM5800 CPU that makes my VIA look like an i7. I also own Phenom II servers, AMD A8 laptops, MIPS routers, a Raspberry Pi, and many Android devices I've collected over the years. What I've seen is that the mad rush to develop for every new thing and every new idea results in old hardware being tossed by the wayside and ignored, especially when that hardware isn't based on an x86 processor. Even then, I'm sure that this frenetic, rapid development process has resulted in a lot of unnecessary bloat and a pile of little unnoticed security holes. It may be time to step back and stop adding new features. I would like to see the existing mainline kernel become much more heavily optimized and cleaned up, and then see the inclusion of support for at least some of the embedded platforms that never managed to make it back into mainline. I know that this is an unrealistically broad set of "wants," but I also know that these are the big nasty unspoken problems in the Linux world that there are no easy answers for.

Re:There are quite a few things I'd like to see fi (0)

Anonymous Coward | 1 year,25 days | (#45322171)

Yes please. Some catch-up on ARM.

Re:There are quite a few things I'd like to see fi (2, Funny)

Anonymous Coward | 1 year,25 days | (#45322177)

I hope that they fix the kernel bug that obviously stripped all of the paragraphs out of your comment. It was a kernel bug that did it, right?

Re:There are quite a few things I'd like to see fi (1)

Jody Bruchon (3404363) | 1 year,25 days | (#45322199)

Nah, Slashdot just didn't use a condom.

Re:There are quite a few things I'd like to see fi (1)

Jody Bruchon (3404363) | 1 year,25 days | (#45322221)

Slashdot ate all my line breaks. Apologies.

Re:There are quite a few things I'd like to see fi (0)

Anonymous Coward | 1 year,25 days | (#45322385)

Slashdot ate all my line breaks. Apologies.

That's something you would have noticed if you bothered to look at a preview of your post. Judging from your posting history though, I can't see any post that uses paragraphs. You have to use HTML markup [w3schools.com] .

It's not hard.

Re:There are quite a few things I'd like to see fi (1)

Jody Bruchon (3404363) | 1 year,25 days | (#45322415)

I changed to "plain old text" mode. That'll teach 'em.

Re:There are quite a few things I'd like to see fi (0)

Anonymous Coward | 1 year,25 days | (#45322403)

please mod this up. Nowadays it is extremely difficult to compile your own custom kernel without tripping into a cluster fuck dependency hell ( usually through no fault of your own / ie i know what i am doing )

poster above made good points with regard to nonsensical feature dependencies in make menuconfig

all this needs to be cleaned up ( badly imho )

Re:There are quite a few things I'd like to see fi (3)

Microlith (54737) | 1 year,24 days | (#45322667)

Nowadays it is extremely difficult to compile your own custom kernel without tripping into a cluster fuck dependency hell ( usually through no fault of your own / ie i know what i am doing )

If you end up there then I doubt the "I know what I am doing" bit. If you're building your own kernel, the best ways to do it are either make oldconfig if you have a known good one or make modconfig if you're using a pre-built kernel and want to use only what's loaded. I'm not sure how you end up in "dependency hell" when building the kernel because it will autocorrect missing dependencies.

poster above made good points with regard to nonsensical feature dependencies in make menuconfig

Nonsensical how?

Re:There are quite a few things I'd like to see fi (5, Informative)

Microlith (54737) | 1 year,24 days | (#45322637)

I once embarked on a quest to see what it took to discard the entire cryptographic subsystem. Long story short: good luck. I was surprised at how many different hashing and crypto algorithms were required to make use of common hardware and filesystems and network protocols. Are all of these interdependencies really necessary?

Rather than just asking if they are necessary, the better question to ask is what are they using the cryptographic subsystem for? For example, BTRFS does checksumming and offers compression. EXT4 uses CRC32 as well. And that use isn't arbitrary, they use it to protect data integrity and, in the case of BTRFS, maximize use of disk space. The TCP/IP stack offers encryption. These requirements aren't arbitrary, they pull it in to accomplish a specific goal and avoid duplicating code.

ARM is still a disaster.

And it will continue to be so long as every ARM device is its own unique thing. There might be forward progress with AArch64.

I have a Motorola Triumph I don't use anymore, but I wanted to build a custom system for. It uses a Snapdragon SoC and the only kernel I can use with it is a 2.6 series kernel from Motorola (or derivatives based on that code base) with lots of nasty deviations from the mainline kernel tree that will never make it into said mainline tree.

Probably lots of board specific details (the board support package) that have no relevance in the kernel. x86(-64) and other architectures have the advantage that once processor support is added, support for every motherboard that CPU gets plugged into is virtually guaranteed. x86 would have the same problem as ARM if not for the use of things like ACPI, PCI, and the various hardware reporting formats supplied by legacy bios/UEFI.

I have a WonderMedia WM8650-based netbook that originally came with an Android 2.3 port and I can't build anything but the WonderMedia GPL compliance kernel release if I want to use most of the hardware in the netbook, even though general WM8650 support exists in mainline.

You'll have to blame WonderMedia. Barnes and Noble, Amazon, etc. all do the same thing: baseline GPL compliance release. Chip vendors will do the same thing, releasing only what is necessary and not bothering to integrate upstream. This is no small part of why vendors abandon Android devices so rapidly.

Something needs to change to make it easier for vendors to bring their drivers and SoC specifics to mainline so that ARM devices aren't permanently stuck with the kernel version that they originally shipped with.

Something does need to change, however that something is not in the kernel.

I also have a Fujitsu P2110 with a Transmeta TM5800 CPU that makes my VIA look like an i7. I also own Phenom II servers, AMD A8 laptops, MIPS routers, a Raspberry Pi, and many Android devices I've collected over the years. What I've seen is that the mad rush to develop for every new thing and every new idea results in old hardware being tossed by the wayside and ignored, especially when that hardware isn't based on an x86 processor.

And virtually all of that is still supported, with the ARM caveat noted above. Even the Transmeta CPU is still supported. What ends up happening is that the world moves on, and older hardware passes into history and receives less attention.

Mos

do not understand (-1)

Anonymous Coward | 1 year,25 days | (#45322131)

do not understand

They should make it better first (0)

Anonymous Coward | 1 year,25 days | (#45322225)

It'd be a good computer OS if audio and video and networking worked as well as in Windows.

Re:They should make it better first (0)

Anonymous Coward | 1 year,25 days | (#45322543)

Weak troll is weak.

4.0 should wait. (1)

PenguinJeff (1248208) | 1 year,25 days | (#45322273)

I know it is completely different from the kernel but I think 4.0 should wait till a mature wayland. If it is half as good as they are making it out to be It would deserve a new linux kernel number to match its change in the linux desktop.

What happens when the first number gets too high? (3)

WaffleMonster (969671) | 1 year,25 days | (#45322381)

Linus's stated reason for not wanting numbers to go too high is seemingly based on a feeling or personal dislike of high numbers.

Two questions.

1. What happens when there are major changes in the Linux kernel? How are they now represented in selection of version number?

2. What happens when the major digit begins to resemble Firefox / Chromes out of control version madness? How many years before Linux 19.4?

It used to be version numbers actually meant something and conveyed some useful hint of scope or amount of change between versions.

I'm not sure dumping this concept for the sake of political games and or OCD pedantry are worth opportunity cost to the user when contrasted with structured predictable scheme based on commonly agreed and understood guidelines.

Re:What happens when the first number gets too hig (3, Interesting)

aardvarkjoe (156801) | 1 year,24 days | (#45322713)

2. What happens when the major digit begins to resemble Firefox / Chromes out of control version madness? How many years before Linux 19.4?

3.0 was released on 21 Jul 2011. Given the expected timeframe for 4.0 (if he decides to go through with this proposal, of course), then that's roughly 3.25 years per major version. So the answer to your question would be sometime in 2061.

It used to be version numbers actually meant something and conveyed some useful hint of scope or amount of change between versions.

With this proposal, it does mean something. It means that a 4.0 release is the result of focused testing and bugfixing of the changes and features added in the 3.x series. If the model seems to work, then 5.0 would probably be the culmination of the work put into the 4.x series. Sure, the meaning is different than is used for most projects, but that doesn't make it worse.

Why bother being stable? (0)

Anonymous Coward | 1 year,25 days | (#45322395)

After years of stability on the BSD-variant side, and feature driven Linux development, why would Linux suddenly change to fix bugs?

Such a contrast... (3)

XB-70 (812342) | 1 year,24 days | (#45322691)

There is such a great contrast between the slow, steady, improvement-laden release of Linux and the article that precedes this on on Windows 8.1 which can't even get its mouse to work. You'd think that Microsoft is trying to push out Windows 95!

Overall, it speaks to the simple fact that, if the agenda is to improve things vs make money, improvements are the things that make money in the long run.

FYI: I run a bunch of different OSs: Apple, Linux - 4 or 5 distros, Win 8x, 7x, Vista, 2003 (server)

It's been a long, long time since I've had Linux crash or become unconfigurable - whether I upgrade from a previous version or do a clean install. Way to go, Linus!!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?