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)
- 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.
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
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...
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.
C:\Program Files\
Ok, is explorer.exe in C:\Program Files\Microsoft\Windows\Explorer\ ? Or in C:\Windows\ ? Or in C:\Windows\System32\? Or in C:\Program Files\Explorer\? And where's iexplore.exe ? Where's the uninstaller for FooSoft Bar? C:\windows\unwise.exe ?
Now go and find those settings. Are they in C:\Documents and Settings\Windows User\Application Data\ ? Are they in C:\Program Files\Foo\Bar.ini ? In win.ini? Are they in the registry in HKLM? Or in HKCU? Or even in HKU\.DEFAULT? Or in a group policy? Or in a custom policy? Somewhere in Active Directory?
Where does iexplore put it's cache? How about MSIE 4? How about 5? How about if you run ME? in C:\Windows\Cache ? In c:\Documents and Settings\Windows User\Local Settings\Temp? Win98x doesnt even have C:\Documents and Settings!
When is %windir% C:\windows and when is it c:\winnt? Why is %windir% even an environment variables, people fuck with those!
Windows paths are a great big piling heap of.. Well, something unpleasant. And the registry doubly so. Granted, the *nix way of doing things isn't perfect, but at least it had homedirectories(!) with
SCO employee? Check out the bounty
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
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.
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
Why not?
/usr readonly? If you've got files that could change during operation on that partition, you're stuffed.
Well, how about if you want to mount
BTW, installation/uninstallation of an app is the job of the package manager, not the user. If the PM knows what files belong to what package, what real advantage is there to having everything for that app under on directory?
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