The existence of my toolchains, and Zach's, is relatively independent
from the existence of lh-bootstrap and mkroot.
As far as I'm concerned, the creation of these toolchains was an
exercise in working with musl-cross-make at start - and then some
people found them useful, so I built them for more architectures.
And landley made it very clear that he does not want to host GPLv3
binaries on his sites, that's why he does not offer precompiled
toolchains. I don't know whether that played a part in Zach's decision
to host his own binary toolchains.
In any case, now that we have the tooling, producing more
toolchains of the sort is mostly a question of machine time. So there's
not much human work involved and not much wheel reinvention - you can
consider it as different takes on the same idea, and pick and choose
which one suits you best. More user choice ! :)
About lh-bootstrap and mkroot: those two projects do not have the
same goals. lh-bootstrap's goal is to make an s6-based minimal system,
mostly as a proof of concept for s6 as an init system and s6-rc as a
service manager. mkroot's is to provide a small "standard" system with
some utilities - not quite as bare-bones as lh-bootstrap, but
without supervision or a service manager. Those are close, but not
exactly similar, projects.
I have asked landley before whether he shared my interests for weird
things such as using less resources than the shell, or supervision
systems. His answer was a resounding and unambiguous "no". His interests
are focused on making a GPL-free platform suitable for systems such
as j2 and Android, and he cares more about porting the existing flawed
tools that people know than about rewriting the world in a better way.
Which is totally fair.
landley is not an easy man to work with. Neither am I. I consider
myself a better coder and integrator than he is; he probably has the
opposite opinion. I value very much the work he's doing; I also
acknowledge, and have thanked him multiple times for, all he has taught
me about Linux interfaces such as initramfs/initrd, sysfs/devtmpfs,
pivot_root/change_root - the documentation he wrote in the Linux kernel
is simply invaluable. But if we are not 100% aligned on a project's
goals, I very much doubt working together would be productive.
Let him do what he wants to do, let me do what I want to do, and pick
your favorite parts. This will work a lot better for everyone. :)
--
Laurent
Received on Mon Sep 03 2018 - 20:47:32 UTC