future ; singular structure in software singularization

[xor]

future ; singular structure in software singularization

If you look at the problems experienced in a software
There are many problems that start with a missing file or a file that is not up to date.

even compiling the standard software compiler
first compile the kernel with this new compiler
and then all other applications
and likewise in their libraries.
It means compiling with the new compiler.

If this does not happen;
A growing fork of problems will emerge over time.

The fact that the files are scattered may mean that the required structure is used with smaller components and less memory is used.
In this case, it can be overcome with new standards that can be developed.
As a result, you only read one page of a book at a time.
It is important to realize that you do not read all the pages of your entire book at once.

What should the file structure be like?
1. application program
2. Application program settings registration files
3. development plugins
4. Development plugins settings registration files
5. created content files

Although the main topic should be this simple
It doesn't make sense to get lost in a mixed and confused structure!

Moreover, program development standards need to be rewritten.
program development standards
should be defined by production time dates, not version names

23-12
manule V 1.0.1,
ai-beta-test-model XXYY
etc etc.

According to 2023-12 month standards
handwritten V 1.0.1
ai-beta-model tested XXYY
It should be in the form.

If these don't happen, everything will become history over time.

If you simplify, problems become smaller. !
If you can't simplify, problems will grow. !!!

What is said here today
Tomorrow, there will be projects that will be patented and implemented by big companies. !

Let's put forward our proposal to deduplicate this idea under the GNU license and the rest will come anyway.