Re: [LAD] Any package builders here?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <ralf.mardorf@...>, <paul@...>
Cc: <linux-audio-dev@...>
Date: Wednesday, June 1, 2011 - 4:38 pm

--_61d45e14-1d0d-4fb4-8001-0c16067a2480_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Since people usually are using Jack by a package=2C when thy use real-tim=
e

Neither jack=2C ardour or any other app actually uses the 'nice' option sim=
ply
because it is in the limits file. The file just says that if applications/u=
sers want
to use a value this is what they are allowed to configure themselves withou=
t
having to have root permissions and thereby invalidate a otherwise reasonab=
le
security policy. That is why having a 'nice' value in the file is useful: u=
sers can
tune the system without needing the recourse of having the root password.

> FWIW very often there are recommendations to _avoid_ a kernel-rt=2C since

lex

The issue is bigger than Linux. I was talking to Stings pianist=2C Kipper=
=2C on this
subject a while ago now. He had just bought the biggest FO Mac for his stud=
io.=20
After a few days he pretty much took it back to the store and dumped it on =
them=20
as it did not do what was written on the tin=2C demanding that they make it=
work.
They had to tune it. OK=2C it finally did what he needs but the only differ=
ence is=20
that either you have to do the work or somebody else does. Linux in itself =
is not=20
the issue.

> IMO it doesn't make sense to package audio and MIDI applications without

Again=2C this is not limited to Linux and the PAM limits file is not in its=
elf the solution.=20
The limits file only enables the possibility that applications can ask for =
what devos
think is optimal for their function and that somebody can configure an opti=
mised=20
system without having to be root. That means the limits.conf should give th=
at user=20
or group sufficient access to all the resources that they might need. That =
includes
negative 'nice' values for the cases where it might be useful.

Regards=2C ninck.
=

--_61d45e14-1d0d-4fb4-8001-0c16067a2480_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

&gt=3B Since people usually are using Jack by a package=2C when thy use rea=
l-time&gt=3B audio apps IMO it's ok to include it to a Jack package=2C =
anyway=2C IMO&gt=3B there should be a dependency setting without nice a=
nd with memlock.Neither jack=2C ardour or any other app actually us=
es the 'nice' option simplybecause it is in the limits file. The file j=
ust says that if applications/users wantto use a value this is what the=
y are allowed to configure themselves withouthaving to have root permis=
sions and thereby invalidate a otherwise reasonablesecurity policy. Tha=
t is why having a 'nice' value in the file is useful: users cantune the=
system without needing the recourse of having the root password.&g=
t=3B FWIW very often there are recommendations to _avoid_ a kernel-rt=2C si=
nce&gt=3B a distros 'default'=2C 'desktop'=2C 'generic' kernel should h=
ave the same&gt=3B capabilities and the kernel-rt should have disadvant=
ages. The resume&gt=3B then could be=2C that people wonder=2C that they=
can't use Linux for complex&gt=3B audio sessions.The issue is =
bigger than Linux. I was talking to Stings pianist=2C Kipper=2C on this=
subject a while ago now. He had just bought the biggest FO Mac for his stud=
io. After a few days he pretty much took it back to the store and dumpe=
d it on them as it did not do what was written on the tin=2C demanding =
that they make it work.They had to tune it. OK=2C it finally did what h=
e needs but the only difference is that either you have to do the work =
or somebody else does. Linux in itself is not the issue.&gt=3B =
IMO it doesn't make sense to package audio and MIDI applications without&gt=3B packaging the environment to use those apps.Again=2C this i=
s not limited to Linux and the PAM limits file is not in itself the solutio=
n. The limits file only enables the possibility that applications can a=
sk for what devosthink is optimal for their function and that somebody =
can configure an optimised system without having to be root. That means=
the limits.conf should give that user or group sufficient access to al=
l the resources that they might need. That includesnegative 'nice' valu=
es for the cases where it might be useful.Regards=2C ninck. =

=

--_61d45e14-1d0d-4fb4-8001-0c16067a2480_--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 9:50 am)
Re: [LAD] Any package builders here?, Fernando Lopez-Lezcano, (Wed Jun 1, 5:14 pm)
Re: [LAD] Any package builders here?, Robin Gareus, (Wed Jun 1, 12:40 pm)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 3:38 pm)
Re: [LAD] Any package builders here?, Paul Davis, (Wed Jun 1, 11:27 am)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 4:10 pm)
Re: [LAD] Any package builders here?, David Robillard, (Wed Jun 1, 4:56 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 4:38 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 11:49 am)
Re: [LAD] Any package builders here?, Dominique Michel, (Wed Jun 1, 4:17 pm)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 4:24 pm)
Re: [LAD] Any package builders here?, Paul Davis, (Wed Jun 1, 12:06 pm)
Re: [LAD] Any package builders here?, David Robillard, (Wed Jun 1, 3:06 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 1:11 pm)