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.)

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.

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.

(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.

(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.

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.

(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.

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?

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).

simple, penguins are better. And kidding aside here, I stay from systemd and the likes on my machines that I have control over.

(13-09-2016, 04:12 PM)pranomostro Wrote: I guess we're not all enough die-hard unix people to give up all that for a near-perfect system.

Who said Unix can't do that?

(13-09-2016, 03:43 PM)jkl Wrote: 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?

(11-09-2016, 04:07 PM)rocx Wrote:

Quote: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.

The only true Unix are the proprietary ones:

• AIX
  
• HP-UX
  
• Inspur K-UX
  
• OS X
  
• Solaris
  
• z/OS
  

But you'd be suprised how not Unixy they feel to most people and how stuck you can feel using those systems.
Most of those proprietary Unix certified systems barely do anything to keep the Unix-philosophy alive.

As previously mentioned, the Unix-philosophy isn't about the standards, it's about culture.
And if you think the BSDs are more "unixy" than Linux based OSs you might be in part wrong.

(11-09-2016, 08:29 AM)pranomostro Wrote:

Quote: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.

(13-09-2016, 03:43 PM)jkl Wrote: 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?

UNIX was on its way out the door even in the '90s; the folks at Bell Labs thought they were making the future of it by making the famed (amongst us) Plan 9. Even they knew UNIX had its flaws and were on the project to fix them. Besides that and proprietary UNIX systems, there isn't much of anything now unless you'd consider *BSD a "real Unix".

There's also GNU to praise/blame (depending on your outlook of free software and/or GNU's rather dismal code quality) for the rise of Linux. Perhaps we're better off with it rising than if it didn't. Who knows?

tl;dr People want things that work and do the things they want. That's why they're many who even acknowledge the choice in operating systems still stick with Windows in the first place.

I'm not stuck with Windows, I just prefer my Windows workflow over any other workflow. and no, I don't think GNU should be "praised". Without GNU (the "alternative to Unix"), Unix would probably not have fallen all the way down.

Indeed, OS X does not feel "unixy" at all, neither in terms of usability nor in terms of general system reliability. To be fair, OS X is very little unixy as of today, with all its weird GNUisms having been added over the years. Yes, Unix is proprietary, it always has been - so? Does that mean it's worse? It's actually better: If an operating system is sold for (a lot of) money, see AIX, chances are that its developing company will invest quite much effort to keep it going.

Linux has such a bad overall quality because no one really cares as it's free. They don't need to make sure that the sales will be steady over the next years because there are no sales.

Have you ever thought about why Microsoft hires security specialists to harden their Windows? Because Windows's quality is tied to actual money while Linux companies mainly make money with support, installation and other trivial things.

(13-09-2016, 04:27 PM)jkl Wrote:

Quote:I guess we're not all enough die-hard unix people to give up all that for a near-perfect system.

Who said Unix can't do that?

It maybe can, and probably even better, but my experience shows that the suckiness of a system correlates with general support (software support, web-browsers, games, drivers).

(13-09-2016, 04:28 PM)venam Wrote: But you'd be suprised how not Unixy they feel to most people and how stuck you can feel using those systems.
Most of those proprietary Unix certified systems barely do anything to keep the Unix-philosophy alive.

As previously mentioned, the Unix-philosophy isn't about the standards, it's about culture.
And if you think the BSDs are more "unixy" than Linux based OSs you might be in part wrong.

Interesting. I thought the BSDs were certified systems as well. But okay, I care more about where the food is on my plate than about the question whether or not my system is a certified unix. I mean, nobody needs a fortran compiler, amirite?

(13-09-2016, 08:18 PM)rocx Wrote: There's also GNU to praise/blame (depending on your outlook of free software and/or GNU's rather dismal code quality) for the rise of Linux. Perhaps we're better off with it rising than if it didn't. Who knows?

I think we wouldn't be better off. If you perceive them as a political movement and not a technological one, they have done great work, spreading the idea of freedom of information, convincing the BSD guys to go open source, and establishing the four laws of free software. Technologically, I don't think we would be off better, I am convinced that at all points in time, 90% (95%?) of all software was shitty.

(13-09-2016, 08:18 PM)rocx Wrote: Even they knew UNIX had its flaws and were on the project to fix them.

Right. They saw the flaws and attempted to fix them, beginning of the 90's. Now, how outdated is unix today? How many unfixed warts are left? What could be improved?

(14-09-2016, 07:18 AM)pranomostro Wrote: I thought the BSDs were certified systems as well.

Usually, SysV systems have a better chance to be a "certified UNIX". BSD has come a long way since their first Unix distribution.

(14-09-2016, 07:18 AM)pranomostro Wrote: I mean, nobody needs a fortran compiler, amirite?

Wrong. I even need a COBOL compiler. (OK, I don't. But it's nice to have one at hand.)

(14-09-2016, 07:18 AM)pranomostro Wrote: If you perceive them as a political movement and not a technological one, they have done great work

Oh yes, replacing the Public Domain (as it was common in the 60s: just share your tapes) by a long text about what you are not allowed to do. Awesome.
There are reasons why I try to avoid using GPL software at all.

(14-09-2016, 07:18 AM)pranomostro Wrote: convincing the BSD guys to go open source

