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"
Even the bash approach where you have to explicitly ask for POSIX-conforming behaviour is better than nothing, even if I think that it should be the default.
There are only two sane ways to deal with POSIX brain-damage: Fix POSIX, or don't use that stuff in your programs. OSes that are "mostly" POSIX-compatible are worse for portability that those who just say that they don't implement POSIX at all.
Programming can be fun again. Film at 11.
Errr, no, we need to actually eliminate these functions that are unsafe by design, and if a program uses gets(), then too bad, it needs rewritten by an actual programmer and it can't be ported until it is rewritten.
This is on the same scale as your mother asking, "If all your friends jumped off a bridge, would you jump."
Them even bringing up gets() makes me doubt their whole report. If the rest of their comments are on the same scale as this, I'd say go with the LSB everytime.
The LSB overrides and superceeds all previous standards with a single common way of doing things that actually halfway makes sense.
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.
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?
Both of your solutions don't work. You can't fix POSIX. It takes years to add stuff to a standard (that's why it a standard) Even if you were able to add it you end up with stuff like sql where all the big SQL database support sql 92 but none support sql 97(I might have go the dates wrong). Noone supports the latest sql so there's no point learning it since everyone supports different parts of it. One of the main reason why the LSB was formed was that adding stuff to POSIX takes to long and they wanted to define stuff that's outside of the scrope of POSIX.
The second comment it also wrong. If you have systems that are 90% POSIX compatable it much easier to port software to it than if it's 0% POSIX compatable. In the end you have a lot of #ifdef in you code or in the portable classes. The less #ifdef you have to do the easier it is. It does make it harder to debug though as you have to know the subtle differances.
Most of the time though you use a library that wrapes it all up for you like wxWindows or POSIX that makes it fairly portable. You just have to alway remember that different OS have different levels of completeness.
Because that's where they belong?
/usr/lib/prog stored all the information that prog required, then it would be simpler to cleanly uninstall, and to bundle, a working application.
/etc for system-wide configuration, and put program specific information somewhere where it is clear that it's program specific?
/usr, then yes. Note that this approach would have a program reside entierly reside in /usr/lib/prog, except for the primary binary, which would be in /usr/bin.
/etc, some in /usr/lib/prog), but that's a seperate issue.
/usr. Now, in order to update the program, or to adjust it's settings, you change one set of files, and it is automatically replicated, throught the NFS mounts. If the configureation was seprate, then a new version that required a change in configuration files would result in having to change the file on all the machines, or some ugly hack invloving lot's of symlinks in /etc. And hope that you never have to add a new program to /usr, or it's time to go around all the boxes manually again. This sort of configuration is desirable on Beowulf clusters.
Or, alternativly, why not? If it's just because your not used to it, then ponder it a bit more.
if
Why not reserve
Is there a good reason that configuration data must be all the way across the filesystem from the rest of the program? If you have a range of different machines, doing different tasks, all using one program in different manners, and NFS mount
Now, POSIX may be broken because it's inconsitant (some per-prog configuation in
One big advantage of this approach would be for a large number of systems, that NFS mount