cvs commit: ports/audio/arts Makefile

[Alexey Dokuchaev]

On Tue, Mar 02, 2004 at 04:11:47PM +0000, Eivind Eklund wrote:
> On Tue, Mar 02, 2004 at 10:53:57AM -0500, Brian F. Feldman wrote:
> > Will Andrews <will at csociety.org> wrote:
> > > On Tue, Mar 02, 2004 at 07:47:52AM -0600, Jacques A. Vidrine wrote:
> > > > P.S.  I don't mean to pick on this port in particular.  I believe there
> > > > are other ports that install set-user-ID binaries where it is not
> > > > essential.  I just haven't had a chance to make a sweep of the tree yet
> > > > to identify them.
> > > 
> > > I agree with Michael - I'd rather have working software than
> > > a false sense of security, when it comes to desktop software.
> > > 
> > > If you are going to push a "make all setuid bits optional"
> > > agenda, I suggest coming up with a standard means of letting the
> > > administrator specify their policy regarding those.  You could
> > > also offer alternate means of achieving the effect that set-id
> > > wrappers/programs intend with their privileges.
> > > 
> > > Unfortunately, in arts' case, setpriority(2) is superuser-only.
> > > Perhaps in FreeBSD 5, we should start implementing standard means
> > > of allowing programs like artsd to call setpriority(2) without
> > > privileges, e.g. through MAC.
> > 
> > Is it setpriority(2) or rtprio(2)?  The latter was implied,
> 
> It's sched_setscheduler().  I think it sets up a real time scheduler (it
> looks like it), but the man page is not clear, and I'm not familiar with
> it from before.
> 
> > and it is NOT acceptable to have ports use rtprio(2) without consent
> > from the system administrator -- and not implicit consent, either.
> 
> It is inacceptable to have our desktop systems not work properly.
> Desktop users is where we recruit a large fraction of our developers.

As it's been said, real time priority is needed only when one stresses
their box with some disk I/O-intensive operation, e.g. extracting
mozilla tarboll.  Otherwise, its impact is negligible.  On the other
hand, disk activity might be an issue only is you have bunch of services
running (http/ftp/cvsup/etc) on the same box you run your desktop.
Since vast majority of desktop users does only run their desktop
environment software without any server-type services, disk-intensive
operations are pretty rare.  I doubt that our typical [desktop] user
extracts mozilla or X on a regular basis, moreover, I don't experience
any sound delays when playing xmms/dsp and extracting large tarboll (I
don't use any sound proxy like esound or arts, but there's enough
time-fractions for xmms to read and decode my oggs and mp3s).

Maybe we should _solve_ the problems like these, addressing issues of
concurrent disk usage et al for normal processes, instead of inventing
all those workarounds like setting high priorities?

./danfe