2014/09/21 14:13 "Don Armstrong" <d...@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. -- 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/CAAr43iMJtQ5=ax9qZOWzrjRNO2EwH42XpEA=1oh_c-gdfue...@mail.gmail.com
