> On Tue, Jul 24, 2012 at 3:24 PM, Baho Utot <baho-utot@xxxxxxxxxxxxxxx> wrote: > > I am sorry you think any thing you have will be a waste of time. > > I am looking at this "problem" of moving to systemd, staying with current > > init scripts or moving in the LSB init scripts direction. In order for one > > to make an informed decision one needs to consider all the facts. > > Without your insight or wisdom how would/will I do that? > > > > Discussion is healthy > > I'm happy to discuss and answer any questions. However, Kevin's emails > were: off-topic (this thread was not on systemd, but on rc.conf), > irrelevant (the kind of embedded systems he is talking about would > never run Arch), Well you brought them on topic by saying at some point we will have to embrace systemd and I wasn't the one who commented first. I wonder if ArmArch will run systemd. They may not run arch but they have code and scripts ported over. Of course those scripts can easily be wrote. Also with the 3.4 kernel recently getting NOMMU support. I hope desktop and embedded will get closer not further away. I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom. > To give a couple of comments, for those who have not looked at systemd yet: > > Firstly, systemd is bigger and does more than sysvinit. The reason for > this is that it moves functionality out of the individual daemons and > into init. This functionality is stuff that would otherwise have been > implemented over and over again in every daemon or rc script, each > time it is implemented it would be a potential for bugs. Now we have > it all in one place, where we can all work together to test and review > it. The kind of features implemented in this way are for the purposes > of security and reliability of the daemons on your system (i.e. it > will monitor them and deal with crashes, it will lock down the kinds > of things a daemon is allowed to do, what directories it can > read/write to, what system calls it can make, what user it is run as, > etc). I would not call this bloat, quite the opposite. It means that > the total amount of code on your system, and the total amount of > potential for bugs drastically decreases. > > Secondly, most of the functionality of systemd is separated out in > separate processes/tools, and are not part of PID1. In fact, we use > these tools also in initscripts, and this is why I believe we will be > able to maintain initscripts, even if systemd should take over for > most users. Initscripts currently use the following systemd tools: > > systemd-module-load > systemd-udevd > systemd-cryptsetup > systemd-tmpfiles > systemd-sysctl > systemd-binfmt > systemd-random-seed > systemd-vconsole-setup > systemd-remount-fs > > HTH, > > Tom > plain wrong (his descriptions of how systemd works > and how to use it has nothing to do with reality). > Please give references if you are going to flame me in future. I don't believe I described how systemd works or how to use it. I hope you don't mind me sharing part of a private mail. We seem to disagree on imposing limits onto the user and I assume init halting being good or bad and your comments at the bottom may also prevent anyone moving away from Arch. > The point is that there is no limit to what you can put in rc.conf. That's the beauty of it and the essence of UNIX. Which yes has led to variation and perhaps difficulties for the mass market. Atleast systemd has led to the co-operation that may reduce this variation for init scripts users too. > >> I'm sorry if I take this with a pinch of salt, but previous claims I > >> have seen you make often prove to be unsubstantiated. > > > > In your opinion, many agree with me and moreso those who have > > a decent understanding of UNIX. > > No, not in my opinion. It is objective fact. You keep on making claims > (such as A is more secure/smaller/faster/more accurate than B), and > then admit that you actually haven't checked/don't know for sure. I > assume the same is the case here. You haven't actually read the > systemd documentation or the systemd code. Not all of it of course but with /sbin/init I didn't need to. There are many ways to skin a cat, which is where I think we are getting crossed wires here. It is clear that 800K of pid 1 is going to have bugs. It is also clear that if this daemon is able to do so much such as starting services upon events that there will be major exploits. It is also almost certain that all systems are not going to require all of the functionality that the 800k represents. I am glad it has some modular nature however. I had already considered that there may be some feature I haven't considered that would have made adoption difficult as IPC would be required otherwise. I guess I wouldn't need that function though too. I'm sure raising the size of pid 1 was a thorn the developer had to contend with in any case. I just hope it wasn't features that overrid the complaints. I may have to find time to look at the systemd list archive. The question is do I want to run systemd. It looks like I don't have to answer that for atleast a long time after which some bugs will have been ironed out and it may have become more modular. Is that correct? > I would assume we would get greater modularity and fewer bugs over > time (recently we moved all the sysv compatibility logic out of PID1 > and into separate processes, just to give an example). > As to when Arch will require systemd: I have said that I will help > with whatever the other devs decide. However, I will not take the lead > on a move to systemd, simply because I don't want to deal with the > flames. > I am working to make it possible to support both initscripts and > systemd "forever". That said, I imagine that the other devs at some > point will decide that maintaining our rc scirpts (i.e. the ones > shipped with the different packages, not the ones in initscripts) is > too much of a hassle and discontinue them. I have no idea when this > will happen, if at all, nor do I have any intentions of trying to > influence the decisions/timing. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
