Synchronet currently hard-depends on libmozjs 1.85, which will not run on 64-bit ARM.
This is because the old version of mozjs makes incorrect assumptions about 48-bit vs
64-bit address spaces in NaN handling, which aarch64 and sparc64 violate. Newer mozjs
versions are written in C++ rather than C, which means rewriting any piece of the software
that touches JS. Additionally, the SSH library on the Win32 version is dangerously out of
date, offering zero cipher overlap with modern OpenSSH versions. Finally, the number of
systems that understand cp437 natively is plummeting, and so the UI should probably offer a
UTF-8 option.

Re: synchronet needs a rewrite
By: tidux to All on Tue Apr 30 2019 08:22 pm

Synchronet currently hard-depends on libmozjs 1.85, which will not run on 64-bit ARM.

That may be true (I don't know), but I *do* know that libmozjs 1.8.5 (and sbbs) runs just fine on my 64-bit rPi3. Maybe that's just because it's running a 32-bit OS (Raspbian). I'm not sure if anyone has tried running sbbs on a 64-bit ARM OS.

This is because the old version of mozjs makes incorrect assumptions about 48-bit vs
64-bit address spaces in NaN handling, which aarch64 and sparc64 violate.

Interesting. We patch libmozjs for other ARM-target issues as well during the build process. Perhaps it could be patched for that issue as well. If you legitimately want to report an issue with Synchronet, see http://wiki.synchro.net/howto:support for details.

Newer mozjs
versions are written in C++ rather than C, which means rewriting any piece of the software
that touches JS.

While upgrading the version of mozjs has been and will be painful, it has never involved what I would call a "rewrite". Most of the Synchronet source that uses the JSAPI is already in C++, so not biggie there.

Additionally, the SSH library on the Win32 version is
dangerously out of
date, offering zero cipher overlap with modern OpenSSH versions.

Chasing SSH algorithms is a constant, never-ending task. See http://wiki.synchro.net/faq:tcpip#ssh_algo for details.

Synchronet currently uses Cryptlib v3.4.4 which was the latest and greatest version up until just last month when v3.4.5 was released and of course we'll be upgrading to that version.

Finally,
the number of
systems that understand cp437 natively is plummeting, and so the UI should probably offer a
UTF-8 option.

The number of BBS terminals that understand UTF-8 is incredibly low (like maybe, one or two). Anyway, I'm sure we'll get to it some day and I don't anticipate it requiring "a rewrite".

All that said, you just come across like a whiny a-hole. If you want to have an actual conversation about these things, I suggest you take a different approach and also take it to one of the official Synchronet support message areas (hint: this ain't one of 'em).

digital man

This Is Spinal Tap quote #1:
Nigel Tufnel: These go to eleven.
Norco, CA WX: 54.2°F, 80.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

Digital Man wrote to tidux <=-

Re: synchronet needs a rewrite
By: tidux to All on Tue Apr 30 2019 08:22 pm

Synchronet currently uses Cryptlib v3.4.4 which was the latest and greatest version up until just last month when v3.4.5 was released and
of course we'll be upgrading to that version.

Was interested hearing that cryptlib is updated. I just tried 3.4.5
out in Qodem, and still get the no compatible cipher available error
when talking to modern OpenSSH server with a cryptlib client. On the
host mode (server) side, it worked OK (I think) without the '-m
hmac-md5' workaround for OpenSSH client to speak to cryptlib server.

Alas, it remains in plan (someday when I get time) for Qodem to switch
to mbedtls + libssh2 for Windows SSH support, which will also mean
losing ssh server for host mode. cryptlib is just so ... ugh.

Finally,
the number of
systems that understand cp437 natively is plummeting, and so the UI should probably offer a
UTF-8 option.

The number of BBS terminals that understand UTF-8 is incredibly low
(like maybe, one or two). Anyway, I'm sure we'll get to it some day and
I don't anticipate it requiring "a rewrite".

I gave g00r00 a CP437-to-UTF8 conversion for Mystic (Pascal), don't
know if it made any users happier or not. But yeah it's a small
change, certainly not a "rewrite".

What users want in BBS terminals is SyncTERM/NetRunner: CP437 (with a
good font out of the box), ANSI-BBS, file transfers, scrollback, and
good support for OSX and Windows. But what users want in xterm-type
terminals is vastly different: UTF-8, CJK (including font fallback),
emojis, wide-char, GPU acceleration, tabbed terminals, background
transparency, ncurses/terminfo-level support for "xterm", 24-bit RGB
colors, mouse cut/copy/paste, and X10 mouse support. I feel that
these two user groups will never converge on a common terminal. It
has been a bit bizarre seeing these two worlds with such
outwardly-seemingly identical-looking interfaces, yet being so utterly different in how they are used in practice.

... MultiMail, the new multi-platform, multi-format offline reader!
--- MultiMail/Linux v0.49

Synchronet is open-source.
https://www.synchro.net/docs/source.html
You got a problem with the code?
Feel free to fix it yourself.


On 4/30/19 9:22 PM, tidux wrote:

Synchronet currently hard-depends on libmozjs 1.85, which will not run on 64-bit ARM.
This is because the old version of mozjs makes incorrect assumptions about 48-bit vs
64-bit address spaces in NaN handling, which aarch64 and sparc64 violate. Newer mozjs
versions are written in C++ rather than C, which means rewriting any piece of the software
that touches JS. Additionally, the SSH library on the Win32 version is dangerously out of
date, offering zero cipher overlap with modern OpenSSH versions. Finally, the number of
systems that understand cp437 natively is plummeting, and so the UI should probably offer a
UTF-8 option.

Re: synchronet needs a rewrite
By: Digital Man to tidux on Tue Apr 30 2019 10:31 pm

All that said, you just come across like a whiny a-hole. If you want to have an actual conversation about these things, I suggest you take a different approach and also take it to one of the official Synchronet support message areas (hint: this ain't one of 'em).

"whiny a-hole" was the word I was looking for...