01.22.06

10 things that still suck under Linux

Posted in Unix / Linux at 8:05 pm by skoobi

I have recently setup a Linux server, so it was the occasion of pointing out the few things that still suck on this beautiful Operating System. Even though the distribution was Ubuntu Linux Server, the most famous Debian GNU/Linux derivative, all of these remarks apply to most other UNIXes such as FreeBSD.

The article is not meant to conclude that XXX OS is better than Unix. It is just a series of remarks that will, hopefully, contribute to making it better in the future.

1. Lack of consistency : Anyone having administrated a Linux machine has been faced to the general lack of consistence. I am not referring to the often-criticized lack of consistence in the User Interface, but to the heterogeneity of the miscellaneous components instead.In fact, each component (software, library, daemon) does not integrate to its environment, and no effort is done to ensure a smooth integration. For example, there is no generalized notion of a “virtual host” on the system, whereas it is clear for the system administrator that Apache’s www.bar.com’s VirtualHost, Postfix’s smtp.bar.com’s aliases, ProFTPd’s ftp.bar.com’s virtual Host, and all of their respective logs are somewhat related. Why are all tools so much application-centric, instead of being service-oriented ?Linux would be a better place if all those applications shared, to some extend, a set of configuration parameters, log formats and conventions. When looking at awstats logs, only the web-specific part of the bar.com domain appears, whereas the system administrator would like to have a global vision (HTTP, SMTP, FTP, SQL, etc).Of course, the Virtual Host is only one example of a disparate setting. There are lots of others, such as the lack of generalized identifiers and passwords for people’s accounts. As usual, there is nothing technically impossible here, and the solutions are already existing (LDAP, for example, but not necessarily), but once again, to make it possible, people have to agree on some conventions.If you want to provide FreeNX access to your users, you will have to maintain two sets of user/passwords. So would you if you want to give a MySQL database to each of your users. Additionnally, you will have to define a set of conventions to link a user to its database, since MySQL is a planet, and the system is the rest of the universe : there is no link between the two.Finally, even after all these years of editing and modifying these configuration files in /etc, I still wonder why no single file has the same syntax in /etc. There is no pattern, every single file looks like a different world. History has its part of the responsibility, but sometimes, people should be able to correct their mistakes. I am not speaking about drastically changing the whole /etc, but maybe progressively migrating the unused configuration files (how often have you modified /etc/iniittab by hand ?) to some common scheme. (not necessarily XML, but there should be some consistence in the choice. Consistence is not just about eye candy, it is also, and more importantly, about writing once for all, a generic parser, that can be optimised, and on which would all application rely)
2. Logging is most probably one of the worst parts of a UNIX system. The current syslog system is old and needs to be replaced by something better, cleaner. People could argue that it still works fine, and that syslog-ng solves part of the problem.
   However, it’s an inconsistent system : why is it that we can say mail.* or uucp.* (that only few people use, actually..), but not jabber.*, http.*, samba.*, etc.
   The answer is simple : the system is way too static, many details have been hardcoded into the system a long time ago, and the only extensible part in it are the localX.* that is limited anyways. The proof ? Any decent application (Apache, Samba, ProFTPd, …) implements its own logging mechanism. This has the consequences of bloating instead of componentizing applications.A solution to this would be to implement a flexible, extensible logging framework, that allows any application to fill a set of user-defined attributed, not static ones. The framework should log to a database (SQL, Native XML, OO, whatever), and indexes should be there to help log analyzers to efficiently perform their job. Text files are not machine-friendly, so any log which is to be analyzed by an application should not be written as a mere text file. Of course, system administrators are used to accessing files, so a possible solution is to use something like FUSE in order to implement a virtual /var/log on which UNIX gurus will be able to tail -f, grep, vi, and less. UNIX not-so-gurus will, on the other side, enjoy seeing better graphical applications focusing on the user experience, search, etc, instead of focusing on parsing and optimizing access the big files.
   Additionnally, FUSE would allow tools such as logrotate to still work.
