[systemd-devel] thoughts on different command structure

[Xen]

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.