Page 3 of 3 FirstFirst 123
Results 21 to 24 of 24

Thread: Linux 3.12 Kernel Released; Linux 4.0 Planning Talked Up

  1. #21
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by mercutio View Post
    ubuntu numbers after release date, so 13.04, 13.10 etc.
    I think Ubuntu has the best version naming model, clear and concise. And even though most of their code names sound silly, they are a simple and user friendly way to identify them, so I like that, too.

  2. #22
    Join Date
    Apr 2008
    Posts
    182

    Default

    Quote Originally Posted by DanL View Post
    Kernel version numbers are fairly meaningless. You can't really tell anything about the kernel just from the version number unless you follow Phoronix or some other kernel news source. If the pattern continues to repeat, you may be able to tell which kernel is an LTS and which kernel a distro will use, but that's subject to change very quickly.
    Well, it depends, before the late 2.6.x cycle and switch to 3.0, the kernel version WERE meaning something precise.


    last:
    2.2.x = mainly bugfixes or micro features over the previous one.

    middle:
    with split: odd = devel/unstable, even = production.
    2.3.0 = starting to develop a bunch of new features, introducing new file systems, introducing new sub-systems in the kernel
    2.4.0 = new features are deemed "stable", making an stable release for the world to use and benefits from all the improvement in th 2.3 release.

    first:
    0.9 = Linus uploads kernel on FTP and let rest of the world backup it for him
    1.0 = first stable kernel.
    2.0 = complete revamping of the architecture. It's not simply adding a brand new USB sub-system, or rewritting the packet-filtering system. It's about re-doing the modularity of kernel.
    3.0 = following the old version scheme, should have come when 2.x series god completely rewritten and re-architectured beyond the few subsystem (Linus himself jokingly said that would be when he rewrites the kernel in a special dialect of Message-Passing Visual Basic)

    This did work at the beginning because the kernel was much smaller and development was done in lock steps.
    All new features/subsystems, etc. where developped together in an odd version, like 2.1 and then all the new stuff released at once in 2.2. With subsequent 2.2.x being only bugfixes.
    2.2.0 and 2.2.47 are more or less compatible.

    What had happened it that Linux actually grew bigger. Subsystem weren't all written at the same time. The kernel didn't change completely with each release. Instead some subsystem were urgently needed and were introduced before the next 2.7.x kernel, and were actually already thrown in the 2.6.x cycle. Other things are showing signs that they are NOT GOING to move at all for a long time, because they are good enough for now. Other things were developed but not as much at the same pace.

    Thus the 2.6.x series was a weird one. Between two closely related 2.6.x number (say from 2.6.4 to 2.6.5), not much had changed (as it was always the case in previous 2.4 ans 2.2 series, when such things where only bugfixes) but if you took numbers more appart (say 2.6.1 and 2.6.8 and 2.6.18, etc.) things weren't compatible anymore. So much "small things" did change, that they all add up and you end up with almost as many change as between 2.0 and 2.2, etc.

    The development model has organically changed from a unstable/stable alterning with strong versionning, to a continuous development model.

    If things were kept the same, you would end up with a kernel version 2.6.876 pretty quickly. Which wouldn't have anything in common with 2.6.
    But with no exact transition on the timeline. In stead, a long continuum of version between 2.6.1 and 2.6.876, each only adding a small part (change of 1 subsystem, addition of 1 or 2 filesystems) but overall so many small things adding up that after 875 intermediate, nothing even barely ressemble the beginning (whereas 2.2.0 and 2.2.47 are all mostly the same).
    (again no clear transition, just lots of cummulative small changes).

    The alternative would have been bumping the middle number each time a new sub-system is added. But then you would have also lots of aberrations. Like reaching 2.451.0 pretty soon. (but at least you know that this one is perfectly compatible with 2.451.1 and 2.451.3, but 2.450.4 and 2.452.0 have a rewrite in one of the subsystems. Say 2.452.0 introduces btrfs) or bizarre number sequence (so okay, you here that one team decided to develop a new packet filtering system. So you decided to call that 2.317.0 - odd number because it's still in development. But before they finish and stabilise (and you thus introduce 2.318.0 to the world) another team finishes porting a GPLed ZFS: how will you call that?! 2.320.0? 2.318.0 and change the net-filter team's version?! Now multiply this by the number of subsystems that are developed in parallel).

    That's why lots of software move to a different numbering scheme after a while:
    - before development happened in discrete big leaps.
    - now it's just a lot of micro-jumps. No new version is radically different. Each is only an improvement of a subpart. But it all adds up.

    Linux moved to 3.x versions. Firefox decided to bump up major numbers (and scare the shit of some sysadmins, even if the difference between, say 21 and 22 aren't as big as between 1.0 and 2.0 and 3.0, and deploying 22 should be as smooth as 21, except for that one single specific feature, but it should be possible for your IT department to monitor exactly which specific features it depends and only test for those).

    Quote Originally Posted by leif81 View Post
    I personally really like semantic versioning http://semver.org
    Semantic versioning works nicely for small to mid projects where all the development happens in lock-steps.
    pidgin version 2.6 added quite a few new things upon 2.5, but didn't break anything.
    pidgin version 2.0 was a complete rewrite using GTK2 and changed pretty much everything - up to the point that not 1 single 1.x plugin could work in 2.x
    pidgin version 2.10.7 fixed a bug in a few of the protocols.

    Firefox and the Linux Kernel have become much larger than that (and i feel that this will also be the case with pidgin after 3.x)
    Development doesn't happen in lock-steps
    Nobody will change everything at once (Linus will NOT start rewriting the whole kernel from scratch in message-passing VB.net as he joked before). Only small parts change at once. but all parts end-up changing *eventually*.
    You can't do semanting versionning (at least not on the whole. Subsystems could have their own internal semantic versions).

    Either you end-up always bumping up the major incredibly fast, because almost every new version you publish change some subsystem, and thus fucks up everything depending on it (but only things depending on it. The other 99.7% of plugins/software are completely un-affected, and even un-aware of this fact). That the way Mozilla choose for Firefox. (firefox 24 introduced "ASM.js" thus completely changing the way you do optimised javascript for it. But if you're not a developer of emscripten, you absolutely don't care about this. Adblock will work in 24 just as fine as in 23 an nobody will notice. Just like about every other software/plugin/app which is not Bannana Bread)

    Or you could only bump minor, because overall things don't change that much. Only 0.245 % of all software will be affected by the chance and break - beside these few exceptions, you're not breaking anything only introducing new features. And you end up with a major that will never ever move up. That was the case of Linux kernel during the 2.6.x cycle. things were heading toward a kernel version 2.6.91094 (which doesn't add much to 2.6.91094, but over time has grown completely incompatible with 2.6.3)

    Or you scratch everything and move to a different numbering scheme. New and completely arbitrary (that's the situation you have now with Linux 3.x). And most end-users don't care. Only integrator care, and follow specifically what interests them. If your into graphics you'll be following when the kernel will introduce its move from DRI2 to DRI3 (hey, subsystem with an almost semantic versioning !) and whatch out for these changes because you depend on them. If you're using the API to interface with joysticks, you don't give a fuck about anything, because it didn't move since the kernel 2.6 and its introduction of /dev/input and won't be introducing anything else for a while.

    Quote Originally Posted by ciplogic View Post
    But compared with real software like Windows, which in one year they make the "desktop is a tile", and anyone should write WinRT, Linux is more predictable. GTK+ 2 to 3 was a minor change by all standards, KDE 3 to 4 too.
    ...and don't forget "ribbons". The previous stuff Microsoft was in love with.

  3. #23
    Join Date
    Oct 2012
    Posts
    148

    Default

    Quote Originally Posted by leif81 View Post
    For a guy who runs such a tight ship it's pretty surprising how useless the Linux versing numbers are.

    I personally really like semantic versioning http://semver.org
    all changes added to Linux are done so in backwards-compatible matter. If Linux used semantic versioning we would still be at 1.x.y, with x being 3 digit number.

    In other words, for kernel it doesn't make sense.

  4. #24
    Join Date
    Apr 2013
    Posts
    134

    Default

    Seems to be than the kernel works better for games, but, now heats a lot, even with dpm activated. Kernel 3.11 works great in that aspect, but seems to be than is not the same for 3.12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •