Just some considerations I posted elsewhere:
- I think there are good reasons to do away with -ctl nomenclature no
matter how prevalent these days across Linux systems.
- You could call the journalctl tool "journals" -- it doesn't exist,
could give access to various system logs, and become the ease-of-use
"gateway" to such logs (as it already is, or portends to be).
- You could call the systemctl tool "control" -- systemd is now
ubiquitoes and important enough on most systems it is installed in that
such a generic term would perhaps now be warranted. Instead of the long
list of abilities systemctl has now it could be more modularized in the
git style of things, or some of its functionality could be extracted to
.e.g some "services" tool.
Even a tool called just "system" would be up for consideration, I think.
Why not think about whether instead of one systemctl there could be
perhaps 3 different tools that could be closely related or function as
part of modules of their own.
Close to that is that many useful programs are called systemd-something
which is already that modularisation I speak of.
But "systemd" is not a user tool. However you are inclined to type
"systemd" after having used on one the other tools.
I would propose that systemd would become either the name of the control
application (and not just, or not, the daemon) or you think about
reorganising the things such that you one one nomenclature for all the
different systemd-programs that a person can or needs to use.
Having separate commands makes for shell-friendliness (due to
tab-completion) but regardless the same is also provided for something
like Git.
The - nomenclature is very nice though, one frequently wants to write
"apt-show" on a debian system. However the systemd-* tools are not most
prominent, most prominent are systemctl and journalctl.
And personally I just like the upstart syntax as well...
If you were responsible for the complete end-user experience of a
system, you would choose names as generic as "system" or "control".
"system shutdown" is not all that bad of a thing to say.
"service enable <name>" would perhaps get rid of the upstart heritage,
no matter how much I like it.
More I would like "service <name> enable" because it seems more
object-oriented, but either way, the current confusion is annoying.
How about "target graphical activate" ;-).
"journal sys view"
"journal openvpn" -- view = default actuion.
It becomes a way of selecting objects and performing actions on them.
One could even write a systemd-wrapper for nothing other than the syntax
of commands. It should be possible to demonstrate a different model that
way, but would take a lot of work from a single person not that invested
in the product.
For example,
"service <name>" would default to the "status" command.
Or to provide description and status.
"target multi-user" would provide a description and possible actions you
can perform on that target.
"target list" could list all known targets
"target history" could show the sequence of targets in the current
running system.
"target list enabled" would show enabled targets, and so on.
So you would turn service and target, two notable concepts, into tools
of their own that provide information and manage those two types of
objects.
Then "journal" becomes the 3rd tool I mentioned. Then "system" becomes
the fourth, or something, and you'd be done with that.
Then "user" becomes the fifth, making it more possible to access
user-specific services (--user).
I mean it is all very generic and we know of the complaints against the
omnipresence of systemd but at the same time These are all commands for
runlevel things and services and startup and shutdown which systemd
already is. And log information about that system, in a sense.
So you then have these commands:
- system
- service
- target
- user
- journal
They accept a mix of verbs and objects, such that
* service <name> action
* service list <parameter>
* service status
* service overview
Become acceptable commands. This does require that some names become
forbidden for use as service names.
* target <name> action
* target history
* user change
* user logout
* user password
* user groups
* user service <*>
* user target <*>
* user system <*>
* system suspend (...)
* system analyze <target/object>
* system mask <service>
* system protect network
* system shutdown network
Become available tools.
Broad, system-wide actions or use cases could be given a single,
accessible and pleasurable verb that are almost like the equivalent of
commands such are "systemctl rescue" today.
Why not such actions or targets such as:
- closing all network access
- closing all external action to services
- closing all encrypted containers currently open (by force)
- booting a certain user, or shutting down all services belonging to
that user.
- maybe even entering a maintenance mode that even umounts the root
filesystem such that the rootfs can be repaired, etc.
You could imagine prompts such as lvm>
You could imagine services typically having a console that you could
enter with service <name> console
I don't know. Just possibilities.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