BSD was "open source" from the beginning. Unix was not. (That's why the early 90s were seeing the first "free BSD": The non-free code parts by AT&T had to be rewritten first.)

(14-09-2016, 07:24 AM)jkl Wrote: BSD was "open source" from the beginning. Unix was not. (That's why the early 90s were seeing the first "free BSD": The non-free code parts by AT&T had to be rewritten first.)

Actually, that's not totally accurate.
Most softwares of the time were distributed with their source code as a license, Unix is no different.
It was shipped as a big package of self contained environment for programming, documentation, source code, etc..

It's when the proprietary train started that what you mention happened.

Again, the idea was to have an open environment for development, research, and education, that is easy to grasp and cheap.

The commercial certified Unix of today don't achieve this.
They certainly have the title of Unix but not the philosophy and spirit of the communal operating system people get around to hack with.

Now the definition itself depends on your view of the matter.

The "spirit" of an "operating system people get around to hack with" was never a part of what Unix tried to provide. Just because it was possible for a short while, it was not automatically planned this way.

(14-09-2016, 08:15 AM)jkl Wrote: The "spirit" of an "operating system people get around to hack with" was never a part of what Unix tried to provide. Just because it was possible for a short while, it was not automatically planned this way.

I quote Dennis Ritchie's vision of Unix:

Quote:What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.

Interesting quote, but I honestly doubt that Ritchie had talked to Thompson about this before making it. Just like C, Unix was not there to please as many people as possible but to work on what hardware was there.

(14-09-2016, 08:26 AM)jkl Wrote: Interesting quote, but I honestly doubt that Ritchie had talked to Thompson about this before making it. Just like C, Unix was not there to please as many people as possible but to work on what hardware was there.

And you are absolutely right about that.
Ken Thompson doesn't have the same view that Dennis had on the contribution and openness matter.

But that doesn't mean it's necessarily wrong, those are just two sides of the same coin.

for what it's worth i'm pro unix philosophy and pro minimalism.

back in the day (when i used and abused windows) i was a software horder. i prided myself on always having the newest and greatest versions of everything. even if i never used or even installed them. if i needed to do mechanical drawing i had the latest autocad ready to go. if i wanted to do sound engineering i had reaper, reason, abelton, etc, etc, etc... it got so bad that i joined multiple scene release groups just so i had quicker 0day access to warez. the whole thing was based on the fact i didnt want to pay for anything.

i had used linux some as a kid, and again in networking classes early in my university career, but never gave it much stock. eventually the windows world got to be too much for me. i spent more time removing and editing parts of the os than really using it. and hording all the crap wasnt doing me much good either (beyond scene cred and ridiculous torrent ratios). not sure how i got there, but one day i found myself reading about the roots of unix, free and open software, designing things with simplicity in mind. the phrase "do one thing, and do it well" then just chain multiple simple programs together to make more complex use cases really struck a cord with me.

i distro hopped for a few months checking things out. trying DEs and WMs alike, seeing how each distribution was configured. but it wasnt until crunchbang really showed me what i needed to see that it clicked. if you dont know #! was just a minimal debian net install with openbox and a few xfce4 tools put together to makeup a simple system. i realized they picked a component to do each thing: openbox for wm management, tint2 for a dock and tray, networkmanager + nm-applet for networking configs, nitrogen for wallpapers, etc, etc, etc... now over time i really learned to hate most of these applications (i'm looking at you openbox and network manager) but i finally got what it was to take a minimal system and craft it exactly the way you wanted.

at the end of my windows career git was brand new. and i was eager to replace svn with something better. i started using a pseudo-shell called mingw, with emulated bash in many ways. so when i switched to linux i was enthralled by the terminal. the totem of "write programs to handle text streams, because that is a universal interface" became my mantra. i tried to forsake gui applications as much as possible and focus my efforts on a shell based workflow. and minus a few applications like a web-browser, image viewer and editor, i think i've gotten pretty close. and even those, i often use tools like imagemagick from the terminal for simple edits (cropping, resizing, etc) and curl in combination with grep/sed to pull out the parts of a website i want.

this is about the time i learned about nixers. jmbi taught me the difference between ricing (visually appealing tweaks to you system) and beaning (tuning how the system worked under the hook for performance and workflow). now when i design a system i try and think about the things i'm actually going to do with it, and let that define my workflow, not the possibility of something. if i need to do something new, i'll just research it and decided what the best tool for the job is when that arises. that's applied unix philosophy, in my mind at least.

(27-09-2016, 12:43 PM)xero Wrote: i started using a pseudo-shell call mingw

You started a project called mingw? Nice coincidence.

(27-09-2016, 12:43 PM)xero Wrote: the totem of "write programs to handle text streams, because that is a universal interface" became my mantra.

I should start meditating.

'Do one thing and do it well. Write programs to handle text streams, because that is a universal interface.' repeated over and over again.

In the past I'm also the warez guy (All category downloaded and uploaded almost 0day)
After the day has come this pointless activity went to linux and still like it not cracked & wrecked my system anymore.
My computer is not very mainstream therefore not use any DE. First ricer desktop with dwm, after short period in awesome, bspwm and now the herbstluftwm.

"Warez" are an important part of Unix's history. Without "warez" it would never have been so successful in its early days.

Granted,licensing was different back in the days.

Oh! That's for some people a heated topic because they take it to heart in an emotional way.
In sync with our book club, reading The Unix Programming Environment, I think it's good to revisit this topic of understanding the Unix philosophy and how it was derailed quite profoundly over the years, maybe even over-interpreted like ancien scripture text that people would take literally.

So, what's your take on this?