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"
No programmer in their right mind uses the I/O POSIX functions without checking the user input. Too bad there are still very common buffer overflows, format strings and heap overflows found in (more or less major) projects.
Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing"
Obviously I'd say that POSIX is in the right; it's an older, wider standard. But as for the LSB... why do we even need it? A single totalitarian ruleset like this is against the spirit of open source; the progress we have from the competition of projects like KDE and Gnome show this. .deb or portage) we're just going to find ourselves ending up with a single system with no choice, no better than M$ Windoze.
I'm not trying to start a flamewar, but if we carry on dogmatically sticking to the LSB (and incidentally make everyone like Redhat; god only knows why RPM was chosen over
Everything else is going toward POSIX compliance, even NT4 can be made POSIX compliance so why go the other way? Just to be different?
Rus
Cheap UK and US VPS
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.
This guy has it backward. Linux is the standard for Unix. The OpenGroup should learn about the state of the world as it exists, and not fret over what is no longer. The OpenGroup has lost their prerogative. They are no longer in the game. Linux is the big dog; the rest of the also-rans are fleas along for the ride.
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.
POSIX is not Unix. POSIX is a standard which describes a set of basic functions to aid portability which any Operating System can implement. Many non-UNIX Operating Systems implement POSIX, including WindowsNT, BeOS, Amiga OS etc. POSIX is diliberatly small in scope and does not enforce policy; all it defines is the most basic parts of the API. POSIX does not tell you how to lay out your filesystem, how to implement a network layer or even how your scheduler should work.
The Open Group are probably putting this together because they are seeing problems with developers who are assuming that non-POSIX extensions from GNU and the LSB These developers write with these extensions and then run into problems on another POSIX system when these extensions do not work.
This isn't just a problem for "old school" Unix vendors not being able to compile non-POSIX Linux source, but also a problem for other non-Linux OS which are trying to stick to the standards. Linux running away and doing its own thing doesn't help anyone, free software or otherwise.
So it's better to be compliant with a single operating system than an open, published standard? It's OK to go against the standard, because your way is better and developers will still write code for your operating system?
Is that really what you're saying?
Someone inform Microsoft, they were right all along.
--
Use Vobbo for Video Blogs
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
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)
C is a dead language that hasn't moved ahead in 20 years. C++ simply makes official the extensions and common way of doing things that has grown up in the years since C 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 language like C or C++ 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 C is silent on way too many very important things that govern an actual program.
If two languages meet ISO/IEC FDIS 14882 standards this is no guarantee that they are compatible in any way shape or form. But if two languages meet the ANSI standard, 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 ANSI. It's called gcc.
Standards are standards, because they don't change fast. Get it?
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