Great list! Thanks everybody for your input, because for those of us who aren't programmers, this helps clarify a lot of the reason why systemd is less than ideal from a technical perspective. I'm more of a "if I can't read it or write it in vi or manipulate it via a bash script, then it doesn't belong in Linux" kind of guy, and I believe the reason why I have such disregard for systemd is evident in the aforementioned statement. I don't need to write a conf file that is actually a wrapper to a piece of code that then configures how my machine runs, all the while with me having no insight to what is going on inside; and yes, I'm aware this is a gross simplification. However, your list and consequent addendums are great food for thought. Educating the masses with fact, logic, and just plain old good common sense is the only way to combat the idiocracy that the Linux community as a whole has become. Thanks again!
Linux O'Beardly @LinuxOBeardly http://o.beard.ly linux.obear...@gmail.com On Tue, Mar 31, 2015 at 1:00 PM, Steve Litt <sl...@troubleshooters.com> wrote: > On Tue, 31 Mar 2015 09:11:54 -0400 > Hendrik Boom <hend...@topoi.pooq.com> wrote: > > > On Tue, Mar 31, 2015 at 11:16:02AM +0200, Martin Steigerwald wrote: > > > > > > [1] [systemd-devel] I wonder… why systemd provokes this amount of > > > polarity and resistance: > > > > > > > http://lists.freedesktop.org/archives/systemd-devel/2014-September/thread.html > > > > The discussion here contains a quotation about the Unix philosophy > > (in an attempt to explain how systemd follows it). I find it > > summmarises well the way Devuan believes a Linux system should be > > organised: > > Allow me to make a couple small enhancements. Please keep in mind that > I use "TS" to mean "Thin, Standard", where a standard interface is a > pipe, named pipe, fifo, socket, simply structured file, etc. When I > insert something, I'll use square brackets. When I delete something, > I'll use X{whatever deleted text}. > > > > > > > 1. Write simple parts connected by clean > > [TS] > > > interfaces. > > 2. Clarity is better than cleverness. > > 3. Design programs to be connected to other programs > > [by TS interfaces] > > [3a Connect programs only on a need to know basis, where the connected > program is purposed primarily to do what the connected program needs > done. Don't connect to a bicycle just to get a spoke.] > > [3b If the connecting program, at various locations, requires various > types of services from the connected program, it might be OK to > violate 3a. This might, in some cases, justify connecting to GTk and > Qt.] > > > 4. Separate policy from mechanism; separate interfaces > > from engines. > > 5. Design for simplicity; add complexity only where you > > must. > > 6. Write a big program only when it is clear by demonstration > > that nothing else will do. > > 7. Rule of Transparency: Design for visibility to make inspection and > > debugging easier. > > 8. Robustness is the child of transparency and simplicity. > > 9. Fold knowledge into data so program logic can be stupid and robust. > > 10. In interface design, always do the least surprising thing. > > 11. When a program has nothing surprising to say, it should say > > nothing. > > 12. When you must fail, fail noisily and as soon as possible. > > 13. Programmer time is expensive; conserve it in preference to > > machine time. > > [13a. Unless doing so would make life slower for users and admins, in > which case your top priority should be saving time for the users and > admins.] > > > 14. Avoid hand-hacking; write programs to write programs when you can. > > 15. Prototype before polishing. Get it working before you optimize it. > > 16. Distrust all claims for “one true way”. > > 17. Design for the future, because it will be here sooner than you > > think. > > I think my modifications go a long way toward rejecting faux modularity. > > SteveT > > Steve Litt * http://www.troubleshooters.com/ > Troubleshooting Training * Human Performance > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
