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.
