Slashdot Mirror
LSB & Posix Conflicts
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. "
← Back to Stories (view on slashdot.org)
IMHO it's better for GNU/Linux (never know if rms is watching ;) to comply to the older POSIX standards than a nice utopian LSB. I doubt if it will ever get of the ground since the whole Linux distro's are so scattered and divided (let alone the commmercialization of certain products).
e e.org/regauth/posix/
btw. check the following for more information on POSIX
http://www.posix.com/
http://standards.ie
Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing"
Can someone familiar with the decision making process post a summary of why the LSB group simply didn't choose to implement POSIX rather than creating their own standard?
I've read most of the article, and while there are some things that were clearly (and subjectively) chosen by the LSB group as being "better" (line 123, for example), others appear to be technical limitations (line 219, for example) and some are purely arbitrary (for example line 282).
A lot of time and experience went into creating POSIX, and on the whole it's pretty sound. It seems a shame not to leverage it, both from an academic perspective, and also because lack of POSIX-compliance is a barrier to porting existing applications to Linux.
SCO: "Too similar"
TOG: "Too different"
LSB: "Just right!"
Sheesh, evil *and* a jerk. -- Jade
- The LSB spec is a sub-set of the required POSIX implementation (E.g. PThreads)
- The LSB spec has pulled in some extra GNU functionality (E.g. getopt(), extra flags to a few shell utilities)
None of this seems to major however. Some of it even seems sensible (E.g. the LSB deprecates gets()) Some of it is dangerous though. This is especially true where the LSB and POSIX spec defers on things such as ioctl() and system() In these cases, LSB needs to come into line with POSIX, or at least support the LSB implementation as a superset of POSIX.Some of the LSB PThreads stuff could be anoying, but currently very few implementations of PThreads are feature complete anyway. LSB and Linux have just as much chance as anyone else to bring themselves into line with POSIX.
Nothing too shocking, but it could be a handy reference. If in doubt though, stick with POSIX.
099 2.1.2 gethostbyname [...]
102 2.1.3 getopt [...]
106 2.1.4 gets [...]
109 2.1.5 getservbyname [...]
112 2.1.6 getservent [...]
115 2.1.7 ioctl [...]
120 2.1.8 iswctype [...]
123 2.1.9 kill [...]
133 2.1.10 nice [...]
139 2.1.11 opterr, optind, optopt [...]
142 2.1.12 strptime
Pfff, we're saved. printf("Hello world\n") will still work on all platforms. Isn't it the standard portability test after all?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
I do a lot of really high-performance multi-threaded programming, and the Linux threads model pretty much eliminates it from competing in that arena - and believe me, I'd love to be able to underbid any competition by constructing a Linux cluster of commodity pizza boxes.
There's no way doing a popen() or system() should hang a multithreaded process.
If IBM is really going to make Linux work on this sort of enterprise level, maybe they should make Linus an job offer with one crooked number followed by a blank and tell Linus: "Fill in as many zeros as you think is correct".
POSIX does some dumb things. Ever hear of the gets() function?
Also, in most cases the LSB is a superset of POSIX, but the contradictions are _minor_. Not show-stoppers.. not enough to require significant application rewrites when porting to Linux. So what if O_LARGEFILE is set most of the time? This is actually a good thing because most of the time it causes no problems. Even if you are checking the fd flags O_LARGEFILE being set isn't a problem as long as you check the flags in the _right_ way, that is logical AND'ing them with the flag you want to check for. The only time this contradiction causes a problem is if you are breing stupid and expecting the flags to be explicitly equal to some magic number you were expecting. Sure that is not exactly to spec, but for 99.9% of the apps out there it doesn't break compatibility, and if it does it's a one-line fix. However the benefint of fcntl() acting this way is clear -- most apps on linux have no problems with 64-bit file-sizes which are more and more common these days!
Even the bash approach where you have to explicitly ask for POSIX-conforming behaviour is better than nothing, even if I think that it should be the default.
There are only two sane ways to deal with POSIX brain-damage: Fix POSIX, or don't use that stuff in your programs. OSes that are "mostly" POSIX-compatible are worse for portability that those who just say that they don't implement POSIX at all.
Programming can be fun again. Film at 11.
Errr, no, we need to actually eliminate these functions that are unsafe by design, and if a program uses gets(), then too bad, it needs rewritten by an actual programmer and it can't be ported until it is rewritten.
This is on the same scale as your mother asking, "If all your friends jumped off a bridge, would you jump."
Them even bringing up gets() makes me doubt their whole report. If the rest of their comments are on the same scale as this, I'd say go with the LSB everytime.
The LSB overrides and superceeds all previous standards with a single common way of doing things that actually halfway makes sense.
Ask yourself this: can you read a copy of the POSIX standards online?
No, that's why Linus couldn't implement it fully.
Phillip
If you want POSIX compatibility under Windows you are better of using Cygwin or - at the shell level - the native ports of GNU utilities to Win32. Add to the mix my Outwit tools for Windows interoperability and you are set.
Diomidis Spinellis - Code Reading: The Open Source Perspective
#include "/dev/tty"
2002, great, too bad it wasn't available in 1991.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Gcc-1.40 and a posix-question
Message-ID:
Date: 3 Jul 91 10:00:50 GMT
Hello netlanders,
Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice.
A month later, Linus posted:
As to POSIX, I'd be delighted to have it, but POSIX wants money for their papers, so that's not currently an option.
This June 1999 article is good: The Past and Future of Linux Standards
Also, this Dec 2000 interview with Linus touches on Linux and POSIX/LSB standards.
To sum it all up: POSIX is good, LSB is good, let's work together towards world peace.
Phillip