Lennart Poettering (mzerqung@xxxxxxxxxxx) said:
> So, here's my call for help, in order to make this all a big success:
So, I've actually played with this now, instead of just asking questions
and operating on knowledge from the initial announcement.
I must admit... at first glance, I'm not the hugest fan, simply because of the
interface it presents to the admin.
1) Jargon/Renaming of concepts
systemd is heavily invested in jargon specific to systemd. For example,
the main unit of configuration is:
- sysv: service file
- upstart: job file
- systemd: unit file
'service' and 'job' are fairly well-understood (and similar) concepts.
'unit' has no overall meaning... it's just a generic word.
Even if you go to explore that, it states:
A unit configuration file encodes information about a service, a socket, a
device, a mount point, an automount point, a swap file or partition, a
start-up target, a file system path or a timer controlled and supervised by
systemd(1).
I do realize that it's essentially operating as an abstract class here, but
that's a complicated distinction to make, as the docs are essentially
telling the admin that an unit can be anything or nothing.
Similarly, the redefinition of the concept of 'runlevel' as 'target' (well,
amalgamations of targets) is replacing a concrete concept with a generic word, and
replacing 'enabled/disabled' with 'active/inactive' seems random.
2) Complexity
While there's a certain level of complexity to doing complex things, systemd
seems to go overboard.
Example 1:
# of jobs/events/whatever files shipped by default (not counting SysV services):
- sysv: 1
- upstart: 19
- systemd: 62
And in this case, we're not using systemd for much natively. It's a lot of
data to sort through if you're trying to just figure out what's going on,
and if you're not clear with all of the systemd concepts, a lot of it looks
strange, such as:
- why does everything need *both* mount and automount files?
- if swap, local-fs, etc. are all bookkept internally, what's the point of
having a target file?
- why does setting of Alias *also* require a symlink? (It may not, but
local vs. rc.local seems to imply it might.)
I do wonder if perhaps this could be simplified by:
- Keeping services and targets separate on the filesystem
- Merging services and sockets into the same file where appropriate... given
that they're tied together inherently anyway, I'm not sure why they
need to be separate.
Example 2:
I want to configure the number of gettys on the system.
- sysvinit
Edit /etc/inittab. Add/delete some obvious lines.
- upstart
Edit /etc/sysconfig/init (discoverable by looking in /etc/init at the
start-ttys.conf file, which is documented in inittab if people look there
first.)
- systemd
Use systemd-install to add or delete the
/etc/systemd/system/getty.target.wants/getty@xxxxxxxxxxxx (or whatever)
symlink.
This requires knowledge of:
- what systemd targets are
- what the target name is that starts gettys
- what 'wants' means in this systemd context
- the proper systemd interface to install/remove commands
At least, if it doesn't *require* that knowledge, it *exposes* you to that
complexity in terms of the path names, the random '@' which I'm sure has
meaning, but isn't obvious, etc. (And, as neat trick, you can't find
these getty services via systemctl, as far as I can tell.)
...
In any case, that's just a first impression. I'll play with it and try and
wrap my head around it some more. But I can't help but think that systemd
presents as much more complex/baroque than it needs to.
Bill
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
