Re: Which 90% of POSIX /is/ good then?

[Alfred M\. Szmidt]

   * pids are broken. They aren't persistent handles, like fds, so
   hello race conditions on anything using them.

You cannot get away from race conditions, nor should pids be persitent
in a non-persitent system.  In other words, PID's aren't broken.

   * devices are in the filesystem namespace, socket port numbers
   aren't.

POSIX doesn't mandate that devices must be in the filesystem
namespace.

   * The main file API does things mostly by path name, within the
   mutable namespace. More race conditions! Look at all the temporary
   file and symlink bugs. I do get a process cwd, so can maybe
   directory handles etc. Later we add fstat etc, getting better.

Race conditions cannot be fixed, no matter what kind of a API you
implement.

   * uids are an amazingly coarse security measure. They are all or
   nothing. And every process gets the whole system call array to use:
   network, interprocess signals, etc. No way to create subsets.

This has nothing to do with POSIX, you are free to imlpement subsets,
this was done in the Hurd.

   * The unified file namespace is tied all together by ".." parent
   acess and by symlinks relative to the root. (And now by shared
   libraries for binaries) Separating out individual directories is
   pretty pointless, and chroots are a pain to use. No chance of
   security subdomains there.

This isn't a argument against what you call a unified file namespace,
it is a argument against: badly written programs and chroot's.

   * terminal subsystem - stuck in the days of serial access. What
   happened to graphics, multimedia? Oh yes, we've got X. Its ok, but
   somehow lacking in quite a lot. Where's my network transparent
   sound after 20 years?

The terminal subsystem in POSIX is actually quite fine, it doesn't
prohibit you from implementing any of what you suggest.  Once again
this is not a argument with how POSIX does something, but a argument
what is _missing_ in POSIX (and one can argue if such things should be
in POSIX at all).

   * File access API. Assumes most files are mutable. (clue: this
   turns out to be wrong!) Ignores multiple versions. Destroys
   transactional semantics by making files appear in filesystem on
   open, instead of on close. Hello access to half-completed files!
   Oh, wow, we do a get a transactional rename. Wot no metadata?

All of these has nothing to do with POSIX once again, you are free to
implement a versioning file-system, add metadata etc, and it won't
make the system a non-POSIX system.

   * fork: oh dear, it leaves all the fds open, signals enabled,
   sessions wrong, uids gids etc. Its rarely what we actually
   want. Most things just (forget to) close lots of things and exec
   immediately.

So you blame incompetence instead of attacking the real faults with
fork/exec.

   * device model. We've got character and block devices. How much of
   their behaviour is standardised? What about standards for other
   sorts?  Hello ioctl hell!

ioctl isn't meant as a general way to access all types of things; it
is meant as a cheap way to access a specific feature of the device
(like rewinding a tape, or ejecting a CD).  If you don't know what a
block/char. special file is, then you should read the standard.

   * Shell process control. Its stuck in the tty age. screen is your
   friend.... Except when ptys go bad. Can you say security nightmare?

No, I can't.  Can you say: Nothing to do with POSIX?

   * pipes. raw character streams. all that richly formatted data
   squashed into it. Look at the hassle of making find | xargs grep
   work with arbitrarily named files.

Once again not a problem with POSIX, blame the implementation.  For
the record, I have never experienced problems with find+grep with
arbitrarily named files (this includes files with weirdo chars that I
can't input without resorting to octal codes).

What you seem to not understand about POSIX is that it is a middle
ground for writting portable programs, programs that will run on
various POSIX systems.