Just curious

[staalmannen]

I am mostly an interested bystander of the project and have followed
it by looking at the commits. So how do you envisage the future
"glendix distro"? Will it be a completely "purist" Plan9 environment
with no GNU or X11? There has been some discussion about package
management etc - but the rest? As far as I understand a lot of
programs and drivers require Xorg (although perhaps Wayland will offer
an alternative) and the linux kernel itself is only (as far as I
understand) only compileable with GCC (although ICC also seems to work
and work is being done with Clang). I have tried to search for
attempts using the plan9 compiler for the linux kernel, but I do not
expect it to work since even compilers that attempt to be GCC-
compatible (like LLVM/Clang) have problems.

I am just a layman and will unfortunately not be able to help with any
of the technical issues, but if you find it interesting - feel free to
be speculative and share your fantasies about the future of this
project. :)

[Daniel Cordero]

On Tue, May 26, 2009 at 01:40:54PM -0700, staalmannen wrote:
>
> I am mostly an interested bystander of the project and have followed
> it by looking at the commits. So how do you envisage the future
> "glendix distro"?

I believe Glendix will just be installing a package on your chosen
distribution. Making a new distro means a lot of people might have to
change to something unwanted.

> Will it be a completely "purist" Plan9 environment
> with no GNU or X11?

Nope, GNU & Plan 9 may live in harmony in Glendix. GCC is pretty much
required for compiling a kernel, so that has to stay.

X11 may be discarded if draw(3) can be written without it. However, the
drivers that come with X11 might come in useful.

[Anant Narayanan]

On 26-May-09, at 11:20 PM, Daniel Cordero wrote:
>
> On Tue, May 26, 2009 at 01:40:54PM -0700, staalmannen wrote:
>>
>> I am mostly an interested bystander of the project and have followed
>> it by looking at the commits. So how do you envisage the future
>> "glendix distro"?
>
> I believe Glendix will just be installing a package on your chosen
> distribution. Making a new distro means a lot of people might have to
> change to something unwanted.

Daniel is correct for the most part, in the current state Glendix is
nothing more than a set of kernel patches and modules. In the future
however, Glendix will probably end up being a distribution of its own.
This is because we might find it difficult to maintain packages that
add "glendix functionality" to other existing distributions because of
the differences in kernel management; and also because Glendix is a
collection of several pieces of software that work together, we want
to ensure a correct and consistent user experience (atleast during the
alpha/beta stages in which we are now). Also, small things like
setting the default window manager to be rio, and the default editor
to be Acme will foster people to start using and appreciating Plan 9
software: something we can do in a distro of our own.

We aren't that far ahead in the road yet though, so maintaining
packages for other major distros is an option I am not ruling out.
That is certainly how you can test and develop Glendix today (ask me
for debian/gentoo packages!).

>> Will it be a completely "purist" Plan9 environment
>> with no GNU or X11?
>
> Nope, GNU & Plan 9 may live in harmony in Glendix. GCC is pretty much
> required for compiling a kernel, so that has to stay.
>
> X11 may be discarded if draw(3) can be written without it. However,
> the
> drivers that come with X11 might come in useful.

Glendix will allow both Plan 9 applications and existing Linux
applications to co-exist peacefully. Think of Glendix as your regular
linux distro will all the Plan 9 bits added - use them if you need
them. In a broader perspective, we hope that this will eventually lead
some Linux application developers to use Plan 9 functionality to
enhance their apps: and we are working very hard with the kernel
developers to ensure that all the Glendix patches are incorporated
upstream to facilitate this.

We are currently debating on what the best way to provide draw(3) is.
Wrapping over the linux framebuffer is tempting, but we might also
want to wrap over the large number of X11 drivers out there.

To summarise, you will be free to install & run any existing GNU/Linux-
based software on Glendix, because we are merely adding new
functionality to Linux - not removing or modifying existing features.

HTH,
Anant

[J.R. Mauro]

To summarise the summary: Glendix will be what you want it to be,
whether that is all Plan 9 (on a linux kernel) or all GNU with support
for P9 binaries, or somewhere inbetween. I predict the latter will be
most common, and that things will cross-pollinate (e.g., GNU programs
leveraging /net)

