Re: Perfect Jessie is something like this...
On Sun, Nov 2, 2014 at 5:35 PM, Jonathan Dowland <jmtd@debian.org> wrote:
> I don't think we have universal agreement that systemd
> violates the (rather nebulous)
(Well, engineering principles do tend to _appear_ nebulous, I suppose.)
> UNIX philosophy,
True. Kind of like there was a time when Newton's description of
gravity was not universally accepted.
"Unix philosophy" is just a verbal description of the ways that
principles of engineering apply in software. It is not yet well
formulated.
Modularity once looked like the paradigm, but we discovered that
modularity was also not easy to get our hands on. Lots of ways to
partition a design into modules, even given the focus on character
processing and use of filters in pipes.
Objects, patterns, etc., and we keep finding new ways to look at the
principles, and we keep finding contexts in which those ways of
looking at the principles don't apply.
> at
> least any more egregiously than the kernel,
Well, we know the kernel is significantly more monolithic than it
might be. Part of the reason Linus still has work to do is that it
takes time to figure out how to partition the kernel into modules that
work well with each other.
Getting it running was important, once people started using it. Now
the devs spend a lot of their time trying to find new ways to make the
kernel conform to principles of engineering.
It would be nice if the L4 groups and the mainline Linux kernel group
could find it easier to integrate the essential elements of L4 into
the mainline kernel. But L4 is not the only, or necessarily best
partition.
> GNU,
The gnu userland is a mix. But, in general, it more-or-less follows
the unix userland it was originally duplicating to a large extent.
Most of the Linux tools have accreted cruft, and the original unix
functional partition is not guaranteed to be the one-and-only best
partition.
But the fundamental reason for the success of Unix was that the
partition was exceptionally good. Dennis, Ken, Brian, Robert, Doug,
et. al., made one of those rare useful leaps when they defined their
set of tools.
We have since been going both directions with software technology.
Some of our software is complicated because the people who pay for it
want complicated machines. Some follows engineering principles because
the people who pay for it are willing to let engineering principles be
used, in so far as we understand engineering principles.
> or
> many other key components of Debian.
One of the problems with current software technology is that, when
people realize their pet projects run against proper principles of
engineering, instead of refactoring, they want to invent a domain in
which the rules of engineering don't apply.
But even games are subject to rules of engineering.
The leading edge of research, on the other hand, tends to be a place
where we don't know how to apply the rules of engineering. The rules
apply, but sometimes in non-intuitive ways.
Now, one of the interesting things about computers is that CPUs often
have extra cycles, and those extra cycles can be used to hide places
where the external design doesn't follow principles of engineering.
Unfortunately, that leaves many people with the impression that, if we
have enough CPU cycles and RAM we can break laws of nature.
The results, like the Segway, can be interesting, but to make the
Segway work they had to use some pretty strict engineering underneath.
Not that the Segway was worthless, but we don't want to try to replace
all bicycles and short-distance cars with Segways.
> Nobody can rule
> with any particular authority on the matter,
Back before the almost-success of ISO/ANSI C, we used to say that the
compiler had the last word. It's still true, but we have been able to
describe so much that we tend to think of the standard as the
compiler. And gcc reigned alone as the best implementation of the
standard for a long time.
Which is to say, when we break principles of engineering, things fail.
Sometimes we don't notice the failure until storm winds expose the
fact that an exponent got inverted in the design of a bridge, or a
dance party in a hotel ballroom has twice the rated occupancy,
combined with rhythmic motion that was not considered in the design,
and things fail in non-graceful ways.
The real world is the ultimate compiler to test our designs against.
> and one
> person's opinion is not worth more than anothers.
That's wishful thinking. Engineering principles apply, even though no
living engineer has God's understanding of the principles.
What you can say is that computer science and information science are
still not well developed, and you can hope that Poettering & company's
work will expose new ways to apply the engineering principles.
That won't happen to the extent you want it to.
What will, I hope, happen, is that Poettering and his group will
eventually quite protecting their baby. They have been fixing some of
their mistakes, so things don't look all bad.
The rest of desktop.org's work, I'm not sure about. Gnome, in particular.
In the meantime, debian's devs are finding ways to start the
re-factoring, in their efforts to provide for alternate init systems
and alternate desktops.
The reason I have to hope that things will work out with systemd is
that it's clear that something is pushing adoption of systemd against
all reason right now. Good engineering would have systemd being
developed and debugged first only in a limited number of experimental
distributions. Red Hat was not willing to be that patient, and now
something is pushing their lack of patience on the rest of the Linux
community.
Are managers really so scared of non-visual interfaces?
--
Joel Rees
Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.
Reply to: