6 ms·

Unix is great, but it seems like it has killed off a lot of hackers' imaginations. Hell, we haven't even iterated on Unix all that much since System III, not ev

Unix is great, but it seems like it has killed off a lot of hackers' imaginations. Hell, we haven't even iterated on Unix all that much since System III, not even something like Sprite, Spring or Amoeba. "Unix has retarded OS research by 10 years and linux has retarded it by 20." -- Boyd Roberts

dangerlibrary 11y ago
s/retarded/delayed the need for/g -- sed, awk, and their friends.
pjmlp 11y ago
" 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. " -- Rob Pike on his Slashdot interview
- iopq 11y ago
  "That's why I created a language that feels like it was made 30 years ago"
- digi_owl 11y ago
  And a hammer is perhaps as old as humanity.
  - vezzy-fnord 11y ago
    Just because Unix is a hammer doesn't mean you shouldn't use or build jackhammers.
    - digi_owl 11y ago
      Right tool for the job though. And all to often the attitude is that the jackhammer is always better because it is newer.
  - Confusion 11y ago
    The hammer has been reinvented and innovated many times. You don't use a rock strapped to a stick with leather straps, do you?
matt_s 11y ago
I think that is the point of the article above. Is it good enough? What killer feature of an operating system is missing that would take it to another level? And for said killer feature, how will that help normal humans?
- vezzy-fnord 11y ago
  Oh, too many things to list. Orthogonal persistence, seamless process checkpointing, process migration, dynamic binding (like dynamic linking but with unused symbols being deduplicated and freed), a generic name service that lets users define their own mechanisms for resolving names to resources throughout the system (like how directories, environment variables, device nodes are all discrete objects that name references -- imagine redirecting between any arbitrary object type or making your own abstract one) [1], single-system imaging, dynamic code upgrading for every part of the system, process and executable semantics implemented as user-space servers, capability-based security, autorestarting drivers, etc. etc. The thing is that despite them bringing enormous economic benefits when realized in the mainstream, the short-term incentives are aligned to hacking around what's broken instead. [1] https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/nelson.pdf https://www.usenix.org/legacy/publications/library/proceedin...
  - nostrademons 11y ago
    I'm not sure that many of those are a net win for the end-user (where end-user = "grandma"), though. Orthogonal persistence and seamless process checkpointing destroy the "reboot to fix corrupted software" solution, and now that devices can stay in sleep mode for 6 months on a charge, there's very little reason for them. End users don't want to think about names, let alone generic naming services that let them perform more configuration; they want to think in terms of tasks and get them done with a minimum of extraneous details. Dynamic code upgrading loses much of its benefit when users want to be prompted every time an upgrade is ready. Many of these would be big wins for developers. But developers actually have an incentive to make their own job harder, as long as they charge for their skills. Tougher development serves as a barrier to entry for the profession, which increases the wages they can charge. Make an OS so developer-friendly that the end-user can develop and the profession of software engineer would go away...which may not actually be a bad idea in theory, but neither software engineers nor end-users seem to be that keen on it.
ploxiln 11y ago
There was Plan9. But the people who worked on that, who are bitter that nobody uses it, or anything like, or even anything "post unix", don't realize what the killer feature of linux was, which ended "OS research": It was the large body of useful open source and copyleft code. This made it so everyone could stop pouring huge resources into the base OS layer individually, use something that works really quite well (with whatever necessary tweaks since it is open source), and focus on what goes on top. And there's no one extracting rent on this layer. There's no licenses and activations. Nothing of the sort. (You can contract for RHEL, but you can just as easily not.) BSDs came a couple of years after linux, and plan9 was open sourced many years after (and initially under the problematic "lucent public license"). It was way too late. And the innovations to the most basic interfaces of the OS were just not nearly as valuable as the body of open source which was already available for Linux / BSD. Plan9 is like the Concorde - pinnacle of tech/design, nobody uses it. Never had seat-back entertainment. Never had wifi. Maybe a silly metaphor, but it fits the OP. There are still low-level changes these days in Linux and BSDs. Nothing that drastically breaks compatibility of course. But more security boundaries and privilege management (openbsd w/x and aslr stuff, linux seccomp-bpf, freebsd capsicum, containerization), and speed/efficiency measures like sendfile(), epoll() / kqueue(), RCU fs cache lookups, etc.
- vezzy-fnord 11y ago
  There's far, far more than Plan 9. That's only the beginning. Many others iterated heavily on Unix architectures to make them more novel, or started from scratch. John Ousterhout and U.C. Berkeley developed Sprite, which introduced things like checkpointing, live migration, SSI, log-structured file systems and other things. Andy Tanenbaum did Amoeba, which is sadly only remembered for being the platform that birthed Python. Spring was Sun Microsystems' research system, the name service of which brilliantly resolved the problem of "naming things" (I highly recommend you read this paper: https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/nelson.pdf https://www.usenix.org/legacy/publications/library/proceedin...). Unfortunately, Sun barely implemented any of its ideas to Solaris. Just the least interesting ones like the doors IPC mechanism. Never had wifi. Well, it was developed during a different time. It did get wi-fi thanks to 9front, though. linux seccomp-bpf A sandboxing/syscall filtering mechanism. Nothing new there, and its interface is rather leaky, much like Berkeley sockets are. freebsd capsicum This is one of the few legitimately interesting projects going on. Bringing capability-based security on top of fds. I don't know if it'll catch on beyond FreeBSD, though. Google seems to be an early adopter. containerization Nothing that IBM didn't do much better. Docker reeks of opportunism. sendfile(), epoll() / kqueue() sendfile(2) is just a cheap trick that got turned into a syscall: https://groups.google.com/forum/#!msg/golang-nuts/gdp1q6T0DNY/sFaRetnWPWIJ https://groups.google.com/forum/#!msg/golang-nuts/gdp1q6T0DN... epoll(2) isn't anything special, it's a rather convoluted if performant I/O multiplexing mechanism. kqueue(2) is much cleaner designed, at least.

