Slashdot Mirror
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."
...'cos the common abbreviation for a Compaq Linux Impact Team would be interesting.
/. readers who have no Y chromosone and/or who don't appreciate South Park-style humour.)
(Apologies in advance to all
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
before going to design NEW linux applications,
PLEASE take your time and DEBUG the current ones.
The collection of half-abandoned software that has tons of bugs that nobody uses (perhaps of those bugs) is absolutely huge.
From the article:
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.
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.
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.
"Derp de derp."
Documentation in
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
The author states that /opt is obsolete, and that everything should use RPM and install in /usr. Maybe this is the ideal in a system where everything is binaries-only, but I firmly believe it is poor administration practice.
The RPM database is binary and fragile. Once it is corrupted, the data describing what belongs to what goes out the window. RPM-packages have to be trusted not to clobber existing files or make changes to configuration files that one wants left alone. The alternative is per-application directories and symlinks (or a long PATH variable); there are tools which automate this, such as stow. The advantage is that the file system is - or at least should be - the most stable thing in the system. One can just examine a symbolic link to see what package it belongs to. This makes removing and updating applications very easy, and also makes it easy to see if there are any links left around from older installations. Removing an application is typically as simple as removing the corresponding application directory.
RPMs which install in the /usr tree will require root priviledges, whereas applications that can work from a self-contained directory can be installed by a non-priviledged user in their own directory,
Also, /usr in principle can be mounted read-only. This will certainly slow down any attempts at installing software in it!
I have had Redhat's installer corrupt the RPM database on multiple occasions; and I've had to override the dependancy checking innumerable times in attempts to update packages under both Redhat and SuSE, thus rendering useless the other purported benefit of RPM. New software typically comes in source form before RPMs; and the RPMs that do become available are almost always going to be third-party ones that don't necessarily play well with your system. By the time a vendor-created RPM becomes available, the distribution version you are using is no longer actively supported, and you'll need 300MB of updates to other packages just to satisfy dependencies. I've been there, it's horrid.
Seriously, a lot of Linux applications try to duplicate the Windows world and end up being just as bad. For example, for audio software, a monolithic executable with GUI is a Windows-style application--hard to reuse, hard to extend. A bunch of command line applications that can be piped together and come with a simple scripted GUI, that's a good Linux application because its bits and pieces can actually be reused.
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.
That is what I found in the fortune at the bottem of the this thread.
Ascii artist &
/opt is in FHS 2.2 at secton 3.12. It begins:
Doesn't look very depricated to me. I think the problem is your FHS link isn't really the FHS; it is the SAG (Systems Administrator Guide), which in section 4.1 clearly says it is loosely based on the FHS.
As for /usr/local, I do agree it should be off-limits to the distribution (besides setting it up if not already present). And packages in the package format of the distribution (e.g. RPM for Redhat, Mandrake, SuSE, etc ... DEB for Debian and any like it ... TGZ for Slackware ... and so on) really should stay out of /usr/local. What /usr/local should be is whatever is local policy (FHS doesn't say it this way). Packages that the administrator really wants to be separate from the package management system, stuff compiled from source, stuff locally developed, all is eligible to be in /usr/local. My guess is the author of the article has no experience doing system administration combined with a decision making role where he might have to choose to do something slightly different than what everone else does.
now we need to go OSS in diesel cars
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:
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).
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.
now we need to go OSS in diesel cars