Re: [Dng] Devuan philosohy
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
wrote:
> On Tue, 31 Mar 2015 09:11:54 -0400
> Hendrik Boom 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
Re: [Dng] Devuan philosohy
On Tue, 31 Mar 2015 09:11:54 -0400
Hendrik Boom 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
Re: [Dng] Devuan philosohy
On Tue 31 March 2015 09:11:54 Hendrik Boom 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: > > > 1. Write simple parts connected by clean interfaces. > 2. Clarity is better than cleverness. > 3. Design programs to be connected to other programs. > 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. > 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. > > (see > http://lists.freedesktop.org/archives/systemd-devel/2014-September/023294.ht > ml for the actual post) > > -- hendrik Jóhann B. Guðmundsson in http://lists.freedesktop.org/archives/systemd-devel/2014-September/023294.html asks: > Now after you have read these more of an guidelines than actual > philosophy I would like to hear from you where you think systemd has and > is falling short of them during it's development phase and lifetime so I > can better understand why people seem to be claiming it's not following > these guidelines? I think it's more easy to list where systemd (the project) is _not_ failing: #3 and just maybe also on #12 (unlikely), #14, #15 - I didn't feel like checking just to complete the already overwhelming list of failures. I wonder how anybody could fail to see how systemd massively violates particularly #6 but also #1 #2 #5 and just recently #10 (8.8.8.8 issue). In the end the tone and obvious hybris and arrogance in that mail make it seem unlikely that answering to this guy would result in anything good. I mean somebody claiming that "7 years of function hijacking are hard to beat by any competitor that's just a init system" (paraphrased) is clearly explaining the issue itself as well as exposing his own complete lack to grok the issue. There's a lot more to say about other fallacies in this mail, but I think everybody willing to see will not need me to point all that out. /j signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan philosohy
A good list. Some combo of 1. and 10. WRT interface design "Be liberal in what you accept for input and conservative in what you output to the next victim" Also for 13. sysadmin time is also expensive. Human time gets more expensive every year and machine time gets cheaper every year. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan philosohy
On Tue, 31 Mar 2015, Hendrik Boom 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: > > > 1. Write simple parts connected by clean interfaces. > 2. Clarity is better than cleverness. > 3. Design programs to be connected to other programs. > 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. > 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. > > (see > http://lists.freedesktop.org/archives/systemd-devel/2014-September/023294.html > > for the actual post) thanks for extracting this summary. IMHO Martin makes good points by opening this thread. Beyond the jokes and the fact is 1st of April in New Zealand already :^) we may want to facilitate a "disarmament" process of the two factions. Nevertheless I find pretty offensive episodes like the one at Libre Planet where a Peter gets publicly alienated as troll for asking a question about systemd, it just feels like we are fighting an asymmetric war against a leading group that seized all resources and will not drop its weapons while playing victim. Beyond all their good intentions I believe they still want us all "dead". Also the final argument of this mail you link is disgusting considering the vote they keep waving is a 4v4 Condorcet draw and it should have been pondered with some more attention or at least not waved as the final resolution that sends all others to Hell. Ultimately we are lucky as it looks like Hell is a much better place than we thought initially, at least there is much more activity and space for innovation than in Heaven ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
