Well this makes a change. Linus Torvalds has announced that the next version of the Linux Kernel release is to be ‘3.0’. “I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can no longer comfortably count as high as 40.”
Instead of going for a glorious ‘break-everything’ approach Linus has described the change-set as nothing in particular:
We are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We’ve been doing time-based releases for many years now, this is in no way about features. […] There’s absolutely no reason to aim for the traditional “.0” problems that so many projects have.
Instead the release will work on testing the build scripts for the numbering change, but will also include the “usual two thirds driver changes, and a lot of random fixes” and “some nice VFS cleanups, various VM fixes, some nice initial ARM consolidation (yay!)”.
“In general this is supposed to be a fairly normal release cycle” as Linus puts it.
Kernel renumbering was discussed last year, but I like Linus’ ability to make a decision otherwise such an otherwise meaningless change could be caught up in endless squabbling. “Let’s face it – what’s the point of being in charge if you can’t pick the bike shed
color without holding a referendum on it? So I’m just going all alpha-male, and just renumbering it. You’ll like it.”
So, no bandwagon. Just the same usual reliable improvements with a new shiny number.
It’s about changelog
What a shame! I was SO looking forward to see a kernel programmed in a “special message-passing version of Visual Basic”.
Note to zealots: No trolling here, pass along. Linus himself promised: http://lkml.org/lkml/2005/3/2/247
Moreover: no modular micro kernel
I thought that discussion was over with in 1991!
May be SEL4 you are interested in !!!
http://ertos.nicta.com.au/research/sel4/
tbh its not always reliable updates
also, i don’t know whats with versions numbers, but hey, 3.0 is all nice and shiny.
If I were you, I’d hold out until Linux 3.11 for Workgroups.
Comment score, at the time at which I read this : 11.
Epic win.
I wonder what happens once it reaches 40 O.o
It will have a nonzero probability of reaching 42
At the time I saw it (just now) it was at 49, the same as the number of comments here. Coincidence? Only if you consider that I’m comment #50 and before commenting I took the score to 50.
Sure you can reach that score. Just copy another funny comment from slashdot, like the author of the parent thread did.
http://linux.slashdot.org/comments.pl?sid=2196142&cid=36285752
Not copied that I can see, at least not word for word, or really even in spirit. The comment on Slashdot had an entirely different feel to it than this one. And who knows, it could have been the same person there as here, and he just carried his own joke over in a different format.
Besides, there has to be more than one person who thought of a joke like that. We’re not all twenty-something newbies who only know XP and beyond, you know.
Of course, I could be completely wrong, but who cares? If it was funny to you, laugh and go on.
Even just changing version number without any other big changes is likely to cause some problems. Any poorly written script that tries to check if kernel is newer than 2.x will break.
To be honest if they make such as simple mistake as a version check, I don’t really want that software on my system. Just sayin’
How do you know that software you do currently want on your system doesn’t contain latent errors? You might not actually want the software you want
Write better scripts. It’s not Linus job to make sure crappy scripts doesn’t work.
I remember when Linux kernel 2.6 was released… it was all over tech news sites, and seems like a long time ago. After reading this article, I got curious about version 2.8, and then after looking around, realized they never got to 2.8. I feel kind of dumb for not knowing that. lol
Linux kernel development used to make headlines regularly on ‘mainstream’ tech sites, but I rarely hear about it anymore, which just goes to show you how exciting Linux (and PCs in general) is today. Basically, not very exciting at all. Now days, it’s all about phones and gadgets. Hell, we rarely have Linux vs Windows pissing contests around here anymore; I kind of miss those
Note: I don’t mean to imply that Linux development is not important (based on all the devices that run it), just not very exciting. It’s like the MAME arcade emulator – in the old days (like in the late 90’s), when a new release of MAME was drawing near, people used to hang out on IRC channels together and wait for it to be uploaded, just to play all the new games it supported. Now days, it’s just 9,000 different variants of Mahjong, and nobody really gives a shit anymore.
Edited 2011-05-30 09:39 UTC
Kernel development is definately important and this kernel continues to have a faster development cycle than the other mainstream OS kernels. (70 days or some such thing on average?) Personally, I could do with seeing more support from hardware manufacturers in getting drivers into the main line instead of being aftermarket binary blobs or third party reverse engineering projects for lack of manufacturer support.
In terms of news though, I think an Xorg update would be a much bigger anouncement. Everything is going toward touchscreen devices yet that area of support in Xorg and Gnome/KDE remains a big gaping pile of missing. Consider the Asus Eee PC touchscreen all-in-one:
– easy to config touchscreen support. Just install xserver-xorg-input-evtouch, update your xorg config (it doesn’t autodetect is said to be the new Xorg way), reboot and whammo.. your Eee PC touchscreen working hapily. – nope.
– easy to config touchscreen support. Just grab the interface manufacturer’s provided driver, run the setup script and reboot. – nada. No Va.
To the manufacturer’s credit, they do provide Debian5 and Ubuntu 10.04 native drivers among four or so other OS. They just don’t actually work (if Nvidia can deliver a GPU driver that works across multiple OS distributions, a simple input device can’t be that hard to do).
I’d really like to see touchscreen support and auto-config improved in the graphic layer with finger-poke interfaces being the hot selling feature these days.
Secondary question:
Anyone have suggestions on desktop sized touchscreens that behave well with Linux based OS (preferably Debian)? I’ve been banging my head against this lack of support for a while now. It remains the one outstanding issue that keeps me from moving on to more interesting home projects.
I’d rather see something about Wayland in that case.
Well, you’ll certainly see a lot about wayland from 2012 onwards, as that is clearly where Linux is headed now.
The one thing I’ll miss or have to replicate is support for GUI forwarding over SSH and it’ll need Nvidia GPU support before I go anywhere near it but given those two requirnments, I wouldn’t complain if it shipps with a future Debian.
If a Wayland requirement breaks NX, then all 150 of my users will be moving to Windows. That’s not a threat. It would probably happen over my dead body. And we could move to some distro that supports X. But if Wayland is the future of Linux, Linux will eventually be my customers’ past.
We care about getting work done, and network transparency. VNC-like “solutions” are a total joke for real work.
Wayland advocates care about shiny eye-candy effects to amuse them. If I presented Wayland’s “advantages” to my customers, they’d laugh me out of the room. But they like me. So they’d probably chip in to send me to a good sanitarium.
-Steve
Deployments such as yours will probably be running X server as a wayland client, and the X clients (i.e. apps themselves) will use X11 versions of the libraries to work in network transparent fashion.
That said, it will probably be a long time before RHEL & likes move over. Wayland is important for mobile and desktop, but somewhat uninteresting to enterprise. I.e. MeeGo and Ubuntu will jump first.
New KDE Project Aims at Tablets, Mixed UIs
http://www.osnews.com/story/24634/New_KDE_Project_Aims_at_Tablets_M…
http://www.techworld.com.au/article/382938/new_kde_project_aims_tab…
http://community.kde.org/Plasma/Active
http://community.kde.org/Plasma/Active/Contour
I grant you it is a new project. They do however already have a a proof-of-concept working on certain hardware, with a basic working shell, but an incomplete set of key applications.
Cheers. I’ll have to watch how this one progresses. It’s a bit heavy for my current project but well worth considering should touch screens become a normal function in laptops (or I have the disposable budget to put into a proper Toughbook again).
At present, I’m trying to get simple touch support. I’m basically booting a minimal install through XFCE into a browser. If I can get it working, I may actually boot raw Xorg into the browser with no window manager inbetween though it causes some issue with any popup windows. The idea is to dedicate one of my machines to a pure touchscreen thinclient.
I remember compiling Linux 2.4.0 for the first time. It has improved multi media support which was going to revolutionize the Linux desktop.
“I think we should hold off on our plans to migrate the business to Linux. They’ve just released a new version – we should wait six months for them to fix the bugs in it.”
Sure, Linus can do whatever he feels, but to me a major version number represents massive breaking API changes. <shrug>
That’s the problem I have with Semantic Versioning. If a product only adds feature, and fixes bugs, in an API compatible way all the time… the said product is supposed to be at 1.x.x for ever? Say… 1.1024.42?
perhaps now he did it so he can start the version numbering to approach Pi… like TeX.
What do you mean with massive breaking API changes? Care to elaborate?
Breaking the binary system call interface, in the case of Linux. Like, I don’t know, giving a new parameter to malloc that is mandatory and has no default value. Or switching the integer type used to store PIDs from 32-bit to 64-bit, it that’s not done already.
Edited 2011-05-30 14:55 UTC
Isn’t that just bad programming on the developer’s part?
Not necessarily so. In the case of the PID example, 32-bit PIDs may have served well for decades and saved boatloads of RAM before a day came where Linux was used on clusters so large and running so much processes that the ability to run more than 4 billion processes at once became needed.
That’s why people should use libc and use the ANSI C and Single UNIX Specification standards. If you use syscalls you ought to get bitten in the tail.
By the way, the kernel does not have a malloc system call, it is implemented as a C library function. The C library normally manages the heap, and grows the heap if necessary with the brk() (or depending on the implementation/situation mmap()) system call.
Edited 2011-05-30 16:33 UTC
or generally speaking some massive breakthrough such as an architecture overhaul, a whole host of new features or a complete ui rethinking in the case of an application)
ABI changes needn’t happen… remember that early versions of NT were based on a (Mach- like) microkernel, but even migrating whole subsystems from userspace services into the kernel executive, didn’t result in a mass breake of userspace applications – API/ABI breakage involved platform libraries in charge of direct interfacing with the migrated (reimplemented) system services – but applications linked to them, could continue working unchanged (as long as those libraries were accordingly reimplemented)
Agree, I think linux should keep the old numbers until braking API and/or really large underlying changes.
To you perhaps, but not to everyone subscribes to that view. Some prefer not to give an particular meaning to “major” and “minor” version numbers other than, well, it’s a new version.
I’ve always preferred to bump the major version for ANY change in features, no matter the size or scope, and the minor version if only bug-fixes were done. That’s perhaps the most common form of version number handling I’ve seen among the programmers I associate with. But to each their own… I just find it silly that a “mature” product with more than a decade of work can still be at version 0.xxx.
Major version releases for products like Linux Kernel is just a silly notion. Going from 2.8 to 3.0 seems just as logical then any.
If the number doesn’t mean anything any more, I would make it something that makes it obvious how old the kernel is, like,
kernel 2011.05.03-02
released on 03 may 2011, patch version 2
Why keep and change arbitrary number, when you can make a number which actually means something?
Edited 2011-05-30 13:14 UTC
Too much common sense for one post there, friend.
Which number should be replaced with a date? The major, the minor, the patch number or the additional backport version number?
So one date for 2.x.x, one for 2.6.x, one date for 2.6.40, and one date for 2.6.40.x patches?
I think numbers over 40 are annoying is as good a reason as any, just like, date? what date? multiple dates are annoying..
The problem is Linux version branches now. When 2.6.32 is released, it is finished from Linus point-of-view but it is still maintained has bug-fixes backported etc. Hopefully this will become 3.x is released by linus and 3.x.x are released by point-release maintainers with bug-fixes only.
Edited 2011-05-30 13:37 UTC
The problem is that atleast in Linux kernel the version number DOES indeed mean something. In x.y.z versioning if z changes it just tells you that it’s a bugfix and any modules compiled against the previous version should work just fine on newer versions too. If y changes then it means that release has some new functionality, drivers and/or features that are remarkable enough to warrant version bump. It might also break something, but usually shouldn’t. If x changes then it is a major devision from previous versions and most likely breaks any and all out-of-kernel-sources modules.
This is important for example for compatibility reasons. With date-based versioning you’d lose all that, you couldn’t for example deduct whether your driver will work on current release if the driver was made 5 releases back.
So there IS indeed a meaning to those version numbers. Why Linus bumped to 3.0.0 then? Well, he apparently felt that the kernel has deviated so much from 2.x.x line, even with incremental changes, that it warrants a version bump.
Yeah sure, version the kernel after some guy who happens to be the excuse for some stupid religion. That would be something.
And Linus said it was time based. Third decade of kernel development.
This is what I am thinking, but I would use a two-digit year, no leading ‘0’, and no day of the month so the version above would be 11.5.2. I do not follow Linux kernel releases so I do not know if Linus has released more than one kernel in the same month, but if he has/will then the day would be included like so, 11.5.3.2.
You did put more thought in it then I did and I like it,
two digit year.two digit month.two digit patch version, like 11.5.2 is indeed far better the mine and is more in line with current version number.
Dates are (1) meaningless, (2) arbitrary and, worst of all, (3) non-uniform.
Until we can have all months with numbers of days divisible by something sensible, like 10 or 2, and until we can have years with a number of days divisible by something sensible, like 10 or 2, and until we can have a number of months divisible by something sensible, like 10 or 2, then I say “No thanks!” to date-based versioning.
Everything has a release date anyway. Why throw out the version number?[i][/i]
I wonder what he is making out of Fedora. Did he stuck with 14? Did he move back to KDE? Did he embrace GNOME Shell? Is he running it on fallback mode? Come on Linus, we need some input on this!
They could at least remove some deprecated APIs and ABIs. Or some ancient stuff like Vesa Local Bus for example.
So they changed number from 2.6.40 to 3.0, and what will be next? 3.0.1 or 3.1 ? I think there will be lots of scripts, build scripts, and other things in the world which will break. I really do not see what was wrong with continuing 2.6.x series. And do 3.0 only if some important ABI change will happen (like removing most of syscalls, and leaving only modern ones).
I guess they should have written better build-scripts, eh?
Thom,
the word is “fanfare” ( http://en.wikipedia.org/wiki/Fanfare ), not “fan fare”.
You need to capitalize the T in “the”. http://en.wikipedia.org/wiki/Capitalization
Edited 2011-05-30 18:03 UTC
Thanks. I turned off auto-capitalisation on my iPad yesterday, and apparently had no time to get used to it