Articles / Editorial: Robert Current

Editorial: Robert Current

Robert's followup editorial addressing incorrect statements and proceding further on regarding the Linux Standard Base issue.

For Talk

I'm back, and with some good news. First off, I have to say, there were incorrect statements in the editorial (at http://freshmeat.net/editorials?item=linuxopinion) published here on freshmeat.net and I am happy to have received so many comments of correction. Yet, there are some things that are still true, and still worth considering.

To start with, LINUX is as much a community as it is a kernel. It has been for some time, and it's a spirit that will last, and help us all work through the headaches we occasionally experience. You are not alone out there when you run into problems. And, as anything in life, there will be problems. The spirit I have clearly seen flowing through my mailbox in the last couple days is amazing. And, I now have newfound hope. The great thing is, now more than ever, there is a place for everyone to contribute in the LINUX community. If you don't hack the kernel, you can develop applications. If development is still over your head, you can look into distribution management. If that task is too advanced, you can find a nitch responding to "newbies" in newsgroups and on mailing lists. If that doesn't appeal to you, you can find work doing LINUX advocacy (which http://sunsite.unc.edu/LDP/HOWTO/mini/Advocacy.html has now even made clear). If that is all still to much, you can beta test and send bug reports. If you want to help, there is room, no matter what your LINUX skill level is. And, if you need help, there are always places to turn.

There is no position in the LINUX community that is not important. Everyone from Linus Torvalds himself, to the guy who just spent $50 for a boxed package of Red Hat at his local Best Buy, is a living, breathing, thinking feeling human being, with thoughts, hopes, dreams, strengths, and weaknesses. As a community, to be healthy, we need to learn to minimize all the weaknesses, and learn to draw on the strengths. Some of us are better suited to do things that others of us can't. That does not make them less or more important. If Linus never started work on the kernel, the distributors and site maintainers would have nothing to distribute, and the end users would have only Microsoft and Macintosh to turn to. If the distributors and site maintainers were not in place, Linus would be sitting alone in a room hacking away at a kernel without help, and no way to get it out to the people who would like to use it. If the end user wasn't there, where would the pat's on the back come from when developers do a good job, and what point would there be to do any of it at all. (If I through a party, and no one came, I would be a little pissed off that I cleaned my house and bought beer for nothing!) And there are many steps in-between, and lots of little niches to be filled. They move, they shift, you go from one level and one project to another, but there is always a place for you.

Now, I need to go over some of the points from the previous editorial quickly, and make some clarifications. The "hackers only" attitude in the LINUX community is rapidly fading. I will not deny that I received about several messages with a RTFM or don't try to swim with the big fish attitude. To my approximation, about 20% of the letters sounded that way. My response? Well, if it were possible to wear out an application, I would have wore out xman several times already, starting with my first SGI account in 1993. And while I am on the soap box, how about a nice GUI update to xman, making it faster, more versatile, and prettier?

I am quite happy to report on what the other 80% or so of my mail has been! About 50% or so has been to the effect "I totally agree, find a way to do it, and I will help with all I can." The remaining 30% or so has been "take a look at this URL, I think it has information you're looking for."

As for the lack of commercial support for applications, I have had some positive responses in that area too. Well, when you finally scream loud enough, solutions present themselves. I just now (after the original editorial) found a Page Layout program (at http://www.axene.com/english/xclamation.html) for LINUX that may be usable. This is something I have been asking about for several months with no positive response. And even more, it's proof that some commercial applications are out there, just relatively hard to find at this point. I see it's part of a commercial company providing UNIX solutions, this one (at http://www.axene.com/english/) is a full office suite for about $50, and provides some of the tools I wanted that Applixware and Star Office were lacking for me.

About my comments of a standard file structure for LINUX, I was flat wrong. There is one out there. Major distributions are trying to follow it. It seems as thought it's the people who upload their packages to the "contrib" sites that are the ones ignoring it (I'll get back to that later, below).

