[TUHS] Re: SunOS 4 in 2024

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Mar 14, 2024 at 11:44:45AM +1100, Alexis wrote:
> 
> i basically agree. i won't dwell on this too much further because i
> recognise that i'm going off-topic, list-wise, but:
> 
> i think part of the problem is related to different people having
> different preferences around the interfaces they want/need for
> discussions. What's happened is that - for reasons i feel are
> typically due to a lock-in-oriented business model - many discussion
> systems don't provide different interfaces/'views' to the same
> underlying discussions. Which results in one community on platform X,
> another community on platform Y, another community on platform Z
> .... Whereas, for example, the 'Rocksolid Light' BBS/forum software
> provides a Web-based interface to an underlying NNTP-based system,
> such that people can use their NNTP clients to engage in forum
> discussions. i wish this sort of approach was more common.

This is a bit off-topic, and so if we need to push this to a different
list (I'm not sure COFF is much better?), let's do so --- but this is
a conversation which is super-improtant to have.  If not just for Unix
heritage, but for the heritage of other collecvtive systems-related
projects, whether they be open source or proprietary.

A few weeks ago, there were people who showed up on the git mailing
list requesting that discussion of the git system move from the
mailing list to using a "forge" web-based system, such as github or
gitlab.  Their reason was that there were tons of people who think
e-mail is so 1970's, and that if we wanted to be more welcoming to the
up-and-coming programmers, we should meet them were they were at.  The
obvious observations of how github was proprietary, and locking up our
history there might be contra-indicated was made, and the problem with
gitlab is that it doesn't have a good e-mail gateway, and while we
might be disenfranchising the young'uns by not using some new-fangled
web interface, disenfranchising the existing base of expertise was
even worse idea.

The best that we have today is lore.kernel.org, which is used by both
the Linux Kernel and the git development communities.  It uses
public-inbox to archive the mailing list traffic, and it can be
accessed via threaded e-mail interface, as well as via NNTP.  There
are also tools for subscribing to messages that match a filtering
criteria, as well as tools for extracting patches plus code review
sign-offs into a form that can be easily consumed by git.

Of course none of this is a substitute for hiring a technical writer
working with keye developers to create architecture documentation so
that when a key developer retires (or gets hit by a bus) that critical
knowledge doesn't get lost.  This requires real investment, and while
some communities might have a large corporate-funded foundation who
might be able to fund that sort of thing, one of the things we've
found is that there are real limits to the sort of documentation work
that can be done by volunteers.  (For example, right now the Linux
kernel documentation maintainer is also the owner and editor for the
Linux Weekly News, and Jon is keenly aware of the limits of what he
can do in his copious spare time.  And none of us is getting any
younger....)

So it's a real problem, and I think it's one that needs a lot more
conversation, both within various open source projects, and perhaps
between different projects to exchange some techniques for better
preserving lore.  After all, it would be great if we could make things
easier for the next generation's *-Heritage-Society.  :-)

							- Ted