Truly Understanding the "Unix Philosophy" - Psychology, Philosophy, and Licenses
rocx
When I first joined up with the Nixers, I was a plain Ubuntu user who enjoyed what GNOME 3 brought to the table. Eventually I got converted into using stranger and more minimalist concepts, such as downsizing to a window manager from a full blown graphical shell to learning how to use the Bourne Again shell. Soon I blended in to the likes of many here. Further down the line (like, late 2015), I've become what some would call a heathen as an Emacs user to this "Unix philosophy"; the one I thought I knew back in those terminal days. Now... What exactly is the "Unix philosophy"?

Most people would tout the famous quote "Write programs that do one thing and do it well." attributed to the greybeard Doug McIlroy. This more or less sums up what feels like everyone's understanding of the spirit of Unix. It feels like people take this idea to the extreem by breaking up parts of a program into several more programs, often requiring them to be chained together in a script or pipeline. Such software that go to this extremity is maim and slop, made to be a less sucky scrot(1) and `scrot -s` respectively and the wmutils suite to perform individual functions of a window manager by our own z3bra and dcat.

Why would I call this "extreme"? Maybe I have a false understanding of those words "do", "one", "thing", and "well". I believe that those four words means more than that. It's getting the programmer to ask a question to themselves before they begin their project. What problem am I trying to solve? A program does its best when it has a goal in mind and its options extend the solution to solve the domains of the problem. A program is easier to manager when there isn't constant scope creep threatening to make the problem seem larger than it really is.

Would a window manager do better if it was split up into an individual program per function? Would a screenshooting program do better if the option to select an area of the screen was done separately? Using my ideals, no they would not. A window manager does exactly what it says in the name: it manages windows. A screenshooting program should be able to have the features to make more detailed shooting easy to use or non-existant (and leaving the cropping to an external image editor, an idea also considered part of the Unix way). It's not to say these tools being made external would be strictly harmful.

slop(1) can chain with another program, using the selected area's geometry as arguments. The wmutils can allow some more fine-tuning that a stock window manager cannot. Finding the balance in where things should be included in a tool and things that can be left separate is key. After all, the users of these tools are the ones who dictate how it gets used and they can be used in many unexpected ways a developer cannot fathom.

