[TUHS] Were all of you.. Hippies?

ron minnich rminnich at gmail.com
Fri Mar 24 16:06:31 AEST 2017


So, first, I'm not here to argue about the merits or lack thereof of the
Unix model as I described it. I am just trying to explain my view of what
the Unix model was. Since this is the TUHS, I'm trying hard to avoid things
related to LUHS, or 9UHS :-)

So, nope, I'm not responding to the comments that I see as out of scope of
TUHS. Lack of response does not indicate agreement :-)

But it got me to thinking: what aspects of the Unix model did not age well?
It's certainly aged remarkably well for 50 years. But what would we do
differently?  I'm glad that at least one subsequent effort -- by the guys
who invented these things as it happens -- fixed most of the list that
follows.

Without further ado, and based on the v6 system call set, which is where I
came in (I'm biased) ...

Device special files. These gave us the situation we have today with major
and minor numbers. I deal with it daily. I wish I did not have to. And we
don't need them.

ptrace -- there's much better ways to do what ptrace does.

Open which combines walk and open. Linux at some point added O_PATH, which
is very nice, as it lets you get an fd for a file but not actually open it,
and 9p has walk and open, but sadly plan 9 never exposed them; it just has
open which does both. There's two kernels I'm involved in which will be
breaking open out into walk and open. But who knew 50 years ago you'd want
two ops, not one?

ioctl.

unidirectional pipes. Bidirectional pipes are so much nicer.

errno. Once you get used to getting an error string from the kernel, with
detailed information, errno just drives you crazy.

integer user ids. Totally reasonable approach pre-networking on 16-bit
machines, but think of the amount of trouble that integer user ids give us.
There was a time when a file name was just an integer, and we'd never
accept that now; why do we still accept an integer for a user name?

root user.

and the big one ....

fork.The amount of abuse I've seen heaped on fork over the years is pretty
amazing. I always found it convenient, but at the same time, how much
effort have we expended as we move from processes with 16 or 128 4k pages
to processes with, in some cases, millions of fds and pages? How many gray
hairs has fork caused you over the years? Would you pick something else?

What do you see that you think could be done differently, given 50 years to
look back?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/51c05929/attachment.html>


More information about the TUHS mailing list