[Toybox] Toybox / mkroot init

[Roberto A. Foglietta]

On Thu, 19 Feb 2026 at 22:39, Rob Landley <rob at landley.net> wrote:
>
> On 2/17/26 05:21, Roberto A. Foglietta wrote:
> >>> I wish to know which was the license in original, BSD (as toybox), MIT? etc.
> >>
> >> 0BSD like the rest of toybox.
> >
> > Thanks for the kind answer.
>
> Conceptually this initramfs is just
> https://linuxfromscratch.org/hints/downloads/files/OLD/bsd-init.txt
> taken to its logical conclusion. (Over the course of 20+ years. And I'm
> pretty sure I started with an earlier, simpler version of that before it
> got "updated" to be more complex, but am not fishing for it...)

Correct, both the bare-minimal linux-system and gzcmd.sh are
conceptually the kernel and userland an initramfs pushed to their
logical conclusion with the current means and that means which are
evolved in terms in implementation since 1970-01-01 (Unix time start)
conceptually are similar. Innovation is not about invention but rather
integration and for integrating things for having novel practical
results there are two main factors that play (more than others) a
real-world experience about tech stuff and about "marketing" (why
people buy what they buy rather than something else, aka providing
solutions for real-world problems whatever people recognise they have
such a problems or not). Anyone saying "I have not invented anything
new" is also epistemological, not because s/he is cheap but
acknowledged of everything that preceded and all the people and
mistakes that were contributing to a subject or a tool.

