
“Unix and Windows are very, very similar and they should be bashed in unison” - vezzy-fnord
http://c2.com/cgi/wiki?UnixAndWindowsHell
======
bcantrill
I'm having a hard time dating this rant (despite its historical importance, I
can't seem to convince WikiWikiWeb to cough up a page history), but I would
guess that it's from ~1996. If so, it is a time capsule that represents the
stagnant OS thinking in the mid-1990s: the belief was that Unix was dead (!),
that Windows was going to be everywhere (!!) -- or that both of these systems
were essentially useless and what we _actually_ needed was radical surgery
like object-oriented operating systems or microkernels or exokernels or
orthogonal persistence (or all of the above!).

If it needs to be said, this time was a terrible atmosphere in which to aspire
to OS kernel development, a suffering that I expanded on (at far too much
length!) in a recent BSD Now.[1] I do not miss the mid-1990s at all, and even
now, I find that this ill-informed screed fills me more with resurrected anger
than it does any sense of vindication or nostalgia...

[1]
[http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_k...](http://www.bsdnow.tv/episodes/2015_08_19-ubuntu_slaughters_kittens)

~~~
vezzy-fnord
_what we _actually_ needed was radical surgery like object-oriented operating
systems or microkernels or exokernels or orthogonal persistence (or all of the
above!)_

Do we not?

I watched your interview, but I don't recall you saying anything about
research ideas. You even made a jab against Spring which rubbed me the wrong
way.

An orthogonally persistent microkernel-based operating system, even another
Unix, would be great. Which is why I'm looking at MINIX 3 and Hurd as
interests. The latter has its anachronisms, but it's still a step forward.

~~~
igravious
We've had the microkernel versus monolithic kernel debate _over_ and _over_.
I'm not against research but I've yet to see a convincing argument that
microkernels are better. If you decouple the logical bits of the kernel from
each other all you'll get is greater impedance and message passing overhead.
And for what? A "clean" architecture? Sometimes perfect is the enemy of the
good, and I think that applies in this case. We've also got the tools to make
monolithic kernel development scale now. Basically, I'll believe it when I see
it.

~~~
vezzy-fnord
_We 've had the microkernel versus monolithic kernel debate _over_ and _over_.
I'm not against research but I've yet to see a convincing argument that
microkernels are better._

Sure, if all you do is read Linus Torvalds ranting.

 _If you decouple the logical bits of the kernel from each other all you 'll
get is greater impedance and message passing overhead._

Debunked many times, as early as 1992 in fact:
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.1...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16)

Microkernels have come a long way since Mach.

 _And for what? A "clean" architecture?_

You clearly have no idea what the advantages are.

 _Basically, I 'll believe it when I see it._

You're seeing it in the billions of L4 deployments worldwide in wireless modem
chipsets. You're seeing it in QNX being everywhere.

But then again, you might not see it, because you are willfully ignorant.

~~~
tedunangst
How many of those L4 deployments end up running 90% of their code in the
"Linux" or "posix" process?

~~~
kragen
That might still be an argument in favor of microkernels if the Linux process
can't crash the machine or cause it to miss hard-real-time deadlines. Or if
you can use it to confine malicious code in the Linux process.

~~~
tedunangst
Fair, but when people talk about "real systems" built with micro kernels, as
often as not, it could also describe Linux on xen with a watchdog restart.
It's not especially compelling evidence that micro kernels are practical. Want
to convince me that micro kernels are the bomb? Tell me about a system where
no single service exceeds 40% of the code/runtime.

~~~
kragen
"Unikernels" is the misnomer being promoted by MirageOS for applications
compiled to run on Xen, which they are currently doing on Amazon EC2 hosts
alongside Linux instances. There are EC2 hosts that host a number of
instances, including "unikernels" and Linux instances, and although I don't
have details, the pricing on the smaller burstable instance types makes me
think that some of the EC2 hosts are hosting actually quite a large number of
instances, in which no instance exceeds 5% of the code or runtime. Is that
what you're talking about?

