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)
These need to addressed since POSIX is more important than LSB. The LSB should be modified.
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
Won't somebody think of the script kiddies!
- 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
My biggest problem is the fact that the different distros think that Foo needs to be in different locations. It has became better of late but it is still unacceptable that Redhat thinks that X, apache,samba,etc... need to be installed somplace different than everyone else, and everyone thinks that the origional creators are twits and NEVER uses the correct install locations.
Under BSD it seems to be better between the 2 net/free but could suffer the same fate as others start thinking of making their own flavors...
I want apache to be in the same place on every damn distro.... is it really that difficult to not screw with an install of a app?
Do not look at laser with remaining good eye.
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!
Dude, gets() is so bad, there is _no way_ to guarantee that the incoming string isn't going to totally cause a buffer overflow! _No way_! You can ioctl() with FIONREAD all you want, you still aren't guaranteed that the string you pass to gets() is actually big enough to hold the incoming text. At best you get a program crash -- at worst you get a hacker with root!
gets() is just bad, horrible, terrible design. You say something about checking the input to prevent overflows, but by the time you get the string back from gets() it's too late! The stack is already fsked. Or if it's on the heap you probably already crashed or your program is somehow otherwise corrupt...
Funny thing you mention them in the same breath, since RMS was behing the original /usr/group that gave birth to POSIX.
Given that his world view isn't Linux-centric, I guess he'd be behind POSIX even today, as compliance would make eventual port to the Hurd easier in some measure; OTOH, many of the LSB extensions are actually the officialisation of GNU extensions in glibc and other GNU tools, so they don't hurt so much these days that software get ported from GNU to proprietary Unix instead of the other way round.
All things considered, standards should go together; extensions aren't bad if they bring benefits and are easily flaggable, but simple violations are evil if they can just creep in without bringing benefits nor being easily spotted.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Could it be that more people are writing apps for the "unoffical" version because it has more seats than all of the offical Unixes put together? Is everybody just going away from "Unix" and leaving them holding their useless rubber "Unix" stamper? Oops!
I'm no thread programmer, but I think that NPTL (The Native POSIX Thread Library for Linux) may solve your problem.
/Styx
was the source of some of the headaches VMware has been giving people... (as the BSD implementation of nice(3) follows POSIX).
Code writers: pay close attention to this page if you want to avoid being laughed at by the rest of the world...
Looking through the list in the few instances where there is a real world impacting difference the change was made for reasons of sane implementation. Like the difference in kill, Linus tried it the POSIX way and people were not at all happy. Same thing with gets, it makes sense to make something that leads to so many bugs deprecated. There are some real issues there to be fair but I think Linux is about as POSIX compliant as anything. MS's NT4 POSIX subsystem sucks and is only compliant to an ancient version of POSIX. It was tacked on when the government required POSIX compliance for most contracts.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
POSIX is a dead standard that hasn't moved ahead in 20 years. The LSB simply makes official the extensions and common way of doing things that has grown up in the years since POSIX stopped evolving.
A standards document like this is not a holy book that everyone must use as a daily guide. Every aspect of a standard like this should be constantly under ruthless attack to do things better.
When I was in the Army every unit I was in had a Standard Operating Procedures (SOP) book. This document formalized the way things were being done at the time. This made it easier to train new people, but if someone came up with a better, easier, faster way of doing things and could get it accepted, guess what? That's right, they updated the book. So various units would evolve slowly overtime to the best way of getting the job done.
A document like POSIX or the LSB is actually merely a "best practices" book and should reflect the best practices of the times, not be some arbitrary thing that documents how things were done 20 years ago.
Not to mention the fact that POSIX is silent on way too many very important things that govern an actual Unix or Linux distribution.
If two Unix or Linux distributions meet POSIX this is no guarantee that they are compatible in any way shape or form. But if two distributions meet the LSB, then you are guaranteed a very high level of interoperablity between the two.
And there are easy to use tools that actually test compliance to the LSB.
RMS is "Richard Stallman", the man behind the GNU project. Undoubtably a very talented and gifted individual, he has unfortunately been perceived as something of a "crank" amongst many people involved in the open source world. He is notorious for his insistence that the Linux OS should be referred to as "GNU/Linux", giving proper credit to the GNU software required to do anything useful. However, many people see this as whining - after all, following that precedent would mean that the OS should be called
GNU/X/Apache/GNOME/KDE/BSD/Linux
etc. in order to "properly credit" all those parties involved.
He also has a very big beard. See his webpage for more info on the man.
It was at least a year after we ported to Linux that I noticed a bug related to the nice() system call. Even more strange, it didn't happen on one of the newer Red Hat Linux test systems. This document could have saved us so much time.
Everything is going toward POSIX compliance?
XP and Win Server 2003 aren't compliant.The POSIX subsytem was removed in XP and everything after.
POSIX does some dumb things. Ever hear of the gets() function?
Now correct me if I'm wrong, but I'm pretty sure gets() was defined
in the ANSI C standard libraries, and these were subsequently adopted by POSIX?
Not to mention scanf()/sscanf()..
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"
You seem to forget that posix is just a description of what functions a system must implement(If it want to support posix) and how theese functions must behave. It is not a system description.
Posix is(shuld be) a subset of LSB meaning that a LSB system should support posix, not the other way around.
Posix have been implemented on hurd,*Nix,linux qnx 6,amiga os(Almost, but contain some problems with the filesystem functions, and fork) and I also think that beos got a posix layer. (Oh and windows got posix support too, you just can't use it together with other windows functions, so that support is rather pointless)
Martin
What does POSIX have to do with the standard C library? We live in a world where C is no longer the only language used. Why can't the spec be split into "system stuff" and independent "cross-platform (your favorite language) requirements"?
It's 10 PM. Do you know if you're un-American?
POSIX is a dead standard that hasn't moved ahead in 20 years.
Except that, well, it's not. There's a new POSIX (ISO/IEC 9945:2002) which is now the same as the Single Unix Specification, V3. The article is about the differences between LSB and this version of the standard.
I'll admit it's a bit tedious, but it helps prevent gets overflows.
As far as I can see the policy seems to be to comply with the POSIX standard as much as possible, except in cases where it is idiotic, in which case it seems reasonable to implement something better, as in the case of threading:
The LSB simply makes official the extensions and common way of doing things that has grown up in the years since POSIX stopped evolving.
Except that many of these extensions and ways of doing things are only common on Linux systems. A program that adheres to POSIX isn't guaranteed portable to Linux, and a LSB compliant program isn't guaranteed to be portable to Solaris, BSD, AIX, HPUX, etc.
A Government Is a Body of People, Usually Notably Ungoverned