dangerlibrary 11y ago

s/retarded/delayed the need for/g -- sed, awk, and their friends.

pjmlp 11y ago

" 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. " -- Rob Pike on his Slashdot interview

iopq 11y ago
"That's why I created a language that feels like it was made 30 years ago"
digi_owl 11y ago
And a hammer is perhaps as old as humanity.
- vezzy-fnord 11y ago
  Just because Unix is a hammer doesn't mean you shouldn't use or build jackhammers.
  - digi_owl 11y ago
    Right tool for the job though. And all to often the attitude is that the jackhammer is always better because it is newer.
- Confusion 11y ago
  The hammer has been reinvented and innovated many times. You don't use a rock strapped to a stick with leather straps, do you?

matt_s 11y ago

I think that is the point of the article above. Is it good enough? What killer feature of an operating system is missing that would take it to another level? And for said killer feature, how will that help normal humans?

vezzy-fnord 11y ago
Oh, too many things to list. Orthogonal persistence, seamless process checkpointing, process migration, dynamic binding (like dynamic linking but with unused symbols being deduplicated and freed), a generic name service that lets users define their own mechanisms for resolving names to resources throughout the system (like how directories, environment variables, device nodes are all discrete objects that name references -- imagine redirecting between any arbitrary object type or making your own abstract one) [1], single-system imaging, dynamic code upgrading for every part of the system, process and executable semantics implemented as user-space servers, capability-based security, autorestarting drivers, etc. etc. The thing is that despite them bringing enormous economic benefits when realized in the mainstream, the short-term incentives are aligned to hacking around what's broken instead. [1] https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/nelson.pdf https://www.usenix.org/legacy/publications/library/proceedin...
- nostrademons 11y ago
  I'm not sure that many of those are a net win for the end-user (where end-user = "grandma"), though. Orthogonal persistence and seamless process checkpointing destroy the "reboot to fix corrupted software" solution, and now that devices can stay in sleep mode for 6 months on a charge, there's very little reason for them. End users don't want to think about names, let alone generic naming services that let them perform more configuration; they want to think in terms of tasks and get them done with a minimum of extraneous details. Dynamic code upgrading loses much of its benefit when users want to be prompted every time an upgrade is ready. Many of these would be big wins for developers. But developers actually have an incentive to make their own job harder, as long as they charge for their skills. Tougher development serves as a barrier to entry for the profession, which increases the wages they can charge. Make an OS so developer-friendly that the end-user can develop and the profession of software engineer would go away...which may not actually be a bad idea in theory, but neither software engineers nor end-users seem to be that keen on it.

ploxiln 11y ago

There was Plan9. But the people who worked on that, who are bitter that nobody uses it, or anything like, or even anything "post unix", don't realize what the killer feature of linux was, which ended "OS research": It was the large body of useful open source and copyleft code. This made it so everyone could stop pouring huge resources into the base OS layer individually, use something that works really quite well (with whatever necessary tweaks since it is open source), and focus on what goes on top. And there's no one extracting rent on this layer. There's no licenses and activations. Nothing of the sort. (You can contract for RHEL, but you can just as easily not.) BSDs came a couple of years after linux, and plan9 was open sourced many years after (and initially under the problematic "lucent public license"). It was way too late. And the innovations to the most basic interfaces of the OS were just not nearly as valuable as the body of open source which was already available for Linux / BSD. Plan9 is like the Concorde - pinnacle of tech/design, nobody uses it. Never had seat-back entertainment. Never had wifi. Maybe a silly metaphor, but it fits the OP. There are still low-level changes these days in Linux and BSDs. Nothing that drastically breaks compatibility of course. But more security boundaries and privilege management (openbsd w/x and aslr stuff, linux seccomp-bpf, freebsd capsicum, containerization), and speed/efficiency measures like sendfile(), epoll() / kqueue(), RCU fs cache lookups, etc.

vezzy-fnord 11y ago
There's far, far more than Plan 9. That's only the beginning. Many others iterated heavily on Unix architectures to make them more novel, or started from scratch. John Ousterhout and U.C. Berkeley developed Sprite, which introduced things like checkpointing, live migration, SSI, log-structured file systems and other things. Andy Tanenbaum did Amoeba, which is sadly only remembered for being the platform that birthed Python. Spring was Sun Microsystems' research system, the name service of which brilliantly resolved the problem of "naming things" (I highly recommend you read this paper: https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/nelson.pdf https://www.usenix.org/legacy/publications/library/proceedin...). Unfortunately, Sun barely implemented any of its ideas to Solaris. Just the least interesting ones like the doors IPC mechanism. Never had wifi. Well, it was developed during a different time. It did get wi-fi thanks to 9front, though. linux seccomp-bpf A sandboxing/syscall filtering mechanism. Nothing new there, and its interface is rather leaky, much like Berkeley sockets are. freebsd capsicum This is one of the few legitimately interesting projects going on. Bringing capability-based security on top of fds. I don't know if it'll catch on beyond FreeBSD, though. Google seems to be an early adopter. containerization Nothing that IBM didn't do much better. Docker reeks of opportunism. sendfile(), epoll() / kqueue() sendfile(2) is just a cheap trick that got turned into a syscall: https://groups.google.com/forum/#!msg/golang-nuts/gdp1q6T0DNY/sFaRetnWPWIJ https://groups.google.com/forum/#!msg/golang-nuts/gdp1q6T0DN... epoll(2) isn't anything special, it's a rather convoluted if performant I/O multiplexing mechanism. kqueue(2) is much cleaner designed, at least.