(To-do: Go into possible explanations of Eric Raymond's seventeen rules of more a more in-depth look at the Unix way.)
venam
With the Unix philosphy in mind you most of the time write software from the bottom up, writing many utilities that does what they are supposed to do and then plying them together.

However, there's a limit to this.

The amount of small units you write should not be overwhelming and too small otherwise your brain just won't handle them and it'll overcomplicate it.

Also, there's a lot more to add to the Unix philosophy than "do one thing and do it well".

There's the everything is a file concept.
There's the modularity and compactness.
With that comes the cooperation between processing, piping and the likes.
There's the textuality and usual formats used, clear, concise, and transparent.
With that comes streaming, and favoring text UI before GUI, the GUI is just a wrapper over it.
There's the social aspect of code and the barrier to development.
With that comes open source and more contribution.
With that also comes the rebel hacking mindset, the internet culture.


There are a lot of standards like POSIX and the single UNIX specification but those are all irrelevant in my mind.

Most BSDs and Linux don't adhere to them, only the proprietary Unices do.

What a Unix-like OS is is more than that, like all big generic concept, it's social first, it's a state of mind.

The Art of Unix Programming by Eric Steven Raymond is a great piece that deals with the definition of what the Unix philosophy and mindset it.

EDIT: I think the bottom up approach of building blocks goes hand in hand with the "don't repeat yourself" rule. If you find yourself writing a piece of software and you know other programmers will use this feature over and over again then make it a module or a separate program.

Also, I've recently read that it's a good approach to always accompany a module with a software implementing the module functions.
pranomostro
DRY is a very important concept in my opinion for the unix philosophy. Never implement a feature twice is exactly what having one single command for it is about. I think it's hard to determine the right size, for example xbps is split into different utilities, while pacman is one single program. But to me, pacman feels right. The chart venam gave for orientation might help, but that is not for sure. There are lots of programs that are a lot bigger and still very simple and clean (the rc shell, the sam text editor, ...).

Also, I am not sure how to think about huge software projects split into lots of small utilities. The git project comes into my mind. It is very complex, very complicated, very flexible and very fast. But is it truly unixy? I fear not.

Then, about the question of text: I've heard people argue that structured information would be much nicer in unix pipes, like windows powershell does with objects. I fear that this would lead to complications, that the parsing of the information would cause more work than it would relieve. But on the other hand I am rreally enjoyed using jq (a json command line processor), which probably means that the text approach is better, because it gives the possibility of using special formats without enforcing them.

I have also come to the conclusion that file servers (in the idea of Plan 9, or like ii or ratox) are a wonderful idea. They allow to interact with running programs in a plug-on manner, without sacrificing any of the unix philosophy.

(11-09-2016, 02:18 AM)venam Wrote: What a Unix-like OS is is more than that, like all big generic concept, it's social first, it's a state of mind.

This is a nice quote. It remands me of 'In the beginning was the command line', where Neal Stephenson remarks that unix could be reimplemented from scratch without any documents because hackers in the world have memorized it, and it is much more a culture than an operating system.
rocx
(11-09-2016, 08:29 AM)pranomostro Wrote: Never implement a feature twice is exactly what having one single command for it is about.

But yet there are many different tools that can more or less do the same thing. For example of including a file in another, you can use cat(1) to concatenate one on top of the other. You can use m4(1) (general text preprocessor) or cpp(1) (C preprocessor) with include() or #include to target where to put it in. Want to include a file in a document? troff(1) has the .so request to source another file in.

Addendum: ESR has a koan on this matter.

(11-09-2016, 02:18 AM)venam Wrote: Most BSDs and Linux don't adhere to them, only the proprietary Unices do.

The difference between a certified POSIX system and a POSIX-compliant system is the fancy certificate.

(11-09-2016, 08:29 AM)pranomostro Wrote: Also, I am not sure how to think about huge software projects split into lots of small utilities. The git project comes into my mind. It is very complex, very complicated, very flexible and very fast. But is it truly unixy? I fear not.

Some projects are just complex by nature. Adhering to the Unix way isn't a strict codex but more as guidelines. If you have to break those guidelines, make sure there's some justification. What is more important is that the Git project has a goal. It does version control and considering its rise (GitHub partially to blame), it does it pretty well.
pranomostro
(11-09-2016, 04:07 PM)rocx Wrote: Some projects are just complex by nature. Adhering to the Unix way isn't a strict codex but more as guidelines. If you have to break those guidelines, make sure there's some justification. What is more important is that the Git project has a goal. It does version control and considering its rise (GitHub partially to blame), it does it pretty well.

Hm. I am not sure if version control is actually that complex. I mean, maybe it's unfair, but in my opinion, git has a lot of accidental complexity in it. Also, it has a lot of features for configuration of output and options like that could be left out.

(11-09-2016, 04:07 PM)rocx Wrote: But yet there are many different tools that can more or less do the same thing. For example of including a file in another, you can use cat(1) to concatenate one on top of the other. You can use m4(1) (general text preprocessor) or cpp(1) (C preprocessor) with include() or #include to target where to put it in. Want to include a file in a document? troff(1) has the .so request to source another file in.

Okay, true. But none of these programs includes one of the others in it's feature set. Or maybe we as humans are not capable enough to find the program that perfectly includes a file in another one, but this is what unix would demand in the end. What would you say about integrating a line-numbering in a pager. Is that 'okay' in the unix philosophy?

Another point comes to my mind. A lot of people claim that X (nodejs (http://blog.izs.me/post/48281998870/unix...and-nodejs, https://www.safaribooksonline.com/blog/2...d-node-js/), vi (some reddit comment I can't find right now) adheres to the unix philosophy. They list then the points of the unix philosophy 'Do one thing and do it well, speak text'. But they are wrong, because of one reason: Their programs are unices, but the rules are for unix programs. Unix is more about integration into an existing unix than about reinventing unix in the form of a javascript runtime application or a text editor. vi is a unix because you can combine it's commands, but you can't use them outside of the vi context.
robotchaos
Not exactly sure where it fits in, but I absolutely adore the documentation provided by most projects in the Unix world. I love being able to --help a program and go searching through manpages for a particular command to find out how to make the program behave in the way I am hoping for. Sometimes, you find out that it can't. Bummer. Add it to the project list of something to do. Or, you find out that there's a few switches that do things you did not know about and now have found a better use for said program. The see also sections of manpages are a good place to check as well. Perhaps there's a program that does what you are looking for. And outside of manpages, half of my bash_history is spent in /usr/share for the various sample files and added documentation.

So I think doing one thing and doing it well lends to this aspect of the unix philosophy because now that the simple program has been perfected, the author can now start focusing on its documentation. Which I greatly appreciate.
pranomostro
(12-09-2016, 01:26 PM)iomonk Wrote: So I think doing one thing and doing it well lends to this aspect of the unix philosophy because now that the simple program has been perfected, the author can now start focusing on its documentation. Which I greatly appreciate.

This. Also see http://250bpm.com/blog:50 for a perfect writeup about why it is important to 'finish' a project.

You have feature-completeness? Good! Now start improving tests, documentation, performance, security, port it to other systems, maintain it! Software is hard enough when it is finished.
jkl
It amazes me that so many people who like the Unix philosophy decided to use Linux instead of an actual Unix, regardless of Linux's tendency to become a bloated monolith (see: systemd). Why is that so?
pranomostro
I guess we all still like systems that offer some modern comfort (like having a webbrowser, driver support, maybe some games then and when) and I guess we're not all enough die-hard unix people to give up all that for a near-perfect system. Although It seems like some people here really like OpenBSD (which is also what I have been looking at for some time).
robotchaos
simple, penguins are better. And kidding aside here, I stay from systemd and the likes on my machines that I have control over.




Members  |  Stats  |  Night Mode  |  Help