9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jens Staal <staal1978@gmail.com>
To: rbnsw-plan9@yahoo.com.au,
	Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] GNU/Linux/Plan 9 disto
Date: Mon, 11 Jul 2011 18:41:06 +0200	[thread overview]
Message-ID: <CAK8RtFrvW2mT5ubAb73WqFJ563H_E-2YkYMY+rOXsSivAKSZGQ@mail.gmail.com> (raw)
In-Reply-To: <1310400339.71319.YahooMailClassic@web30908.mail.mud.yahoo.com>

Personally, I believe that a Plan9 target for a cross compiler might
be more interesting. GCC already added support for the Plan9 dialect
of C. If it also could be made to compile Plan9 binaries, it could be
used for an alternative self-hosting distro as the one you envisaged.

I am fully aware that this is quite herretic and probably not very
interesting for mainline Plan9.

2011/7/11  <rbnsw-plan9@yahoo.com.au>:
> Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.
>
> I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols.
>
> While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device  model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution.
>
> Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions.
>
> I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current
>  maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model.
>
> Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,
>
> Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...
>
>
>



  reply	other threads:[~2011-07-11 16:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 16:05 rbnsw-plan9
2011-07-11 16:41 ` Jens Staal [this message]
2011-07-11 16:59   ` Gorka Guardiola
2011-07-11 19:31     ` Charles Forsyth
2011-07-12  5:59       ` Pavel Zholkover
2011-07-12 15:13         ` [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto) Lucio De Re
2011-07-12 18:35           ` Francisco J Ballesteros
2011-07-13 18:31             ` Lucio De Re
2011-07-13 18:45               ` Lucio De Re
2011-07-14 18:59                 ` stephano zanzin
2011-07-14 20:21                   ` Lucio De Re
2011-07-14 20:35                     ` Iruatã Souza
2011-07-15  2:37                     ` Fazlul Shahriar
2011-07-22  4:40               ` Lucio De Re
2011-07-22 14:37                 ` Ethan Grammatikidis
2011-07-27  2:55                   ` kokamoto
2011-07-12 18:44           ` Skip Tavakkolian
2011-07-12 12:35       ` [9fans] GNU/Linux/Plan 9 disto Ethan Grammatikidis
2011-07-12  5:50     ` Jens Staal
     [not found]   ` <CACm3i_j1dxqY=sfunozAXRY+uhO83BnTodfpWvNb+4rSNouC_g@mail.gmail.c>
2011-07-11 17:43     ` erik quanstrom
2011-07-11 19:29       ` Charles Forsyth
2011-08-21 16:20         ` Enrico Weigelt
2011-08-21 17:27           ` erik quanstrom
2011-08-21 16:16   ` Enrico Weigelt
2011-07-11 17:56 ` hiro
     [not found] ` <CAFSF3XO7ejhGBq5Zqj1oL7UnnPf7naTtwbG56hN4k1fz3koxBw@mail.gmail.c>
2011-07-11 18:12   ` erik quanstrom
2011-07-12  0:10     ` hiro
2011-07-12 13:35       ` Ethan Grammatikidis
2011-07-12 17:18         ` hiro
2011-07-12 18:09       ` Richard Miller
2011-07-12 19:08         ` Ethan Grammatikidis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8RtFrvW2mT5ubAb73WqFJ563H_E-2YkYMY+rOXsSivAKSZGQ@mail.gmail.com \
    --to=staal1978@gmail.com \
    --cc=9fans@9fans.net \
    --cc=rbnsw-plan9@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).