Language Selection

English French German Italian Portuguese Spanish

why you don't rely on uname

Filed under

It is difficult to be angry at Linus for anything, on the count of how much good he did, and is doing to us with the whole idea of having Linux – it’s not like waiting for a GNU kernel would have helped – but honestly I feel quite bothered that he ended up making the decision of bumping the kernel’s version number like it was just a matter of public relations, without the need to consider the technical side of it, of software relying on the version numbers being, you know, meaningful. Which, honestly, reminded me of something but let’s not get that in front of us.

Let’s ignore the fact that kernel modules started to fail — they would probably be failing because of API changes without the need of anything as sophisticated as a version bump to 3. And let me be clear on one thing at least: it’s not the build failures that upset me – as I said last year I prefer it when packages fail at build time, rather than, subtly, at runtime.

At any rate, let’s begin with the first reason why you should not rely on uname results:

rest here

Dependency on 2.x.x kernel numbering is lazy programming

I would have thought programmers would have considered numbering scheme changes, just as they should have considered century changes in the late 20th century. Just because your kernel dependency check works this month, don't depend on it working 'forever.'

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Openwashing (Fake FOSS)

Android Leftovers

Slackware Live Edition – Beta 2

  • Slackware Live Edition – Beta 2
    Thanks for all the valuable feedback on the first public beta of my Slackware Live Edition. It allowed me to fix quite a few bugs in the Live scripts (thanks again!), add new functionality (requested by you or from my own TODO) and I took the opportunity to fix the packages in my Plasma 5 repository so that its Live Edition should actually work now.
  • Updated multilib packages for -current
  • (Hopefully) final recompilations for KDE 5_15.11
    There was still some work to do about my Plasma 5 package repository. The recent updates in slackware-current broke several packages that were still linking to older (and no longer present) libraries which were part of the icu4c and udev packages.

Leftovers: Software

  • Resuming work on Yokadi
    A few weeks ago we started working again on Yokadi, our command-line oriented, todo list. We are now finally ready to release version 1.0. This new version fixes a few bugs but does not bring new features. This lack of new features is actually a conscious decision: we wanted to make changes under the hood, and doing changes under the hood at the same time as adding new features is often a recipe for disaster.
  • remctl 3.10
    remctl is a simple and secure remote command execution protocol using GSS-API. Essentially, it's the thinnest and simplest possible way to deploy remote network APIs for commands using Kerberos authentication and encryption.
  • rra-c-util 5.9
    A minor release of my C utility library, including some changes required for the previous release of pam-afs-session and the upcoming release of remctl.
  • Feeding Emacs
    For the past fifteen years, I have been tweaking my ~/.emacs continously, most recently by switching to Spacemacs. With that switch done, I started to migrate a few more things to Emacs, an Atom/RSS reader being one that's been in the queue for years - ever since Google Reader shut down. Since March 2013, I have been a Feedly user, but I wanted to migrate to something better for a long time. I wanted to use Free Software, for one.
  • ELKI 0.7.0 on Maven and GitHub
    Version 0.7.0 of our data mining toolkit ELKI is now available on the project homepage, GitHub and Maven.