Updates from the Free Standards Group

Daniel Quinlan writes "Today, the Free Standards Group released version 1.2 of the Linux Development Platform Specification and let loose with the public review of FHS 2.2-beta that will be used in the Linux Standard Base (and is already being used by distributions). Also of note, the Linux Standard Base has a new chairman, George Kraft IV, and the LSB specification is nearing completion. Really."

Comments

Re:Even if this happens, what can it change?

[Cycon]

The only way this will work is if all vendors come together on this and make it happen. Why would they want to do that? There are so many flaovors out there, if we start to standardize, the smaller "flavors" will be eventually out of business and we are back to capitalism at it's finest.

Linux vendors might want to standardize offerings because when it comes to Operating Systems, Linux itself is one of the "smaller flavors."

Besides, standardization doesn't mean that everyone does things the same way, it means that configuration files and binaries can be expected to be found in the same places, using the same formats. This allows individual vendors to create and provide tools which are helpful to everyone. Personally, I'd prefer to see commercial vendors like Redhat, Mandrake, and SuSE compete on grounds which don't include different methods for managing users and configuring software. If I wanted to swtich vendors, I don't want to have to learn how to do simple tasks all over again, for the sake of competition.

--Cycon

Re:Ah....standards....

[autechre]

>Maybe what we need is some generic tool for installing binaries (like Installshield) that can detect what it needs.

Oh, you mean like apt? Not that you're going to be able to "apt-get install oracle" any time soon :)

However, something like apt, which intelligently manages package dependancies (if the packagers and packaging system intelligently SET package dependancies) can see which versions of glibc, Perl, SDL, $WHATEVER exist on a system and determine what needs to happen in order to install a program.

What would be interesting is if distributors of binary packages (not counting those included in distributions such as Debian) could have those packages attempt to use libraries other than the exact ones for which they were compiled, if those libraries stood a reasonable chance of working. For example, I have a symlink in my /lib directory because the people at mozilla.org compile mozilla for Linux against a slightly older libc++ than the one I have. If it could have detected that and said "Oh, that libc++ is the same major version, it'll probably work", and simply run with a warning or something, that might be nice. (It does work perfectly, BTW).

As for where oracle should put its stuff, it should probably use /opt.

Sotto la panca, la capra crepa

Re:If they only had the balls..

[autechre]

As another poster pointed out, the window manager (KDE, GNOME, E, Win98) is responsible for standardising the interface (like alt-f4 being "destroy this window" in Windows).

And as for KMail, it is, IMHO, being evil. For years, *NIX has used the "highlight is copy, middle button is paste" philosophy. Ctrl-C is "kill"!! Why did the developer of KMail decide that they had to emulate Windows? StarOffice is also bad in this respect.

File open dialogs, OTOH, are totally the realm of the application developer, and in the Linux world, that means that everyone will probably write a dialog that works the way they want it to work. It would be interesting if the WM would provide hooks for something like that, where any app could call a standard "File Open" dialog; unfortunately, this would probably be different for every WM. Another case of one of the things that makes Free Software great (choice) working against it at the same time (it's easy to make everything shiny and smooth, if you're Apple and you control hardware + software tightly).

Sotto la panca, la capra crepa

This is only a stopgap standard for the lazy

[Arandir]

This is only a stopgap standard for use by the lazy. What needs to be done is to make Linux conform the the *current* standards already out there, instead of continuing to ensure that Linux apps will only run on Linux systems.

Conform to the ISO/ANSI Standard C Library instead of glibc-2.2.

Conform to POSIX instead of Linux-2.2.14.

Conform to X11R6 instead of XFree86-3.3.5.

A few pieces of software will need to be system specific, but the vast majority of Open Source code should be cleanly rebuildable on all Unix like operating systems, including *BSD, Solaris, HPUX, IRIX, etc.

Re:This is only a stopgap standard for the lazy

[Arandir]

If you use glibc, linux and Xfree86 extensions in your program, then it will *only* run on Linux.

