On 28.12.2024 03:07, Lawrence D'Oliveiro wrote:
> On Sat, 28 Dec 2024 00:44:10 +0100, Janis Papanagnou wrote:
>
>> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>>
>>> Compiling Thunderbird should be very easy indeed when we use Linux
>>> distro's package management.
>>
>> You expect _users_ of tools to use a _development_ environment to fix
>> *inherent* shortcomings of a tool?
>
> On Linux, there is no “development environment” versus “user environment”.
> The same packaging tools work with both source code and built binaries.

You think it's normal that on a Linux installation where, say, no 'cc'
(as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting
languages just to create a binary (as opposed to just installing the
binary)? - I'm not sure I understood what you were saying or aiming at
especially in context of what I had been saying.

For the Unix systems I worked with (commercial Unixes, Cygwin, Linux)
there was no development environment guaranteed to be in the default
installation.

Janis

On 12/27/24 18:44, Janis Papanagnou wrote:
> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>>> [...]
>>
>> No need to be skeptical, we live in modern ages
>> where things have been made quite convenient for us.
>
> LOL. :-)
>
>> Compiling Thunderbird should be very easy indeed
>> when we use Linux distro's package management.
>
> You expect _users_ of tools to use a _development_
> environment to fix *inherent* shortcomings of a tool?
> (Shortcomings that should not be there in the first
> place!)

IIRC, this is in reference to my difficulty when Thunderbird changed the
Reply button to mean "Reply" rather than "Followup", and instead added a
new button that is labelled "Followup". I have never complained about
that change - it was an entirely sensible one. I'm just having trouble
re-training myself to use the newer, more sensible interface in a few
years after spending a couple of decades using the older, less sensible
one. And I fully appreciate other people's irritation at my difficulty
with re-training.
I wouldn't mind if they reinstated the ability, which existed in older
versions of Thunderbird, to rearrange the list of buttons that are
displayed. I do complain about the removal of that customization
ability. I don't want to go back to those older versions because that
would mean undoing other improvements. I'm especially worried about
undoing security bug fixes.

I don't like the idea of creating my own personal version of Thunderbird
by modifying their source code, because it means I would have to re-do
the build every time they put out a new version. I want quick and easy
upgrades to newer versions, especially security bug fixes, and that
desire conflicts with the desire for customization.

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> ./mach build -v
>
> with
>
> ./mach build -j6 -v

Okay, I am finally back at home and it is 21:43
o'clock.

The change above did not help because earlier in the
spec file there is this:

# Require 4 GB of RAM per CPU core
%constrain_build -m 4096

I now have:

%constrain_build -m 1024

But I am still very baffled. I tried to build TB
without any source code modifications to make sure
that the building process with rpmbuild works okay.

Instead of success, my build has terminated with:

RPM build errors:
No patch number 416
No patch number 419
Bad exit status from /var/tmp/rpm-tmp.N27puv (%build)

I cannot understand this because all references to
patches 416 and 419 are commented out in the Fedora
41 spec file. I now completely removed them and will
try again...

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> I cannot understand this because all references to
> patches 416 and 419 are commented out in the Fedora
> 41 spec file. I now completely removed them and will
> try again...

I am having massive problems with having only 16GB of
RAM.

Using 'top', I was able to see that Rust compiler 'rustc'
was hogging something like 11GB of memory, and then
after a while OOM killer got rid of the Rust compiler
process. I am also seeing swapping take place when I
attempt the build.

It is really painful but I guess I have to use
just a single CPU:

../mach build -j1 -v

Because of this, the build takes forever to complete.

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> It is really painful but I guess I have to use
> just a single CPU:
>
> ./mach build -j1 -v
>
> Because of this, the build takes forever to complete.

Despite that, rpmbuild was using three CPUS. Now trying
to add this too:

RPM_BUILD_NCPUS=1 rpmbuild -bb ~/rpmbuild/SPECS/thunderbird.spec

The build is in progress again and things look better now:

$ grep MOZ_MAKE_FLAGS /var/tmp/rpm-tmp.5ctL0k
echo "mk_add_options MOZ_MAKE_FLAGS=\"-j1\"" >> .mozconfig

Without explicit RPM_BUILD_NCPUS=1, rpmbuild defaulted to
3.

br,
KK

On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:

> You think it's normal that on a Linux installation where, say, no 'cc'
> (as prominent example of a development tool) is installed the package
> manager would first install ALL the necessary compilers and scripting
> languages just to create a binary (as opposed to just installing the
> binary)?

The discussion has to do with creating your own version of the binary,
rather than using the repo-provided version.

