New apps - SSH client, IRC client, TTY

[jade_nekotenshi]

I'm not sure how the community feels about AI-assisted coding, but the this last week I've been bashing on three new OPENSTEP apps: a GUI ssh client (StepSSH), IRC client (RatChat) and an improved color terminal (StepTTY). So far all three are kind of preliminary, but I've been using them regularly with good success.

If anyone's interested, I have GitHub repositories for all three. (I can provide NIS packages though I don't have them up on GH yet.)

StepSSH
RatChat
StepTTY

[onionmixer]

I'm not sure how the community feels about AI-assisted coding, but the this last week I've been bashing on three new OPENSTEP apps: a GUI ssh client (StepSSH), IRC client (RatChat) and an improved color terminal (StepTTY). So far all three are kind of preliminary, but I've been using them regularly with good success.

If anyone's interested, I have GitHub repositories for all three. (I can provide NIS packages though I don't have them up on GH yet.)

StepSSH
RatChat
StepTTY

I think the address for RatChat might be wrong... @.@;

[jade_nekotenshi]

Wrong how? It takes me to the GitHub repo.

[onionmixer]

Wrong how? It takes me to the GitHub repo.

By any chance, did you create the RatChat repository as private?

[don_apple]

By any chance, did you create the RatChat repository as private?

Seems to be the case, since it does not appear in the list of public repos: https://github.com/jadenekotenshi?tab=repositories

[jade_nekotenshi]

Oh. I'll fix that here shortly. Oops!

EDIT: It's public now.

[Rhetorica]

These are all sorely needed! There were at least four different NEXTSTEP clients for IRC in the 90s, but the only one that works properly is ircii—stuck in the terminal—which has always been a crying shame in my mind. I look forward to playing with these!

We are generally pro-AI here. It's been incredible at opening doors for people and breaking down barriers that have stood unassailed for many years. I'm going to make a thread so we can discuss it more. Your projects are very welcome.

[jade_nekotenshi]

Thanks for your kind words!

Of the projects, I'd say that StepSSH is the most solid. I'm about to add a small tweak to increase throughput, assuming you have a Pentium or above. (Alas, it's probably unusably slow on black hardware and marginal on SPARC or 486; I don't have a SPARC or virtual SPARC to test with right now).

RatChat does have TLS support, and I tested it enough to be sure it mostly works, but please exercise the heck out of it if you can.

StepTTY is probably the least solid overall, but please, test it out and tell me what you think.

[jade_nekotenshi]

If you grab the sources for StepSSH and build it on x86, edit the Makefile.openstep and add "-m486" to the OPT flags - it considerably increases throughput. I'm not sure if -m68040 makes any difference on black hardware or not - I'm testing that now.

EDIT: On 68k, set "-O2 -fomit-frame-pointer -m68040", but your throughput still won't be great. Note that -O2, on x86, actually is slower than -O. I'm not sure what flags make the most sense on SPARC.

[jade_nekotenshi]

StepSSH is currently not working on 68k. I'll release an updated version once it does work. For right now the status is:

x86 - Working
68k - Not Working
SPARC - Untested

EDIT:

After the patch, we're now at:

x86 - Working
68k - Working
SPARC - Untested

[jade_nekotenshi]

Turns out OPENSTEP's compiler has a bug on m68k that was causing ed25519 host key verification to fail.

I found it and nailed it to the wall with a kluge that works around the miscompile. I also added selective optimization flags that increased throughput on x86 by about 30% and on 68k by about 15%. I've tested, to some extent, StepSSH on both platforms. RatChat would also have been affected by this bug when connecting to servers with TLS, so it's been fixed as well.

Note, SPARC is still completely untested. If anyone actually has a SPARC, I'd greatly appreciate test results (even if it's just to compile and run "make test")

[ptek]

Turns out OPENSTEP's compiler has a bug on m68k that was causing ed25519 host key verification to fail.

I found it and nailed it to the wall with a kluge that works around the miscompile. I also added selective optimization flags that increased throughput on x86 by about 30% and on 68k by about 15%. I've tested, to some extent, StepSSH on both platforms. RatChat would also have been affected by this bug when connecting to servers with TLS, so it's been fixed as well.

Very interested to know what the m68k bug was. Was it a fpu bug?

[jade_nekotenshi]

This is what Claude had to say:

It's a compiler bug, and I've fixed it in both StepSSH and RatChat. It's untested on the 68040 so far. gcc 2.7.2's m68k backend miscompiles a 64-bit right shift by the constant 16, and the result comes back with a zero high word. car25519 does exactly that shift, so every field multiply was wrong. That broke X25519 and Ed25519 and nothing else.

I don't have to guess that this explains it. I made the host reproduce the bug by zeroing the high word of that shift in a scratch copy of nacl.c. All 29 wrong lines from your 68040 came out identical, including the X25519 outputs, the Ed25519 key and signature, and the raw carry limbs. Nothing was left unexplained.

I'm not sure if this is a bug in the 68040's FPU or a bug in the compiler, or maybe even a bug in Previous, but it's kluged around now!

[itomato]

I'm not sure how the community feels about AI-assisted coding, but...

Personally, I am for it.

[jade_nekotenshi]

StepSSH 1.4.1 is now available. Tested on all three architectures now.

Big changes:
Tested and working on SPARC
Cipher selection box
Big optimization pass that has increased bulk throughput considerably.