[staalmannen]

Thanks!

It seems like very realistic hopes I would say (extending the current
GNU/Linux ecosystem with plan9 features). I wish you all luck with the
project!

I suppose this also means that there might be a gradual cross-
polination where some parts actually may get wide acceptance even
before the complete port of plan9 is complete?
For example, if /net would be accepted in the mainline kernel and GNU
programs prior to the "completion" of the glendix project?

[J.R. Mauro]

On Wed, May 27, 2009 at 1:16 PM, staalmannen <staa...@gmail.com> wrote:
>
> Thanks!
>
> It seems like very realistic hopes I would say (extending the current
> GNU/Linux ecosystem with plan9 features). I wish you all luck with the
> project!
>
> I suppose this also means that there might be a gradual cross-
> polination where some parts actually may get wide acceptance even
> before the complete port of plan9 is complete?
> For example, if /net would be accepted in the mainline kernel and GNU
> programs prior to the "completion" of the glendix project?

Yes, supposing Murmuria makes advances. And I actually find time to
start helping him. (I swear, just give me a couple of weeks, school is
over, just have to move down to NYC and then I'll have more free time)

[staalmannen]

I saw a kernel commit by you for /dev/time where the feedback was that
it could possibly be added as a /staging/plan9 directory in the
mainline, but that you were afraid of flamewars. In a later reply
someone else questioned the plan9 compatibility of the format of /dev/
time (and not the design as such).

Do you often experience such "ideological" resistance to improving
linux with plan9 functionality?

On 27 Maj, 19:23, "J.R. Mauro" <jrm8...@gmail.com> wrote:

[J.R. Mauro]

On Thu, May 28, 2009 at 7:39 AM, staalmannen <staa...@gmail.com> wrote:
>
> I saw a kernel commit by you for /dev/time where the feedback was that
> it could possibly be added as a /staging/plan9 directory in the

Wait, a commit? I didn't know /dev/time made it anywhere (sad face)...

I don't want to abuse staging. It's already a controversy, and
straining it by falling back on Greg to always say yes is a bad idea.
FWICS, things in staging get less feedback than things put out on
LKML. The thing is that if no one cares, these little patches won't
get picked up. I don't think that shoehorning them into staging is
good.

Glendix will probably wind up having to host these stray patches, and
maybe someday we'll have an arsenal of examples of us getting Plan 9
code into Linux. Yes, in some ways, Linux is a popularity contest. But
it stems from people trusting others to not screw things up.

> mainline, but that you were afraid of flamewars. In a later reply
> someone else questioned the plan9 compatibility of the format of /dev/
> time (and not the design as such).

The discussion about the format was not ideological, it was logical.
/dev/time exposed jiffies, which isn't really something userspace
should necessarily see. Plan 9's man pages state that the latter 2
fields are implementation-defined. So the first 2 fields are ok, and
all that really matter. That and the formatting, which I patched for
Chris.

Also, the CUSE system will be out shortly, and something as simple and
non-performance-intensive as /dev/time will probably want to be done
in userspace.

>
> Do you often experience such "ideological" resistance to improving
> linux with plan9 functionality?

I experience resistance to improving Linux with Linux functionality.

[staalmannen]

OK thanks for that explanation (and it was probably not a commit - I
might have misinterpreted it, as I said before I am just a curious
layman so those things happen). The "ideological" resistance as I
interpreted it was mostly a comment about that plan9 compatibility
should not be a purpose on its own and that it (plan9) had an "ugly
interface".

Sorry for all the questions - feel free to tell me that I am annoying
if you get bothered by them ;)

On a completely different track - what would you feel would be the
"killer feature" to get into mainline from glendix? Would it be /net
or something else? Some stuff like /proc has been widely accepted so
why do you think that other useful things derived from the Plan9
design concept have not been integrated previously?

On 28 Maj, 15:24, "J.R. Mauro" <jrm8...@gmail.com> wrote:

[J.R. Mauro]

On Thu, May 28, 2009 at 10:52 AM, staalmannen <staa...@gmail.com> wrote:
>
> OK thanks for that explanation (and it was probably not a commit - I
> might  have misinterpreted it, as I said before I am just a curious
> layman so those things happen). The "ideological" resistance as I
> interpreted it was mostly a comment about that plan9 compatibility
> should not be a purpose on its own and that it (plan9) had an "ugly
> interface".

I don't remember anyone saying Plan 9 was ugly. Just that exposing
jiffies to userspace was dumb. Which, maybe it is. Like I said, those
last two fields can be whatever, so changing it isn't a big deal. And
IIRC, Chris did change it.

>
> Sorry for all the questions - feel free to tell me that I am annoying
> if you get bothered by them ;)
>
> On a completely different track - what would you feel would be the
> "killer feature" to get into mainline from glendix? Would it be /net
> or something else? Some stuff like /proc has been widely accepted so
> why do you think that other useful things derived from the Plan9
> design concept have not been integrated previously?

If by 'killer' you mean absolute fatality, then full Plan 9 support.
In the meantime, smaller goals like /net, improving /proc, true rio on
top of /dev/draw, etc. will be very nice milestones.

[staalmannen]

I found the link to the discussion by the way:
http://thread.gmane.org/gmane.linux.kernel/805491

Thanks for explaining things for me. I will definitely follow the
further development with interest and hope that new and amazing things
will breed (or "pollinate") out of this in the future ;)

On 28 Maj, 16:56, "J.R. Mauro" <jrm8...@gmail.com> wrote:

[J.R. Mauro]

Oh, I guess they did call Plan 9 ugly. But that's Pavel. I don't think
he likes anything.

[Christopher Brannon]

staalmannen wrote:
> I found the link to the discussion by the way:
> http://thread.gmane.org/gmane.linux.kernel/805491
>
> Thanks for explaining things for me. I will definitely follow the
> further development with interest and hope that new and amazing things
> will breed (or "pollinate") out of this in the future ;)
>

I'm the person who sent the original /dev/time patch.
The complaint about exposing jiffies was fixed.
The patch needs a couple more tweaks before it is fully Plan 9 compatible:
1. Specify the correct widths of values when calling snprintf. Trivial!
2. Allow the user to read the data using several partial reads. Plan 9
does this. My patch to Linux only allows reading at offset 0, so you
have to read the whole text string with one call. This shouldn't be difficult
to fix, either.

-- Chris

[J.R. Mauro]

On Thu, May 28, 2009 at 12:56 PM, Christopher Brannon
<cmbra...@gmail.com> wrote:
>
> staalmannen wrote:
>> I found the link to the discussion by the way:
>> http://thread.gmane.org/gmane.linux.kernel/805491
>>
>> Thanks for explaining things for me. I will definitely follow the
>> further development with interest and hope that new and amazing things
>> will breed (or "pollinate") out of this in the future ;)
>>
>
> I'm the person who sent the original /dev/time patch.
> The complaint about exposing jiffies was fixed.
> The patch needs a couple more tweaks before it is fully Plan 9 compatible:

Don't let the Negative Nancies on LKML stop you. We have support from
lots of people who want to bring in these Plan 9 support patches :)

[staalmannen]

I just thought of something else where Glendix actually provides
additional value compared to all other user-space or virtualized plan9
implementations (like Inferno, 9vx, 9ports etc). In contrast to those
- glendix might be used for incremental porting of complex apps with
lots of dependencies not filled by native plan9.

The thing I was thinking of (which I do not know if it is at all
feasible or just completely stupid) is for example porting of KDE
(which gives a full productivity suite and is made to be portable).
Several things are not possible to even start with in native Plan9
(for example, no c++ capable native compiler - I have a gut feeling
that LLVM/clang may be more portable than GCC since the only problem
officially recognized by LLVM for porting to plan9 is its dependencies
of a Bourne shell - and if rc could be replacing that...).
The nice thing is ofcourse that the whole porting in an hybrid
environment could give working semi-ported intermediates that run on
glendix but not on plan9 or GNU (a "kwin" on rio, a plan9-type Hal and
Dbus etc, which "downstream" (towards the kernel) talk Plan9 and
"upstream" (towards applications) have the usual interface of the
original components) - sort of the way glendix is built right now -
incremental improvements where each improvement has a potential use
even before full Plan9 compatibility is achieved.

