> Sadly it is obvious from the rest of this message that you are not up > to speed on the topic here. If you want to usefully contribute to the > topic, at a very least you should familiarise yourself with the prior > threads about systemd to debian-devel. At a very, bare-minimum least. > It would then of course be polite to other thread participants to make > sure you are at least up to speed on what systemd is and how it works… > > > I think it is categorically important to *identify* and *convey to the > > community*... > > > > -> What role is systemd designed to facilitate? > > > -> Do we know why we want to prevent a process from forking? > > This is something that pretty much goes without saying, if you are > familiar with the technology which underpins what we're talking about.
First off, I don't have a sysvinit agenda. I know you didn't say that, but I keep getting the feeling that is what these responses are concluding, and therefore dismissing what I am saying. I use gentoo with openrc. So I would like for you to consider my reasons are something different than -> I am just trying to shoot down anything that is not sysvinit. I read through some of the systemd man page and a little of the original design document. I think I have a rough idea of what systemd thinks it is. But I am not able to form a sound foundation from the ideas systemd describes. It is very dangerous to go ahead with systemd if that first question cannot be given an answer. It seems to me that you are confusing my asking as me being ignorant and stuck to archaic ideas (which I tried to show previously old idea != bad idea), when the real reason I am asking is to get you to think about how this is designed and how it should work. If you can't formulate them and write them down, we have an underthought design. In engineering, there is a *very wise* expression when considering how much thought to give to a design.... -> If you can't put it in writing, then you don't understand it well enough. Software engineering is no different. Read the second listing as to what caused the Air France 447 crash in 2009. https://en.wikipedia.org/wiki/Air_France_447#Final_report -> Inappropriate control inputs. (the sticks the pilot and copilot each have were not coordinated to act together) In flying (originally with mechanically linked controls), when the pilot and copilot are in the cockpit, their control over the airplane is synchronized. One pilot cannot pull up and the other pilot push down. This has the purpose of letting one pilot know if the other is making a mistake. People make mistakes, planes crash, we learned to have to pilot & copilot with constant connection to each other so that they could watch for errors. What went wrong with Air France 447 is the *software* that controlled the force feedback on the *digital stick* didn't give this any thought and the pilot's control stick was not coupled together with the copilot's control stick. Air France 447 crashed because a rookie pilot pulled the stick the wrong way during a sensor error -> while the experienced pilot held steady and the airplane's software *stupidly* averaged the two inputs together. If it had synchronized it like the mechanical sticks do, Air France 447 would not have crashed. If they had thought it out.... -> What design does the synchronized sticks fulfil and why is it like that? -> Should we perhaps consider it when coding the digital sticks? -> Why do we have 2 sets of sticks and only one is needed to fly the plane? Not knowing how to *answer the question* of how to make 2 sticks fly one plane, they just decided : we'll average them together. That makes sense. Ok, moving on..... If you can't give me an answer to my questions it might be that systemd is so overly complicated and takes on so many separate roles that it might be a disaster to lump them all together. I say might, because unless you can show me how it won't, then it certainly needs some more thought to its design, and certainly needs to answer my questions with something besides *sigh, isn't it obvious you know nothing...read documentation* So I would appreciate it if you would consider that linux might be used in some important technology, like deployment of airbags in cars one day, and I would like you to be able to see that we might have a problem with what all systemd is trying to take control over and how that might require a bit more thought. People went to the moon on 1960s technology, others designed the unix model with 1960s technology. What they first had to master was *understanding what it was they were doing* - they had to *comprehend* it. They gave it thought. They *designed* it according to what *role* it was supposed to serve. There is real wisdom in that. So let's review the purpose of my previous post in this sobering light one more time. Has systemd considered that the *filesystem* in linux is the mechanism in which programs can interact with other programs and other machines as well... Perhaps systemd should consider it might be trying to reinvent a partially formed wheel and not recognize it..... Certainly, systemd should consider that the filesystem is the communication medium for a reason, and contemplate why, as opposed to just asserting that really daemons just use sockets and we can ignore that when one starts it might have a reason to talk to another and just suppress that in a queue we provide....because systemd knows best that really everybody just wants to have a fast startup and that's the only reason it has staggered launch.... We will just average the sticks together. -> This is the feeling I am getting when reading the original design of systemd. -> Please step back and think this through. If you think about the architecture of the domain in which all things operate in linux, the filesystem is really an address book. Linux keeps order as the programs converse among themselves. Systemd is presuming to know best what all conversations will be and is asserting itself in place of the communication mechanism that is the filesystem. Systemd is also presuming it knows how the daemons operate better than the daemons know, and systemd presumes that it can makes these decisions for them by declaring what they really need is just <x, y, z>.... That is stated very close to the beginning of the system original design. http://0pointer.de/blog/projects/systemd.html I don't presume to know that -> really all the daemons just need to use sockets and so we can go ahead and start them at the same time. But systemd *does*. I might be testing something with ssh and I need sshd isolated from the internet. No internet connection but I need sshd, please don't make my choices for me systemd, *I can reason myself as well*. My previous post: http://lists.debian.org/debian-devel/2012/11/msg00563.html I got that systemd claims to do damn near everything. What systemd doesn't understand is being able to do anything is equivalent to no restrictions on what you can do which leads to anarchy. Read my 2nd post about udev. If there are no boundaries, what do you expect from this? Systemd connects *everything* together. This is bad. They call it progress. Don't listen to their intimidation, comprehend their reason(s) and check it against the reasons I have in my last post. I don't think they have better reasons. I ask, but I have *yet* to be given an actual reason (not just a better one), I am getting no rationale and that is very likely because none exists. I am going to say that if we can't soundly answer the questions in my previous post, we need to *halt* all work on systemd and form up a *blueprint* so we really understand what systemd is trying to do and how well that will work given the lessons we have learned from the past. Don't let this lead into another Air France 447 because they bullied you into agreeing that : it's systemd -> therefore you should just use it. If I continue to get responses telling me that it's so simple if you read the documentation, and you really are just ignorant and wasting all of our time... Or if someone tries to deflect the questions with pointing me to read some previous thing (because they *can't* simply *answer* the question)..... -> That is a sign for EVERYONE to CUT AND RUN from systemd. -> They don't know what they are doing and they are trying to suppress it, or they are getting angry because they can't express it. -> This is not a flame war, this is a wake up call that systemd is a disaster of an almost idea. Yet systemd is aggressively trying to conform you into using systemd. -> FREE UDEV and save linux from this disaster. Gentoo is forking udev. Pick up the trail there and help them out. If we free udev, we can simply ignore systemd and this problem is over. Wake up everybody. Remember Air France 447. -Kev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadkoaxgqmo96wgzwdguwqnusd-ad9w7beifstsgk9ucfmgg...@mail.gmail.com
