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.
While he doesn't mention Debian at all, it's clear that the article is strong on packaging. I actually prefer Debian's approach, having a list of sources from which you obtain software, and providing search tools for that list.
./configure command line to get a build that did what you wanted, you're likely to put off upgrading.
/etc/apt/sources.lists
;)
;)
The other important thing is that programs often don't work very nicely with each other, or need certain versions to work. This is where having a central system for controlling dependencies is rather important. I don't actually think Debian goes far enough at the moment (not really handling Recommends with apt), but it's getting there.
The other important part of packaging is handling upgrades automatically. Packages have security problems, they have new features added. If you have to work out (a couple of months later) which --gnu-long-opts-enable --with-features --without-bugs you had to put on the
# echo "http://debian.brong.net/personal personal main" >>
# apt-get update
# apt-get install bron-config
Whee
(note - that URL doesn't exist yet, but it's my plan for the future).
(note:2 - no ssh private keys in that
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."
Your post could be interesting if you had explained to us why integration is bad. IMO, the yields of object separation over integration packs have belong to the fact you'd compile separate parts of code such as libraries, device drivers and kernel, instead of being tied by a Windows-like central management and interpretation for kernel and virtual machines. Then, "separation" benefits *nix. On the other side, "integration" benefits Windows.
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
So I'm not a developer, and I don't know that much about programming. (Teaching myself QT 3 for the heck of it, but can't really do much worthwhile)
Anyway here would be my two suggestions:
1) Quit ripping off Microsoft and Apple. or at least think before you do. Using any Linux GUI you can immediately see the areas where the team said "lets make this more like Windows." on the one hand, this makes things more familiar and easy for the new users, but on the other hand, it repeats a bunch of bad and arbitrary GUI conventions that should be re-examined. For instance, in Mozilla by default, there's the same irritating password remember feature as in IE. This should not be a default-on option, the security risk is huge, whoever made that mistake at MS ought to be fired. Why do we continue it?
2) Drop the in-jokes please. Calling everything "GNU-" putting funny little things in the help files etc. etc. etc. we want to convince people that we're making a professional quality product. And nothing spoils that faster than giving the appearance of a hack.
and my suggestion to the non-developing members of the community would be:
spending some of your time filling out bug reports and posting (well thought out, politely worded) suggestions is much more effective than posting "linux roolz" on public news services.
here on Slashdot we like to speculate that Microsoft has hired a group of people to spread anti-opensource FUD in our midsts. the lamers who do nothing but insult "Micro$oft" all the time are the free equivalent.
In Capitalist America, bank robs you!
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.
Anyone running Red Hat 7.2 or many other RPM based distributions can easily install apt (or a similar tool, like urpmi, tho I prefer apt) to do the same thing.
5 5-fr7.i386.rpm
The advantage there is that RPM is a standard - currently the older RPM (version 3) is included in the Linux Standards Base, but once Maximum RPM is updated for RPM 4, its extremely likely that RPM 4 will become the standard.
If you're using Red Hat I highly recommend installing it.
rpm -Uvh http://enigma.freshrpms.net/pub/apt/apt-0.3.19cnc
apt-get check
apt-get update
apt-get install
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.
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
-
Use Validators and Load Generators to Test Your Web Applications
Also if you program in C++, these articles may be useful:-- Could you use my software consulting serv
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
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.
now we need to go OSS in diesel cars
Bingo. This is a point where the Mac - or should I say NextStep - made something very correct. Installing an application found online is a simple process in three stages: download, double-click to unpack from .tar.bz2, move it to the /Applications or ~/Applications folder. Removing it is equally simple: delete the application and *poff* it's gone.
Why hasn't this been adopted by the Unix community? It's just some special treatment of a damned folder! What else is needed for you to accept this solution?
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
Designing good Linux applications is easy as 1, 2, 3. Just follow these simple steps.
1) Command line only. We all know real users only use command line.
2) Don't comment your source code. Ever. It just wastes valuable programming time.
3) No installation/usage documentation. If they deserved to use your app, they can go figure it out themselves. What are you, tech support?
If you follow these simple instructions, you are guaranteed a rabid cult following, or at the very least a feeling of superiority over your users.
</sarcasm>
slashdot!=valid HTML
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:
now we need to go OSS in diesel cars
The article is still partly in Portuguese:
sobretudo = above all
destacado = detached (apparently he means that KDE is the most developed)
I emailed the author about the HTML problems.
Bush's education improvements were
The full quote goes something like this...
/opt is reserved for the installation of add-on application software packages. /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
/opt, as they must ask for specific permission of the local sysadmin to install files there.
/opt use by packages is logically quite rare (and in my own opinion rightly so).
(snip)
Distributions may install software in
This strongly discourages distribution use of
Since almost all software could be part of a distribution, and Unix has traditionally sorted its files by their type before their application,
When trying to partition the different mount points
Hopefully, the folks in charge of the FHS will consider this.
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
This line-length is quite hostile to the reader; human factors experts say that line-length optimally should be on the order of 60 characters; much longer lines--such as yours--make the text very difficult to read. This principle is even evident in the HTML source for your article, which (one observes) uses indentation for readability, together with an evident right margin column of 75, and a mean line length of 41.0485 characters. You have preserved readability for *yourself* but have seriously com promised it for others.
Please reconsider!
Thank you
"My opinions are my own, and I've got *lots* of them!"
So there are no apps for Debian Linux? Maybe that explains why software is so easy to install, uninstall, and update on Debian... its because none of it really exists.
Lets face it, the LSB is not an objective standard but a crappy attempt at a standard that has succeeded in nothing more than giving Redhat a supposed stamp of approval as not only the defacto Linux standard, but the dejure Linux standard. Why not just ditch the LSB and replace it with a sentence that says, "Must be Redhat compatible"? At least people wouldn't be kidding themselves.
I'm getting real tired of repeating this every few weeks.
/opt. It's worth noting that it's /etc/opt, /lib/opt..., not /opt/etc, /opt/lib.... A lot of people (including me) tend to get this wrong, but it's in the FHS.
/usr/local. In this case it's /usr/local/etc, /usr/local/lib....
/opt, but with PM/CM it could load into the standard locations. It should never load into /usr/local.
/opt practices.
/opt instead the standard locations. Relocating the files is trivial - it's a rewrite of the data.tar.gz headers and some standard control.tar.gz files, but automatically fixing installation scripts is still problematic.
When I recompile a standard package with different options (e.g., to match my environment, to be more secure by disabling some standard servers, etc.), intending to redistribute the packages to others, where the fsck am I supposed to put the results?
Hint: put it in the standard places and expect to be burned at the stake. I'll bring the burning torch. Non-standard builds that aren't clearly identified as non-standard tend to waste a *huge* amount of time because people reasonably, but erroneously, think that the package is official one.
To be blunt, the decision of where to put files is simple and well-established:
1) The standard packages (from Red Hat, Debian, whoever) loads into the standard locations.
2) Any modified packages distributed to others load into
3) Any modified packages that are not distributed to others load into
4) Any original package not distributed by the OS has historically gone into
5) Finally, "depot" style builds use their own trees, probably following the
As an aside, I've even been experimenting with a tool that rewrites Debian packages so the load into
The thing about the article that really pisses me off is that *all* of his advice can be applied equally well in all four scenarios. The fact that I can mechanically change a package to use a different installation target really drives this home. Yet out of nowhere he makes an uninformed comment that makes life difficult for those of us distributing modified standard files. (Comment deleted for profanity)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I would argue that it was STEVE JOBS that nearly killed Apple - Dr. Amelio made the necessary step to get more Macs on desktops by allowing low-cost/reasonable quality clones of the Mac to be produced.
Had the cloning efforts gone through, we'd all be bitching about Apple's industry dominance, instead of Microsoft (or at least bitching more about it).
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
Do you remember...
- When all commands had a manpage? And it actually describe the program! And it would have all the proper sections like "Synopsis" and most oftenly it would include an example or two.
- When all kinds of other things had manpages too. "man nfs", "man kernel" etc. actually worked?
-
When the "learn" program was around? Remember that? (It was a program that did interactive little courses on newbie topics. You'd do "learn vi" or "learn files". If you stopped at some point it remembered how far you had gotten and would start there the next time. It was simple, but useful.)
- When vendors actually shipped usable termcaps for common terminals? (OK, the linux vendors are pretty good at this, but some of the "real" unix vendors... Brr.)
On the positive side, I really do like Debian's manpage policy. Maybe there's hope./August, feeling old today.
"An object declared as type _Bool is large enough to store the values 0 and 1." -- 6.1.2.5, C99 standard.
portanto = consequently
clareza = clarity
obrigatoriamente = necessarily
garantindo = guaranteeing
separando = separating
The article is actually about creating high-quality installation programs, so the title is misleading. Here is a link to a copy that is better formatted, but not as well edited:
Creating Integrated High Quality Linux Installation Programs
FHS is the FileSystem Hierarchy Standard, an important standard.
I love Brazil and Brazilian culture, but not everything about the culture is wonderful. Brazilians generally don't like to give attention to detail.
Bush's education improvements were
Great article but I find it humorous that the article stresses user friendliness but the web page is WAY to wide forcing me to horizontally scroll almost every line that I read. :0)
Just struck me as funny.
The race isn't always to the swift... but that's the way to bet!
The LSB guys are smarter than you'd think. And Debian contributed too btw.
Of course, it might be nice if people wrote packages for each distribution and release but that doesn't happen in the "Real World." The LSB is a compromise that most people can live with.
Lets face it, the LSB is not an objective standard but a crappy attempt at a standard that has succeeded in nothing more than giving Redhat a supposed stamp of approval as not only the defacto Linux standard, but the dejure (sic) Linux standard.
The standard itself seems to speak otherwise.
I don't think you're very aware of the LSB, its content, or its history.
Maybe that explains why software is so easy to install, uninstall, and update on Debian... its because none of it really exists.
Asides from the lack of logic in yoru sarcasm there (where did I indictae that there aren't any apps for Debian), there's very little difference in ease of use installing software on either Deb or RPM based distro's. Many Debian folk seem unaware that tools like up2date, urmpi and apt exist and come with most RPM based linux distributions. Personally, I apt-get update my Red Hat 7.2 machine from Freshrpms each day.
Like making sure that your HTML documentation doesn't cause a horizontal scroll bar to kick in?
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Jobs killed the program almost the moment he was brought back on board. Read up on Power Computing sometime (not the web company in Alaska, either).
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
Now that looks like a useful tool, whether one will build RPM packages, or something else. It looks like the installwatch part could be useful during Linux From Scratch installs. Hope it works the right way inside chroot, which should be fine by making it part of the base system.
now we need to go OSS in diesel cars
That was pre-open source, when paying customers demanded well-rounded, finished systems...