Building my development environment – Part 1

I am a bit old fashioned, so I am looking somehow disparaging at the Docker approach. Whenever the real world is your intended crash site, you soon realize, that you should have considered real world problems during development! This is about how I put things on.

It starts with building up the underlying environment. Will I pollute my system with my development stuff?! To be honest, current systems come as a pigsty of software installations. The builders of the distributions dump everything into one single installation path. This is the unpleasant consequence of more and more Windows-socialized developers coming to also develop on Linux systems. But the UNIX-paradigm goes a little different.

How software installations are organized

Software should be separated according to its nature. There is system software and there is add-ons and there is 3rd-party and there is COTS (commercial off-the-shelf)

System software is separated by such that is utterly important to boot a system. This software is statically linked and it resides in a directory that will be on the root partition (please see “partitioning the installation disks” There is no link yet, as I will write it later), while the other system software goes to /usr/bin. On classical UNIX systems these two are on different partitions, as the root “/” resides on its own little partition (respectively “slice”).

After the basic system is installed, you cannot do a lot with it, unless you install additional software. The UNIX and Linux systems usually come with a somewhat rudimentary C-compiler, that allows you to change system parameters and build a new operating system kernel. But this C-compiler is carefully assembled to prevent you from doing your own software development. In the old days, the 1970s and 1980s, a C-compiler was an expensive piece of software. I remember in 1986 the Megamax C-Compiler for my Atari ST  would have cost some 1,300.– D-Mark, so I bought an assembler which was available for a little over 100.– D-Mark.

Today, for many systems the system compiler is the GNU C-compiler, which is free. Hence the basic compiler is much more comprehensive and comes with lots of development libraries. Nevertheless, today’s desktop environments are so swollen, that the they require tons of additional libraries and header files and all this ends up in the /usr directory and all this is on the same partition with the root, if you don’t decide to go with the UNIX-paradigm and change it.

So in this example we assume, that we do our development with llvm and not with GNU-C ( it’s just an assumption ). In this case we would install the additional compiler suite in /usr/local which normally resides on its own partition.

When I decide to install the Postgres database I will compile it in the /usr/local directory, but when I install an Oracle/Informix/Ingres database, it will go to /opt which of course will be on its own partition again. But if I compile open source version of the Ingres database or the free version of BerkeleyDB from source it would go to /usr/local.

In the examples I will be showing and explaining, I will follow the UNIX-way of organizing the software installation.

My basic system

For the time being, I am working on a laptop with VMware workstation 12, but I will likely move VMware on a dedicated server with enough CPU.

The underlying host-operating system is Mageia 5. I chose this for several reasons.

  • Debian derivatives (and Ubuntu is a Debian derivative, too) come with a bug in the xinput system. I am working with a laptop with a trackpoint and I am touch-typing, so I want to disable the touch pad, because whenever I touch it by accident, the cursor goes somewhere else and the input of course, too. This is really annoying and it is even more annoying that Debian is maintaining the bug that prevents xinput from recognizing the touchpad since years.
    On most other systems, I am able to first detect the touchpad:

    # xinput --list
    ⎡ Virtual core pointer                          id=2    [master pointer  (3)]
    ⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
    ⎜   ↳ AlpsPS/2 ALPS DualPoint Stick             id=12   [slave  pointer  (2)]
    ⎜   ↳ AlpsPS/2 ALPS DualPoint TouchPad          id=11   [slave  pointer  (2)]
    ⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
        ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
        ↳ Power Button                              id=6    [slave  keyboard (3)]
        ↳ Video Bus                                 id=7    [slave  keyboard (3)]
        ↳ Power Button                              id=8    [slave  keyboard (3)]
        ↳ Integrated Camera                         id=9    [slave  keyboard (3)]
        ↳ AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
        ↳ ThinkPad Extra Buttons                    id=13   [slave  keyboard (3)]

    And subsequently I disable the touchpad

    # xinput --disable 11

Note: I am using the #-sign as the system prompt, to prevent the troubles of unintended copy/paste.

  • I don’t like the somewhat Stalinist concept behind the Gnome 3 – and Unity – desktops. I am frequently installing software on my own following the UNIX-paradigm and end up in trouble telling these desktops (Gnome 3 is worse) to assign an icon starter on the desktop.
  • Mageia reminds me a bit to SuSE-Linux, but it doesn’t ask me so often for my or the root-password.
  • I like the frequent system updates provided by Mageia and the ease with which they are applied.

In the next article I am discussing the disk-layout I am using to install UNIX-/Linux-systems.