Hi all, Rick Moen wrote > At least some in the Debian community are particularly annoyed by > the systemd team's unwillingness to take patches for portability > to kernels beyond Linux. That led Adam Borowski to jokingly dismiss > OpenRC because it lacks "a hostile upstream". > > https://lwn.net/Articles/511726/
Unfortunately the advocating for/against tools can become a bit questionable too. Russell Coker wrote: > We had a "debate" about the relative merits of the various init systems on > this list some time ago. It turned out that only one of the people who were > criticising systemd had actually used it, and that person wasn't making the > more extreme criticisms. > > https://etbe.coker.com.au/2015/04/26/anti-systemd-people/ That is obviously April 2015. I am not sure where other people work but I, at least, cannot avoid to work in environments that are established, and I rarely have a workplace where I could just say: I do not like systemd - so I replace it with something else. So, as a systems administrator I had plenty of opportunities to deal with systemd. But I still do not like it. I also do not like Linux containers. I do not like SELinux. If I say so, it seems to be heresy in some quarters. I do like clean solutions that are easy to work with. They should be reliable. Saying: I have containers but I do not trust them is a bit like saying: I have Windows and it is safer now but I do not trust them, and for that reason better install Antivirus software. It is better to have containers and they separate resources sufficiently so you can trust them. SELinux policies are quite an expensive(in effort) afterthought to try to plug holes in case something "escaped". The policies have to be written and adapted for every application and every Linux distribution, and they are absolute useless under anything but Linux. SELinux is preventing simple solutions to work as expected. A simple link 'ln -s /opt/petros/etc/ntp.conf /etc/ntp.conf' fails without doing additional SELinux adaption. Quite often the fix has to be re-applied after a package update. I have seen many, many times where the "something is wrong" was countered with setting SELinux in permissive mode, and never revisited again. From estimates, that covers probably 30 to 50% of systems I have encountered [I really make that up, I do not have proper statistics, sorry. So the "measurement" is subjective. Sorry. But it may give you an idea that it is not "once in a while".] If, after many many years, this is still the case, then it is probably fair to say: This technology is not doing a good job. [Yes, I know my way around SELinux, most of the times. Actually nearly all, I would think. I just need sufficient time. And I also know what a deadline looks like, and I also see what others do around me.] Now, with systemd, it adds another layer of complexity into this ecosystem, entrenching it further. The end of it are systems that are occasionally "misbehaving", and I just hope that it is half-way safe. I would not bet on it. To argue in favour of complex systems and solutions is always amusing. People make mistakes, and with more complexity comes more opportunity to make them. systemd partially tries to solve some problems that are quite irrelevant for many scenarios. It is a good Unix tradition to use it where needed. For that reason it should easily co-exist with other solutions, not aiming to replace them. The team working on it does not seem to be keen to accommodate this. You all probably know what ISO 9001 is about. It judges how well a organisation is structured to produce good quality. I dare to say that the public behaviour of some of the "systemd people" did not foster my confidence that the structure, their decision making, is based on a strong culture which may lead to rational outcomes all of the time. Apologies, that I am not keen to take magnifying glass and scalpel to look after the systemd further in detail. The solution does not have appeal to me, and I rather spend my spare time on nicer things. Unfortunately, to come back to this: > At least some in the Debian community are particularly annoyed by > the systemd team's unwillingness to take patches for portability > to kernels beyond Linux. That led Adam Borowski to jokingly dismiss > OpenRC because it lacks "a hostile upstream". > > https://lwn.net/Articles/511726/ systemd will be harder and harder to get rid of in the Linux world in the future, and that is quite sad. For me, it means that I spend less and less time thinking about traditional Linux distributions, besides of work-related commitments. In general, it might be that some developments in the future make "Linux tomorrow" the "Windows of today", and there are enthusiasts who may create something more simple and better suitable for new products and systems coming along. Regards Peter _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
