Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "Is The Unix Philosophy Still Important?" video.

  1. One of the key things I learned from my CS courses is abstraction and layering. You start with the bare hardware, which is the most general machine possible because it hasn’t been specialized in any way. You put down the first layer of programming, which creates a new “abstract machine” that is better suited to some purpose you have in mind, but is likely less suited to something that someone else may have in mind. Then another layer on top of that, and so on. And every stage, each layer is replaceable and can be substituted with something else. For example, you get to the layer of the command-line shell, which can do a range of things. You can customize it by writing a shell script, which performs some function that is useful to you. But once you get to the GUI layer, that’s the end of all your abstractions. That’s because the GUI layer cannot be automated. So you cannot build any more “abstract machines” on top of it. It is designed to be directly controlled by humans, and that’s it.
    13
  2. Some GUI applications, particularly open-source ones, are an exception to the “inflexible monolith” paradigm. A good example is Blender, the 3D modelling/animation/rendering app. Look at the Python API for extending its functionality, which is breathtakingly comprehensive -- probably more so than any other, and includes its own purpose-built high-level GUI toolkit. Plus the fact that you can run it in batch mode (with its GUI disabled), and feed it Python code to execute, makes it very versatile for workflow automation.
    5
  3. GNOME is easily the most bloated UI out there. And yet it is the least flexible. They keep chopping and changing things around between versions, to the great annoyance of many users. As far as GUI apps are concerned, I think the Unix philosophy stops at the display server. Because that’s as far as you can go with “mechanism, not policy”. Everything above that is specific to some particular policy, it isn’t just mechanism any more.
    2
  4. 1:10 The problem with “do one thing and do it well” is that such simple examples inevitably have to build on much larger and more complex underlying layers. For example, does any command-line shell “do one thing and do it well”? Does X11 “do one thing and do it well”? Does the Linux kernel “do one thing and do it well”? What about glibc, the good old C runtime library, that just about every userland program depends on? I would say that none of these things fits that paradigm. But they all enable the creation of pieces on top of them that do. This applies to systemd as well. Writing a systemd service file is typically so much simpler than all the boilerplate you need to include in an old-style sysvinit script. That’s why it’s worth using.
    1
  5.  @accountid9681  Mechanism, not policy.
    1