The runit init system used in Void Linux is a perfect example of how software should be developed.
After some years of updates, its developer declared, “the job is finished”, and he froze all development , even bug fixes.
Runit has been static, ever since. It has survived. No-one has had any problems. No-one is screaming for bug fixes. It just works.
Do it once, do it right.
There are other examples … the Unix utilities are rarely updated . They just work. There is no case for rewriting them in rust … it is not needed … there are no bugs in utilities.
The larger the program you attempt to write, the longer the debugging period. Some huge apps like browsers will probably be debugged forever … eternal updates.
There is a case for writing small apps. … cut the task into man-sized pieces.
Modern software seems to be going in the opposite direction. Code bloat is a disease … its symptoms are eternal updates and instability.
it is an isolated task and does not interact much with other parts of the OS
there is a size limit to human comprehension of code… if you exceed that it may never be debugged properly. AI might extend the size limit, but that will just encourage further bloat.
I dont think you can , for example, cut a thing like Firefox into manageable pieces.
You have to design the manageable pieces in the first place.
That was one of the achievements of the first developers of Unix … they knew how to keep things a manageable size.
With simple utilities, such as grep, cut, sort, and tee, it might be perfectly logical to write them once as a small utility and finish them at a certain point.
However, as @nevj mentioned nicely, browsers are extremely complex pieces of software. You might not expect it, but everything is able to manipulate everything else in a browser Window. That’s why web apps are a possibility these days. For better or worse, people seem to like it that way.
How would one create a web browser out of a million small utilities? Same goes for a word processor, spreadsheet, or video editing programs. These programs cannot be made small – lest they be less useful to their users.
You do it by dissecting the task. What is missing with GUI apps is a way of combining several smaller GUI apps. … there is nothing like pipes for GUI.
There is a challenge for you. … invent a way of making GUI apps work together
because
until we have that coders will be pressured into writing one giant app that does everything.
I assume this is not true. Even if I never used it actively, there must be an interprocess communication. I know in for sure from my windows programming experience.
The main concern is that most of the browsers nowadays are damned feature ceatures and resource hogs as well.
A browser just has to do what itss name suggets, browse the internet and make avoid any harm to the user and his system. But e.g., why has a browser to care about DNS configuration and contain so many other gimmicks?
GUI is very visual. There is the X protocol – I have zero knowledge of it, so feel free to correct me – which can be used to make various apps work together with some gymnastics.
Thing is, the screen has a lot of data throughput, especially where it concerns non-trivial animations; say a bird flying from one end of the window to the other. In cases like this, and even more complex cases, you want the best possible performance – unfortunately, piping data from one application to the other is not really as fast as it can get.
However, looking beyond the limitations, I can imagine having downloading data and uploading data piped around for a browser could really be useful. That being said, there are some browser based applications which need a real-time connection. How do you suppose to solve those, without taking the performance hit piping stuff around would mean?
I guess the other way is dynamic loading of plugins … like the kernel does with modules.
I could imagine a GUI where you moved things around and plugged them into other things.
Such as widgets, which is supported by most major DE?
EDIT: thing is, this isn’t all that easy. With GUI applications a certain amount of performance is expected. Also, GUI users generally are not waiting to put their own applications together. They simply want a ready, functioning, application. Turning the GUI into a puzzle, defeats the purpose of it.
Well how do you propose we encourage developers to write small feature-free GUI apps?
We want apps that are stable and debuggable. … that means they should be man-sized and focus on one task
Here is an example. Some years ago KDE decided to make Konqueror act as both a browser and a file manager. … BAD IDEA … it resulted in something that was second rate for both tasks.
How do we discourage that?
Firefox is enormous… and they keep adding features that I will never use. … I want a basic browser app, with the ability to somehow link in features if I choose… a bit like a minimalist Linux where you add only the parts you nèed.
it is an isolated task and does not interact much with other parts of the OS
I am agree with both but they are tight with something important: Complexity about what the task is resolving
there is a size limit to human comprehension of code… if you exceed that it may never be debugged properly. AI might extend the size limit, but that will just encourage further bloat.
Can you expand the idea pls?
I dont think you can , for example, cut a thing like Firefox into manageable pieces.
You have to design the manageable pieces in the first place.
Interesting point of view
That was one of the achievements of the first developers of Unix … they knew how to keep things a manageable size.
Agree
The situation is: how was planned to build from the beginning each software?. FF vs Unix
That is a human weakness
Even with that … consider the following: if hardware technology changes or “evolves” then the kernel code must be upgraded. Right?
"There are two ways to get enough: One is to accumulate more, and the other is to desire less.” Bishop Fulton Sheen
Have read the good news about him? See the YouTube channel of EWTN
People will keep suggesting “improvements” but they rarely suggest downgrades.
Interesting point of view. Could you share some examples about “downgrades” in software?
I’ve found an example for you: uzbl; a browser which adheres to the UNIX philosophy.
LyX might be another example of what you’re looking for. It’s a word processor.
I think you’ll appreciate these people. Their software is right down your lane.
All that being said, I think there’s a lot of software which is simply too complex and too demanding to make a small binary of (browsers being such a case). Yes, you can take a lot out, but the core still remains big.
You might also be interested in the Ladybird browser project. They want to make a completely new browser from nothing. They seem to got some stuff going, but they’re still at an alpha state.
small programs like cat or ls seem to never require updates … they are completely debugged
runit developer has taken this to the next step and declared runit to be comp,etely bug free and frozen
large programs … like browsers, word processors, seem to get bug fix updates and expansion updates forever
I personally find it harder to debug large slabs of code … unless written in a very modular fashion.
So , I conclude some current popular apps are too large … too large a codebase for one person to master and too poorly structured for a team to master.
So , I am looking for better ways to eg) write a browser.
Maybe the way forward is … use AI to write even larger programs , because AI seems to be able to comprehend large code slabs better than any person.
or
Maybe the way forward is to abandon bloated concepts like browser and instead define a toolkit of smaller concepts. Coding that should be easier
I notice that Office software is a toolkit of word processor, spreadsheet, and presentation blobs. Maybe we need to push that breakup further.
Changing from systemd to more modern init systems like dinit, runit, S6. That move is a downgrade in the sense that modern init systems are smaller in concept and in code size.
We can already see that runit, for example has less bugs than systemd and way fewer updates… in fact zero updates.
I like it. … enough to give it a trial … will report back
Yes, it tries to do what I am advocating.
I would like to see something more radical … I think there is a simpler solution
to code bloat somewhere … maybe not implemented but a concept in someone’s dreaming.