Hello everyone!

I have a couple of ideas that could improve GNU systems and, in particular,
Hyperbola. These ideas need discussion, and I also have some questions about
them. The ideas are arranged in the order of their ideal implementation
chronology, but that's already utopian.

1. Standardization of Programming Languages

At some point, I wondered why Python developers make so many stupid changes
with each minor version. Then I noticed that C and C++ have standards, Ruby has
a standard, and why can't Python have a standard to follow and just fix errors
in the interpreter? I asked this question in a Python IRC channel, and it also
concerned how to write books about Python if they become outdated in six
months. A few contributors replied. Some complained that the ISO would do
everything themselves and not listen to people's wishes. But the question that
struck me was, "Don't you want Python to evolve?"... F**k, we need to write
software, not track Python changes. This problem could be solved even without
the ISO and other standardization organizations by thinking through a standard,
for example, PY224 (Python 2024), and if changes in the language are necessary,
just update the standard to PY227. Currently, technically, Python is not a
language.

2. Chains of Writing -> Testing -> Packaging

We need to come up with a software development chain. Here's what happens now:
I am a developer of something (it doesn't matter what), and I have CI/CD
systems, I have a version control system, but I don't have a system for
tracking changes in my project's dependencies, nor a security testing system (I
mean fuzzing). Suppose I am writing a project in C and want the changes in the
libc API that concern my project to be sent to me by email, for example:

From: system.myhost.xyz
To: Me
Subject: Your project X

Developers have released a new version of libc 1.2.3.
Detailed changes: ftp://libc.host.org/1.2.3/ChangeLog.txt

The current version of libc used by your project is 1.1.1:
The following libc entities used in your project have changed:
int strcpy(char *dest, char *src); : Added new error value ERR_XFXF.

To switch to the new version, you need to change the use of the entity in these 
places:
ProjectX/src/srcfileA.c in line 1337
ProjectX/src/srcfileB.c in line 1338
ProjectX/src/srcfileC.c in line 1339

But all this works only if there is a development server, and what if there
isn't? For such cases, we need to think through interfaces for local use. At
the same time, everything described above should adhere to the Unix philosophy.
That is, the fuzzing program is separate, the change tracking system is
separate, and the CI system is separate.

I have thoughts on implementing a change tracking system:
First: every software that provides an API should provide a projectA.api.yml
file (for example). It describes the entire API provided. As a developer of
ProjectX, I add it to the ProjectX/usingapi/projectA.api.yml directory.
Second: I think that tracking the places where the API is used will be
implemented through ctags or something similar. Then the Change Tracking System
- cts.

Now, when I am in my project's directory, I execute:

$ cts news --no-changes-show usingapi/
libc: newest 1.2.3 current 1.1.1
libtls: newest 0.9.0 current 0.8.0
libgmp: newest 1.0.0 current 0.9.1

$ cts to-update "libc" "1.2.3" # What needs to change to update libc from 
current to 1.2.3
*** int strcpy(char *dest, char *src); ***
Description of the API in 1.1.1:
    <short description>
    params:
        ...
    return:
        ERR1
        ERR2
        ERR3
Description of the API in 1.2.3:
    <short description>
    params:
         ...
    return:
        ERR1
        ERR2
        ERR3
        ERR4
    Changes:
        return:
            ERR4
This libc API is used in:
src/file1.c:1337
src/file2.c:1338
src/file3.c:1339
src/file4.c:1340

It doesn't matter if your project is written in C, Bash, or JS; drivers can be
created for cts for any programming language to track dependency changes based
on entities.

Questions:
1) What existing systems can you recommend for CI/CD, fuzzing tools, and CTS?
2) Your suggestions.

3. Idea of Standardizing AI Systems in GNU

Sometimes I imagine using LLM as a standard GNU utility. These thoughts
intersect with thoughts about the Rockchip 3588 chip; I watched a video where
they ran a couple of LLMs on the Orange Pi 5. I think it would be cool to make
a kernel module for working with the NPU, and in userspace, create libai that
would provide an API for working with AI. But I've never even run AI myself.
And as I write this paragraph, I expect you to thoroughly critique my post so I
can think further.

4.Typesetting Language Instead of Heavy LaTeX

This project is related to the fact that LaTeX is simply impossible to use
adequately locally. It's an absolutely non-intuitive system. This project is in
progress, and there are already some developments for the interpreter.

My current projects:
httpoke - a free clone of BurpSuite with full compatibility with HyperbolaBSD,
using FLTK as GUI and libtls from libressl for the HTTPS proxy server.