Slashdot Mirror

← Back to Stories (view on slashdot.org)

LSB & Posix Conflicts

Posted by Hemos on from the understand-it-better dept.

An anonymous reader writes "The OpenGroup has published a detailed list of the conflicts between the Linux Standards Base and Posix ? that is accessible through their website. "

4 of 354 comments (clear)

  1. int post(0); by Anonymous Coward · · Score: -1, Troll

    slashprintf("HAHAHA! GNAA CAN SUX0R H0RS3 COX0RZ");

  2. How about making more Distros comply first. by Anonymous Coward · · Score: -1, Troll

    The biggest violator is Debian gnu/linux. It uses an outdated kernel (violation, the standard specifies 2.4.19 and above), a non standard implementation of X (A hacked version of 3.3.6 to use X4 modules), A propeirtry (as in incompatible, not as in closed) package format known as dotdebs (RPM is the official standard). Uses an outdated file system (it uses ext2, the offical filesystem is reiserfs). Uses EMACS as its text editor (the offical one is vi for the console and kate for X) and finally it uses gnome as its default window manager (the offical standard mandates kde)

  3. screw POSIX by Anonymous Coward · · Score: -1, Troll

    fuckem. Linux is about creating new shit - not being weighted down with legacy POSIX crap

  4. Re:Oh yeah? POSIX can be DUMB! by Anonymous Coward · · Score: 0, Troll

    There are many uses for gets(), and I'm surprised you
    can't imagine how it can be used safely. In fact it can,
    if you stop and think about the problem for a bit.

    But there's also the issue of legacy apps that need gets().
    Don't give me this "it needs to be rewritten" stuff. What
    if someone wanted to run these apps on their own
    computer, disconnected to the net, in a bomb proof bunker
    in the middle of the Antarctic, giving only VALID INPUTS
    to gets(). Would it not be THEIR CHOICE and not
    LSB's silly, knee-jerk reaction against gets()?

    A better question is why, oh why, did LSB decide to kill
    the messenger (that is, gets()), instead of fixing the
    original problem (W^X pages lacking in kernel, no exec
    stack emmu on x86).