From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1310400339.71319.YahooMailClassic@web30908.mail.mud.yahoo.com>
Date: Mon, 11 Jul 2011 09:05:39 -0700
From: rbnsw-plan9@yahoo.com.au
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [9fans] GNU/Linux/Plan 9 disto
Topicbox-Message-UUID: fecb001a-ead6-11e9-9d60-3106f5b1d025

Not to rain on anyone's summer of code project but I think producing a Linu=
x 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 inter=
esting.

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 th=
en you will require some sort of device mapping layer, say a FUSE file syst=
em that makes Linux devices look like their Plan 9 counterparts - the chief=
 problem being mapping between Linux ioctls and the Plan 9 ctl file protoco=
ls.

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 cau=
se Linux and Plan 9 to converge. Since it is difficult to make ioctl work o=
ver the network unless source and destination have the same binary architec=
ture Linux needs to be encouraged to change to be closer to the Plan 9 devi=
ce=A0 model, or at least to a portable ioctl model. Providing a mapping lay=
er just entrenches the problem with Linux and moves Linux no closer to a so=
lution.

Unfortunately, even though there are clustering solutions available which e=
ven address process migration Linux people seems quite happy to address rem=
ote device access with ad hoc solutions.=20

I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the grea=
ter 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 deta=
il. 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 Pl=
an 9 natively rather than via Linux emulation. Nothing should be removed, w=
here 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) an=
d the Linux code reliant on the missing mechanism ported to work natively w=
ith 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 pr=
ocesses migrate from my lower powered laptop including the Window manager m=
igrate 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 bo=
ot, I will see what I can do...