[TUHS] evolution of the cli

[A. P. Garcia via TUHS]

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
>