>>42
>most of the intelligent posters here will immediately disengage.
There are none left. See below.
>>43-45
Not a single mention of the kbsd or killumos projects let alone gunug+lunix userland replacements like gentoo/netbsd.
The useful argument is projects like gentoo/netbsd are dead and openrc is still wacky for replacing bsdrc when daemontools does better. A majority of enoch was due to disgruntled bsd devs attempting lunix. A proven bad idea.
Otherwise yes it's just the same bullshit with different package mangers a few special patches and some themeing maybe preloaded mac rules tailored for the distribution packages.
Common bsds are only slightly better there's still tons of overlap and illumoses pull from the same base with a shitty bootstrap. Plan9s pull from the same base and do like the bsd but make it worse not better. Plan9 is going too far for this arguments usecase but it was bumped recently.
Now it's the codependent trolls turn why is this on /prog/.
Interestingly imageboards turned into lunix and textboards into bsd what a shitty pattern.
Bloat is socially constructed. When others demand we concern ourselves with bloat, we should ask what would we be thinking about if we weren't thinking about bloat? Are we being distracted from thinking about that? Does a distraction with bloat keep us working on solved problems? Does a concern over bloat restrict our thinking?
>>46
How did i get lumped into this??? I haven't made a single distro comparsion. At the most i've used systemd as an example of different bloat types.
>>47
The same thing, no, no and no.
At the core i am not really concerned about bloat anyways. What i am concerned about is superfluous complexity. Of course i could be thinking about/doing different things with the time used on this but avoiding complexity usually saves time later on so in the end there's time gained actually.
What happens when noone spends time on "bloat" is quite evident today: Giant heaps of complexity that have tons of bling with no productive value while making it painful to adapt to new usecases or optimize existing ones. On top of enormous resource waste and bad debug abilities in case anything fails.