Plan 9 from Bell Labs 9fans@9fans.net
Date: Mon, 18 Jul 2011 11:32:17 +0300
Subject: Re: [9fans] novel userspace paradigms introduced by plan 9
That would be the only problem, yeah.
2011/7/17 Charles Forsyth fors...@terzarima.net:
CLONE_NEWNS?
privileged processes only
That would be the only problem, yeah.
2011/7/17 Charles Forsyth fors...@terzarima.net:
CLONE_NEWNS?
privileged processes only
On Monday 18 of July 2011 11:04:51 Balwinder S Dheeman wrote:
On 07/16/2011 04:23 PM, simon softnet wrote:
Please, don't let plan 9 and linux be interrelated in the future in any
way ...
Future plan 9 users have the opportunity to experience novel user-space
paradigms.
Why do they have
that's certainly a restriction, but a bigger one is that name spaces
really come into their own when many, even most, resources are represented
through the name space, and it makes sense to remap the name space to change
the actual resources accessed through a name. on Linux, significant things
On Sat, 16 Jul 2011 23:10:24 +0200
simon softnet ph.soft...@gmail.com wrote:
If it wasn't for this cancerous web applications ordeal, I would be happy
with OpenBSD rio,
and maybe with pure Plan 9 in the future ..
You'd be missing the best of Plan 9. Actually, I really feel we already have
CLONE_NEWNS?
2011/7/2 Jacob Todd jaketodd...@gmail.com:
Private namespaces.
CLONE_NEWNS?
privileged processes only
On 03/07/2011 23:08, andrey mirtchovski wrote:
they've changed everything else in unix, why hold so tightly to the clearly
unhelpful ideas?
because it's a cult. things don't make sense in cults. i encountered
the following quote the other day, which finally convinced me.
OK, maybe this is
Please, don't let plan 9 and linux be interrelated in the future in any way
...
Future plan 9 users have the opportunity to experience novel user-space
paradigms.
Why do they have to be sucked into the linux world?
Simon
On Mon, Jul 4, 2011 at 4:59 PM, Robert Seaton seat...@dupage.edu wrote:
I don't see why anyone combining ideas from Plan 9 into Linux hurts
Plan 9 as long as Plan 9 continues to exist.
On Saturday, July 16, 2011, simon softnet ph.soft...@gmail.com wrote:
Please, don't let plan 9 and linux be interrelated in the future in any way
...Future plan 9 users have the
Because it's more likely that users will settle with linux+some plan 9
features
instead of with pure plan 9
Simon
On Sat, Jul 16, 2011 at 9:12 PM, David Leimbach leim...@gmail.com wrote:
I don't see why anyone combining ideas from Plan 9 into Linux hurts
Plan 9 as long as Plan 9 continues to
On Sat, 16 Jul 2011 21:17:14 +0200
simon softnet ph.soft...@gmail.com wrote:
Because it's more likely that users will settle with linux+some plan 9
features
instead of with pure plan 9
Most of us have to anyway.
For now...
Simon
On Sat, Jul 16, 2011 at 9:12 PM, David Leimbach
If it wasn't for this cancerous web applications ordeal, I would be happy
with OpenBSD rio,
and maybe with pure Plan 9 in the future ..
Simon
On Sat, Jul 16, 2011 at 9:32 PM, Ethan Grammatikidis eeke...@fastmail.fmwrote:
On Sat, 16 Jul 2011 21:17:14 +0200
simon softnet ph.soft...@gmail.com
one might find http://www.glendix.org/ project interesting
2011/7/2 Robert Seaton seat...@dupage.edu:
Hello, 9fans!
...
one might find http://www.glendix.org/ project interesting
The project actually already uses a glendix patched kernel and much of
my upcoming work will be focused on porting more of Plan 9's syscalls
to the Linux kernel so that more native Plan 9 apps can be run on
Linux. :)
Which distro's version of text utils ? hehe ..
Let's not start an anti-linux flame war now ...
On Sun, Jul 3, 2011 at 1:31 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
lyn...@orthanc.ca wrote:
I don't see any meaning in Linux adopting some set of plan 9
commands...
Have you read the source code
Hey,
On 2 July 2011 19:36, dexen deVries dexen.devr...@gmail.com wrote:
linux'c `clone()' syscall (the underpinnings of fork()) actually do accept
CLONE_NEWNS, CLONE_NEWNET, CLONE_VM and other flags, pretty close to p9's.
Yeah, clone() is afaik compatible with rfork(), so long as you have
I know bloated GNU projects are generally frowned upon, but I think
it's quite interesting that GNOME's GVFS allows, afaict, per-process
synthetic filesystems. But clearly that's extremely ugly compared to
Plan 9.
and yet there's a key difference. this is a private joke amongst gnome
On 3 July 2011 12:55, erik quanstrom quans...@quanstro.net wrote:
and yet there's a key difference. this is a private joke amongst gnome
processes. i can give file references to gnome programs like
http://example.com
to a gnome proc. cat(1) won't accept the same reference.
Well yes, it
On Sun Jul 3 08:34:26 EDT 2011, c...@lubutu.com wrote:
On 3 July 2011 12:55, erik quanstrom quans...@quanstro.net wrote:
and yet there's a key difference. this is a private joke amongst gnome
processes. i can give file references to gnome programs like
http://example.com
to a gnome
On 3 July 2011 13:51, erik quanstrom quans...@labs.coraid.com wrote:
what i was trying to say is that even in that case, i think gio is a weak
model. it goes back to the vms/dos days where the method of access
becomes part of the name. that is, i need to know if it's accessed via
http or ftp
On Sun, Jul 3, 2011 at 8:06 AM, Connor Lane Smith c...@lubutu.com wrote:
Still, FUSE has extended attributes, so you
could e.g. configure a window manager just by setting attributes on
the 'window manager filesystem' root directory.
something like extended attributes can be accomplished by
I think what I'd say is the most novel userspace paradigm in Plan 9
is its pervasive synthetic filesystems. You have FTP filesystems and
so on with FUSE now, but writing something as flexible (technically)
as Rio still requires something other than FUSE. But more importantly,
since Plan 9
On Sunday 03 July 2011 19:57:16 Lyndon Nerenberg wrote:
Actually, what this discussion keep pointing out is the elegance of the
Plan9 authentication model vs. UNIX's superuser scheme. It's the lack
of a superuser that makes the whole namespace paradigm work in the first
place.
On Sun Jul 3 13:58:49 EDT 2011, lyn...@orthanc.ca wrote:
I think what I'd say is the most novel userspace paradigm in Plan 9
is its pervasive synthetic filesystems. You have FTP filesystems and
so on with FUSE now, but writing something as flexible (technically)
as Rio still requires
why do you think that the lack of a super user make per-process namespaces
work?
The fact that you own the hardware you are running on means there's no
need to provide enhanced priv's (such as root) to protect things like
mount(2). And if you do something stupid, the only damage you can do
why do you think that the lack of a super user make per-process namespaces
work?
The fact that you own the hardware you are running on means there's no
need to provide enhanced priv's (such as root) to protect things like
mount(2).
that's a property of per-process namespaces, not the
they've changed everything else in unix, why hold so tightly to the clearly
unhelpful ideas?
because it's a cult. things don't make sense in cults. i encountered
the following quote the other day, which finally convinced me. you
can't rationalize things with this sort of thinking:
It is out of
following this thread.
do something interesting.
- build a system with only plan9port binaries
- use the cap device in linux to authenticate yourself
as a user
- have init setuid to that user.
- figure out how to make linux work with no root user
Anything else is likely to be not that
Its a pdf about plan9 authentication in linux by one Ashwin Ganti, sorry for
the double post.
On Sun, Jul 3, 2011 at 3:38 PM, andrew zerger rhoyerb...@gmail.com wrote:
More info for people looking from the same vantage point as me..
This document is something I am about to read.. (I wasn't
More info for people looking from the same vantage point as me..
This document is something I am about to read.. (I wasn't sure what a cap
device in linux was, this was the most relevant google result.)
as a person who has spent the last three years exclusively in
user-level filesystems on Linux, I can safely say this -- my biggest
problem during that time has been the root user. from dealing with
programs which allow only root-level access (xen tools) to dealing
with programs who explicitly
something like extended attributes can be accomplished by layering file
servers.
or simply make a directory
Hello, 9fans!
I'm a GSoC student working on Plan 9 From Gentoo, a Gentoo project
to create a liveCD that comprises of a Gentoo base-system and a Plan
9-inspired userspace, instead of the typical GNU userspace.
However, I'm new to Plan 9, and I'm wondering if veteran 9'ers have
any suggestions
Private namespaces.
On Saturday 02 July 2011 18:15:17 Robert Seaton wrote:
(...)
Some of the things I have discovered so far:
* Sending things via plumber
(...)
you've made me realize i've been using plumber-like stuff before.
back on KDE 3.5, there was that `dcop' thingie that i've employed for plumbing
On Sat, Jul 2, 2011 at 8:29 AM, dexen deVries dexen.devr...@gmail.com wrote:
disclaimer: i'm not a plan 9 person for any viable value of `p9 person'
I'm in the same boat, but I aspire to be in the other boat. :)
-Jack
I have used gentoo extensively and plan9 for a few years now as well, and
this concept of namespaces for processes is a confusing but interesting
concept. maybe you could use grsec to limit the access to gentoo's file
system at a per-process level. This would be somewhat similar to what
plan9
On Saturday 02 July 2011 20:23:02 Eli Cohen wrote:
I have used gentoo extensively and plan9 for a few years now as well, and
this concept of namespaces for processes is a confusing but interesting
concept.
linux'c `clone()' syscall (the underpinnings of fork()) actually do accept
Plan 9 is good because it is a system designed with such principles in mind
from the start.
I don't see any meaning in Linux adopting some set of plan 9
commands...vanity..
On Sat, Jul 2, 2011 at 8:36 PM, dexen deVries dexen.devr...@gmail.comwrote:
On Saturday 02 July 2011 20:23:02 Eli Cohen
I don't see any meaning in Linux adopting some set of plan 9
commands...
Have you read the source code for their cat(1) ???
41 matches
Mail list logo
