Debate on the UNIX Philosophy
(:toc:)
Click to add your perspective to this debate.
!Opinion: Suckless
[[http://suckless.org/philosophy/]]
!Opinion: Small Technology
[[https://small-tech.org/about/#small-technology]]
!Opinion: Trivial Technology
[[https://trivial.technology/]]
Differences from UNIX Philosophy:
-
{-Use the original implementation and push any changes upstream-}
-
{+Modify your copy of the original implementatoin for yourself without combining upstream+}
Differences from Small Technology:
but, I'd say the principal difference, from which all other differences come, is the attitude towards centralization
TT is public domain as much as possible, there is no master branch, there is no original author, because you don't have to send changes back, the original repo does not become a feature pinata
Differences from Suckless:
they use similar language, but the intent is opposite. when they say simple, they mean "that which I am habituated to", they pre-suppose familiarity with C (of all things), and use the "worse is better" approach to simplicity. TT, instead, focuses on the cognitive aspects of simplicity, and is not centric to any language or ecosystem, but rather the tools provided for people to understand what is going on, as well as a design philosophy that allows modifications to flow from that understanding naturally
Things the reader must understand:
-
the code itself
-
the APIs the code calls (e.g deps), including the possible side-effects of the APIs
-
the license (making CC0 significantly worse than, say, 0BSD)
-
any meta-work required (such as how the build system works, the sources of the build stuff, etc)
Things the reader does not need to understand:
-
internal implementation details of the deps
-
the platform upon which things run (e.g how linux works internally, otherwise we have a recursion problem)
!Counterpoint: Trivial Technology
[[https://trivial.technology/]]
-
project upstream is a source of trust, lack of that fosters malicious forks
-
permissive licences fail to protect user-rights
-
makes dependency management/dynamic linking next to impossible (mind a major proponent behind the current static linking trend is google)
-
trivial interfaces often require complex implementaions (eg. secure crypto, fast databses, reliable networking, ... are by nature not trivial)
!Opinion: Techs Should Factor: Programs should work well together; but the rest is extraneous
[[users.category_mirrory]]
-
Agree: Programs should work well together.
-
Agree: Try to design the output of one program to be the input of another
-
Revise: {-Avoid-} {+Factor+} interactive input.
-
Revise: {-Avoid-} {+Factor+} feature creep.
-
Disagree: {-Do one thing and do it well-} {+What "one" "thing" "well" is is domain-specific.+}
-
Disagree: {-Use text as an interface-} {+The choice of interfaces (types) is domain-specific.+}
!Opinion: The "original" UNIX philosophy
[[freedom.unix]]
All software must be free software.
Follow open standards that are in wide use
Follow the UNIX philosophy:
# Do one thing and do it well
# Use text as an interface
# Avoid feature creep
# Try to design the output of one program to be the input of another
# Avoid interactive input when not needed