On Thu, Jan 20, 2011 at 02:11:49PM +0100, Tom Gundersen wrote:
At the moment I think the support is complete, and for me it has been 100% stable for some time. That said, much more widespread testing is required before it can really be said to be stable (so any testing and bug reporting would be highly appreciated, especially if you use lvm/raid/encryption). ... Any questions can be posed on this mailinglist, on the systemd thread in the forum or in #archlinux or #systemd on IRC, where myself ("tomegun") and "falconindy" can sometimes be found.
I'm using or being admin for at least 10 system using Arch, all of them used for audio processing (not the typical desktop multimedia stuff, but for professional music recording and reproduction systems driving up to 200 separate audio channels). All of them run between 10 and 30 different audio applications at any time. All applications used for 'pro' audio require threads to run in real-time mode (i.e. SCHED_FIFO), and the use of mlock() to avoid data being swapped out, again to ensure real-time behaviour. After years of problems and frustration,for the last two or three years we (the people using such audio apps on Linux) have finally got a system that allows normal users to do this (using ulimits and just two lines in /etc/security/limits.conf giving members of the 'audio' group the required privileges). So here's my question: will a system using systemd still allow this, *without* requiring source modifications to each and every application (to join a specific cgroup), and *whitout* every application requiring real-time or memory locks to be 'registered' somewhere ? As far as I've understood it would not. Which would make systemd an absolute no-go for users requiring this. ??? Ciao, -- FA There are three of them, and Alleline.