Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Announcements Software Linux

LSB Project Seeks Input at Annual Meeting 17

Posted by timothy from the fair-warning dept.
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!
This discussion has been archived. No new comments can be posted.

LSB Project Seeks Input at Annual Meeting More

LSB Project Seeks Input at Annual Meeting

Comments Filter:
  • 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.
    • 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 [christiannerds.com] too? Maybe we could trade links.
      • 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 [autopackage.org] support became part of the LSB one day ;)
  • 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! (Score:3, Funny)

    by MoogMan ( 442253 ) on Monday August 01, 2005 @09:26PM (#13219156)
    Note that the room only holds 55 people, though!

    Potentially giving us a new meaning for slashdotting!
  • 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 makin

    • (..) 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 [pathname.com] v2.3: "There may be one or more variants of the /lib directory on systems which support more than one binary format requiring

      • 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
  • 1. Get rid of RPM.
    2. Add APT.
    3. Er...
    4. That's about it.
  • LSB has rendered itself useless after picking GNOME as the standard.

    It is no longer a Linux standard, but only a GNOME Standard Base.
    • MODS please mod parent Funny.
      Or Troll. :-)

Slashdot Top Deals

Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.

Close