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.
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.
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.
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!
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.