Designing Good Linux Applications 209
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."
Not totally true... (Score:4, Interesting)
"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... (Score:5, Interesting)
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
Re:/usr/local obsolete? (Score:3, Interesting)
On GCC and others of the same ilk. (Score:2, Interesting)
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, (Score:5, Interesting)
IMHO, to attract OSS developers, a piece of software has to be:
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 (Score:3, Interesting)
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 [linuxfromscratch.org].
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:Init levels (Score:3, Interesting)
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:
Re:dependency hell (Score:5, Interesting)
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).
/opt considered evil (Score:2, Interesting)
When trying to partition the different mount points
Hopefully, the folks in charge of the FHS will consider this.
Re:First of all, (Score:3, Interesting)
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...