It's not true that computers are not shared anymore. At my university there is a computer pool for all the students to use running linux. Each user has it's own desktop and home directory. Everybody can use any computer, and I do not need to bring my laptop from home anymore.
There's really nothing stopping you from making a "shell" exactly like you describe for current UNIX systems. There's also nothing stopping you from making a distro with just two privilege levels. Separate filespaces are also very much possible on Linux (containers). A request/response IPC that starts up programs is what systemd can do. Configuration in the form of a registry is also implemented on various systems. Of course, what you then and up with is a platform within a platform, and we already have many of those. That is part of why systems are such a mess. The GTK people have their ways of doing things, we have a variety of IPC mechanisms running alongside each other, we have various authorization protocols in place, etc. Most of what you describe as solutions are really just conventions you want to see. You can't expect everyone to follow your choices and limit everyone from making different choices. This reminds me of the old "we have both standard A and standard B in place, so we're making standard C to create a unified standard."
A really good talk. I don't necessarily agree with everything but its a good perspective and raises some really pressing questions, ones we should ask more.
Had some decent ideas at the start but this is dangerously inadequate from a security perspective. Any replacement should have more security controls not less. Actually I would go so far as to say that a new system should be built with security as the core concern with multiple measures at each level to bring it beyond any other system. User and file permissions is a weak and outdated method to place any trust in and causes all kinds of issues but the service they provide should not be discarded. A lot more should be added to a system beyond this. A registry is also particularly bad from a security standpoint since it is by nature a shared space. To adequately isolate programs from each other you wind up putting up walls that defeat the purpose of the registry. Or you just let any program have free reign to do whatever it likes to everything in your system.
I think that the dichotomy of "admin software" vs "not-admin software" being your only method of permissions is a bad idea for security reasons, for the same reason that setuid root programs in Unix are encouraged to drop root privileges as soon as possible; you want software to have the least amount of permissions for the least amount of time, so that the impact of vulnerabilities in the software is minimized.
Brian you are wrong, we cannot abandon the entire concept of a shell, and replace it with a general purpose language. You need a way to quickly interact with a running system, and some form of shell is an ideal answer. What we actually need is a modern widely available OS built on a micro-kernal with clean lew level IPC mechanisms,... so basically FuschiaOS, then we can iterate on user-land concepts, without trashing performance or ignoring driver and platform complexity.
Terry Davis addressed some of these ideas in TempleOS. His shell runs C code interactively. He also argued that Linux is way too complex for single-user machines, saying that Unix-like is an 18 wheeler and all he needs is a dirt bike.
I've complained about gratuitous complexity since at least 1993. The universal response is that I'm too stupid to grasp what's necessary, clearly, and should probably revert to being a tester-or-something. Yet, somehow, I delivered over 20 shrink-wrapped projects ( when that was a thing ) on five different architectures before delving into web programming in 2005.
I find it interesting that most cloud infrastructure really attempt to implement most of the proposal presented here (on top of current tech) and, for security or organization, we build all the stuff the proposal attempts to remove right back on top of the platform that doesn't have them. To me this suggests most of the pain may just be what security requires. Concretely, UNIX and other referenced initial platforms were typically developed in the absence of security and security was attached somewhat ad hoc through the years. For a proposal like this to truly work security must be worked in from the beginning. Trying to remove all those hairy parts does not bring in security. You're not just protecting against local users (who really should be protected from one another otherwise a non-administrative user can corrupt an administrative user intentionally or unintentionally and you get disaster). Minimizing the affected scope of breach is a good starting point but communication is key. We need communication for effectiveness but we must restrict it for security and stability. Finding that balance is tough no matter what the underlying platform looks like.
Regarding protecting users from each other, you say it almost never happens that strangers share a computer, but what about public libraries or computer labs at universities where students have unix accounts accessible from any machine on the lab?
Anyone championing a reduction of all the accidental, corrupting, pointless and often insane complexity in modern IT, gets my vote. Unfortunately, this complexity sells consultancy hours, days and months... it keeps most people in their cosy jobs. It's also a power trip for most: those who understand the nonsense complexity have (lots of) power over those who do not. "Trust me, I'm a doctor" (and my invoice is in the post)
what are your thoughts on NixOS? Seems like Nix really tried to do this exact thing, with the added feature of utilizing immutable data structures on top
I can't say I agree with everything here, especially the idea of dispensing with user-level protections from other users. Its important to remember that users represent separations of concern, not just human users. Ex: a mysql user or a www user. I'm also not convinced on the registry store as being better than /etc or keeping config files in a individual user's namespace in plaintext files. I think the points about package management are the strongest here.
![THE TOYS x NONT TANONT - ดอกไม้ที่รอฝน (spring) [Official MV]](http://i.ytimg.com/vi/pPa1d5cC8M4/mqdefault.jpg)
It's not true that computers are not shared anymore. At my university there is a computer pool for all the students to use running linux. Each user has it's own desktop and home directory. Everybody can use any computer, and I do not need to bring my laptop from home anymore.
There's really nothing stopping you from making a "shell" exactly like you describe for current UNIX systems. There's also nothing stopping you from making a distro with just two privilege levels. Separate filespaces are also very much possible on Linux (containers). A request/response IPC that starts up programs is what systemd can do. Configuration in the form of a registry is also implemented on various systems. Of course, what you then and up with is a platform within a platform, and we already have many of those. That is part of why systems are such a mess. The GTK people have their ways of doing things, we have a variety of IPC mechanisms running alongside each other, we have various authorization protocols in place, etc. Most of what you describe as solutions are really just conventions you want to see. You can't expect everyone to follow your choices and limit everyone from making different choices. This reminds me of the old "we have both standard A and standard B in place, so we're making standard C to create a unified standard."
A really good talk. I don't necessarily agree with everything but its a good perspective and raises some really pressing questions, ones we should ask more.
The straightforward solution to the majority of package management issues is to statically compile our programs
All shells should be replaced with the LISP REPL.
Had some decent ideas at the start but this is dangerously inadequate from a security perspective. Any replacement should have more security controls not less. Actually I would go so far as to say that a new system should be built with security as the core concern with multiple measures at each level to bring it beyond any other system. User and file permissions is a weak and outdated method to place any trust in and causes all kinds of issues but the service they provide should not be discarded. A lot more should be added to a system beyond this. A registry is also particularly bad from a security standpoint since it is by nature a shared space. To adequately isolate programs from each other you wind up putting up walls that defeat the purpose of the registry. Or you just let any program have free reign to do whatever it likes to everything in your system.
Have you seen NixOS?
I think that the dichotomy of "admin software" vs "not-admin software" being your only method of permissions is a bad idea for security reasons, for the same reason that setuid root programs in Unix are encouraged to drop root privileges as soon as possible; you want software to have the least amount of permissions for the least amount of time, so that the impact of vulnerabilities in the software is minimized.
Brian you are wrong, we cannot abandon the entire concept of a shell, and replace it with a general purpose language. You need a way to quickly interact with a running system, and some form of shell is an ideal answer. What we actually need is a modern widely available OS built on a micro-kernal with clean lew level IPC mechanisms,... so basically FuschiaOS, then we can iterate on user-land concepts, without trashing performance or ignoring driver and platform complexity.
Python can be used instead of bash. But it is not, because bash is still the lesser evil for this job.
Terry Davis addressed some of these ideas in TempleOS. His shell runs C code interactively. He also argued that Linux is way too complex for single-user machines, saying that Unix-like is an 18 wheeler and all he needs is a dirt bike.
I've complained about gratuitous complexity since at least 1993. The universal response is that I'm too stupid to grasp what's necessary, clearly, and should probably revert to being a tester-or-something. Yet, somehow, I delivered over 20 shrink-wrapped projects ( when that was a thing ) on five different architectures before delving into web programming in 2005.
"The notion of strangers sharing the same machine is outdated, that doesn't actually happen"... yeah right, what about fucking servers?!?
When you're working with someone over the phone and you ask them to type:
>systemd is good
I find it interesting that most cloud infrastructure really attempt to implement most of the proposal presented here (on top of current tech) and, for security or organization, we build all the stuff the proposal attempts to remove right back on top of the platform that doesn't have them. To me this suggests most of the pain may just be what security requires. Concretely, UNIX and other referenced initial platforms were typically developed in the absence of security and security was attached somewhat ad hoc through the years. For a proposal like this to truly work security must be worked in from the beginning. Trying to remove all those hairy parts does not bring in security. You're not just protecting against local users (who really should be protected from one another otherwise a non-administrative user can corrupt an administrative user intentionally or unintentionally and you get disaster). Minimizing the affected scope of breach is a good starting point but communication is key. We need communication for effectiveness but we must restrict it for security and stability. Finding that balance is tough no matter what the underlying platform looks like.
Regarding protecting users from each other, you say it almost never happens that strangers share a computer, but what about public libraries or computer labs at universities where students have unix accounts accessible from any machine on the lab?
Anyone championing a reduction of all the accidental, corrupting, pointless and often insane complexity in modern IT, gets my vote. Unfortunately, this complexity sells consultancy hours, days and months... it keeps most people in their cosy jobs. It's also a power trip for most: those who understand the nonsense complexity have (lots of) power over those who do not. "Trust me, I'm a doctor" (and my invoice is in the post)
what are your thoughts on NixOS? Seems like Nix really tried to do this exact thing, with the added feature of utilizing immutable data structures on top
I can't say I agree with everything here, especially the idea of dispensing with user-level protections from other users. Its important to remember that users represent separations of concern, not just human users. Ex: a mysql user or a www user. I'm also not convinced on the registry store as being better than /etc or keeping config files in a individual user's namespace in plaintext files. I think the points about package management are the strongest here.