Re: Effectively criticizing decisions you disagree with in Debian
2014/09/21 14:13 "Don Armstrong" <don@debian.org>:
>
> On Sat, 20 Sep 2014, Jerry Stuckle wrote:
> > Then please explain to us why, with all of the negative technical
> > aspects surrounding systemd, it looks to be the default init in
> > Jessie.
>
> You can start by reading why I voted for systemd:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3661
Okay, Don, I read your reasons in post #3661. I didn't read the whole
thread, but I did read a few others. what I read was unsettling
enough. Your comments below are equally unsettling.
Let me ask you:
What problem were you trying to solve when you decided there had to be a switch?
-- you, as an individual, and you, the community of developers?
> You would also do well to read the statements by the other committee
> members.
>
> On Sat, 20 Sep 2014, Bob Proulx wrote:
> > For one by closing bugs without fixing them. As users we are always
> > admonished to file bugs. But whether those bugs will be acknowledge
> > and handled appropriately depends upon the project. My experience is
> > that if it is systemd that the bug will not be handled nicely.
>
> This is because of a combination of not enough volunteers to handle the
> bugs, and the bludgeoning
I do hope you meant burgeoning there. ;-/
(Although, frankly, what has been happening has felt a bit like the
use of blunt instruments at times. Perhaps on both sides of the
debate, but you have to understand that the user pushback is exactly
that, pushback.)
> of people working on systemd in general as
> evidenced on this very mailing list. Package maintainers are only human,
> after all.
So are the users, and we are your final Q/A. Those of us who
understand the tech walk away and your Q/A suffers seriously.
> > Eventually Ben Hutchings got involved, reopened the bug, and objected
> > to the kernel maintainers choices being overridden. And therefore it
> > was eventually fixed. But if he had not gotten involved I am sure it
> > would not have been fixed since it had not been in spite of multiple
> > reports.
>
> Yes, that bug could have been handled better. It was eventually resolved
> thanks in no small part to the willingness of Ben Hutchings to bring
> forward the precise technical issues with the overriding of the default
> kernel sysrq mask by systemd. That's the sort of healthy communication
> between a user of systemd (Ben) and the maintainers of systemd in
> Debian that we all would do well to emulate. [Even though Ben is a
> Debian Developer, he has no special powers regarding this particular bug
> than anyone reading this has.]
Why was that communication allowed to break down in the first place?
> On Sun, 21 Sep 2014, lee wrote:
> > [Stuff that I am not prepared to talk about, as I have not been able to break open the time in my schedule to help out. I want to, but my current situation does not alow it.]
> >
> > What I don't understand is that criticism and other forms of speaking
> > up cannot be considered as a form of contribution.
>
> Constructive criticism is often a useful contribution. Destructive
> criticism, much less so.
Do you know how oil well fires are put out?
Sometimes the first step to constructive is rather destructive.
> Disagree all you want, but don't malign others when you do so. (Or at
> least, don't do it on Debian communication infrastructure.)
I'd usually agree, but for what I find so unsettling about the
conversation I've seen so far.
> --
> Don Armstrong http://www.donarmstrong.com
>
> G: If we do happen to step on a mine, Sir, what do we do?
> EB: Normal procedure, Lieutenant, is to jump 200 feet in the air and
> scatter oneself over a wide area.
> -- Somewhere in No Man's Land, BA4
You guys want technical analysis of systemd, along with dbus, cgroups,
whatever the log daemon was called, and several other so-called
"technologies" that have come together to produce this situation?
The following is by no means complete:
(1) Simplicity in art is simplicity in art.
Simplicity in engineering is the difference between literally fatal
errors and graceful failure modes. That goes across the board.
(2) When I was a college student, when we talked about modularity, we
talked about something called "implicit linkage". I don't know what
the current term for it is, but it is the generalized problem of
global constants, variables, protocols, and design patterns,
especially those which are never formally declared.
It's hard to set an absolute measure of implicit linkage, but we do
know that the more you declare globally, the less you can be sure that
what you declare locally will behave as you declared it.
In other words, the old adage that "A computer only does what you tell
it to." no longer applies when implicit linkage is high.
(3) Design itself (what is often wrongly referred to as "ABI" or such)
is one of those global declarations, and when the design is unstable,
nothing in the system can be stable.
There are at least two classes of instability at play here, one is
often called, colorfully, "moving the goal posts".
The other is generally described as internal conflicts between
important of the design.
We aren't talking about "warm fuzzies" and "aesthetics" here. These
are not just epithets, these are serious engineering issues that are
being ignored, and to solve some unnamed problems.
(4) You can't solve problems you can't name. This is as much an
engineering problem as a management problem.
That said, what has often been referred to in the discussion as
"entanglement" has generally referred to one or more of the above. You
can also talk, I think, of breaking the modularity. These have been
made to sound like abstract epithets by certain who have argued in
favor of systemd, et. al., they have been labeled "fud" and
"scaremongering", but they are real engineering issues resulting in
large numbers of real bugs.
Getting more specific:
(5) Pid 1 has to be as simple as possible to provide deterministic
response. When it handles all the stuff that systemd handles, there is
no possible way of analyzing the system for certain classes of bugs.
Race conditions are the most easily described of those classes, but
they are by no means all.
(6) systemd and cgroups (at minimum) end up overriding the permissions
system. It's bad enough having SELinux and ACLs brought in to knock
holes in the permissions system, but when arbitrary non-kernel system
functions start getting their hands into the equation, there is no way
to be sure that when you set any particular file under /etc or under
~/ -- including /etc/ssh and ~/.shh -- as mode 740, that the effective
permissions don't end up 666 or 1147. In this case, even pid 1 is a
group of arbitrary non-kernel functions.
Permissions and race conditions are not the only ways that the
modularity of these technologies is broken. I'm not going to try to
enumerate them here.
(7+n) The most prominent result of entanglement is "lock-in", and,
while "lock-in" has been named by many businessmen as a feature, it is
definitely a class of bugs and the symptom of many others. "Getting
rid of lock-in" is not just a matter of political or economic whimsy.
Lock-in is a serious symptom of very fundamental engineering issues.
It's 3:30 a.m. here. I have to stop here or I'm not going to get any sleep.
Joel Rees
Computer storage is nothing more than fancy paper,
and the CPU nothing more than a fancy set of pens.
All is text, streaming forever from the past into the future.
Reply to: