From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Sun, 16 May 2010 09:37:19 -0600 From: EBo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <5F6D7D62-ABA5-4426-B8CF-28980B2511E8@fastmail.fm> References: <6aaf2d79af665bf1905db13e44e194e5@quanstro.net> <3c68655ad1dadf393d44b4a945abbd7a@swcp.com> <26f3b3b7fc6f7e8e8d90094305925bdd@kw.quanstro.net> <5F6D7D62-ABA5-4426-B8CF-28980B2511E8@fastmail.fm> Message-ID: <2e306ac633d435a597383e9148dba082@swcp.com> User-Agent: RoundCube Webmail/0.3.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] nupas update Topicbox-Message-UUID: 24a68756-ead6-11e9-9d60-3106f5b1d025 > Indeed, Gnu/Linux is almost unique as an operating system in suffering > from an inconsistent base system which, without going into detail, is > at the very least a huge abuse of everyone's time. and since plan 9 has a consistent back most of the rigmarole is not necessary, but some is. Before people start arguing that it *will* lead to inconsistancies and gnu/linux'isms it doe not have to. A canonical can be kept separate from any avant garde changes. > The problem I see here is like this: > > 1: A consistent base system is extremely desirable. > 2: Some parts of the base system sometimes need to be replaced. > 3: It is often desirable to be able to safely experiment with > replacement basesystem parts. > > Point 2 raises the questions of which parts, and when. Perhaps upas > should be replaced with nupas in the official distribution. > > Point 3 is the only one which suggests a package manager, I would debate that point 2 would also benefit, but that is a minor issue. > but it > equally alternatively suggests using a filesystem with history, or > perhaps care on the sysadmin's part to archive all files which will be > replaced by the new installation. >>From personal experience with taking the backup approach, this works fine until you forget about it once, and it also results in a huge number of copies of the system/source laying around. This is less an issue in this day and age of cheap disks, but > Automated solutions are of course > possible, but I don't think there is one which solves conflicts > between packages to everyone's satisfaction. So the question is what functionality are people looking for? EBo --