LSB Project Seeks Input at Annual Meeting

nickstoughton writes "The Linux Standard Base (LSB) project is holding its annual plenary meeting next week, Aug 8, in San Francisco, to coincide with LWE. The meeting is open to all, and the workgroup is seeking feedback on the next direction to take now that LSB 3.0 is out. But ... you must sign-up in advance since the meeting is to be held in IBM's San Francisco offices, and building securuty needs to know names for badges. At very least, this should be an opportunity to grill the developers of the standard as to why it is the way it is, what's happening with the ISO verion of the LSB, etc. If you are planning on going to Linux World Expo in San Franciso, this is worth adding to your itinerary!" Note that the room only holds 55 people, though!

Comments

yes but what is it?

[nocomment]

What does LSB do? All I know is that it's supposed to bring more standardization to Linux, but about the only thing i've noticed is that I've checked the box for "LSB" at Mandrake `s/rake/riva` and it's made a couple things not work right (although I can't remember what they are now).

Perhaps they need a simple "these files go here instead of here" level tutorial on it.

Securuty? Verion? San Franciso?

[verbatim_verbose]

Now, Slashdot does often have grammar of dubious quality, but, give me a break!

No offense, but you really shouldn't post articles written by people that write like small children without at least glancing over them.

A slashdotting!

[MoogMan]

Note that the room only holds 55 people, though!

Potentially giving us a new meaning for slashdotting!

LSB/FSSTD brain-damage to be cured?

[Improv]

If anyone goes, try to bring up the mess they've made for amd64 -- that native 64-bit libraries don't live in /usr/lib, instead living in /usr/lib64. This is a mess, and in a few years the excuse that it's there for compatibility won't matter. It's not cool to pay more attention to backwards compatibility than to native code, and it's always something one regrets later. Another counterargument -- that legacy software that needs to find libraries to load or link to at runtime could easily be handled by making ld a little bit smarter, rather than complicating and uglifying the simple, native case.

Re:LSB/FSSTD brain-damage to be cured?

[Alwin Henseler]

(..) that native 64-bit libraries don't live in /usr/lib, instead living in /usr/lib64. This is a mess, and in a few years the excuse that it's there for compatibility won't matter. It's not cool to pay more attention to backwards compatibility than to native code, and it's always something one regrets later.

How do you mean, a mess? To quote from the Filesystem Hierarchy Standard v2.3: "There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries."

So for example a /lib64 or /usr/lib64 isn't there to indicate that libraries are native 64 bit, nor for backwards compatibility. Only for allowing different sets of libraries side-by-side on the same system, if needed. In that case, you can have a mix of binaries linked against different library sets, that live happily together.

Don't want or need that? A simple symlink, or hard-linking one directory to another, should do the trick.

.. and it's always something one regrets later.

Once all binaries are linked to a single library set only, changing "lib64" back into "lib" is trivial. So what's your problem here?

Re:LSB/FSSTD brain-damage to be cured?

[Improv]

The problem is that it is forbidden to fix later, burdening the system with a shortsighted legacy. /usr/lib is reserved for 32-bit legacy libries on amd64, and /usr/lib64 is reserved for 64-bit native libraries. If they wanted to put the legacy libraries in lib32 and native libraries in either lib (ideal) or lib64 and use a symlink (less ideal), that'd be fine. The mandate that things be perpetually the wrong way around is what bothers me. To be clear, your symlink breaks the standard and also neglects the issue that LSB-compliant native code must incorporate the lib64 mess.

What are you talking about with regards to hard-linked directories anyhow? Very few filesystems support directory hardlinks, and given what userland applications expect and do in practice, directory hardlinks are unsafe to use on the few filesystems that support them anyhow.

Standards

[GuitarNeophyte]

Isn't it sad, though, that standards tend to only be set by those who are the minority, in order to convince the major player to conform to them?

It's not flamebait, it just seems true. Like, the whole, IE7 thing. It said it's just adding the most-requested standards to the package.

*shrug*

Luke
----
Have a website that teaches basic computer education too? Maybe we could trade links.

Re:Standards

[ZephyrXero]

The main reason you don't see it advertised for more distros is because you have to pay for certification. A lot of the distros will try to follow most of the LSB guidelines, but don't have the funding to spend on certification.

I'd love it if Autopackage support became part of the LSB one day ;)

LSB wishlist

[metamatic]

1. Get rid of RPM.
2. Add APT.
3. Er...
4. That's about it.

Re:LSB wishlist

[Compenguin]

sigh,

rpm:dpkg::yum/apt4rpm:apt

Re:LSB wishlist

[metamatic]

I know. I was eliding the details.

For the hard of thinking:

1. Remove RPM.
1b. Replace it with dpkg.
2. Add APT.
2b. Removing YUM.
3. Er...
4. That's about it.

Re:LSB wishlist

[corsec67]

Just as long as the default package isn't binary.

(points to sig)

Re:Securuty? Verion? San Franciso?

[Anonymous Coward]

" Now, Slashdot does often have grammar of dubious quality, but, give me a break!"

If we're going to be picky let's mind our own grammar and cut down on erroneous commas.

LSB is useless now

[Carewolf]

LSB has rendered itself useless after picking GNOME as the standard.

It is no longer a Linux standard, but only a GNOME Standard Base.

Re:LSB is useless now

[Anonymous Coward]

It hasn't picked Gnome as "the" standard. Work is proceeding on gtk+ libraries which meet the LSB selection criteria. Work is not proceeding on kde libraries, which are blocked by the license choices made by the vendor of qt, the underpinnings of the kde system. If that issue were resolved, kde is not otherwise excluded.

Re:LSB is useless now

[turbidostato]

"Work is not proceeding on kde libraries, which are blocked by the license choices made by the vendor of qt"

And what are those choices that preclude KDE to be currently there?

Oh, yes, I see! Gtk+ is LGPL while Qt is either GPL.

Well, you just need to have a look at Linux kernel and Linux distributions history to see it is all about... er... Open Source/Free Software (I won't go into that war now) while the choice of Gtk+ has no sense unless we understand it benefits some privative licensed software sellers while it has no advantage to anyone else.

That kind of mentality is percolated all the LSB stuff along, and that's the very reason why LSB will never be but of secondary interest.

Ha Ha

[hummassa]

MODS please mod parent Funny.
Or Troll. :-)