[GoLUG] Writing an internet server (was: Mailing list, long term.)

[Barry Fishman]

[I've changed the subject line, since I think I have wandered into
a more general topic.]

On 2025-08-18 19:30:11 -07, Ron wrote:
> Barry Fishman wrote on 2025-08-18 10:19:
>
>> My impression is that the JS repository has distributed a lot of
>> dangerous code, and is very badly supervised.
>
> If you mean Node repos, yes it has been targeted a lot due to its
> popularity.

It's also has had a history of lacking oversight in keeping dangerous
software out of it.

>> It's code is pulled in by the web browser
>
> A lot of Node repos' code is run on the server side - back-end code.
>
>
>> Although the browser may be heavily sandboxed, it still seem to
>> trigger a lot of internet CVEs.
>
> A browser is a very large application by its nature and since it is the
> most common interface to the internet, it does get more CVEs than most
> applications that are not users' primary internet facing software.
>
> Yet it's exceedingly rare for users to get "infected" via web browser
> considering the billions of daily users across billions of devices.
>
>
>> Python doesn't dynamically load its code from the internet
>
> Yet one line of Python, whether malicious or incompetent, can have
> devastating effects with its access to the user's home folder.
>

I think my point of view may be colored by a lack of trust in browsers
in general and my situation in particular.  Browsers are complex
programs where the security issues are complex, that requires the
attention of people writing software for them.  They are in the hands of
companies like Google, Apple, and Microsoft who have demonstrated a
desire for profit that exceeds that of their desire to protect the
interest of their users.  Firefox is a bit better, but to produce a
browser that meet all the industry set standards and stay in business is
limited in what they can do.

Being retired and programming primarily for my own benefit, I don't like
spending my time writing software who's function is dependent on the
good graces of an industry that has show very little regard for their
users desires.

Python is community (although I don't tend to use it myself) which
has shown a strong desire to make its users welcome.  Even when they
make a fundamental change like Python2 -> Python3, they don't suddenly
withdraw the previous version, or remove functionality from the
language.  Looking at their APIs, I find them to be very well
designed.  

Even Gnome, which I have many differences, at least seems open about
what they are doing and where they are headed, and their software base
is far easier (for me at least) to look at the code and workaround any
problems than that of any of the browsers.  I still disagree with a
great many of their decisions.

Some people here feel that they are overly influenced by companies like
RedHat, but I think they suffer more from the Silicon valley mindset
with their perceived meritocracy and single minded lack of consideration
of other points of view.

> It is not sand-boxed at all.

Sand-boxing is a workaround which browsers have integrated into
themselves to avoid their own design failings.  It greatly increases the
memory footprint and slows the browsers responsiveness.  I could just
run each browser invocation in a separate container, and then determine
when such a tradeoff is worthwhile.  On nice feature of Qubes was that I
could (out of the box) run browser in multiple levels of security and
user contexts, down to a pure tor environment.

And a sand-boxed crypto-miner, or DoS agent might not change files on
your computer but I still class a security issue.

> i.e. I argue it's much, much safer for a user to run JS in a browser
> than the equivalent functionality in Python.
>
> Plus, JS is supported everywhere and running Python on many platforms is
> difficult to impossible for average users.

Python does have the issue that all extendable interpreted environments,
in that it does require careful user setup.

This is mostly avoided when you install all the required parts with you
distributions package manager, but when you use things that are not in
the package manager things can get more complex.

I'm not sure of the current situation is with Python, since I don't use
Python very much, and use NixOS where the situation is quite
different. The Free Desktop solution with its ~/.local, ~/.config/ etc
setup work well with packages and distributions that use it.  I know
that some programs are distributed as zip executable that seem to work
just fine.  I did that a long time ago.

>> Since this thread seems to be the usual response to the "I want to
>> write some code to fix this problem I have found", which is "lets
>> all discourage them from doing anything"
>
> I disagree, it's more like "Have you considered $x?" and "your assertion
> of $y is not well supported", with attempts to explore these issues.
>
> Could save a *lot* of pain during the development process by hashing
> out issues in advance.

I guess I was a bit over the top. May I call it poetic license? :-)

Sometimes what drives someone to write code is that although other
solutions exists, they tend to be far too complex or involved to want to
use.  One would have to spend time working around issues in an existing
code base that you are not familiar, rather that on thinking about what
you really want to do.


                      -----------------------

