Re: [stali] Purpose (was Re: [dev] Re: [stali] updating package source)

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Thu, 15 Sep 2016 13:24:19 +0200

Hi FRIGN,

On 15 September 2016 at 12:17, FRIGN <dev_AT_frign.de> wrote:
>> concentrate on the essence here, this is all a waste of time.
> - hiro
>
> to be fair and meaning no offense to anybody, I think stali in
> general is a waste of time. It is too ambitious given the low manpower
> and the hypetrain, if I may call it so, is just pissing people off when
> they hear
> 1. how long ago this has been announced, still being vaporware
> to this day
> 2. how "many" people are working on it
> 3. how overambitious it is (rewriting makefiles for base, ...).

It all boils down to the scope that one wants to achieve with stali.
If you expect a suckless linux distro in the fashion of Debian or
Ubuntu, you know where to find it. stali surely aims to suck less as a
distro, hence its scope cannot be "general purpose".

stali's scope is now targeting embedded or special purpose
setups/platforms. Maintaining this scope is doable and doesn't require
herds of people performing crap management. The current software in
src/ is already too much for my taste and I will strictly reconsider
certain stuff that is currently in. I already mentioned my plan to
introduce 9base, as I believe it is superior to posux rewrites for
several reasons ;)

I see stali as an interesting platform for IoT devices in the future.

I agree that developing a general purpose distro with stali's design
goals is and would be a very hard task and require a lot of effort.
Hence I also gave up on this idea some years ago. But for the special
scope it is doable and works. I use it on my pi's for a special
purpose.

> The only Linux package manager which really does dependencies right is
> portage, even when the dependency trees are huge. And it also makes it
> really easy and straightforward to create cross compilers, which is
> usually a huge mess.

One rule of thumb is, that if you consider "packages" or package
management, you have left the suckless arena already. It is for a
reason that stali has no package management, because it is a magnitude
of complexity that can be avoided if done right. src/ is my answer to
"package management".

> up time, unless you spit out makefiles in 10 seconds each. Rewriting
> the build systems for other projects and maintaining them along the
> line is borderline insane.

You might not believe this, but having the stali.mk's in src prior to
my last session where I updated the software components of src/ proved
to be less of a hassle than in the first place when I was forced to
use autohell to identify all object files and compiler flags required
for the project in question.

If I interpolate this, in the longer term the time spend in developing
your own build system aside the official autohell crap pays off. As
said, it cannot be done for everything. But if you are after a very
simple basic system with no crap aboard, stali is already quite close.
The vaporware times are gone now. Have a look at what has happened
this year. The effort involved wasn't a big deal.

Cheers,
Anselm
Received on Thu Sep 15 2016 - 13:24:19 CEST