[Toybox] project goals (was Re: sed -e '$a\')

[Andy Chu]

(answering these old mails in chronological order... I was working
heads down on the shell for 2 weeks, hence the silence)

On Sat, Mar 26, 2016 at 1:00 AM, Rob Landley <rob at landley.net> wrote:
>
>
> On 03/26/2016 01:36 AM, Andy Chu wrote:
>>> The problem to solve here is that Debian is currently broken when using
>>> toybox. That's a real problem that needs to be fixed, but there's more
>>> than one way to fix it. Debian introduced this bug within the past few
>>> years and maybe we can convince them to fix it on their end, that's one
>>> possible fix.
>>
>> What's the goal of toybox with respect to Debian?  I looked through
>> the design and roadmap pages and didn't see much about Debian
>> specifically.
>
> I take it you haven't read http://landley.net/aboriginal/about.html
> (specficially http://landley.net/aboriginal/about.html#hairball ).

I think there is a good point here, to have a universal foundation and
root of trust for different distros, although I wonder what work has
been done toward this goal?

I also wonder if the Debian maintainers would be on board with it.  It
seems like it would increase the maintainers workload to test with
both coreutils/etc. and toybox.  It's a pretty big moving target,
because they update their packages with every distro release.

I'm quite familiar with debootstrap, which is the big shell script
used to bootstrap a Debian/Ubuntu system.  You can use it to create
just the runtime environment, or also the build environment, which can
in turn rebuild the set of required or buildd packages.

It's like a big 4000 line shell script, and it doesn't seem like it is
very highly maintained (it's extremely inefficient, for one thing).
I guess the best thing you can say about it is that it does its job.

(FWIW I was building scientific computing programs in R with
containers from the ground up, with debootstrap, installing build
dependencies of R like Fortran, building R, installing R packages and
their runtime dependencies, and then installing R scripts on top... it
was quite involved and I have several thousand lines of shell scripts
that start with calling debootstrap to do this.)


> My original goal when I started all this nonsense circa 2002 or so was
> Knoppix. Linux From Scratch was over 100 megs but tomsrtbt was 1.7 megs,
> and I thought if I could save Knoppix 100 megs of space on its CD they
> could do WONDERS with it. The goalposts hae shifted a bit over the
> years, but oddly enough knoppix was debian based too. :)

I like the Aboriginal goal of being the simplest linux system capable
of rebuilding itself.  That is very crisp goal, and it has some nice
applications in terms of provenance and security.

My questions were more about the toybox goals.  The Debian goal seems
fuzzy, and a moving target.  Maybe there's something I'm not
understanding.

Also, I would consider stuff like "factor" and probably "rev" to be
cruft in toybox ... is there any evidence that people use that stuff?
I mean sure you can compile it out, but it just seems like a
distraction.

In other words, Aboriginal has a crisp goal, but toybox seems to have
10 different goals.  The goals here are not very crisp -- it seems
like a bunch of research on similar prior systems:

http://landley.net/toybox/roadmap.html


>> Are you only talking about build time, and excluding runtime?  i.e.
>> using toybox to bootstrap the builds of other distros?
>
> They're separate use cases. I want one to work and I want the other to
> be a reasonable option.

So you want to rebuild all distros with Aboriginal/toybox, and having
things work at runtime is a secondary goal?

But I suppose Android's runtime is the main goal for that OS?  Because
for now the runtime is going to be used way more than building... I
don't think there are many people with compilers installed on their
phones.

> The amount of in jokes in my code is actually reasonably correlated to
> the amount of sleep deprivation I was under at the time. (Like now, it's
> coming up on 3am here.) The "struct {forever[];} strawberry fields[];"
> nonsense in ps is a milder example. I edited most of that back _out_
> before checking it in. Also that song actually has very little in the
> way of lyrics so I COULDN'T pull a lot of variable names from it if I
> wanted to.

FWIW this was preventing me from understanding the sed code when I was
in there... :-/


> A) it sucked in python as an environmental dependency, and the move from
> python 2 to python 3 is a bit like the move from gpl 2 to gpl 3,
> fragmenting the community into incompatible warring camps and making a
> lot of old-timers walk. (It doesn't seem to be turning off newbies
> nearly as much, though, so maybe python will survive this if then NEVER
> do a python 4.0.)

Personally I think the best thing about Python 3 is that it froze
Python 2.7 in stone.  Python 2.7 will still be with us 20 years now,
and I'll probably still use it because it works great for a lot of
things (I haven't used Python 3 yet really).  It's like a de-facto
standard for Python, since PyPy and a half dozen other implementations
all target CPython 2.7.

> I was a longtime mercurial supporter, but bowed to the inevitable
> eventually.

Yeah same here.  I briefly worked on Google Code, which did Mercurial
hosting,  later added Git, and was recently shut down.  Git is
frustrating, but I get why it's popular -- it really is the best tool
for collaboration.  It enabled me to juggle a lot of patches I sent
you in parallel, something I never did with Mercurial.  I believe in
code reviews, and when you have code reviews you will have overlapping
patches which need to be updated asynchronously... that is not an easy
problem to solve, and Git is the best at it.

Andy