GitHub really annoyed me this month by starting to require
Javascript in the web view of Git repos just to browse directories
and source code.

My answer is GophHub:
gopher://tilde.club/1/~freet/gophhub/

Still not completely finished, but the weekend's over so it is what
it is. There are only two significant missing features left on
my to-do list (plus line numbering in syntax-highlighted source
files, which I've given up on (adding one excludes the other)).
--

- The Free Thinker | gopher://aussies.space/1/%7efreet/

--- Synchronet 3.19a-Linux NewsLink 1.113

Glad you are being able to get back into Tildeverse Netnews now.
Though I saw from the `Path:` of your post
that you posted from Tilde.club;
so I take that A. SSH forwarding on Aussies.space didn't work for this,
and B. you finally solved the auth'signing algorithm issue
in your normal client, or have worked around it.
(How? If you don't mind telling)

On Mon, 17 Jul 2023, The Free Thinker wrote:

GitHub really annoyed me this month
by starting to require Javascript
in the web view of Git repos
just to browse directories and source code.

Yeah, noticed that for some time now.
Interface-wise, it's now no better than the JavaS'creep-infected GitLab-- while GitLab is still a libre software.
Now Gitea/Forgejo is way better in this regard,
so as SourceHut, Gogs, Savannah, SourceForge/Apache Allura;
or even barebone things like CGit, GitWeb, or Stagit
in a specific browse-only department. [1]

My answer is GophHub:
gopher://tilde.club/1/~freet/gophhub/

Thanks for writing this,
it is indeed a needed workaround for plebs like us
to deal with projects that somehow want to cling there for whatever
(usually corporate, inertia, sunk cost) reason.

Though it's still my stance that a proper long-term solution
is advising people to get off that code-laundering (dis)service,
refrain from participating (sending bug reports/patches) there [3],
and/or avoid getting involved with projects which insist on such disservice
to be a sole public participation channel in the first place.

Regards,
~xwindows


-----

(WARNING:
Rants ahead,
and you probably already know most of this;
so they are intended for as "to other people reading this reply")

[1]
To other people reading this reply: I will remind you
that the original and proper way for an *external* developer
to contribute a change to a public software project managed in Git
is the way that is currently used in kernel Linux development [2];
i.e. `git format-patch origin/master` and `git send-email`
to the maintainer or project mailing list.

(There is a very specific format of email message involved [4]
which allows the maintainer to commit the change directly from MIME file. Easier alternative for less stringent projects
[tilde-related projects counts in this category too]
is one can simply write email to the maintainer
to explaining what the fixes do,
and attach the patch files produced from the first command)

The "pull request" style of "contribution"
(which needs infrastructure)
is rather invented by GitHub to brainwash people
to believe that such submission
would inherently require on centralized service;
in order to capitalize on network effect
(i.e. you need account on single web service to submit changes).
It is not even a natural way to maintain public participation
in this SCM.

[2]
Kernel Linux is the original software project
that Linus Torvalds wrote Git for,
and the name "Git" was a reference to himself;
supposedly for being stupid enough to fall
for BitKeeper SCM's proprietary bait'n'switch ploy
in spite of other people's warnings,
and got burned by that in the end.

[3]
This do not imply that you cannot submit bug report or patches,
if they publish contact email,
mail those to them. [1]
If they tried to redirect you to the disservice,
you got declined,
or treated with silence;
simply share them as if you got responded WONTFIX on your report:
post them the old way on your website,
describe what they do,
the copyright license you are publishing them under,
as well as the exact HEAD/branch/repo
that your patch series is intended to apply;
optionally with your own reasons why they didn't get submitted
on the "official channel".

[4]
When I submit change to a tilde project (like Tilde.club Wiki),
I personally don't use `git send-email`,
but rather craft my own MIME file manually
from what `git format-patch` gave me,
then `sendmail -t` the result (or import to Alpine and send);
allowing me to have a discussion message in the front
(usually me describing what the patch is and what it fixes/adds)
and the patch content itself following right next to it in the message
(rather than as an attachment) for a quick review,
separated from each other by thin a scissor line "-- >8 --".

Apart from maintaining one-mail-per-commit relation,
this also allows the maintainer side to select Pipe command
inside a TUI mail client to run `git am --scissors`
and issue a commit right there if he approves.
(I usually include an instruction too, whenever `--scissors` is needed)

Different people might prefer different way to do this though:
`git --format-patch --cover-letter`
which produces an email thread is one of the other choices.
--
Contains ventilated prose,
manually typed up in RFC 2646
"text/plain; format=flowed" whitespace encoding;
might read like poetry in some newsreaders.
--- Synchronet 3.19a-Linux NewsLink 1.113

xwindows <xwindows@tilde.club> wrote:

Glad you are being able to get back into Tildeverse Netnews now.
Though I saw from the `Path:` of your post
that you posted from Tilde.club;
so I take that A. SSH forwarding on Aussies.space didn't work for this,

I didn't know that forwarding port 119 would allow posting. Hovever
testing now in various environments, I get this error when I
attempt to connect to the forwarded port from the Tin or Telnet and
the connection is immediately closed:

channel 2: open failed: administratively prohibited: open failed

That error is from OpenSSH, PuTTY says nothing but has the same
result (I wish I'd tried in OpenSSH first).

and B. you finally solved the auth'signing algorithm issue
in your normal client, or have worked around it.

Actually for that I was connected via telnet to the SBC that I run encryption-insistent internet software on, and it was running
OpenSSH 9.3. My current posting in Tin on the local spool via SSH
to tilde.club is more of a one-off though - to laggy and awkward.
I'll compile the latest Tin for the OS on that SBC one day and
connect via NNTPS with that.

Tonight I finally got a later version of PuTTY compiled for my old
computers so I can now connect directly from them to tilde.club as
well. It was a saga though, and failure to get a relatively recent
CMake to compile means that I won't be able to upgrade PuTTY again,
because later versions require CMake.

As a result of that, I'm way too tired now and I'll respond to the
rest of your post later (it's been a big day, I've been trying to
heave half a ton of steel around, part of a very different weekend
project to last week's).
--

- The Free Thinker | gopher://aussies.space/1/%7efreet/
--- Synchronet 3.19a-Linux NewsLink 1.113

xwindows <xwindows@tilde.club> wrote:

B. you finally solved the auth'signing algorithm issue
in your normal client, or have worked around it.
(How? If you don't mind telling)

For the next time SSH requirements get upgraded, I'm now
considering attempting to cross-compile PuTTY by chrooting to a
copy of the older distro's root file system on a PC running a
current Linux distro, then using bind mounts and LD_LIBRARY_PATH to
run cmake and make from the newer distro, thinking that they're
running in the older distro.

Right now I'm posting via SSH to tilde.club with PuTTY 0.76 (last
PuTTY to build without CMake) running on a PC from the mid 90s and
Linux from the mid 2000s.

On Mon, 17 Jul 2023, The Free Thinker wrote:

GitHub really annoyed me this month
by starting to require Javascript
in the web view of Git repos
just to browse directories and source code.

Yeah, noticed that for some time now.
Interface-wise, it's now no better than the JavaS'creep-infected GitLab--

Yes I was hoping to find a universal way to browse all Git repos
without downloading their contents, so that it would work with
GitLab as well, but Git just isn't designed for that unfortunately.

while GitLab is still a libre software.
Now Gitea/Forgejo is way better in this regard,
so as SourceHut, Gogs, Savannah, SourceForge/Apache Allura;
or even barebone things like CGit, GitWeb, or Stagit
in a specific browse-only department. [1]

Really just a directory tree of the Git repo indexed by the web
server (with CGI processing disabled) would suit me. A separate
tree with source code files syntax highlighed in HTML would be a
bonus. Of course that's basically a static implementation of what
GophHub offers via Gopher.

My answer is GophHub:
gopher://tilde.club/1/~freet/gophhub/

Thanks for writing this,
it is indeed a needed workaround for plebs like us
to deal with projects that somehow want to cling there for whatever
(usually corporate, inertia, sunk cost) reason.

Though it's still my stance that a proper long-term solution
is advising people to get off that code-laundering (dis)service,
refrain from participating (sending bug reports/patches) there [3],
and/or avoid getting involved with projects which insist on such disservice to be a sole public participation channel in the first place.

Indeed, but if being bought by Microsoft wasn't enough to scare
the open-source community off GitHub already, then I don't know
what is.

But as much as I dislike the centralisation around GitHub, when
looking for obscure open-source projects or code examples by
searching with Duck Duck Go (which admittedly is itself
Microsoft-associated via Bing as a primary data source), adding "site:github.com" to the search string has become an extremely
useful technique.
--

- The Free Thinker | gopher://aussies.space/1/%7efreet/

--- Synchronet 3.19a-Linux NewsLink 1.113

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

xwindows <xwindows@tilde.club> writes:


[...]

Though it's still my stance that a proper long-term solution is
advising people to get off that code-laundering (dis)service, refrain
from participating (sending bug reports/patches) there [3], and/or
avoid getting involved with projects which insist on such disservice
to be a sole public participation channel in the first place.

This is exactly what I am doing. I won't submit a "pull request"... I
only send git patches with git-send-email(1) ;-) .

-----

(WARNING: Rants ahead, and you probably already know most of this; so
they are intended for as "to other people reading this reply")

[1]
To other people reading this reply: I will remind you that the
original and proper way for an *external* developer to contribute a
change to a public software project managed in Git is the way that is currently used in kernel Linux development [2]; i.e. `git format-patch origin/master` and `git send-email` to the maintainer or project
mailing list.

(There is a very specific format of email message involved [4] which
allows the maintainer to commit the change directly from MIME
file. Easier alternative for less stringent projects [tilde-related
projects counts in this category too] is one can simply write email to
the maintainer to explaining what the fixes do, and attach the patch
files produced from the first command)

The "pull request" style of "contribution" (which needs
infrastructure) is rather invented by GitHub to brainwash people to
believe that such submission would inherently require on centralized
service; in order to capitalize on network effect (i.e. you need
account on single web service to submit changes). It is not even a
natural way to maintain public participation in this SCM.

[...]

[3]
This do not imply that you cannot submit bug report or patches, if
they publish contact email, mail those to them. [1] If they tried to
redirect you to the disservice, you got declined, or treated with
silence; simply share them as if you got responded WONTFIX on your
report: post them the old way on your website, describe what they do,
the copyright license you are publishing them under, as well as the
exact HEAD/branch/repo that your patch series is intended to apply; optionally with your own reasons why they didn't get submitted on the "official channel".

[4]
When I submit change to a tilde project (like Tilde.club Wiki), I
personally don't use `git send-email`, but rather craft my own MIME
file manually from what `git format-patch` gave me, then `sendmail -t`
the result (or import to Alpine and send); allowing me to have a
discussion message in the front (usually me describing what the patch
is and what it fixes/adds) and the patch content itself following
right next to it in the message (rather than as an attachment) for a
quick review, separated from each other by thin a scissor line "-- >8
--".

Apart from maintaining one-mail-per-commit relation, this also allows
the maintainer side to select Pipe command inside a TUI mail client to
run `git am --scissors` and issue a commit right there if he
approves. (I usually include an instruction too, whenever `--scissors`
is needed)

Different people might prefer different way to do this though: `git --format-patch --cover-letter` which produces an email thread is one
of the other choices.

:-) . I have learned so much from xwindows and from tilde.club .
Thank you!

=2D-=20
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJmBAEBCgBQFiEEOVeKaEm0xBhCsMmYlk/BEMQK1XUFAmqcOLAbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyFhxrZXlib2FyZGFuQHRpbGRlLmNsdWIACgkQlk/B EMQK1XUWoA/9GSRZXxj8yHayeRBn0UaKnxOPQ1mPvfTmDx6l998FPW+E91Tk+doD MlIoe+8C0cep1U8KoNgTyuOAAkKwg6LVRfYU903wdN4znZ4speIdDo/XJAYqfYxQ t+sPbi+9Am72vgh7KsjTr7GOtjGuP/m1lpIIZM1oGhoNKXASnAGkRAdLHhavk2dZ jKK8md/n/1APyFX2BPzKFjPQGC9Rpdag4QGRo2FeQQp50YfXNlJsAPmVhoktAZhT bO+AYuPnRJaYLYhZGDVgV8jEhKNRhASa7xZ5QB+nDFKY1JfM8b+8hX6X2R1R+CFv g82fWRqRmGuAMEGR1BRLLroy15HUIVRoeJkw1ZP5G2L3HFBrd17MzhGoECk0k+rt mfDMBPEaLi7k9/OG76/2wZHNXQxEiriLj8a99h7sWVp59gKPv3tmXmrSkG1xdxiz fE3jkUQFDToTJKM8yftj9d28XGUeJCC4enW4tt5ldD825Sos0Y7gqu5yn18S3Ani HUc4FMhxKeGhcDKTJay8rTw8iDZKuHB0C/gKi8s+RrSJ9aihtDYTZJDuNc+Ywte3 Q46IxEAfj+uAfJ9uj3M/QpMYfHCfeprEHgiMrVnTFoBfL/HnQgFucaw9eMsNYo6S ZG44fBoFCWiUQ+bWIb24sTX0fqwASPm3Xdj10qutx/urPDvNvDDqgjA=
=ZLPW
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.20a-Linux NewsLink 1.2