Take a look at the FreeBSD ports and start counting how many applications *require* glibc installed just to compile the software. Obviously, there are scads of developers that are indeed using non-portable extensions.

Re:If they only had the balls.. GUI Balls?

[spitzak]

However a couple things he suggested are not GUI. In particular file associations. These are assummed to be "GUI" because they first appeared on the Mac and then on Windows. However it should be pretty obvious that a CLI shell could be written that took any filename typed in, looked up the association, and ran the program. Thus these associations are no more "GUI" than $PATH is.

A common utility program (and easily replaced) to pop up a file chooser, wait for the user to pick a file, and then exits printing the result to stdout, would also be useful. It could greatly reduce bloat of programs by eliminating a large chunk of the toolkit they need to link. Adding some standard programs to display a message, ask the user a question, etc, would allow even scripts to have a "GUI".

March 12, 2000 or 2001?

[LordNimon]

Something is wrong here. http://www.freestandards.org/ldps/ says 1.1 was released March 12, 2001 (yesterday). But if you read that announcement, you'll see the headline says March 12, 2000. Not only that, but the announcement text makes references to old distributions, e.g. Red Hat 6.2.

Also, I'm confused as to which distributions actually uses 1.1.
--

Even if this happens, what can it change?

[woody_jay]

Even if we have an orginization that is giving Linux Standards, the fact that Linux is Open Source means no one has to listen. For example, let's say the Linux Standard's Orginization says RPM is the standard format that will be used for installation of software. Who has to listen? It's open source, if I want to tar and gzip my files to get them out there and force you to compile them yourself, then there is not one thing you can do about it.

The only way this will work is if all vendors come together on this and make it happen. Why would they want to do that? There are so many flaovors out there, if we start to standardize, the smaller "flavors" will be eventually out of business and we are back to capitalism at it's finest.

Re:Even if this happens, what can it change?

[Shotgun]

For example, let's say the Linux Standard's Orginization says RPM is the standard format that will be used for installation of software. Who has to listen?

You forget that social norms, while limiting society, actually frees the individual citizen. Think about it. It used to be universally accepted in the Western world that a man opening the door for a lady was a sign of politeness. The women's liberation movement in the 70's did much to destroy this norm. Now if a man takes a girl on a date he won't know for sure if he's being polite or insulting her. Where once he was free to act, he now has to worry over a decision. At one time there was a standard that everyone agreed to use. Now there is confusion.

Yes, that example was frivilous, I know. But think of the things that distribution do differently for no good reason at all, usually resulting in widespread confusion. Mandrake recently changed the install directory for their version of Wine if I'm not mistaken. Why? Well, was it just that someone thought it was a good idea, and there wasn't anyone saying no. Or, could it be that they just didn't know any better because there was no standard to turn to?

With a standard in place that everyone can point at and say, "That's the way this community likes to do it," many things get simpler. Fewer trivial questions have to be worried over. The mind is freed to move on to more important subjects (like, When on a date do you eat the fried chicken with your fingers or your fork?) Even diverging from the standards will be simplified. Mandrake won't have to list where everything is in their distribution; they'll only need to point out what is different from the standard.

No one will stop you from distributing your project as a tarball. But if everyone else is using RPMs, you may find more acceptance we you go along with the rest of the community. The way it is now, some distribute RPMs, some use apt-get, and some distribute tarballs (with different compression formats). Each has some small strenght over the others, but in the end they are all more similar than different. The end result is that the poor newbie is just confused. One distribution format would give him one less thing to worry over. Standards are a good thing.

Re:Even if this happens, what can it change?

[Nailer]

The way it is now, some distribute RPMs, some use apt-get, and some distribute tarballs (with different compression formats).

Excellent post, but APT get isn't a packaging system. You meant to say Deb. Furthermore, APT get is designed to be packaging system independent and currently works with RPM or Deb.

And Soo... The saga continues.

[BadlandZ]