On Sat, 28 Dec 2024 19:27:07 +0100, Janis Papanagnou wrote:

> Personally I don't think that package managers contribute a lot since
> for ordinary users it's the same whether the package managers install a
> binary package or a source that is compiled under the hood.

Package managers contribute a lot to both tasks. On Linux, there is no
“development environment” versus “user environment”. The same packaging
tools work with both source code and built binaries.

> The difference is that source package needs a development
> environment (compiler, etc.) that "ordinary users" might not have
> installed or may not want to get installed (just for that).

Platforms like Microsoft and Apple try to build a wall between two
separate “developer” versus “ordinary user” modes of using the system;
Linux doesn’t.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
>
>> You think it's normal that on a Linux installation where, say, no 'cc'
>> (as prominent example of a development tool) is installed the package
>> manager would first install ALL the necessary compilers and scripting
>> languages just to create a binary (as opposed to just installing the
>> binary)?
>
> The discussion has to do with creating your own version of the binary,
> rather than using the repo-provided version.

Right.

Anyway, to be honest, I never realized how bloated Thunderbird is.
The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
the main source directory unpacked is:

~/tmp/tb/thunderbird-128.5.2 $ du -sh
4.2G .

Building TB with the help of a pre-made spec file on Fedora is
probably very much easier than doing 'git clone' and trying to
build it from there. Using 'dnf', it was just one command to
download all the dependencies. I suppose the size of the
dependency packages was 260MB in total. It would be a nightmare
having to download them manually and then building them.

Packages are just so handy.

Fedora and Red Hat have already done the hard work so it
is wise to use their source RPM as a basis for your own
modifications when you are on Fedora or Red Hat Enterprise
Linux.

My single CPU Thunderbird build has now lasted for over two
and half hours and I have no clue when it will be ready.

This codebase is absolutely massive! I am beginning to
lose patience.

br,
KK

On 12/28/24 17:32, Kalevi Kolttonen wrote:
> This codebase is absolutely massive! I am beginning to lose patience.

I remember when compiling X11 was a good burn in text for a processor.

Then it was the Linux kernel.

Now it's Thunderbird / Firefox, followed by Chromium, followed by Rust.

--
Grant. . . .

On Sat, 12/28/2024 6:32 PM, Kalevi Kolttonen wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
>>
>>> You think it's normal that on a Linux installation where, say, no 'cc'
>>> (as prominent example of a development tool) is installed the package
>>> manager would first install ALL the necessary compilers and scripting
>>> languages just to create a binary (as opposed to just installing the
>>> binary)?
>>
>> The discussion has to do with creating your own version of the binary,
>> rather than using the repo-provided version.
>
> Right.
>
> Anyway, to be honest, I never realized how bloated Thunderbird is.
> The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
> the main source directory unpacked is:
>
> ~/tmp/tb/thunderbird-128.5.2 $ du -sh
> 4.2G .
>
> Building TB with the help of a pre-made spec file on Fedora is
> probably very much easier than doing 'git clone' and trying to
> build it from there. Using 'dnf', it was just one command to
> download all the dependencies. I suppose the size of the
> dependency packages was 260MB in total. It would be a nightmare
> having to download them manually and then building them.
>
> Packages are just so handy.
>
> Fedora and Red Hat have already done the hard work so it
> is wise to use their source RPM as a basis for your own
> modifications when you are on Fedora or Red Hat Enterprise
> Linux.
>
> My single CPU Thunderbird build has now lasted for over two
> and half hours and I have no clue when it will be ready.
>
> This codebase is absolutely massive! I am beginning to
> lose patience.
>
> br,
> KK

This is one of the bigger things that you could attempt to build.

In the old days, there would have been almost zero chance
of you finishing the linking phase (XUL linking). Today,
they've fixed up how linking is done, so you might
actually finish the build without incident.

Keep a copy of "top" open, so you can watch the RAM consumption
during linking.

Paul

On Sat, 28 Dec 2024 20:30:07 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> I cannot understand this because all references to
>> patches 416 and 419 are commented out in the Fedora
>> 41 spec file. I now completely removed them and will
>> try again...
>
>I am having massive problems with having only 16GB of
>RAM.
>
>Using 'top', I was able to see that Rust compiler 'rustc'
>was hogging something like 11GB of memory, and then
>after a while OOM killer got rid of the Rust compiler
>process. I am also seeing swapping take place when I
>attempt the build.

Why TF is the rust compiler involved in the process at all?

