- Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathroadmap.html
1442 lines (1221 loc) · 67.7 KB
/
roadmap.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html><head><title>toybox roadmap</title>
<!--#include file="header.html" -->
<title>Toybox Roadmap</title>
<h2>Roadmap sections</h2>
<ul>
<li><ahref=#goals>Introduction</a></li>
<li><ahref=#susv4>POSIX-2008/SUSv4</a></li>
<li><ahref=#sigh>Linux "Standard" Base</a></li>
<li><ahref=#rfc>IETF RFCs and Man Pages</a></li>
<li><ahref=#dev_env>Development Environment</a></li>
<li><ahref=#android>Android Toolbox</a></li>
<li><ahref=#aosp>Building AOSP</a></li>
<li><ahref=#tizen>Tizen Core</a></li>
<li><ahref=#yocto>Yocto</a></li>
<li><ahref=#fhs>Filesystem Hierachy Standard</a></li>
<li><ahref=#buildroot>buildroot</a></li>
<li>Miscelaneous: <ahref=#klibc>klibc</a>, <ahref=#glibc>glibc</a>,
<ahref=#sash>sash</a>, <ahref=#sbase>sbase</a>,
<ahref=#uclinux>uclinux</a>...</li>
<li><ahref=#packages>Other Packages</a></li>
</ul>
<aname="goals" />
<h2>Introduction (Goals and use cases)</h2>
<p>We have several potential use cases for a new set of command line
utilities, and are using those to determine which commands to implement
for Toybox's 1.0 release. Most of these have their own section in the
<ahref=status.html>status page</a>, showing current progress towards
commplation.</p>
<p>The most interesting publicly available standards are A) POSIX-2008 (also
known as SUSv4), B) the Linux Standard Base version 4.1, and C) the official
<ahref=https://www.kernel.org/doc/man-pages/>Linux man pages</a>.
But they include commands we've decided not implement, exclude
commands or features we have, and don't always entirely match reality.</p>
<p>The most thorough real world test (other than a large interactive
userbase) is using toybox as the command line in a build system such as
<ahref=https://landley.net/aboriginal/about.html>Aboriginal
Linux</a>, having it rebuild itself from source code, and using the result
to <ahref=https://github.com/landley/control-images>build Linux From Scratch</a>.
The current "minimal native development system" goal is to use
<ahref=faq.html#mkroot>mkroot</a>
plus <ahref=faq.html#cross>musl-cross-make</a> to hermetically build
<ahref=https://source.android.com>AOSP</a>.</p>
<p>We've also checked what commands were provided by similar projects
(klibc, sash, sbase, embutils,
nash, and beastiebox), looked at various vendor configurations of busybox,
and collected end user requests.</p>
<p>Finally, we'd like to provide a good replacement for the Bash shell,
which was the first program Linux ever ran and remains the standard shell
of Linux (no matter what Ubuntu says). This doesn't necessarily mean including
every last Bash 5.x feature, but does involve {various,features} <(beyond)
posix.</p>
<p>See the <ahref=status.html>status page</a> for the categorized command list
and progress towards implementing it. There's also a
<ahref=todo.html>historical todo list</a> from the project's 2011 relaunch.</p>
<hr/>
<aname="standards">
<h2>Use case: standards compliance.</h2>
<h3><aname=susv4/><ahref="#susv4">POSIX-2008/SUSv4</a></h3>
<p>The best standards describe reality rather than attempting to impose a
new one. A good standard should document, not legislate.
Standards which document existing reality tend to be approved by
more than one standards body, such ANSI and ISO both approving <ahref=https://landley.net/c99-draft.html>C99</a>. That's why IEEE 1003.1-2008,
the Single Unix Specification version 4, and the Open Group Base Specification
edition 7 are all the same standard from three sources, but most people just
call it "posix" (portable operating system derived from unix).
It's available <ahref=https://pubs.opengroup.org/onlinepubs/9699919799>online in full</a>, and may be downloaded as a tarball.
Previous versions (<ahref=https://pubs.opengroup.org/onlinepubs/009695399/>SUSv3</a> and
<ahref=https://pubs.opengroup.org/onlinepubs/7990989775/>SUSv2</a>)
are also available.
(Note:
<ahref=https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/>Posix
2008</a> was reissued in 2013 and 2018, the first was minor wordsmithing
with no behavioral changes, the second was to renew a ten year timeout
to still be considered a "current standard" by some government regulations.
It's still posix-2008/SUSv4/issue 7.)</p>
<h3>Why not just use posix for everything?</h3>
<p>Unfortunately, Posix describes an incomplete subset of reality, because
it was designed to. It started with proprietary unix vendors collaborating to
describe the functionality their fragmented APIs could agree on, which was then
incorporated into <ahref=https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-2-1993.pdf>US federal procurement standards</a>
as a <ahref=https://www.youtube.com/watch?v=nwrTTXOg-KI>compliance requirement</a>
for things like navy contracts, giving large corporations
like IBM and Microsoft millions of dollars of incentive
to punch holes in the standard big enough to drive
<ahref=https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem>Windows NT</a> and
<ahref=http://www.naspa.net/magazine/1996/May/T9605006.PDF>OS/360</a> through.
When open source projects like Linux started developing on the internet
(enabled by the 1993 relaxation of the National Science Foundation's
"Acceptable Use Policy" allowing everyone to connect to the internet,
previously restricted to approved government/military/university organizations),
Posix <ahref=http://www.opengroup.org/testing/fips/policy_info.html>ignored
the upstarts</a> and Linux eventually
<ahref=https://www.linuxjournal.com/article/3417>returned the favor</a>,
leaving Posix behind.</p>
<p>The result is a "standard" that lacks any mention of commands like
"init" or "mount" required to actually boot a system.
It describes logname but not login. It provides ipcrm
and ipcs, but not ipcmk, so you can use System V IPC resources but not create
them. And widely used real-world commands such as tar and cpio (the basis
of initramfs and RPM) which were present in earlier
versions of the standard have been removed, while obsolete commands like
cksum, compress, sccs and uucp remain with no mention of modern counterparts
like crc32/sha1sum, gzip/xz, svn/git or scp/rsync. Meanwhile posix' description
of the commands
themselves are missing dozens of features and specify silly things like ebcdic
support in dd or that wc should use %d (not %lld) for byte counts. So
we have to extensively filter posix to get a useful set of recommendations.</p>
<h3>Analysis</h3>
<p>Starting with the
<ahref="http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/idx/utilities.html">full "utilities" list</a>,
we first remove generally obsolete
commands (compress ed ex pr uncompress uccp uustat uux), commands for the
pre-CVS "SCCS" source control system (admin delta get prs rmdel sact sccs unget
val what), fortran support (asa fort77), and batch processing support (batch
qalter qdel qhold qmove qmsg qrerun qrls qselect qsig qstat qsub).</p>
<p>Some commands are for a compiler toolchain (ar c99 cflow ctags cxref gencat
iconv lex m4 make nm strings strip tsort yacc) which is outside of toybox's
mandate and should be supplied externally. (Again, some of these may be
revisited later, but not for toybox 1.0.)</p>
<p>Some commands are part of a command shell, and can't be implemented as
separate executables (alias bg cd command fc fg getopts hash jobs kill read
type ulimit umask unalias wait). These may be revisited as part of the built-in
toybox shell, but are not exported into $PATH via symlinks. (If you fork a
child process and have it "cd" then exit, you've accomplished nothing.)
Again, what posix provides is incomplete: a shell also needs exit, if, while,
for, case, export, set, unset, trap, exec... (And for bash compatibility
function, source, declare...)</p>
<p>A few other commands are judgement calls, providing command-line
internationalization support (iconv locale localedef), System V inter-process
communication (ipcrm ipcs), and cross-tty communication from the minicomputer
days (talk mesg write). The "pax" utility <ahref=https://slashdot.org/story/06/09/04/1335226/debian-kicks-jrg-schilling>failed</a> to replace tar,
"mailx" is
a command line email client, and "lp" submits files for printing to... what
exactly? (cups?) The standard defines crontab but not crond. What is
pathchk supposed to be portable _to_? (Linux accepts 255 byte path components
with any char except NUL or / and no max length on the total path, and
<ahref=https://yarchive.net/comp/linux/utf8.html>EXPLICITLY</a>
doesn't care if it's an invalid utf8 sequence.)</p>
<p>Removing all of that leaves the following commands, which toybox should
implement:</p>
<blockquote><b>
<spanid=posix>
at awk basename bc cal cat chgrp chmod chown cksum cmp comm cp
csplit cut date dd df diff dirname du echo env expand expr false file find
fold fuser getconf grep head id join kill link ln logger logname ls man
mkdir mkfifo more mv newgrp nice nl nohup od paste patch printf ps
pwd renice rm rmdir sed sh sleep sort split stty tabs tail tee test time
touch tput tr true tty uname unexpand uniq unlink uudecode uuencode vi wc
who xargs zcat
</span>
</b></blockquote>
<h3><aname=sigh/><ahref="#sigh">Linux Standard Base</a></h3>
<p>One attempt to supplement POSIX towards an actual usable system was the
Linux Standard Base. Unfortunately, the quality of this "standard" is
fairly low, largely due to the Free Standards Group that maintained it
being consumed by <ahref=https://landley.net/notes-2010.html#18-07-2010>the Linux Foundation</a> in 2007.</p>
<p>Where POSIX allowed its standards process to be compromised
by leaving things out (but what
they DID standardize tends to be respected, if sometimes obsolete),
the Linux Standard Base's failure mode is different. They respond to
pressure by including anything their members pay them enough to promote,
such as allowing Red Hat to push
RPM into the standard even though all sorts of distros (Debian, Slackware, Arch,
Gentoo, Android) don't use it and never will. This means anything in the LSB is
at best a suggestion: arbitrary portions of this standard are widely
ignored.</p>
<p>The <ahref=https://mjg59.dreamwidth.org/39546.html>community perception</a>
seems to be that the Linux Standard Base is
the best standard money can buy, I.E. the Linux Foundation is supported by
financial donations from large companies and the LSB
<ahref=https://www.softwarefreedom.org/blog/2016/apr/11/lf/>represents the interests
of those donors</a> regardless of technical merit. (The Linux Foundation, which
maintains the LSB, isn't a 501c3. It's a 501c6, the
same kind of legal entity as the Tobacco Institute and
<ahref=https://lwn.net/Articles/706585/>Microsoft's</a>
old "<ahref=https://en.wikipedia.org/wiki/Don%27t_Copy_That_Floppy>Don't Copy That Floppy</a>" program.) Debian officially
<ahref=http://lwn.net/Articles/658809>washed its hands of LSB</a> by
refusing to adopt release 5.0 in 2015, and no longer even pretends to support
it (which affect Debian derivatives like Ubuntu and Knoppix). Toybox has
stayed on 4.1 for similar reasons: a lot of historical effort went into
producing the standard before the Linux Foundation took over.</p>
<p>That said, Posix by itself isn't enough, and this is the next most
comprehensive standards effort for Linux so far, so we salvage what we can.</p>
<h3>Analysis</h3>
<p>The LSB specifies a <ahref=http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/cmdbehav.html>list of command line
utilities</a>:</p>
<blockquote><b>
ar at awk batch bc chfn chsh col cpio crontab df dmesg du echo egrep
fgrep file fuser gettext grep groupadd groupdel groupmod groups
gunzip gzip hostname install install_initd ipcrm ipcs killall lpr ls
lsb_release m4 md5sum mknod mktemp more mount msgfmt newgrp od passwd
patch pidof remove_initd renice sed sendmail seq sh shutdown su sync
tar umount useradd userdel usermod xargs zcat
</b></blockquote>
<p>Where posix specifies one of those commands, LSB's deltas tend to be
accomodations for broken tool versions which aren't up to date with the
standard yet. (See <ahref=http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/more.html>more</a> and <ahref=http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/xargs.html>xargs</a>
for examples.)</p>
<p>Since we've already committed to using our own judgement to skip bits of
POSIX, and LSB's "judgement" in this regard is purely bug workarounds to declare
various legacy tool implementations "compliant", this means we're mostly
interested in the set of LSB tools that aren't mentioned in posix.</p>
<p>Of these, gettext and msgfmt are internationalization, install_initd and
remove_initd weren't present in Ubuntu 10.04, lpr is out of scope,
lsb_release just reports information in /etc/os-release, and sendmail's
turned into a pile of cryptographic verification and DNS shenanigans due
to spammers.</p>
<p>This leaves:</p>
<blockquote><b>
<spanid=lsb>
chfn chsh dmesg egrep fgrep groupadd groupdel groupmod groups
gunzip gzip hostname install killall md5sum
mknod mktemp mount passwd pidof seq shutdown
su sync tar umount useradd userdel usermod zcat
</span>
</b></blockquote>
<h3><aname=rfc/><ahref="#rfc">IETF RFCs and Man Pages</a></h3>
<p>They're very nice, but there's thousands of them.</p>
<p>Discussion of standards wouldn't be complete without the Internet
Engineering Task Force's "<ahref=https://www.rfc-editor.org/in-notes/rfc-index.txt>Request For Comments</a>" collection and Michael Kerrisk's
<ahref=https://www.kernel.org/doc/man-pages/>Linux man-pages project</a>.
Except these aren't standards, they're collections of documentation with
low barriers to inclusion. They're not saying "you should support
X", they're saying "if you do, here's how".
Thus neither really helps us select which commands to include.</p>
<p>The man pages website includes the commands in git, yum, perf, postgres,
flatpack... Great for examining the features of a command you've
already decided to include, useless for deciding _what_ to include.</p>
<p>The RFCs are more about protocols than commands. The noise level is
extremely high: there's thousands of RFCs, many describing a proposed idea
that never took off, and less than 1% of the resulting documents are
currently relevant to toybox. And the documents are numbered based on the
order they were received, with no real attempt at coherently indexing
the result. As with man pages they can be <ahref=https://www.ietf.org/rfc/rfc0610.txt>long and complicated</a> or
<ahref=https://www.ietf.org/rfc/rfc1951.txt>terse and impenetrable</a>,
have developed a certain amount of <ahref=https://www.ietf.org/rfc/rfc8179.txt>bureaucracy</a> over the years, and often the easiest way to understand what
they <ahref=https://www.ietf.org/rfc/rfc4330.txt>document</a> is to find an <ahref=https://www.ietf.org/rfc/rfc1769.txt>earlier version</a> to read first.</p>
<p>That said, RFC documents can be useful (especially for networking protocols)
and the four URL templates the recommended starting files
for new commands (toys/example/skeleton.c or toys/example/hello.c depending on how much
plumbing you want to start with) provide point to posix, lsb, man, and
rfc pages.</p>
<hr/>
<aname="dev_env">
<h2><ahref="#dev_env">Use case: provide a self-hosting development environment</a></h2>
<p>The following commands were enough to build the <ahref=http://landley.net/aboriginal/about.html>Aboriginal Linux</a> development
environment, boot it to a shell prompt, and build <ahref=http://www.linuxfromscratch.org/lfs/view/6.8/>Linux From Scratch 6.8</a> under it.</p>
<blockquote><b>
<spanid=development>
bzcat cat cp dirname echo env patch rmdir sha1sum sleep sort sync
true uname wc which yes zcat
awk basename chmod chown cmp cut date dd diff
egrep expr fdisk find grep gzip head hostname id install ln ls
mkdir mktemp mv od readlink rm sed sh tail tar touch tr uniq
wget whoami xargs chgrp comm gunzip less logname split
tee test time bunzip2 chgrp chroot comm cpio dmesg
dnsdomainname ftpd ftpget ftpput gunzip ifconfig init less
logname losetup mdev mount mountpoint nc pgrep pkill
pwd route split stat switch_root tac umount vi
resize2fs tune2fs fsck.ext2 genext2fs mke2fs xzcat
</span>
</b></blockquote>
<p>This use case includes running init scripts and other shell scripts, running
configure, make, and install in each package, and providing basic command line
facilities such as a text editor. (It does not include a compiler toolchain or
C library, those are outside the scope of the toybox project, although mkroot
has a <ahref=https://landley.net/code/qcc>potentialy follow-up project</a>.
For now we use distro toolchains,
<ahref=https://github.com/richfelker/musl-cross-make>musl-cross-make</a>,
and the Android NDK for build testing.)
That build system also instaled bash 2.05b as #!/bin/sh and its scripts
required bash extensions not present in shells such as busybox ash.
To replace that toysh needs to supply several bash extensions _and_ work
when called under the name "bash".</p>
<p>The development methodology used a <ahref=http://landley.net/aboriginal/FAQ.html#debug_logging>command logging wrapper</a>
that intercepted each command called out of the $PATH and append the
command line to a log file, then <ahref=https://github.com/landley/aboriginal/blob/master/more/report-recorded-commands.sh>analyze</a> the result to create a
<ahref=https://landley.net/notes-2008.html#23-01-2008>list of commands</a>,
then <ahref=https://github.com/landley/aboriginal/blob/master/host-tools.sh>create a directory of symlinks</a> pointing to those commands out of the
host $PATH. Then the new implementation can replace these commands one
at a time, checking the results and the log output to spot any behavior
changes.</p>
<h3>Stages and moving targets</h3>
<p>This use case has two stages: 1) building a bootable system that can
rebuild itself from source, and 2) a build environment capable
of bootstrapping up to arbitrary complexity (as exemplified by building
Linux From Scratch and Beyond Linux From Scratch under the resulting
system). To accomplish just the first goal, the old build
still needs the following busybox commands for which toybox does not yet
supply adequate replacements:</p>
<blockquote><b>
awk dd diff expr fdisk ftpd gzip less route sh tr unxz vi wget xzcat
</b></blockquote>
<p>All of those except awk, ftpd, and less have partial implementations
in "pending".</p>
<p>In 2017 Aboriginal Linux development ended, replaced by the
<ahref=https://github.com/landley/mkroot>mkroot</a> project
designed to use an existing cross+native toolchain (such as
<ahref=https://github.com/richfelker/musl-cross-make>musl-cross-make</a>
or the Android NDK) instead of building its own. In 2019 the still-incomplete
mkroot was merged into toybox as the "make root" target. This is intended
as a simpler way of providing essentially the same build environment, and doesn't
significantly affect the rest of this analysis (although the "rebuild itself
from source" test now includes building musl-cross-make under either mkroot
or toybox's "make airlock" host environment).</p>
<p>Building Linux From Scratch is not the same as building the
<ahref=https://source.android.com>Android Open Source Project</a>,
but after toybox 1.0 we plan to try
<ahref=http://landley.net/aboriginal/about.html#hairball>modifying the AOSP build</a>
to reduce dependencies. (It's fairly likely we'll have to add at least
a read-only git utility so repo can download the build's source code,
but that's actually <ahref=https://www.youtube.com/watch?v=P7n6G2IL6eo>not
that hard</a>. We'll probably also need our own "make" at some point after
1.0, which is its own moving target thanks to cmake and ninja and so on.)
The ongoing Android <ahref=http://lists.landley.net/pipermail/toybox-landley.net/2018-January/009330.html>hermetic build</a> work is already advancing
this goal.</p>
<hr/>
<h2><aname=android/><ahref="#android">Use case: Replacing Android Toolbox</a></h2>
<p>Android has a policy against GPL in userspace, so even though BusyBox
predates Android by many years, they couldn't use it. Instead they grabbed
an old version of ash (later replaced by
<ahref="https://www.mirbsd.org/mksh.htm">mksh</a>)
and implemented their own command line utility set
called "toolbox" (which toybox has already mostly replaced).</p>
<p>Toolbox doesn't have its own repository, instead it's part of Android's
<ahref=https://android.googlesource.com/platform/system/core>system/core
git repository</a>. Android's Native Development Kit (their standalone
downloadable toolchain) has its own
<ahref=https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md>roadmap</a>, and each version has
<ahref=https://developer.android.com/ndk/downloads/revision_history>release
notes</a>.</p>
<h3>Toolbox commands:</h3>
<p>According to <ahref=https://android.googlesource.com/platform/system/core/+/master/toolbox/Android.bp>
system/core/toolbox/Android.bp</a> the toolbox directory builds the
following commands:</p>
<blockquote><b>
getevent getprop modprobe setprop start
</b></blockquote>
<p>getprop/setprop/start were in toybox and moved back because they're so
tied to non-public system interfaces. modprobe shares the implementation
used in init. getevent is a board bringup tool built with a python script
that pulls all the constants from the latest kernel headers.</p>
<h3>Other Android /system/bin commands</h3>
<p>Other than the toolbox links, the currently interesting
binaries in /system/bin are:</p>
<ul>
<li><b>arping</b> - ARP REQUEST tool (iputils)</li>
<li><b>blkid</b> - identify block devices (e2fsprogs)</li>
<li><b>e2fsck</b> - fsck for ext2/ext3/ext4 (e2fsprogs)</li>
<li><b>fsck.f2fs</b> - fsck for f2fs (f2fs-tools)</li>
<li><b>fsck_msdos</b> - fsck for FAT (BSD)</li>
<li><b>gzip</b> - compression/decompression tool (zlib)</li>
<li><b>ip</b> - network routing tool (iproute2)</li>
<li><b>iptables/ip6tables</b> - IPv4/IPv6 NAT admin (iptables)</li>
<li><b>iw</b> - wireless device config tool (iw)</li>
<li><b>logwrapper</b> - redirect stdio to android log (Android)</li>
<li><b>make_ext4fs</b> - make ext4 fs (Android)</li>
<li><b>make_f2fs</b> - make f2fs fs (f2fs-tools)</li>
<li><b>ping/ping6</b> - ICMP ECHO_REQUEST tool (iputils)</li>
<li><b>reboot</b> - reboot (Android)</li>
<li><b>resize2fs</b> - resize ext2/ext3/ext4 fs (e2fsprogs)</li>
<li><b>sh</b> - mksh (BSD)</li>
<li><b>ss</b> - socket statistics (iproute2)</li>
<li><b>tc</b> - traffic control (iproute2)</li>
<li><b>tracepath/tracepath6</b> - trace network path (iputils)</li>
<li><b>traceroute/traceroute6</b> - trace network route (iputils)</li>
</ul>
<p>The names in parentheses are the upstream source of the command.</p>
<h3>Analysis</h3>
<p>For reference, combining everything listed above that's still "fair game"
for toybox, we get:</p>
<blockquote><b>
arping blkid e2fsck dd fsck.f2fs fsck_msdos gzip ip iptables
ip6tables iw logwrapper make_ext4fs make_f2fs modpobe newfs_msdos ping ping6
reboot resize2fs sh ss tc tracepath tracepath6 traceroute traceroute6
</b></blockquote>
<p>We may eventually implement all of that, but for toybox 1.0 we need to
focus a bit. If Android has an acceptable external package, and the command
isn't needed for system bootstrapping, replacing the external package is
not a priority.</p>
<p>However, several commands toybox plans to implement anyway could potentially
replace existing Android versions, so we should take into account Android's use
cases when doing so. This includes:</p>
<blockquote><b>
<spanid=toolbox>
dd getevent gzip modprobe newfs_msdos sh
</span>
</b></blockquote>
<p>Update: <ahref=https://android.googlesource.com/platform/system/core/+/master/system/core/Android.bp>
external/toybox/Android.bp</a> has symlinks for the following toys out
of "pending". (The toybox modprobe is also built for the device, but
it isn't actually used and is only there for sanity checking against
the libmodprobe-based implementation.) These should be a priority for
cleanup:</p>
<blockquote><b>
bc dd diff expr getfattr lsof more stty tr traceroute
</b></blockquote>
<p>Android wishlist:</p>
<blockquote><b>
mtools genvfatfs mke2fs gene2fs
</b></blockquote>
<hr/>
<h2><aname=aosp/><ahref="#aosp">Use case: Building AOSP</a></h2>
<p>The list of external tools used to build AOSP was
<ahref="https://android.googlesource.com/platform/build/soong/+/master/ui/build/paths/config.go">here</a>,
but as they're switched over to toybox they disappear and reappear
<ahref="https://android.googlesource.com/platform/prebuilts/build-tools/+/refs/heads/master/path/linux-x86/">here</a>.</p>
<blockquote><b>
awk basename bash bc bzip2 cat chmod cmp comm cp cut date dd diff dirname du
echo egrep env expr find fuser getconf getopt git grep gzip head hexdump
hostname id jar java javap ln ls lsof m4 make md5sum mkdir mktemp mv od openssl
paste patch pgrep pkill ps pstree pwd python python2.7 python3 readlink
realpath rm rmdir rsync sed setsid sh sha1sum sha256sum sha512sum
sleep sort stat tar tail tee todos touch tr true uname uniq unix2dos unzip
wc which whoami xargs xxd xz zip zipinfo
</b></blockquote>
<p>The following are already in the tree and will be used directly:</p>
<blockquote><b>
awk bzip2 jar java javap m4 make python python2.7 python3 xz
</b></blockquote>
<p>Subtracting what's already in toybox (including the following toybox toys
that are still in pending: <code>bc dd diff expr gzip lsof tar tr</code>),
that leaves:</p>
<blockquote><b>
bash fuser getopt git hexdump openssl pstree rsync sh todos unzip zip zipinfo
</b></blockquote>
<p>For AOSP, zip/zipinfo/unzip are likely to be libziparchive based. The
todos callers will use unix2dos instead if it's available. git/openssl
seem like they should just be brought in to the tree. rsync is used to
work around a Mac <code>cp -Rf</code> bug with broken symbolic links. That
leaves:</p>
<blockquote><b>
bash fuser getopt hexdump pstree
</b></blockquote>
<p>(Why are fuser and pstree used during the AOSP build? They're used for
diagnostics if something goes wrong. So it's really just bash, getopt,
and hexdump that are actually used to build.)</p>
<hr/>
<h2><aname=tizen/><ahref="#tizen">Use case: Tizen Core</a></h2>
<p>A side effect of the Linux Foundation following the money to the
exclusion of all else is they "support" their donors' myriad often
contradictory pet projects with elaborate announcements and press releases.
Long ago when Nokia's Maemo merged
with Intel's Moblin to form <ahref=https://www.linuxfoundation.org/press-release/linux-foundation-to-host-meego-project/>MeeGo</a>, there were believable <ahref=https://www.linuxfoundation.org/press-release/public-support-for-the-meego-project/>statements</a>
about unifying fragmented vendor efforts. Then MeeGo merged with
<ahref=http://en.wikipedia.org/wiki/LiMo_Foundation>LiMo</a> to
<ahref=notes-2012.html#16-05-2012>form Tizen</a>,
which became a Samsung-only project (that <ahref=https://www.androidheadlines.com/2021/05/samsung-tvs-continue-use-tizen-os.html>still ships</a>
inside <ahref=https://twitter.com/cstross/status/1453747613686288385>televisions</a>,
but was otherwise subsumed into <ahref=https://www.theverge.com/2021/5/18/22440483/samsung-smartwatch-google-wearos-tizen-watch>Android GO</a>).</p>
<p>Along the way, the Tizen project expressed a desire to eliminate GPLv3 software
from its core system, and in installing toybox as
<ahref=https://wiki.tizen.org/wiki/Toybox>part of this process</a>.</p>
<p>They had a fairly long list of new commands they wanted to see in toybox:</p>
<blockquote><b>
<spanid=tizen_cmd>
arch base64 users unexpand shred join csplit
hostid nproc runcon sha224sum sha256sum sha384sum sha512sum sha3sum mkfs.vfat fsck.vfat
dosfslabel uname pinky diff3 sdiff zcmp zdiff zegrep zfgrep zless zmore
</span>
</b></blockquote>
<p>In addition, they wanted to use several commands then in pending:</p>
<blockquote><b>
<spanid=tizen>
tar diff printf wget rsync fdisk vi less tr test stty fold expr dd
</span>
</b></blockquote>
<p>Also, tizen uses a different Linux Security Module called SMACK, so
many of the SELinux options ala ls -Z needed smack alternatives in an
if/else setup. (We added lib/lsm.h to abstract this.)</p>
<hr/>
<h2><aname=yocto/><ahref="#yocto">Use case: Yocto</a></h2>
<p>Another project the Linux Foundation is paid to appreciate is Yocto,
which was designed to fix the ongoing proprietary fragmentation problem
(now in Linux build systems instead of vendor unix forks) by being the
build system equivalent of a glue trap. While proclaiming that having the
"minimum level of standardization" contributes to a "strong ecosystem",
Yocto uses a "<ahref=https://www.yoctoproject.org/software-overview/layers/>layered</a>"
design where everybody who touches it is encouraged to add more and more layers
of metadata on top of what came before, until they wind up <ahref=https://github.com/varigit/variscite-bsp-platform>using repo</a> just to manage
the layers (let alone their contents). But -- and this is the
important bit -- all these dispirate forks are called "yocto" and built on
top of giant piles of code the Linux Foundation can take credit for
since they filed the serial numbers off OpenEmbedded.</p>
<p>Yocto's "core-image-minimal" target (only 3,106 build steps in the 3.3
release, which believe it or not is
<ahref=https://landley.net/notes-2019.html#06-02-2019>an improvement</a>) builds a busybox-based system with the following commands:</p>
<blockquote><b>
<spanid=yocto_cmd>
addgroup adduser ascii sh awk base32 basename blkid bunzip2 bzcat bzip2 cat
chattr chgrp chmod chown chroot chvt clear cmp cp cpio crc32 cut date dc dd
deallocvt delgroup deluser depmod df diff dirname dmesg dnsdomainname du
dumpkmap dumpleases echo egrep env expr false fbset fdisk fgrep find flock
free fsck fstrim fuser getopt getty grep groups gunzip gzip head hexdump
hostname hwclock id ifconfig ifdown ifup insmod ip kill killall klogd less
ln loadfont loadkmap logger logname logread losetup ls lsmod lzcat md5sum
mesg microcom mkdir mkfifo mknod mkswap mktemp modprobe more mount mountpoint
mv nc netstat nohup nproc nslookup od openvt patch pgrep pidof pivot_root
printf ps pwd rdate readlink realpath reboot renice reset resize rev rfkill
rm rmdir rmmod route run-parts sed seq setconsole setsid sh sha1sum sha256sum
shuf sleep sort start-stop-daemon stat strings stty sulogin swapoff swapon
switch_root sync sysctl syslogd tail tar tee telnet test tftp time top touch
tr true ts tty udhcpc udhcpd umount uname uniq unlink unzip uptime users
usleep vi watch wc wget which who whoami xargs xzcat yes zcat
</span>
</b></blockquote>
<aname="fhs" />
<hr/><ahref=fhs>Filesystem Hierachy Standard</a>
<h2>Filesystem Hierarchy Standard:</h2>
<p>Another standard taken over by the Linux Foundation. (At least the
links to this one didn't <ahref=http://lanana.org/>go 404</a> the
instant they took it over). Of historical interest due to what it
managed to achieve before they chased away the hobbyists maintaining it.
Only one version (3.0 in 2015) has been released since the Linux Foundation
absorbed the FHS. The previous release, Version 2.3, was released in 2004.
The Linux Foundation did not retain earlier versions. The contents of
the relevant sections appear identical between the two versions, the
Linux Foundation just added section numbers.</p>
<p><ahref=https://refspects.linuxfoundation.org/FHS_3.0/fhs-3.0.html>FHS 3.0</a>
section 3.4.2 requires commands to be in the /bin directory, and then 3.4.3
has an optional list,
and then 3.16.2 and 3.16.3 similarly cover /sbin. There are linux
specific sections in 6.1.2 and 6.1.6 but everything in them is obsolete.</p>
<p>The /bin options include csh but not bash, and ed but not vi.
The /sbin options have update which seems obsolete (filesystem
buffers haven't needed a userspace process to flush them for DECADES),
fastboot and fasthalt (reboot and halt have -nf), and
fsck.* and mkfs.* that don't actually specify any specific filesystems.
Removing that gives us:</p>
<blockquote><b>
<spanid=fhs_cmd>
cat chgrp chmod chown cp date dd df dmesg echo false hostname kill ln
login ls mkdir mknod more mount mv ps pwd rm rmdir sed sh stty su sync true
umount uname tar cpio gzip gunzip zcat netstat ping
shutdown fdisk getty halt ifconfig init mkswap reboot route swapon swapoff
</span>
</b></blockquote>
<hr/><aname=buildroot/>
<h2>buildroot:</h2>
<p>If a toybox-based development environment is to support running
buildroot under it, the <ahref=https://buildroot.org/downloads/manual/manual.html#requirement-mandatory>mandatory packages</a>
section of the buildroot manual lists:</p>
<blockquote><p><b>
which sed make bash patch gzip bzip2 tar cpio unzip rsync file bc wget
</b></p></blockquote>
<p>(It also lists binutils gcc g++ perl python, and for debian it wants
build-essential. And it wants file to be in /usr/bin because
<ahref=https://git.busybox.net/buildroot/tree/support/dependencies/dependencies.sh?h=2018.02.x#n84>libtool
breaks otherwise</a>.)</p>
<p>Oddly, buildroot can't NOT cross compile. Buildroot does not support a cross toolchain that lives in "/usr/bin"
with a prefix of "" (if you try, and chop out the test for a blank prefix,
it dies trying to run "/usr/bin/-gcc"). You can patch your way to
making it work if you try, but buildroot's developers explicitly do not
support this.</p>
<hr/><aname=klibc/>
<h2>klibc:</h2>
<p>Long ago some kernel developers came up with a project called
<ahref=http://en.wikipedia.org/wiki/Klibc>klibc</a>.
After a decade of development it still has no web page or HOWTO,
and nobody's quite sure if the license is BSD or GPL. It inexplicably
<ahref=http://www.infoworld.com/d/data-center/perl-isnt-going-anywhere-better-or-worse-211580>requires perl to build</a>, and seems like an ideal candidate for
replacement.</p>
<p>In addition to a C library less general-purpose than bionic (let alone
musl), klibc builds a random assortment of executables to run init scripts
with. There's no multiplexer command, these are individual executables:</p>
<blockquote><p><b>
cat chroot cpio dd dmesg false fixdep fstype gunzip gzip halt ipconfig kill
kinit ln losetup ls minips mkdir mkfifo mknodes
mksyntax mount mv nfsmount nuke pivot_root poweroff readlink reboot resume
run-init sh sha1hash sleep sync true umount uname zcat
</b></p></blockquote>
<p>To get that list, build klibc according to the instructions (I
<ahref=http://landley.net/notes-2013.html#23-01-2013>looked at</a> version
2.0.2 and did cd klibc-*; ln -s /output/of/kernel/make/headers_install
linux; make) then <b>echo $(for i in $(find . -type f); do file $i | grep -q
executable && basename $i; done | grep -v '[.]g$' | sort -u)</b> to find
executables, then eliminate the *.so files and *.shared duplicates.</p>
<p>Some of those binaries are build-time tools that don't get installed,
which removes mknodes, mksyntax, sha1hash, and fixdep from the list.
(And sha1hash is just an unpolished sha1sum anyway.)</p>
<p>The run-init command is more commonly called switch_root, nuke is just
"rm -rf -- $@", and minips is more commonly called "ps": I'm not doing aliases
for these oddball names.
The "kinit" command is another gratuitous rename, it's init running as PID 1.
The halt, poweroff, and reboot commands work with it.</p>
<p>Yet more stale forks of dash and gzip got sucked in here (see "dubious
license terms" above).
<p>In theory "blkid" or "file" handle fstype (and df for mounted filesystems),
but we could do fstype.</p>
<p>We should implement nfsmount, and probably smbmount
and p9mount even though this hasn't got one. The reason these aren't
in the base "mount" command is they interactively query login credentials.</p>
<p>The ipconfig command here has a built in dhcp client, so it's ifconfig
and dhcpcd and maybe some other stuff.</p>
<p>The resume command is... weird. It finds a swap partition and reads data
from it into a /proc file, something the kernel is capable of doing itself.
(Even though the klibc author
<ahref=http://www.zytor.com/pipermail/klibc/2006-June/001748.html>attempted
to remove</a> that capability from the kernel, current kernel/power/hibernate.c
still parses "resume=" on the command line). And yet various distros seem to
make use of klibc for this.
Given the history of swsusp/hibernate (and
<ahref=http://lwn.net/Articles/333007>TuxOnIce</a>
and <ahref=http://lwn.net/Articles/242107>kexec jump</a>...) I've lost track
of the current state of the art here. Ah, Documentation/power/userland-swsusp.txt
has the API docs, and <ahref=http://suspend.sf.net>here's a better
tool</a>...</p>
<p>This gives us a klibc command list:</p>
<blockquote><b>
<spanid=klibc_cmd>
cat chroot dmesg false kill ln losetup ls mkdir mkfifo readlink rm switch_root
sleep sync true uname
cpio dd ps mv pivot_root
mount nfsmount fstype umount
sh gunzip gzip zcat
kinit halt poweroff reboot
ipconfig
resume
</span>
</b></blockquote>
<hr/>
<aname=glibc/>
<h2>glibc</h2>
<p>Rather a lot of command line utilities come bundled with glibc:</p>
<blockquote><b>
catchsegv getconf getent iconv iconvconfig ldconfig ldd locale localedef
mtrace nscd rpcent rpcinfo tzselect zdump zic
</b></blockquote>
<p>Of those, musl libc only implements ldd. Of the rest:</p>
<ul>
<li><b>catchsegv</b> is a rudimentary debugger, probably out of scope for toybox.</li>
<li><b>iconv</b> has been <ahref="#susv4">previously discussed</a>.</li>
<li><b>iconvconfig</b> is only relevant if iconv is user-configurable; musl uses a
non-configurable iconv.</li>
<li><b>getconf</b> is a posix utility which displays several variables from
unistd.h; it probably belongs in the development toolchain.</li>
<li><b>getent</b> handles retrieving entries from passwd-style databases
(in a rather lame way) and is trivially replacable by grep.</li>
<li><b>locale</b> was discussed under <ahref=#susv4>posix</a>.
localedef compiles locale definitions, which musl currently does not use.</li>
<li><b>mtrace</b> is a perl script to use the malloc debugging that glibc has built-in;
this is not relevant for musl, and would necessarily vary with libc.</li>
<li><b>nscd</b> is a name service caching daemon, which is not yet relevant for musl.</li>
<li><b>rpcinfo</b> and <b>rpcent</b> are related to the Remote Procedure Calls
layer (an old sun technology used by some userspace NFS implementations),
which musl does not include and debian does not install by default.</li>
</ul>
<p>The remaining commands involve glibc's bundled timezone database,
which seems to be derived from the <ahref=http://www.iana.org/time-zones>IANA
timezone database</a>. Unless we want to maintain our own fork of the
standards body's database like glibc does, these are of no interest,
but for completeness:</p>
<ul>
<li><b>tzselect</b> outputs a TZ variable correponding to user input.
The documentation does not indicate how to use it in a script, but it seems
that Debian may have done so.</li>
<li><b>zdump</b> prints current time in each of several timezones, optionally
outputting a great deal of extra information about each timezone.</li>
<li><b>zic</b> converts a description of a timezone to a file in tz format.</li>
</ul>
<p>We implemented getconf, and I could see maybe arguing for ncsd.
The rest are not relevant to toybox.</p>
</b></blockquote>
<hr/>
<aname=sash/>
<h2>Stand-Alone Shell</h2>
<p>Wikipedia has <ahref=http://en.wikipedia.org/wiki/Stand-alone_shell>a good
summary of sash</a>, with links. The original Stand-Alone Shell project reached
a stopping point, and then <ahref=http://www.baiti.net/sash>"sash plus
patches"</a> extended it a bit further. The result is a megabyte executable
that provides 40 commands.</p>
<p>Sash is a shell with built-in commands. It doesn't have a multiplexer
command, meaning "sash ls -l" doesn't work (you have to go "sash -c 'ls -l'").
</p>
<p>The list of commands can be obtained via building it and doing
"echo help | ./sash | awk '{print $1}' | sed 's/^-//' | xargs echo", which
gives us:</p>
<blockquote><b>
alias aliasall ar cd chattr chgrp chmod chown cmp cp chroot dd echo ed exec
exit file find grep gunzip gzip help kill losetup losetup ln ls lsattr mkdir
mknod more mount mv pivot_root printenv prompt pwd quit rm rmdir setenv source
sum sync tar touch umask umount unalias where
</b></blockquote>
<p>Plus sh because it's a shell. A dozen or so commands can only sanely be
implemented as shell builtins (alias aliasall cd exec exit prompt quit setenv
source umask unalias), where is an alias for which, and at triage time toybox
already has chgrp, chmod, chown, cmp, cp, chroot, echo, help, kill, losetup,
ln, ls, mkdir, mknod, printenv, pwd, rm, rmdir, sync, and touch.</p>
<p>This leaves:</p>
<blockquote><b>
<spanid=sash_cmd>
ar chattr dd ed file find grep gunzip gzip lsattr more mount mv pivot_root
sh tar umount
</span>
</b></blockquote>
<p>(For once, this project doesn't include a fork of gzip, instead
it sucks in -lz from the host.)</p>
<hr/>
<aname=sbase/>
<h2>sbase:</h2>
<p>It's <ahref=http://git.suckless.org/sbase>on suckless</a> in
<ahref=http://git.suckless.org/ubase>two parts</a>. As of November 2015 it's
implemented the following (renaming "cron" to "crond" for
consistency, and yanking "sponge", "mesg", "pagesize", "respawn", and
"vtallow"):</p>
<blockquote><p>
<spanid=sbase_cmd>
basename cal cat chgrp chmod chown chroot cksum cmp comm cp crond cut date
dirname du echo env expand expr false find flock fold getconf grep head
hostname join kill link ln logger logname ls md5sum mkdir mkfifo mktemp mv
nice nl nohup od paste printenv printf pwd readlink renice rm rmdir sed seq
setsid sha1sum sha256sum sha512sum sleep sort split strings sync tail
tar tee test tftp time touch tr true tty uname unexpand uniq unlink uudecode
uuencode wc which xargs yes
</span>
</p></blockquote>
<p>and<p>
<blockquote><p>
<spanid=sbase_cmd>
chvt clear dd df dmesg eject fallocate free id login mknod mountpoint
passwd pidof ps stat su truncate unshare uptime watch
who
</span>
</p></blockquote>
<hr/>
<aname=nash/>
<h2>nash:</h2>
<p>Red Hat's nash was part of its "mkinitrd" package, replacement for a shell
and utilities on the boot floppy back in the 1990's (the same general idea
as BusyBox, developed independently). Red Hat discontinued nash development
in 2010, replacing it with dracut (which collects together existing packages,
including busybox).</p>
<p>I couldn't figure out how to beat source code out of
<ahref=http://pkgs.fedoraproject.org/git/mkinitrd>Fedora's current git</a>
repository. The last release version that used it was Fedora Core 12
which has <ahref=http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/source/SRPMS/mkinitrd-6.0.93-1.fc12.src.rpm>a source rpm</a>
that can be unwound with "rpm2cpio mkinitrd.src.rpm | cpio -i -d -H newc
--no-absolute-filenames" and in there is a mkinitrd-6.0.93.tar.bz2 which
has the source.</p>
<p>In addition to being a bit like a command shell, the nash man page lists the
following commands:</p>
<blockquote><p>
access echo find losetup mkdevices mkdir mknod mkdmnod mkrootdev mount
pivot_root readlink raidautorun setquiet showlabels sleep switchroot umount
</p></blockquote>
<p>Oddly, the only occurrence of the string pivot_root in the nash source code
is in the man page, the command isn't there. (It seems to have been removed
when the underscoreless switchroot went in.)</p>
<p>A more complete list seems to be the handlers[] array in nash.c:</p>
<blockquote><p>
access buildEnv cat cond cp daemonize dm echo exec exit find kernelopt
loadDrivers loadpolicy mkchardevs mkblktab mkblkdevs mkdir mkdmnod mknod
mkrootdev mount netname network null plymouth hotplug killplug losetup
ln ls raidautorun readlink resume resolveDevice rmparts setDeviceEnv
setquiet setuproot showelfinterp showlabels sleep stabilized status switchroot
umount waitdev
</p></blockquote>
<p>This list is nuts: "plymouth" is an alias for "null" which is basically
"true" (which thie above list doesn't have). Things like buildEnv and
loadDrivers are bespoke Red Hat behavior that might as well be hardwired in
to nash's main() without being called.</p>
<p>Instead of eliminating items
from the list with an explanation for each, I'm just going to cherry pick
a few: the device mapper (dm, raidautorun) is probably interesting,
hotplug (may be obsolete due to kernel changes that now load firmware
directly), and another "resume" ala klibc.</p>
<p>But mostly: I don't care about this one. And neither does Red Hat anymore.</p>
<p>Verdict: ignore</p>
<hr/>
<aname=beastiebox/>
<h2>Beastiebox</h2>
<p>Back in 2008, the BSD guys vented some busybox-envy
<ahref=http://beastiebox.sourceforge.net>on sourceforge</a>. Then stopped.
Their repository is still in CVS, hasn't been touched in years, it's a giant
hairball of existing code sucked together. (The web page says the author
is aware of crunchgen, but decided to do this by hand anyway. This is not
a collection of new code, it's a katamari of existing code rolled up in a
ball.)</p>
<p>Combining the set of commands listed on the web page with the set of
man pages in the source gives us:</P>
<blockquote><p>
[ cat chmod cp csh date df disklabel dmesg echo ex fdisk fsck fsck_ffs getty
halt hostname ifconfig init kill less lesskey ln login ls lv mksh more mount
mount_ffs mv pfctl ping poweroff ps reboot rm route sed sh stty sysctl tar test
traceroute umount vi wiconfig
</p></blockquote>
<p>Apparently lv is the missing link between ed and vi, copyright 1982-1997 (do
not want), ex is another obsolete vi mode, lesskey is "used to
specify a set of key bindings to be used with less", and csh is a shell they
sucked in (even though they have mksh?), [ is an alias for test. Several more bsd-isms that don't have Linux
equivalents (even in the ubuntu "install this package" search) are
disklabel, fsck_ffs, mount_ffs, and pfctl. And wiconfig is a
wavelan interface network card driver utility. Subtracting all that and the
commands toybox already implements at triage time, we get:</p>
<blockquote><p>
<spanid=beastiebox_cmd>
fdisk fsck getty halt ifconfig init kill less more mount mv ping poweroff
ps reboot route sed sh stty sysctl tar test traceroute umount vi
</span>
</p></blockquote>
<p>Not a hugely interesting list, but eh.</p>
<p>Verdict: ignore</p>
<hr/>
<aname=BsdBox/>
<h2>BsdBox</h2>
<p>Somebody decided to do a <ahref=https://wiki.freebsd.org/AdrianChadd/BsdBox>multicall binary for freebsd</a>.</p>
<p>They based it on crunchgen, a tool that glues existing programs together
into an archive and uses the name to execute the right one. It has no
simplification or code sharing benefits whatsoever, it's basically an
archiver that produces executables.</p>
<p>That's about where I stopped reading.</p>
<p>Verdict: ignore.</p>
<hr/>
<aname=slowaris/>
<h2>OpenSolaris Busybox</h2>
<p>Somebody <ahref=http://hub.opensolaris.org/bin/view/Project+busybox/>wrote
a wiki page</a> saying that Busybox for OpenSolaris would be a good idea.</p>
<p>The corresponding "files" tab is an auto-generated stub. The project never
even got as far as suggesting commands to include before Oracle discontinued
OpenSolaris.</p>
<p>Verdict: ignore.</p>
<hr/>
<aname=uclinux/>
<h2>uClinux</h2>
<p>Long ago a hardware developer named Jeff Dionne put together a
nommu Linux distribution, which involved rewriting a lot of command line
