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

/usr/local obsolete?

[Osty]

From the article:

/usr/local, /opt

These are obsolete folders. When UNIX didn't have a package system (like RPM), sysadmins needed to separate an optional (or local) application from the main OS. These were the directories used for that.

I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong. Perhaps /usr/local is obsolete with respect to package managers, and that makes some sense (because the package manager should handle proper management of placed files, though in practice that's not always the case), but as long as open source is around, there will always be software that is compiled rather than installed through a package manager. There will also always be applications that are not distributed in your package format of choice (as long as there is more than one package management system, this will always hold true). In these cases, it's still a good idea to keep around /usr/local and /opt. Personally, I'll have /usr/local on my systems for a long time to come, because I prefer to use the Encap management system.

Re:/usr/local obsolete?

[Tet]

I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong.

Actually, no. It is from the diseased mind of the author of the article. He first cites the FHS, and explains how good it is to have a standard like that, and then proceeds to ignore everything it says. /usr/local is explicitly reserved for local use and therefore no package should *ever* install itself there (my /usr/local, for example was NFS mounted, and RPMs that tried to install there would fail because root didn't have write access to it). So far, so good, and we're in agreement with the article. But then he goes on to say that /opt should never be used. What? According to the FHS, /opt is exactly where IBM should be installing stuff. Quite how he's decided that the two directories are obsolete is beyond me. Both have well defined and useful purposes, both in common usage, and in the latest FHS spec (see http://www.pathname.com/fhs/). I'm afriad IBM have just lots a lot of respect from me for this...

This is plain wrong.

[slasho81]

Designing Good Linux Applications

The 'Linux' word is completely unnecessary - "Designing Good Applications" should suffice.
Application design couldn't care less of the OS that the application is planned to run on.

Think outside the Linux box

[Oink.NET]

This guy's ideas would be way more useful if he could think outside the stereotypical structure of today's Linux apps.

Ditch the concept of spreading pieces of your app all around the FHS. This is organizationally similar to Microsoft's registry. It becomes a maintenance nightmare. Yes, RPM keeps track of some pesky details that let us get away with a messier install. Yes, the FHS does impose a common structure on what is an otherwise unstructured mess. But programmers are human beings, subject to the whims of ego, ignorance, and yes, even creativity and sheer brilliance. We're going to deviate from the suggested standards if given the opportunity, for one reason or another.

Give me one main point of access to everything the application does. If you need to use config files, give me the option of manipulating them through the application itself, preferably in the context of my current task. Give me one place to go looking for all the bits and pieces of the app. No, the FHS isn't simple enough. Give me context-sensitive documentation so I don't have to wander outside the app to get my job done. Don't make me wade through a spaghetti-code config file, with the documentation propped open on a separate screen to keep from getting lost.

Programmers are lazy. I should know, I am one. The last thing I want to do when I'm getting ready to release a program to non-techie users is tie up all the loose ends that seem ok to me, but not to the non-techie user. I'd rather document how to get a tricky task done than write the code that automates the tricky parts. I'd rather tell the user how to go tweak the flaky data in the database by hand than add another error-correcting routine. And it's more work to give the user one simple, full-featured point of entry to each piece of a complex application. But that additional work will make the application more usable, for the expert and the novice alike.

Re:dependency hell

[Skapare]

It's the creation of the spec file that's a chore. I have to know what dependencies the package has to make it. If I know already, such as by RTFM's the original source package docs, then I know all I need to know to manage it without RPM. I still see making an RPM here as a redundant step.

I do some programming, but I still don't RPM-ify those programs ... yet. But when someone comes up with an "autospec" "autorpm" program which figures out everything to make the RPM file so it becomes as trivial to make it as to install it, I might be more interested. Right now I'll still with "./configure" and "make install" which work just fine for me.