On Sat, 28 Dec 2024 23:32:37 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
>>
>>> You think it's normal that on a Linux installation where, say, no 'cc'
>>> (as prominent example of a development tool) is installed the package
>>> manager would first install ALL the necessary compilers and scripting
>>> languages just to create a binary (as opposed to just installing the
>>> binary)?
>>
>> The discussion has to do with creating your own version of the binary,
>> rather than using the repo-provided version.
>
>Right.
>
>Anyway, to be honest, I never realized how bloated Thunderbird is.
>The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
>the main source directory unpacked is:
>
>~/tmp/tb/thunderbird-128.5.2 $ du -sh
>4.2G .

Welcome to Lego brick style programming where the main application devs are
incompetant halfwits unable to implement even simple things themselves beyond
designing (if that applies to Thunderbird) a GUI so have to import 101 libraries
to do everything for them.

I've written my own newsreader system and while admittedly its command line
only it requires only one 3rd party library which is OpenSSL.

In article <vkr61v$srrk$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>Why TF is the rust compiler involved in the process at all?

Well, obviously, because parts of TB are (apparently) written in Rust...

Rust seems to be, like Python, trying to ingratiate itself into the basic
running of the system, not just be a peripheral "scripting language".

--
"It does a lot of things half well and it's just a garbage heap of ideas that are
mutually exclusive."

- Ken Thompson, on C++ -

On Sun, 29 Dec 2024 10:33:43 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>In article <vkr61v$srrk$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>Why TF is the rust compiler involved in the process at all?
>
>Well, obviously, because parts of TB are (apparently) written in Rust...

Christ, who's stupid idea was that?

>Rust seems to be, like Python, trying to ingratiate itself into the basic
>running of the system, not just be a peripheral "scripting language".

Requiring 2 seperate compilers to build anything is an absurdity.

On Sun, 12/29/2024 4:54 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 28 Dec 2024 23:32:37 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
>>>
>>>> You think it's normal that on a Linux installation where, say, no 'cc'
>>>> (as prominent example of a development tool) is installed the package
>>>> manager would first install ALL the necessary compilers and scripting
>>>> languages just to create a binary (as opposed to just installing the
>>>> binary)?
>>>
>>> The discussion has to do with creating your own version of the binary,
>>> rather than using the repo-provided version.
>>
>> Right.
>>
>> Anyway, to be honest, I never realized how bloated Thunderbird is.
>> The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
>> the main source directory unpacked is:
>>
>> ~/tmp/tb/thunderbird-128.5.2 $ du -sh
>> 4.2G .
>
> Welcome to Lego brick style programming where the main application devs are
> incompetant halfwits unable to implement even simple things themselves beyond
> designing (if that applies to Thunderbird) a GUI so have to import 101 libraries
> to do everything for them.
>
> I've written my own newsreader system and while admittedly its command line
> only it requires only one 3rd party library which is OpenSSL.

You know that Thunderbird uses the source code of Firefox,
to build XUL.so , which is the rendering engine for the interface.

Thunderbird is the demo app for XUL. It's not really
a product, it was partially a creation which was
intended to show how XUL could provide a web render
engine for another software package.

As a result, a relatively small amount of code, implements
News and Email functions. At least 90% of the vast volume
of files in the tarball, is a copy of the Firefox source.

The Thunderbird build tree, even has an option to "just build Firefox".
This is a means of proving the Firefox portion of the tree was
not damaged by staff during tree preparation.

The Thunderbird program, tries to restrict just exactly
how much of Firefox is used for "browsing". If there is a
URL in an email message, Thunderbird would prefer to call
the platform browser (whatever it is) to handle the URL.
But if the Thunderbird staff want to put up an appeal for
donations, using a Mozilla-hosted web page, that part uses
the Firefox code inside Thunderbird, for rendering. This is a
security consideration, an analysis and action on the attack
surface available. Notice that Thunderbird does not do
"Quantum" the way Firefox does, so it doesn't have exactly
the same security precautions. And that's because the
browser portion, is not really intended for "general browsing".

The Thunderbird GUI is a three-pane view. If the render engine
fails, the pane view turns yellow and there is a reference
on the screen "to an XML file". It is that XML file, which
draws the three pane view and populates it with decorations.
When you see that yellow failure condition, that's your
chance to verify exactly how the product works. The graphics
are not drawn with Athena widgets. The graphics are a demo
of what the XUL shared library can do for you.

Is the whole thing obscene ? Yes. You won't find too many
software creations, this distorted. Still, people are using it.
Most people are not aware what is under the hood. It's
a herd of elephants :-)

Paul

Muttley@dastardlyhq.com wrote:
> Why TF is the rust compiler involved in the process at all?

TB codebase is a mix of C++, Rust and JavaScript.

Without my hack, the build process took four hours to complete
and it produced a working TB. However, with my tiny JavaScript
modification, the build failed.

