Slashdot Mirror

← Back to Stories (view on slashdot.org)

Designing Good Linux Applications

Posted by michael on from the not-an-oxymoron dept.

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."

4 of 208 comments (clear)

  1. Not totally true... by NanoGator · · Score: 4, Interesting

    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."
  2. With any luck... by Nailer · · Score: 5, Interesting
    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).
  3. Re:First of all, by ianezz · · Score: 5, Interesting
    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.

  4. Re:dependency hell by Nailer · · Score: 5, Interesting
    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).