3 ms·
> systemd at it's core is very much adhering to UNIX principles. Speaking only for myself and every Unix developer and system administrator I have ever met: N
by AdieuToLogic 7y ago
> systemd at it's core is very much adhering to UNIX principles.
Speaking only for myself and every Unix developer and system administrator I have ever met:
No, systemd in no way, shape, or form adheres to well known Unix prinicples.
- oblio 7y agoUnix itself doesn't adhere to Unix principles. The Unix philosophy died when ls learned to sort its output and find learned to execute commands. Perl, the do-all tool, was the final nail in the Unix philosophy, way back in the 80's.
- AdieuToLogic 7y ago> Unix itself doesn't adhere to Unix principles. Principles != dogma. > The Unix philosophy died when ls learned to sort its output and find learned to execute commands. As for "find", I leave the explanation of it to this[0] recounting. Suffice to say that one command doth not a philosophy make. Regarding "ls learned to sort", let's put this trope to rest, shall we? The 'ls' command, as I am sure you and all whom read this posting are aware, is described[1] as: NAME ls -- list directory contents Now there are many command options which have been added to 'ls' over the decades, no doubt. But you partially identified the death of "The Unix philosophy" as being "when ls learned to sort," so let's focus on that. The implication of that assessment, in this context, I assume to be a reference to "do one thing and do it well."[2] Which begs the question; what is the one thing which 'ls' must do? Given the summary description quoted above, that "one thing" is: list directory contents This leaves the remaining conjunctive clause of "do it well." Since the operation of 'ls' includes both filtering and production due to the functional requirement of having to "list directory contents", there exists two disjoint concerns which must be addressed in order to satisfy the goal of "do it well." For example, an invocation can involve identifying C source files ("*.[ch]"), yet want the production of the files which match based on when each file was last modified ("-c"). To achieve sorting on the modification time using another program, such as sort[3], would require 'ls' produce both the desired output as well as out-of-band information needed to sort[3]. This also implies that the desired sorting (such as numeric or lexiographic) must be provided out-of-band as well. And this, too, would imply that sort[3] is made aware of what/where the out-of-band data can be found. All of this leads to a "Leaky Abstraction."[4] Instead, if one identifies the functional requirement of 'ls' to treat both filtering and production as coequal concerns when listing directory contents, the need for 'ls' to "learn to sort" becomes self-evident. 0 - http://doc.cat-v.org/unix/find-history http://doc.cat-v.org/unix/find-history 1 - https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sekti... 2 - https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a... 3 - https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=0&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sek... 4 - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...