From 922ed5dd6c379e345b8d64f467cfb6a60e4f1af1 Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Tue, 4 Mar 2025 14:12:53 -0600 Subject: [PATCH] Minor roadmap refresh. --- www/roadmap.html | 95 ++++++++++++++++++++++++++++++------------------ 1 file changed, 59 insertions(+), 36 deletions(-) diff --git a/www/roadmap.html b/www/roadmap.html index a3494976..32efac86 100644 --- a/www/roadmap.html +++ b/www/roadmap.html @@ -6,9 +6,13 @@ - +

Introduction (Goals and use cases)

We have several potential use cases for a new set of command line @@ -37,6 +41,7 @@ commplation.

  • POSIX-2024 (also known as SUSv5)
  • the Linux Standard Base version 4.1 (frozen, becoming obsolete)
  • the official Linux man pages
    • +
  • IETF Request For Comments> But each of those include commands we've decided not implement and/or exclude commands or features we have, nor do they always entirely match reality.

    @@ -68,7 +73,8 @@ command list and progress towards implementing it.

    Use case: standards compliance.

    -

    POSIX-2024/SUSv5

    + +

    POSIX-2024/SUSv5

    The best standards describe reality rather than attempting to impose a new one. I.E. "A good standard should document, not legislate." Standards which document existing reality tend to be approved by @@ -97,8 +103,8 @@ in 2024.

    Why not just use posix for everything?

    Unfortunately, Posix describes an incomplete subset of reality, because -it was designed to. Those first few pre-SUSv2 Posix standards that remain -unavailable on the Open Group's wesite were produced during a period known as +it was designed to. Those first few pre-SUSv2 Posix standards (which remain +unavailable on the Open Group's wesite) were produced during a period known as "the unix wars" when AT&T's prioprietary control over the original UNIX(tm) intellectual property sucked the old UNIX(tm) ecosystem dry until Linux and FreeBSD swept away @@ -188,10 +194,10 @@ who xargs zcat -

    Linux Standard Base

    +

    Linux Standard Base

    One attempt to supplement POSIX towards an actual usable system was the -Linux Standard Base. Unfortunately, the quality of this "standard" is +Linux Standard Base. Unfortunately, the quality of this "standard" was fairly low, largely due to the Free Standards Group that maintained it being consumed by the Linux Foundation in 2007.

    @@ -202,33 +208,32 @@ the Linux Standard Base's failure mode was different. They responded to pressure by including anything their members paid 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, Alpine...) 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 +Gentoo, Android, Alpine...) don't use it and never will. This means anything in LSB was +at best a suggestion: arbitrary portions of this standard were widely ignored.

    The community perception -seems to be that the Linux Standard Base is -the best standard money can buy: the Linux Foundation is supported by -financial donations from large companies and the LSB -represents the interests -of those donors regardless of technical merit. (The Linux Foundation, which -maintains the LSB, is NOT a 501c3. It's a 501c6, the +became that the Linux Standard Base was the best standard money can buy: the +Linux Foundation was supported by financial donations from large companies and +LSB represented +the interests of those donors regardless of technical merit. (The Linux +Foundation, which maintained the LSB, is NOT a 501c3. It's a 501c6, the same kind of legal entity as the Tobacco Institute and Microsoft's old "Don't Copy That Floppy" campaign.) Debian officially washed its hands of LSB by refusing to adopt release 5.0 in 2015, and no longer even pretends to support -it (which affects Debian derivatives like Ubuntu and Knoppix). Toybox has -stayed on 4.1 for similar reasons.

    +it (which affects Debian derivatives like Ubuntu and Knoppix). +Toybox has stayed on 4.1 for similar reasons.

    -

    That said, Posix by itself isn't enough, and this is the next most +

    That said, Posix by itself isn't enough, and this was the next most comprehensive standards effort for Linux so far, so we salvage what we can. A lot of historical effort went into producing the standard before the Linux Foundation took over.

    Analysis

    -

    LSB 4.1 specifies a list of command line +

    LSB 4.1 specified a list of command line utilities:

    @@ -252,7 +257,7 @@ interested in the set of LSB tools that aren't mentioned in posix.

    Of these, gettext and msgfmt are internationalization, install_initd and remove_initd weren't present even in Ubuntu 10.04, lpr is out of scope, -lsb_release just reports information in /etc/os-release, and sendmail's +lsb_release just reports information in /etc/os-release, and sendmail turned into a pile of cryptographic verification and DNS shenanigans due to spammers.

    @@ -267,10 +272,12 @@ su sync tar umount useradd userdel usermod zcat
    -

    IETF RFCs and Man Pages

    +

    IETF RFCs and Man Pages

    +

    IETF RFCs and Man Pages

    They're very nice, but there's thousands of them. The signal to noise -ratio here is terrible.

    +ratio here is terrible, and neither is a good indicator of whether a linux +system should or should not include a given command in its basic command set.

    Discussion of standards wouldn't be complete without the Internet Engineering Task Force's "Request For Comments" collection and Michael Kerrisk's @@ -280,16 +287,31 @@ 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.

    -

    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.

    - -

    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. 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 long and complicated or +

    Unix's first production deployment in 1970 was a typesetting system for +AT&T's internal patent and trademark licensing office (providing the +budget for Bell Labs' engineers to port their prototype system from a +surplus PDP-7 fished out of an attic to a newly purchased PDP-11), and +has retained a robust documentation tradition ever since, albeit still +written in the old "troff" typesetting language designed to control 1970's +daisy wheel printers, and in a terse style intended to save both memory +and paper. Still: every command in a descendant of unix should have an +entry in the unix instruction manual, with section 1 (ala "man 1 ls") listing +commands available to normal users and section 8 ("man 8 mount") listing +system administration commands for use by the root account. Run "man -k ." +to see every manual page currently installed onthe system.

    + +

    The modern Linux man pages project has loosened up a bitwebsite includes commands from git, yum, perf, postgres, +flatpack... It's useful for examining the features of a command you've +already decided to include, but useless for deciding _what_ to include.

    + +

    The RFCs are mostly about protocols and file formats, not commands. +The documents are numbered based on the order they were received, with +no real attempt at coherently indexing the result. +The noise level is also extremely high: there's thousands of RFCs, many +describing a proposed idea that never took off, and most of the rest are +extensions to or replacements for earlier RFCs. Less than 1% of the resulting +documents are currently relevant to toybox. As with man pages they can be +long and complicated or terse and impenetrable, have developed a certain amount of bureaucracy over the years, and often the easiest way to understand what they document is to find an earlier version to read first. @@ -675,15 +697,16 @@ shutdown fdisk getty halt ifconfig init mkswap reboot route swapon swapoff -

    +

    buildroot:

    If a toybox-based development environment is to support running buildroot under it, the mandatory packages section of the buildroot manual lists:

    -

    -which sed make bash patch gzip bzip2 tar cpio unzip rsync file bc wget + +which sed make diff bash patch gzip bzip2 tar cpio unzip rsync file bc find wget +

    (It also lists binutils gcc g++ perl python, and for debian it wants @@ -695,7 +718,7 @@ breaks otherwise.)

    with a prefix of "". If you try, and chop out the test for a blank prefix, it dies trying to run "/usr/bin/-gcc". In theory you can modify any open source project to do anything if you rewrite enough of it, but buildroot's developers -explicitly do not support this usage model.

    +explicitly do not support this usage model.

    klibc:

    -- 2.39.5