Creating a distro based on glendix and gentoo

[vh4x0r]

Hi, I'm interested in contributing to the project for creation of a
distro based on Glendix and Gentoo. I have acquainted myself with
Glendix, and also have a lot of experience with Gentoo. Can you please
provide me with some pointers about where to start ?

--
To post to this group, send email to gle...@googlegroups.com
To unsubscribe from this group, send email to glendix+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/glendix?hl=en

[Rahul Murmuria]

Hi vh4x0r,

On Wed, May 19, 2010 at 2:51 PM, vh4x0r <vikraman....@gmail.com> wrote:
> Hi, I'm interested in contributing to the project for creation of a
> distro based on Glendix and Gentoo. I have acquainted myself with
> Glendix, and also have a lot of experience with Gentoo. Can you please
> provide me with some pointers about where to start ?
>

Sorry I missed you on IRC... so, you mentioned GSoC. The current
season is already underway and you cannot be part of it this summer.
So no money involved (just wanted to get that out of the way before we
discuss further) :P

Nice to hear that you have been playing with Glendix. A large part of
this project is to make key design decisions before actual work is
taken up. Your mentor is going to be Anant Narayanan. He is our
project lead, and is the only person you need to consult. He watches
this mailing list, but does not do so everyday... Hang in there for
his response.. :)

Looking forward to more updates from you on this mailing list.

--
Rahul Murmuria

[EBo]

On Wed, 19 May 2010 11:51:44 -0700 (PDT), vh4x0r
<vikraman....@gmail.com> wrote:
> Hi, I'm interested in contributing to the project for creation of a
> distro based on Glendix and Gentoo. I have acquainted myself with
> Glendix, and also have a lot of experience with Gentoo. Can you please
> provide me with some pointers about where to start ?

I have an experimental ebuild on sys-kernel/glendix-sources, and some
other stuff you can use as a basis to start if it would be at all helpful.
For the next while I am focusing on my plan9 work which was accepted for
this years GSoC. Some of that work might also be of use to backport to
Glendix.

EBo --

[Jens Staal]

[sorry about hijacking]

Actually I was thinking a bit recently.... what about an "inverse glendix"? That is, rather than porting Plan9 to Linux, how about porting Linux to Plan9?

The thought was basically - would it be possible to make some sort of Plan9 "NDISwrapper"/"FUSE" for Linux kernel modules for drivers, filesystems etc that could be mounted/run in either Plan9 or Plan9/APE userspace? If I have understood it correctly, this is what L4, Hurd and MINIX tries to do to get good hardware support fast. I am not saying that this in anyway would be a BETTER solution than Glendix, rather a complementary one geared towards people that are more Plan9 than Linux but still would like to be able to run it on their toaster without writing every driver themselves.

2010/5/19 EBo <e...@sandien.com>

[Jorden M]

It's called Linuxemu. I'm sure the developer would love help.

[Jens Staal]

As far as I understood it Linuxemu is a way to run GNU/Linux applications in a virtualized Debian on top of Plan9. The thing I was talking about was rather utilizing Linux (the kernel) for drivers etc like NDISwrapper used to be used to run Windows drivers in Linux until native drivers came along.

2010/5/19 Jorden M <jrm...@gmail.com>

[EBo]

There is also 9vx which I am helping Ron Minnich repackage for
TinyCoreLinux, and it was just recently added to TCL's standard package
list.

EBo -- e...@sandien.com

[Jorden M]

Oh. That's been discussed a bit on 9fans. Generally, the opinion is
that since Linux breaks the kernel API every 3 months, it would be a
useless effort. You'd have to provide a hell of a lot, too, since
Linux drivers don't talk exclusively to something like Apple's
DeviceKit.

[Jens Staal]

@EBO

That is definitely interesting. I read about a 9vx/TCL solution sometime ago. This is a lot more like what I was talking about (even if it still means that Plan9 "only" is virtualized under Linux)

2010/5/19 EBo <e...@sandien.com>

[EBo]

I'm still learning about Plan9, et al., but TCL is a micro-install Linux,
so you get Linux and Plan9. Also, the '#Z' device allows you to access the
linux file system, so depending on what you are trying to do it might be
easily doable.

EBo --

On Wed, 19 May 2010 23:49:12 +0200, Jens Staal <staa...@gmail.com>
wrote:

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >>> For more options, visit this group at
>> >>> http://groups.google.com/group/glendix?hl=en
>> >>
>> >> --
>> >> To post to this group, send email to gle...@googlegroups.com
>> >> To unsubscribe from this group, send email to
>> >>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> For more options, visit this group at
>> >> http://groups.google.com/group/glendix?hl=en
>>
>> --
>> EBo -- e...@sandien.com
>>
>> --
>> To post to this group, send email to gle...@googlegroups.com
>> To unsubscribe from this group, send email to
>>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

[Jens Staal]

That the kernel API breaks that fast is only important if you want to keep up with Linus' Linux. Let's say that you find all the drivers you ever would like to use in version 2.6.35 - then you could basically just use modules from this release indefinitely. A major update to support newer drivers would only be done when it was considered needed. I have no idea how the other OSes who tries to exploit linux drivers are doing it, though.

As for amount of work - probably lots and way over my competence. It was basically some random musings and I just liked to know how others thought about them.

2010/5/19 Jorden M <jrm...@gmail.com>

[Jorden M]

On Wed, May 19, 2010 at 6:00 PM, Jens Staal <staa...@gmail.com> wrote:
> That the kernel API breaks that fast is only important if you want to keep
> up with Linus' Linux. Let's say that you find all the drivers you ever would
> like to use in version 2.6.35 - then you could basically just use modules
> from this release indefinitely. A major update to support newer drivers
> would only be done when it was considered needed. I have no idea how the
> other OSes who tries to exploit linux drivers are doing it, though.
> As for amount of work - probably lots and way over my competence. It was
> basically some random musings and I just liked to know how others thought
> about them.

That helps narrow things but there's still a huge amount of code that
any driver can call out to. That would be a lot to port, and could be
impracticable as I'd bet that drivers call out to some pretty
Linux-kernel specific subsystems (sysfs, for one, which would not need
to be ported to Plan 9.) Yes it would be possible to `stub' all that
out, but you would have to make a potentially large framework just for
stubs, since preconditions and postconditions of your stub API calls
may have to be met to ensure that the drivers continue to function.

All in all, pretty damn hard. Linux is a large, complicated,
fast-moving code blob.

[EBo]

In order to pull this off you would wither have to work closely with the
Plan 9 folks (9fans more specifically), or fork the code and go your own
way. Problem is that if you propose this over on 9fans you will be
hammered with reticule and insults. Just read through the 9fans archive
for suggestions of doing anything like this and you will get a very clear
picture of what I mean. I see two ways forward. 1) fork and move on, or
2) embed youself in the pla9 community and start writing drivers (saying
nothing of your motivations). I made similar mistakes and paid for it.

[staalmannen]

I was looking around a bit and the Suckless.org Sta.li (http://
sta.li/) distribution that is in the works seems to be a pretty good
fit for a glendix-type distro, since it already tries to Plan9-like in
some ways (initiation scripts, static linking). Something built on
that (perhaps with a Gobo-hide patch to make a Plan9-like file
hierarchy) could be cool.

After reading through the different projects at Suckless, I came
across that wmii actually has a 9P interface (http://
wmii.suckless.org/). Sorry for my ignorance, but would it
(theoretically) be possible to "complement" the things that do not yet
work natively under Linux with Glendix-patches using Plan9port+wmii+P9
mount of wmii to /dev/draw? If the lack of /dev/draw is a temporary
"blocker bug" for some Plan9 stuff to work under Glendix, perhaps that
could be a temporary solution?

I suppose the bigger "blocker bug" is the private namespaces stuff.

I have no clear idea how the different Plan9 binaries are
interdependent and whether something like that would work.

[Jorden Mauro]

Wmii does not create a draw device. It uses 9p for control, more like
the FS rio or acme post.

You could implement draw on top of X11, or even the Linux framebuffer.

[staalmannen]

Thanks for explaining the difference. I guessed I had made a couple of
too simplistic assumptions.

On the other hand, would it be feasible to use a mix of native Plan9
on Glendix and Plan9port (static)binaries in the default /bin as
primary utilities and the regular GNU stuff in some sort of "APE"
directory? (something not recommended by the plan9port guys, but on
the other hand that is on a "normal" GNU/Linux distribution, whereas
this hypothetical glendix distribution -as far as I see- more would be
about proof-of-concept where the plan9port portion could be gradually
reduced as Glendix gets more and more native Plan9 binaries to execute
correctly).

On 31 Maj, 19:58, Jorden Mauro <jrm8...@gmail.com> wrote:
> Wmii does not create a draw device. It uses 9p for control, more like  
> the FS rio or acme post.
>
> You could implement draw on top of X11, or even the Linux framebuffer.
>

[Jorden Mauro]

You'll break programs that expect GNU options. grep -A, for example.

[Jens Staal]

Only if you got programs that expect such behaviour in the base system and not exclusively run them in the "APE" (chroot?) environment with legacy GNU binaries.

2010/6/2 Jorden Mauro <jrm...@gmail.com>

You'll break programs that expect GNU options. grep -A, for example.

On Jun 2, 2010, at 1:43 AM, staalmannen <staa...@gmail.com> wrote:

Thanks for explaining the difference. I guessed I had made a couple of
too simplistic assumptions.

On the other hand, would it be feasible to use a mix of native Plan9
on Glendix and Plan9port (static)binaries in the default /bin as
primary utilities and the regular GNU stuff in some sort of "APE"
directory? (something not recommended by the plan9port guys, but on
the other hand that is on a "normal" GNU/Linux distribution, whereas
this hypothetical glendix distribution -as far as I see- more would be
about proof-of-concept where the plan9port portion could be gradually
reduced as Glendix gets more and more native Plan9 binaries to execute
correctly).

On 31 Maj, 19:58, Jorden Mauro <jrm8...@gmail.com> wrote:

Wmii does not create a draw device. It uses 9p for control, more like
the FS rio or acme post.

You could implement draw on top of X11, or even the Linux framebuffer.

On May 31, 2010, at 1:10 PM, staalmannen <staal1...@gmail.com> wrote:

I was looking around a bit and the Suckless.org Sta.li (http://
sta.li/) distribution that is in the works seems to be a pretty good

fit for a glendix-type distro, since it already tries to Plan9-like in

some ways (initiation scripts, static linking). Something built on
that (perhaps with a Gobo-hide patch to make a Plan9-like file
hierarchy) could be cool.

After reading through the different projects at Suckless, I came
across that wmii actually has a 9P interface (http://
wmii.suckless.org/). Sorry for my ignorance, but would it
(theoretically) be possible to "complement" the things that do not yet
work natively under Linux with Glendix-patches using Plan9port+wmii+P9
mount of wmii to /dev/draw? If the lack of /dev/draw is a temporary
"blocker bug" for some Plan9 stuff to work under Glendix, perhaps that
could be a temporary solution?

I suppose the bigger "blocker bug" is the private namespaces stuff.

I have no clear idea how the different Plan9 binaries are
interdependent and whether something like that would work.

On 19 Maj, 20:51, vh4x0r <vikraman.choudh...@gmail.com> wrote:

Hi, I'm interested in contributing to the project for creation of a
distro based on Glendix and Gentoo. I have acquainted myself with
Glendix, and also have a lot of experience with Gentoo. Can you
please
provide me with some pointers about where to start ?

--
To post to this group, send email to gle...@googlegroups.com
To unsubscribe from this group, send email to glendix+u...@googlegroups.com

For more options, visit this group athttp://groups.google.com/group/
glendix?hl=en

--

To post to this group, send email to gle...@googlegroups.com
To unsubscribe from this group, send email to glendix+u...@googlegroups.com
For more options, visit this group athttp://groups.google.com/group/glendix?hl=en

--
To post to this group, send email to gle...@googlegroups.com
To unsubscribe from this group, send email to glendix+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/glendix?hl=en

[Jorden M]

Bind mounts would work, also, I'm just thinking the vast amount (and
size) of GNU/Linux programs would make things perform worse if you had
to set up some special environment for every one that gets run,
especially considering most of the programs running at any given time
will be native Linux programs, not the Plan 9 ports. But perhaps not.

[Jens Staal]

I think it is one or the other depending on a particular use case. For the supposedly vast majority of users Glendix or Plan9ports will probably just complement their standard GNU/Linux. For that use-case, there already are ports for Gentoo, for example. If Glendix would develop a "poster child" distro, however, I assume that it would benefit from highlighting its unique characteristics rather than just being another re-spin on the GNU/Linux theme with some added features.

Perhaps more a symbolic rather than technical observation - but most decisions made are not rational anyways...

2010/6/2 Jorden M <jrm...@gmail.com>

[Jorden M]

Not true. Since the Glendix kernel is just Linux with some patches, at
least the bare bones of the usual Linux system will be there to get
things to boot (and get networking, graphics, etc. working). Even if
you restrict yourself to what runs immediately from init up to a login
screen, you're going to have a lot of programs that will need to have
a special environment made for them in the event of /bin being filled
with Plan 9 programs.

Trying to figure out which programs depend on GNU features in binutils
programs so that they could be kept outside the special environment is
more work than it's worth.

Having separate namespaces for all plan 9 and Linux programs would
work and probably perform ok, but the barrier created by the
namespaces may make things very inconvenient. Note that the simple
solution of having separate $PATHs will not work, since many programs
will call binutils with the full path specified.

[Jens Staal]

I am curious to see how the Sta.li guys will deal with that issue actually. At least from their "outline" it seems like they are trying to purge their system as much as possible from GNU. Personally I have no strong feelings either way (about GNU), but I find it VERY interesting with projects trying to do something entirely different and innovative (hence me lurking around here asking stupid questions and coming up with impractical ideas).

Just another reflection on the "APE" chroot/bind idea (if possible). Another cool thing it would enable (if it is at all possible to make a base system that runs (relatively) purely on Plan9/Glendix and Plan9port binaries) would be the freedom to re-define the file system hierarchy for the base system to look like that on Plan9 (users in /usr rather than /home etc...), whereas it from within the "APE" environment would look like a standard file system hierarchy (since things would be mounted that way in the chroot/other chroot-like solution).

Thanks for coming up with healthy critisism.

2010/6/2 Jorden M <jrm...@gmail.com>

[Jorden M]

That would be relatively simple, I think, as long as you are ok with
splitting the plan 9/linux stuff into separate namespaces. /usr would
then simply be bind-mounted to /home in the other namespace.

Again, this would make things feel too separate, I think. e.g., I
couldn't in that scenario use 9term to navigate into /etc and edit a
file with sam without doing work first.

I should hasten to add that of course, there could be mutual binds
that let both namespaces peek into each other. That could be awkward,
but a sane design could perhaps make it work.

[Jens Staal]

Thanks!

I think I will scetch a bit futher on this but wait until the first Sta.li is out to use as a template. I imagine that it will be easier to move around clearly defined static binaries (in fact, probably will involve a lot of itterative "copy alternative binary to /bin and see what breaks after reboot of VM copy" kind of stuff since I am no expert in how these things work).

by the way... according to the Gentoo documentation init is handled by an rc script - is this the "same" rc as the Plan9-type rc or just similar names?

2010/6/3 Jorden M <jrm...@gmail.com>

[EBo]

Jens,

If you get this all pulled together I will take a look at it and see if I
cane break away a little time to write another Gentoo ebuild for it.

EBo --

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> >>>>>> For more options, visit this group
>> >> >> >>>>>> athttp://groups.google.com/group/
>> >> >> >>>>>> glendix?hl=en
>> >> >> >>>>
>> >> >> >>>>> --
>> >> >> >>>>> To post to this group, send email to
gle...@googlegroups.com
>> >> >> >>>>> To unsubscribe from this group, send email to
>> >> >> >>>>>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> >>>>> For more options, visit this group
>> >> >> >>>>> athttp://groups.google.com/group/glendix?hl=en
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> To post to this group, send email to gle...@googlegroups.com
>> >> >> >>> To unsubscribe from this group, send email to
>> >> >> >>>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> >>> For more options, visit this group at
>> >> >> >>> http://groups.google.com/group/glendix?hl=en
>> >> >> >>
>> >> >> >> --
>> >> >> >> To post to this group, send email to gle...@googlegroups.com
>> >> >> >> To unsubscribe from this group, send email to
>> >> >> >>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> >> For more options, visit this group at
>> >> >> >> http://groups.google.com/group/glendix?hl=en
>> >> >> >
>> >> >> > --
>> >> >> > To post to this group, send email to gle...@googlegroups.com
>> >> >> > To unsubscribe from this group, send email to
>> >> >> >

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> > For more options, visit this group at
>> >> >> > http://groups.google.com/group/glendix?hl=en
>> >> >>
>> >> >> --
>> >> >> To post to this group, send email to gle...@googlegroups.com
>> >> >> To unsubscribe from this group, send email to
>> >> >>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> >> For more options, visit this group at
>> >> >> http://groups.google.com/group/glendix?hl=en
>> >> >
>> >> > --
>> >> > To post to this group, send email to gle...@googlegroups.com
>> >> > To unsubscribe from this group, send email to
>> >> >

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/glendix?hl=en
>> >>
>> >> --
>> >> To post to this group, send email to gle...@googlegroups.com
>> >> To unsubscribe from this group, send email to
>> >>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> >> For more options, visit this group at
>> >> http://groups.google.com/group/glendix?hl=en
>> >
>> > --
>> > To post to this group, send email to gle...@googlegroups.com
>> > To unsubscribe from this group, send email to
>> >

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> > For more options, visit this group at
>> > http://groups.google.com/group/glendix?hl=en
>>
>> --
>> To post to this group, send email to gle...@googlegroups.com
>> To unsubscribe from this group, send email to
>>

glendix+u...@googlegroups.com<glendix%2Bunsu...@googlegroups.com>

>> For more options, visit this group at
>> http://groups.google.com/group/glendix?hl=en
>>

--
EBo -- e...@sandien.com

[Jens Staal]

an e-build for the disk image of a modified Glendix/Plan9port/Sta.li system?

I suppose the "base architecture" should be relatively easy to "port" to different distros, where basically just the "APE" sandbox (chroot) is changed to whatever distro you prefer.

The ideas I outlined are still on a scetch-stage and I will probably first have to familiarize myself with Sta.li as it gets released (hopefully this will be easy since it should be relatively "clean", few "moving parts" (dynamically linked binaries), and small (apparently according to a gentoo discussion about it, most /bin:s come from OpenBSD, which is an interesting twist).

2010/6/3 EBo <e...@sandien.com>

[Jens Staal]

First: sorry about spamming the list with these ideas of mine. I just got inspired :) (tell me to stop if you find it annoying)

I just found that when Sta.li comes out, my planned work might already be half-done

http://www.mail-archive.com/d...@suckless.org/msg03834.html

Apparently some on the [dev] mailing list of Sta.li want to use Plan9port binaries instead of OpenBSD ones where possible. This will simplify stuff somewhat for the Glendix implementation, since it then only involves replacing the plan9port ones with native plan9 (the ones that currently can run on glendix, that is) ones after a glendix-patched kernel has been compiled for it. :) For the file system hierarchy, I will just have to think about whether it is "worth it" or not.

Look forward to play with it :)

2010/6/3 Jens Staal <staa...@gmail.com>