Designing Good Linux Applications

An Anonymous Coward writes: "A guy from IBM's Linux Impact Team in Brazil has written a guest column on Linux and Main describing how applications should integrate with Linux. It's Red Hat-centric, but there is a lot of material about the FHS and LSB that most users probably don't know."

Comments

Not totally true...

[NanoGator]

I do agree that some of what they talk about in this article would apply to most applications, but not everybody uses an OS the same way. Take this except, for example:

"Everybody loves graphical interfaces. Many times they make our lives easier, and in this way help to popularize software, because the learning curve becomes shallower. But for everyday use, a command at the console prompt, with many options and a good manual, becomes much more practical, making scripts easy, allowing for remote access, etc. So the suggestion is, whenever is possible, to provide both interfaces: graphical for the beginners, and the powerful command line for the expert."

This is wonderful advice in the Linux world. However, most Windows and Mac users, sadly, don't know what a command prompt is, let alone how to script it. This is a native concept to a Linux user.

I have no doubt that even in the Windows/Mac world a really powerful Command Line feature for any given app would be super useful, but it is only so for those who have climed that learning curve. In that case, it's better to focus on making the App do what it needs to do.

In any case, I'm sure I'll draw criticism for that comment. I'd prefer you didn't, though. The point I'm making is that slasho81's comment that all software should be the same despite the OS isn't quite so black and white.

With any luck...

[Nailer]

This will get round to people making the applications. I'm absolutely fed up with people, especially vendors of proprietary software, making nonstandard software. In my book, standard (LSB) Linux apps are the *only* Linux apps, this means:

• They are packaged as RPM 3 files, to allow standard installation, deinstallation, auditing, and management of relationships with other necessary software. Not some interactive self extracting tarball I can only use once unless I do the vendors job and package it myself (which unfortunately is necessary for modern sysadmins if they want to do their job properly).
  
• They use SysV init scripts which live in /etc/init.d. Again, I often have to do the vendors job for them and write the initscript myself. This sucks, I paid my money for a Linux app and I want a Linux app. This means you Sophos Mailmonitor.
  
• General FHS compliance. I should be able to mount / readonly and /var read write and your app should work, once I have configured it. This is too often not the case. This means you StarOffice.
  
