This is a discussion on Re: strip FreeBSD a bit - FreeBSD ; email@example.com wrote: > > FYI, UUCP is also required by POSIX 1003.1-2003 > > > > http://www.opengroup.org/onlinepubs/...ties/uucp.html > > > > It's part of the [XSI] subset, which is required for compliance > > with the Single UNIX Specification. If ...
> > FYI, UUCP is also required by POSIX 1003.1-2003
> > http://www.opengroup.org/onlinepubs/...ties/uucp.html
> > It's part of the [XSI] subset, which is required for compliance
> > with the Single UNIX Specification. If FreeBSD wants certification
> > someday, it will have to bring back UUCP.
> Perhaps this only shows that the POSIX standards should not be
> looked at anymore and a new standards group is needed.....
I'll be happy to switch, as soon as you form your new standards
group, get it accepted internationally by international standards
bodies, and then get your standard on the GSA schedule as being
an allowable product purchase in lieu of POSIX when bidding on
When you do this, perhaps we can rip the assinine System V signal
non-restart behaviour, System V instead of BSD tty dissociation
code that makes us have to check return codes on reads after a tty
is revoked rather than just taking a SIGHUP from our parent, and
System V behaviour when closing one of several open instances of a
file, when there are advisory locks outstanding on a descriptor
other than the one you are closing.
Doing this would *vastly* simplify our threads libraries, FWIW,
and cut by 300% the number of real system calls per wrappered call
that needed to be made *each and every wrappered call* in libc_r
At the same time, maybe we could fix the fact that multiple fd's
open on the same file, and resulting from fork/fcntl(,F_DUP)/dup/dup2
all share the same structure, so that if one process modifies the
file offset, all of the others end up getting the modified offset,
instead of their own offset.
BTW, all this cruft and more were concessions to POSIX conformance,
vs. The Traditional BSD Way Of Doing Things.
Maybe we could make people use mmap() and rendezvous via a file,
in order to obtain shared memory, instead of wiring down kernel
maps and using up precious kernel resources with shmget/shmat,
while we're at it.
Typing up all the cruft that came in with the tacit requirement for
POSIX conformance would be enough to make even my fingers tired...
but I recognize the need for standards conformance, so if all you
have is an ugly standard, well, it's better than no standard at all,
or a mythical not-yet-standard standard.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"