Hi FRIGN, On 15 September 2016 at 12:17, FRIGN <d...@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
