Recent Changes - Search:
Debate /

Debate on the UNIX Philosophy

List of other debates.
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

  1. All software must be free software.
  2. Follow open standards that are in wide use
  3. Follow the UNIX philosophy:
    1. Do one thing and do it well
    2. Use text as an interface
    3. Avoid feature creep
    4. Try to design the output of one program to be the input of another
    5. Avoid interactive input when not needed
  4. Achieve tight integration with the OpenBSD operating system
  5. Prefer languages native to OpenBSD: C, korn shell, perl
  6. Prefer software that ships with OpenBSD or are written by OpenBSD developers: opensmtpd, openhttpd, unbound, nsd, acme-client, tmux, etc.
  7. Prefer BCHS web apps
  8. Prefer software that is endorsed by the suckless project
  9. Prefer OpenBSD or suckless style guidelines
  10. Avoid unnecessary, 3rd-party dependencies
  11. Prefer software that has a long history of being reliable and stable
  12. Prefer permissive, 2-clause BSD or MIT license over the GPL
  13. Prefer software with better documentation
  14. Prefer software that can be easily audited and forked