My First Linux
I have been on Debian nearly all the way since I started with Linux at some point in (I guess) 2006. Initially, I was using SUSE Linux until a friend working in the broader IT sector asked: “SUSE really? Why not Debian? Isn’t that what all the geeks use these days?”
I was switching to GNU/Linux at a point in time when installing a Linux was not a gravely masochistic experience any more (contrast this with the present where you can install a Ubuntu from a live image running in main memory only). Still, Debian was just switching from Xfree to Xorg and installing it on a brand-new laptop without prior Unix experience still fell into a broad category of computer-related masochism. Back then, it was Debian 3.1, released as “Sarge”.
And since then, I basically have always been as happy as it gets with Debian. Naturally, getting it to run on any new hardware has been a pain, but it has always been bearable. I briefly tried out Ubuntu. Apparently, it worked much better out of the box. But the thing is: as soon as you get too far off the beaten track, Ubuntu is not much of a help and Debian just has a much broader support for even your obscurest software wishes (e.g., minimalistic window managers with a small user base).
How Your Minimal Installation Degrades
With Windows, I never had the feeling, that I am in full
control. Installing and uninstalling software did not necessarily
leave the system in a state that we would have had without performing
any operations on the OS. With Debian and
aptitude, I finally have
this feeling of full control. Although not quite until recently.
I have always aimed for a minimal Debian installation. Currently, my laptop setup comprises 2,687 installed packages. On my webserver (hosting this website) I have 527 installed packages.
While all these libraries, executables, documentation and headers are
neatly and cleanly managed via packages, it is still easy to loose
track of the big picture. We all know the typical
./configure && make
&& make install battle against tar-balls with undeclared
dependencies. You run configure, the feedback informs you about
missing packages. You install the dev-package and its dependencies.
Leather, rinse, repeat three more times. Sometimes you need a newer
version which is not in stable or testing, so you upgrade the
package to unstable. Then you try to compile, notice that more
packages are missing which are available on git only and after one
more hour of installing weird packages which are dependencies of these
git repositories, you realize that this package is not worth spending
your entire weekend on. Do this a few times and you start to loose
track why a certain package has been installed and all of the sudden
you get conflicts with packages that you actually do not need.
aptitude keeps a record about which package has been installed
automatically as a dependency and package has been installed
explicitly by the user. The advantage: if no package depends on an
automatic package any more, it will be automatically uninstalled. Less
bandwith is necessary for updates. A minimal installation may expose
you to less security risks (this does not need to be your primary
If you browse through your installed packages, the automatically added
package have an
A close to the
i. You can change the status of a
i A by pressing
M when the package is
highlighted. For the reverse operation (marking a package as
My suggestion: fire up
aptitude, go through all installed packages
and mark as much as possible as an automatic dependency. For
categories such as
libdevel, I recommend to mark the
entire category automatic at once. Notice, that if the package has
been installed by any other means (e.g.,
aptitude does not have any information on whether it was added as a
After uninstalling everything that you do not want on your system, you
can later revisit your selection of willfully installed packages by
!~M. On my laptop, I currently have 125
non-automatic packages which is a very managable number. On my
webserver it is just X non-automatic packages.
debian ubuntu aptitude