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)
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.
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)
These decisions regarding implementation and USER PREFERENCE are mandated by LSB? You're kidding right?
My journal has hot
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.
Yep, I saw this and thought that deprecating gets() is one thing the LSB shouldn't change. While there are valid points in the article, this is one I would contest. gets() is such an easily misused function that it needs to be deprecated. I think the current behavior of the linker issuing a warning when this function is used is a great thing.
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
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 is so deprecated that they haven't removed gets().
LSB is going to be more important than POSIX.
Even right now, Unix developers consider more important being Linux compatible than being POSIX compatible.
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!
It's quite interesting how the parent got modded 'interesting'
Programming can be fun again. Film at 11.
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.
Actually, glibc only uses linker warnings for a few functions. In contrast, dietlibc warns of many other functions, e.g. unportable functions like sendfile, security risks like system and {tmp,temp}nam, functions introducing bloat into your programs like all stdio stuff, and so on.
A monkey is doing the real work for me.
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.
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.
POSIX SHMOSIX! (no offense to mosix developers)
POSIX was designed back when they had to limit the length of strings because hardware was expensive. POSIX and LSB, sadly, happen to be the most nitpicking standards I've seen to date.
I intend to support the LSB, but give me innovation over a decaying standard. Do we want the Linux kernel to look like the x86 chip design?
Your P4 and Athlon can run code written for stop lights (Intel was in the stop light biz before the personal computer).
Besides with so many differences, can SCO or MS really claim Linux has copied code?
The message on the other side of this sig is false.
How the heck does this junk get marked insightful? Linux exists because people were able to run their UNIX software on Linux. Working against POSIX will only harm Linux adoption in industry, where people care about acronym compliance.
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.
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 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.