> Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.

This is a very relevant remark and highlights the root of the entire discussion, I believe. There seems to be an ideological fault line here. And I think, it is between those who wish for some ideal, all encompassing design and those who have been burned by the short sightedness of such ideals. Grand engineering ideals cemented into closely knit structures are really great on paper. But some years down the line, you realize you have made too many commitments, optimizing for something not relevant anymore. And now you have to circumvent all those greatly engineered structures. It's a bit like looking at satellite cities, the visions behind them, and what has become of them.

The Unix philosophy is mostly about avoiding those pitfalls. But I guess, understanding this might only come with experience.

Totally, this is put better than I could have, but is exactly how I feel watching and experiencing the systemd thing play out. I'm old enough now that I (I'm such a nerd) don't really want my init system messed around with, but I do get there may be better ways in general.

In practice though, to me that would mean something that while looking pretty and being better automated would come with many fewer hidden parts and many fewer interactions between parts than sysvinit. That is, I'm looking for simplicity, composability, editability.

The implied technical debt of one system to rule them all is a lot over 20 years, and you will inevitably have to get into line with a dominant system as a developer downstream from it.

At any rate, happily this behaviour was publicised enough that I won't spend a day googling it when it happens to me. :)

> Totally, this is put better than I could have, but is exactly how I feel watching and experiencing the systemd thing play out. I'm old enough now that I (I'm such a nerd) don't really want my init system messed around with, but I do get there may be better ways in general.

Thanks. I'm kind of in the same boat, age wise. I have the impression (and this comes from a number of comments online and a podcast with Poettering I listened to lately) that any criticism from the experienced crowd is seen as a sort of elitism of people entrenched in their abilities they honed over many years. This might be the case for many critics, and Poettering may be right to dismiss them. But I'm afraid that the very valid criticism regarding overall design goals is lost in all of this. The systemd team steams on, believing that all naysayers are just stuck in their ways.

The way i see it is that systemd developers are coming at it from the DE down. This while unix systems are pretty much constructed from the kernel up. You get the kernel going, then you get CLI userspace going, then perhaps you get X going, and only after all that a WM or DE.

This means that if the DE or X develops a fault, you can always fall back to the CLI to get it back up.

But with systemd, the CLI has become subservient to the DE.

That's interesting. And, of course, the linux desktop environment (other than android) has not had the best story in the last twenty years, so maybe you do have to come at it desktop first.

I really like my CLI though, and really really want to be able to change anything about my system from vi if need be, so I guess I fall on the other side of that perspective.

Meh, i think the problem of Linux DEs is not the DEs themselves but having to face of against Microsoft where they are strongest.

Android got in the door by Google convincing the OEMs to switch Window Mobile for Android, with Google carrying the brunt of the development cost for free.

This happened just as MS was running around in a panic and managed to split their mobile platform in two with Phone 7.

In contrast MS bent over backwards regarding netbooks. They had started shipping Vista, and yet they gave XP another reprieve on execution when Asus started shipping their Linux powered EEEPCs.

Only with major cockups regarding Windows powered warships, and having a former general as chairman of the board, has Red Hat been able to get on the DoDs good side.

I don't see how the process are even able decide to run forever.

They can decide to die when they lose the terminal on SIGHUP (or on any other event), be nicely asked to stop with SIGTERM, and surely can be forced to die with SIGKILL. Everything is there for decades, sane and simple - so I don't really get the idea.

I mean, if some process hadn't considered dying on HUP (i.e. on session close) while it should - it's a bug in that program, go ask its author to fix it.

Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a strawman argument.

In fact, the question is should the shell and init environment overrun the (at least 30 year) unix convention that a user's background processes are not killed when they log out?

The reasons given for a 'yes' answer to this question had better be well and truly good, from my perspective. It's not nearly sufficient to say 'some users complain that things are running when they log out'.

If you read the original bug report, this all started because some userspace programs aren't very well behaved, and the typical windows or os x behaviour would be to log out, ensuring the OS kills them, then try them again.

Generally the advice from unix land would be:

1) Don't use those programs 2) Learn to use ps / top and how to kill a naughty process 3) logging in and out is meaningless when it comes to things running as daemons or in the background.

It's pretty shocking to me that someone thinks the best solution is to obviate all that advice. Not that users won't get an experience they expect from other OSes -- they will. But many users will lose a simple experience they rely on, even if they never touch the GUI. That has a bad architecture smell to me, and I think some other solution could be found.