back to article May the fourth be with you: Torvalds names next Linux v 4.0

Linus Torvalds has decided it's time for version 4.0 of the Linux kernel. The Linux lord has been wondering about Linux kernel release numbering for a while, notably in a Google+ post last week. He now seems to have taken the plunge, by declaring that the version of the kernel he's working in is “Linux 4.0-rc1” in this post …

  1. Nate Amsden Silver badge

    don't break compatibility since forever

    So binary drivers built against 2.6 will work fine against 4.0 huh? Yeah, that's what I thought. Breaking compatibility seems to be by design.

    Of course I gave up on hopes of Linux ever getting a stable ABI for drivers probably 10 years ago.

    I do miss the even odd releases of what was it 2.2.x and 2.3.x? days? where one was feature and one was stable. Course since they abandoned that concept I abandoned the thought of compiling kernels ever again.

    (Linux user for 19 years - desktop linux for past 17 years including now)

    1. Anonymous Coward
      Anonymous Coward

      Re: don't break compatibility since forever

      Thank you for a refreshing shot of reality. Served cool but hardy, a nice change around here.

    2. Voland's right hand Silver badge

      Re: don't break compatibility since forever

      Seconded - you do not compile a kernel nowdays unless you are a developer. I developed and maintained some patches versus one of the architectures for 3 years and even if you are doing it day to day trying to keep up versus head and have a stable shipping version at the same time is utter nightmare.

      As you - I would love to see the old even/odd system from days past back if not for any other reason, because you could submit fixes and improvements versus the stable and the maintainers considered it normal to port them themselves to the "odd" one. That is gone - you submit versus latest and greatest and anyone with ideas about seeing a backport versus one of the long term stables (3.2, 3.4, etc) can leave all hope entering here.

      1. linicks
        FAIL

        Re: don't break compatibility since forever

        "you do not compile a kernel nowdays unless you are a developer"

        Strange, I do on my server and my notebook at least once a week - and I am not a developer?

        1. linicks

          Re: don't break compatibility since forever

          I dunno why I got down modded for this. I ain't a developer, just a hobbyist. Ever since I got GNU/Linux around 1999 I was intrigued that I could do what I wanted (much like the early 80's with my Spectrum/Atari machines).

          So I learnt to build stuff from source... this lead up to doing kernel builds, and I have done it ever since. I build kernels without module support as I just tailor them for the hardware I have. Same with userland programs - I just build them with the options I need/and or change the code to fix things that I don't want/need/or breaks.

          So I am a hobbyist not a developer (albeit I have had a few kernel patches accepted over the years, but mostly that was to fix dodgy hardware I had) - but I build my own kernels without being a developer.

        2. Goobertee

          Re: don't break compatibility since forever

          >>"you do not compile a kernel nowdays unless you are a developer"

          >>Strange, I do on my server and my notebook at least once a week - and I am not a developer?

          Loverock? Is that you?

      2. yossarianuk

        Re: don't break compatibility since forever

        It was only badly made applications / (closed source) drivers that had an issue with the 2.6 -> 3.x change

        Hopefully lessons were learnt then...

        Anyway it was trivial to use the uname26 application to make apps/drivers compatible with kernel 3.x

        https://kb.wisc.edu/cae/page.php?id=22435

    3. Anonymous Coward
      Anonymous Coward

      Re: don't break compatibility since forever

      >Breaking compatibility seems to be by design.

      It's a monolithic kernel, what do you expect?

      When your drivers are operating using C functions where the API may change the drivers will break.

      1. Oninoshiko

        Re: don't break compatibility since forever

        Solaris went through two major versions without breaking ABI compatibility. I know this because I took a 3rd party driver built for 8, and used it on Opensolaris/Indiana. I don't know if Oracle changed things though.

        Solaris is a modular monolithic kernel, the same as Linux.

        1. Alan Brown Silver badge

          Re: don't break compatibility since forever

          "Solaris went through two major versions without breaking ABI compatibility"

          You didn't try moving from 4.1.3 to 5.0.1, did you? That's when the "slowaris" moniker popped up.

          All those "solaris 8, 9, 10" builds are minors: 5.8, 5.9, 5.10 etc

    4. This post has been deleted by a moderator

    5. Anonymous Coward
      Anonymous Coward

      Re: don't break compatibility since forever

      "Of course I gave up on hopes of Linux ever getting a stable ABI for drivers probably 10 years ago."

      Not to mention a proper modular network driver stack like Windows so that things like hardware acceleration don't require kernel hacks...

    6. alain williams Silver badge

      Re: don't break compatibility since forever

      That is because the ABI compatibility that Linux it talking about is *userland* ie programs. Compatibility within the kernel has never been a design goal - they want to be able to change the way that things work so that they can do things in new/better ways.

      That is not at all a problem because all device drivers should be within the kernel tree and thus be recompiled (after perhaps some code changes) with a new kernel.

      Binary device drivers are an anathema in the Linux kernel world -- so if you do it, what do you expect ? -- it was never intended to work in the first place! Everything in the kernel is supposed to be Open Source.

      So: don't complain about something that was never a design goal.

      1. Daggerchild Silver badge

        Re: don't break compatibility since forever

        Seconding the 'Compatability != ABI. Compatability == Userland' foreverfact.

        The organisational benefits far outweigh the inconvenience (ask any MMO raid that has to wait for afk members). You aren't kept down by them, they have to keep up with you. There are *more* of them than there are you, so distributing this responsibility to them, forcing them to be aware of their (naturally hazardous) environment seems perfectly sensible to me.

        This means code without an active maintainer naturally dies. I'm afraid this is healthy.

      2. Zolko

        Re: don't break compatibility since forever

        That is because the ABI compatibility that Linux it talking about is *userland* ie programs.

        not to mention that people have asked userspace drivers for ages. Now claiming that the kernel is compatible with userland when they refuse to let drivers in userland is a bit rich.

        The problem being: userland ie programs. No, userland is whatever is not kernel space, and in Linux userland is programs, but that doesn't have to be. There was a thesis by a German guy who made changes to the FreeBSD kernel to allow userspace drivers, seamlessly.

        This could happen with Linux if the even&odd naming scheme had been preserved, instead of the current lazyness à-la Windows: "Hey, let's put everything in the kernel, it's sooooooooo much easier". If a user can plug and unplug a device, that's userland: what is there not to understand about that ? A USB stick driver, a USB joystick driver, a video screen driver, must logically be in userspace: they are industry standards, FFS ! Of course that scheduler and memory management must run in kernel space.

        If I had time, I would dump Linux and switch over to FreeBSD. The systemd debacle might actually provide the necessary incentive. Yeah, monolithic kernel my arse.

    7. P. Lee Silver badge

      Re: don't break compatibility since forever

      2.6 came out in 2003, which is "forever" ago (in my book), when they still did even-prod, odd-dev numbering (which I rather liked). 2011 was the last release of that kernel.

      I seem to think Linus said kernel-internal interfaces are always open to change, though user-facing ones are not. Is that correct? We still have 3c509 NIC drivers, so I'm guessing it isn't too difficult to keep drivers up to date.

      I know there are certain long-lived systems, but this is open-source. If there is a business case for the drivers then upgrade them, if not, leave them as they are. If you can't do it yourself, pay someone who can - I'm sure many devs are open to having cash thrown at them. You aren't left high-and-dry without source code here. I seem to think CheckPoint were still running 2.6 kernels fairly recently.

  2. DougS Silver badge

    Beat me to it

    Linus' definition of breaking compatibility is different than that used by Unix vendors, or even Microsoft. Linux 3.19 isn't 100% compatible with with 3.18, but maybe he's talking about 3.19.x being compatible with 3.19.0. Not a hard target when 'major' releases are popping out every three months!

    Granted this isn't an issue for most users, but it sure makes stuff that has to touch the kernel like VMware a pain - every time I install an updated Fedora and install VMware I have to scan the vmware forums to find a patch some guy has cooked up because Linux's driver ABI changes with every point release.

    Not a terrible thing, but Linus is in major denial if he thinks Linux never breaks compatibility!

    1. Wensleydale Cheese Silver badge
      Thumb Up

      Re: Beat me to it

      DougS wrote: " every time I install an updated Fedora and install VMware I have to scan the vmware forums to find a patch some guy has cooked up because Linux's driver ABI changes with every point release."

      I had the same problem with VirtualBox when I was using Fedora. It was nice using the bleeding edge stuff that Fedora had but it was simply taking too much of my time so I moved to something more stable.

      VirtualBox itself has got much better in dealing with this and even tells you the command to run to do the necessary rebuild (you do need to have installed the kernel development stuff and headers yourself though).

      1. DougS Silver badge

        Re: Beat me to it

        VMware includes source for what it needs and automatically does the rebuild, has done so for years. That doesn't help when the ABI changes - the rebuild fails and that's when you need the patch.

  3. 45RPM Silver badge

    The mans a lunatic. A very clever lunatic, responsible for an excellent OS, but a lunatic nonetheless. His version numbers mean nothing. He might as well just give them silly names.

    The thing is, a version number should mean something. It should give the user an inkling of what they'll be getting. Personally, I'm a bit fan of x.y.z (foo) where x is a major revision or rewrite, y is a minor revision, z is a bug fix and foo is the build number. I don't care how big the numbers get. I'm a big boy. I can count quite high.

    His weird obsession with keeping numbers small is - odd. Never mind, I suppose he can't be good at everything - and I suppose it's better for the world that he's good at kernel programming than that he's good at counting (even though I would have though basic numeracy was a prerequisite)

    1. Anonymous Coward
      Anonymous Coward

      I think he's pretty much just a project manager on the kernel these days.

    2. Nigel 11

      The thing is, a version number should mean something. It should give the user an inkling of what they'll be getting. Personally, I'm a bit fan of x.y.z (foo) where x is a major revision or rewrite, y is a minor revision, z is a bug fix and foo is the build number. I don't care how big the numbers get. I'm a big boy. I can count quite high.

      Thing is, who decides what is major? This scheme way work for an application, but for a kernel? One for which much of the code is optional, and may not even be compiled-in (or even compile-able) on the system you are using?

      Take btrfs becoming production-ready. That's pretty major, if you want to use some of the advanced features like near-infinite snapshots or de-duping. On the other hand if you are doing quantum chemistry on some massively parallel network of wafer-scale integrated CPUs, btrfs might be of little interest. Something obscure to do with locking in massively parallel environments, on the other hand ....

      1. 45RPM Silver badge

        @Nigel 11

        How about using the x for a significant rewrite or for multiple new functionalities that will affect everyone, y for a significant addition, whether or not it benefits everyone, and the z for bugfixes. I don’t see why the kernel should be given special exemption in version numbering - and it seems to me that x.y.z works just as well as it would for any other software.

      2. sawatts

        Thing is, who decides what is major?

        Compatibility (technical) or responsibility (commercial).

        In this scheme, major versions (x) don't promise any compatibility with other major versions - so are used both when the product is rewritten, or to draw a line under a previous release sequence. We may interpret the Linux kernel 4.0 as the latter.

        Minor versions (y) should be backwards compatible within the major release; while update or bug-fix versions (z) should be backwards and forwards compatible within their minor release.

        The downside to choosing to move to a new major version number is customer perception of increased risk - which is mitigated by waiting for some indication of stability, such as a couple of more minor releases.

    3. fandom Silver badge

      "He might as well just give them silly names."

      And that's why v4.0-rc1 is actually called "Hurr durr I'ma sheep"

      The numbers are there for legacy reasons as some people insist they are significant.

      But then, some people are just weird.

    4. no-one in particular

      > The thing is, a version number should mean something...

      Such as, marketing wants to change the name and "update our image" with a new colour scheme, so that means the major version number goes up.

    5. Hans 1 Silver badge
      Happy

      >He might as well just give them silly names.

      He gives them silly names ... Linux 3.11 was Linux for Workgroups

      >His weird obsession with keeping numbers small is - odd.

      Do you work for Mozilla ? When is Firefox 69 scheduled for release ?

  4. wolfetone Silver badge

    Finally

    I'll be able to get Linux 4.0 NT.

  5. linicks
    Alert

    It's actually...

    ...Linux 34.0-rc1

    https://lkml.org/lkml/2015/2/23/50

  6. Nigel 11

    Pity ...

    Personally, I'd have reserved 4.0 for "world domination", or at least for the day that Microsoft abandons its own NT-derived kernel and goes over to an open-source kernel derived from Linux.

    Still, it's just a number.

    1. Daniel von Asmuth Bronze badge
      Windows

      How much longer do we have to wait

      for Linux 10??

      1. P. Lee Silver badge
        Coat

        Re: How much longer do we have to wait for Linux 10??

        Right after Linus has had a few beers, we'll get Linux X...

        1. Anthropornis
          Coat

          Re: How much longer do we have to wait for Linux 10??

          Some of us want one that goes to eleven.

    2. Tom 13

      Re: Pity ...

      Always look on the bright side. This may be the occasion on which Linux will go Forth and conquer.

  7. picturethis
    Mushroom

    Probably going to get downvoted, but here goes..

    1) I like Linux, I use Linux every day (along side Windows 7, Windows 8, Windows 10)

    Unfortunately it's Linus' behavior such as this controversy over versioning and, what should be, a relatively straight forward approach. Unfortunately Linus, while brilliant, shows a somewhat lack of maturity in certain aspects of software development. What it comes down to is that he has demonstrated frequently that the Linux kernel is "his ball" and he will "take it home" if we don't play the game the way he likes. Fine, it's his ball.

    But, if he really wants to see Linux on the Desktop in his lifetime, his behavior would have to change. My impression is that to Linus, Linux is a software project that he enjoys working on. The fact that the rest of the world may use it, isn't really of any importance to him. The fact that he's never really had a job where he wasn't in complete control of a project's decisions just shows.

    Linus as a developer = GREAT, Linus as a product manager = not so great. I don't like making this a personal matter, but he chooses to imprint his personality on the Linux kernel in the most visible ways possible. That's just not a good approach for the long term.

    Maybe it's time for an alternative (non-linux) kernel to go along with alternative distros? I actually shudder to think what is going to happen to kernel dev once he is no longer working on it (for whatever reason).

    As far as versioning goes, any approach is good, as long as one defines it and sticks to it. But he is not even willing to do that. Personally I've always used: Major = not guaranteed to be backwards compatible + new features, Minor = guaranteed to be compatible within same major + minor enhancements, Build = bug fixes. This seems to work pretty well for me.

    Congrats, if you got this far.. (TL;DR)

    1. James Hughes 1

      Re: Probably going to get downvoted, but here goes..

      "Linus shows a lack of maturity"

      Well, almost every developer I've ever met (including me) shows a lack of maturity in one way or another.

      "Linux on desktop"

      Is that really what he wants to see, or does he just not care a jot, given the OS is used on the top 10 supercomputers, in every android phone, in huge numbers of household devices?

      "Project manager"

      I'd have to say that as a project manager he has done quite well. Most project managers I have worked with would not have got Linux to the place it is now. Since there is no other open OS project that has got anywhere near close to Linux, it would appear that is quite the success.

  8. /dev/null
    WTF?

    “So on the whole, I wouldn't read too much into the number.”

    That's a shame... proper, rationally thought-out version numbering can be very useful in conveying information. See, f'rinstance, the NetBSD release glossary for how it should be done.

  9. dz-015

    Somebody used Google+ for something?

    No wonder this story is in the news.

  10. Tom 13

    Seems Linus has done something to warm the cold cold cockles of my heart

    “But hey, I asked, so I'll honor the votes.”

    Having seen far too many execs put forth surveys expecting results that would back their pre-determined decision only to get flustered when they didn't agree, this is something which I heartily applaud.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019