* 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. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
