Debian Init System Discussion Is Still Unsettled

[gens]

Well, KDE now uses the startkde shell script to, well, start the KDE environment, and startkde is a complicated, old, unreliable minefield of a script, and something that systemd could do much better with its user sessions in a reliable, consistent and easily debuggable manner. Similar thing with KDM, it's a huge piece of old code that is extremely difficult to debug and change, and it seems that there aren't any people left who actually know how the thing works to begin with (those who try to figure it out seem to get a headache). So KDE plans to get rid of both as soon as they can, and replace them with superior alternatives (for KDM, they were thinking of SDDM or LightDM, probably the former). Probably in time for KF5 launch.

would you mind posting the startkde script, i don't have kde installed
would be grateful

people have been yelling "sysvinit is complicated" for a while now
idk maybe on fedora it is, i know only slackware BSD stile sysvinit (sysvinit is only the "init" program, although you may say the accompanying scripts count too) and that is simple
when i get the time i'l check the debian scripts (got it on a laptop) if they are that complicated
(i do remember trying to understand fedora boot a while ago, it was not simple)

[gens]

PS
still haven't seen any technical reasons for the claimed superiority of systemD over everything else
(unless you count quotes out of context, or more precisely in very narrow context where existing solutions are not allowed)

[gens]

PPS

forgot to add to socket activation talk

there is one other, similar, thing that could save memory
its called, by what it does, "lazy library loading"
it is something that really is complicated to do properly
and glibc does not do it (didn't find any other loader to do it either)

why not do that and call it a must have feature

[stevenc]

there is one other, similar, thing that could save memory
its called, by what it does, "lazy library loading"

Call me old fashioned, but when you mention sockets being opened and a service being spawned on-demand, I think of:

http://man.freebsd.org/inetd

"The inetd utility appeared in 4.3BSD"
"4.3BSD was released in June 1986"

But systemd can add cron and syslog to its list obnoxiously reinvented services, which developers will be told to now learn and then rewrite their software to accommodate. The same thing all over again in another couple of years no doubt.

[erendorn]

Call me old fashioned, but when you mention sockets being opened and a service being spawned on-demand, I think of:

http://man.freebsd.org/inetd

"The inetd utility appeared in 4.3BSD"
"4.3BSD was released in June 1986"

But systemd can add cron and syslog to its list obnoxiously reinvented services, which developers will be told to now learn and then rewrite their software to accommodate. The same thing all over again in another couple of years no doubt.

Resource management (cgroups), and correct restart of processes, and their dependent processes, even when started by different means.

[Akka]

Resource management (cgroups), and correct restart of processes, and their dependent processes, even when started by different means.

This post frome tomegun at the arch forum is good as why Arch switched to systemd https://bbs.archlinux.org/viewtopic....49530#p1149530

[erendorn]

This post frome tomegun at the arch forum is good as why Arch switched to systemd https://bbs.archlinux.org/viewtopic....49530#p1149530

nice post, I didn't realize that by using socket buffers you could actually do without dependency and starting orders. Cool stuff.

[gens]

Resource management (cgroups), and correct restart of processes, and their dependent processes, even when started by different means.

http://cateee.net/lkddb/web-lkddb/PROC_EVENTS.html

even when started by any means
simple, took me 20 sec to find

edit: it's also netlink, so more efficient then dbus

[erendorn]

http://cateee.net/lkddb/web-lkddb/PROC_EVENTS.html

even when started by any means
simple, took me 20 sec to find

edit: it's also netlink, so more efficient then dbus

Okaaay.. you know what "management" means?

[gens]

Okaaay.. you know what "management" means?

yes
most of it is done by cgroups
"On their own, the only use for cgroups is for simple job
tracking. The intention is that other subsystems hook into the generic
cgroup support to provide new attributes for cgroups, such as
accounting/limiting the resources which processes in a cgroup can
access.For example, cpusets (see Documentation/cgroups/cpusets.txt) allow
you to associate a set of CPUs and a set of memory nodes with the
tasks in each cgroup."

so all you need to do is to know when something is started and set it's cgroup.. policy i guess to whatever is defined somewhere
if you need to set something after the fact or dynamic or whatever, make a GUI or a daemon that does it

point is you do not need a special init system, nor patch every thing to do it

or is there something wrong with that ?

PS Kay Sievers wants to remove the cgroups virtual fs