~~~
tedunangst
No. What I mean is a micro kernel pace maker where 40% of the code is the beep
beep service, and 30% is the meep meep service, and 30% is the bop bop
service. As opposed to 99% of the code in the Linux service and 1% of the code
in the realtime watchdog restart service.

Calling EC2 a micro kernel success story also seems like quite the
definitional stretch.

------
luckydude
As an old guy, I'm rather unimpressed with this sort of bashing. Yeah, Ward
made the first wiki. Kudos for that, he deserves it.

But if you are going to bash unix, Ritchie, plan 9, and windows all one page,
I'd like it if you had a concrete proposal for a better answer.

And saying unix and windows are the same, really? I've supported a fairly
complex SCM on windows, linux, macos, all the other unices, for 18 years. I
don't find unix to be the same as windows but maybe that's just me.

~~~
vezzy-fnord
_I 'd like it if you had a concrete proposal for a better answer._

[http://c2.com/cgi/wiki?BlueAbyss](http://c2.com/cgi/wiki?BlueAbyss)

Old spec:
[http://c2.com/cgi/wiki?BlueAbyssFramework](http://c2.com/cgi/wiki?BlueAbyssFramework)

(By the way, it's Richard Kulisz who is saying all of this. Ward Cunningham
has nothing to do with it.)

~~~
luckydude
Thanks for setting me straight.

So after reading that stuff I'm still not impressed. Might be me, I worked on
SunOS and we did "objects" for the VFS layer. It was like a class with all
virtual methods. Worked well.

Full on object oriented stuff in an OS seems weird to me. But I'm not an OO
person, I like really simple stuff, SunOS made that work, I hacked vi so that
when you tagged on VOP_OPEN it knew that there was ufs_open and nfs_open and
tmpfs_open and you could walk all of them, but it was very simplistic. And as
such it actually worked.

I like stuff that works, proven in the field, proven in the development space,
we can ship this and can support it.

I may be well behind the times but what I read didn't make me want to go work
on it, it made me skeptical about it actually working in real life. I'd be
happy if someone proved me wrong, it sounds cool. When is it shipping?

~~~
tedunangst
Yeah, but see, vfs doesn't count because... Uh, it uses macros, or something.

Hell, even the user land side is "OO". The same set of syscalls work on files,
sockets (IPv4 and IPv6), pipes, etc. "needs more OO" is a pretty nebulous
complaint about an OS.

~~~
luckydude
Device drivers are the original OO in operating systems and they seem to work
pretty well. Without any OO support in the programming language.

------
jfb
I'm not at all convinced that Smalltalk-80 was the apotheosis of computing
environments; both Windows and Unix are, cockroach like, exceedingly good at
staying alive. Neither is fun to use, but nobody's put selective pressure on
"fun to use" since, oh, maybe the introduction of the Multifinder.

~~~
cwyers
Microsoft Bob.

~~~
jfb
An evolutionary dead-end if ever there was one.

------
everyone
Fair enough, everything is flawed. But what should we use instead? TempleOS?

~~~
omginternets
>TempleOS?

I dunno, meddling in the affairs of the One True God seems like the sin of
pride to me. I shudder to think of the implications of serving porn on a
TempleOS server; that's asking for an IRL segmentation fault.

------
rsync
I like thinking about operating systems, and I am sympathetic to the notion
that things could be better than UNIX, but there's some real gibberish in this
article.

"Both have flat, useless WIMP GUIs;" ... this has nothing at all to do with
UNIX - you don't need a GUI at all in UNIX (which is great) and there are MANY
non-WIMP operating environments available - many of which are serious,
sophisticated, current offerings.

"Neither has a programmable GUI." False. ion3, for instance, which is one of
the many available non-WIMP environments I mentioned above, is completely
programmable with lua. I am sure there are 100 other examples.

"Neither is versioned, both are irreversibly destructive." Hard to say exactly
what is being pointed out here, but I _think_ it's related to filesystems and
going backwards ... and ZFS provides that just fine with snapshots. In fact,
even UFS2 has filesystem snapshots. Available on FreeBSD, Solaris, and many
others ... including Linux.

"Neither takes account of any modern research" ... again, previously mentioned
ZFS ... that's as modern as it gets. netgraph in FreeBSD also comes to mind as
something genuinely inventive, unique and modern.

"You can't learn programming from either Unix or Windows." Inasmuch as I would
consider the UNIX shell as part of UNIX, you absolutely can learn to program.
Further, inasmuch as DOS batch files are part of Windows, you can learn to
program there as well. I certainly did.

When was this written ?

~~~
igravious
In the 90's, don't know when exactly. I remember when this site was active :)
Showing my age. Back when wikis were new and /. was the nerd forum of choice.
Ah those heady times.

But seriously, this pre-dates ZFS for sure and ion3 I don't know about.

~~~
x0054
I am not sure when it was written, but it references "WimpIsBroken" article on
the same page. That article has been updated to also bash Windows 8 design.
So, if not written, then it must have been at least updated somewhat recently.
So I am guessing the author still agrees with all of his points of view.

------
igravious

       What a quaint and flimsy ranty troll,
       Written 'ere the web got old,
       In those days nobody'd call you out,
       When you started spewing through your spout.

------
Eiriksmal
> You can't learn programming from either Unix or Windows. You can learn it
> from other applications and from tons of books, but you can't learn it from
> the OS.

I grew up in an era of Windows 3.1+, so I'm probably showing my youth when I
ask, how can you learn to program from an OS? Is this akin to compiling your
own kernel from scratch and being forced to tinker with the kernel modules to
get Linux 2.x to run on your 2015 laptop..?

~~~
drdaeman
ZX Spectrum 48k had a BASIC interpreter as its primary OS. When the computer
was powered on the first thing user would see was a REPL (128k version
introduced a GUI menu with a few shortcuts). Although users weren't required
to, they literally invited to learn some programming.

Not that this was "user-friendly" in modern sense, but also don't think anyone
had issues with this.

~~~
JdeBP
To amplify that point: A lot of what were then often called home computers
bootstrapped into a BASIC interpreter. To pick just a few: the Oric, the BBC
Micro A/B, the Master, the Electron, the Commodore PET, the VIC-20, the TI
99/4A, and the QL

The Jupiter Ace bootstrapped into Forth.

None of these were akin to learning to program with the first step being the
giant leap from zero to compiling one's own kernel. That is not because they
didn't have kernels. Several did, coming with actual operating system kernels
that underlaid the interpreter. QL SuperBASIC, for one example, was an
applications program running on a multi-process multi-tasking single-user
handle-based I/O operating system named QDOS.

The learning to program had as its first steps the rather lower bar of the 2
or 3 line program that printed a string, or asked the user for input, or drew
a coloured triangle on the screen ...

------
trav4225
The value of a particular approach to OS design depends upon what it's used
for. This post seems to me to be making a number of assumptions in this regard
and I found myself thinking "that doesn't apply to me" about much of what it
states about UNIX.

Not a criticism per se, just stating that this definitely seems to be from a
specific POV.

Having said that, I must say that a few claims are made that are head-
scratchers to me, e.g. that UNIX is a "single-user system", and that an OS
should be something that one can "learn programming" from.

~~~
trav4225
Also, doesn't xmonad (which I happen to use) count as a "programmable GUI"?

~~~
vezzy-fnord
Not really. Oberon is an example of a programmable GUI, for one.

~~~
trav4225
Interesting. I am a bit confused though as to how xmonad could _not_ be
considered programmable. I'm curious -- what does it lack in your opinion?

~~~
vezzy-fnord
It's still just a WIMP interface. It might be a more flexible one since it's
tiling, and it might support a larger number of configuration options than
most.

An actual programmable GUI is one where there is no distinction between what
is referenced at initialization and what is bound at runtime. You're actually
live scripting the interface's own structures and moreover potentially
concocting intricate programs out of the on-screen text that can be typed at
any arbitrary offset, and is interpreted as a programming construct. Clicking
on a piece of text can serve as an entry point or continuation for performing
some form of computation, as it can point to anything, including the internal
state of a system object.

You could read people rabble, or you could just try Oberon, Bluebottle OS or
similar systems.

~~~
delish
Just to rabble in agreement, one recompiles xmonad (typically with mod-q),
where recompiling means loading one's entire xmonad.hs file. "Reloading a
file," especially when that file is typically solely used for xmonad resources
(and not for any object the user desires) is not nearly as programmable as a
Smalltalk or an Oberon.

~~~
trav4225
Gotcha. Understood.

------
tsotha
This rant brings to mind Stroustrup's observation about there being only two
kinds of languages: the ones people complain about and the ones nobody uses.

What is BEOS's market penetration?

------
jmspring
I agree a fair amount with the bashing. And I recall historical commentary
similar.

That said, the two hangups for me on windows are -

254 character path limit no posix compliance (lack of a shim library even) --
there used to be a posix compliant set of libs that were optional under NT

That said, outside the scope of the rant, Windows has been really good at
keeping backwards compatibility. (See issue w/ 254 char path limit).

------
ISL
"Neither have been designed well, both are the products of random evolutionary
pressures."

As is every living being.

------
gizi
What alternative does he propose? I don't see any. Furthermore, why doesn't he
propose/create practical, incremental improvements? In the meanwhile, I am
just going to stay compatible with all the miracles and all the horrors of the
past! ;-)

