Re: Doesn't introspection limited to passive examination, withoutactions?
Can we collaborate about it?
Justin B Rye <justin.byam.rye@gmail.com> wrote:
> u34@net9.ga wrote:
> > Refering to
> > https://manpages.debian.org/bullseye/systemd/networkctl.1.en.html .
> > The DESCRIPTION section of the networkctl manual page, at the top of the
> > page, writes about introspection. Does introspection correctly describes
> > actions such as delete, up, down, reconfigure, reload? Those actions are
> > mentioned as possible commands at the COMMANDS section.
> > Can someone who read only the DESCRIPTION assume networkctl only offers
> > a simple dump of the network interface states?
>
> I think you're right; the synopsis
>
> networkctl - Query the status of network links
>
> is also misleading, and should at least say "query or modify" - more
> probably just "control".
>
> There's no good reason for networkctl(1) to mention the word
> "introspection" at all; that word is used these days as a technical
> term for something unrelated. What "networkctl status" does isn't
> even introspection in the normal non-jargon sense, since it doesn't
> check anything internal to networkctl itself, it reports the status of
> the machine's network interfaces (even if they're all managed by
> ifupdown).
>
> Manpages for other utilities in the systemd -ctl family say:
>
> bootctl - Control EFI firmware boot settings and manage boot loader
> busctl - Introspect the bus
> hostnamectl - Control the system hostname
> journalctl - Query the systemd journal
> localectl - Control the system locale and keyboard layout settings
> loginctl - Control the systemd login manager
> systemctl - Control the systemd system and service manager
> timedatectl - Control the system time and date
>
> I would suggest that busctl, journalctl, and networkctl should all
> standardise on "Control" (if it isn't accurate, they're misnamed!),
> and they should especially avoid adding redundant extra syllables to
> the word "inspect".
>
I believe that changing the names are far fetching, since they were get
used to by a lot of users. I think they will not accpet it. I also believe
that small, to the point, fixes are more managable for them.
> The bugreports would only be priority "wishlist", though.
Since the public upstream repository is at github, I headed there. Do you
think filing a debian bug is a better approach?
What do you think of
https://github.com/ZjYwMj/systemd/compare/systemd:systemd:main...man-pages-fixes
?
--
u34
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package
Reply to: