From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by ewsd; Thu Jan 23 19:40:14 EST 2020 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B56AA22083 for <9front@9front.org>; Thu, 23 Jan 2020 19:40:12 -0500 (EST) Received: from imap35 ([10.202.2.85]) by compute1.internal (MEProxy); Thu, 23 Jan 2020 19:40:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=+QkkmYXyxFgOcdQk9qMOny6mAzlpH6y I6OQt6VWk+ZU=; b=MrwfnezwDIAOdpx1pfhkzVPpJGMOAjUkG4LvBFwq4ydC5n1 S1q3i/+CznlPhssNsM5Oxh2LuWPP1p3vhEng1IYOzdWNYxslZiDHVA/zSIX/pP61 1mfwaOR0oiY0syG0aiyKPoyG5k7vwGDH5yYlSz+7/5NykWvz1BeS7ivRRT2LAuad F2GroKhS8GNtrMwXN2LAagC0EGdE+W0XJBD5ZyxfUCuKZKLjwQPLiDm18Z6pQClr Io3YqaQc+wXS7ckkCuQjvECp0oCO0GlOi/NVt+qpXF0BLvtZt+UP5BEl1JQAd9/Z sQTofStilNUZETRPsXhjrLpXmZEkdig4S3cTnRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+QkkmY XyxFgOcdQk9qMOny6mAzlpH6yI6OQt6VWk+ZU=; b=jdD9HhbGpRu6+ZXq9qGH0g VEl0FnXVXgYfdNA7E3Vtpvek980XyIFAf9XyX2lHIHQsveIQtddkMe5PQukoNW8e fFoFrn4kgFoXmPb4FO2e07lozhgR0cTjbOPzSWqJnvTnqajrby4DVh5fMCIY2XO5 He/79fAU84ekD8kPFCwS7CoLYmlw2lVgT9n39O4U6ZLcowVWEr4YsigdaEwParlg GQLlSGSyscPKlZ9F+YVVJWm/Ou6JUn+dN/6yYKpjxpPTtMJDsbsAmF6ieMZ57yBa +AvYWXN0EZqHgg0A8JNTXkBsacPUWijRmeNOnYJiLAMxSCXyb8AXmOSMDiIr6JlQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdefgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdfgthhhrghnucfirghruggvnhgvrhdfuceovggvkhgvvgeh jeesfhgrshhtmhgrihhlrdhfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepvggvkhgvvgehjeesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7CA1314C009E; Thu, 23 Jan 2020 19:40:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-777-gdb93371-fmstable-20200123v1 Mime-Version: 1.0 Message-Id: <2c66fdc0-bc0c-4183-b054-f5a85904d452@www.fastmail.com> In-Reply-To: References: <5c2e3e1c-99a4-4caf-9ab4-615035aec1f8@www.fastmail.com> Date: Fri, 24 Jan 2020 00:39:52 +0000 From: "Ethan Gardener" To: 9front@9front.org Subject: Re: [9front] rio wishlists Content-Type: text/plain List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: core GPU NoSQL database On Thu, Jan 23, 2020, at 9:23 PM, hiro wrote: > does everybody understand what i mean with higher granularity > namespace sharing? it might be non-obvious if you don't know the linux > mount namespaces and their features. I think so. With my idea, the sections of the namespace you could change with env vars are fixed at compile time. I mean there might be just one var for cons kbd mouse and draw, or there might be two, but that's about it. File namespacing allows all sorts of detail changes which the program/library authors may not have considered. > i might be all wrong about this, but then i still would like to see a > more generalized mechanism that is self-similar and orthogonal to > everything else. > On Thu, Jan 23, 2020, at 10:42 PM, Julius Schmidt wrote: > One mechanism would be turn the namespace into a tree of commands, which > can then be shared only partially. > For instance, /dev could be a node in the tree which is shared among > most/all programs. Sounds like what I intend for my Forth, but that's an entirely different concept. :) > Another approach would be to give mount/bind commands a number indicating > priority, but I don't have a clear picture how that would work. I don't think I quite understand either of these, but they inspired this "namespace priorities" idea: A process may have multiple namespaces, each with a different priority. Files are searched for in the highest-priority namespace first, then if they're not found, the next highest, etc. Rio would then pass two namespaces to each of its children, the global namespace it itself inherited as a low priority, and a high-priority private namespace with only its window-specific files. (This also seems to provide a better means of union mounting. What happens if Rio inherits multiple namespaces in this scheme? Some options: A: They could all look like one single namespace with rio unable to distinguish between them. B: Priorities are numbers, the priorities of inherited namespaces are reduced. C: Namespaces occupy a linked list. A namespace's priority is simply determined by its position in the list. C is by far my favourite, linked lists are so powerful in this context. One of the biggest reasons I like Forth so much is the power given by the dictionary being a linked list. B has the same problem as BASIC and APL with their line numbers and goto. :) Both B and C have a little problem: What *exactly* is inherited by child processes? Are the numbers/is the list copied to each child, or can the child mess with the priorities of its parent? Grandparent? I suspect it would be enough to always copy the priorities, but I'm tired and need to stop thinking now.