Because these builds take four hours, I have to admit defeat.
I simply do not have the time to make more modification
attempts.

What is more, James Kuyper said that he does not want to
build his own TB so it was all in vain anyway.

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Because these builds take four hours, I have to admit defeat.
> I simply do not have the time to make more modification
> attempts.

Well, I did give it one more go and this happened:

Dec 29 16:03:10 14-5A-FC-31-E8-67 kernel: [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
Dec 29 16:03:10 14-5A-FC-31-E8-67 kernel: [ 1058] 998 1058 4009 225 32 193 0 73728 160 -900 systemd-oomd
Dec 29 16:03:10 14-5A-FC-31-E8-67 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-2.scope,task=rustc,pid=244790,uid=1004
Dec 29 16:03:10 14-5A-FC-31-E8-67 kernel: Out of memory: Killed process 244790 (rustc) total-vm:16524360kB, anon-rss:9185412kB, file-rss:448kB, shmem-rss:0kB, UID:1004 pgtables:30152kB oom_score_adj:0
Dec 29 16:03:13 14-5A-FC-31-E8-67 kernel: oom_reaper: reaped process 244790 (rustc), now anon-rss:212kB, file-rss:448kB, shmem-rss:0kB

That was a single CPU build but it still failed.
My hardware just does not cut it with monstrous
builds like TB.

br,
KK

In article <vkrfue$vl1b$1@dont-email.me>, Paul <nospam@needed.invalid> wrote:
....
>Is the whole thing obscene ? Yes. You won't find too many
>software creations, this distorted. Still, people are using it.
>Most people are not aware what is under the hood. It's
>a herd of elephants :-)

Just out curiosity, does all of this apply to the Windows version as well?

I know this thread is mostly about the Linux version, and although I
actually don't use TB at all, I know someone who uses the Windows version.

--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.

- Maya Angelou -

with <vkpkn3$ga7s$1@dont-email.me> Kalevi Kolttonen wrote:
> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> ./mach build -v
>> with
>> ./mach build -j6 -v
> Okay, I am finally back at home and it is 21:43 o'clock.
*SKIP* [ 14 lines 1 level deep]
> I cannot understand this because all references to patches 416 and 419
> are commented out in the Fedora 41 spec file. I now completely removed
> them and will try again...

Yay! The joy of building redhat. Expect your build dependencies being
inadequate, missing, or plainly wrong. Just saying.

p.s. No, I'm not enjoing your pain. Just to make things clear -- about
two decades ago I've upgraded RH5.1-modified to something RH6 (IIRC)
then added RH7.3 to the mix. Slackware way (rpmbuild wasn't an option
because look-ma-no-interwebs).

p.p.s. Then in The Moment of Clarity I realised that I was making a
mistake. And immediately made another.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Eric Pozharski <apple.universe@posteo.net> wrote:
> Yay! The joy of building redhat. Expect your
> build dependencies being inadequate, missing,
> or plainly wrong. Just saying.

After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.

I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!

br,
KK

On 28.12.2024 20:26, James Kuyper wrote:
> On 12/27/24 18:44, Janis Papanagnou wrote:
>> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>>
>>> Compiling Thunderbird should be very easy indeed
>>> when we use Linux distro's package management.
>>
>> You expect _users_ of tools to use a _development_
>> environment to fix *inherent* shortcomings of a tool?
>> (Shortcomings that should not be there in the first
>> place!)
>
> IIRC, this is in reference to my difficulty when Thunderbird changed the
> Reply button to mean "Reply" rather than "Followup", and instead added a
> new button that is labelled "Followup". I have never complained about
> that change - it was an entirely sensible one. I'm just having trouble
> re-training myself to use the newer, more sensible interface in a few
> years after spending a couple of decades using the older, less sensible
> one. And I fully appreciate other people's irritation at my difficulty
> with re-training.
> I wouldn't mind if they reinstated the ability, which existed in older
> versions of Thunderbird, to rearrange the list of buttons that are
> displayed. I do complain about the removal of that customization
> ability. I don't want to go back to those older versions because that
> would mean undoing other improvements. I'm especially worried about
> undoing security bug fixes.

The post didn't contain a reference to your case (but I also had it
still in mind). My reply was based mainly on own experiences with
TB (and with experience in software development, software ergonomy,
and system environments in principle).

I do understand the "re-training" aspect. - Been there. It was so
annoying (to me) that I was desperately seeking a way to fix it on
the user-interface level (and finally [somehow] succeeded in some
[non-obvious] way).

