Date: Wed, 3 Mar 2004 12:09:25 +0600 From: Alexey Dokuchaev <danfe@nsu.ru> To: Eivind Eklund <eivind@freebsd.org> Cc: Michael Nottebrock <michaelnottebrock@gmx.net> Subject: Re: cvs commit: ports/audio/arts Makefile Message-ID: <20040303060924.GA37692@regency.nsu.ru> In-Reply-To: <20040302161147.GK27008@FreeBSD.org> References: <20040302153831.GK13724@sirius.firepipe.net> <200403021553.i22Frvhr030302@green.homeunix.org> <20040302161147.GK27008@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040303060924.GA37692>