9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: hiro <23hiro@gmail.com>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] upgrading the 9legacy shell (was: Gmail vs Upas)
Date: Wed, 4 Dec 2019 14:59:03 +0000	[thread overview]
Message-ID: <CAFSF3XOUNoEmE-3mApK8YxWd3aK5eDLiwweQAkKj_KwpcYTR6g@mail.gmail.com> (raw)
In-Reply-To: <fbb691cfe22b72acc78d7c46698694c7@pipebanger.net>

> I have no interest in using 9front for [...] non-technical reasons.

as i said, probably some misunderstanding.

> The "community" is atrocious; anyone willing to turn a blind eye
> toward bad behavior due to technical merit is sophomoric if not
> abusive.  ISTR calling this "elitist fuckery" in the past, I still
> stand by that.

this is the kind of stuff that *seems* so self-evident it's rare i
hear it spelled out. i'm happy we finally get to this point, because i
partly agree with the statement in theory.

bad behavior is bad, and passive acceptance of bad behavior in your
own social circles is just as bad.

i just don't see how people would still apply it to 9front. we have
tried quite hard to relativize whatever might have once inspired the
thought of calling 9front development elitist fuckery. and i would
appreciate it if we can fully clear it up for whoever still feels
offended in this way. no community is ever perfect and the difficulty
in real consensus naturally rises with size of the community and the
complexity of the tackled problems.
pointing out how we should change is important, even if it comes from
an outsider. but there always have to be people changing things from
the inside, about oneself and the people nearby oneself. some are
willing to work on whatever real issues there are. in my personal
experience there are always issues. always new things to develop,
learn, fix, also about oneself. please keep up such constructive
criticism so we can all develop together.

> Second, the gatekeeping that was done while the labs was still active
> was tough, but usually fair.  Geoff did a nice job of keeping the
> spirit of plan9 alive and often rejected larger changes that could
> have upset the balance.

i also have no personal complaints. though i have heard complaints
second-hand (as i hinted in my previous mail). and given the
alternative, most people, even the ones having problems getting
through geoff's selection process, would probably agree it was still
better to have geoff and a working bell-labs lab and website around
than whatever state we are in now. even if for some the only positive
outcome is that thousands of html links would at least not be broken
now.

David's work on 9legacy also follows the same
> spirit; it's a patch queue that pulls from a number of different
> sources but strives to keep the original spirit intact.  I struggle to
> see the same mindset held by 9front.

i agree it uses the same contrib technology. the mindset of 9legacy
indeed didn't change much, but mainly because not much at all got
changed in the first place.
i'm not sure this is a spiritual difference or rather a difference of
plain volume.

also, we were not the ones going around and adding syscalls and what have you.
9front tried much harder to preserve backwards compatibility. and that
takes quite some skill considering how many more lines of code have
been touched!

so what direction do you think did the "9front mindset" wander off to?
all i see is more coherency, not a new direction.
btw, in case you didn't notice, many changes in 9front were fixes and
completing already existing features.

probably the only big regret that all 9front users are still suffering
from is not rewriting nupas from scratch. 9legacy has never moved
fully to nupas so it didn't manage to run into this error.

and i hope we can remove python and hg some day soon. that would be
really awesome. just like openssl got removed from python before. that
was one of those great days in 9front history that i will always look
back to with joy :)

> That said, there is work being done outside of 9front.  It's not as
> public or as polarizing, but there are still people hacking away.

sure, some form of IT slavery is how most of us are surviving.
thankfully they pay for most of this non-plan9 work, even though i can
not philosophically identify with that industry as much.

it's not like without plan 9 we couldn't have fun, too. but with plan
9 we can also get peace.

  parent reply	other threads:[~2019-12-04 14:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  4:10 Lucio De Re
2019-12-03  6:17 ` ori
2019-12-03 10:19   ` Richard Miller
2019-12-03 11:42     ` Lucio De Re
2019-12-03 15:25       ` hiro
2019-12-03 20:01         ` Skip Tavakkolian
2019-12-03 20:31           ` hiro
2019-12-03 22:06             ` Skip Tavakkolian
2019-12-03 22:46               ` hiro
2019-12-03 22:53                 ` andrey mirtchovski
2019-12-04  0:46                 ` Skip Tavakkolian
2019-12-04  1:06                 ` sstallion
2019-12-04  1:18                   ` Alex Musolino
2019-12-04  4:55                     ` Lucio De Re
2019-12-04  5:28                       ` Alex Musolino
2019-12-04 14:59                   ` hiro [this message]
2019-12-04 16:42                     ` Nicolas S. Montanaro
2019-12-03 17:43     ` ori

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=CAFSF3XOUNoEmE-3mApK8YxWd3aK5eDLiwweQAkKj_KwpcYTR6g@mail.gmail.com \
    --to=23hiro@gmail.com \
    --cc=9fans@9fans.net \
    /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).