“Unix and Windows are very, very similar and they should be bashed in unison”
c2.com
c2.com
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...
I generally dismiss a lot of the things the author is saying for 3 reasons:
1. The author is listing a lot of problems without actually specifically listing why they are in fact problems. For instance, he states that neither Windows nor Unix can teach you how to program. Why would my OS need to be able to teach me how to program? That's like complaining that my Car doesn't teach me how to rebuild the transmission, or my refrigerator doesn't teach me how to generate refrigerant. That's just an obvious example that jumped out at me, there are many others.
2. The author is pointing out a lot of problems without actually pointing out any solutions. People who point out problems but provide no solutions are generally useless. If you ever worked on a project with a person like that, you know what I am talking about.
3. c2.com lacks any sense of design or taste. The author also lacks any ability to communicate his point of view in a logical and consistent manner. I wouldn't trust the author to design a Ski Free game, let alone an operating system. In reality, if tasked with a job to write a Ski Free game, the author would instead return a 30 page paper on the subject of problems with modern game design.
The content on c2.com is not the work of any particular author - it's a wiki whose articles are collaboratively created and edited. Each paragraph may be the work of one or more anonymous or named writers.
In fact, c2.com happens to be the world's very first wiki, designed by Ward Cunningham. (The wiki's content has been frozen and is no longer editable. I seem to remember that Ward is working on a next-generation replacement for it.)
It has the very best design! http://motherfuckingwebsite.com/
For some history, the Jeff that he keeps talking about is a former student of mine at Stanford. I wasn't a big deal at Stanford, I was a TA for a Xerox PARC guy, when he retired Stanford asked me if I'd teach the class.
This was the papers class in operating systems. If you don't know what "papers class" means it means there are no text books, this is where you go to learn at the cutting edge. Pretty advanced class and Stanford let me teach it. To this day I wonder what they were thinking. That said, I'm proud of how I taught that class. The students learned a lot.
Jeff Bonwick was a student who was doing a major in statistics. Somehow he ended up in that OS class. I could tell he was sharp and I was working at Sun in the kernel group, I recruited him as hard as I could. He asked me why I would want him, his exact words were "I can't program in C". I told him that I could teach him how to program, I can't teach people how to be smart. He was very, very smart. I told him when he came to Sun he would go far higher than I ever did and I was right, he did.
Bryan is cut from the same cloth. He's an OS geek. There aren't many of those geeks around these days. Go him.
Mostly what I learned was about people, it wasn't about OS.
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.
Sadly we will get a userland full of container-ized apps (via systemd) and a monolithic kernel (still linux). Worse is better.
Finally, in terms of Spring: based on the fact that you are implicitly defending it, I would guess that you never had to run it. As one of the very few outside of Sun inflicted with that flaming garbage barge, I can tell you that it was not at all a pleasurable experience -- and that whatever novelty it represented was more than offset by its horrifically poor implementation. If I ever harbored any illusions about Spring, they certainly didn't survive my first encounter with a machine running it...
Most "micro"kernels aren't micro at all, they are bloated crapware. QNX was not like that, they actually had a micro kernel and it worked. I ran 4 developers on an 80286 (no VM) and it worked just fine. Far far better than the VAX 11/780 that had more memory and more CPU power. The VAX was running 4.1 BSD.
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...
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.
Calling EC2 a micro kernel success story also seems like quite the definitional stretch.
No personal attacks, please.
I'm not assuming that. Any amount of research could be no research or close to none. People who have done very little research shouldn't opine. People who have done lots of research are more likely to be correct.
News flash: it is possible for informed people to disagree.
Well of course. Someone who's barely informed can disagree with someone who is far more informed. That would be two informed people disagreeing.
If someone has done adequate research and I'm correct, they must agree with me, otherwise the amount of research wouldn't be adequate or I must be wrong. I can avoid being wrong by avoiding having strong opinions on things I don't understand or know much about 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.
http://c2.com/cgi/wiki?BlueAbyss
Old spec: 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.)
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?
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.
Although most UNIX variants today support either the POSIX or X/OPEN standard, every UNIX vendor has tried to differentiate its offering with a proprietary interface, applications, and architecture.
http://windowsitpro.com/systems-management/nt-vsunix-one-sub... [1998]
AmigaOs is underused solely because it's superior.
http://c2.com/cgi/wiki?WimpIsBroken
My concrete proposal is to avoid using concrete.
A more contemporary version of that rant would no doubt be extolling the more FP oriented OS instead of OO though. Written by someone who drifted off while reading Lisp books too many times. They are in for a let down when they find stuff was "hacked together in Perl" instead.
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.
"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 ?
But seriously, this pre-dates ZFS for sure and ion3 I don't know about.
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.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..?
Not that this was "user-friendly" in modern sense, but also don't think anyone had issues with this.
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 ...
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.
By your own admission, you "use" it, which makes you a "user", and as we all know, all users are clueless, therefore you are in no position to judge whether it is "usable". That's logic! -- Tweedledum
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.
Using these semantics then, this is all user-layer stuff, and even less of an argument against "UNIX" itself. :)
What is BEOS's market penetration?
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).
As is every living being.
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.
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.
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.)
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.
I think you have the layering completely the opposite way. NT has security descriptors on everything that has a name. Then above there is Win32, originally bolted on top of NT as a compatibility mode among others, which is historically an API for not very security conscious systems. And most Windows programs out there don't care about the security features.
So it's more like the higher layers suck in this regard.
Huh?
The fundamentals of Windows NT (the object manager, the registry and NTFS) all have ACLs.
vs
> You can't learn programming from either Unix or Windows.
Really?
Reading this article is an exercise in Poe's Law.