Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 5805 bytes --]

On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote:
> On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@gmail.com> wrote:
> 
> [ snip ]
> 
> > Well, I'm no authority on this since I can't code,
> 
> My point exactly.

I think your point is not valid, unless you view Linux as an operating system 
intended for and inviting comments only from an inspired l33t who can code and 
it is *only* their user requirements that count.

I understand though that it is their/their employer's choice as to how they 
spend their coding time and what they spend it on.  I am not ungrateful for 
their generosity whether I agree with their approach or not.


> And that's the point; the people doing this changes *obviously
> understand Unix*. They understand it so well that they are able to
> look at it honestly, beyond dogma or articles of faith, and see its
> downsides, so they can try to fix them.

You seem to have a lot of faith in their approach and choice-limiting 
decisions.  They have made arbitrary decisions in developing their software in 
ways contrary to their predecessors.  I don't know if this is because they are 
cleverer than their predecessors, or more ignorant/arrogant/wrong.


> >   http://en.wikipedia.org/wiki/Unix_philosophy
> 
> This reminds me of the people that quote from religious books to argue
> about anything non theological. The "rules" and "sound bites" in the
> links you provide are there to summarize rules of thumb; they are NOT
> scripture, and they are certainly NOT the only way to get a
> technically good program that is easily maintainable. In other words,
> you can ignore most of them, or just following them to a point, and
> anyway end up with a sound design and a technically great program that
> is easy to maintain and extend.

I agree.  This is not a religion, but a statement of design principles based 
on some observations of what seemed to work (at the time) that were made after 
the event.


> The people with coding experience (or most of them anyway) understand
> this; we are not a religion, we don't have prophets that speak the
> undeniably truth. We have highly skilled developers who can have
> opposing views on how to design and implement many different ideas,
> and that doesn't (necessarily) means that any of them are wrong.

We agree again, except that some of these opposing ideas are limiting future 
development choices and current user options.


> There are many ways to solve a problem of sets of problems. Having
> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is
> "wrong", nor the other way around.

KDE took a wrong turn the moment it started emulating Gnome by hardcoding 
redland a whole host of components in its pursuit of a semantic desktop, 
removing choice from users who would be otherwise very happy with the KDE3 
functionality.  Many users have voted with their feet - not because they can 
code better or code at all, but because they still have a choice as plain 
users.

At least KDE has not hardcoded a requirement for systemd as Gnome now has.


> >> I've now concluded it's a myth, much like invisible pink unicorns.
> >> 
> >> Is it like the kernel? A huge monolithic chunk of code with support for
> >> modules?
> > 
> > I would think that although the kernel has grown over the years, it has
> > not done so like systemd.  You can still *not* build modules you don't
> > need in your kernel.
> 
> This has nothing to do with "Unix principles"; it's just that someone
> willing and able implemented the different options.

Well, "someone willing and able implemented the different options", but did so 
by following the paradigm of modular development.


> > The Unix design philosophy may not be globally applicable, but has served
> > Linux well over the years.
> 
> No; what has served Linux is to have developers willing and able to
> write the necessary code, following whatever design they decide is the
> correct one.

I think we have a fundamental disagreement here.  The Unix design principles 
inc. modularisation and extensibility make good sense when seen from the 
perspective of many contributors adding to and improving code in a piece meal 
fashion.  X11 did not follow this approach and ended up with convoluted 
unmaintainable code that had to be broken up.

Having developers able and willing to write code is of course a precondition, 
but not just any code.  It has to be code which others can pick up, improve 
and extend.  In other words, they have to write code which is versatile, being 
respectful of and keeping in mind future development effort.


> > Lennart has de facto introduced a different way of
> > developing his Linux code, which to others and me seems more restrictive.
> 
> First of all, it's not only Lennart; the systemd repo has (literally)
> dozens of contributors with write access.
> 
> Second of all, calling "restrictive" the tightly integrated approach,
> is exactly as constructive as calling "anarchic" the loosely
> integrated one. Like "Unix principles", it means nothing and it says
> nothing.

On the contrary, I think it says something quite specific:  Lennart and other 
contributors have  decided to not follow a modular approach and have hard 
wired components into a growing monolith.  In doing so they have remove choice 
from users.  You want Gnome?  You *must* user systemd.  At least for this 
reason alone his and other contributors design approach is deficient and 
criticised by many as inappropriate for Linux.

I expect that ultimately, this hard wiring will meet its timely end because it 
is by its nature self-limiting and a new development effort will start again.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]