Well.... I do not know if I am just rambling, but I thought this was a
pretty interesting and unique advantage of Glendix compared to other
ways of running Plan9.

On May 28, 4:56 pm, "J.R. Mauro" <jrm8...@gmail.com> wrote:

[Rahul Murmuria]

Hi staalmannen,

You are just beginning to realize what Glendix's motive is. One of our
strongest wishes is that regular Linux-based apps like KDE and GCC
start using the Plan 9 features we add to Linux in the future. Like
network based apps should use a /net virtual filesystem instead of the
socket ioctl calls. Basically do things "the Plan 9 way", while
staying in the Linux world. So, as a corollary, If a Linux apps ends
up using exclusively Plan 9-like features, then its executable should
work out-of-the-box in Plan 9. Like KDE should start using /dev/draw
instead of X11.

This will lead to what you just described. Others are welcome to
correct me, if I have failed to see your point.

Have fun!

--
Rahul Murmuria

[Jens Staal]

I think you understood me correctly :)

The more I think about it the smarter it seems - a very elegant way to
break a catch 22 where "good enough" legacy blocks better solutions -
and with more applications and tools available on top of the
alternative paradigm, more people will be ready to work on it.

I think this definitely can be the beginning of something big if
things really take off.

2009/7/20, Rahul Murmuria <rahul....@gmail.com>:

[J. R. Mauro]

I somehow don't see Aaron moving KDE to /dev/draw. I also really don't
see the benefit of crap like dbus and hal. Cross polination will be
nice, but it will also suck. Don't get your hopes up about anything
migrating. The only tasty thing people might want us /net

[Sam Fuqua]

I'm sorry if this has already been answered, but how close are we to a /net implementation for Linux?

--
Sam Fuqua
ΣΝ ΘΗ 454

[J. R. Mauro]

On Jul 20, 2009, at 10:51, Sam Fuqua <samf...@gmail.com> wrote:

I'm sorry if this has already been answered, but how close are we to a /net implementation for Linux?

Some of the basic structure is there for tcp. Actually generating new connections is not started yet. 10 percent maybe?

[staalmannen]

Is there a repo for /net with an RSS feed? I already subscribe to the
glendix Hg repo and the Private Namespaces repo to see how you guys
are doing :)

I really wish I knew how to code and stuff...

A completely unrelated (and probably herretic) question: does Wine
compile on APE + the plan9 ported X? If it did people who want to be
"bare metal" plan9 users could still enjoy a browser etc :P.

On 20 Juli, 17:02, "J. R. Mauro" <jrm8...@gmail.com> wrote:

> On Jul 20, 2009, at 10:51, Sam Fuqua <samfu...@gmail.com> wrote:
>
> > I'm sorry if this has already been answered, but how close are we to
> > a /net implementation for Linux?
>
> Some of the basic structure is there for tcp. Actually generating new
> connections is not started yet. 10 percent maybe?
>
>
>

> > On Mon, Jul 20, 2009 at 10:23 AM, J. R. Mauro <jrm8...@gmail.com>

> > wrote:
>
> > I somehow don't see Aaron moving KDE to /dev/draw. I also really don't
> > see the benefit of crap like dbus and hal. Cross polination will be
> > nice, but it will also suck. Don't get your hopes up about anything
> > migrating. The only tasty thing people might want us /net
>

> > On Jul 20, 2009, at 9:45, Jens Staal <staal1...@gmail.com> wrote:
>
> > > I think you understood me correctly :)
>
> > > The more I think about it the smarter it seems - a very elegant
> > way to
> > > break a catch 22 where "good enough" legacy blocks better
> > solutions -
> > > and with more applications and tools available on top of the
> > > alternative paradigm, more people will be ready to work on it.
>
> > > I think this definitely can be the beginning of something big if
> > > things really take off.
>

> > > 2009/7/20, Rahul Murmuria <rahul.is.a...@gmail.com>:

