Re: [9fans] [GSOC] plan9 which arch code to use?

[lucio@proxima.alt.za]

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

I have every intention of making my efforts available to everyone,
should I have even just a remote chance of success.  More importantly,
what I'm trying to do is to reduce differences, rather than increase
them.

Now, I note that by adding the amd64 stuff to an already modified
version of the Bell Labs distribution, I'm complicating thing rather
than simplify them, but that is the only approach that has caught my
attention.  And I am listening to the limited discussion on this forum
and, no, I am not paying attention to other discussions that may be
taking place elsewhere and to which I either have not been invited or
from which I have been explicitly been expelled.

Now, bear with me for a minute.

David has some good stuff lying around that, like much other stuff,
needs to be reviewed before it is incorporated with the Bell Labs
distribution.  Like me, I believe that David's preferrence is to
remain with the Bell Labs stuff, whatever his motives.  Mine, in
passing, are to secure portability for Plan 9 across architectures,
idiotic as that may be (I despise the Intel 8088 and all its progeny).

Then there is 9atom and 9front that I am aware of, neither of which I
am really familiar with, but both of which I respect, greatly, the
genesis of.  Now, I am human and not a particularly clever specimen of
my species, therefore I am picking familiarity over features as my
foundations: I know that - bar DNS glitches - the Bell Labs
distribution is robust and also the most conservative of the options
out there, or maybe just the slowest moving, so it makes a good rock
to build a castle on.

What's missing in this picture is the tool chest to add walls to this
rock, as 9atom (you, Erik, with few assistants) and 9front (cinap and
what seems like a superb, youthful team) have already done in their
own way.  So we have plenty of bricks, some master masons and a
community that, at least in small ways, is no doubt willing to
contribute.

But there is no code review facility (unless you call "patch" a code
review tool - I'm afraid the real thing has spoiled me rotten, despite
some shortcomings) and no trusted code review board to push along
deserving fixes.  Perhaps we can also have a team that takes on ideas
that either have no corresponding code or where implementation does
not pass review and makes the necessary adjustments, subject to review
as well as cooperation from the original submitter(s).

I know I can make the time to participate in such an effort, I'm not
sure who else might be willing.  I also know that there are
personality problems as well as ideology problems, but I always
believed that these can be overcome in a technological environment
where financial incentives are not dominating.

Anyway, the elections in South Africa are distracting me, so I'm not
going to take this further now, but I'd be delighted to hear from
like-thinking developers as well as from those who may want to
approach this problem from a very different perspective.

++L

[-- Attachment #2: Type: message/rfc822, Size: 3937 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] [GSOC] plan9 which arch code to use?
Date: Wed, 7 May 2014 14:22:42 -0400
Message-ID: <b3a9f25efdffc75e75b05f92e972a14d@ladd.quanstro.net>

> Mostly just a mixture of arrogance and ineptitude that says I want to
> do this my way?
>
> For real, I can't resist a convergence challenge.  The image I had in
> my mind was of an amd64 environment within the Bell Labs release
> (i386) that would allow me to build either 9atom or 9front releases
> with minimal adjustments.

if everybody does their own thing, perhaps we spend all our collective
time doing the same thing, and no progress is made?

just an observation.  and obviously there are tradeoffs.  i'll give you that
i love to do things my self.  let me know if you see anything in atom that causes
issues.  certainly a goal is to keep these to a minimum.

the atom stuff of course came about for three reasons that were not
solved elsewhere at the time: working with certain hardware, 21-bit
runes, and production amd64 support.

i think all of these are at least to some extent still valid.  there are gaps
in the distribution's 21-bit rune support, and the hardware support gap
may have increased.

- erik