What are some Unix design decisions that proved to be wrong or short sighted?

“Short-sighted - users and groups.

It makes sense on a single-host system being shared at a university. It is weak for pretty much any other setting. It acts as a distraction in pretty much every setting where we now use unix: on personal systems, on cloud deployments, in the enterprise. There are constant hassles of aligning users and groups between systems, and ensuring that applications are structured along those lines.

To offer an alternative. We would be in a better place if unix provided some kind of standard process-group sandboxing, along the lines of jails. Permissions would be applied at the jail level rather than the filesystem level. The sandboxes in smart-phone OSs hint at the way.”

I feel this pain in some cloud deployments, but I’ve never thought about the whole users and groups concepts as the core of this issue.

Seriously, see these slides by Rob Pike from his talk in 2001: "The good, the bad and the ugly: the Unix legacy":

http://herpolhode.com/rob/ugly.pdf

Pike writes: "What makes the system good at what it’s good at is also what makes it bad at what it’s bad at. Its strengths are also its weaknesses. A simple example: flat text files. Amazing expressive power, huge convenience, but serious problems in pushing past a prototype level of performance or packaging." And so on, with several other examples.

This was understandable in a time when disk space was scarce, but it causes all kinds of dependency hell when you want to install programs that need different versions of the same library, or when you upgrade one of those libraries and break a bunch of programs.

Plan 9 got this right with static linking a long time ago: https://9p.io/wiki/plan9/why_static/index.html. Sadly this has still not been adopted by major Unixy operating systems. Flatpak and Snap seem promising for isolation of dependencies in Linux without requiring full containerization.

Another concept is a certain separation between users and programmers, in both LispM, Xerox Alto and even Plan9 users can smoothly program their environment easy, so users have the maximum flexibility possible and a usable a effective systems thanks to high level of integration and freedom. As actual comparison try Squeak, few Scheme implementation, Emacs itself with elisp config they are not, of course, integrated and effective like ancient LispM or Alto however demonstrate enough how powerful can be such paradigma.

Last thing the everything is a file that's really limited in unix, well implemented in Plan9. Everything is a file is a super-nice concept, but everything must be really everything.

ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | tail -1 | cut -d: -f2 | awk '{ print $1}')

(grabbed from first SO question I could find)

Text streams were great 40 years ago, but you run into the limitations of what you can do properly with awk and sed pretty quickly.

Passing structured data through pipes using a standard format would have been a universal interface. Text streams are really just a void* pointer. Sure, you have the data, but good luck making sense of it.

I also think that file names should be more constrained. If we didn't have whitespace in file names we could have avoided uncounted hours of people trying to get quoting right.

I want stdio to be fd0 and it to be both readable and writeable. I want it to be socket-like. Read from "stdin", and you read from fd0 and it's a socket. Write to "stdout", and you write to the same fd0. It would simplify child process handling code since you can use one call to `socketpair()` for stdio. Stderr could be implemented on top of the out-of-band stream, and for program-to-program communications on Linux with a domain socket, you can pass file descriptors and discover the PID of your peer.