5 ms·

Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files.

Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files. Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or output for other programs to map against and write into / consume?

overgard 5y ago
I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.
- mjevans 5y ago
  Simplicity is a good baseline. In Unix systems, off the cuff scripting works really well for live human interaction. Complexity, particularly NOT-self-documenting complexity, becomes a nightmare. Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. Reflection of supported interfaces becomes easy. It integrates with existing software, and it's self documenting for both software and users. Complexity can be opt-in rather than the only way to operate.
  - vbezhenar 5y ago
    > Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. That's API. Users will depend on it. So now you either have to freeze your code or break users flows.
  - comex 5y ago
    > Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. This is basically how Plan 9 works (or so I’ve heard).
- AnthonyMouse 5y ago
  "The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem." - Claude Shannon, A Mathematical Theory of Communication Everything is inherently a stream of bytes. You can use programs that interpret them as typed data or newline or null-delimited arrays all you like.
  - rocqua 5y ago
    Thing is, without a build in (good) way to do e.g. array types, every program will roll their own. That is lots of duplicate work, and makes having programs interact a manual process of integrating 2 unspecified ad-hoc standards. Programming languages create idioms and standard ways to do things. We judge those for their clarity and quality. On that front UNIXs "you get a stream if bytes, do what you want" leads to a fragmented world of low quality idioms. And hence gets judged poorly.
    - AnthonyMouse 5y ago
      Except that there are standard ways of doing arrays. Newline terminated is the most common, null-terminated is used for data that could have unusual characters in it, and most of the standard utilities support both. The problem with not doing this is that the operating system is imposing some arbitrary standard on data that may not have even come from the same system. If the data you get is JSON, there are utilities for parsing JSON. If it's XML, there are utilities for parsing XML. It could be a PDF and you want to convert each page to a TIFF and then tar them into an archive. The file came over the internet; it doesn't care about your system's encoding defaults.
      - iainmerrick 5y ago
        There are standard ways of doing arrays Is that why 80% (at a guess) of shell scripts don’t handle spaces in file names correctly?
- strictfp 5y ago
  Having tried many techniques for program-to-program interfacing, I must say that text still is the lingua franca, and I think it's the best "non-standard" to set.
- pjmlp 5y ago
  Even in the 70's it wasn't that great, Powershell "novelty" was a standard way of working across Interlisp-D, Smalltalk, XDE/Mesa and Mesa/Cedar at Xerox.
ZealousIdeal 5y ago
I enjoyed Benno Rice's talk, "What UNIX Cost Us". I think he provides some examples of where the simple interface breaks down when compared to other systems (i.e. Windows, macOS) take on it.
lavabiopsy 5y ago
>Unix generally has the correct basis for the design. I can't disagree with this more, Unix is broken in so many ways and its designs continuously cause me pain. I would not describe a modern Linux or BSD as "simple", maybe the core of it is, but to actually build a modern OS there are so many layers on top of it. And when you do that, the crumminess of the foundation really starts to stand out.
hvasilev 5y ago
This was correct in the 1980s, it is definitely not correct today.

overgard 5y ago

I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.

mjevans 5y ago
Simplicity is a good baseline. In Unix systems, off the cuff scripting works really well for live human interaction. Complexity, particularly NOT-self-documenting complexity, becomes a nightmare. Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. Reflection of supported interfaces becomes easy. It integrates with existing software, and it's self documenting for both software and users. Complexity can be opt-in rather than the only way to operate.
- vbezhenar 5y ago
  > Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. That's API. Users will depend on it. So now you either have to freeze your code or break users flows.
- comex 5y ago
  > Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. This is basically how Plan 9 works (or so I’ve heard).
AnthonyMouse 5y ago
"The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem." - Claude Shannon, A Mathematical Theory of Communication Everything is inherently a stream of bytes. You can use programs that interpret them as typed data or newline or null-delimited arrays all you like.
- rocqua 5y ago
  Thing is, without a build in (good) way to do e.g. array types, every program will roll their own. That is lots of duplicate work, and makes having programs interact a manual process of integrating 2 unspecified ad-hoc standards. Programming languages create idioms and standard ways to do things. We judge those for their clarity and quality. On that front UNIXs "you get a stream if bytes, do what you want" leads to a fragmented world of low quality idioms. And hence gets judged poorly.
  - AnthonyMouse 5y ago
    Except that there are standard ways of doing arrays. Newline terminated is the most common, null-terminated is used for data that could have unusual characters in it, and most of the standard utilities support both. The problem with not doing this is that the operating system is imposing some arbitrary standard on data that may not have even come from the same system. If the data you get is JSON, there are utilities for parsing JSON. If it's XML, there are utilities for parsing XML. It could be a PDF and you want to convert each page to a TIFF and then tar them into an archive. The file came over the internet; it doesn't care about your system's encoding defaults.
    - iainmerrick 5y ago
      There are standard ways of doing arrays Is that why 80% (at a guess) of shell scripts don’t handle spaces in file names correctly?
strictfp 5y ago
Having tried many techniques for program-to-program interfacing, I must say that text still is the lingua franca, and I think it's the best "non-standard" to set.
pjmlp 5y ago
Even in the 70's it wasn't that great, Powershell "novelty" was a standard way of working across Interlisp-D, Smalltalk, XDE/Mesa and Mesa/Cedar at Xerox.

ZealousIdeal 5y ago

I enjoyed Benno Rice's talk, "What UNIX Cost Us". I think he provides some examples of where the simple interface breaks down when compared to other systems (i.e. Windows, macOS) take on it.

lavabiopsy 5y ago

>Unix generally has the correct basis for the design. I can't disagree with this more, Unix is broken in so many ways and its designs continuously cause me pain. I would not describe a modern Linux or BSD as "simple", maybe the core of it is, but to actually build a modern OS there are so many layers on top of it. And when you do that, the crumminess of the foundation really starts to stand out.

hvasilev 5y ago

This was correct in the 1980s, it is definitely not correct today.