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."
This is great and dandy and all, but which distro's are going to pay attention to this? Anyone have a link as to the state of LSB-compliance for the major distros?
For the lazy... (from the document):
The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.
The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.
The LSB is composed of two basic parts: A common part of the specification describes those parts of the interface that remain constant across all hardware implementations of the LSB, and an architecture-specific part of the specification describes the parts of the specification that are specific to a particular processor architecture. Together, the generic LSB and the architecture-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
-----
LSB is an excellent initiative. But the bad thing is the "L" ("Linux") in it.
This standard is designed for Linux, and only Linux.
Standardization of the filesystem namespace is needed on *ALL* Unices. And an unique document that would apply to *ALL* Unices would be a big win, both for developpers and for end-users.
DJB's packaging system isn't that bad. The only trouble is that only DJB promotes it and very few software are packaged that way because it totally changes the traditionnal namespace layout.
{{.sig}}
There is a poison that is affecting this great land, and that poison has a name: Linux.
You may have heard of this dangerous hacker's program. Developed by the Soviets during the Cold War, Linux is a "UNIX-like operating system." In layman's terms, this means it is computer software that allows criminals to perform unauthorized (and illegal) tasks with their computers. What may shock you, however, is that this program has begun to slowly make its way through our nation's computer networks, and now threatens the economy, the stock market, and the great corporations that founded our country and keep it running.
Linux, and other hacking tools with such strange names as "emacs," "PHP" (an obvious drug reference) and "gcc," have been used by thousands of foreigners and terrorists to undermine the American way of life. Okay, I realize you might be skeptical. How, you ask, could the United States, the world's peace-keeping police force, allow such harmful programs to enter our great country? Folks, I wish this was just an alarmist rant. But the threat to capitalism is real. Although the former Iron Curtain is long gone, its final creation is coming to bear on our own soil, in our own backyards.
Yes, friends, leftist groups and individuals, although mostly confined to covert computer hideouts called "chat rooms," are actively spreading Linux into corporations and other organizations as you read this. Why would any American do such a thing? We may never know. Perhaps these misguided individuals have been shunned by legitimate software development firms like Microsoft and America Online. These poor souls, many of whom are but children, have sadly devoted themselves to a life of crime, by secretly learning programming techniques such as "debugging" and "optimizing," techniques previously reserved for patriotic, God-fearing professional engineers like Bill Gates.
The time to act is now! As proud citizens and voters, we owe it to our children to stand up to this new "red scourge" and voice our concerns to our elected representatives. It is a sad testament to our country's deteriorating moral fiber that, despite the efforts of righteous Christian organizations such as the RIAA and the MPAA, the use and possession of Linux is still legal. Frightening, yes, but through faith and determination, we shall drive these Linux terrorists from our holy American soil.
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.
Agreed. There is a similar project for the BSD
world at http://www.openpackages.org/. It would
be _great_ if the two would cooperate to define
a common *nix platform that vendors could depend
on.
b
What f*ing box!?!?
No no, it's ok, really...
Other Unices can just use the L-SBE (The Lesser
Linux Standard Base).
:)
"Can of worms? The can is open... the worms are everywhere."
My personal objections to the LSB are large, and centered around one single fact: The LSB documents as "standard" the GNU C library and command line utilities. This means that every Linux
So, the net effect is that any system claiming to be Linux-standard [according to the LSB] must support all these wacky, underused, GNU-specific extensions in their commands and C library. Given the proliferation of C libraries under Linux this seems like a mistake of a large order.
But this isn't the reason why I use Debian. That reason is the deb format. It's quite simply far more powerful and more consistent.
Here's a discussion of the issues by a Debian package maintainer
But deb format maintenance requires a certain package developer/maintainer culture that might tend to clash with the requirements of the kernel/base developer/maintainers, which are rather different from those of general package maintainers. And Debian-based systems can already deal with rpms, no problem, using alien. So using rpm for standardized base is a no-brainer.
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.
I'd like to just get a few objections in on the LSB while everyone runs around cackling with perverted glee.
/log come to mind) but at least that lets us get an idea of where the mess all came from, and when we delete the directory we can also delete all dangling symlinks and truly get rid of stuff.
/usr/bin and the lib directories.
I for one am sick of finding files from install packages all over the place. Everyone and their mother is sick of this. Apps should install into ONE directory only. They can symlink everything they want everywhere else (/etc and
Linux is literally worse then windows on this count. PLEASE PLEASE contain the spawl. Someone needs to do an ls -l on
It won't happen because it's a bad idea. This kind of standarization stifles innovation. Of course it is a good idea to have a way for packages to know where things can be found, but that's generally going to be standard executeables, libraries, headers, and various resource files. One of LSB's problems is it's aiming to become the ultimate distribution where everyone else is just forced to make a copy of them.
now we need to go OSS in diesel cars
Nothing wrong with binaries. Just do:
and there you have it, your binaries are installednow we need to go OSS in diesel cars
What LSB really needs is some alternatives to choose from. The thing I most dislike about standards, especially those that try to codify existing sloppy practices, is lack of choice and the end to new ideas.
now we need to go OSS in diesel cars
From http://geektools.com/cgi-bin/proxy.cgi, the geektools.com whois search:
Server used for this query: [ whois.addresscreation.com ]
Whois Server Version 1.3
>>>>Whois Database last updated on: Fri Jan 4 03:32:01 2002
Organization:
Buy This Domain
Web Master
5 Tpagrichnery St., # 33
Yerevan Yerevan 375010
Armenia
Phone: 208.978.3555
Fax: 208.978.3555
offer@NameRegister.com
Registrar Name: addresscreation.com
Registrar Whois: whois.addresscreation.com
Registrar Homepage: http://addresscreation.com
Domain Name: unix-vs-nt.org
Created on: 11/25/2001
Expires on: 11/25/2002
Record Last Updated on: 11/25/2001
Administrative Contact:
Buy This Domain
Web Master
5 Tpagrichnery St., # 33
Yerevan Yerevan 375010
Armenia
Phone: 208.978.3555
Fax: 208.978.3555
offer@NameRegister.com
balh...blah...blah
In other word, they let the domain expire and some slimeball snapped it up, hoping to make a quick buck. The lesson kiddies: don't let your domain registrations expire!
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Have you ever had a problem with ./configure; make; make install; not working ?
Whoah my friend... if you've NOT had a problem with that, I suggest you either don't compile many projects you grab from various sites, or you only compile your own stuff (or you don't compile at all). Probably 1 in every 8-10 tar.gz packages I get I have a problem with "./configure make, make install". It usually revolves around some dependancies not being fulfilled, but it's also sometimes caused by the package maintainer hardcoding things where they shouldn't.
creation science book
Personally I'd rather have things equally bad than have each distro be bad in its own unique way...
creation science book
It doesn't take a lot of thought, and is overused by people who think altogether too much of themselves.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
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.
:). Anyway, do the following on your Red Hat box:
:)
I too have had more problems with apples as opposed to oranges
1. Visit FreshRPMS
2. Download and install the APT p[ackage from there
3. Use APT to check your system for dodgy package, then apt-get update.
4. You may now APT all of Red Hat 7.2, sources, extras, and a bunch of brand new cutting edge packages created on request by FreshRPMs ninja Matthias Saou.
5. Smile
PS - Matthias needs more mirrors and Python / Perl ninjas to help him with RpmForge, his upcoming project. get his contact details from the web site.
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. . .
What, standard Unix? ROTFLMAO. The Linux folks had better jump quick and try to make everything Linux work just like Solaris, err no, AIX, NO! True....
The parent of this thread was flamebait. No normal person would say a developer was unaware of sed because they implimented a function.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.