cross
|
|
response 1 of 23:
|
May 22 02:35 UTC 2017 |
A little history.
I should write a blog post about this stuff or something.
I've been using Grex for nearly 17 or 18 years now; since about
1999 or early 2000. The system grew out of the earlier "M-Net"
system in Ann Arbor and got started in 1991; a detailed account of
early history is here: http://www.unixpapa.com/conf/oldhistory.html
(sadly, the author of that link -- Jan Wolter -- passed away a few
years ago. I really liked Jan; he was one of the most *reasonable*
people I ever came across on Grex).
I heard about Grex on a mailing list somewhere; maybe cypherpunks
or bugtraq. I believe Marcus Watts mentioned that 'they' were going
to use a modified version of the MIT Kerberos KDC for authentication
on their public access Unix system, and a tiny amount of research
showed that these fools gave an account with more or less unrestricted
shell access on a Sun machine running SunOS 4 to literally anyone
who logged in off the Internet. What craziness! How could that
POSSIBLY work?! I had to login and find out for myself.
Have you ever seen the movie, "The Life Aquatic with Steve Zissou"?
Logging into Grex was kind of like walking onto Zissou's boat.
Everything was sort of run-down and old-fashioned, but juxtaposed
with this sense that people took it seriously. It was bizarre:
"Let me tell you about my boat."
https://www.youtube.com/watch?v=d1RnYfFZK2k
"The bearing-casings aren't supposed to look like that, but we can't
afford to repair them this year." There was also this pride in
being something of a species of bottom-feeder: Grex liked to acquire
old and slightly broken hardware and press it into service. While
laudable in some sense, in an era of geometrically increasing
computing power at plummeting cost, it didn't seem like a particularly
good use of the scarcest of resources: volunteer time.
Grex also had its heroes and local flavor already. It was hard to
come in as a Unix-guy and make suggestions and be taken seriously;
if you weren't one of the local favorites, no one knew to consider
you different than any number of other users who would blow in off
the Internet, make some drive-by comments and then disappear again.
It took me a few years to get folks to believe that anything I had
to say wasn't just uninformed hot air. Here, well into the 1990s,
people were writing user-interface like code for a time-shared
system like it was the early 1980s. It was all a bit surreal and,
frankly, frustrating.
By any objective measure, one should have logged out and never
looked back.
But like a favorite stuffed animal that's been mauled through
childhood and is now missing an ear and half of its stuffing, Grex
kind of gets under your skin and is hard to let go of.
In part, there's the challenge of keeping things going. Part of
it is the retro-charm of the place and nostalgia for a simpler and
a lost style of computing: time-sharing. As Dennis Ritchie once
said,
"What we wanted to preserve was not just a good environment
in which to do programming, but a system around which a
fellowship could form. We knew from experience that the essence
of communal computing, as supplied by remote-access, time-shared
machines, is not just to type programs into a terminal instead
of a keypunch, but to encourage close communication."
(from http://cm.bell-labs.co/who/dmr/hist.pdf)
Grex really got the fellowship part, though of course in a far
difference context than the development of Unix.
Sadly, I think the local focus held Grex back for a *very* long
time. While the bottom-feeder mentality just didn't make sense on
a modern piece of hardware, it was mostly harmless: like aging
hippies dropping off potluck dinners you don't want, the obsolete
hardware accumulated wasn't a real burden. But the local hero thing
became a problem; Grex damn near succumbed to Founder's Syndrome
(https://en.wikipedia.org/wiki/Founder%27s_syndrome).
When the bulk of your users are no longer local, then such a strong
regional focus and culture stops making a lot of sense. Yet Grex
tried to hold onto that and fought tooth-and-nail NOT to evolve as
its user-base changed out from underfoot. That was problematic.
The staff, many of whom had been founders, were very resistant to
change; consequently, most of the users went elsewhere. Grex now
sees a fraction of the traffic it received at its peak of popularity
back in the 90s and early 2000s.
The Picospan program is a representative example. Written by one
of the founding members (Marcus Watts), it was (is?), unfortunately,
closed source and only two people locally had access to the source
code. When Grex moved off of the Sun and onto x86 hardware, getting
an updated version when we upgraded the operating system was
sufficiently difficult that it became a blocker. But there was
significant resistance to replacing Picospan with an open-source
equivalent. Eventually pragmatism won out and it happened, but it
was a slog. Similarly with abandoning some of the customization
made to the Sun computer: despite them no longer being relevant on
a modern machine, there was serious talk about bringing them forward.
It was bizarre.
However, most of those folks have drifted away now. While sad in
some sense, it presents a unique opportunity in others.
Wondering into Grex now is like wondering into an abandoned city,
but one with a fully-functional infrastructure. It's like you can
take it and make it into the kind of place you always wanted to
live!
|
cross
|
|
response 2 of 23:
|
May 22 02:57 UTC 2017 |
Things to do: Rewrite backtalk/fronttalk.
Backtalk was a neat idea: a "skinable" wrapper around a Picospan-like
conferencing system. Backtalk itself is actually a language interpreter for
a small (relatively), concatenative programming language that vaguely
resembles PostScript. The various "interfaces" are then programs written in
that language. The command-line interface, fronttalk, is then one of those
programs. Or rather, one half of fronttalk is like that; the other half is
deals with interacting with the user and is written in Perl.
While a neat idea at the time, it seems a bit antiquated now. The "modern"
way we would address this would be to generate consistent structured markup
and then use CSS to "skin" the presentation to the user. Actual manipulation
of the conference would be done using a RESTful API and a structured data
format like XML or JSON. A web interface could be written that would plug
into this framework and provide a user-interface; another program could
provide a command-line interface.
As well as fronttalk/backtalk have served Grex for the past decade or so,
I think it's time to start talking seriously about putting both out to
pasture and moving towards something both more maintainable and modern.
|
tfurrows
|
|
response 5 of 23:
|
May 24 20:16 UTC 2017 |
Awesome thread, looks like things are moving in a good direction. On the
subject of community-contributed software, I think it's a great idea. User
papa had the idea of ~username/share/bin folders, which he and I and possibly
a few others have already started using, so that we could share
scripts/utilities/filters. It's a nice way to use things from known users;
you can reference them directly of course, or place that user's share/bin in
your own path.
I think it would be nice to have a shared folder on the system, where anyone
could contribute. I have once such utility shared that way on SDF, but a
different "metaARPA" user had to place my script in the folder for me... in
any case, like you postulated, the ability is there. On the LCM's 3b2/1000
there is also such a folder for community-contributed items. So there is
certainly a precedent on current multi-user systems.
|