• Man pages should always exist (no, not `Debian tells me I need a man page so this is it, I have no actual useful content, write me!' man pages but actual real no-bullshit man pages. Man pages go in /usr/share/man.
  
• 
  Documentation in /usr/share/doc. Not in /usr/lib. Yes, the FHS says you can install non-user executed binaries in /usr/lib, but documentation is not libraries or binaries, never was, and never will be. This means you Citrix.
  
• Die symlinks, die. Linking correct locations to their incorrect locations should be as short term as possible. Yes, this means you Red Hat. Reverse the /etc/init.d -> /etc/rc.d/init.d symlinks now.
  
• UNLESS YOU ASK MY EXPLICIT PERMISSION TO INSTALL EACH FILE SUSE OR ANY OTHER DISTRO HAS NO RIGHT TO DO THINGS TO MY /OPT. Aaaarrgggh Suse!
  

There will be things you don't like about the LSB and FHS. Personally, I reckon initscripts aren't config files and should live in /sbin. But I put them in /etc/init.d because the FHS says I should. Likewise, if you have a problem with RPM, make it better (apt-get's already a basis for all my Red Hat installs and updates thanks to Freshrpms).

Re:/usr/local obsolete?

[Krapangor]

The latest version of the IBM JRE (v1.3) installs in /opt. So they don't seem to take his ideas too serious.

On GCC and others of the same ilk.

[yeOldeSkeptic]

I agree with the main thesis of the article. I just wish more packages follow the ideas expounded, and specially the FHS.

For example, gcc when installed from source defaults to putting itself into /usr/local/ which is quite understandable, because it was locally installed. Unfortunately libgcc_s.so should have placed itself in /lib instead of /usr/local/lib because some boot-time binaries need it. (modutils if I recall correctly.) The first time I installed gcc from .tar.gz, my sysinit crashed because /usr wasn't mounted yet.

Other packages have this problem too: fileutils, bash and modutils come to mind. The default configuration is to install themselves into /usr/local/ despite the fact they are needed during boot. (init's message of "rm: no such file" puzzled me the first time I saw it.) Now, I know that ./configure --prefix=/ fixes those things, but my point is, the user shouldn't have to learn from experience how to correctly install those packages. The packages should help him.

Re:First of all,

[ianezz]

As much as I share your desire, I think there is something deeper going on:

IMHO, to attract OSS developers, a piece of software has to be:

• Useful to the developer, or at least it should offer the perspective to be useful in the near future. Otherwise there is very little motivation do mantain/debug software (sorry, I don't buy at all the idea that a OSS developer puts his time and brain in doing something exclusively for the good of humanity or users).
• Easy to understand, extend and debug: if it isn't easy to grasp the whole picture, or at least grasp the picture of a whole subsystem, OSS developers will leave the project in frustration after a while, starting their own. The fact that large (successful) projects like Gnome, KDE, Mozilla and OpenOffice are divided in several smaller components, and the Linux kernel itself, although monolithic, is divided in several subsystems, should tell something on the subject.
• Well documented (for developers): because it's hard to grasp the big picture only by looking at the sources when the codebase is large: you end just seeing a lot of trees, but you lose yourself in the forest. Sources tell a developer how something is implemented and how it is supposed to be extended, but usually they tell very little on why things have been implemented that way. Intelligent comments in the code are good, but when a concept spans on several source files, a README on the subject or a tutorial are definitively needed.

By any way, I don't pretend that these are anything more than a few rules of thumb, but in the end I'm sure that, for OSS software having the characteristics above, developers willing to do maintenance will show up by themselves without needing to preach them.

dependency hell

[Skapare]

After using many versions of Slackware, I finally tried Redhat at version 5.1. Actually I had tried it at a way earlier version and it never successfully installed. But 5.1 worked OK. The reason I tried it was I bought a Sun Sparc 5 and wanted to try Linux on it. Redhat seemed to be OK, so I later tried it on a couple other i386 systems, and that was working OK ... for a while. As it turns out, I needed to make upgrades before RPMs became available (see next paragraph). I also needed to make some changes in how things were built. The RPM system started getting out of sync with what was actually installed. The system ran just fine, but soon it got to a point where some packages I was installing with RPM would not install because the RPM database thought things were not installed which actually were (but weren't installed from RPM, so I can understand why it didn't know this). So I ended up having to do forced installs. And that ended up making it more out of sync. By the time I had gotten to Redhat version 6.0, I was getting fed up with it. I switched back to Slackware (and Splack for Sun Sparc eventually came out and I use that, too) and am happy again, with well running systems. And I am now exploring LFS.

You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that. If I get some package which is just a TGZ source file tree (because the developer was writing good portable code, but not using Linux to develop on), why should I, in the system administrator role, have to be one to make a package out of it? I'll agree it doesn't take more brains than needed to properly install the majority of source code, but I won't agree that it is easy (in terms of time spent) to do. At least I have the brains to actually check the requirements of what a given package I'm compiling needs, and make sure it is there by the time it is actually needed. The dependency may not be needed until it is run, so I have the flexibility of installing in whatever order I like. Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.

Re:dependency hell

[Nailer]

The system ran just fine, but soon it got to a point where some packages I was installing with RPM would not install because the RPM database thought things were not installed which actually were (but weren't installed from RPM, so I can understand why it didn't know this). So I ended up having to do forced installs.

That's not the solution to the problem. Any management system ceases to become effective as soon it ceases to be ubiquitous. If your Apache is locally built, and you made the mistake of not packaging it, then you've nullified the effectiveness of the package manager for anything which touches apache.

You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that.

Good point - ideally the programmer should, but its a simple enough case for SysAdmins to learn if they do encounter an unpackaged app.

Have you tried making RPMs? I'm not a programmer by any means but its amazingly simple. Check www.freshrpms.net for a few good tutorials.

Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.

Another good point. This should be handled by a system similar to debs excellent required / suggested / recommended dependency system, which could fairly easily be ported to RPM from what I understand of it.

Finding out a dependency exists when something breaks is no way to manage a system. Knowing what software has been installed on a machine is vital tomaintaining the security of your machines, and having proper uninstalls stops your hard disk from filling with crap. And there's a stack of other benefits.

I find most people who dislike RPM haven't used the system. its very much similar to building an app. Inside the RPM itself is the original tarball of the app (plus maybe a couple of patches) and the spec file which is comprised of:

• Metadata, like the name of the app, version, package version, app description, group, copyright
  
• Instructions on how to patch, configure, compile, install, and uninstall software (with extra nifty stuff, like triggers for when other software is installed, able to be added at your own descretion).
  

Its pretty muc hthe same as if you'd compiled the app without a package manager. RPM just standardizes your build process. You can easily rebuild source RPM for your local architectecture, and RPM will take compiler flags for your own custom configuration options. I like compiling a lot of apps from source too: I just take a few extra moments do it in a standardized fashion. This pays off repeatedly when I'm administering the machine infuture (or if I need to repeat thsi work on another machine).

Re:Init levels

[Skapare]

My sparc runs fine at run level 5. What would you like to see the various run levels be for? I changed mine around, and it looks like:

l0:0:wait:/etc/rc.sys 0 halt
l1:1:wait:/etc/rc.sys 1 single user mode
l2:2:wait:/etc/rc.sys 2 network admin mode
l3:3:wait:/etc/rc.sys 3 server mode
l4:4:wait:/etc/rc.sys 4 workstation mode console only
l5:5:wait:/etc/rc.sys 5 workstation mode X windows
l6:6:wait:/etc/rc.sys 6 reboot

/opt considered evil

[BetaJim]

:) I really wish that /opt didn't exist.

When trying to partition the different mount points /opt prevents using a small / partition. Usually, what I do is postpone installing some software (KDE) until I can ln -s /opt /usr/opt. /opt should really be one more level up from /. At the very least, I think that /usr/opt is a better place for this type of directory. Since /usr is usually allocated a lot of space (and / is kept small) it makes more sense to have opt under /usr.

Hopefully, the folks in charge of the FHS will consider this.

Re:First of all,

[Waffle Iron]

50% of the projects are still even in "design" stage and out of the 50% left 90% are abandoned in one way or another and only the resulting 10% have some sort of activity

Commercial software projects are the same: only a small fraction of them make it to final release without being canceled or redefined. The general public just doesn't see these. You can rest assured, however, that the revision control systems in your average software company are littered with countless defunct projects.

For some reason, management doesn't say: Why develop new products? We can just restart work on all of our old canceled projects and bring them to market. Maybe the reasons we canceled them magically went away...