But the key thing that prompted me to start this whole discussion is still true. LINUX applications can be a real difficult thing to install. That is not a doubt. I have heard from many people now on this issue, and I have only found ONE that claimed he has never had a problem. Then when I pointed out the applications I was trying to install to this ONE user, his comment was "Oh, I see now where you might be having some problems, I don't use those type of applications." The good news is, there are a couple plans in the works, and supporting them will be vital to the LINUX community (also see below).

Talk shouldn't stop here. This is the beginning of the battle, and only a rough outline of some things that can be done. I, by no means, am an expert in the matter. I am only a "whine end user" who is trying to bring this discussion to a broader audience. I am not afraid to help out where I can, I can not solve it all myself, but I am confident that the resources are out there, and we all can play a part in "make"ing the LINUX community a happier place without too many "make stopped, error (1)" situations. I only hope it becomes clear, us "whine end users" are not afraid to get our hands dirty and help out, when we are given a chance!

For People Ready to Get Their Hands Dirty (a little)

Compile some programs from source and package them. That is what I plan on trying to do in my spare time. My coding itself is not really the greatest (sure, "hello world" went ok, and some variations on it, but the more advanced stuff isn't perfect :P I am a long way from coding the awesome GUI applications that the GNOME developers are doing), so this area is probably the best place for me too.

We have to be a little careful in this area. Make sure you have read up on the standards efforts that are forming now at http://www.pathname.com/fhs/ and http://paradigm.uor.edu/linux/standard/ (and any others you find) and try to see that you follow them. Email to the developers of the programs is probably in order to help resolve some of these issues. Don't complain too much, just make it clear you're ready to help, and to do that, the standards need to be followed. You can't expect a developer to simply say "yea, sure, here you go, I will change everything now just because you say so" when you talk to them. You have to be willing to realize, you're there to help them, not to take over.

An enormous amount of very useful LINUX applications I have ran across that needs some help in this area can be found at http://SAL.KachinaTech.COM/ and a packaging effort for them has started at http://SAL.KachinaTech.COM/sal-package.html already. I think one of the programs that interests me that I may try to help out with if I can is Raster3D (at http://www.bmsc.washington.edu/raster3d/raster3d.html) which I found at SAL (on http://SAL.KachinaTech.COM/Z/2/ were most of the stuff I want is located).

Of course, if you find some applications yourself that are more useful to you, start with the work you would enjoy most! The GNOME project (at http://www.gnome.org/) is a very popular effort, and they are constantly recruiting support.

When your done, submit them! Sunsite is of course the obvious place they should go, and also places like http://rufus.w3.org/linux/RPM/ run by Daniel Veillard (Daniel.Veillard@w3.org of the RPM repository) and freshmeat (at http://freshmeat.net) are becoming important in this area.

Also see "Consider Packaging" below.

For People Ready to Organize and Discuss Management

Resolution and coherentness need to be discussed and implemented yet. All the "standards" out there seem to still be in a bit of flux. Read up on what's out there, and the starting points are clearly at http://www.pathname.com/fhs/ and http://paradigm.uor.edu/linux/standard/ but there are others.

One of the next steps is automating the "dependencies" issue for installing applications. It has been recently explained to me that Debian has a method of dealing with this (A point I hadn't experienced when I briefly worked with a Debian system). Red Hat has some ideas in the works at the moment also. And, IMHO, the auto fetching of dependencies in the FreeBSD ports collections is a good working model to draw ideas from (something like "tar -zxvf ports.tar.gz" then cd to the package you want, and all you have to do is "make; make install; make clean" and if parts are missing, it goes out on the net and gets them for you).

Freshmeat.net is doing it's part too, providing links and archives of useful applications and packages, since you're here at the site, you can already see that. There are other collections out there as well, such as Daniel Veillard's RPM archives on Rufus (at http://rufus.w3.org/linux/RPM/ ) and the infamous Sunsite resources (at http://www.sunsite.unc.edu/pub/Linux/ which is case sensitive, capital L for Linux). My favorite archive is Scientific Applications on Linux (at http://SAL.KachinaTech.COM/) where I find stuff I could really use at work.

One idea about how to bring some of these things together is from Daniel Veillard, in his Linux Packages Metadata Mirroring Proposal (at http://rufus.w3.org/linux/rpm2html/mirroring.html). Some of the key people running these sites working together to make it all happen would be great. Clearly, not everyone is going to jump on Daniel Veillard's proposal without wanting some input and suggestions first. But at least he floated an idea, and is a reasonable guy open to discussion about making it all work. He is already mirroring freshmeat.net on his site.

A quote from Daniel Veillard (Daniel.Veillard@w3.org of the RPM repository is quite noteworthy in this area.

"Yes, SAL is a very well done software database, there is another one
on linuxHQ which is nice too. However currently finding the packages you
want to install is only the first part of the installation. And the next
steps are painful:
- fetch the package
- try to install it
- fails since it lacks libgif.so.2
- now which package on your CD Rom or on the net provides this
damn library (supposing that it doesn't clash with another existing
app on the system ...). "

Some of his proposals such as "Linux Packages Metadata Mirroring Proposal" at http://rufus.w3.org/linux/rpm2html/mirroring.html are quite noteworthy. Lend support and suggestion to these kinds of ideas! Rufus at http://rufus.w3.org/linux/RPM/ already is starting to solve some of these problems, but if I may quote Daniel Veillard (Daniel.Veillard@w3.org of the RPM repository) again:

"this is not sufficient. Just a first step toward finding a real solution, i.e. one where the user interaction is
limited to the interesting stuff ."

The matter is a quite serious one. My recent discussions with one of the Debian developers has informed me that they have worked out some of the solutions to this problem. But, even if that camp has worked out some of the details, it is only for Debain users, and only works for programs that have been put in debian packages. Their model (as well as the FreeBSD ports model) should be looked at, and solutions they find be considered for a broader use.

My personal feelings are if a joint statement were to be made from people in the position to make a few waves like heads of Debian (at http://www.debian.org) Marc Ewing (marc@redhat.com of Red Hat http://www.redhat.com), Daniel Veillard (Daniel.Veillard@w3.org of the RPM repository http://rufus.w3.org/linux/RPM/), and the people at http://SAL.KachinaTech.COM/ who have also already proposed getting more applications out to end users (at http://SAL.KachinaTech.COM/sal-package.html), developers would listen! Add to the list the people at http://www.linux.org and the LINUX section maintainers at Sunsite resources (at http://www.sunsite.unc.edu/pub/Linux/) and change would happen.

Maybe even the guys at Caldera, Slackware, and SuSE, but I suppose that is even more to ask. I am but one person suggesting an idea. Many of these guys are ready to make it work. We just have to listen, pay attention, and lend support. The Slackware crowd may be one of the tougher sells on the idea.

If they all could agree to announce something as simple as how the much neglected http://www.pathname.com/fhs/ thing is truly important for the LINUX community, it would be a great start.

If all of them together could get Linus himself to take a couple minutes away from his Transmeta work and kernel hacking to get a few simple words of endorsement, that would really make waves. Linus has kept the kernel development a remarkably clean venture and his work should serve as an example to all of us.

The GNOME project (at http://www.gnome.org/) would also be a great place to hear support developer compliance to these standards. GNOME seems to be the hot bed of developers right now, with remarkable applications in the works like GIMP (at http://www.gimp.org/ which may compete with Adobe Photoshop) and Glue is under development (at http://aix2.uottawa.ca/~s1204672/glue/ which may take on Adobe Pagemaker, Microsoft Publisher, and Quark Express). With applications that are so fundamentally mainstream coming down the pipes, the standards will be crucial in getting them out to the end users.

Agreement to support things like http://paradigm.uor.edu/linux/standard/ coming from the top would revive it from the dead, and make the LINUX community much more coherent.

Web site maintainers will be key in this situation also. Their willingness to clearly post the standards such as links to http://www.pathname.com/fhs/ and http://paradigm.uor.edu/linux/standard/ and a statement about how these sites provide useful standards will help the situation as well.

Things like Alien Package Converter (at http://kitenet.net/programs/alien/) may also prove to be very useful in the grand scheme of things.

The Red Hat Developer site (at http://developer.redhat.com/) has been up and running for a little while. It also has links to Freshmeat (at http://freshmeat.net) proving again that Freshmeat itself is a player in the distribution scheme. What is interesting to me at the Red Hat Developer site is the new Contrib-Net section (at http://developer.redhat.com/contribnet/) which tries to reach out to contributors and help them best reach the most end users successfully. So, add another URL to the list.

I have also read some email regarding the idea of adding a "NEED_FILE" to the current RPM packaging, as a base to allow automation of resolving and fetching dependencies.

Sure, not all of these systems will do everything we would like. But the more of these systems we look into, the more we can draw an outline of something that will work and benefit all of the LINUX community. They are definitely starting points in the discussion, and things worth reading.

Things like Grpm Marc Ewing (marc@redhat.com of Red Hat http://www.redhat.com) is working on for the GNOME project (at http://www.gnome.org/) definitely show promise. And if something can be taken from the developers, their use of CVS (current version snapshot) tracking applications and installers would be one of those thing.

For Hard-core Coders

The LINUX standards are there to help, not hurt. Using them, or at least converting to them at the time your ready to distribute your software, benefits everyone.

There was a standard at one time that went by the name of "File system Standard (FSSTND)" but I believe its changed names now to "File system Hierarchy Standard" (FHS) with a home page at http://www.pathname.com/fhs/ and it has been suggested that a recent large influx of "Windows" programmers don't pay any attention to this standard. Wanting to keep everything together, putting it where ever they feel like, and doing it your way may be great for you in the initial development stage. But I will warn you now, you're going to be setting yourself up for for a flood of complaints about path problems and errors from end users, and some serious flame wars in the development community (look at the KDE versus GNOME issue if you don't believe me, they are in a slugfest over the /opt directory as well as choices about which libraries they choose to use).

Another source of great information about where the standards in LINUX are heading is at http://paradigm.uor.edu/linux/standard/ which is somewhat of a must read for programmers.

Help is wanted. Help is needed. "Apply within" is all over the place for people willing to put in some coding time. The developer (singular) for KIRC has been screaming for help and has approached burnout, if you want to find a guy that will welcome you, check out Aaron Granick (at http://x.unicom.net/kirc/). GNOME is also always looking for help, and I personally will be watching projects like Glue (at http://aix2.uottawa.ca/~s1204672/glue/) and the "GnuCash" guys (at http://www.gnucash.org) because I can't wait to get my hands on working versions of these applications!

Consider Packaging

Without serious consideration to that packaging of the application, the development can be somewhat futile. People will seek out applications that they are able to install instead, and great programs from world class coders will go by the wayside.

Red Hat has tried to start a developer site to help bring people together (at http://www.developer.redhat.com/). Their goal is to help, not get in the way. Some reading materiel is available, I went through http://www.developer.redhat.com/news.phtml?id=6 and found it worth the read. And they do have mailing lists on packaging up your applications also, which can be found at http://archive.redhat.com under rpm topics.

For developers with some time and money on their hands, a copy of one of these from Red Hat should be well worth the money. Look at http://www.redhat.com/products/product-details.phtml?id=rpmb and http://www.redhat.com/products/product-details.phtml?id=mxb for more details.

Standards are also in place for Debian packaging, and can be found at http://www.debian.org/doc/packaging-manuals/packaging.html/. This too provides insight into how to bring an application to the end user.

These are the standards that we are working with now. They may change, as all things do, but that is not justification for ignoring them now.

Thanks for my 15 minutes of fame, back to the chemistry lab for me.
Robert Current (aka BadlandZ)
http://cgsa.chem.und.nodak.edu/~current/badlandz/
current@plains.nodak.edu

Recent comments

10 Dec 1999 19:46 Avatar skylance

Great Write Up
Really informitive, I liked reading it alot.

Actully this was just a test to make sure when i posted it worked, as it hasn't in the past :-(

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.