[TUHS] Macs and future unix derivatives

[Theodore Ts'o]

On Mon, Feb 08, 2021 at 11:37:38PM -0700, Andrew Warkentin wrote:
> > But hey, if you only want V7 Unix, why are you complaining?  Just go
> > and use it, and give up on all of this cancerous new features.  And I
> > promise to get off of your lawn.  :-)
> >
> There's no reason any of that has to be implemented with primitives
> though. All of that could be implemented on top of normal file APIs
> fairly easily.

Everything can be implemented in terms of a turing machine tape, so
I'm sure that's true.  Whether or not it would be *performant* and
*secure* in the face of application level bugs might be a different
story, though.

In fact, some of the terrible semantics of the Posix interfaces exist
only because there were traditional Unix vendors on the standards
committee insisting on semantics that *could* be implemented using a
user-mode library on top of normal file API's (I'm looking at you,
fcntl locking semantics, where a close of *any* file descriptor, even
a fd cloned via dup(2) or fork(2) will release the lock).  So yes,
Posix fcntl(2) locking *can* be implemented in terms of normal file
API's.... AND IT WAS A TERRIBLE IDEA.  (For more details, see [1].)

[1] https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html

I could go on about other spectactularly bad ideas enshrined in POSIX,
such as telldir(2) and seekdir(2), which date all the way back to the
assumption that directories should only be implemented in terms of
linear linked lists with O(n) lookup performance, but I don't whine
about that as feature bloat imposed by external standards, but just
the cost of doing business.  (Or at least, of relevance.)

> Also, sockets are not the ideal interface for a window server IMO. The
> only reason they are used is because conventional Unix didn't provide
> user-mode file server support until fairly recently (and the support
> that's been added to more recent conventional Unices is a hack that
> has poor performance and isn't used all that much).

I'm not sure what you're referring to; if you mean the *at(2) system
calls, which is why they exist in Linux (not for !@#!? Windows file
streams support); they are needed to provide secure and performant
user-mode file servers for things like Samba.  Trying to implement a
user-space file server using only the V7 Unix primitives will cause
you to have some really horrible Time of Use vs Time of Check (TOUTOC)
security gaps; you can narrow the TOUTOC races with some terrible
performance sucking impacts, but removing them entirely is almost
impossible.

The reason why it's not used that much is because a lot of programmers
want to be compatible with OS's that don't support those new
interfaces --- and so they don't use it.

And that's the final thing for folks to remember.  There's an old
saying, "without software, it's just a paperweight."  This is just as
true for an OS; if you don't have application software, who cares how
clean it is?  And it had better be performant, and not just a
Posix-compliant layer afterthought demanded by the Product Manager as
a checklist feature item.  Rob Pike talked about this over two decades
ago in his talk, Systems Software Research is Dead[2].  The slide
talking about Standards (page #13) is especially relevant here:

    To be a viable computer system, one must honor a huge list of
    large, and often changing, standards: TCP/IP, HTTP, HTML, XML,
    CORBA, Unicode, POSIX, NFS, SMB, MIME, POP, IMAP, X, ...

    A huge amount of work, but if you don’t honor the standards you’re
    marginalized.

[2] http://herpolhode.com/rob/utah2000.pdf

That's because most people aren't going to port or rewrite application
software for some random OS, whether it is a research OS or someone's
new "simple, clean, reimplementation".  And most users do expect to
have a working web browser.... and text editor..., and their favorite
games, whether it's nethack or spacewars, etc., etc., etc.

If you want to call it feature bloat, so be it.  But that seems to me
like it's an excuse made by people who are bitter that people aren't
using (or paying for, or contributing to) their pet operating system.

Cheers,

					- Ted