[TUHS] evolution of the cli

[Arnold Robbins via TUHS]

Hi.

"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.

OK, so I'll buy that your approach makes some sense for that crowd.

> 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 like that idea.

> 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.

I know nothing about WASM, so I can't really comment.

What's echoing in my head at this point is that something like
Plan 9's treatment of devices with /dev/xxx/ctl and /dev/xxx/data
files would be better - if you could expose a file system like
interface to the kernel data structures.  Maybe via FUSE?

Of course, your query language was sort of SQL-like, and as an
old Unix hand I prefer shell scripts, so now my bias is showing.

Interesting ideas, though.

Arnold