--INSERT SARCASIM- Again, the self claimed gurus of standards frantically address the problems of fragmentation. But, as usual, it's a fierce fight to find a middle ground between various distributions (if you wish, including Linux as a now heavy and already fragemented player along with the other standby *nix systems).

While all the troops lay out in the trenches of the subdivisions of /etc/rc* and /var/godknowswhy the real working system administrators couldn't honestly care less, they know the intricate deviations of each *nix they use already.

Lost in the trenches, the architects of the new FHS fail to see the growing problem of network integration, and the lack of logical in the situations of day to day mantainance.

If they had some balls, they would see, the battle should be for the greater good, and as such, ALL of the FHS should make a major shift in philosophy to how to make *nix systems more friendly.

Most already agree that the bin, etc, var, sbin, home, lib structure works pretty well. So, now use it!

IMHO, what needs to be done is:

• make /opt the place for EXPORTABLE. Subdivide /opt into the basic components, /opt/bin, /opt/sbin, /opt/home, /opt/lib, /opt/etc, etc... Then, all the exportable home dirs are in one place... all the binaries that can be run on similar architecture go in the exportable by design /opt dir. (exportable is not /mnt, /mnt is only for TEMPERARY stuff).
• make /usr/local REALLY LOCAL. Define it's structure like / and /opt, with /usr/local/etc, /usr/local/var, /usr/local/bin, etc... Put all the system specific stuff that isn't really part of the base OS (like apache and it's configuration files) in this LOCAL directory. Users who only run on that ONE system have a /usr/local/home
• make only the NEEDED stuff that is truly the BASE of the OS go into /, like the kernel, a shell or two (with the extra shells like zsh and such in /opt/bin), basic init stuff (and I don't care if it's SysV or BSD personally, as long as I know where to go to find it).

Just basically make some sense of it all! I know NO distribution (Solaris, Tru64, Linux, BSDs, none) will be compliant YET. But if they are making the standards, they need to have the balls to say "this makes sense, we need to do it, even if it takes a few years before everyone starts using it." In the long run, it is good for *nix. Everyone is just WAY to focused on short term middle grounds.... Why not focus on laying down a foundation that will not be continually growing more complex and illogical?

This is so typical of standards committees, put a band-aid on a harlequin quilt, and say it's all matching and compliant now. It's time to throw that quilt in the washer with a package of clothing dye, and REALLY make it all match.

Thus, finally, my annual *nix sux rant is complete, commence the flaming.

Re:And Soo... The saga continues.

[Malcontent]

Whever happened to old DOS days when every app lived in it's own directory and needed nothing outside of what could be found in there?
Is the concept of trying to save disk space even valid anymore?

Re:And Soo... The saga continues.

[Malcontent]

Or do what apple did. Throw out backwards compatibily and come up with a directory structure that makes sense to you, add a super slick GUI on the top of that, add some really cool programming environments and call it something geek sounding like MACOSX.

Re:And Soo... The saga continues.

[4of12]

I agree with the need for sanity about where to put things after wrestling with various flavors of UNIX for the past 15 years.

I've lost my personal favorite: user directories currently go into /home, where I had hoped the early transition would have been made from /usr into /u.

Given some of the divergence that has already occurred in some of the Linux distributions, I suggest that while it is fine to encourage uniform placement of libraries, config files etc. in the file system, that such a battle is already lost.

Retreat and fortify the next line of defense!

That is, enforce a standard with something like a global /configure script that populates a named database. That database will have name value pairs showing the important places that important things exist:

glibc_directory = /usr/lib

for example. Now, then, the line of defense against needless diversity is to enforce a standard on the metadata, the names, not the values!

If every distribution can agree that the same name will be used to contain the value, we can stop at one level of indirection and breathe a collective sigh of relief. Third party app installation will include a check for the existence of such a database to know where it should try to look for some dependent shared library, for example.

Then, every system should have a cron job to cull through every directory on the system looking for .MagicConfigure files to run that will update the database of name value pairs. Make it so the database can be mapped nicely into a hierarchal tree, can be converted to XML, etc.

KMail/KDE

[jfunk]

Did you notice the little clipboard icon in KDE?

That is a neat little interface to the standard X clipboard which is what is used by KDE, including KMail. You will also notice that anything you select, whether by Ctrl-C (using the keyboard entirely) or simply selecting with the mouse, will be in the clipboard. The little icon also has history, so you can select something from the history, and it will be in the X clipboard. It is truly seamless and friendly.

Netscape's handling is what is wrong here. KDE is doing the right thing, IMO. Besides, with the current Konqueror, I no longer need Netscape. I haven't used it since KDE 2.1 was released. I was buying stuff the other night and found that Konqueror worked were the latest Netscape didn't...

Re:KMail/KDE

[spitzak]

Correct, it appears that Netscape is in the minority.

Most new Unix programs use the PRIMARY selection for both the "copy" command and select-this-text. Netscape uses the SECONDARY selection for the copy & paste command. So only middle-mouse-click works to it. This may be true of all Motif programs.

I discovered this quite quickly when I foolishly tried to make fltk use SECONDARY in the same way. It fixed Netscape but broke everything else.

Only using PRIMARY is also good when you have programs like xterm, or ported Windows programs, that only have one way to paste.

Re:If they only had the balls.. GUI Balls?

[Malcontent]

Let me tell you why file associations are a bad idea. This is a true story.

My wife called me one day because her and the accountant had spent the entire day tring to get one quikbooks file transfered from her work computer into the accountants. She had done a backup but quickbooks could not see the file and double clicking on the program did something weird and eventually locked up the computer.

I went over there to find out that when she made the backup she named it backup.doc not backup.qbb. Because the open file dialog was filtering by qbb it never showed up as being on the disk. When she explored the disk it hid the extensions and she saw that there was a file called backup. When she double clicked on it word attempted to open up the file and crashed.

Here is the lesson. The name of the file should never be the most important thing about that file.

The machintosh had things right it knew about the program that created the file no matter what you named it.

Re:Bring Back /usr/doc!

[Malcontent]

If you said /usr/dict/words to joe use his brain would explode. Joe use needs to get a mac. MacosX is pretty nice gui for a unix!

Re:/usr/local vs. /opt?

[Nailer]

But Adobe stuff is closed source and ends up in /usr/local...

Actually, it doesn't. At least not in ANY of the acroread packages on RPMfind.net.

Red Hat put in in /usr/lib [!] which contradicts the FHS completely (yes, binaries can go here, no, documenatation are sample files cannot).

Everyone else puts it in /opt.

religeon != Sience.

[Forge]

It's realy that simple. You don't need solid profe in order to pray. However you do need it to consider something a sientific fact.

The interesting thing is that for those inside "Organised Religion", God is fact. However some of us ( including me ) accept that we cannot prove this to other people.

Bring Back /usr/doc!

[Anonymous Coward]

Maybe my Debian distro is screwed, but half of my documentation is now in /usr/share/doc. Why can't we just keep /usr/doc? And no reason why the dictionary has to be /usr/share/dict/words/ and not /usr/dict/words ... Arrgh, this is so annoying. Seems like design by committee to me...

Re:Bring Back /usr/doc!

[ChadN]

And furthermore (in regards to the original post) Debian packagers are slowly converting from /usr/doc to /usr/share/doc but many packages haven't yet been fixed in this regard. There is some debate as to how to handle this when relase time comes, since the rate of conversion (over 6000 packages now in Debian!) is somewhat lagging.

Why do we wait?

[Ubi_NL]

It was so cute to find that the new RH release used a new glibc, making it pretty much incompatible with older versions.

Are the FSG members supposed to wait untill the linuxbase paper is finished before they start thinking about being backwards compatible themselves?

The question is...

[Tom7]

Who do all the Linux Standards Base belong to?

I feel that you're missing an important point

[devphil]

It was so cute to find that the new RH release used a new glibc, making it pretty much incompatible with older versions.

Uhhhhh. Let's say that RH waited until version 14.0, a decade from now, to switch to the new glibc. Would you then be saying, "It was so cute that they broke backwards compatability." What about the other vendors who use the new glibc in their distros -- are they now guilty of breaking backwards compatability? Would you have recommended that no vendor ever change glibc versions?

It's not the vendor's fault if glibc broke compatability in a point release. At least RH waited until a major release before shipping it as the default library (I believe). At some point in time, every vendor is going to make such changes. The win under Linux, of course, is that if you don't agree you can always change out the glibc version yourself.

Re:/usr/local vs. /opt?

[Nailer]

The wording in the FHS and its use on the mailing list arenear polar opposites.

The FHS itself uses the wording `optiona' to describe things that go in /opt. Since this is completely arbitrary (neither distributions nor users nor admins nor ISVs have a consistent concept of `optional' software), the FHS itself is fairly poor in this regard.

But ask on the FHS mailing list, and your response will be: ifs its an application that needs its own tree, it should live in /opt, especially it its from an ISV.

If its something you've compiled yourself (which you want to have its own tree, thus being seperate from your packaged applications) it should live in /usr/local.

For one, I think /opt should be dtruck from the FHS. The only reason anyone uses to justify its existence in backwards compatibility - so I'd add a note

Why kill /opt?

* Because Unix applicatioons should be structured by the types of files (ie, documentation, configuration ,etc)and their role within the system (ie, whether being a base level component (eg, needed to boot and run nearly all programs). /opt breaks this.

* Because we don't need any more subdirectories under /

* Because people actually believe the FHS when it uses the term `optional' and decide to stick whatever fits their own personal definition of `optional' this week into the directory.

* Because "`/opt" is becoming "Program Files" of the Unix world and a dumping ground for badly written apps that use their own heirarchies making the filesystem even more of a mess

* Because I'd rather break compatibility (even in such a small way) than include this *hack* into the FHS simple for the reasons of backwards compatibility. I'm a DevFS / ACL / boot sanity / Xrender / DRI type of guy - if somethings is broken, I want it fixed, regardless of whether its popular in flavors of Unix I don't use. They don't set the standards any more, we do.

* becuase plenty of people also dislike /opt, including it seems most people on the FHS list and Alan Cox. Most of these would also prefer to see the directory phased out over time.

Re:/usr/local vs. /opt?

[Nailer]

Amongst all that, I forgot another important point:

* /opt was designed for closed source Unices where there is a clear delineation between OS vendor and third parties. That same delineation exists within Linux, but since the same package can be provided within or without a distribution, its not consistent. A distribution (which includes package x) puts x into its FHS annointed spot. A user running a distributions without package x who installs it puts in its FHS annointed spot.

Same package. Same base standard. Two completely inconsistent locations. I can no longer sit down at a machine and know where package X is instaleld anymore. This is the exact type of thing the FHS is set out to prevent.

apt-get should be able to install closed source pa

[Nailer]

Actually, there's no reason why anyone couldn't use apt-get to install binary closed source packages. Combined with encryption it could even allow you to purchase them from a distriobution mirror of those packages, with a small portion of the funds going to your vendor.

I'm probably not talking about Debian here, since most commercial software isn't tested too well on Debian or released as .deb. However, the newer APT based distros like Mandrake 8 and Connectiva should definitely expand APT (or libraries) to handle this. It saves admins time and hassle and makes them a little cash too.

As for where oracle should put its stuff, it should probably use /opt.

It should if it didn't come with the distro. if it did come with the distro (eg, Red Hat + Oracle, of free databases which do and don't come with distriobutions) it should live in /usr/local, according to the FHS list (the FHS itself is very unclear).

Hey wait...same package...two locations. I can't sit down on a machine and know where it lives anymore. Oh my God! Maybe /opt is broken!

Re:If they only had the balls..

[Nailer]

File Open dialogues should be customized between GNOME/GTK and KDE/QT applications.

Its amazes me when people keep telling me `yes, but different people work on GNOME and KDE' as some type of magical excuse (not you specifically, but in general). So?!?! Lack of consistency is hurting Linux desktops more than competitoion is enhancing it anyway, but that's a point for another day. Sit down with each other and work out a standard design. If you're *really* worried, juts make somethign that looks the same in your respective toolkits.

Linux less fragmented than it used to be

[meltiste]

I think with the rise of the gnome and kde projects that linux is likely less fragmented today than it used to be. Most people only see the desktop 90% of the time anyways.

thoughts

[OdinHuntr]

- This is version 1.1, not 1.2

- Why XFree86 3.3.x? 4.0 has proven stable and is faster.

- Why on Earth is there no mention of Perl? Perl is the glue that holds many, many useful applications together; not including it in a standard makes no sense.


--

/usr/local vs. /opt?

[Isaac-Lew]

What (if anything) is the difference between these two? The only thing I can tell (from personal experience) is that Solaris wants to put stuff in /opt, & most Linux distributions prefer /usr/local (as do most GNU programs). The FHS doesn't really make any distinction; the 2 sections (on /opt & /usr/local) look the same to me.

Ah....standards....

[Kris Warkentin]

I guess the key reason for standards among Linux distributions is for vendors of binaries....Oracle needs to be able to make some assumptions about where things are/should go if they're going to distribute distro-agnostic software. I think it's probably a lot easier (in general) to distribute binary software in the Micro$oft world at the moment. Maybe what we need is some generic tool for installing binaries (like Installshield) that can detect what it needs. After all, automake and autoconf makes it pretty easy to get stuff to BUILD on various distros/Solaris/*BSD/etc. It should be that easy to INSTALL as well.

*sing* I'm a karma whore and I'm okay....
I sleep all night and I work all day

runlevels are beyond the scope of FHS

[slothbait]

The FHS (Filesystem Hierarchy Standard) lays out the basic organization of a compliant filesystem. The differences between flavors of init scripts run deeper than simply where the scripts are located within the filesystem. Thus, runlevels are beyond the scope of the FHS.

While inappropriate for the FHS, runlevels may well be treated in the more comprehensive LSB. I am unaware if this is on the agenda of the LSB, but the current discrepancy between systems is certainly an annoyance. However, standardization of start up scripts may prove difficult as it involves treading through a few holy wars. Some of the old SysV / BSD schism carries on in the Linux camps, and this partially explains the different runlevel schemes in use today.

Personally, I think rc scripts *should* be homogenized, and the LSB may be the appropriate body to push this through. I don't think the current divide is buying us much other than headaches. However, presently the LSB seems more concerned with binary compatibility at the application level: glibc versioning, ABI standardization, etc. This is a rather important topic as third party companies begin porting to "Linux", which they quickly find is segmented into ~5 pretty much compatible systems. This isn't such a big deal if you have source code, but can be a big hair mess for binary-only applications. Of course, some would argue that they don't *want* binary only applications on their system, but I'll leave that debate to the Slashdot masses...

--Lenny

If they only had the balls..

[slick_rick]

This could really be a good thing. They could fix many of the "problems" that prevent Linux from dominating the desktop.

Setting a standard set of APIs for stuff like the clipboard, file associations, desktop integration, etc. The Windoze way to handle clipboard stuff is to first "register" a type for the data you are placing there. Most apps use a canned type and therefore you can cut and paste between almost any windows program. Why is it bad for things to work? Couldn't we do the same thing in X with a XML spec of some sort?

And how about standardizing the interface a bit. I can't tell you how hard it is to explain to my wife that in KMail you use CTRL+C to copy, but then to paste it in Netscape you push the middle mouse button, and hope...

Not to mention the 15 different file open dialogs I see every day. Some of them are really rotten too...

I love Linux, don't get me wrong. However, I believe that standardizing some of the more obvious stuff for the GUI crowd would benefit us all immensely.