3. Everything is based on the polling paradigm. Why would man-db run every week, even though I haven’t touched any man page for years ? why would awstats re-analyze my logs every night even though I haven’t had any query the whole day on several virtual hosts ?
   The problem is both about elegance and performance. The polling paradim gives the impression of a dumb system, that reverts to ugly hacks to minimize the performance hit caused by this inefficient system.
   If my server only uses 1% of its CPU during the day to serve Apache Queries, I do not want to wait until the end of the day for my awstats to be updated. Moreover, if at the end of the day, my Apache still eats 100% of the CPU, I do not want awstats to start analyzing logs.
4. Permissions. Since sensitive data is disseminated everywhere (passwords all over the configuration files, private keys for some daemons, etc), it is nearly impossible to ensure that a consistent set of permissions are applied.Instead, there should be a central repository where all critical information would be stored, and that could be safely protected and watched by the system administrator. Passwords should not be disseminated to /root/.my.cnf, /etc/freenx, /etc/apache/*, etc..

   Additionnally, no distribution currently takes advantage of ACLs by default. It is always possible to mount the filesystem with acls enabled, but no package would, by default, set ACLs instead of standard permissions. However, this could be useful in some cases, such as setting default ACLs in /usr/local/stow (for those who use this system), to ensure that any file created later in this directory will be readable by the staff member, regardless of the umask of the creator.
   A lot of other files could benefit from ACLs, and more specifically, default ACLs. This could be used to enforce stricter permissions, such as forbidding access to anyone to /var/log, and only authorizing specific users to rotate logs, etc. A lot of things can be thought and re-engineered.

5. Useless bindings all over the place. There are many languages, it is a fact. Since every language must communicate with libraries written in other languages, everyone creates bindings all over the place. However, it would be a little smarter to take advantage of the current .Net platform, implemented by the Mono project. For example, there are bindings for Gtk and all Gnome libraries for the .Net platform, so why are people developping Gtk / Gnome bindings for Python, since there already is a python compiler targetting the .Net platform.
   Developping less stuff, and concentrating on the already developped architectural blocks would help homogeinizing the system as a whole. I am not against the diversity of languages, but since a platform exists to make all these languages communicate, it should be used.
6. There should be standard communication patterns between processes. It looks like everybody reinvents the wheel to communicate with other processes. Some applications (pop-before-smtp) watch logs of others (courier-imap, etc), some use IPC, some other prefer UNIX sockets.. It looks like more and more people are adopting dbus these days. Maybe  all applications should take the  same path, to let the system administrator be able to monitor communications (logging, permissions, etc).
7. Limits and MaxSettings are hard to parameter. The maximum number of Apache threads , for example, is pretty hard to configure, since there is no easy way to calculate it. It is even harder to set a reasonable value when there are other services that may use  the CPU as well…
   So, I believe that there should be global parameters, instead of application-specific parameters. It does not make sense to set the number of Threads/Processes in Apache regardless of the other daemons running.
8. Applications cannot communicate with users :The only communication mean between applications and users are emails. However, email is a specific communication mean, and not everybody wants to use it. Some system administrators may prefer getting paged when a error outcomes (log, whatever) on the system.
   There is simply no dedicated mean for alerting a user, so people revert to quick and dirty hacks (call a specific shell script that will send a message to the cell phone, setup a email<-> phone bridge, etc..).

   So, there should simply be an abstraction to alert and send messages to the system administrator. The middleware would then use the appropriate plugins to communicate with the user, and such a system would prevent every application to implement specific means of notification.

9. Too many legacy unsecure systems.Whenever an application ships with SSL/encryption, this encryption is an option. Why wouldn’t things be encypted by default ? Having applications that already implement encryption communicate securly by default does not seem something hard to do, so why would we still stay with all those legacy services, unencrypted just because the system administrator is too lazy to configure the SSL certificates, and stuff ?
   SSH is a good example to follow : keys are generated by default, making the system useable right after installation.
   SSL is a bad example : its limits prevent it from being used easily with Virtual Hosts, so it should be improved..
10. Running an encrypted / is hackish. It is particularly hackish (init ramdisk, etc..) to run a system where / is encrypted. This should be fixed to allow people with laptops to take their computer without fearing their data might be stolen.

Once again, I am not criticizing any work done by all the volonteers on this planet. I am just pointing out all the items that I think should be enhanced, in case people did not realize the few things that are still problematic today.

I would love to see other people list their wishes and remarks too.

Permalink