>
> > >> Hi staalmannen,
>
> > >> You are just beginning to realize what Glendix's motive is. One of
> > >> our
> > >> strongest wishes is that regular Linux-based apps like KDE and GCC
> > >> start using the Plan 9 features we add to Linux in the future. Like
> > >> network based apps should use a /net virtual filesystem instead of
> > >> the
> > >> socket ioctl calls. Basically do things "the Plan 9 way", while
> > >> staying in the Linux world. So, as a corollary, If a Linux apps
> > ends
> > >> up using exclusively Plan 9-like features, then its executable
> > should
> > >> work out-of-the-box in Plan 9. Like KDE should start using /dev/
> > draw
> > >> instead of X11.
>
> > >> This will lead to what you just described. Others are welcome to
> > >> correct me, if I have failed to see your point.
>
> > >> Have fun!
>

> > >> On Mon, Jul 20, 2009 at 1:58 PM, staalmannen<staal1...@gmail.com>

> ...
>
> läs mer »

[J. R. Mauro]

On Jul 22, 2009, at 15:23, staalmannen <staa...@gmail.com> wrote:

>
> Is there a repo for /net with an RSS feed? I already subscribe to the
> glendix Hg repo and the Private Namespaces repo to see how you guys
> are doing :)

/net is done in the main glendox repo. There just haven't been any
recent commits. We're all really busy.

>
> I really wish I knew how to code and stuff...

Visit the local bookstore.

>
> A completely unrelated (and probably herretic) question: does Wine
> compile on APE + the plan9 ported X? If it did people who want to be
> "bare metal" plan9 users could still enjoy a browser etc :P.

APE is probably nowhere near what wine needs. There is a Linux
emulator for plan9 that people run browsers in. I would personally go
this route but plan 9 won't support half the hardware on my laptop.

[staalmannen]

I just saw that Greg KH considered dropping the p9auth in 2.6.33 if
nobody was interested in it. I do not know how well this one fits with
the rest that Glendix tries to do and whether it provides some
functionality needed by the glendix project...

On 22 Juli, 21:27, "J. R. Mauro" <jrm8...@gmail.com> wrote:

> ...
>
> läs mer »

[jrm...@gmail.com]

> I just saw that Greg KH considered dropping the p9auth in 2.6.33 if
> nobody was interested in it. I do not know how well this one fits with
> the rest that Glendix tries to do and whether it provides some
> functionality needed by the glendix project...

Is Ashwin Ganti not willing to maintain it? Did Greg or anyone mention changes
that need to be done (I think they did)? Maybe Glendix can take over maintainership.
Should be easy since the driver is (AFAIK) complete, the userspace stuff needs taking
care of.

[Rahul Murmuria]

I wonder what the current status is, on p9auth. You guys got info? Did
Ashwin Ganti present it anywhere and has the details online? Its a bad
thing that it is scheduled for removal in .33 kernel.

I found while googling that the LTP project has written a test-case
for p9auth. (http://www.mail-archive.com/ltp-...@lists.sourceforge.net/msg08288.html).

I plan on examining p9auth and review the paper as well as the
implementation for one of my courses. I tried explaining factotum to a
security prof and he agreed for me to take this up as a review, only
because he was curious and thought it is a bad idea. :P

I have 3 weeks to do this in, and in the process we can learn about it
enough to include it as a part of Glendix. You guys got any pointers?

--
Rahul Murmuria

[J. R. Mauro]

I'd like to see someone maintain it instead of watching Greg drop it
from staging.



On Oct 7, 2009, at 23:41, Rahul Murmuria <rahul....@gmail.com>
wrote:

[staalmannen]

I wonder whether the Google Chrome OS and its "novel security
architecture" actually is the p9auth... it would make sense since the
initial publication was from a Google researcher...

On Oct 8, 5:41 am, Rahul Murmuria <rahul.is.a...@gmail.com> wrote:
> I wonder what the current status is, on p9auth. You guys got info? Did
> Ashwin Ganti present it anywhere and has the details online? Its a bad
> thing that it is scheduled for removal in .33 kernel.
>
> I found while googling that the LTP project has written a test-case

> for p9auth. (http://www.mail-archive.com/ltp-l...@lists.sourceforge.net/msg08288.html).