~~~
nerdy
I propose TempleOS for this author.

------
codelitt
I actually find Unix and Windows to be very fundamentally different.
Particularly where he talks about security. Unix security concepts are built
into the system architecture whereas in Windows they are implemented as
features on top of the OS. A perfect example that he calls out, ACL. Some does
exist in the architecture of Windows, but it is only a half hearted
implementation.

Modularity is another example of something that is fundamental both in the
architecture AND the philosophy of Unix, but very far behind in Windows where
many applications such as a browser exploit can tie into the kernel space.

The communities and philosophies are also something I breezed over, but I
think they are a non-trivial part of an operating system.

~~~
kragen
> I actually find Unix and Windows to be very fundamentally different.

There is a small child growing up in El Paso who thinks English and Spanish
are "very fundamentally different", too, because in English there's no word
for "quererte" or "sacartelo". But that's just because they've never heard
Chinese, let along Lojban or Python, and they don't know how to read yet, so
they have no idea along what lines languages might vary.

Unix and Windows are both single-node monolithic multi-user non-real-time
operating systems built on a hierarchical filesystem (with names that are
sequences of strings) with ACLs for discretionary access control, no mandatory
access control, a global user namespace controlled by a single system
administration authority, and in which executables (which share code using
dynamically-linked libraries) run with the full permissions of the user who
invoked them. In both systems you communicate with I/O devices as if they were
files. The interface they provide to user processes uses system calls to
present a programming interface that is much simpler than that of the
underlying machine; those processes can have multiple threads sharing memory
that block in system calls independently and can pre-empt one another, and by
default their memory is not shared with other processes. They are both written
mostly in C with some C++, and other programming languages are more or less
obliged to use C calling conventions to interoperate. Both of them use sockets
for network I/O. Users typically use them via a windowing system, which
provides a huge variety of complicated ways of setting pixels inside a
rectangular region on a virtual screen, and accommodates up to one mouse
pointer.

