3 ms·

I would argue that while Unix the technology is helpful, Unix the idea is now actively harmful. The Unix idea just doesn’t scale well or have the necessary sec

I would argue that while Unix the technology is helpful, Unix the idea is now actively harmful. The Unix idea just doesn’t scale well or have the necessary security. It seems we are more and more going to an idea that is even older than Unix - the mainframe. From fault tolerance to distributed computing to security to memory channels our modern architectures are more resembling mainframes than Unix and that is good. Everything is a file is a very, very leaky abstraction. There are all sorts of issues with latency, cost, atomicity, security, persistence. I feel at this point, that this constant looking back to Unix “purity” is holding us back and closing our mind to new solutions.

chargingmarmot 3y ago
There's a book I like called "Design Rules: The Power of Modularity"; it was written by some business professors in 2000 and is loosely about the industrial organization and the history of IBM's System/360 (the first "modular computer family") and more generally about how modularity enables innovation and growth. They enumerate what they call "modular operators" which are basic ways a system can be changed: * "splitting" a design into modules * "substituting" one module design for another * "augmenting" adding a new module to the system * "excluding" a module from the system * "inverting" to create new design rules * "porting" a module to another system It doesn't matter here whether the modules are functions, computer programs, hardware components, business units, 2 pizza teams, or companies in an industry (Intel, AMD, RAM manufacturers...). Modularity is a core part of the Unix philosophy. Unix itself is an operating system and involves some particular concepts (pipes, files, processes). It seems obvious that the concepts for an operating system (pipes, files) will be less relevant in a different domain (say, web programming). While I agree that maybe the Unix abstractions aren't appropriate for new problems in different domains, I think some parts of the Unix philosophy (i.e. modularity, minimalism, and compositionality) still deserve consideration.
- bmitc 3y ago
  Thanks for the reference to that book. I need to check it out now.
shrubble 3y ago
Have you ever used a mainframe OS like MVS, or the z/OS or earlier versions of it?
galaxyLogic 3y ago
> “purity” is holding us back and closing our mind to new solutions. Maybe. But consider shebang. It means that any program (/script) written in any language known by the system can call any other program written in any other language. That keeps open the option of which laguage should we use for our next module. Right?
- coldtea 3y ago
  That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file). As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external). Linux offers another way anyway: linux_binfmt If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.
  - galaxyLogic 3y ago
    It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program. It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.
    - coldtea 3y ago
      There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary). So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.

chargingmarmot 3y ago

There's a book I like called "Design Rules: The Power of Modularity"; it was written by some business professors in 2000 and is loosely about the industrial organization and the history of IBM's System/360 (the first "modular computer family") and more generally about how modularity enables innovation and growth. They enumerate what they call "modular operators" which are basic ways a system can be changed: * "splitting" a design into modules * "substituting" one module design for another * "augmenting" adding a new module to the system * "excluding" a module from the system * "inverting" to create new design rules * "porting" a module to another system It doesn't matter here whether the modules are functions, computer programs, hardware components, business units, 2 pizza teams, or companies in an industry (Intel, AMD, RAM manufacturers...). Modularity is a core part of the Unix philosophy. Unix itself is an operating system and involves some particular concepts (pipes, files, processes). It seems obvious that the concepts for an operating system (pipes, files) will be less relevant in a different domain (say, web programming). While I agree that maybe the Unix abstractions aren't appropriate for new problems in different domains, I think some parts of the Unix philosophy (i.e. modularity, minimalism, and compositionality) still deserve consideration.

bmitc 3y ago
Thanks for the reference to that book. I need to check it out now.

shrubble 3y ago

Have you ever used a mainframe OS like MVS, or the z/OS or earlier versions of it?

galaxyLogic 3y ago

> “purity” is holding us back and closing our mind to new solutions. Maybe. But consider shebang. It means that any program (/script) written in any language known by the system can call any other program written in any other language. That keeps open the option of which laguage should we use for our next module. Right?

coldtea 3y ago
That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file). As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external). Linux offers another way anyway: linux_binfmt If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.
- galaxyLogic 3y ago
  It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program. It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.
  - coldtea 3y ago
    There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary). So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.