Re: [LAD] JACK, cgroups and systemd
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Sun, 12 Jan 2014 22:37:34 +0100, Philipp Überbacher a écrit : > On Sun, 12 Jan 2014 22:20:06 +0100 (CET) > k...@aspodata.se wrote: > > > Dominique: > > > Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), > > > "Patrick Shirkey" 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" 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
On Sun, 12 Jan 2014 22:20:06 +0100 (CET) k...@aspodata.se wrote: > Dominique: > > Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), > > "Patrick Shirkey" 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" 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? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Dominique: > Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), > "Patrick Shirkey" 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" 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] beatslash-lv2 1.0.2
On Sat, 11 Jan 2014 20:41:35 + Aurélien Leblond wrote: > Hope that's clearer. > > Otherwise don't hesitate to ask :) Coll stuff. Thanks for the explanation. Dennis ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), "Patrick Shirkey" 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" 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 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. > > > > 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. > > > > 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. I can only hope you will succeed with that. > > 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [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" 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 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. > > 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. > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Mon, 13 Jan 2014 00:22:40 +1100 (EST), "Patrick Shirkey" 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 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. 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 > > > > -- > Patrick Shirkey > Boost Hardware Ltd > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [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: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK, cgroups and systemd
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
