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.
Perhaps we should just have a UNIX Standards BASE or USB.... oh wait..
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.
Ahem. That's GNU/GNU/Linux, GNU/Posix, GNU/LSB, and GNU/Linux GNU/Distros. And the first word should be IMHGNU/O. So there. :-P
-- rms
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.
In other news:
Acme, Inc. has announced that they won't be porting their leading product, Foocreator-4.5, to the Linux platform, CEO John Doe announced today. "The incompatibilities between Unix and Linux are minor, but significant enough that we'd have to review our entire codebase. There may not be a large enough Linux market to justify this effort." he declared today.
"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".
It seems that Posix has some updating to do.
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
It is always amazing to me that Linux is able to evolve, despite the fact that there are a million different websites that all have various linux-based information on them, and a million people all working on it in different places. Linux is almost evolving like a life form, versus a Microsoft piece of software which evolves more like a battle plan -- all wrapped up in one office under one company.
stuff |
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.
> GNU has helpfully published a version of "Hello, World!" that uses autoconf
Why make things so complicated!
Sheesh, evil *and* a jerk. -- Jade
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.
...because I only ever program in raw ANSI C89. You can't beat it for portability. There's only, like, 100 functions.
:-)
Of course, there's no hope for me writing something as simple as id or whoami, but still, I can just laugh when people bitch about standards.
Bash script for FP whores
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
Happy now?
Oh, and while I don't doubt that you know a few English majors that were good at programming, your statement would only make any sense if MOST English majors were good at programming. The thought process for reducing things to simple steps is at odds with the normal authors thought process in my experience.
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.
When most Linux systems conform to POSIX behavior on these aspects (for example by using NPTL for threads), the difference can be removed. Before then, programmers should try to make the program work in both POSIX systems and LSB systems.
It accomplishes NOTHING. First of all, the overflow can still occur if more I/O arrives on stdin between your ungetc and your gets call.
Secondly, if there was no data on stdin (e.g. closed pipe at other end) and you got unlucky during function initialization, you can overrun the dummy buffer with your strlen call. If there is no data, fgets will not alter dummy in any way, there is no guarantee that it is an ASCIZ string, and you call strlen on it. Boom! At least initialize dummy if you want consistent code behaviour.
Third, you're doing way too goddamn much work, and it's EXPENSIVE work!
How about this:
char buf[10];
if (fgets(buf, sizeof(buf), stdin) != NULL)
process_some_data(buf);
Simpler, cheaper, safer, quicker, easier to read, and not retarded!
Do daemons dream of electric sleep()?
Not so! The GNU/Linux name signifies that GNU is running on top of the Linux kernel. But your long thing seems to say that, among other things, GNOME runs on top of KDE. GNOME is actually part of GNU, and I think a better way of referring to my system would be:
(KDE/XFree86 & GNU & BSD/Linux) & (Apache/GNU & BSD/Linux). Note the parentheses and ampersands.
I hope that the LSB standards, which I think are freely downloadable, become the main standard.
POSIX and all those ISO standards, while good I guess, cost a lot of money.
This report on the conflicts seems like an attempt to protect the IP value of the POSIX standards. It wants LSB to reference the POSIX standard or other ISO standards everywhere so that people will feel they need to go buy them.
Free standards to match the freeness of Linux is the way to go.
only on slashdot would a post about how to do something right get modded as flamebait...
I don't think your greasy hamburger example is analogous. If you eat greasy hamburgers and as a result have a poor quality of life, incur horrible medical expenses, and die a miserable death, it is arguably not society's business because all of the costs are internalized. (Unless, of course, you insist on a form of socialized health care where I'm forced to subsidize your health costs and thus your poor nutrition decisions. But that is a debate for another day.)
However, if in this internet connected world somebody writes a piece of software that is vulnerable to buffer overflow exploits, there is a good chance that as a practical matter all of the costs will not be internalized. The person who wrote the buggy software may bear some of the costs, but not all of them. Where externatlities exist, society arguably has an interest in imposing some standards and reducing one's freedom to make mistakes.
Only Women Bleed (Sex, Sharia remix)
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:
POSIX doesn't define everything (other posters have pointed out that many of the differences are really extensions because of the GNU tools, which typically have more functionality than their POSIX/Unix equivalents), and having a single set of guidelines will really help to alleviate the "This works on Red Hat but not Mandrake or anything else" problem.
We'll take your example of RPM. The standard doesn't mean that everyone has to use RPM as their primary package format; they just have to be able to use RPM packages, which Debian can thanks to alien. So if you have an RPM of Commercial-Closed-Source-XYZ, it can be installed on your LSB-compliant system, and it will have a reasonable idea of where to find what it needs.
KDE and GNOME are cooperating to create common APIs so that software can be written for both at once. This is the same thing. Distributions can still do many things to set them apart from each other, like the strict package management of Debian. But having common ground for developers to target is a huge plus.
WMBC freeform/independent online radio.
is consistency. I don't really care if it's POSIX or not. I care if it's consistent.
Consistency across platforms is more important than POSIX.
In other wods: If everyone is going to conform to posix completely, fine, let's do it. If one distro or another is going to be "different" by complying, it's not worth it.
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
The LSB doesn't prevent competition, it encourages it:
/etc symlinked to three or four different places in the filesystem.
- The LSB prevents distribution lock-in by lending similarity to competing distributions. This reduces pain and training costs when a user changes distributions.
- The LSB helps new distributions by providing an open documentation of best practices. This reduces research costs and interoperability problems for a company bringing up a brand new distribution.
The LSB also makes Linux systems in general a lot cleaner. I used to use Slackware in 1995, when it wasn't uncommon to find files in
The LSB does not beat POSIX on all counts, however. Take this section, in particular:
Consider that only passing the actual command used as $0 (POSIX) allows the user's relative command to be seen literally. If the objective is to find the full pathname of the script, this behavior is annoying, since the PATH must be perused iteratively. However, at least $0 has been be initialized from given, finite data. In constrast, if an implementation follows the LSB's "may be set to an absolute pathname", what happens when the PATH contained "." (don't whine, now, it's still perfectly valid despite security concerns), and the current directory is a couple of thousand levels deep in subdirectories? Now a time consuming search for the root has to proceed, particularly since most shells can't maintain a PWD variable under these conditions. A buffer for the result can't be preallocated, since it will probably be longer than then commonly used PATHLEN or whatever it was (usually about 1024 bytes, I think about 4K in Linux, POSIX might have been shorter), so we're looking at a likely recursive function with the associated impact on the stack (although said impact is a relatively minor problem nowadays).
If all of these factors aren't handled, than the theoretically simple act of digging up a $0 could crash the script before it executes a single line. If this seems unlikely, note that this same kind of blindness used to crash some versions of Unix (specifically IRIX), due to symlink-handling code in the kernel and a buffer problem - which they wouldn't fix until it was pointed out that creating a USENET newsgroup of sufficiently long name would crash every SGI newsserver on USENET, which would then crash again during the boot fsck's.
But suppose all that's addressed, and our LSB-option using script mechanism handles the buffer overrun issues and we accept the performance penalty. Only the raw technical issues have been addressed so far.
Naturally, in searching for the "absolute path", we have to ask which one: the logical path via whatever symlinks might have occured, or the physical path - a classic problem of subjective opinion. Well, if no PWD was maintained, the first may be pretty much unobtainable, but either way, we still have to wonder if someone will complain of the shell's current logical/physical setting for "cd .." should be
adhered to. Hardly a recipe for consistancy
from the script's perspective, since it wouldn't
have yet had an opportunity to set its own preference first.
So, how could this absolute pathname "option" for $0 possibly be considered an improvement over the POSIX default? Makes me wonder if the lack of this questionable feature was what was posted as a "defect report" against the POSIX guide.
Hehe. All of this just goes to show that standards writing is a trick business. It's hard to get this kind of thing right in -all- cases.