Debian Now Voting On Init System Coupling

[GreatEmerald]

Oh yeah, you'll find quite a lot of information on the subject presented in an entertaining way in GreatEmerald's Ace Attorney cases if you haven't already seen them. The links to these can be found in one of these threads, can't recall which one.

This very one, one of the first pages of the thread:

In related news, I now started the third case of the discussions' adaptation in Ace Attorney format (this goes up to and including Watson's position statement). Here are the links to all three parts:
http://aceattorney.sparklin.org/jeu.php?id_proces=57684 - case 1
http://aceattorney.sparklin.org/jeu.php?id_proces=57899 - case 2
http://aceattorney.sparklin.org/jeu.php?id_proces=58428 - case 3

[Gusar]

it is for process control
so it could easily get all dem PID's from daemons
and so double forked daemons can't hide from whatever started them (systemd in this case)
(since daemons are processes re-parented to init, that runs on PID 1)

thing is linux kernel gives other ways of achieving this, and even more

also if you cgroup something, it can't escape anyway

You've described cgroups a bit here, but similar to that blog post prodigy_ linked to, you haven't described why it's bad that systemd does it.

I did some work for you, found a mention by Lennart about it (click):

cgroup support is used to spawn services, so how could you put that into another process if to start that process you need cgroups?

I'm sure there's more, but I'll leave that for you to research.

BTW, Lennart's Google+ page (especially the comments) is in general a very nice resource of info on the how and why of systemd, I suggest you go through it. The comments at lwn.net are many times insightful too, Lennart goes by "mezcalero" there.

[Gusar]

Damn, the short edit times at this forum...

Anyway, like I said, the comments at lwn.net are very valuable - here's one where Lennart talks about cgroups in pid1: http://lwn.net/Articles/575793/

[gens]

I never called you dumb. Please do not put words in my mouth.

You didn't call me up on anything. You just asked me a rather ambiguous question (that has been asked countless times before), then proceeded to say you already know the answer but do not accept it. Not much point in answering something like that.

Anyway, Lennart's blog isn't the only source for information on systemd's design choices. Google will help you find several mailing list and forum threads, blogs and even presentations on the subject. Hell, you'll find several good posts on the subject even here on Phoronix forums if you're up to trawling for them amidst all the chaff and trolling. I simply do not have the inclination and frankly cannot spare the time to do this for you. Oh yeah, you'll find quite a lot of information on the subject presented in an entertaining way in GreatEmerald's Ace Attorney cases if you haven't already seen them. The links to these can be found in one of these threads, can't recall which one.

ok

you answered another persons post that was about why putting stuff on pid1 is bad
i asked you if you know and stated that i know
you answered me that i should google it, that it's simple
saying i should google something i said i know implies that you think i don't understand

ye, sry for interpreting what you wrote
i will write unnecessarily long posts so people do/don't miss the context of a talk
i guess talking died a long time ago on teh internets

and this is not the first time i ask this question
every time i got a "google" or similar response
and there is nothing wrong with not knowing something, i don't know nearly as much as some experienced engineer or admin
nobody was born with all the knowledge of the world

lennarts blog is no site to find out design decisions
it is about how to use some programs

and phoronix, as much as i like raw benchmarks, is not a place where you can get reliable facts about details
ofc there are exceptions like the radeon threads, mesa, nouveau, xorg, enlightenment, some distros sometimes and such
but not about systemd
frankly i started reading the debian mailing list only just before the votes started
but from what i read it was more of political BS then technicalities and ramifications of same
(ofc there was lots of technical discussions as they are all very knowledgeable and capable people but there was still more political BS)

bdw i wrote about the why after having 4-5 hours of sleep and before drinking coffe
also a reason why pid1 is so it can get exit statuses from processes
another thing a kernel can provide to any program ran under the SYS_ADMIN flag (root)

[gens]

You've described cgroups a bit here, but similar to that blog post prodigy_ linked to, you haven't described why it's bad that systemd does it.

I did some work for you, found a mention by Lennart about it (click):I'm sure there's more, but I'll leave that for you to research.

BTW, Lennart's Google+ page (especially the comments) is in general a very nice resource of info on the how and why of systemd, I suggest you go through it. The comments at lwn.net are many times insightful too, Lennart goes by "mezcalero" there.

...
IT NEEDS THAT INFORMATION TO SET UP CGROUPS
should i add exclamation marks ?