A feature to rearrange buttons (as being present in some former TB
releases) is not something that I'd consider to be a sensible user
interface for application software for several reasons.[*] - Here
we might be disagreeing on what should be part of a user interface
and what should be defined in a sensible way in a predefined form
that matches the application case, and not polluting the interface.

I understand well that you don't want to go back to older versions.
Myself I also don't want to go forward if that means that I have to
buy some change that results in inferior software behavior; but it
happens, sadly.[**]

>
> I don't like the idea of creating my own personal version of Thunderbird
> by modifying their source code, because it means I would have to re-do
> the build every time they put out a new version. I want quick and easy
> upgrades to newer versions, especially security bug fixes, and that
> desire conflicts with the desire for customization.

Exactly, that's one reason; against a system-wide replacement.[***]

Janis

[*] Given that I meanwhile see tons of followups on this thread and
the [in this NG] well known effect that even small "BTW-statements"
are leading to bandworm-threads with much heat and little substance
I'll not extend on that here; with minimum software experience and
an open-minded thinking it should be obvious anyway.

[**] That's why I was amused by the other posters "[...] modern ages
where things have been made quite convenient for us."

[***] You could of course create a separate version in /usr/local and
define your PATH appropriately, but you still would have to keep track
of newer changes, e.g. those security fixes that you are concerned
about.

On 29.12.2024 11:38, Muttley@dastardlyhq.com wrote:
> On Sun, 29 Dec 2024 10:33:43 -0000 (UTC)
> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>> [...]
>
>> Rust seems to be, like Python, trying to ingratiate itself into the basic
>> running of the system, not just be a peripheral "scripting language".
>
> Requiring 2 seperate compilers to build anything is an absurdity.

(Disclaimer: I skipped most of the sub-thread, so if that generalizing
sentence was addressing some peculiar (maybe even TB-related) software
specialities you may ignore the rest of my post.)

From my experience it's no "absurdity" but actual (sensible) normality
to use multiple compilers and other software generators in SW-projects.

It seems that depends on the software architecture. It's (IMO) fine to
create libraries that are combined in an "anything" to be compiled with
the (at the time of their creation) most appropriate compiler. It's
also fine if you use a second language as a higher-level intermediate
language. Also if you create the "anything" based on several components
(or subsystems) that are combined. Using separate protocol compilers is
also not uncommon to get the transfer objects and functions. Also using
own compilers for the accompanying parts like documentation is typical.
(All these examples just off the top of my head from some professional
projects that I observed or was engaged with.)

Janis

On 29.12.2024 13:39, Paul wrote:
> On Sun, 12/29/2024 4:54 AM, Muttley@dastardlyhq.com wrote:
>> [...]
>>
>> I've written my own newsreader system and while admittedly its command line
>> only it requires only one 3rd party library which is OpenSSL.

That's a fine property. - Too bad one has to write one's own piece
of software to get a more sensibly defined product.

> [ snip explanations of some TB internals ]

Very interesting.

>
> Is the whole thing obscene ? Yes. You won't find too many
> software creations, this distorted. Still, people are using it.
> Most people are not aware what is under the hood. It's
> a herd of elephants :-)

You get some impression of what's under the hood if you try to fix
that [supposedly] primitive issue with the Reply-button. But it's
(software design wise) actually even worse than I'd have imagined.

Janis

On 29.12.2024 15:32, Kenny McCormack wrote:
> In article <vkrfue$vl1b$1@dont-email.me>, Paul <nospam@needed.invalid> wrote:
> ...
>> Is the whole thing obscene ? Yes. You won't find too many
>> software creations, this distorted. Still, people are using it.
>> Most people are not aware what is under the hood. It's
>> a herd of elephants :-)
>
> Just out curiosity, does all of this apply to the Windows version as well?
>
> I know this thread is mostly about the Linux version, and although I
> actually don't use TB at all, I know someone who uses the Windows version.

I've used the Windows version quite some time ago. I can only say from
a user's perspective that it was similar to use; maybe the menus were
organized a bit differently (memories are faint). (Can't say anything
about the/any "under the hood obscenities" on that platform.)

Janis

On 29.12.2024 21:55, Janis Papanagnou wrote:
>> On Sun, 12/29/2024 4:54 AM, Muttley@dastardlyhq.com wrote:
>>> [...]
>>>
>>> I've written my own newsreader system and while admittedly its command line
>>> only it requires only one 3rd party library which is OpenSSL.
>
> That's a fine property. - Too bad one has to write one's own piece
> of software to get a more sensibly defined product.

I forgot to ask; wasn't it an option to use any existing text oriented
newsreader (nn, rtin, ...)?

(I recall I liked 'nn' a lot back these days.)

Janis