Slashdot Mirror
The LSB Delivers Again
gk4 writes "The LSB has updated and published the
gLSB v1.1 draft for review. The LSB has also published for review the new
psLSB for IA32 v1.1 draft and the completed
LSB v1.0.1 Test Suites. Review ends Friday January 4th; however, the LSB welcomes comments from the community at any time."
Yes, I'd agree. Unix was supposed to be the great standard, and then stuff started branching off. I've never used any other unix (than linux) except freeBSD briefly, but I think that someone needs to unify our unices. It'd certainly set a good standard.
So RPM is now the "standard?" I'm not sure I like that. RPM is great and all, and many distros use it or at least can handle them, but I think maybe it should be refined a little more. I like debian's package manager as it is easy to use and fairly straightforward. I know RPM is supposed to be that way as well, but I've had a lot more dependency problems with RPMs than I have with apt.
wonder how many sites get /.'d simply because folks are trying to find out "what the hell" the acronym means.
Same with random other sites that have are not related to the project, but share a similar acronymn.
I'm sure the owner's of www.lsb.org are right now thinking... "Where the hell is all this traffic coming from?"
"Can of worms? The can is open... the worms are everywhere."
By that logic the GNU tar maintainer shouldn't have included the -z flag either because you could always pipe the output from tar through gzip. The -E flag for cat was almost certainly added for the same reason that many commandline flags are added to GNU software. It was easy to add, and it makes the software a little easier to use. Why in the world would I want to use sed to put a '$' at the end of the line when I can simply do cat -E?
I also think that the LSB is fundamentally flawed, but not because it specifies GNU software (complete with their various and sundry GNUisms). The LSB is flawed because it isn't self hosting. In other words there really isn't a good way to know that your binary application is LSB compliant. You can't just install the LSB onto some test machine and bang away on it. They are working on a test script that hopefully will eventually allow you to check for compliance but currently the README states:
And if that isn't bad enough, the LSB isn't a particularly exciting platform to port to. Most of the cool new Linux features are not included. Basically the LSB is Linux with all of the joy sucked out. No wonder commercial vendors simply test against RedHat and call it good. It simply doesn't make sense to do anything else.
I can understand wanting to have a standard Baseline to have across the platform but it fails miserably.
,"We like it that way"
/usr/local/lib in the ld.so.conf (pretty retarted of them)
Redhat,slackware,Debian....
all are completely different to the point that only one will work correctly if you download a major project's sourcecode and install it, it works. and that is slackware. Redhat decided to place apache where is isnt supposed to be, and Debian decided to move KDE around. Why? they wont give any good reasons other than
Creating incompatabilities like this does nothing but create problems and fractures in the Linux camp. Apache needs to be installed in EVERY distro where APACHE or the end user wants it. X,KDE,GNOME, etc... wherever the sourcode for that phoject drops things after an untar,make make install happens is where it goes. not where Alan Cox wants it, not where Linux wants it.. where the Apache or that project's Development team wants it.
and then we have lib dorectories all over the place, redhat not coming with
The things covered in the LSB are not important... What is important is getting a linux filesystem layout standard in place and FORCING it upon every distro.
it wont happen......
and linux will remain a nitche until it does.
Standards/guidelines are good for the Linux community, how many times have you followed a installation readme, or read a HOW-TO and *nothing* is where it supposedly should be?
Try typing which filename with common executable names on two different distros and you will know what I am talking about.
That is why I think the FHS is slightly more important. The Filesystem Hierarchy Standard is supposed to help prevent this, so hopefully the LSB compliments this cool document supported by freestandards.org.
This sig is taken.
By that logic the GNU tar maintainer shouldn't have included the -z flag either because you could always pipe the output from tar through gzip.
You completely missed the point. Standards need to be lowest common denominator. Having a -z flag in GNU tar is damn useful. But it should not be the standard.
There are standards for most Unix utilities, and those standards should have been used instead of the mandating the GNU extensions.
A Government Is a Body of People, Usually Notably Ungoverned
Standardizing Unix has been tried; the results were things like POSIX and the Single Unix Spec. They cost millions to develop and didn't completely solve the portability problem. Why try again?
...it all lives in one file.
/usr/local/etc/rc/ and are just simple shell scripts. They can be as simple as 2 lines, or as complex as any shell script can get. Every shell script in this directory is run in alphabetical order. This is where stuff like Apache, MySQL, and the like would keep it's start up stuff.
Okay, some serious clarification needed for folks who don't normally use FreeBSD. The "one file" in question is "rc.conf". This file has no scripting at all in it. It looks far more like a simple config file, with variables and values, then an rc.d startup script.
This file only affects core OS kinds of things, like basic network settings, host name, and stuff like that. For most folks this file is something like 10 lines long. It can get a healthy bit longer depending on what you're doing. Without looking, I'd guess mine is about 20 lines with comments and such added.
For daemons not expressly part of FreeBSD there are still start up scripts. They live in
I personally found the FreeBSD far simpler for me to grasp what all was going on then the sysv startup. On RedHat those scripts looked so darn complex for a newbie not then familiar with shell scripting (a bit smarter about that these days) that I was forever afraid to alter them. The whole time I had RedHat installed I just started up Apache manually rather than try to tackle where in them rc.x files I needed to add the stuff I wanted. Even as a relatively new Unix user I totally "got" what was going on with FreeBSD, and had very little trouble altering which services started, or didn't.
I've just heard this "one file" argument against FreeBSD too many times now as though there was some sort of monstrous 1000 line file a user had to figure out. This simply isn't the case at all. Regardless of your preference I felt that a fair comparison of the two systems needed some clarification from the other side.
The line must be drawn here. This far. No further.
The result is that most major Linux distros can't keep binary compatibility between updates and errata on the same OS release, much less between releases. Even with the LSB, I think it will be a while before we see binary compatibility between distros.
Use SCO Open Server some time. They do this. All packages are installed in a "per directory" manner and then sym linked to the "/bin, /lib, /etc" heierarchy.
.let me hit a few quick points. . .if you're very interested I could write a large paper about why it is a bad idea. . .
.this simple script will symlink every file into a "package heierarchy" [untested]:
/Program-Files
/Program-Files/$F
/Program-Files/$F/$G
/bin /lib /etc format is an EXTREME advantage. You can optimize mount points based on file types (ro,rw in NFS rsize, wsize, etc) and most of all with NFS you can remote mount filesystems off of a large server that are not likely to change (such as the /usr/local directory but unlike the /etc diretory) and thus have a central install base that only requires ugrading *ONE* server.
.spec file and use rpm to build them. That way they'll be in the database and you can easily un-install them later.
.I think that's why most people won't even bother attempting to reply to this. . .
I thought it ws an interesting idea until I had to admin about 50 of these things. . . I can't even begin to explain why it is a bad idea. .
It's a complete mess not to mention the massive performance hit from derefencing every symlink (afterall you're not going to have your PATH contain hundreds of variables to EVERY package's sub-directory so you'll still be referncing the current heierarchy after which you file system will have to dereferance every single stinkling sym link).
If you *REALLY* want every single file for a program in the same directory you can easily do it with the RPM database. .
#/bin/bash
mkdir
for F in `rpm -q -a`; do
mkdir
for G in `rpm -q -l $F`; do
ln -s $G
done
done
Have Fun!
BTW having files in the
Having a central install base is a *BITCH* in Winblows and a lot of it has to do with the filesystem heierarchy.
Lastly the RPM database is the answer to your dilemma. It keeps a record of where every file is for every program. If you want to get rid of every file to a program you simply do a "rpm -e". That's it! Rather then doing "make install" with your builds simply write a
The advantages to the current heierarchy is massive and frankly if you don't like it learn how to use the RPM database or get the SRMS to everything, do a little editing on the install scripts and create your own custom distro.
I hope that most people will agree with me that the current heierarchy has many many high-level administrative benefits (that you only realize after you've managed a few hundred UNIX boxen at a time). .
As a note SCO OpenServer used to be known as XENIX, a Microsoft product. . .
I assume you are talking about packages you compiled and installed by yourself, since what are you talking about is clearly a non-issue with packages handled by a proper package manager.
Well, for packages based on autoconf/automake that you compile by yourself, there is GNU Stow doing exactly what you ask.