12 Jan
2014
12 Jan
'14
5:03 p.m.
Le Mon, 13 Jan 2014 02:39:08 +1100 (EST),
"Patrick Shirkey" <pshirkey(a)boosthardware.com> a écrit :
On Mon, January 13, 2014 2:28 am, Dominique Michel wrote:
I can only hope you will succeed with that.
Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
"Patrick Shirkey" <pshirkey(a)boosthardware.com> a écrit :
Well we also see similar issues with PA and JACK. The reasoning
appears to be that the different camps are not really interested or
motivated to scratch each others itches and no one is being paid to
do the dirty work to make sure the corner cases are being polished.
I am working on getting some official funding for the latter so this
issue interests me from that perspective.
On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote:
With the cgroups, that flexibility exist. One of the main point
of the cgroups is to be flexible enough to be setup for any possible
use case. But with a systemd system, that flexibility doesn't exist
any more, because the only possible "normal" use case permitted by
systemd is to run a GUI (as stated by the "normal" one in charge of
this mess).
It is more than 1 year I use the cgroups within an openrc system,
and you can do whatever you want with the cgroups. The same apply
for sysv init system.
What made me mad in that story, is not because it is a bug into
systemd which made a kernel function to misbehave, I know very well
that the only one that doesn't make bugs is the one that doesn't
make code, but this is the complete lack of consideration for other
needs than what he consider to be the needs of a "normal desktop
user". Which strongly suggest users with other needs are abnormal
users. Which in turn imply that person is a racist when he suggest
I am abnormal. And I am not the only one, systemd will break any
cgroup configuration for any other use case than to run a GUI.
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 found the reason here:
http://article.gmane.org/gmane.linux.kernel/1063354
"Lennart Poettering:
Well, this feature is... completely irrelevant for normal desktop
people.
...
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)."
Another completely idiotic stuff of this guy.
The point of the cgroups is it is possible to setup them for
whatever use will be made with a computer, and this guy think he
have the insane and pretentious capability to decide for every
single user of the use they will made with their computers, and
he is suggesting users doing something else are abnormal. He
must be stopped!
That patch is over three years old. It seems like you have found a
loophole in the logic that was used to justify it.
Granted, it's annoying but it just means we have to find a better
solution.
Similar to Fon's main objection to jack-session being *not flexible
enough*. We all knew it would cause problems for specific use cases
but we still haven't found a perfect solution to enable the
flexibility that Fons identified while also allowing people to get
on with the task at hand. Hence we have the less flexible but still
useful for most use cases version of jack session.
It seems the days are over when people had the time or motivation to
fix the tricky and annoying integration issues under there own steam.
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.
Dominique
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev