Porting to the Linux Standard Base
An anonymous reader writes "If an application conforms to the Linux Standard Base (LSB), and a flavor of Linux is LSB compliant, the application is guaranteed to run. This tutorial, written by Martin Streicher, Editor in Chief of Linux Magazine, ensures that your code runs reliably on as many Linux flavors as possible. It shows you how to port your apps to the Linux Standard Base, then takes you through the LSB test tools to verify conformance."
and was just an attempt by redhat to push the subpar RPM package format. If they were serious about a somewhat standard linux, they would have started with debian.
"If they were serious about a somewhat standard linux, they would have started with debian."
1-LSB is more than just RPM.
2-There's nothing wrong with RPM. Just the people who use it.
It' looks like it only applies to package formats. Am I wrong?
I would really love to see this implemented by everyone!!! http://en.wikipedia.org/wiki/Filesystem_Hierarchy_ Standard
"Anyone have a "public" version of this doc?"
Building Applications with the Linux Standard Base
Rubbish.
Autotools are the wrong solution, LSB is the right one. Autofoo is an awful build system (the nick "autohell" has its reasons, just see the results in google). They are horrible to use, the scripts are a nightmare to debug, and M4 is just plain from hell. SCons, CMake, Premake, Jam are better tools (btw, CMake has been created by autotools veterans and creators). The interest in better build systems is quite high, just look at the KDE guys (they moved everything from autofoo to CMake), or at Blender. Autotools may have been a good idea back then, but its time for some progress.
Also, NO ONE ever uses autotools in Windows, there is just no reason to do that.
CS is bad bad bad? Oh my. CS is THE ONLY WAY Linux is ever going to have serious games (is Doom3 OS? UT2004? NWN?) and if Adobe decides to port Photoshop, be prepared for a binary blob. Maya is closed source. Baad programs we don't need? Dream on. Besides, the aforementioned games have their issues with incompatible libc's etc. which is the precise reason why LSB is a GOOD thing.
This sig does not contain any SCO code.
There are three distributions listed that conform to LSB3.0: SUSE, RedHat, and Asianux. Why should I write for LSB?
FTFT (from the...tutorial): LSB has binary compatibility standards, so I can compile once and run anywhere. But if the application is GPL and nontrivial, it shouldn't be that hard to get it into the package repositories in question. Otherwise, it's probably in a scripting language, so the end user doesn't have to build or install it anyway.
This is really only important for commercial Linux software.
GNU Autoconf and Automake, when used properly
Fuck them, dude... Both are a bloated wet-scriptkiddie-dreams. Any project that relies on those two bitches needs at least one developer to maintain them. Debian has two different autoconf versions included where one works worse or better than the other...
I rather change my code or add the whole codebase of a lib into my code befre I start thinking about those two bitches who bitch about shit that has nothing to do with getting the project done!
I wonder if the autoconf developers can even spell or understand the meaning of the word "lite" since autoconf's only job should be to find files (*.h and libs) and stuff inside these files and define macros accordingly. But it does everything else and bitch about it... ooops-here M4-bullshit-there..
It's a complete mess... and here you are suggesting to use autoconf and automake to build packages?
DIE MONSTER!!!!
The point of dynamic libs is not just the memory savings, both RAM and disk, but the bug fixing. You fix a bug in a lib, all the linked apps get it fixed by definition. Static apps require the vendor to relink and rerelease the apps.
There is also a small slowdown with dynamic apps, load and runtime, but that has never bothered me.
Infuriate left and right
Quake 3 is open source. Check out Tremulous or the newest Rocket Arena for games using the engine.
...but don't feel bad, so do most people on this forum
_ Standard
It' looks like it only applies to package formats. Am I wrong?
Yes, you are almost completely wrong. LSB applies to much more than package file formatting. LSB distributions have a common set of libraries and such, so that every single LSB package has the exact same set of dependencies--those defined by the spec. There is even a package NAMING convention that must be followed to ensure there are no package naming conflicts.
I would really love to see this implemented by everyone!!! http://en.wikipedia.org/wiki/Filesystem_Hierarchy
Then you'd really love to see LEB implemeted by everyone too, becasue the FHS is one aspect of the LSB.