Le Sun, 12 Jan 2014 22:37:34 +0100,
Philipp Überbacher <murks@email-addr-hidden> a écrit :
> On Sun, 12 Jan 2014 22:20:06 +0100 (CET)
> karl@email-addr-hidden wrote:
>
> > Dominique:
> > > Le Mon, 13 Jan 2014 02:39:08 +1100 (EST),
> > > "Patrick Shirkey" <pshirkey@email-addr-hidden> a écrit :
> > > > On Mon, January 13, 2014 2:28 am, Dominique Michel wrote:
> > > > > Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
> > > > > "Patrick Shirkey" <pshirkey@email-addr-hidden> a écrit :
> > > > >> On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote:
> > > > >> > Recently, I experimented with Debian sid, which use
> > > > >> > systemd. Systemd idea is nice, but its implementation is a
> > > > >> > catastrophe. It is more than one year I am using the kernel
> > > > >> > cgroups on gentoo to get rt scheduling with JACK, that
> > > > >> > without any trouble.
> > > > >> >
> > > > >> > On Debian, this is just impossible, because whatever I try,
> > > > >> > systemd insist to put what it think is good to have into
> > > > >> > the rt cgroup, which soon or later result in a complete
> > > > >> > system freeze with even dead magic keys. After loosing my
> > > > >> > time a few days with this, I removed Debian and installed
> > > > >> > gentoo instead.
> > ...
> > > I can understand this when some developers seam use their time to
> > > break the kernel and other important functions. We get udev
> > > breakage of firmware loading with some modules, the *kit story
> > > which will hopefully end with its disappearance, and now systemd
> > > which have a catastrophic implementation. And that's only the ones
> > > I am aware of.
> >
> > The sad part is that distributions and some programs have stopped
> > to respect the local administrator, by implementing more and more
> > policy.
> >
> > Regards,
> > /Karl Hammar
>
> The usual answer that I get for criticism like that is: "Well, you can
> change it.". The problem is that the effort to do so is often too
> large to make this a practical option.
>
> I'm not sure how it is in this case though, is it possible to change
> the behavior of systemd without code change?
No, in the same link I put in the first mail, Lennart say:
"In fact, I just prepped a patch to systemd to move every service and
every user session into its own cgroup in the 'cpu' hierarchy (in
addition to the group it already creates in the 'systemd' hierarchy). On
a system that runs systemd for both managing users and sessions this
means you are already half-way at what you want."
He concede this systemd patch is onhly half of what the kernel can do
when correctly used.
And he conclude:
"Well, if I make behaviour like this default in systemd, then this means
there won't be user setup for this. Because the distros shipping systemd
will get this as default behaviour."
His is talking about implementing in systemd something similar to the
automatic cgroups stuff if the kernel. For what I know, this is the
only thing that is implemented into systemd for the cgroups, and it is
only cosmetic possibilities to configure them with systemd.
This is way I also think we are not the only ones concerned, but any
body using something else than the automatic kernel cgroups stuff is
concerned.
>
> I do try to stay away from things that I don't need (polkit, systemd,
> PA, *kit, ...) but it's not always possible. I can hardly maintain
> an init system in parallel to the one my distribution uses.
It is why I replaced debian by gentoo. It it even an udev fork,
eudev, which is udev without the crap. Some of my USE flags are
"-policykit -consolekit -udisks -udisks2 -pulseaudio", and I masked
udev and installed eudev instead.
Anyway, I launched another discussion on that topic on systemd
email list: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
http://lists.freedesktop.org/archives/systemd-devel/2014-January/016110.html
As I understand it, the problem is related with a basic miss-conception
of what an user is doing with its computer. For peoples like Lennart (it
is other like him at freedesktop and in some distributions, and maybe
also elsewhere, the users are running a modern GUI. For them, it is 3 of
them, kde, gnome and xfce, and all other use cases are not relevant to
them. In other words, for them, an user doesn't work with its computer
but he is running a modern GUI.
Beside to not use systemd, the only solution to solve that mess is to
rewrite the cgroups API of systemd, so that it will support all the
cgroups features, and not only a subset, and so that the users can
configure it. Maybe he will put a java script interpreter into systemd
-:)
Dominique
>
> Regards,
> Philipp
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jan 13 04:15:02 2014
This archive was generated by hypermail 2.1.8 : Mon Jan 13 2014 - 04:15:02 EET