Compared to any of PolyForth, Pick, Genera, Oberon, VMS, KeyKOS, VM/360,
SqueakNOS, MacOS up to 9, MS-DOS, Spring, Sprite, QNX, and Amoeba, Unix and
Windows are as alike as two peas in a pod.

~~~
tedunangst
This is a good point, though also a bit curious, proposing as it does, that
msdos is perhaps a superior alternative. Protected memory is indeed an
argument that windows and Unix are the same. I'm less inclined to agree it is
a reason they should be bashed in unison.

~~~
kragen
MS-DOS is a superior alternative only for hard real-time systems and, perhaps,
for systems where security is more important than almost any functionality.
And probably running Linux under a real-time operating system like RTLinux is
a better alternative in the first case.

My point, though, is not that MS-DOS is better in any way; rather, it's that
"a flat space of multiple processes with independent address spaces of mutable
memory, separated using memory protection, each containing multiple threads,
which access I/O devices through system calls" (and, although I didn't say
this, with disjoint kernel and user spaces) is only one possibility among
many.

You could have only one process with one thread.

You could have multiple processes, but all in the same memory space, with any
of them able to overwrite the others' data. (You could call this "one process,
multiple threads.")

You could have multiple processes that share an address space but have access
to different parts of it, which sounds stupid but means you can pass raw
memory pointers in IPC and was the basis for a whole research program called
"SASOSes" a few years back.

