Hi all, to start with Douglas Adams: "There is a theory which states that if ever anyone discovers what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this already happened." I have this sometimes in my mind if I look at Linux related development. Especially in the area of desktops, btw. Everybody knows that Unix is around for so long because it suffers the "good enough" syndrome. What are the killer features that make systemd so much appealing to change? "Making a boot a bit faster" isn't good enough for such an intrusive change, I would think. What else does it do better? Why do I need a journald (mandatory) if I have already a bunch of syslog services developed over many years? Are there binary logs which are hard to read if things go really really wrong? (That really would be a show stopper for me.) What exactly is the network demon used for? Does it work nicely with approaches as OS virtualisation (e.g. Linux containers with own network stack) I have simply problems to understand motivation and design. It seems to be more than just init. Which "other parts" will it take over? Does it "eat into he kernel" finally and makes Linux a microkernel? Or does it replace traditional userland applications (e.g. syslog) and makes the systemd equivalents mandatory even sometimes unintended? (Let's say: the modern Linux desktop is Gnome, Gnome packages require systemd, systemd includes journald)? BTW: Making parts of a system less exchangeable does not only hurts porting, it creates "single point of failures" if there is a problem. Think of bash recently. You cannot replace it if your scripts have a lot of "bashisms" in it. If you do not have a fix you are stuffed. If FreeBSDs sh is vulnerable I can simply replace it with bash (e.g.) If rsyslogd is vulnerable and there is no fix: Just replace it with syslogd. If systemd requires journald and there is an issue: good luck! Not having a choice makes a system less modular and flexible. This looks very much "Un-Unix-like" to me. Obviously Solaris SMF is there for a while. Being a commercial product it just arrived and was not discussed widely in public. Admins looked, were confused and .. just went on with it. For me it is between "A bit annoying" and "This works quite well"! I did not do too much "cool stuff" to appreciate it. So I do not have a definite well-informed opinion about it. I used Ubuntu for a few years with upstart and was mildly annoyed. But I did not explore it too much. It was just my desktop and it's mostly web browser and terminal multiplexer. No point in getting religious about it. It is a different story if I have to deploy and administrate Unix/Linux servers. To be honest, if I can I choose FreeBSD. If I need commercial support it more or less dictates Red Hat so Debian will not be my choice. Well, maybe I "find" somewhere Debian servers to look after. But it dd not happen to me for more than ten years now I think. But it is more or less likely that I have to deal with systemd in the future, Debian or Red Hat. What are the shortcomings of the existing GNU/Linux framework so it has to be replaced by systemd? I see a lot of cons (Maybe some only because I am not well-informed? Please correct me!) and not many pros. Regards Peter
P.S. obviously Craig Sanders wrote something in parallel but with quite similar opinion I think. [me]
I see a lot of cons (Maybe some only because I am not well-informed? Please correct me!) and not many pros.
[Russell Coker]
But when developing software real-world experience in developing such software counts for a lot.
I've been a DD for ~14 years. I know how Debian works.
I do not doubt this. I would like to know your pro/cons about systemd. Sometimes developers can "lose the plot" completely and the intended audience just stares blankly with disbelief that they build a ship when everybody wanted a car. [Trent W.Buck]
IIRC, at least initially, the feature that had a hard requirement on systemd was serving multiple independent, concurrent user sessions (keyboard/video/mouse) from a single workstation.
That does not need a change in NTP I guess;-) Console driver comes to mind.. Regards Peter
On 10 October 2014 10:31, Peter Ross <Petros.Listig@fdrive.com.au> wrote:
What else does it do better?
It *can* replace annoying init.d scripts, that are deceptively hard to write, often are very buggy and suffer from various race conditions. e.g. have lost count of the number of times have "/etc/init.d/daemon restart" only to find the daemon never stopped properly in the first place, or tried to start again while it was still running and both copies exit. Often I have to manually kill a daemon because "/etc/init.d/daemon stop" didn't - sometimes without any messages or errors. Use of killall in init.d scripts also bothers me. Could easily kill processes it is not meant to. e.g. on a virtual container host. Some init.d scripts I have seen will delete a socket, start the daemon, and then try to chown/chmod the socket, which is very much a race condition. Or something like that. etc Yes, sure, well written init.d scripts wouldn't have these problems, however the fact is these problems do get into distributions, and often go unnoticed by the responsible maintainers. "It works for me!" -- Brian May <brian@microcomaustralia.com.au>
Brian May <brian@microcomaustralia.com.au> writes:
On 10 October 2014 10:31, Peter Ross <Petros.Listig@fdrive.com.au> wrote:
What else does it do better?
It *can* replace annoying init.d scripts, that are deceptively hard to write, often are very buggy and suffer from various race conditions.
e.g.
have lost count of the number of times have "/etc/init.d/daemon restart" only to find the daemon never stopped properly in the first place, or tried to start again while it was still running and both copies exit. [...] Yes, sure, well written init.d scripts wouldn't have these problems, however the fact is these problems do get into distributions, and often go unnoticed by the responsible maintainers. "It works for me!"
There was a plan to deal with the easy 90% of these: https://packages.debian.org/unstable/metainit It was started at a Debian conference where people were pushing for upstart in Debian; it hasn't really been touched since, but since sysvinit hasn't CHANGED since, it still works for me.
On Fri, 10 Oct 2014, Brian May <brian@microcomaustralia.com.au> wrote:
It can replace annoying init.d scripts, that are deceptively hard to write, often are very buggy and suffer from various race conditions.
Also init scripts often allow non-root daemons to have access to the same tty that is used for the sysadmin shell. That means if an attacker can compromise a daemon at startup (EG replace programs it runs at start before detaching from the tty) then they can push characters into the root keyboard buffer. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 10/10/2014 3:48 PM, Russell Coker wrote:
On Fri, 10 Oct 2014, Brian May <brian@microcomaustralia.com.au> wrote:
It can replace annoying init.d scripts, that are deceptively hard to write, often are very buggy and suffer from various race conditions.
Also init scripts often allow non-root daemons to have access to the same tty that is used for the sysadmin shell. That means if an attacker can compromise a daemon at startup (EG replace programs it runs at start before detaching from the tty) then they can push characters into the root keyboard buffer.
systemd can be compromised under the same conditions, it isn't immune to having non-authorized updates to the machine. What's more, systemd is a /fairly/ new set of code, okay, not really new, but the size of the code and the /feature creep/ that has been seed means more new code all the time ... leading to more potential bugs with each code extension. Nightmare. A.
"Peter Ross" <Petros.Listig@fdrive.com.au> writes:
to start with Douglas Adams: "There is a theory which states that if ever anyone discovers what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
There is another theory which states that this already happened."
I have this sometimes in my mind if I look at Linux related development. Especially in the area of desktops, btw.
I refer my learnèd colleague to The Kid: http://www.jwz.org/doc/cadt.html
participants (5)
-
Andrew McGlashan -
Brian May -
Peter Ross -
Russell Coker -
trentbuck＠gmail.com