[My argument stops here, The following is purely my point of view, but
feel free to comment on it.  It probably uses a lot of poetic license.
The current political climate has its influence, but I'm not talking
about politics.]

Unix was an attempt to build a system from simple small programs that
would interplay with each other, rather than large complex independent
programs (applications) each trying to meet a variety of specific goals.
It was a reaction to Multics, but also meeting the needs of a far more
primitive available computer. You appreciate this more when you run Unix
on a PDP-11, and your shell pipes end up being done one command at a
time with the input and output temporarily saved in /tmp as files.  "cc"
take a while with all the compiler phases being run one at a time.

But I like this approach, and develop most of my code in this context.

The GNU tools were an attempt to copy that environment.  However, they
used bigger programs that tried to do things in memory and had many
options built in, as was done to some extent by BSD.  It wasn't that
they were not appreciative of Unix's simplicity, but that they were
trying to avoid being sued by AT&T.  It seems that there is not much
variation in approaches to simple stream based programs that do one
simple thing, and they really couldn't afford to defend themselves in a
court fight.  Richard Stallman was very clear about the initial
guidelines for the project, and the tradeoff.  But more options then led
to the idea of "--key=value" style options to make them clearer, which
made for more options, etc.

We may complain about all the options to a command, but few people want
to go back to "ls | mc | more", although it usually ended up as a shell
function in your .profile file.

lc () {
 ls "$@" | mc | more
}


My appreciation of this approach may seem like a conflict with my use of
Lisp and Emacs.  It is, to a point.

Lisp System are built from blocks of code that solve particular
problems.  They are wired together at the "protocol" or API (function
call) level.

The basic data components are lists or a-lists (dictionaries) or
tree structures these work like the file or streams seen by the Unix
Shell. protocol (API).

Modes (like a shell script) use these component's APIs to build
functionality (a program).

Lisps separate these building blocks using separate name spaces, rather
than separate executables, but the intent is the same to isolate the
code blocks (programs).

They can use hooks (also functions) in traversing these components and
build the functionality of the program, allowing one to adapt how the
program works.  A kind of powerful replacement for how the Unix shell
environment works.

Emacs is an old Lisp System that lacks Common Lisps idea of name-spaces,
and simulates that with function/variable naming conventions and mode
scope.

You might say that all computer languages have this facility.  Yes.  Many
of the more modern languages are very explicit about it.  But many large
programs don't make its protocol structure very explicit, or it extends
to only some of its functionality.  It isn't wired into the brains of
its programmers, and the structure of the language.

I was a enthusiastic C++ programmer, but when faced with some basic
programming problems it became clear it was a language problem, not a
coding problem.  I learned to code around them, but it felt like a hack.

I began looking at Common Lisp, and learned how these problems were done
in that language.  It changed my feelings about C++ completely.

The closest non-lisp language I have found that captures some of this
modularity is Haskell.  The Monads in Haskell form it Unix like "Shell".
In fact the file system (streams) which are the basis of the Unix
Shell becomes just a Monad in Haskell.  Shell pipes are in some sense a
Monad, and behaves much like one.

In (lisp based) Emacs this view has been implicit from its start.
Although it had shed much of its Common Lisp style functionality, it has
slowly found itself reluctantly re-adopting some of it back.  Most user
code ends up like a shell where you build your own data structure (file
like) and produce interactive functions (shell like) to build your
desired mode (program like).  Most of the time you don't have to go that
far, and just override parts of the mode you are trying to replace.

For example I am writing this in a Emacs text window, which as a part of
GNUs, is made into a reply window with its own extra functionality.  It
then has some additional functionality I have wired in from other
packages, some not distributed with Emacs.  Even though they are layered
they are still separate and don't usually interfere with each other.  It
like object oriented class hierarchy.

For example, my code (via the Corfu package), as I type it often suggest
completions for the word I am typing in dynamically changing popup
window which appears just below (or above) where I am typing.  Being a
bad speller I have enabled this functionality.  I can ignore the window,
or just hit tab and select the current option.  Or using the up and own
arrows move around in the popup list of words, select another word and
use that.  The interaction takes a bit of getting used to.  This is a
bit like the mobile phone keyboard widget that continually suggests
completions.

If you find this annoying in Emacs, as I sometimes do, Your can shut it
off at any point in time (and later turn it back on).  Of course by
default the mode is never turned on, you have to choose it.

