From owner-cvs-all@FreeBSD.ORG Tue Mar 2 22:07:54 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0288916A4CF; Tue, 2 Mar 2004 22:07:54 -0800 (PST) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1554343D1D; Tue, 2 Mar 2004 22:07:53 -0800 (PST) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.30) id 1AyPa9-00025V-Lt; Wed, 03 Mar 2004 12:10:13 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i2369PGx057959; Wed, 3 Mar 2004 12:09:25 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i2369PDb057929; Wed, 3 Mar 2004 12:09:25 +0600 (NOVT) (envelope-from danfe) Date: Wed, 3 Mar 2004 12:09:25 +0600 From: Alexey Dokuchaev To: Eivind Eklund Message-ID: <20040303060924.GA37692@regency.nsu.ru> References: <20040302153831.GK13724@sirius.firepipe.net> <200403021553.i22Frvhr030302@green.homeunix.org> <20040302161147.GK27008@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040302161147.GK27008@FreeBSD.org> User-Agent: Mutt/1.4.1i cc: "Brian F. Feldman" cc: "Jacques A. Vidrine" cc: Michael Nottebrock cc: cvs-all@freebsd.org cc: ports-committers@freebsd.org cc: Will Andrews cc: cvs-ports@freebsd.org cc: Michael Nottebrock Subject: Re: cvs commit: ports/audio/arts Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 06:07:54 -0000 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 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