cgroups aka container groups are "containers" for processes
they were made afaik by oracle engineers, and they were made to isolate processes from other processes in the context of virtualization
but they were designed and made good, so good in fact that you could use them to separate users
and they are really modular in that you don't have to even have support for limiting the cpu or memory, you can choose what you want from them
they themselves use the kernel scheduler and process tracking (and memory management part for memory management ofc, if chosen)

they are easy to set up and very flexible since they are simple in design
simplest way is the cgroups virtual file system where you treat processes as files and create directories that act as groups
you can even have cgroups inside of cgroups (cgroupception hehe.. he)

again, pid 1 is not about cgroups
it helps set up cgroups, but it is not just about that
that link is about the cgroups part
cgroups can be set up anytime, you can even do it now

so stop fkin trolling
you are bringing the avg knowledge of the world down

and fk google plus

PS if Kay Sievers gets hes way you won't be able to simply set up cgroups, you will have to do C or set up systemd to do it for you
'cuz fuck the shell no ? what is it good for anyway

[Gusar]

so stop fkin trolling

I provide you with a link where Lennart explains why systemd does cgroups in pid1 and you accuse me of trolling?

There's only one possible response to this: Dafuq?

[makomk]

You name components, then say it's monolithic? I think you need to check a dictionary.

udev is completely seperate, journald is easy to replace right now, logind has a stable API that can easily be provided by systemd's successor. Next.

They may run as seperate processes, but they're tightly coupled - the only one that can currently run independently is udev, and it's not clear how long that will last. (After all, having udevd running is just as critical to launching other processes as having cgroups, and Lennart's already arguing that cgroup handling has to be in PID 1 for that reason. I fully expect udev to go the same way.) If you want to use anything other than systemd, you need to write and maintain your own implementation of logind, journald, cgroup management, and anything else systemd subsumes in the future. That's essentially the reason Ubuntu gave up on Upstart, it just wasn't practical for them to keep developing and maintaining their own versions of every key system component that systemd swallowed up and made dependant on itself.

logind would be a problem because it has a dependency on systemd, but as mentioned, udev is fine.

You missed the whole point, though, systemd is not monolithic, so that claim is bullshit. That's like saying Fedora is monolithic, because Gnome depends on X, which depends on the graphics drivers, which depend on the kernel. They're separate, ie the OPPOSITE of monolithic.

Note that's graphics drivers *plural* - as in, there are multiple competing graphics drivers, generally supporting more than one kernel (such as Linux+BSD or Windows+Linux). Systemd is closer to the old-fashioned proprietary Unix model where X servers were tied to specific graphics drivers and distributions, and adding a new driver meant forking or developing your own version of X.

Exactly, but my point was that most of the code in the systemd source tree does not actually run in PID 1, so that the claims that systemd does too much in PID 1 are a bit overblown, regardless of the actual need to put there what's actually in it.

The only parts of systemd that don't run as PID 1 are the ones providing functionality that used to be in separate packages entirely until systemd swallowed them all up, and even then much of their core functionality is still handled by the part of systemd running as PID 1. Essentially the entire init-related and service-management parts of systemd run as PID1 - if most of the code isn't part of PID 1, that's only because most of the code is NIH replacements for stuff other than the init system.

[TheBlackCat]

They may run as seperate processes, but they're tightly coupled - the only one that can currently run independently is udev, and it's not clear how long that will last. (After all, having udevd running is just as critical to launching other processes as having cgroups, and Lennart's already arguing that cgroup handling has to be in PID 1 for that reason. I fully expect udev to go the same way.) If you want to use anything other than systemd, you need to write and maintain your own implementation of logind, journald, cgroup management, and anything else systemd subsumes in the future. That's essentially the reason Ubuntu gave up on Upstart, it just wasn't practical for them to keep developing and maintaining their own versions of every key system component that systemd swallowed up and made dependant on itself.

They are specialized tools that rely on other specialized tools in specific, documented ways. That is the exact opposite of monolothic.

[tga.d]

Votes are in, N officially wins.

https://lists.debian.org/debian-ctte/2014/02/msg00595.html

[Rich Oliver]

What I'd really like to see is a SystemD package manager. Then along with Wayland we'd have a unified core of a desktop/ laptop/ tablet/ phone operating system that significant numbers of developers might want to target