Slashdot Mirror


Linus on Kernel Version Numbering

walshy007 writes "In a recent thread it was asked what it would take for an 'unstable' 2.7 development tree to be created, to which Linus replied: 'Nothing. I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back. That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember. I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on "features" any more, so why should we do version _numbering_ based on "features"?'"

50 of 416 comments (clear)

  1. also known as kernel numbering by thrillseeker · · Score: 5, Funny

    version 2.0 ...

  2. Linus... by Gewalt · · Score: 5, Funny

    Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)

    --
    Modding Trolls +1 inciteful since 1999
    1. Re:Linus... by setagllib · · Score: 5, Insightful

      http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

      Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.

      --
      Sam ty sig.
    2. Re:Linus... by Daniel+Phillips · · Score: 3, Interesting

      Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)

      Rename article title as "Linus on Crack". You are right, Linus is now only Linux's second greatest advantage, Andrew Morton is the greatest. Linus has always been erratic but great. Lately, he really stepped in it a lot, but he is still maybe the best bug hunter that ever lived. Mind you, he tends to have a large hand in creating the horrible complexities that lead to the need for the bug hunt in the first place, but then if he did not we would never have the pleasure of watching him exercise his art.

            http://lwn.net/Articles/215868/

      And yes, I agree, Linus is on crack about the version numbers. Just drop the 2. at the beginning and it will all be fixed.

      --
      Have you got your LWN subscription yet?
    3. Re:Linus... by ivan256 · · Score: 4, Insightful

      The name of that file cleverly describes its contents, even though it is attempting to describe the argument it 'debunks'.

      You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer. Te fact of the matter is that it would *benefit* linux to force the developers of the various driver layers to have to consider interface stability when they make their changes. It would benefit the entire community to make it incredibly difficult for distributors *cough*redhat*cough* to change the driver API for a service layer and release the kernel with the same version number.

      Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.

    4. Re:Linus... by morgan_greywolf · · Score: 5, Informative

      This "no drivers" myth continues to be quite pervasive.

      There are lots of drivers, as long as you don't want to install something non-mainstream and you're okay with the binary blob drivers for the NVIDIA and ATI/AMD graphics cards (although, my understanding is that the ATI/AMD front is changing and AMD is pushing the specs out the community now).

      There are very good drivers for hardware in just about any class. Scanners, printers, digital cameras, webcams, video capture, bluetooth, USB, you name it.

      The trick is that you have to buy hardware that is known to work well and be supported on Linux. You might have to buy stuff that's a bit behind, too. Here's an example: the Epson Stylus C120 has a release date of August 2007. The Gutenprint driver for the C120 just appeared within this last month or so in 5.2 Beta releases (I think it's been available in the CVS for sometime). That means distros that keep up like Ubuntu will probably start supporting it in their next releases.

      So you had to a wait a year. Big deal. In that year, the list price dropped from $89.99 to $69.99.

      If you're one of those people that just HAS to have the latest hardware NOW, you're probably a gamer and should use Windows anyhow.

    5. Re:Linus... by Profane+MuthaFucka · · Score: 4, Interesting

      Might also point out that the kernel driver maintainers have a standing offer: anybody who provides specs gets a free driver written, maintained, and kept in the kernel. Companies should be developing hardware specs and taking advantage of all that free development work.

      Maybe what we should be doing isn't writing an NDIS wrapper for Linux, we need to write an NDIS wrapper for Windows. That way companies can provide the specs to the Linux team and then use the wrapper to drop them into Windows as they are written.

      --
      Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
    6. Re:Linus... by Hal_Porter · · Score: 4, Interesting

      Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.

      Exactly.

      It was written by Greg Kroah Hartman who famously broke the Philips webcam driver, causing the maintainer to quit.

      http://www.smcc.demon.nl/webcam/

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    7. Re:Linus... by fudoniten · · Score: 3, Insightful

      It's also why Windows is dying slowly. Attempting to be backwards-compatible with years of unmodifiable binary cruft, sucks.

      In the short run, the no-binary-drivers rule sucks. It means you can't use Linux and play your games. It also means that Linux won't win the desktop war overnight (though I would argue that allowing binary drivers would have killed Linux before it could win). In the long run, it's a huge win.

      There's practical reasons for the rule. Most of the kernel programmers are very--even notoriously--pragmatic. If they allow binary drivers...people will start making binary drivers. In theory, kernel developers wouldn't get blamed or harassed for problems with those drivers. In theory.

      In fact, though, most of the major problems with Linux (wireless and graphics) occur in the two areas where binary drivers are common. You think that doesn't affect the kernel developers? They don't want to deal with that bullshit, and good for them. I'm willing to wait until the better model wins.

    8. Re:Linus... by Nevyn · · Score: 5, Insightful

      You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer.

      Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.

      And, specifically from the kernel perspective, the usual example is the Solaris kernel in the 2.3/2.4/2.5 timeframe (memory is getting old) where they refused to fix a security bug because it would break ABI compatibility. So the corollary to your argument then is that Solaris kernel engineers are idiots?

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    9. Re:Linus... by 4prefect2 · · Score: 3, Insightful

      As a graphics driver developer, I have to tell you that the opposite is true in some cases. In the DRI, a graphics driver consists of three parts: the DDX, the DRM, and the 3d driver. In the current system, all of these components maintain stable ABIs with each other, and it's a nightmare. In fact, not being able to experiment freely with ABIs is one of the things that hold up the development of memory managers, and that in turn holds up a large number of advanced features (think render to texture, redirected direct rendering, ...).

    10. Re:Linus... by ivan256 · · Score: 3, Insightful

      To me (to many software developers), stability doesn't mean "backwards compatible forever"... It means a reasonable attempt to maintain compatibility, and a minimum committed duration that a particular interface will be supported.

      The attitude you describe does result in cruft, but that attitude has nothing to do with stability.

      Announce the intention to break compatibility at least two releases ahead. Roll multiple trivial changes into a single release instead of releasing them at the maintainers fancy. Specify the interface somewhere other than in the code so your third-party distributors can't get away with breaking the interface and calling their kernel "Linux" with the same version number as the upstream edition. That is stability.

    11. Re:Linus... by ivan256 · · Score: 3, Interesting

      Show me where I said it's easy. I said that changes are frequently trivial....

      Stability doesn't mean the interface never changes. Stability means that interface doesn't change on a whim... That small changes should be rolled up to minimize the frequency of changes. That compatibility changes should be announced well in advance. That two kernels with the same name and version number from multiple distributors provide the same interface... It means that backwards compatibility should be a goal, but not that you can't break it.

      "Stable" doesn't mean "supported forever". It means "changes as little as possible".

      I'm not sure how you derived the "Solaris kernel engineers are idiots" argument from what I said. Whomever (and I'm sure it wasn't an engineer) decided that maintaining compatibility was more important than fixing a security hole, is an idiot. If breaking compatibility is what you need to do to fix a serious issue, then you break compatibility. If you think I was saying meant that Solaris engineers should have been able to fix the security issue and still maintain compatibility, you need to go back and read what I said again.

  3. Stop Raggin' on 26 by Anonymous Coward · · Score: 5, Funny

    What did it ever do to you?

    Besides, it's accomplished a lot:

    In mathematics

    Inherent mathematical properties

    Twenty-six is a composite number, its proper divisors being 1, 2, and 13. 26 is the only number between a square number and a cube number, the numbers being 25 (5 squared) and 27 (3 cubed). This was first proved by Pierre de Fermat.

    It is the 7th distinct biprime (2.13) and the 5th with 2 as its lowest non-unitary prime factor. The aliquot sum of 26 is 16 with an aliquot sequence of 8 members; (26,16,15,9,4,3,1,0), leading to 0 through the prime 3 the 6th composite number so to do and so the sixth member of the 3-aliquot tree.

    There is no solution to the equation Ï(x) = 26, making 26 a nontotient. Nor is there a solution to x - Ï(x) = 26, making 26 a noncototient.

    In the classification of finite simple groups there are 26 sporadic groups.

    Properties of its positional representation in certain radixes

    Twenty-six is a repdigit in base three (222) and in base twelve (22).

    In base ten, 26 is the smallest number that is not a palindrome to have a square which is (26^2=676).

    Twenty-six is the number of five-digit prime quadruplets, the first of which is {13001, 13003, 13007, 13009}[1].

    In science

    Astronomy

  4. Excellent notion by MaulerOfEmotards · · Score: 5, Insightful

    Linus' idea to switch to date-based version numbering seems excellent to me. From a psychological perspective, humans have difficulties with numbers, especially larger numbers. Also, a purely incremental numbering system without any external relationships (let's call it "semantic anchors" or something) are just that: numbers. By using dates we tie in with an already establish cognitive category which not only tells us the version but also how old it is. Since we Linux folks are usually very conscious about keeping up-to-date (at least the /. crowd) it would be a good and automatic reminder of the state of our system. That is, we use the "date obsolescence effect" (the reason Microsoft stopped naming their software after the year released) to the advantage for security rather than the disadvantage of negative sales.

    1. Re:Excellent notion by TheGreek · · Score: 5, Informative

      (the reason Microsoft stopped naming their software after the year released)

      An excellent point, sir.

    2. Re:Excellent notion by KlaymenDK · · Score: 5, Funny

      Anyone who has problems with "large numbers such as 26" probably shouldn't be doing kernel coding ... just sayin' ;-)

    3. Re:Excellent notion by Tim+C · · Score: 5, Insightful

      which not only tells us the version but also how old it is

      Who cares how old it is? If it works and isn't known to have any stability or security issues (or at least not ones that affect your use of it), does it matter?

      Software that is newer is not inherently more secure, software that is older is not inherently less secure. I really fail to see how this "date obsolescence effect" helps improve security - I know version 20080213 is older than 20080601, but then I also know that 2.2.12 is older than 2.2.25. Neither of these schemes in themselves say anything at all about the security of the software in question.

    4. Re:Excellent notion by Tom · · Score: 5, Insightful

      date-based is good for continuous processes, which the development isn't and shouldn't be. From the user perspective, my primary concerns are comparisons - is this driver for my kernel version? Do I run the latest kernel version? Is this function available in my current version?

      Numbers are easier to compare than dates. They are also international, while dates aren't. 07.01. means 1st of July in some countries and January 7th in others.

      Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.

      That's why I hate MS year-based versioning system. "Word '97" tells me absolutely nothing about how it compares to '95, '96 or '98. A version number would at least tell me what the manufacturer thinks it's "worth" (even though with MS that was mostly a lie as well).

      And if Linus thinks that "big" (26, yeah right) numbers are a problem for people, then dates will be as well. Quick, how many releases were between 2.6.20 and 2.6.24? Good. Now quick, how many days were between January 17 and March 11? And... how many releases?

      --
      Assorted stuff I do sometimes: Lemuria.org
    5. Re:Excellent notion by bfields · · Score: 5, Informative

      Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.

      Kernel development no longer works that way--the current model is, every 2-3 months a new kernel is released, then there's a couple weeks to merge new work, then the rest of the time until the next release is spent tracking down regressions.

      There's never going to be another long-lived development branch: having years where all the real development went on in a kernel that nobody actually used caused all sorts of problems: bugs would pile up because the development branch wasn't getting enough testing, and distro's had to backport a lot just to be able to distribute "stable" kernels with the features and hardware support their customers needed.

      So the kernel version is *always* going to start with "2.6.". Hence the thought that maybe the version numbering doesn't explain the new process as well as something like "2008.07" might.

      And as for incompatibilities, they shouldn't happen. You should be able to drop a new kernel into an old system and everything should work--if not, report it as a bug. There's a few exceptions where some interface is dropped or change, but normally the assumption is that it's something that won't cause a problem for people--so if it does, speak up, they need to hear from you.

      (Of course, the above only applies to real userland interfaces, not to internal kernel interfaces. If you're trying to run a bunch of proprietary out-of-tree code (like the proprietary nVidia driver) inside the kernel, then you're on your own.)

  5. Open Source by LordHatrus · · Score: 3, Insightful

    The beauty of open source is that if you miss the odd-kernel numbering system more, you can fork the kernel and make your own! Yay! Enjoy maintaining both a stable and experimental code tree, constantly backporting important security fixes and features everyone wants, when you could just be modifying only one tree. Hope you have lots of free time!

  6. customers rely on "features" by Speare · · Score: 5, Insightful

    Er, you don't do a release for specific "features," but once the release has been made, customers rely on knowing what "features" are (or are not) in the release they're using. There should be a sane and rational comparison rule to know if one version is newer (and likely to have more good "features" and fewer bad "features") or not. Ubuntu uses dorky names but anyone who knows the alphabet and the comparison rule can at least decide if "Beaver" is older or newer than "Walrus." I don't care what the kernel uses, but it should be something people can figure out the ordering.

    Hey, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.43.-12b34_+omicron-rc6, or not?

    --
    [ .sig file not found ]
  7. It also reflects... by Junta · · Score: 4, Insightful

    It is in part semantics, but at the same time it also represents the core not ostensibly having a bugfix-only branch. Distributions fill in the gap there to an extent. But it does reflect a departure from a lot of common practice of having a branch to follow for those content with featuresets, but needing the security and bug fixes too. As of the no-2.7 branch, this was already the case, this truly is just semantics. But the 2.7 decision was about more than semantics.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:It also reflects... by gmack · · Score: 5, Insightful

      There are multiple bugfix only branches. 2.6.16.x to 2.6.25.x are all still actively maintained.

      The simple fact is that the new model has actually caused Linux distros to have more stable kernels now that vendors aren't trying to constantly backport things from the unstable branch.

      Shorter dev cycles were one of the best ideas Linus ever had.

    2. Re:It also reflects... by gmack · · Score: 5, Interesting

      Talk about rose tinted glasses.. The 2.4 /2.5 split that I remember left me at times with TWO unstable kernel series thanks to 2.5.x not being ready for production yet and maintainers trying to backport drivers and to 2.4.x so it could still handle the latest hardware.

      At the worst of it I recall setting up a state of the art server with a SCSI card that crashed randomly on 2.4.x and wouldn't boot on 2.5.x series kernels. Lucky for me the bug was fixed in 2.5.x a week later.

      The new way is easy.. new features and drivers get added to the latest 2.6.x-rc only and only bug fixes get added to the old kernels. This means that if I want to be sure I'm rock solid I just install the latest patch to the kernel I'm running and I can be sure no one has tried to add new features or drivers that would otherwise destabilize my stuff.

      Why anyone would possibly want to go back to the old way is beyond me.

    3. Re:It also reflects... by IntlHarvester · · Score: 3, Informative

      In the good old days, I could depend on 2.5 being bleeding edge and 2.4 being ready for production. Since 2.6, I either depend on a distro to track the kernel versions(which I do at home), or watch the kernel forums to see which should be the next "stable" kernel version (which we do at work).

      Haha, that's not what happened at all. The vendors forked 2.4 and backported all the fancy new 2.5 features. So most users were running something that was nothing like the 'official' kernel. Meanwhile 2.5/2.6 went into dev hell because it wasn't relevant for the people paid to develop Linux.

      Odd/Even was a nice simple system in theory, in practice it didn't work out so great.

      --
      Business. Numbers. Money. People. Computer World.
    4. Re:It also reflects... by Bill_the_Engineer · · Score: 5, Insightful

      The new way is easy.. new features and drivers get added to the latest 2.6.x-rc only and only bug fixes get added to the old kernels.

      You do realize that if you substitute 2.6.x-rc with 2.7.x, you are doing the same thing we've been doing when we had the experimental branch.

      The only difference is that we no longer have to update the minor number, otherwise we would be on version 2.8 (or higher) by now.

      This means that if I want to be sure I'm rock solid I just install the latest patch to the kernel I'm running and I can be sure no one has tried to add new features or drivers that would otherwise destabilize my stuff.

      I can see the advantages of the current version number scheme as it relates to the traditional desktop/server user.

      But you're lucky enough to not have to compile a driver for a non-mainstream piece of embedded hardware, and have to spend time updating the driver code because something that was probably flagged as deprecated in 2.6.8 was removed completely in 2.6.9. However in the old system, the function would be deprecated in the 2.6 kernel and removed in the 2.8 kernel. Under the old system, a driver marked for the 2.6 kernel would compile without modification, but I would expect to have to update the driver for 2.8.

      My point being that both number schemes has its advantages, it just the old system benefited me more. Now if we would tag versions that are considered a production release (like I suggested in my previous post), it would be a good compromise since you would continue to benefit from not having so many forks in the kernel and I would benefit by knowing where the removal of deprecated functions have taken place.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  8. Re:A suggestion by Anonymous Coward · · Score: 5, Interesting

    The previous post might sound like a troll, but it makes a great point. Debating over version number schemes feels even more arbitrary and trivial than debating over, say, Code names for projects. Do version numbers or project names really have that much of an influence on how well code is written? If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?

  9. Why versioning based on features? by Anonymous Coward · · Score: 3, Informative

    Well, at least with the kernel, it gave me an idea of whether I ought to expect a program to run with few problems, require recompiling to work with few problems or require porting and compiling to work with few problems.

    1. Re:Why versioning based on features? by MacColossus · · Score: 5, Insightful

      I agree. Exactly. It aids non linux developers in troubleshooting issues and knowing if package b will work with package a and kernel x or if I need to update to kernel y.

    2. Re:Why versioning based on features? by bryce4president · · Score: 5, Funny

      kernel x or if I need to update to kernel y

      So you are a fan of letter based versioning then?

  10. Re:A suggestion by bigstrat2003 · · Score: 4, Funny

    If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?

    The obvious answer is yes. It'd be 1337, of course it'd be better!

    --
    "16MB (fuck off, MiB fascists)" - The Mighty Buzzard
  11. Re:A suggestion by Darkness404 · · Score: 4, Informative

    Why bother with Linux?, get a proper OS. You know, one that doesn't make you create everything yourself, and hide stuff with obscure names in obscure locations, unique for the developer who shat it out.

    BeOS died long ago. And AmigaOS runs on specialized hardware. And OS X is UNIX-based so it does the "hide stuff with obscure names in obscure locations" and runs offically only on specialized hardware. And don't even get me started with Windows... So basically, all competition for OSes died after Windows 95. So either you get a UNIX-like OS such as Linux, or you get Windows.

    --
    Taxation is legalized theft, no more, no less.
  12. Re:A suggestion by cloakable · · Score: 4, Insightful

    You mean like where Windows hides the registry?

    --
    No tyrant thrives when every subject says no.
  13. Here's what I think by Godji · · Score: 5, Interesting

    (because surely someone must care)

    If the 2.6 is not going to change, drop it, it's redundant.

    So we're down to 26. I personally find a name like "Linux 28" to be cool. "Linux 41 was released today...". There's nothing wrong with big numbers: see udev.

    The problem with date-based numbering is that when you go from 2008.4 to 2008.10, it looks like you missed a few releases. And if you pre-announce a release, you have to meet your deadline or else rename the release.

    So they could do what Gentoo does - 2007.0, 2007.1, 2008.0, 2008.1, etc. But you still have the problem that every year, you lose count of how many releases have happened. Was there a 2007.2 or did we just go to 2008.0 because we missed the Christmas deadline due to that last-minute security bug?

    They could reduce the problem by using a longer period, such as a decade. (At 6 months for a release, for example, the number will only reach 20, which is not large.) But that's somewhat arbitrary. Plus, being in the 0th decade, we don't want to have 2.6.30 be called 0.3.

    To reduce the complexity on all that, just drop the dates, and what's left is a single big number. No dots, no multiple numbers, easy. Linux 112 is fine by me.

  14. Re:A suggestion by Erikderzweite · · Score: 5, Informative

    What has the kernel to do with printer drivers? It has always been CUPS domain.

    Besides, it's not like they don't want to support all the hardware available, it's win-only hardware manufacturers that are the main obstacle towards better hardware support in linux.

  15. Version 2.6.26? by pr0nbot · · Score: 5, Funny

    Can anyone help? I installed the 2.6.26 kernel on my pentium, but it keeps saying I have version 2.6.25999999999993 installed?

  16. Re:A suggestion by fatboy · · Score: 3, Funny

    What has the kernel to do with printer drivers? It has always been CUPS domain.

    Back in my day, used lpd, AND WE LIKED IT!

    --
    --fatboy
  17. Re:A suggestion by mpapet · · Score: 4, Insightful

    Your comment conveniently ignores his role in the project. It seems like he doesn't really work at the nuts-and-bolts level of driver development. His comments lately lead one to believe he's pretty satisfied with the overall status of the kernel such that issues like this are important to him.

    I know you and the moderators are not satisfied with some aspects of the project, but you would be barking up the wrong tree.

    --
    http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
  18. Comment removed by account_deleted · · Score: 4, Insightful

    Comment removed based on user account deletion

  19. Re:A suggestion by Tim+C · · Score: 3, Informative

    If Windows had a kernel numbered 1.33.7

    Funnily enough, the build number of Windows XP is 2600.

  20. I like version numbers that tell me something by Cro+Magnon · · Score: 4, Insightful

    If I see a version number of 2.00, I can ASSume that there are significant changes from 1.X. Also, as an "ohoh" version, it's more likely to have bugs than 2.1.

    A year-based version tells me when it was released, but not much else. Maybe there was a major change in August, and V2008.08.01 is an "ohoh" version.

    Named versions tell me even less. I might ASSume that "Perfect Penguin" is later than "Ornery Onyx", but I don't know how much has changed, or how long it took to release.

    --
    Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
  21. Re:A suggestion by inode_buddha · · Score: 4, Insightful

    The POSIX API is hardly obscure, nor are the file system and naming conventions. It's an ISO standard FFS!

    --
    C|N>K
  22. correcting this for you... by Anonymous Coward · · Score: 5, Funny

    _O_
        |
    _/|\_
    me

  23. Why tell hardware manufacturers what to do? by Tetsujin · · Score: 4, Insightful

    "The way to fix this is to mandate that hardware manufacturers publish detailed specifications based upon which FLOSS drivers can be written."
    Why?
    Why should tell a hardware manufacture what they can and not do?

    Because if I am their customer, then I want them to act in a way that serves my interests. That is part of what I want for my money. I understand that I can't expect full indulgence from every hardware manufacturer - but I want them to understand, when I buy a piece of hardware I also want to have all the information necessary to make use of it. That is the message I want to send.

    If you don't want to send a similar message, that's your business. I won't tell you you should think otherwise.

    --
    Bow-ties are cool.
  24. Re:Define "lots" by u38cg · · Score: 4, Interesting

    This is bollocks. I no longer bother to check whether the hardware I buy is Linux compatible; I assume if it's selling in large quantities it will work. And it does. Maybe I'm lucky, but all the Linux users I know hold a similar view: hardware drivers are no longer an issue. Just for giggles, I recently had to reinstall Windows and my main desktop. Ubuntu took me an hour to install, and another hour to install all my favourite programs. Two weeks later, I have given up on finding a windows driver for an old Canon scanner that Ubuntu is more than happy to talk to. And don't talk to me about having to explain to India that no, I am not pirating Windows, I am merely reinstalling it, because it is so crappy that that is the only way to keep it functional is to reinstall it six-monthly.

    --
    [FUCK BETA]
  25. Lots of changes from 2.6.n to 2.6.n+1 by aegl · · Score: 5, Insightful

    Several slashdot readers have made comments like "I can easily upgrade from 2.6.n to 2.6.n+1 because not much will have changed".

    This is all part of the delusion of version numbers. The changes between releases are only limited by how many can be squeezed into the merge window. With an increasing number of developers, and development tools that seem to be scaling the overall trend seems to be that the n+1 release is progressively more different that its predecessor. Here are the diffstats for the last few kernels:

    2.6.15 -> 2.6.16 6721 files changed, 392461 insertions(+), 202469 deletions(-)
    2.6.16 -> 2.6.17 6321 files changed, 416664 insertions(+), 308709 deletions(-)
    2.6.17 -> 2.6.18 8972 files changed, 381890 insertions(+), 217058 deletions(-)
    2.6.18 -> 2.6.19 8040 files changed, 515161 insertions(+), 291784 deletions(-)
    2.6.19 -> 2.6.20 5825 files changed, 262475 insertions(+), 136162 deletions(-)
    2.6.20 -> 2.6.21 6568 files changed, 319232 insertions(+), 175247 deletions(-)
    2.6.21 -> 2.6.22 7620 files changed, 519591 insertions(+), 266699 deletions(-)
    2.6.22 -> 2.6.23 7203 files changed, 406268 insertions(+), 339071 deletions(-)
    2.6.23 -> 2.6.24 10209 files changed, 776107 insertions(+), 483031 deletions(-)
    2.6.24 -> 2.6.25 9738 files changed, 777371 insertions(+), 404514 deletions(-)
    2.6.25 -> 2.6.26 8676 files changed, 595389 insertions(+), 416139 deletions(-)

  26. Re:A suggestion by Anonymous Coward · · Score: 3, Funny

    If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?

    I painted racing stripes on my car so it can go faster

  27. Stick with major.minor.patch by Todd+Knarr · · Score: 4, Insightful

    Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).

  28. Re:A suggestion by uzytkownik · · Score: 3, Insightful

    Also the names are not very helpful. Imagine the configuration of apache was in files named as /etc/apache/{6f35ff5c-5bcc-420d-a1f4-8e37af8eaf06}

    --
    I've probably left my head... somewhere. Please wait untill I find it.
    Homepage: http://blog.piechotka.com.pl/