"To be honest, looking back on it, Unix today is worse than the systems that Unix itself was created to get away from."
"I didn't use Unix at all, really, from about 1990 until 2002, when I joined Google. (I worked entirely on Plan 9, which I still believe does a pretty good job of solving those fundamental problems.) I was surprised when I came back to Unix how many of even the little things that were annoying in 1990 continue to annoy today. In 1975, when the argument vector had to live in a 512-byte-block, the 6th Edition system would often complain, 'arg list too long'. But today, when machines have gigabytes of memory, I still see that silly message far too often. The argument list is now limited somewhere north of 100K on the Linux machines I use at work, but come on people, dynamic memory allocation is a done deal!
"I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."
http://slashdot.org/story/04/10/18/1153211/rob-pike-responds...
This is a shitty argument. Dynamic memory allocation is a done deal, but it's trivial to bring down a system that doesn't limit it, and so you still need a limit beyond which users will still get errors.
And usually, if you keep getting it, it's down to bad habits (globbing instead of find + xarg, the latter which lets you take full advantage of multiple processors)
"..the Unix/POSIX/Linux systems of today are messier, clumsier, and more complex than the systems the original Unix was designed to replace.
It started to go wrong when the BSD signal stuff went in (I complained at the time), then symlinks, sockets, X11 windowing, and so on, none of which were added with proper appreciation of the Unix model and its simplifications."
That's my feeling about Go and C.
If you look for desktop alternatives to Unix, OSes to look at are BeOS (an open source clone is developed under the name HaikuOS) and the Windows NT kernel (don't hurt me: the Windows NT kernel is IMHO far more elegant than, say Linux or Mach. What is crappy is especially the WinAPI; please look deep below the surface: Here Windows gets nice).
The reason why you won't find many desktop/server alternatives to Unix can be read here: http://herpolhode.com/rob/utah2000.pdf Thus lots of OS reserach is either focused on embedded stuff or virtualization instead of desktop or server.
Accepting this, especially have a look at the L4 kernel family (a family of very small and fast microkernels). If you like highly secure designs, you'll probably like seL4, the first formally verfied kernel. Also QNX is worth a look (QNX is Unix, accepted; nevertheless a very elegant kernel design).
In respect to the WinAPI, OS/2 API shares part of the pain. And Xlib is way worse.
I am looking forward to WinRT fixing some of the WinAPI issues.
Haiku https://www.haiku-os.org/
Haiku http://en.m.wikipedia.org/wiki/Haiku_(operating_system)
Windows NT Kernel http://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT
Windows NT Kernel http://blog.zorinaq.com/?e=74 (which references back to HN)
L4 microkernels http://en.m.wikipedia.org/wiki/L4_microkernel_family
SEL4 http://sel4.systems/
I'd also like some clarification on what you think is good about the NT kernel. It seems far too entangled with other cruft that forms the Windows stack.
That said, I'd also like to mention the Hurd. At this point, it's really a fragile ad-hoc reimplementation of 9P file servers on top of a modded Mach, but such a model was still quite daring for general purpose computing back during the Hurd's original window of opportunity (1989-1995, or so). Probably would have advanced the state of modern OS at least a bit, if it weren't for managerial incompetence.
It's still a Unix at heart, though, despite many important extensions.
BeOS was very optimized for multimedia, which is an interesting property I think. Also the GUI library used multithreading from beginning. This surely isn't interesting for servers, but for desktop computers.
> I'd also like some clarification on what you think is good about the NT kernel. It seems far too entangled with other cruft that forms the Windows stack.
For a lack of time for explanations I will only give one example: How to do fast asynchronous I/O (You know: Asynchronous IO: The hot thing that node.js is about ;-) ;-) ). Under FreeBSD/Linux asynchronous I/O is just synchronous non-blocking I/O (FreeBSD needed to implement kqueue to even allow this in a fast way; the Linux developers implemented epoll (which is incompatible to kqueue :-( )). Under Windows NT it is an easy problem that has been solved (from beginning?). See
> http://sssslide.com/speakerdeck.com/trent/pyparallel-how-we-...
for details.
BeOS claimed to be optimized for multimedia, but that does not mean that it was. I remember, that I was able to have fluid DivX (3.11) playback on PII-300 running Windows and Linux, but not on BeOS.
What BeOS did have is DirectShow-like media architecture, using nodes and pipelines. But at the time, it was not an effective architecture.
(And yes, the BeOS engineers never managed to support VESA GTF in their display drivers, meaning that the picture on my monitor was always shifted compared to other OSes).
Back when BeOS was still on sale, Windows latest versions were Windows 2000 and Windows 98, with XP around the corner.
I never remember using DivX on those systems.
The original hacked codec appeared in 1998. It got boost in popularity when the movie The Matrix came out (1999).
This happened in Windows 98 timeframe. Windows 2000 was in early beta, not yet on sale and XP was unheard of yet. The current linux were Redhat 5, 5.1 and 6; BeOS 4 and 4.5.
I would need to go dig into my Zip floppies collection, a few thousand kilometers away from my current location.
[1] http://www.openmirage.org/ [2] https://www.youtube.com/watch?v=UjonFD-2ATo or http://www.se-radio.net/2014/05/episode-204-anil-madhavapedd... (audio only) [3] https://github.com/GaloisInc/HaLVM
Pike was talking about Plan 9. It was created by the research group that developed Unix as a more modern successor to Unix. From Wikipedia: "Plan 9 from Bell Labs was originally developed by members of the Computing Science Research Center at Bell Labs, the same group that originally developed UNIX and C. The Plan 9 team was initially led by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with support from Dennis Ritchie as head of the Computing Techniques Research Department. Over the years, many notable developers have contributed to the project including Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup and Bruce Ellis."
All that effort has shifted over to the browser and the web as a platform on every device. What's the point of putting such a large effort into a complicated, multi-tasking and multi-user desktop operating system if it spends 90% of its time running a browser for one user?
A Lisp based workstation (Interlisp-D), a Smalltalk based workstation and a workstation with the first GC enabled systems programming language Mesa/Cedar.
The said systems offered a REPL interaction with the operating system that UNIX to the day still can't match. With powerful concepts of UI workflows, which OLE on Windows or the ill faited Taligent are based on.
They also had the first IDEs, unit testing, AST code transformations and live debugging capabilities.
Some of the Mesa/Cedar ideas were re-used by Niklaus Wirth on his Oberon and Lilith OS research, and corresponding derivatives.
OS/2 offered a OO based UI, and the OS component model (SOM) was way better than COM, allowing for inheritance of implementation and meta-classes.
Amiga UI could have multiple resolutions at the same time, thanks to its chipsets chew more graphics than X-Windows can dream of. Additional it had a concept of libraries where developers could extend the OS and existing applications via plugins. Suddenly application X would be able to work with new file formats.
Risc OS also had quite a nice set of features, but I will let someone else jump in on that one.