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!
I think the Mutual Standards Base should be created from the best of both.
I write code.
- 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
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
We had better fix this. I'll go ask SCO what to do.
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".
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
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...
just wondering . . . it seems i'm always behind on /. jargon.
"The nice thing about standards is that you have so many to choose from" -- Andrew S. Tanenbaum
It's quite interesting how the parent got modded 'interesting'
Damn, Slashdot moderation is screwed up. Joke post gets -1, post by clueless person who doesn't get the joke gets 5. Next time I go to the zoo I'm going to check the monkey house for chimpanzees with mod access
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
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.
This is wrong.
Ignore him.
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
I find the misues of such a word by a programmer to be quite funny, since programmers can quite often be quite excellent with the written language.
In fact, I know a few English majors that turned out to be exceptional programmers, since programming is simply a combination of imagination and learning the rules, complex or otherwise, of a new language. This isn't much of a leap from learning the rules of the English language.
Yeah, go ahead and mod me off-topic, ignore the thread I am responding to why don't you...
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
Linux should be striving to be POSIX compatible. Extensions are fine (and frequently even necessary) to address problems/omissions of the standard, but they should be separate from the standard implementation.
I fully endorse the deprecation of gets (it's a truly brain-dead function), but only if it's marked as deprecated and not removed from the system. There are large numbers of (insecure) heavily used programs that use gets() and that are not going to be changed in the near future simple because of time/budget constraints.
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()..
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
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.
(psst... | is or, & is and )
I've never heard of POSIX. Is it better than Linux?
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.
Computer instructions include arithmetic operations such as ADD or SUB.
Computer instructions include logical operations such as AND or OR.
Logical AND is maybe a bit redundant, (illogical AND?), but avoids confusion as a synonym for ADD as in "2 and 2 are 4".
& is a binary operator which produces the logical AND of its two evaluated parameters.
&& is a flow control operator which evaluates its right-hand parameter only if required to determine the truth value. This is NOT what was referred to.
ASM goes something like:
LOAD flags
AND FLAG_CONSTANT
JZ around_blah
C could be as simple as:
if ( flags & FLAG_CONSTANT ) { blah ; }
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()?
How do you pick the best location? Should the entire install go under /home/apache? /opt/apache? Or should each part be put where it goes, with config in /etc/apache, data in /var/www, libs in /usr/lib and executables in /usr/bin? Or should it be called 'httpd' as they do in redhat?
/home/app or /opt/app so that they can add or remove or upgrade whole chunks by themselves. Others want everything put in the FSSSTD locations so that the distro can manage everything. There is no right answer to this question, except to pick a theme and stick with it within a distro. Most do that just fine.
It's not simply a matter of picking one and sticking to it because people have different needs. Some people want their apps under
So learn the rules of the distro you like and get over yourself, or build your own Linux From Scratch.
In fact, RMS himself coined the term "POSIX" (before that, it was called "IEEEIX" *sigh*).
A monkey is doing the real work for me.
Do you have any references? I could never find a nice history of POSIX.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
You're just saying that because LSB has "Linux" in the name. You'd be crying a river if it were called something like the "BSD Standards Base" or the "Winders Standards Base".
Eat a dick for lunch, fucko.
...now here's something that linux vendors *should* be worrying about instead of SCO v IBM.
I love this idea. It also nicely circumvents the problems many Unixy programs get when you have spaces in filenames (quite a few windowsy programs as well).
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
> COMMANDMENTS FROM GOD",
To paraphrase Andrew Tannenbaum, an Operating System is a program which hides the details about the hardware and presents a nice interface to the programmer. [well, that's one aspect.. others including scheduling, etc., but aren't relevant to this discussion]
Now, how is that interface presented? Function calls would be handy. What are function calls? They are a standard way of passing parameters to another piece of code, executing that code, and return control back to the caller.
One way of doing this is to push the return address on the stack, push the parameters on the stack, jump to the code to execute, execute it, pop the parameters off the stack, pop the return address off the stack, and jump to it. (Note that it doesn't happen exactly like this on any architecture that I'm aware of.. but that's beside the point).
Notice that this discussion hasn't included one character of C code yet -- I'm describing assembler-level operations.
Great! Now we have a way to call functions. But it would be useful to tell programmers how to call them. After all, this is a really annoying description, particularly when calling conventions vary from OS to OS!
Hmm, seems simpler to me, and contains all of the requisite information. Now, just because the specification is written in C doesn't mean the routine is only callable in C; it's just a specification for a hunk of assembler, for God's sake!
It's not hard to translate the specification for use by another language (I know how to do it in VB for God's sake, and I'm sure it can be done in almost any other crap-language-du-jour... well, except Java, because Java doesn't allow direct interfacing with the OS anyhow).
Note for the pedantic: Yes, I know strcpy() doesn't return void. I was trying to simplify my example by making it procedural.
Note for the uber pedantic: I included cdecl to make the comparison fair, and because it is actually needed under some of the bastard systems out there with multiple calling conventions... examples include MS-DOS, WIN32, and WCE.
Note for the people who are missing the point: Yes, I know strcpy() isn't a real OS call, it's just a handy function for examples, because it's so darned simple.
Do daemons dream of electric sleep()?
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.
a) Linux Standards Base?
-or-
b) Posix
(oops, did I forget the mares?)
Yikes I didn't know his middle name was Benedict.
In any case we how can get the POSIX standard. We have the info: the LSB and how POSIX diff's from it.
only on slashdot would a post about how to do something right get modded as flamebait...
GNU Hello is pure bloat; no wonder it can't follow ANSI C standards. It can take five options, and it has a feature to output your mail spool. Why?!
Bash script for FP whores
what the heck do we pay you for???? ...
... eh heh ...
er i mean
*eeep*
modded down for minty freshness
The stable distribution is well over a year out of date. If that isn't death, I don't know what is!
I think the higher-end MKS Toolkit packages also provide portability code, ala Cygwin. It's pricey, but if a PHB needs a corporation to provide support contracts it's a viable solution.
I do not fail; I succeed at finding out what does not work.
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?
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:
Richard Stallman is the person who first suggested the term Posix.
Of course, bloat is another important quality. You might note that your program therefore doesn't qualify as a part of the GNU system - it doesn't even use gettext! Even their version of /bin/true uses gettext, and supports several command line arguments, but only depending on the POSIXLY_CORRECT env variable (and hence it is much more code than your hello version, and thus obviously better).
GNU's Not Unix, indeed.
Programming can be fun again. Film at 11.
It is my understanding that POSIX is interesting, not for technical reasons, but for political ones. Back when I used to work as a sysadmin for the National Weather Service, it was a common criteria for procuring new systems that the new systems were POSIX compliant. If they weren't compliant, the government wasn't allowed to spend money on them. If we want to be able to sell Linux to the government, we might still need to be POSIX compliant.
"Violence is the last refuge of the incompetent" --Salvor Hardin
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.
Please report to the nearest organ bank for humane termination.
No, it's not ANSI/ISO-C (btb, if you use -posix, it doesn't work). But it's the linker that throws the warning, not pre-parser. So it isn't implemented that way anyhow.
That being said, it should be let back in by default (but with lots of red tape around it)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Additional trivia: the name "POSIX" itself was suggested by RMS.
Unfortunately, in the years since then, his idea of "portable" seems to have become "don't care about other systems, only write your code for GNU/<kernel>, because then users can always just install the GNU system (and will have to if they want your program)."
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
No thanks.
i hope you are aiming for a funny moderation... because if not, you have missed the point of this program!
often, the best way to learn something is by example; the GNU auto* tools, internationalisation, localisation and overall package maintenence hierarchy/structure is all documented in this package extremely well. in fact, its only purpose is to serve as a a guidance for people who dont want to reinvent the wheel with these things, and just want to get stuck into writing their program.
there are ANSI standards, and there are POSIX standards, they are different. is there a standard for the exact path and command line arguments to a c compiler or linker? not that i am aware of...
the C code itself may be standardised, but often the build environment is not. that is what the GNU tools help you sort out. add to that, the immense need to translate programs to non-english speaking countires and you find yourself needing soemthing like the GNU precedures for that as well (unless you'd care to write your own, which distracts you from your coding...)
damn, i just fed a troll, didnt i? :-/
The problem with O_LARGEFILE is that if an application assumes that flags have not been set by the system (which is entirely valid according to POSIX) and thus set the flags for the files to the flags they want with the assumption that this only modifies the behavior related to those flags that were explicitly set...inadvertently clearing it.
It's a big mistake that O_LARGEFILE even needs to exist.
I would love to read all this history in full!
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Haven't!... :-(
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I actually like it. You see, with Linux, there are just processes (this may have changed recently, but go with me here). You can have processes that share nothing (like most processes) or processes that share everything (like threads). However, it's more general than that. Processes can share memory, file descriptors, certain regions of memory -- ANYTHING. So, you basically have one concept of processes, and another concept of sharing, and you can share or not share anything you like. Shared nothings are just called "processes" while shared everythings are called "threads", but really there's no technical distinction between the two.
Engineering and the Ultimate
is this because only /. has modding?
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
So, my PHB asks me about POSIX and LSB, to which I respond that it's fallout from the SCO FUD, IMHO. Besides, we use AIX from IBM, so there's no worries about LSB, but there is, again, the SCO FUD. But IANAL, I've just got an A+ and a CCNA, so I suggest the PHB take it to the COO, who talks to the CEO, who goes to our law firm RSTL'n'E.
Hmm...no, still a bit too readable.
One only needs two tools in life: WD-40 to make things go, and duck tape to make them stop. ~G.M. Weilacher
For the love of god you're an even bigger moron than the parent. No, wait. The parent wasn't being an idiot, it was a joke. Jackass.
You fail it, you suck at life, etc.
And you should be using read() anyway.
gets() should still be thrown away. It's like saying "please make my program crash and have security problems."
From the Linux Programmer's Manual man page:
Nah, you are mistaken, it does not matter if more data arrives, it will happily be placed at the back of the buffer where it should be. That solution is guaranteed not to cause a buffer overrun. It is unfortunately not guaranteed to work as expected in general anyway, POSIX only specifies that you can ungetc 1 character of input. Therefore the only completely safe use of gets is to set a char to '\n'.
:)
char c;
c = '\n';
if(untegc(&c, stdin) != EOF)
{
c = 0;
gets(&c);
}
will set c to '\n' and cannot in any way overrun any buffers. Wonderful isnt it? And it is all POSIX too
Oh, and get a sense of humor, calling actually funny people retarded is not good social style.
Fabulous. :)
No. Languages are turing complete, you can solve any problem in any turing complete language, given enough time.
In other words, you can solve the same problems in C that you can in C++.
Standards are not turning complete. Standards seek to enumerate the best practices of any given time.
Nice troll, but way off the mark.
Who has a better implementation of pthreads than Linux or AIX? Sun's is their own thread interface that isn't 100% POSIX. HP-UX has historically used DCE threads (aka POSIX draft thread specs.) Win32 is completely incompatible.
So, pray tell, which is this grail of pthreads implementations that is perfect?
I do not fail; I succeed at finding out what does not work.
Sorry, but if you're using system() to run subprograms, you need to seriously look at the exec() and fork() functions that let you provide the control you want. system() is for quick hacks, not production-grade or threaded code.
If you think using system/fork-exec to spawn a process is threading, take another look at the POSIX and DCE thread APIs. In neither case is system() or fork() the way that you spawn a thread, but the means of spawning a seperate process.
I do not fail; I succeed at finding out what does not work.
$ figures are a poor way to determine the market %'s esp with a non-trivial chunk of the Windows market actually being Linux/BSD and huge number of retrofits on used equipment being Linux. In terms of the server market, I would use the Internet's % as a better judge of what is really running.
Rationale
1) A windows-based shop will run MS on their web server unless they are experimenting with OSS.
2) A unix-based shop will run the unix that is available in their shop. A solaris shop will continue to run Solaris for a web server. This is all true unless they are experimenting with OSS 3) A (Linux|BSD)-based shop will almost certainly run $1. period. end of story. If they are already running OSS, they will not be running a closed source OS. So what are the %'s as outlined by netcraft or other sites? I think Linux's % is far greater than 20%.
I prefer the "u" in honour as it seems to be missing these days.
Not to mention scanf()/sscanf()
These functions (especially sscanf()) aren't anywhere near as bad as gets(). The main problem with scanf() (apart from idiot users not knowing how to use it) is that if it runs into something it can't digest, it stops processing, leaving whatever's in stdin still there. sscanf() is much better, because it uses a user-supplied string that you presumably got with fgets().
Just because you can do scanf("%s", buffer); doesn't mean it's a bad function. What about:
char buffer[100 + 1] = "";
scanf("%100[^\n]%*[^\n]", buffer);
if (!feof(stdin) && !ferror(stdin)) getchar();
Optimize the initialization of buffer if you don't want to waste time setting all 101 locations to zero. But scanf() does have its uses, whereas gets() doesn't.
char buffer[100 + 1] = "";
So basically you allocated this nice 101 char buffer on the stack and then overwrote your pointer with a pointer to the constant "".
char x[5]; /* x, of type char[], points to 5 chars on the stack */
/* oops. now x points to "hello" which is in a string table somewhere */
x = "hello";
The rest of your example seems OK.
Hands in my pocket
$ echo "puts(\"Hello, world\");" > main.c
$ gcc -o test main.c
main.c:1: parse error before string constant
main.c:1: warning: data definition has no type or storage class
No, char buffer[100 + 1] = "" is equivalent to char buffer[100 + 1] = { '\0' }, which initializes the first element of the array and leaves the contents of the other 100 elements unspecified.
as many readers had noted, POSIX is avaible here, unfortunately, to download it, you shoud accept a licence that states "However, you are NOT permitted to amend, copy, reprint, offer for sale, or otherwise re-use material from these documents without explicit permission from The Open Group/IEEE." (emphasis added by me)
;)
i wonder if "writing an opereting system" to be compliant to this documentation is to "reuse material" and in violation of the licence...
beware what you download and read if you are a kernel developer
char x[5];
x = "hello";
That's not legal. An array is not a modifiable lvalue, and thus can't be assigned to. My example filled buffer up with zeroes. Repeat: an array is not a pointer. an array is not a pointer. an array is not a pointer. thank you.
The reply to you was wrong, too, but not as wrong:
char buffer[100 + 1] = "" is equivalent to char buffer[100 + 1] = { '\0' }, which initializes the first element of the array and leaves the contents of the other 100 elements unspecified.
That's not quite true. The first part's fine, the second is not. It actually initializes the entire array to zero:
C99 6.7.8p21: If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.
And if you don't know about initialization of objects with static storage duration:
C99 6.7.8p10: If an object that has static storage duration is not initialized explicitly, then:
if it has pointer type, it is initialized to a null pointer;
if it has arithmetic type, it is initialized to (positive or unsigned) zero;
if it is an aggregate, every member is initialized (recursively) according to these rules;
if it is a union, the first named member is initialized (recursively) according to these rules.
/* You always assume there will be room for one int here because it's nonsensical to say you can change where x points. */ /* The same applies here, although lots of people get this wrong because of the relationship between pointers and arrays. */
To complete:
char buffer[100 + 1] = "";
That's an aggregate being initialized with a string literal. We all agree that the first element is set to the null character (which has value zero). But since there are fewer characters in the string literal than there are elements in the array, the remaining elements are also set to zero, because they are arithmetic types, and by 6.7.8p10 they are set to zero.
Just remember that arrays and pointers are distinct types. When you make an array, no matter what, it will always have as much storage as you specified at its declaration. You can't change the size of an array.
Don't get that confused with a pointer + malloc()/realloc(). A pointer can point to a chunk of memory that might be resizable. Or a pointer can be pointed somewhere else (even to an array, or more commonly, an array's first element). An array isn't a pointer, so it can't be pointed anywhere else.
int x;
int x[5];
In most expressions, an array name does evaluate to a pointer to its first element. But it's not a pointer! This is, in my opinion, one of the most difficult aspects of C to wrap your head around.
Posix have been implemented on hurd,*Nix,linux qnx 6,amiga os(Almost, but contain some problems with the filesystem functions, and fork)
Yeah, but nobody uses hurd.
That's not how char[] types work. You're confusing pointers and arrays, which are not equivilent (despite hype to the contrary; RTFAQ). It's a common mistake, but can lead to problems.
If you try the code you gave, you'll see that it doesn't actually compile; you can't assign to arrays. But the char buffer[100 + 1] = ""; does. That's because it's not an assignment, but an initializer. It sets the initial contents of the buffer that's allocated on the stack; it doesn't move the buffer.
Don't believe me? Make some stack guards! Try this on an x86 Unix (it will probably work on other boxes). It's not legal C, but it should illustrate the point.
Compile this and run it. The exact output will, of course, depend on your box. gcc, at least on my architecture (x86/FreeBSD), will generally allocate variables in the order they're declared, if you don't use -O. So you should have the lowguard and highguard immediately around the spot on the stack where the buffer is allocated. Check the first line of output to make sure. The three numbers should be either in order (either increasing or decreasing), and each one four bytes from its neighbor. The string table is probably far-removed from the items on the stack.
Now, let's examine the consequences.
Lines 14-16: Note that buf as an int is 0x78757571, which is "quux" in hex. (Remember, this example is for x86 only, although the point it illustrates is applicable to any ANSI C system.) Now, if we read the words directly above and below lowguard, one of those will be buf. This indicates that the string "quux" is allocated on the stack, alongside lowguard.
Line 17: We didn't compile with -fwritable-strings, so if you're using gcc, this would generate a runtime error (writing to a read-only segment) if buf pointed at a constant in the string segment.
Line 20: By overflowing the array, we changed one of the guards. Were buf pointing into the string table, then we wouldn't have changed the contents of the stack. (Note the output of line 12: the string table is far away from the stack.)
This should make it clear that what the AC wrote was an initialized array, not buggy code.
I double your bet your program won't run in all GNU-possible platforms.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Thanks, I didn't realize you couldn't partially initialize an array (I don't have copies of the Standards, though I should). I think I misremembered something about incompletely initializing a struct. Do you happen to know if that also goes for C++ and C89?
Yes, it's true for both C89 and C++98.
Relevant sections are 6.5.7 for C90 (I don't have C89, but it's the same except for paragraph numbering, I think it's 3.something, probably 3.5.7 in C89), and 8.5 and 8.5.1 in C++98.
This applies to both arrays and structs.
It is possibal to run some UNIX version with / mounted read only. However when you do that you break anything that needs to write to /. (It is difficult if not impossibal to put /etc on something other than /) If you really care about secruity you might care that / is read only for an extra level of protection.
There are even more reasons to run /usr read only. NFS sharing everything in there is common, and do you really want a program you told at to start for you to run on every machine on the network? What a waste. For that matter (Assuming you set things up so at didn't function that way) do you really want every machine on the network to have access to the information of what another machine will run?
As someone else pointed out, /var is the perfect place for this. A partition defined as a place for things to change often, and unique for each machine. (You can nfs mount email and news which are in /var, but most of the files in /var a specificly different for each machine)
How about if you're not using a package manager? There are plenty of programs out there that are still only available as binaries or source code, not as packages. RPM isn't the answer to everything. I realise that you can build your own packages, but sometimes you don't want to. I do agree, however, that files that need to be writable probably shouldn't be on /usr, though you then have /usr/local/etc to be concerned about. The /var partition was created for this kind of thing. I'm not sure why this doesn't go in /var/cron myself.
An interesting development is the long term plans of ReiserFS. They have a concept of multiple filesystems being mounted at the one point. So, for example, you first mount the system /etc read-write, then you mount a NFS filesystem to /etc read-only for central configs, then you mount another local filesystem to /etc read-write as a user logs in, which contains that user's own configuration files. All programs would then know that configs go in /etc, and no more ~/.everything type directories. In fact, this would allow for separation of configuration from home directories, so that you could have your home directory mounted at whichever workstation you sit down at, but have different configurations depending on what workstation you are on. The filesystem would handle mounting any number of filesystems to /etc, and transparently handle the permissions on the different filesystems mounted at that point.
I haven't made it through much of the documentation on the website yet, but it's a very interesting read.
It would be PSB, Posix Standard Base, not as humourous but a lot more functional.
/sysfs/posix/* for the documented features to allow you to set stuff like "gets(): yes/warn/signal" on the fly. If you did this per-process you could have your LSB and POSIX too. (-:
The system calls in particular seem to be preponderantly a matter of documentation. AFAIK, upwardly compatible extensions aren't an issue at all, eliminating another dozen or so issues. The remainder seem to be trivial enough (e.g. returning EISDIR vs EPERM when rm is aimed at a directory) that they could easily be a kernel config (or even runtime) option.
It would be relatively trivial to add
The utilities? Well, there's always the POSIXLY_CORRECT and _POSIX2_VERSION envars. The utilities can be knocked over one at a time based on that, and the stuff in glibc like leading zeros can make decisions based on it (I would cache detection of the envars once on process startup lest this become slow).
What I want to know is: does this Open Group document represent an unofficial/tactful offer to POSIX-certify a version of Linux, presuming compliance?
Got time? Spend some of it coding or testing
Posix is(shuld be) a subset of LSB...
Unfortunately that means LSB can't deprecate anything in POSIX, and POSIX is probably not willing to deprecate anything at all, resulting in decades of cruft.
Put the files in /etc and symlink them into /usr/lib/cron to keep both parties happy (and let me continue to run with /usr mounted readonly). A slightly less bizarre place to put them than cron would be /usr/lib/at if that existed, however I've become accustomed to finding all of my global config files under /etc.
I do agree that some of POSIX exists for hysterical reasons only, but if it gets people off UnixWare - which is not UnixV3 compliant, and neither is OpenServer - I'm quite happy to have (configurable) breakage added to Linux.
Got time? Spend some of it coding or testing
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?
The LSB group can't choose those things, because LSB only documents the existing behavior of Linux/glibc. The decisions are actually made by Linus and Ulrich Drepper, and they usually have good reasons when they deviate from POSIX.
IRL, there seem to be ablout 3 or 4 common ways of arranging files and/or registry entries. Let's take the example of an application which could be considered a utility, something vaguely like MS-Draw or their equation editor.
That's roughly six and a half changes, to say nothing of the odd application which ignore the existing mess or (MS-Publisher comes to mind) was slow to keep up with it. If Microsoft had had a standard like POSIX or LSB to follow, this wouldn't have happened, and those vendors who broke the guidelines could very reasonably and clearly be reprimanded for their intransignence. However, they've dug their own cesspit, now they have to wallow in it.
Got time? Spend some of it coding or testing
I guess I was rightfully smacked down for that. Thanks for the clarification, all.
Hands in my pocket
There are some very good reasons for doing stuff differently to POSIX, but most of them relate to simple issues like gets() which could be addressed by a compatibility library or the location of "at" files which can be mostly cured with a symlink.
Some of the issues are annoying to cure even on POSIX systems because different versions of POSIX sometimes make incompatible recommentations (the case raised by the GNU people was "sort +2" which sorts based on the second field in earlier POSICES and sorts a file called "+2" in later ones. The vast majority of the FSF's GNU tools snap very much into the POSIX line if you run them with POSIXLY_CORRECT=yes.
Got time? Spend some of it coding or testing
Damn fine idea.
Mandrake have noticed how cluttered ~/ gets and now default all (well, many) of their apps to saving stuff in ~/Documents/ instead. It wouldn't be a great conceptual leap from there to add ~/etc/ or ~/rc/ config files to that (only they'd probably want to use something more user-intuitive like ~/Configuration/) but it would take forever to get the several thousand individual upstream application authors to make such a conversion, and they'd have to get Debian, SuSE et al to agree that it was a good idea.
And hey, it'd break POSIX compliance even further, wouldn't it?
Got time? Spend some of it coding or testing
How... readable.
Got time? Spend some of it coding or testing
...I'd prefer /local/bin, /local/sbin, /local/etc, /local/share "and so on and so forth". Much easier to cope with than nested mounts, particularly if one of them (e.g. /usr) might be NFS and in theory less reliable than local storage.
Got time? Spend some of it coding or testing
Won't agree 100% but I do like their use of config directories (/etc/pp/ip-{up,down}.d/ for example).
Got time? Spend some of it coding or testing
Signed: Trey Gates
* so called because they'll be different tomorrow
Got time? Spend some of it coding or testing
However, there are several (at least 8 plus 3 MIA) Forth operating systems afoot. Including one which is implemented as a Linux kernel thread.
Got time? Spend some of it coding or testing
He'd be +1 Informative if I did
Using the web as a source of statistics for overall market share is a poor measure. Many sites outsource their web site hosting, and this particular market is an unusually strong one for open source software. It also tells you nothing about what is in the server room, or the desktop.
More than 50% of my desktops are Suns, about 6% are Linux, the rest are Windows. Our web site is outsourced and runs on Windows due to its use of some specific server software. At my last employer the desktops for our division were mostly Macintosh, with some Windows and Unix. The external web site was outsourced and on Windows. An important internal site ran on Linux. Our department web server ran on HP/UX. The corporatation was overwhelmingly Windows, and the corporate site ran on company hardware on Solaris on Ultrasparc servers. My brother's company is planning a web site. His company is 2/3 Macintosh, 1/3 windows, and the web site will almost certainly run on either Linux or a Sun.
I think that this is a fairly common pattern. You can't reliably tell anything about what is in the server room or desktop by its web site.
Most servers today are bought with the OS they will use. This is particularly true now that most big vendors sell computers with Linux so there is not a strong reason to change. (I could see a small exception to this for *BSD since so few vendors sell *BSD boxes preconfigured.) I think that its pretty likely that the new sales figures are probably a much closer approximation of the market share than web server statistics.
I also think you are overlooking the fact that some systems migrate from Linux to Windows. Don't kid yourself, there are people that try Linux and find that its not for them. There are also people that buy a box for a specific purpose and then recycle it later. I just bought a Very well equipped preconfigured Linux box from HP for my company, but it will live as a Linux box for only about 60-90 days. After that it will become a Windows 2000 box. Why? I bought it as a compute server for a short term project that needs the power. After that it will go to a lucky software developer. There is no doubt that particular box will be counted as a Linux sale, but that is only part of the story. Is this sort of thing a big influence on the numbers? Probably not. But then Linux is not a huge percentage of the market either.
Even if the market share of Linux was huge, it is an irrelevant question. If Linux doesn't conform to existing standards where they exist, and which many other company's products adhere to, it is no better than Microsoft and its "standards."
Got time? Spend some of it coding or testing
Well put.
CAn'T CompreHend SARcaSm?
I take a hard view on issues like this. If the standard body can't get its act together to deprecate a function this misbegotten, I have a hard time listening to anyone argue that compliance with POSIX for the sake of compliance is a good thing.
A standard codifies practice, and that is the primary work output of a standards body. But the moral authority of the standard does not rest on the fact that it has been endorsed as a standard: the practice it codifies must ultimately provide the moral foundation for its acceptance.
We all know that gets() should be taken out back by the toolshed and summarily executed. We all know we can't do this, because gets() retains a purely historical legitimacy.
This is why we invent fancy terms such as 'deprecated', where we admit that we've learned from our mistakes. Back in 1950, the use of CFCs didn't seem like suck a bad idea.
Once we learned the true effects of CFC on the ozone layer, refusing to deprecate CFC would have called into question the moral authority of the entire chemicals industry.
gets() pollutes the programming environment every bit as much as CFC destroys the ozone layer. I feel it sabotages the moral authority of the entire programming profession.
Someone commented that POSIX is in fact a living standard. That would seem to imply that the most recent POSIX standard has failed, once again, to deprecate gets(). To my eye, this is far more damning than if POSIX had remained unchanged for the last twenty years.
If the people involved in the POSIX standard care about standards and standards compliance, they should care enough to take the minimum necessary measures to sustain their moral authority, or they should be prepared to sit back as the world rallies around alternative codifications of standard practice that does live up to its moral obligations.
Ultimately, standards have to be earned.
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.
Unless, Linux is becoming the "Standard" Unix anyway, without OpenGroup's "permission" and they're trying to hold on for dear life. After all, there is still capitalism at work...the "person" with the most seats sets the standard. Linux is rapidly approaching that point where more people write specificly for Linux than specifically for any of the "offical" unices!
For all those who pointed out that standards are good. There will be a standard Linux! Everyone else will just have to follow along! The market is slowly choosing...If the OpenGroup is this scared it must be true!
The book "Unix Network Programming" by W. Richard Stevens says so.
A monkey is doing the real work for me.
I hoped for a reason, not an authority.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin