On 03.12.18 10:49, g4sra wrote:

> As someone has already pointed out on this mailing list Linux Distros in
> general are taking away the freedom to customise (in particular for a
> specific User case).

Not necessarily. Some distros are better for easy customizing than
others, but in the end you can always run your own package repos
(which, in fact, I'm doing regularily).

OTOH, the question often is, whether customizing is really worth the
effort for a particular use case.

> I get that maintenance is an issue, but only
> because software growth has become disproportionate. if there wasn't so
> mush software <<Freudian slip *much* software, it wouldn't require
> software to manage it all and there would be even less software, just
> look at the number of different software build systems there are.

Correct, much of today's software as grown insanely huge and complex.
Browsers (and GUI stuff in general) are probably the best example of
ugly bloat code and bad engineering (beginning w/ lack of modularity).

IMHO, we should work closer w/ upstreams and other distros to improve
the packages step by step. Sometime this also requires some radical
steps.

> Do one thing! do it well!

Correct. But look at the commercial projects Mozilla: they're
trying to roll their operating system, completely ignoring basic
concepts like modularity and package management, and are pretty
learning resistant. At some point you'll have to decide whether
it's worth to invest any resources at all or just drop the whole
code completely.

> I have already hit issues in Devuan that have been inherited from
> Debian. The initramfs\initrd should (and used to) do one thing and do it
> well. It is now so convolutely complex you can do away with the root
> filesystem altogether.

At that point we could go that route consequently and introduce a
strict separation between an init-OS and an main-OS, maybe even move
to some container environment. That idea needs some deeper thoughts ...

> I understand that there are not enough Devuan developers to fix
> everything. I was pondering whether LFS will suit the corner cases which
> even Devuan cannot reach.

Probably. But it takes a lot of time for systems maintenance.
Aeons ago, I've been maintainer of an LFS derivative (l4g) - that was
a really good learning experience, but I wouldn't use it for production.

For some use cases, I'd rather think of building customized images via
PTXDist, maybe run them in chroots or containers.

> Has anyone here have actual practical experience of using LFS to build
> anything moderate (or larger). If so, how much work did it take and was
> the effort worth it in the long run, were there any shortcomings ?

Can't tell anymore, it's sooo long ago. But I've spent really huge
amount of time. Maybe it's much easier now, or maybe it's much more
complex as today's software had become so complex. No idea.

What are the actual use cases you have in mind ?


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287