>
> >>> - why 6.17 instead of 6.12 which is a Long Term Support ?
> >>
> >> Toybox releases generally use the kernel that was current at the time of
> >> the toybox release: toybox 0.8.13 came out October 14 and linux 6.18
> >> came out december 1, a month and a half later.
> >
> > Obviously, the same concept can apply when sticking to a LTS branch
> > but the micro version would be taken instead.
>
> No, the point is to catch upstream regressions in the kernel. I have a
> patch stack I apply
> (https://landley.net/bin/mkroot/0.8.13/linux-patches/) to beat basic
> functionality out of it for that set of architectures. (The README in
> the same directory as the tarballs mentions this, as do the release notes.)
>

Fine. It is a hidden value service fostering kernel bug fixing in
those conditions of working usually people and common distributions
did not intercept. The "price" you pay for this choice is that mkroot
isn't commercially appealing because it does not keep a "maintenance
first" policy. However, is a "commercial price" (or "economy did not
help, as you wrote in your bio) effect. Companies are paying what they
can see and immediately put into a balance sheet, trying to
systematically dump that R&D costs to someone else (and this "saving
R&D costs" has two shortcomings from the dev PoV they are on the
"fraud" line (or a "free meal" leverage as a general policy). In your
specific case, since toybox get into Android mainstream, I hope that
Google is paying for such R&D cost that generates hidden value for
many billion people who are using very cheap smartphone (because those
are spending €1.500, they are the same that are using a TACS mobile
phone when it would have costed like a nice used car).

> >>> Finally, one more question because I saw musl in a toybox:
> >>>
> >>> - What's about https://github.com/jart/cosmopolitan ?
> >>
> >> Are you trolling, or are you serious?
> >
> > I am serious, I did not have the time yet to investigate it.
>
> If you're not skeptical of a "one true standard" that hasn't been
> touched in 6 years...
>
> https://xkcd.com/927/
>
> It thinks "universal" means Linux plus mac and 3 bsd versions.

As much as POSIX allows to be "universal". For a simple principle but
sounding: fix boundaries on R&D because investigating everything means
investigating nothing. Fix those boundaries that are larger enough to
be NOT covered in full 100% (challenging) but in the most useful cases
(or ALSO some few cases that remained unserved or underserved). These
two logic of setting boundaries are fostering innovation (more
integration than invention) because they properly (aka functionally)
combine novelty with usefulness (hidden R&D value that matches
real-world overlooking problems).

For those in marketing this translates into: "there are people out
there who are underserved compared to what the dominating (or leading)
standard is offering today, these people are going to adopt or pay an
extra price over the commodity standard for being properly served". If
you ask to me what makes me having success in "life/work" is
understanding the "real-world hidden thus underserviced needs" and
what works against me, it is the same: the value that a single person
(or a small team) can extract from niches is enough for many people
predatory or over-defending behaviour (he is going to kill the market,
he is going to incorporate all of us). Free markets tend to adapt, and
the good news/bad news is that cheap people are cheap but also
available in millions and for the same reason a man or a team has
limits (also in became functionally rich/wealthy) there is no rational
reason to grow like a cancer (monopoly or "one universal standard")
rather than make selection among those can be "good clients of mine"
not because others are bad in absolute terms (few some are, anyway)
but because they can be better served by something/someone else.
Market, despite marketing people's wettest dreams, is not a flatland.


> It seems to add /bin/sh
> (and thus sourcing various profile scripts) into the invocation of every
> binary. (Presumably meaning your shell still has to be an actual binary
> and libc your kernel has a loader for?) If they really did write their
> own libc (I didn't dig that far) then lib/porability.{h,c} would
> probably double in size trying to make that work.

Shell script is a good approach for prototyping and exploring what
will be written later, apparently without a plan and without design,
but quickly and incremental in practical value, in fact (which is the
conceptual essence of SCRUM). For example, in uChaos project [1] the
main point is not shell-vs-elf but 1. paradigm shift about how we can
intend entropy (not pure white noise which is one of those measurable
KPI but as unpredictability over convenience from an attacker PoV) and
2. a deterministic system can show "true" chaotic behaviours (Lorenz
attractor, tre body problem, 7 billiard cushions, etc). None of these
two core points (or paradigms) violates physics or information theory,
the opposite, they leverage broader well-established knowledge out of
the current "market standards". Because sometimes standards are
"winning" because they are a "sell-machine" not because they are good
in absolute (or even relative) terms.

[1] https://github.com/robang74/working-in-progress/blob/main/random.txt

Therefore uChaos starts from "I am not willing to buy your marketing
standards and KPI" before even a single line of C-code or BASH script
has been written. Whoever is focusing on the current implementation
has almost a sounding 96% chance to end-up to wrong conclusions (and
thus being incapable of predicting the development and the final
results). Again innovation is not about "which tool using" but being
acknowledged of the abstract concepts behind the current market
technology to see the assumptions that have been made initially and
become a too strict market standard that creates underserved but
valuable niches. And nope, I am not marketing uChaos (yes, I am
f*cking doing that) here but just using it as an example to explain
those principles that otherwise might seem too abstract to catch or
accept.





>
> One of the big problems with https://pubmed.ncbi.nlm.nih.gov/41656802/
> is how its users make piles of work for other people. "You did not think
> of this because you did not think at all. You deployed something a
> vending machine glued together out of recycled parts which worked for
> you once, in a problem space you did not even attempt to understand, and
> the inevitable side effects are "externalities" which other people
> clearly should clean up for you because said vending machine tells you
> that you are a special person whose time is more valuable than theirs.
> (And that's not ME saying it,
> https://openai.com/index/sycophancy-in-gpt-4o/ was about doing a whole
> revision to try to make the "sycophancy" (their word!) less obvious
> and/or legally actionable.)
>

I agree but has a little to do with me, apart from seeking for a
better paid role or business. I am pretty aware about chatbot/AI
limitations and because of the HUGE gap between "people perception"
and "reality" (including confusing SLM -- which might not even good as
vending machine but used in a properly constrained terms can act as
agents -- with LLM / LRM entities that are "living" in the cloud and
they might seem "Olympus gods" to common people). Anyway, I have no
clue WHY this topic enters into this discussion, but I like it.

> "Explain to me why this is wrong" is making a request for my time and
> energy, to perform an analysis for someone who admits they haven't
> looked into it at all yet.
>
> > My fault
> > for having not done my homework before asking and just hoping for a
> > brief answer by a supposedly well-known human instead of querying an
> > AI chatbot. Sorry, for asking OT.
>
> It's not the off topic (if you'd asked about shipping bionic binaries or
> mac binaries or bsd binaries that would be relevant), it's that you
> didn't think through it yourself and wanted me to think for you.

Well, this is unfair. I think by myself but approaching you like I was
a beginner because I do not want that my pre-knowledge influences your
opinion and also puts you in condition to seek a simple answer. From
my point of view, and this is the HUGE gap between humans and AI, that
humans judge (you are incompetent, you did not do your homework
properly) while AI did not (by now but soon they will start to mock
humans even worse than H-H usually does). Roberto, you admitted that.
Nope, I answered you were judged in first place, before hands. In this
way of independent thinking (~Ubuntu: I am what I am whatever you all
are or think) that I have developed since a young boy also relay the
ultimate challenge of someone to "have my woman" because women got
crazy (crazy in love, or crazy mad, or both) for those male that have
a male behaviour but a female thinking. Unfortunately, the same woman
does not display the same behaviour with other men (unsurprisingly)
and this related in IT with the same myth (and gag) witches says: it
works on my PC (she is not X but Y with me) -- this is why we invented
dockers (which does not exist for personal relationship). So, it is
more an explanation because of "economy did help" rather than
something related to me and you catch it, are you trolling me? which
implicitly means: why are you asking this like you were dumb? Answer,
many people ending AI prompts with "explain it to me like I was a 10y
child" and most of them are experts in that field.

> I remember you from the busybox mailing list 20 years ago. The first
> commit in the busybox repo mentioning you (7b4aa6ffc6a4) is from 2006.
> You've got at least as much experience here as I do. You're asking me
> about a project you could have poked at yourself to see if it was load
> bearing.

Involving you, get your attention. Because a zelf can be intriguing
after the concept is explored and properly implemented. Which is a far
distant idea that this will become the universal standard of every
executable. Rather than why the hell snap on Ubuntu takes so much
footprint and ram?

>
> Yes, that project is vaguely familiar at first glance, I'm pretty sure
> it wandered by years ago and seemed a manifestation of dunning-kruger
> then too.
>
> There's a reason the web page was last updated 6 years ago and did not
> take the world by storm in the intervening time. What it's TRYING to do
> has an enormous attack surface, to the point it would have been big news
> if it HAD worked. Extraordinary claims require extraordinary evidence.
>
> (I'm trying not to be prejudiced by
> https://lists.busybox.net/pipermail/busybox/2026-February/091907.html
> and https://lists.busybox.net/pipermail/busybox/2026-January/091889.html
> and such, but... there's a reason I keep thinking about AI psychosis in
> this case.)
>
> >> I'm not interested either. (Either we have hardware entropy or we don't
> >> have hardware entropy. Userspace can't programmatically provide entropy.)
> >
> > I see your point, but hardware is free from interference?
>
> No, it's about understanding threat models.
>
> Do you know why Diaper Dan loves eating McDonalds? Because back when I
> lived in New Jersey (I moved out in 1995) he was laundering money for
> the Russian mob.

Sorry, I do not like McDonalds. And now you put me in position to say
if I dislike McFood or Russian Mobs. Hard to say which one killed more
people but in the long run, the first I guess.


> Since the russians love poisoning people (apparently Nalvany got done in
> by dart frog poison, which is just showboating), grabbing random
> commodity meals from an outlet that didn't know he was coming made that
> asshole feel safe back when he still had a temporal lobe.

Since McFood loves poisoning people... right, I agree we can terminate
the "WTF" part of this discussion here. Despite everything, I loved
this part more than the tech-one because here we find each other as
humans, not only as geeks.

>
> > Can be
> > protected and it is local. Unless the hardware itself is tampered or
> > remotely switchable. Which is not a theoretical hypothesis anymore,
> > unless very cheap and limited uCPU.
>
> If your hardware has been tampered with in a supply chain attack or evil
> maid situation, you've already lost.

Under-rating the fact that those attacks require (usually otherwise
too much exposure in plain sight) a specific alignment of few low
grade (5-7) vulnerabilities rather than a single 9.9 one. Some ways of
doing doesn't protect by general terms from supply chain attacks, but
disrupt alignment enough to need a tech guy for each instance of the
"novel" way of doing. It takes weeks or months of R&D for automatising
and including that "niche" of vulnerabilities-misaligned PoC to get
into main-stream and in the meantime evolution will reschedule the
cards again. In the wild, in the savanna, things work in this way
also: predators run faster than yesterday and gazelles learn how to
change their running suddenly. Only Willy the Coyotes never learn...
BIP BIP!


> > Anyway, just let me say: CPUs are hardware,
>
> See the j-core stuff in https://landley.net/resume.html going back to
> 2014? Or stuff like
> https://web.archive.org/web/20001109095700/http://www.fool.com/portfolios/rulemaker/2000/rulemaker000901.htm
> from basically a previous life.
>
> I am aware that CPUs are hardware, thanks.

Thanks for the confirmation, some people underestimated it. LOL.

>
> > thus they can be used for
> > entropy. Despite CPUs not being available as devices (in a proper
> > terms we can intend a /dev/tty) their working affect indirectly the
> > userland activity in particular because of scheduler. Thus, the
> > scheduler jitters are a hardware source of entropy that can be
> > collected also by an userland application.
>
> Which the linux kernel has done since... 1996 I think?

Collected is the WRONG keyword here, entropy in physics is created
doing work. The kernel WAITS to collect entropy and whatever
"collecting entropy" means, is WAIT the wrong assumption. Creates
chaos and harvesting (or enjoys it). Creating chaos in a systematic
and reliable manner by a deterministic hardware/SW might seem
absurd/hard to do, wait is easier, for sure. Therefore, since 1996 the
kernel waits for events instead of creating jitters. Nice, that is
exactly WHERE and WHAT was aiming to. Why does the kernel wait? When
"wait" in kernel terms is avoided doing work thus creating entropy?
Let me guess: because kernel has no entropy enough to init SSH and
thus "wait and polling" which is the reason because in trying a DOS
approach in shortening the SSH first connection time, I creates
activity in kernel that creates entropy and thus I win the 1st
connection sooner compared to quietly sit and wait that kernel ends to
wait that I end to wait...

Has the kernel worked since 1996 in that way? Thanks for the
confirmation. LOL x2.

>
> The kernel is providing those context switches for you. If the kernel is
> exploited, the idea that userspace using information provided from the
> kernel can keep you safe is basically the old hashing security argument
> (providing unknowable answers from known inputs). There used to be some
> conference videos from ~1985 about that. (Not HOPL II but filed next to
> the HOPL II tapes, years ago on VHS in a library I drove to back when I
> lived a more nomadtic lifestyle after my mother died and I inherited her
> station wagon...)

Communication with a system compromised would be a function, its
latencies are 1st grade derivative and jitters are 2nd grade
derivative. As long as the compromised system that it is ROCK DUMB not
smart as a human would, see a Tetris app pretending that user plays
tetris does what is supposed to do, while in a concealed why the app
does what the smart-as-human user is supposed to do without sharing
data and privacy away.

>
> > We can agree that we do not trust in userland,
>
> Who's "we", kemosabe?

Maybe (cit.)


> Rob

- Robert

>
> P.S. One of my proposed talks at ELC, since they're having it in
> Minneapolis this year, is "booting Linux under VHDL simulation" where we
> build a toolflow (well, nvc), build simulated VHDL hardware that sort of
> thinks it's an ECP5 FPGA with simulated spi flash (also VHDL, from some
> foundation) and simulated giant block of SRAM (C via
> https://www.nickg.me.uk/nvc/manual.html#VHPI) bolted on, build linux
> from source with a new device tree, and then do hardware bringup through
> our own ROM bootloader (also written in C, which we also compile during
> this, then the SOC build creates the rom using a trap-based ELF loader
> WRITTEN IN VHDL, Jeff is crazy) that reads a vmlinux from the flash and
> ELF loads it into the sram and calls its entry point, so it can boot up
> and spit messages out to emulated serial port and eventually a serial
> console shell prompt.

You should be paid more for writing such a long e-mail, trust me. ;-)

Best regards,
-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697