New rule for software design discussions: if your argument for a design includes the words "the unix philosophy", your design is automatically rejected, with no appeal available.
If you mean a specific design goal, say what you mean. "The unix philosophy" has half a dozen definitions, unix never followed any of them religiously at all times, and has become shorthand for "I like this and don't feel like unpacking why".
@danderson@hachyderm.io most of the time they refer to "do one thing and do it well". But I get what you mean.
@kura @danderson that isn't very actionable though. What is "one thing"? How atomic do you have to get before it counts as "one" thing? Is the "one thing" from the PoV of the implementor or from the PoV of the user who wants to achieve a task? What is "well"? Well enough for one specific task? Or generally applicable? Who decides the magic barrier for "one thing"-implementations are programs instead of libraries?
tl;dr: good code ignores the unix philosophy
Also, someone explain busybox to me now
... I think I see it now. Thanks!