The choice is mine not the Emacs main developers.  Many of them hate it.
They might never have conceived of doing it but someone saw the
possibility and implemented it.  It also used the popup functionality of
another package, although you can provide a different means of
displaying the options such as another Emacs buffer.

If I was into AI, there are AI plugins that will come up with what words
or phrases to put in the popup.

I can control this interaction in many way like how long it delays
before showing the popup, or how many characters to type before it pops
up.  I can control which text buffers to enable it, or just do it
everywhere.  So if I am in IRC chat I can use the feature.  If I am
programming in Python it knows what functions are available and prompts
me with a choice of those.

The core functionality that underlies this is build into Emacs, but not
the specific use case.  This is not the only area that this tailoring
applies.  Its a design that has been built up since times when Lisp was
developed as a platform for AI research in the 1960s.

Its not as hard to do as it may seem.  Once you learn the structure of
the system you can find where to look for the hooks.  Emacs will even
bring up its source code where the underling feature is implements in a
text window.

This is hard for new (probably most) Emacs users.  But you don't have to
use it.  As one becomes more accustomed to using Emacs you might learn
about it and someone could give you a block of code that you can include
in your startup file to turn this on.  Of get that information from the
web page for Corfu mode (its not in the base Emacs documentation until
you install it).  Like most lisp systems, Emacs contains its own
development environment built in.

This kind of thing exist all through Emacs.  Its not so much that Emacs
has a IRC client (actually several) built into it, its just that one can
be assembled from similar modes, with new required functionality added.
I'm not saying any of this is easy to do.  Its just that with experience
it becomes easier, to the point that there are lots of these things have
been written, and over time people develop their own functionality.  The
problem is not so much adding new functionality to Emacs, but spending
too much time doing so, and not actually doing your real work that you
went into Emacs to do.

But the fact that it may seem hard for new users does not mean the that
experienced users should not have the ability to use it.
I am not a meritocracy believer who feels everyone who doesn't spend their
time learning a system does not deserve consideration.  But I don't feel
that because most people find it hard, it shouldn't be made impossible,
or even extra hard to do.  And its existence does not keep others from
using simple editors

But Emacs can be used like any other editor, with the same keystrokes,
arrow keys as keypad keys as any simple editor.  It even has a familiar
top menubar which you select files to edit, save them, and exit the
program.  It my be a bit slower responding and hinting at a deep level
of functionality that seems just out of reach.  The complex seeming
control/shift/meta level of commands are there and if they get you into
trouble you can just use the menubar edit options to undo your changes
and see that this undo can also be done by "C-x u", whatever that means,
which might encourage you to read the tutorial you get shown each time
you start up Emacs.

My intention was not to sell you on Emacs, but give it as an example of
how systems can be put together.

                         ----------

Note that neither Gnome nor KDE allow Emacs like key bindings in their
text windows.  But both MS Windows and Apple do support them.  Gnome did
up to version 4, but actively removed the code and made it difficult to
add it back in.  I could add the code in myself but it would involve
replacing the whole GTK4 library package, and on an invariant OS systems
like mine, having to rebuild all of Gnome from scratch.  GTK was built
on a great and very flexible object model, which made moving it from
Gimp to build a general window system was possible.  Gnome has since
then systematically pulled out features that they had used to do that
port.

They say that the code makes it more difficult to build the window
system that they are designing.  If people are given this kind of
functionality it will make supporting the functional they want all Gnome
users to use harder.  In some sense it does.  But the cost is their code
is less useful to others.  They want their Window system easier for
their perceived new users.  My impression is that people coming from
Windows tend to choose KDE over Gnome partly because its more familiar,
but mostly because it easier to modify to make it like they want.

KDE makes it easy to change its behavior.  But it doesn't seem to have a
simple way of undoing a set of changes, or even snapshot the current
setup so you can restore it latter, or move it to another computer.
I had a friend who invested a lot in tailoring a KDE4 environment the
way he liked it.  When KDE5 came out he was very reluctant to use it
because he would loose all the effort he put into his KDE4 environment.

Gnome does have the ability to snapshot your configuration into a single
text file, and restore it onto another system, or restore a system you
have messed up.  I don't use that facility but have a set of "gsettings"
shell commands and procedures that I use to make my usual changes to
Gnome.  Its like editing the Registry in MS Windows.

-- 
Barry Fishman