You could reuse the same addresses for kernel space and user space, which not
only gives you a full 4GiB of virtual address space on a 32-bit machine, but
also ensures that your kernel code doesn't pass even the crudest testing while
dereference a pointer passed in from user space without using the appropriate
user-space-access function. (It also imposes the cost of two virtual memory
context switches on every system call; I think i386 can do this cheaply with
segment registers, but I'm not sure, and basically nothing else can.)

You could give user processes direct access to I/O devices so user processes
can access them directly instead of through system calls, which might be
sensible in an environment where you wrote all the processes.

You could _virtualize_ the I/O devices, just as we virtualize memory, so that,
for example, your gigabit network card copies packets directly into your
memory space — but only if they’re _your_ packets, not packets addressed to a
different process. (This was originally called "VIA" on Linux; I think it has
a different name now.)

You could separate your processes through a trusted compiler, like Erlang
does, instead of with hardware; an intermediate approach would use a trusted
machine-code verifier, analogous to Java's bytecode verifier, or a trusted
machine-code rewriter that compiled unsafe machine code to safe machine code.

You could allow only a single thread per process, like Erlang does and like
Unix did for many years, either with or without explicit shared-memory
facilities like shmseg and mmap.

You could entirely decouple threads of control from memory spaces, as KeyKOS
did (if you look at it funny; KeyKOS domains are an awful lot like single-
threaded processes, but you could instead consider them to be locks).

You could make all memory write-once, eliminating many of the difficulties
that attend sharing it (Umut Acar's Self-Adjusting Computation paper is based
on an abstract machine using this model) but probably requiring a global
garbage collector.

You could replace the memory abstraction with a transactional store and
execute transactions rather than continuous-time processes; the transactions
could either be time-limited, as in CICS, or preemptively scheduled like
processes, but in either case incapable of I/O or IPC.

So, considering the enormous design space of possibilities on even this single
matter, Unix and Windows are huddled together in one tiny corner of the design
space, as on many other design choices. It's clearly a better corner than many
other possibilities that we've explored, especially on currently-popular
hardware and with compatibility with the existing applications that bcantrill
was deifying upthread. But the design space is so big and multidimensional
that it seems terribly unlikely that we've found an optimum. We know that it
has failed to ever produce a secure system against many plausible threat
models, and that producing a hard-real-time system in it is possible but more
difficult than with some alternative models. We know shared-mutable-memory
threading is terribly bug-prone. We know that indirecting all I/O through the
kernel imposes heavy performance costs, which adds complexity to user
processes and adds the market barrier to high-performance I/O hardware like
InfiniBand. We know that processes separated by the use of virtual memory
facilities are very heavyweight, so you can't switch between them at more than
a few hundred kilohertz on a single core, you can't _create_ them at more than
a few kilohertz per core, and you can't practically make them smaller than a
few tens of kilobytes, all of which limit the power of the process as an
abstraction facility. (Linux has actually reduced the cost of processes, both
in physical memory and in context-switch time, by more than an order of
magnitude; I imagine OpenBSD has too. But improving the situation much further
probably requires different abstractions.)

~~~
tedunangst
That's a more involved response than I think I deserved. :)

No argument that winux is a only a local maximum, but this thread is in
response to an article that basically claimed it was a global minimum. Fwiw,
your comments are, imo, far more informative and constructive than the linked
post.

~~~
kragen
Flattery will get you everywhere :}

------
Bud
[dated 2008]

------
vacri
> _Neither is usable by someone who isn 't thoroughly familiar with their
> limitations and weird little idioms._

vs

> _You can 't learn programming from either Unix or Windows._

Really?

Reading this article is an exercise in Poe's Law.

