Linux & Simplicity

A while ago, I posted some thoughts on Linux installing.  Just today, I came across this blog post, which covers kindof the same things.  The problem that seems to exist now is that there are multiple ways to do things.  Not that it’s a bad thing; but there’s no real standard way to do it.  Everybody wants to come up with their own way of doing things, as commented on in this article.  New tools are fine, but what should be happening is have these new tools simply provide new ways of accessing/modifying information, not as replacements.  Why is there a separate service that runs for adding users?  That utility has existed ever since UNIX came around.  It’s impossible to actually figure out what file is actually being used at any point in time.

This lack of standardization is really killing me here.  Just today, I was trying to install gnome-common for some development work, and it put it in /usr/local/share/aclocal.  Which is fine, except that the way aclocal is configured on Ubuntu 12.04 it should actually be /usr/share/aclocal.  WHY IS THIS DIFFERENT?!

This is, again, where Windows is better.  Each program has its own, special folder, typically in Program Files.  All the .exes, dlls, images, etc. go in there.  It’s essentially a self-contained unit.  You have the system registry to tell you information about programs, some variables needed, and where they are.  Granted, the system registry is abused quite often.

So, here’s basically what I think needs to happen:

  • Programs should have their own folder that they store all of their .so, executables, images, etc in.
  • Paths need to be better defined, i.e. where to put something, does it go in /usr, /etc, /local, what?  Currently, programs are scattered all over the place, and shared libs also
  • The only shared libraries that should go in the shared library folder(i.e. /usr/local/lib ) are actually shared libraries,  stuff that is used by more than one program.  If you use it only for your program, that goes in your program folder
  • There should be some kind of registry.  This would probably hold information like where to find something, and would essentially be an extension of environment variables, but for all users.  For example, let’s say that you have two different daemons that provide some service.  This registry would point at the daemon that you want to use – as long as their APIs are standardized, it shouldn’t matter which one you’re using.
  • APIs need to be standardized.  There doesn’t seem to be one “true” way to do anything.  As we can see, you can use one of several interfaces to do the same task, which all do something slightly different.

Maybe this would be a good time to split off something new from Linux.  In addition to doing the above standardization, this is also what I would like to see:

  • Get rid of X.  Sure, X is fine and all, but maybe Wayland would be better?  X is annoying to use, and it was designed for something else than what it is being used for now.  Something simpler, with built-in support for modern APIs(such as OpenGL) would be great.
  • Get rid of the SysV init interface.  Use Upstart instead, completely deprecate it.
  • Any new programs and APIs should not replace old programs, such as useradd or usermod.  They should simply provide a new way of doing it.

Well, that’s a mostly disorganized post.  Braindump complete.

2 thoughts on “Linux & Simplicity

  1. While I agree with lots of your points, there is much for you still to learn regarding other points.

    We do have some standards, but not everyone abides by them. See the following.

    Also /usr/local vs /usr. Because you are installing a package for development (I assume it would have been a “make install” or similar), you actually don’t want it in /usr where it would conflict with any packages already installed. Instead, it goes into /usr/local which depending on your system, should be setup to be queried before /usr, so your development packages would get priority over the installed ones.
    A quote from the above link.
    Historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network). Most of the time /usr/local/ is used for installing software/data that are not part of the standard operating system distribution (in such case, /usr/ would only contain software/data that are part of the standard operating system distribution). It is possible that the FHS standard may in the future be changed to reflect this de facto convention).

    I hope that helps you understand some of the oddities more.

    As the author of the blog post you linked to, I’m totally for standards and not changing of some things are done for the sake of adding complexity.

    Oh, and as for a “registry”…. I have a great book you can read on that. We already have a registry of kinds, each application has a folder under a standardised location (used to be a dot folder in the home dir, now days I think its in ~/.config or ~/.local depending. And then in that dir, the program can put it’s registry items, which are hopefully plaintext files. My biggest issue with Windows registry, is that you can break so much by breaking one little bit. With our Unix registry, you can generally only break the program that’s config file is broken. And with a text editor, you can generally fix it! The book is “The Art of Unix Programming” and is also available online at

  2. >Instead, it goes into /usr/local which depending on your system, should be setup to be queried before /usr, so your development packages would get priority over the installed ones.

    The problem as I remember it was that the build system was looking for files inside of /usr/local, however aclocal was looking for files inside of /usr, so it wasn’t finding the right files. The root problem seems to be people disagreeing on where exactly something should be put. Some packages will install to /usr by default, others will go to /usr/local. For example, moving from Google Protocol Buffers 2.3.0 to 2.4.1 took me a while because they completely changed the install location from /usr/lib to /usr/local/lib. Also, the way the paths were setup, cron was still using a different version of protoc than a normal user, that took a while to figure out….

    As for the registry, what I find most useful about it is the fact that you can tell where programs are installed. The problem with having each application have its own registry is that it could be anywhere – ~/.firefox, ~/.config/firefox, ~/.local/firefox, etc. Since there’s also no common format to how configs are stored, it’s not always clear what is what. Granted, the Windows key-value combinations aren’t always flexible enough, but it could simply point to a config program.

Leave a Reply

Your email address will not be published. Required fields are marked *