[TUHS] evolution of the cli

[A. P. Garcia via TUHS]

Arnold, your point about portability keeps echoing in my head.
I’ve been thinking that the right answer might be a plugin architecture
instead of a hard-wired Linux core — a stable vocabulary of objects (Task,
NetIf, Mount, etc.) with back-end modules that know how to populate those
objects for each OS.

That way Linux can pull from /proc and /sys, BSD from sysctl or kvm, macOS
from libproc, and so on. The interface stays constant; the provider changes.

I’m also leaning toward making those providers language-agnostic, maybe
using WASM modules, so anyone could extend the system in whatever they’re
comfortable writing.

It feels like the right compromise between honesty to each platform and a
shared operational vocabulary. I’d love to know if that approach strikes
you as sensible or if there’s a historical pitfall I’m not seeing.


On Sat, Nov 1, 2025, 1:42 PM A. P. Garcia <a.phillip.garcia at gmail.com>
wrote:

> Arnold,
>
> First, thank you. I really appreciate you taking the time to answer
> directly.
>
> I think you’ve put your finger on the most important tension: who is this
> actually for?
>
> I don’t think this shell would be aimed at “most developers,” and I agree
> with you that most developers neither want nor need to think in terms of
> kernel anatomy. Where I’m trying to land is much narrower: the people who
> are responsible for keeping a running system healthy at 2am, and for
> explaining after the fact what went wrong. Call it SRE / ops / old-school
> Unix admin / performance engineer. That’s the user I have in mind.
>
> Today those folks already are working at that level — they’re just doing
> it through a pile of ad hoc ps, awk, /proc/$pid/*, lsof, netstat/ss,
> ifconfig/ip, etc. My argument is basically: can we give them one coherent
> vocabulary instead of twenty partial ones, and let them script against it
> in a way that’s readable the next day?
>
> On the portability point: yes, guilty as charged. The examples I gave are
> Linux-flavored (task_struct, /proc, cgroups, netlink). The idea I’ve been
> kicking around is that Task, NetIf, Mount, etc., aren’t literally the
> kernel structs, but stable “operator-facing” objects. On Linux they’d be
> populated from /proc, /sys, cgroups, netlink, and so on. On a BSD, that
> same Task object would have to be populated differently (kvm, sysctl,
> whatever that platform exposes). Same interface at the shell level,
> different provider under the hood.
>
> In other words: not “the Linux kernel is the universal truth,” but “each
> OS gets to define how to surface its own truth through the same high-level
> nouns.”
>
> If that sounds naive, I’m happy to hear “here’s where that abstraction
> leaks immediately.” I’m trying to figure out whether the conceptual layer
> is sound enough to be worth pursuing, even if the first usable
> implementation is Linux-only because that’s where I live.
>
> Thanks again for the reality check. This is exactly the kind of feedback I
> was hoping for.
>
>
> Phil
>
> On Sat, Nov 1, 2025, 1:29 PM <arnold at skeeve.com> wrote:
>
>> "A. P. Garcia via TUHS" <tuhs at tuhs.org> wrote:
>>
>> > What I’ve been sketching out with a friend is a shell where the
>> fundamental
>> > objects aren’t strings or ad-hoc JSON, but live views of kernel
>> structures.
>> >
>> > [...]
>> >
>> > I’d love to hear if this resonates with your lived experience, or if
>> you’d
>> > say “nice dream, kid, but here’s why it falls apart in the real world.”
>>
>> Nice dream, kid, but here's why it falls apart in the real world:
>>
>> Most developers don't need to know that level of non-abstraction or
>> care to work at that level.  If you're building product, you hook
>> things together with shell (or other) scripts.
>>
>> What you're proposing may be dynamite for sysadmins trying to
>> troubleshoot,
>> but that's a small percentage of the potential user base.
>>
>> Not to mention it's linux-only and won't port to *BSD, macOS or what-have-
>> you.
>>
>> Now if Linux sysadmins IS your target audience, go for it.
>>
>> My two cents, of course,
>>
>> Arnold
>>
>