Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software Linux

LSB & Posix Conflicts 354

Posted by Hemos from the understand-it-better dept.
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. "
This discussion has been archived. No new comments can be posted.

LSB & Posix Conflicts More

LSB & Posix Conflicts

Comments Filter:

  • POSIX is required! (Score:3, Insightful)

    by Anonymous Coward on Monday July 28, 2003 @08:02AM (#6549647)
    These need to addressed since POSIX is more important than LSB. The LSB should be modified.

    • Oh yeah? POSIX can be DUMB! (Score:4, Informative)

      by cculianu ( 183926 ) on Monday July 28, 2003 @08:21AM (#6549726) Homepage
      106 2.1.4 gets 107 The LSB has deprecated the gets() function, whereas it is a first 108 class function in ISO/IEC 9945 and ISO/IEC 9899.
      How about the gets() function??! This is a dumb function. A first class function!! It is the stupidest function ever and GUARANTEES buffer overflow errors!!!

      • Re:Oh yeah? POSIX can be DUMB! (Score:4, Informative)

        by Anonymous Coward on Monday July 28, 2003 @08:34AM (#6549781)
        http://www.opengroup.org/onlinepubs/007904975/toc. htm :

        "Since the user cannot specify the length of the buffer passed to gets(), use of this function is discouraged. The length of the string read is unlimited. It is possible to overflow this buffer in such a way as to cause applications to fail, or possible system security violations."

      • Re:Oh yeah? POSIX can be DUMB! (Score:5, Insightful)

        by __past__ ( 542467 ) on Monday July 28, 2003 @08:35AM (#6549786)
        Doesn't matter a bit. If anything, issue a warning if someone uses a potentially dangerous function (like FreeBSD does for stuff like mktemp, the linker will print "Warning: Potentially unsafe use of mktemp, consider using mkstemp instead" or some such), but don't break apps that adhere to the standard. It has "portable" in its name for a reason.

        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.

        • Re:Oh yeah? POSIX can be DUMB! (Score:5, Informative)

          by cculianu ( 183926 ) on Monday July 28, 2003 @08:38AM (#6549798) Homepage
          Well, if I am not mistaken in the current Gcc/Glibc combo you can turn on dumb things like gets() and mktemp() anyway.. but their being off by default makes most programs safer and a minority of programs require special platform-specific build flags...

        • Re:Oh yeah? POSIX can be DUMB! (Score:5, Insightful)

          by Anonymous Coward on Monday July 28, 2003 @08:46AM (#6549839)
          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.

        • Re:Oh yeah? POSIX can be DUMB! (Score:4, Insightful)

          by natmsincome.com ( 528791 ) <adinobro@gmail.com> on Monday July 28, 2003 @09:43AM (#6550190) Homepage
          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.
          • 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).

            Actuatlly it is SQL 99.

            The real problem is that it takes years for things to be added to standards, and years more for those standards to be implimented in most settings. So although PostgreSQL is nearly ANSI SQL 99 complient (core requirements), it is still being worked

    • Re:POSIX is required! (Score:5, Insightful)

      by pmsyyz ( 23514 ) on Monday July 28, 2003 @08:48AM (#6549850) Homepage Journal
      Ask yourself this: can you read a copy of the POSIX standards online?

      No, that's why Linus couldn't implement it fully.

      • Re:POSIX is required! (Score:5, Interesting)

        by __past__ ( 542467 ) on Monday July 28, 2003 @09:02AM (#6549941)
        San Francisco, CA - January 30 2002- The Open Group announced today completion of the joint revision to POSIX® and the Single UNIX® Specification. The new standard is now available at http://www.UNIX-systems.org/version3/ [unix-systems.org] in keeping with The Open Group's policy of open and free access to its standards.
        As far as I can see, all that is required is a free registration. Am I missing something?

        • Re:POSIX is required! (Score:5, Informative)

          by pmsyyz ( 23514 ) on Monday July 28, 2003 @10:08AM (#6550362) Homepage Journal

          2002, great, too bad it wasn't available in 1991.

          From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
          Newsgroups: comp.os.minix
          Subject: Gcc-1.40 and a posix-question
          Message-ID:
          Date: 3 Jul 91 10:00:50 GMT
          Hello netlanders,

          Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice.

          A month later, Linus posted:

          As to POSIX, I'd be delighted to have it, but POSIX wants money for their papers, so that's not currently an option.

          This June 1999 article is good: The Past and Future of Linux Standards [linuxjournal.com]

          Also, this Dec 2000 interview with Linus [linux-mag.com] touches on Linux and POSIX/LSB standards.

          To sum it all up: POSIX is good, LSB is good, let's work together towards world peace.

    • 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

  • UNIX standards base (Score:2, Funny)

    by Anonymous Coward
    Perhaps we should just have a UNIX Standards BASE or USB.... oh wait..

  • POSIX LSB (Score:5, Insightful)

    by Gorny ( 622040 ) on Monday July 28, 2003 @08:05AM (#6549664) Homepage Journal
    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).

    btw. check the following for more information on POSIX
    http://www.posix.com/
    http://standards.iee e.org/regauth/posix/

    • Re:POSIX LSB (Score:2, Funny)

      by Anonymous Coward
      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

    • Re:POSIX LSB (Score:5, Informative)

      by leandrod ( 17766 ) <l@dut r a s .org> on Monday July 28, 2003 @08:38AM (#6549805) Homepage Journal
      >
      it's better for GNU/Linux (never know if rms is watching ;) to comply to the older POSIX

      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.

    • Re:POSIX LSB (Score:4, Informative)

      by Anonymous Coward on Monday July 28, 2003 @08:58AM (#6549913)
      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.

      • Re:POSIX LSB (Score:5, Informative)

        by TheSunborn ( 68004 ) <mtilsted@gmail. c o m> on Monday July 28, 2003 @09:26AM (#6550056)
        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

      • Re:POSIX LSB (Score:5, Informative)

        by Alan Shutko ( 5101 ) on Monday July 28, 2003 @09:42AM (#6550186) Homepage
        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.

      • Re:POSIX LSB (Score:4, Informative)

        by Arandir ( 19206 ) on Monday July 28, 2003 @03:22PM (#6553066) Homepage Journal
        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.

  • Rationale (Score:5, Interesting)

    by sql*kitten ( 1359 ) * on Monday July 28, 2003 @08:06AM (#6549666)
    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.

    • WRONG! POSIX does some really dumb things!! (Score:5, Informative)

      by cculianu ( 183926 ) on Monday July 28, 2003 @08:29AM (#6549764) Homepage
      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!

    • Re:Rationale (Score:5, Interesting)

      by BJH ( 11355 ) on Monday July 28, 2003 @09:28AM (#6550072)
      They chose not to implement POSIX because of things like this:

      259 The files at.allow and at.deny reside in /etc rather than /usr/lib/cron
      260 on LSB implementations.

      Why, for the love of God, would you want them under /usr/lib/cron, of all places?!

      Face it, POSIX is just broken in some areas.

      • Re:Rationale (Score:4, Insightful)

        by DarkMan ( 32280 ) on Monday July 28, 2003 @10:20AM (#6550470) Journal
        Because that's where they belong?

        Or, alternativly, why not? If it's just because your not used to it, then ponder it a bit more.

        if /usr/lib/prog stored all the information that prog required, then it would be simpler to cleanly uninstall, and to bundle, a working application.

        Why not reserve /etc for system-wide configuration, and put program specific information somewhere where it is clear that it's program specific?

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

        Now, POSIX may be broken because it's inconsitant (some per-prog configuation in /etc, some in /usr/lib/prog), but that's a seperate issue.

        One big advantage of this approach would be for a large number of systems, that NFS mount /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.

        • Re:Rationale (Score:3, Informative)

          by BJH ( 11355 )
          Why not?

          Well, how about if you want to mount /usr readonly? If you've got files that could change during operation on that partition, you're stuffed.

          BTW, installation/uninstallation of an app is the job of the package manager, not the user. If the PM knows what files belong to what package, what real advantage is there to having everything for that app under on directory?
      • > Why, for the love of God, would you want them under /usr/lib/cron, of all places?!

        at was (still is sometimes) implemented in terms of cron. It made sense to keep cron's stuff together. I agree, it's an idiotic place, but there should be symlinks.

        Putting them directly in /etc and not /etc/cron, incidentally, sucks. Directories are nice things, let's use them. Aside from keeping things nice and pretty, it would allow using some sort of remotable config database mounted as a directory, without havin
    • Other posts point out many good reasons (such as dumbness in POSIX, which should not be kept around in another standard), but for certain things (such as threads), the reason is that Linux at the time has not been conforming to POSIX in these aspects, so programmers are expected to pay special attention on Linux compatibility, rather than completely adhering to the POSIX standard, which may save a little effort but will break on many current Linux systems.

      When most Linux systems conform to POSIX behavior

  • Goldilinux and the three bears... (Score:5, Funny)

    by Black Parrot ( 19622 ) on Monday July 28, 2003 @08:10AM (#6549681)


    SCO: "Too similar"
    TOG: "Too different"
    LSB: "Just right!"

  • gets() (Score:4, Funny)

    by Genghis Troll ( 158585 ) on Monday July 28, 2003 @08:11AM (#6549682) Homepage Journal

    107 The LSB has deprecated the gets() function, whereas it is a first
    108 class function in ISO/IEC 9945 and ISO/IEC 9899.


    Won't somebody think of the script kiddies!

    • Re:gets() (Score:2, Insightful)

      by Gorny ( 622040 )
      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.

      • Re:gets() (Score:2, Funny)

        by Surak ( 18578 ) *
        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.

        I do, but then again, I'm working on a project that requires Windows compatibility. ;)

      • It's not even a matter of checking user input! (Score:5, Informative)

        by cculianu ( 183926 ) on Monday July 28, 2003 @08:35AM (#6549789) Homepage
        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.

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

        • Can I invoke stupidity and ask exactly who is being sarcastic?

        • what I do (Score:4, Funny)

          by martin-boundary ( 547041 ) on Monday July 28, 2003 @10:14AM (#6550402)
          Right on! What I usually do when I use gets is this:

          char buf[10];
          char dummy[10];

          fgets(dummy, 10, stdin);
          n = strlen(dummy);
          ungetc('\n', stdin);
          for(i = n - 1; i >= 0; i++) {
          ungetc(dummy[i], stdin);
          }

          gets(buf);

          I'll admit it's a bit tedious, but it helps prevent gets overflows.

          • 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 cod

    • Re:gets() (Score:3, Interesting)

      by BetaJim ( 140649 )
      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.

      • Re:gets() (Score:3, Interesting)

        by quigonn ( 80360 )
        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.

    • Re:gets() (Score:3, Interesting)

      by drakoo ( 604046 )
      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.

      • Re:gets() (Score:2, Insightful)

        by NightSpots ( 682462 )
        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.
  • I think the Mutual Standards Base should be created from the best of both.

  • Nothing major (Score:5, Informative)

    by Anonymous Coward on Monday July 28, 2003 @08:12AM (#6549689)
    Most of the differences fall into two catagories:
    1. The LSB spec is a sub-set of the required POSIX implementation (E.g. PThreads)
    2. 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.

  • Affected C functions (Score:5, Funny)

    by Rosco P. Coltrane ( 209368 ) on Monday July 28, 2003 @08:12AM (#6549690)
    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?
    • Even if not, GNU has helpfully published a version of "Hello, World!" that uses autoconf [gnu.org], so it's quite easy to work around incompatibilities if the GPL isn't a problem for your project. It doesn't seem to be actively maintained at the moment, however, the current version 2.1.1 is over a year old.


      • > GNU has helpfully published a version of "Hello, World!" that uses autoconf

        Why make things so complicated!

        # Makefile for "Hello World" program.
        #
        hello:
        @echo "Hello, World!"

  • POSIX,LSB,BSD,heck, where is everything? (Score:5, Interesting)

    by Lumpy ( 12016 ) on Monday July 28, 2003 @08:16AM (#6549704) Homepage
    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?

    • Re:POSIX,LSB,BSD,heck, where is everything? (Score:5, Interesting)

      by ninthwave ( 150430 ) <slashdot@ninthwave.us> on Monday July 28, 2003 @08:37AM (#6549795) Homepage
      You are probably more inclined to than look at this [pathname.com] project than POSIX compliance different issue altogether though within the scope of LSB.

      POSIX compliance is mainly in the API
      while the directory layout is a matter the LSB is approaching it is not part of POSIX specification except for some directories that must exist.
      Detail [opengroup.org]
    • Won't happen, ever. There are reasons for the differences. For example, OpenBSD stores config files of third-party apps in /etc, FreeBSD in /usr/local/etc - there are good arguments for both ways (basically "all config files should be in one location where you can easily find them all" vs. "there should be a clear distinction between the base system and arbitrary third-party stuff").

      Another problem is non-free software where you don't really have a choice where to put stuff, especially when the author(s)

    • Ironically, your .sig calls for a group of geeks to stand up for what
      they believe in.
      Note that the Debian project is just that, and Debian has probably the
      most consistently well-thought out policy for where and how everything gets
      installed.
      The only problem is, it's different from everyone else's. Still, it
      works. If what you were suggesting is all Linux distributions aim for
      compliance with Debian policy, I'm behind you all the way. Or ahead of
      you, whatever ;)
    • Where should apache go?

      /var is for variable data. While web pages change, it's not exactly 'variable'.

      /usr is good for the binaries, but the data is updated too much. Besides, it's common to mount /usr read only for security reasons.

      /opt? That's for package data. An apache package could live there, but again the data changes, and opt could be mounted read only for the same reason /usr is.

      /home? doesn't really fit either. There's a apache user for it, but it doesn't give multiple users easy access

  • Linux must improve POSIX conformance (Score:5, Interesting)

    by Anonymous Coward on Monday July 28, 2003 @08:24AM (#6549740)
    Especially in the pthreads area.

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

    • NPTL? (Score:5, Informative)

      by Styx ( 15057 ) on Monday July 28, 2003 @08:44AM (#6549824) Homepage
      I'm no thread programmer, but I think that NPTL [redhat.com] (The Native POSIX Thread Library for Linux) may solve your problem.
    • I agree, popen() or system() shouldn't hang the system. That said, under under certain real unices, they aren't marked thread-safe (Solaris 8, for instance). I'm pretty sure that's corrected under Solaris 9, but I haven't checked.

      A reasonable approach might be to use the Apache Runtime for those functions; apr_proc_create(?) combines the ability to do popen/p2open/system into one call which they claim is thread safe, and seems to be from my own experimentation. Well, that, and the fact that they are used f

  • Well (Score:2, Funny)

    by Anonymous Coward
    It seems that Posix has some updating to do.
  • 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.
    • I would argue Linux evolves BECAUSE of the millions of different websites and a million poeple working on it in different places.

      Before we had historians, poeple did things. Before we had journalists, people communicated. Before we had critics, people made artwork and music.

      Never confuse progress with those that try to put the calipers of reason to it. Indeed, what is recognized as a trend doesn't really exist until everyone involved has died and someone picks through the scraps.

  • Why does the Open Group care? (Score:5, Interesting)

    by mabhatter654 ( 561290 ) on Monday July 28, 2003 @08:44AM (#6549821)
    What part of GNU's not Unix don't they understand? As well as the fact that Linux is not an "offical" unix either. Why do they care about what some "fringe" group does?

    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!

    • Re:Why does the Open Group care? (Score:2, Insightful)

      by Anonymous Coward
      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 put
    • Why do they care about what some "fringe" group does?

      If Linux were the only OS that anyone used, then it would have to fork. One of the driving principles of the open source philosophy is strength through diversity. The way in which this strength is maintained is by standards. Linux conforms to standards, as do the *BSDs and Hurd. This allows you to take the source code from a program written on one system and compile and run it on another.

      Contrary to the beliefs of several fanatics, Linux is not

  • The source of evil (Score:5, Informative)

    by quantum bit ( 225091 ) on Monday July 28, 2003 @08:47AM (#6549845) Journal
    Aha! So this is the source of all those Linux-isms that cause some apps to not run right on BSD and other Unicies. Open-source ones can be fixed but I believe that this:

    134 LSB permits as deprecated behavior, the return value of a successful
    135 call to nice() to be 0 (rather than the new nice value). A future version
    136 of the LSB is expected to require the new nice value, as specified in
    137 the ISO/IEC 9945. Until then, applications need to call the getpriority
    138 function, rather than rely on the return value from nice() on LSB systems.


    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...
    • What's the status of select()? In most UNIX implementations, the struct timeval that you pass in is const. In Linux, it is the amount of time left after the wait, including 0 if the select returned because time ran out. This caused me a little chasing around some time back. I'm not sure what POSIX says about that parameter though.
      • Well, POSIX 1.g defines timeout as a const. I just checked the NetBSD and FreeBSD sources, and while they don't define it as a const, both implementations make a copy to use for their own purposes and don't modify the one that the user passes (though the man pages warn that other OSes do modify it so it shouldn't be depended on for portable programs). So making those POSIX-compliant would only take a simple change to the system header files.

        The man page for select on Solaris says that timeout will be mod

  • Terrific resource for porters (Score:5, Interesting)

    by _|()|\| ( 159991 ) on Monday July 28, 2003 @09:09AM (#6549970)
    Regardless of whether this results in changes to POSIX or LSB, this analysis is a terrific resource for those porting applications from Unix to Linux. Thank you, Andrew Josey, for poring over not one, but two specifications. Thank you, Open Group for funding the work.

    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. :-)
  • 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 tim

  • Question... (Score:5, Insightful)

    by Hard_Code ( 49548 ) on Monday July 28, 2003 @09:35AM (#6550128)
    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"?
    • Put 40 C Programmers in a room, ask them to write the same program, you get 39 different copies of the same program. The last guy throws in some inline assembler to be different.

      Ask 40 C++ programmers to write the same program, you get 40 completely different architectures. Ok, 38 differenct architectures, and 2 guys in a fistfight about which version of the standard they are going to use.

      Now beyond those 2, do you honestly see someone writing an operating system based on:

      • Java
      • Fourth
      • Scheme
      • Visual (fi
      • I guess my point is that people program to libraries, not directly to the OS...so instead of having one big monolithic calcified "OPERATING SYSTEM COMMANDMENTS FROM GOD", instead let each language community come up with standard APIs for *their language* and then map them to the particular system as necessary (e.g. Java has its own APIs for threads and files, etc., but each of course is mapped differently to each OS...same for perl, php, most languages...). This way, the operating system just has to suppor
        • > instead of having one big monolithic calcified "OPERATING SYSTEM
          > 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 pie

    • Re:Question... (Score:2, Insightful)

      by elflord ( 9269 )
      What does POSIX have to do with the standard C library?

      POSIX predates the standard C library. UNIX and C were developed concurrently. ANSI/ISO C-99 did not exist when the first UNIX was written.

      We live in a world where C is no longer the only language used.

      Yes, we do now.

      Why can't the spec be split into "system stuff" and independent "cross-platform (your favorite language) requirements"?

      Not sure what you mean here. The point is that these calls are supposed to work in a cross-platform manne

  • POSIX is expensive (Score:2, Interesting)

    by Anonymous Coward
    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.

  • Linus quote (Score:4, Informative)

    by riptalon ( 595997 ) on Monday July 28, 2003 @01:14PM (#6551999)
    Note that the reason the kernel is not POSIX-compliant is:
    - the POSIX standard is technically stupid.
    Linus Torvalds

    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:

    POSIX threads is a braindamaged pile of crap.
    Alan Cox

Slashdot Top Deals

Chemist who falls in acid is absorbed in work.

Close