From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 27 Mar 2010 12:54:59 -0400 To: 9fans@9fans.net Message-ID: <202b36ec0f14adf4b09e53052147ccc8@brasstown.quanstro.net> In-Reply-To: References: <20100325114948.GA7249@polynum.com> <31C84C15-2EE3-46CA-BE9F-48F20886ADF7@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] Man pages for add-ons Topicbox-Message-UUID: f5b8d6c4-ead5-11e9-9d60-3106f5b1d025 > Also, is the size of the namespace list an issue? how does history(1) work in the face of a complicated namespace? we get buy now because the rules are pretty simple. if you want to find how the modifications to /386/lib/libc.a, you know where that is. if you bind 100 packages on top of /386/lib, it becomes necessary to deconstruct namespaces continually. the abstraction of namespace starts to break down. i think it makes more sense to optimize for the common case — using packages, rather than the uncommon questions like "what's in this package". > > I'm thinking over the idea that we're bumping up against the practical limits > > of hierarchal file systems as a means for organising stuff, but I've no idea > > what else might work. > > Google's approach is not to bother sorting things out. Use searches > to find data you want. You can still do some sorting in things like > gmail, but you don't need to. what google uses for its search tables or custom applications might not be that interesting in the context of a general purpose operating system. - erik