On Sat, Oct 18, 2014 at 6:14 AM, Lisi Reisz <lisi.re...@gmail.com> wrote: > On Friday 17 October 2014 21:09:59 Dan Ritter wrote: >> On Fri, Oct 17, 2014 at 07:02:12PM +0100, Lisi Reisz wrote: >> > On Friday 17 October 2014 18:30:31 Andre N Batista wrote: >> > > I cannot believe some people still >> > > thinks [snip] that we should simply stick with >> > > the TC's authority regardless what. >> > >> > Surely no-one has ever said that?? References if someone has? >> >> Sven Joachim. >> >> "Because the people who do the work get to make the decisions, >> that's the way Debian works." >> >> in >> Message-ID: <8761gow4qv....@turtle.gmx.de> >> Date: Tue, 16 Sep 2014 06:47:52 +0200 >> In-Reply-To: <87sijspifa....@yun.yagibdah.de> >> >> >> and Lisi Reisz: >> >> "We can use what we are offered, and be grateful that we are >> offered it. Thank you springs to mind." >> >> in >> Message-Id: <201409202246.44899.lisi.re...@gmail.com> >> Date: Sat, 20 Sep 2014 22:46:44 +0100 >> In-Reply-To: <20140920202015.gc8...@teltox.donarmstrong.com> >> >> -dsr- > > Neither of those says what you claim. ALL the DDs get to make the decision, > including those who have now called for a GR. The TC allowed for this > possibility from the beginning, in lessening the vote required to overturn > its decision, and it is laid down in the constitution.
Much of what happened is what politicians call "nuanced", that is, you interpret it according to your understanding of the circumstances and conditions. > We were objecting to > the ad hominem unpleasantness and destruction of the list. Let me try to explain (yet again, sorry, but re-wording things sometimes does help) my point of view and why some of what I have said should not be considered ad hominem. (Some will say pessimistic, I won't argue with that, even though I think pessimism is warranted.) When I have my engineer's hat on, I do not want to combine the init process with much of anything else. pid 1 should do the bare minimum. The way I see it, even sysv-init also does more than it should. This is in accordance with engineering principles that are as integrated into my understanding of software and computer hardware engineering as my intuitive understanding of gravity is integrated into the way I dance. When I look at systemd, the fundamental design and structure fly in the face of reason. I'm not trying to be insulting when I say that. For some of us it really does fly in the face of reason. According to what I understand as an engineer, everything that systemd does beyond the minimum (in other words, beyond being the ultimate backstop for signals and dying orphaned processes) should be delegated. Maybe I should say "delegated as much as possible", but systemd just does way too much. When we try to describe what systems do when core processes attempt to do too much, we have said such things as "chasing its tail", "thrashing", "wandering away and not coming back" and "recursively trying to figure out what it was doing when it was trying to figure out what it was doing". These may sound insulting, but it's an attempt to describe what is actually happening in the computer when it quits responding to input. There are other, similar issues about the design and structure of systemd, and listing them all here would tend to sound like a litany, so I won't this time. Some terms that have been used to describe engineers who would try to put too much into core processes include "arrogant", "prima donna", and "trying to defy the law of gravity without wings". These terms were not intended to insult. They were intended to point out that, as we gained real-world engineering experience, we would tend to quit doing such things. Shoot, we all started out as prima donnas. Hubris, as as been noted before, seems to be an essential part of the attitude required to push programming projects through to completion. We don't think we are being condescending when we say we know what it's like to be slapped in the face by reality. Good engineers have all had to put up with advice we didn't want to hear, including the use of colorful adjectives intended to help us take a real look at the places things tend to go wrong. Faster CPUs, more CPUs, more RAM than in the past are being depended on to avoid these problems, but there's a wall that will be hit. Several walls, and they have been hit in a number of cases, but CPU speed, extra CPUs, and extra RAM are helping to hide the fundamental problems. Hiding them will not make them go away. As far as the so-called conspiracy theories, looking at parallels in the industry, Microsoft kept making impossible promises about MSWindows being able to duplicate the Macintosh experience on "standard IBM-PC hardware", basically from the year 1985, when they first realized that the early Macintosh might not be a fluke. Their "forward-looking" promises, and their continual reliance on Moore's law to rescue them from the worst of their bad promises, gave them the edge to gain their effective monopoly. That is part of what is being referred to when people express concerns about systemd "taking over Linux". We hope that systemd will improve. Business-types seem to like the stuff it provides. But it's going to take major re-design to make it reliable. As engineers, we wanted systemd to go through that re-design in experimental distros, not in mainstream distros. The way I understand what happened with Fedora, management at RedHat decided that they weren't willing to be patient enough for systemd to happen in an experimental distribution. I have read where some of the open desktop community have expressed the opinion that the changes were going to be too hard to push through if we relied on proper engineering techniques. Or, in other words, they had come to the conclusion that they would have to force everybody to do things the right way, to get people to give up their old ways of doing things. That's the best way I can paint that. This is the background. Does this help explain why what appears to some as mere turf battles and childish name-calling, etc., is a bit more than playground antics? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNC0aL=y6dnjvhtncjgyjip4totctsb-aclqyaefgm...@mail.gmail.com
