12 Jan
2014
12 Jan
'14
12:56 p.m.
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!
Regards,
Dominique
12 Jan
12 Jan
1:01 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
On Sun, Jan 12, 2014 at 01:17:43PM +0100, Dominique Michel wrote:
Recently, I experimented with Debian sid, which use
systemd.
No, the default is still syvinit.
apt-get install sysvinit
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
2:21 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
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 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.
--
Patrick Shirkey
Boost Hardware Ltd
4:06 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
"Patrick Shirkey" <pshirkey(a)boosthardware.com> a écrit :
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.
Dominique
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.
--
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
4:38 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
On Mon, January 13, 2014 2:28 am, Dominique Michel wrote:
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.
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.
--
Patrick Shirkey
Boost Hardware Ltd
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.
5:03 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
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
10:20 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
Dominique:
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:
> > Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
> > "Patrick Shirkey" <pshirkey(a)boosthardware.com> 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
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
10:37 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
On Sun, 12 Jan 2014 22:20:06 +0100 (CET)
karl(a)aspodata.se wrote:
Dominique:
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?
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.
Regards,
Philipp
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:
> > Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
> > "Patrick Shirkey" <pshirkey(a)boosthardware.com> 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
13 Jan
13 Jan
1:06 a.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
Le Sun, 12 Jan 2014 22:37:34 +0100,
Philipp Überbacher <murks(a)tuxfamily.org> a écrit :
On Sun, 12 Jan 2014 22:20:06 +0100 (CET)
karl(a)aspodata.se wrote:
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.
Dominique:
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? 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:
> > Le Mon, 13 Jan 2014 00:22:40 +1100 (EST),
> > "Patrick Shirkey" <pshirkey(a)boosthardware.com> 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
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:47 a.m.
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 run sid, however continue to use sysvinit.
--
Joel Roth
4:36 p.m.
Le Sun, 12 Jan 2014 16:46:56 -1000,
Joel Roth <joelz(a)pobox.com> a écrit :
Dominique Michel wrote:
That's not the matter. When I installed it, systemd was installed, and
it doesn't work with a non automatic cgroups configuration. For what I
know, it will be the same problem with any installation using
systemd, that because the cgroup feature of systemd is designed to only
work with the automatic kernel cgroups stuff, or to reproduce it.
In the case of a rt setup as the one on the jack wiki, this just fail
because systemd is designed to pollute the only cpu group we are using,
which is a real time group, with applications that have nothing to do
in it, and this is so bad it can result into a complete system freeze.
Dominique
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 run sid, however continue to use sysvinit. 
10:27 p.m.
On Mon, Jan 13, 2014 at 04:57:48PM +0100, Dominique Michel wrote:
That's not the matter. When I installed it,
systemd was installed, and
it doesn't work with a non automatic cgroups configuration. For what I
know, it will be the same problem with any installation using
systemd, that because the cgroup feature of systemd is designed to only
work with the automatic kernel cgroups stuff, or to reproduce it.
In the case of a rt setup as the one on the jack wiki, this just fail
because systemd is designed to pollute the only cpu group we are using,
which is a real time group, with applications that have nothing to do
in it, and this is so bad it can result into a complete system freeze.
I have systemd on ten or so machines, all of them doing quite
intensive audio work, and have no problems at all with it.
All these machines run Archlinux, the default setup limits
RT use to 95%.
Apart from that, I'd agree that systemd was a nice idea but
has grown into a bigger problem than whatever it tried to
solve. The comment by another poster was exactly to the point:
systemd defines policy while it should only provide methods
to implement policies.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
16 Jan
16 Jan
1:36 p.m.
On Mon, 13 Jan 2014 16:57:48 +0100
Dominique Michel <dominique.michel(a)vtxnet.ch> wrote:
In the case of a rt setup as the one on the jack wiki,
this just fail
because systemd is designed to pollute the only cpu group we are
using, which is a real time group, with applications that have
nothing to do in it, and this is so bad it can result into a complete
system freeze.
I'm not a fan of systemd for various reasons, but since my distro
archlinux uses it so do I. I also have no problems running my audio
apps SCHED_FIFO (realtime). In what way does systemd cause problems?
I also had a quick browse through /sys/fs/cgroups, and find no mention
of cpu.rt_runtime_us or anything similar?
Maybe it's an implementation issue on your distro?
--
Joakim
13 Jan
13 Jan
2:16 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
2014/1/12 Dominique Michel <dominique.michel(a)vtxnet.ch>
Recently, I experimented with Debian sid, which use
systemd.
As Adrian already noted: Debian Sid does not default to systemd. So what
version of systemd are you running actually?
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
It doesn't on Fedora. So there seems something wrong with the systemd
you're using.
Another completely idiotic stuff of this guy.
For sure...
So, let me ask again: Why and how are you using systemd on Debian?
He must be stopped!
Dead or alive?
2:25 p.m.
New subject: [Jack-Devel] JACK, cgroups and systemd
Am 13.01.2014 14:16, schrieb Felix Homann:
2014/1/12 Dominique Michel
<dominique.michel(a)vtxnet.ch
<mailto:dominique.michel@vtxnet.ch>>
Recently, I experimented with Debian sid, which use systemd.
As Adrian already noted: Debian Sid does not default to systemd. So
what version of systemd are you running actually?
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
It doesn't on Fedora. So there seems something wrong with the systemd
you're using.
Another completely idiotic stuff of this guy.
For sure...
So, let me ask again: Why and how are you using systemd on Debian?
I guess it's Aptosid ( debian/sid based distribution), they just
switched to default systemd in there last release. I'm a Aptosid user
for years, but I keep going with sysvinit for now.
He must be stopped!
Dead or alive?
4017
days inactive
4021
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
10 participants
participants (10)
-
Adrian Knoth -
Dominique Michel -
Felix Homann -
Fons Adriaensen -
hermann meyer -
Joakim Hernberg -
Joel Roth -
karl＠aspodata.se -
Patrick Shirkey -
Philipp Überbacher