2. Files for OS configuration and support
4. User environment and facilities, particular Ubuntu aspects
6. Perception of support by Ubuntu
In spite of reading pages and pages of remarks on Ubuntu and of long discussions that wound up in anything between "great, just what you need" and "don't lose your time", I did not manage to end up with a clear opinion: can an Ubuntu system provide me with a high-quality and – at least somewhat - easy to maintain platform for my daily work? Therefore I invested some time to install Ubuntu and make it run and have a – with respect to what I expect from my working environment – close look at the result.
I started with a live Kubuntu CD (the KDE flavour of Ubuntu, its 6.10 – Edgy Eft release) and then installed it to a spare partition of my desktop computer. I then adapted the installed system to my personal “system-style", a quite lengthy personalisation exercise: I ended up with an operational production-system that looks and behaves like my Mandriva system. The result is positive – the system does precisely what I expect it to do - and surprising - the decision was not at all difficult to know whether I should now dump Mandriva or whether whether I had just done an interesting experiment and put Ubuntu away.
There are certainly other Mandriva users who have become as curious about Ubuntu as I am, and who ask themselves the same kind of question. Here is a short summary of the observations I made.
The system that results from the installation process is somewhat spartan. For instance, it uses inetd and not xinetd; and when you install the xinetd package, you do not get any stubs in support of commonly used services like ssh or rsync – the user must create these files himself. That is easy if he can copy them from his Mandriva partition, quite a challenge if not: and that is probably the normal case.
Additional packages need to be loaded by explicitly and sequentially fetching and then installing them - an installation process which I find cumbersome and less transparent than the checkbox-driven pre-selection facility in Mandriva. I also did not find something that corresponds to the auto_inst.cfg file of Mandriva that serves to facilitate and normalise the process of defining the initial package selection. Installing additional packages is a quite time-consuming process, in particular since the user himself must resolve dependencies by explicitly loading the required packages (quite a job, for instance, when you install xemacs). I did not go farther than loading the packages by clicking the icon of the downloaded .deb packages - possibly there exist more efficient tools than the tool you get by default.
There are some minor differences with respect to the path-names of the directories where Ubuntu expects initialisation and configuration files to be placed and the syntax to be observed for naming these files. In my case, I had to deal with 2 instances of this problem: (1) adding a script-file that includes my $HOME/.profile script – evidently, only if it exists – (that provides me with shell-type independent initialisation of the login shell and of ssh client shells) and (2) during the definition of a file for the site-specific initialisation of xemacs: the file for (1) goes to /etc/X11/Xsession.d (Ubuntu) instead of /etc/X11/xinit.d (Mandriva) and the names of both files must start with "50...", which is not required under Mandriva. This may sound trivial, but it can be quite time-consuming to find out if one is not told.
There appears to be a serious problem of “sh” syntax differences between the “sh” implementation of Ubuntu and that of other Linux distributions, but also between Ubuntu “sh” and “bash”: this became evident when I downloaded and installed the vpnc package (needed for connecting to the private network of my university). The installed package did not manage to start a vpn connection: vpnc aborted with an error message from the “sh” interpereter each time the vpnc-script (an “sh” script) was launched. Correcting this problem was easy, I just needed to replace the #!/bin/sh pragma by a #!/bin/bash pragma - the practically identical script runs on Mandriva without any problem. This problem is not an isolated accident due to what might be considered extravagant use of fancy “sh” features, I had a similar problem with simple “sh” initialisation scripts when I ported them to Ubuntu: the {!variable} feature does not work.
The most likely explanation is that, in the system I got out of the installation process, /bin/sh is a link to /bin/dash - the problem might come from discrepancies between “sh” and “dash”. Simply changing the link target to /bin/bash may be dangerous - OK if the “dash” syntax is simply a subset of that of “sh”, a potential time-bomb if “dash” has specific features that might be exploited by other shell scripts.
Another problem at the same fundamental level appears each time I start a bash shell from a tcsh shell – my login shell (all my .bashxxx files are what Ubuntu installs by default): the bash shell initialisation complains about the syntax of "setenv" statements - which evidently should not figure in a script submitted for interpretation by to bash.
Both errors have in common that they systematically happen when the code of an important library package is launched. Even the most rudimentary quality assurance test should catch them. I mention these problems as an illustration of what I perceive as a lack of quality in the implementation of the present Ubuntu release.
Ubuntu uses grub rather than lilo as its default bootstrap loader. But switching from “lilo” to “grub” is easy, even in a multi-boot environment that accommodates windows, Mandriva and Ubuntu partitions.
Ubuntu does not explicitly support a user named "root", one must type sudo <something> in order to execute <something> with super-user privileges. This is easy to accomplish, I did not perceive this as an inconvenient - particularly since there is the possibility to open a root console with sudo konsole. But it is inconvenient that - about 3 out of 10 times – the sudo <something> command gets lost and needs to be repeated. It is also an inconvenient that I did not find a way to activate the root-password memory of KDE (which you can do in Mandriva by including a [Password] section with Keep=... into the kdeglobals file).
Ubuntus KDE default configuration puts the trash icon in the taskbar, a choice that I do not like: I need my taskbar for icons of important commands and menus, I prefer to have the trash icon sit in the desktop. And - to continue with nearly trivial issues - I like that Mandriva provides you with a "BROWSER" environment variable that points to the default browser, Kubuntu does not a corresponding feature.
In case you write scripts that need to take care of particular aspects of various Linux distributions, have a look at the lsb_release command - Ubuntu installs it by default, in Mandriva you have to load the lsb-release package (beware of the difference in spelling between the name of the command and that of the package!): I found this package very helpful for including distribution-specific conditional code in scripts without exploiting distribution-specific naming conventions like /etc/mandirva-release.
Ubuntu documentation is good and well structured, it is easy to find – substantially better than Mandriva documentation. This may sound a somewhat provocative observation if you consider the weight Mandriva attributes to multi-lingual aspects and the competent contributions from users – which, possibly, might even be a reason for this problem. But: information that is difficult to find has very little value, and in particular to the occasional user.
This is the point where I really have been surprised: I had expected Ubuntu - with its large user community providing potential feedback - to be a smoothly running system, without the "evident" errors that I observed. In Mandriva there have been comparable errors when new releases were published - but they were weeded out quite rapidly and certainly did not hang around nearly 3 months later.
This fact may be related to a second observation: the discussions I have seen in the Ubuntu forums appear dull when compared to the richness of information and helpfulness one sees in the Mandriva forum threads – not to forget the flow of information back to Mandriva. Many threads in the Ubuntu forum look open-ended - few constructive results - and there is no visible contribution of "club-monkey-wisdom".
Just to give one example: having problems to make vpnc run, I did a forum search. Already the split into a Kubuntu and a Ubuntu forum is confusing (retrospectively, I guess that the Kubuntu mainly deals with KDE specific information and that questions on vpnc should rather go to the Ubuntu Forum, but this is not sufficiently clear when you visit the forum). I found many questions to problems with vpnc and kvpnc, but very few constructive answers and practically no help. And, in particular, there was no visible feedback from Ubuntu staff to help work around problems related to the deficient quality of their library package.
I felt slightly intrigued by the "long" time Ubuntu needs to start the system. However, stop-watch in hand the difference is only 10% (Ubuntu 52 seconds, Mandriva 47), and it is compensated by the inverse relation when the system shuts down.
When you register to the Kubuntu forum, be prepared to receive a very kind welcome message – and the corresponding email contains even the text "your password is ..." with your password in clear !
If you are interested in more details, and particularly on technical issues: “Google is your friend” - for instance, I obtained valuable information searching for “ubuntu cooker” (combined search for both terms).
These remarks are spontaneous observations made while installing Ubuntu. They, and particularly the choice of topics, are necessarily subjective and specific to the background of a Mandriva user - but I hope correct. They should be helpful if somebody wants to have a go at installing (K)Ubuntu - or if he simply is looking for input on whether it is worth while to invest his time to try such an installation.
Most of the problems I noted can be fixed by investing some additional time (find a decent “sh” interpreter, find an efficient package installation tool, etc.) - but my point is: I just scratched the surface, the kind of problem that I observed should not appear in a distribution that has had time to maturate. That made me doubt whether Ubuntu places enough priority on quality – for me a decisive argument.
|
Jürgen Harms
|
|
Centre Universitaire d´Informatique
|
|
Université de Genève
|
|
juergen.harms@cui.unige.ch
|
|
13. 1. 2007
|