3 ms·

There's some great stuff here, and some favorite historical systems are represented (e.g., the B5000). Still, I can't help but see this as a hold-over from the

There's some great stuff here, and some favorite historical systems are represented (e.g., the B5000). Still, I can't help but see this as a hold-over from the mid-1990s -- the anti-Unix Dark Ages of Operating Systems.[1] For example, on Unix itself: "Still, after three decades, it can be argued that the widespread acceptance of Unix has become an obstacle to further progress." For evidence for this (absurd) assertion, the author cites a Stonebraker piece[2] that was already two decades old when this was written. And even by 2000, Stonebraker's assertions were either no longer true, or no longer relevant -- and the biggest database systems at the time were on Unix. Fifteen years further down the track, the Unix assertion is (blessedly) comically wrong -- and many of the advances in operating systems since have been underneath the Unix abstractions and/or orthogonal to them. That is, we are (mostly) no longer developing grand new systems with entirely new programmatic models -- but we continue to make important progress on how the abstractions that we have agreed upon (i.e., Unix) are implemented and deployed. Further, I think that the philosophical contribution of Unix (that is, the Unix philosophy[3]) continue to be as important as ever -- and very clearly influential far beyond the bounds of the operating system per se. In short: I would love to see a modern update of this -- especially one that puts Unix in its proper historical context. [1] https://news.ycombinator.com/item?id=10138765 https://news.ycombinator.com/item?id=10138765 [2] http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf http://db.cs.berkeley.edu/cs286/papers/os-cacm1981.pdf [3] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy

vezzy-fnord 11y ago
Pers Brinch Hansen is correct. I enjoy Unix, but it doubtlessly has led to a widespread creative drain among the hacker community. Occasionally there is something like DragonFly BSD, MINIX 3 and to a lesser extent Solaris/illumos which tries to do something more daring (a shame QNX is proprietary), but the Unix architecture entails subscribing to quite a lot of assumptions which imply a level of path dependence. You can see this in the way that OSes which tried to improve on Unix like Spring (which you ostensibly revile -- by the way, is there any way an amateur like me could possibly obtain a copy, or is it lost?), Amoeba and Sprite, failing to gain traction.
- bcantrill 11y ago
  Needs citation: what is this "widespread creative drain among the hacker community" that Unix has somehow induced? (Also, what are the levels of "path dependence" that you're referring to?) To me, the advances in operating systems in the last fifteen years have been deeper than the programmatic abstractions -- ZFS, jails/zones/containers, DTrace, MDB, etc. Unix has inspired these advances, not confined them. Finally, in terms of Spring: I think it's more accurate to describe you as romanticizing it than me as reviling it. As I have outlined for you before[1], I merely ran the beast -- and it was horrific, even when used as intended. It's certainly not lost: I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been. [1] https://news.ycombinator.com/item?id=10138958 https://news.ycombinator.com/item?id=10138958
  - vezzy-fnord 11y ago
    Also, what are the levels of "path dependence" that you're referring to? A process model which makes checkpointing and migration difficult, hierarchical file systems, lack of OS-level typed modules, strict kernel-userspace segmentation, the various flavors of user and group IDs for isolation and privilege segmentation, global namespaces (somewhat minimized these days, but nothing close to a Spring name service or even Plan 9 namespaces), the file interface and the pseudo-file travesty of "special files" (fuck ioctl(2)s), Berkeley sockets, units of execution/threads bound to address spaces/tasks (at least in userspace), no capabilities (modulo bolt-ons like Capsicum which are still experimental), lack of reliable kernel process management and child tracking primitives necessitating supervision schemes, general trend towards monolithic kernel subsystems rather than userland services, lack of reliable messaging IPC mechanism but instead proliferation of many primitive and homegrown solutions, lack of orthogonal persistence, frequent lack of proper metadata indexing/relational querying beyond seeking for byte streams, dynamic linking instead of dynamic binding, lack of network transparency, etc. etc. ZFS, jails/zones/containers, DTrace, MDB, etc. Nothing about those are innovative. You just have an obvious bias for Sun, given your origins. ZFS was an incremental evolution from VxFS and IBM systems. Same for containers, coming from IBM i and possibly earlier. DTrace isn't even necessary on systems with dynamic object introspection. mdb? Seriously? If you consider that one of the great advances in OS research over the past 15 years, may God help OS research. I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been. I will gladly accept that challenge and write an article documenting my experiences. Please give me an email address to contact.
nickpsecurity 11y ago
The paper actually illustrates many advances in OS abstractions and techniques before and after UNIX that was superior to them. There's others outside this paper as well. Many, even on limited systems, smashed it in terms of IPC performance, fault-isolation (esp drivers), concurrency safety + throughput, shared memory support, management, and so on. It was discovered far back that there were limits to how reliable or secure the UNIX API could get when improvements were attempted. Look up UCLA Secure UNIX, LOCK/ix, Trusted Xenix, Mach ports, L4Linux ports, and so on. Outside of isolating a whole OS (i.e. virtualization), they had to change the behavior of and/or eliminate many calls because they had too many negative effects on system state in fault or malicious conditions. This was not true of many alternative architectures that naturally decomposed systems, isolated faults, protected at interfaces, and/or implemented language-based protections. It's just a UNIX + C thing. Let's re-illustrate this economically. MINIX 3 took a few people a few years to get it to a stage where it was quite reliable ("self-healing") as a console OS and easily modified due to architectural choices. How long did it take UNIX/Linux kernels to do that? No, really, because Sun's and Linux's kernels were still crashing on me in the late 1990's plus corrupting my filesystems on occasion. I'm wondering if it took two decades with hundreds of contributors or three decades? Either way, I think the effort vs results says something about their architecture and implementation strategy. Similarly, Oberon was thrown together in a short time with few people while achieving more reliability, consistency, language-oriented protection, and concurrency performance (with AOS vs forking etc). Many examples of systems doing it better with better results across the board. That also directly contradict UNIX model. It never won for superiority: just simple enough to run on the "cheap" hardware back then, open-source, and lots of users already.

vezzy-fnord 11y ago

Pers Brinch Hansen is correct. I enjoy Unix, but it doubtlessly has led to a widespread creative drain among the hacker community. Occasionally there is something like DragonFly BSD, MINIX 3 and to a lesser extent Solaris/illumos which tries to do something more daring (a shame QNX is proprietary), but the Unix architecture entails subscribing to quite a lot of assumptions which imply a level of path dependence. You can see this in the way that OSes which tried to improve on Unix like Spring (which you ostensibly revile -- by the way, is there any way an amateur like me could possibly obtain a copy, or is it lost?), Amoeba and Sprite, failing to gain traction.

bcantrill 11y ago
Needs citation: what is this "widespread creative drain among the hacker community" that Unix has somehow induced? (Also, what are the levels of "path dependence" that you're referring to?) To me, the advances in operating systems in the last fifteen years have been deeper than the programmatic abstractions -- ZFS, jails/zones/containers, DTrace, MDB, etc. Unix has inspired these advances, not confined them. Finally, in terms of Spring: I think it's more accurate to describe you as romanticizing it than me as reviling it. As I have outlined for you before[1], I merely ran the beast -- and it was horrific, even when used as intended. It's certainly not lost: I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been. [1] https://news.ycombinator.com/item?id=10138958 https://news.ycombinator.com/item?id=10138958
- vezzy-fnord 11y ago
  Also, what are the levels of "path dependence" that you're referring to? A process model which makes checkpointing and migration difficult, hierarchical file systems, lack of OS-level typed modules, strict kernel-userspace segmentation, the various flavors of user and group IDs for isolation and privilege segmentation, global namespaces (somewhat minimized these days, but nothing close to a Spring name service or even Plan 9 namespaces), the file interface and the pseudo-file travesty of "special files" (fuck ioctl(2)s), Berkeley sockets, units of execution/threads bound to address spaces/tasks (at least in userspace), no capabilities (modulo bolt-ons like Capsicum which are still experimental), lack of reliable kernel process management and child tracking primitives necessitating supervision schemes, general trend towards monolithic kernel subsystems rather than userland services, lack of reliable messaging IPC mechanism but instead proliferation of many primitive and homegrown solutions, lack of orthogonal persistence, frequent lack of proper metadata indexing/relational querying beyond seeking for byte streams, dynamic linking instead of dynamic binding, lack of network transparency, etc. etc. ZFS, jails/zones/containers, DTrace, MDB, etc. Nothing about those are innovative. You just have an obvious bias for Sun, given your origins. ZFS was an incremental evolution from VxFS and IBM systems. Same for containers, coming from IBM i and possibly earlier. DTrace isn't even necessary on systems with dynamic object introspection. mdb? Seriously? If you consider that one of the great advances in OS research over the past 15 years, may God help OS research. I have a copy in my basement, if no other copy exists, and I would gladly make it available to you if only to force you to see it as it was and not as you wish it to have been. I will gladly accept that challenge and write an article documenting my experiences. Please give me an email address to contact.

nickpsecurity 11y ago

The paper actually illustrates many advances in OS abstractions and techniques before and after UNIX that was superior to them. There's others outside this paper as well. Many, even on limited systems, smashed it in terms of IPC performance, fault-isolation (esp drivers), concurrency safety + throughput, shared memory support, management, and so on. It was discovered far back that there were limits to how reliable or secure the UNIX API could get when improvements were attempted. Look up UCLA Secure UNIX, LOCK/ix, Trusted Xenix, Mach ports, L4Linux ports, and so on. Outside of isolating a whole OS (i.e. virtualization), they had to change the behavior of and/or eliminate many calls because they had too many negative effects on system state in fault or malicious conditions. This was not true of many alternative architectures that naturally decomposed systems, isolated faults, protected at interfaces, and/or implemented language-based protections. It's just a UNIX + C thing. Let's re-illustrate this economically. MINIX 3 took a few people a few years to get it to a stage where it was quite reliable ("self-healing") as a console OS and easily modified due to architectural choices. How long did it take UNIX/Linux kernels to do that? No, really, because Sun's and Linux's kernels were still crashing on me in the late 1990's plus corrupting my filesystems on occasion. I'm wondering if it took two decades with hundreds of contributors or three decades? Either way, I think the effort vs results says something about their architecture and implementation strategy. Similarly, Oberon was thrown together in a short time with few people while achieving more reliability, consistency, language-oriented protection, and concurrency performance (with AOS vs forking etc). Many examples of systems doing it better with better results across the board. That also directly contradict UNIX model. It never won for superiority: just simple enough to run on the "cheap" hardware back then, open-source, and lots of users already.