From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:34:53 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F8E106566C; Mon, 14 Nov 2011 21:34:53 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF7D8FC14; Mon, 14 Nov 2011 21:34:53 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pAELYncl047631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 22:34:49 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1321306489; bh=nDRQVpxsw2VFlW17kpHQOsUzODopE+2oBXLbgvYhEzk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=PfEWT6SSYrWBKu9wAEPDJ8FL4X49bpqRD5QS9kyXgzSNqo/XXjrqPQRN9pK6dQQnr d6eyaYsMAUNMhKDQKYUmSZ0wdXUwhPDsUCiXEfGGutW+HgZSxdG3BcX8UYg3ljonLz ErG4NBfMR2XcxeH1qi2KSfmlDkBWDf+352EQvcO4= Date: Mon, 14 Nov 2011 22:34:49 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ed Schouten Message-ID: <20111114213448.GQ26743@acme.spoerlein.net> Mail-Followup-To: Ed Schouten , Doug Barton , arch@freebsd.org References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114092922.GA2164@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Doug Barton Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:34:53 -0000 On Mon, 2011-11-14 at 10:29:22 +0100, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20111113 23:57: > > If we're going to talk about making a change that's actually worth > > making, let's just move everything into / and get rid of /usr > > altogether. It served its purpose back when it came into being, but with > > modern disk sizes and the (unfortunate) prevalence of the "one big /" > > layout model, it's time in the sun is long past. > > Now that I think of it, it may be possible to sort of combine this with > my approach in a way that it doesn't break POLA for existing users. What > if we leave everything in the tree alone, but only modify the code, so > that any new installations on empty directory structures use the > following symlinks: > > - /sbin -> /bin > - /usr/bin -> /bin > - /usr/games -> /bin > - /usr/lib -> /lib > - /usr/sbin -> /bin Yes please, although it'll never happen :( Why can't we have all the base system in /bin, /lib, /etc with the usual /usr/src /usr/ports /usr/home /usr/compat and the kicker: have all ports install into /usr/bin and /usr/lib (yes, you read that right!) I know that /usr doesn't really stand for "user", so having these contain the third party apps that the user installed is a bit of a stretch, but it wouldn't be the first time in history that something changed its original meaning. (I left /usr/share and /usr/include as an exercise for the reader.) > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? No please don't, any serious installations have their own /home partition anyway. Also in the past, deleting /usr/local only meant you lost all installed ports and /usr/local/etc -- something you usually can easily recover from. Not so if /usr/local/home is where your real data lies. Cheers, Uli