Marc Chamberlin said the following on 04/10/2013 08:06 PM:
it is that simple, and works.
The learning curve is sometimes very steep and there are lots of "magic" commands that not everyone is familiar with.
I'd say the opposite. The big step is letting go of the old way of doing things. There's only really the one command - we've covered that. The trick is to think in terms of the dependency tree. And I mentioned the command for visualising that.
That is why having good GUI's, that act as guides to help us poor uneducated users solve such problems, is so important. IMHO! Then we wouldn't have to bother the experts with our dumb questions.
HA! All the evidence is to the contrary!
Having a sea of command line commands with a universe of options is wonderful for all the advance Linux gurus in the world, but for those of us who are learning the ropes, it is not always easy to find these golden nuggets on our own or discover/grok a new command such as systemctl....
What's this about the see? There aren't many commands; compared to tracing though wall the intricacies of shell scripts, includes, defined functions, external commands, then the systemd way of working is the joyous simplicity. If this had been thought of first we'd never have dreamt of something as awkward as sysvinit. Please disabuse yourself of this 'sea of commands' notion and please disabuse yourself of the idea that systemctl was difficult to find. Well perhaps it was since it is just the one think. Oh, right, there's a GUI version as well. Two things. And the log viewer. Three. As for finding things in the 'sea' that is /usr/bin - DON'T! I keep telling you guys out there in the suse world - use the 'apropos' command. A few times. "apropos systemd" will refer you to 30 man pages which will let you learn about the innards and operation of systemd. Does that seem a lot? Well think how many you need to read to learn about file systems - access control, the various standards, how udev works and more. In true UNIX tradition it has been broken down on the 'each thing does one thing' principle. And really, of those 30 how many are commands? systemctl (1) - Control the systemd system and service manager This is the one you need to know systemd (1) - systemd System and Service Manager You never invoke that, the init process starts it systemd-ask-password (1) - Query the user for a system password Again, you never run that; the system uses it when it needs your input systemd-cat (1) - Connect a pipeline or programs output with the journal That's the equivalent of "logger(1) for when you're writing control scripts, if ever systemd-cgls (1) - Recursively show control group contents A debugging & reporting tool Only relevant if you are using the control group mechanism (which pre-dated systemd) to divide up machine resources, for example to virtual machines or tasks. systemd-cgtop (1) - Show top control groups by their resource usage See note above. like the top(1) command but for the groups systemd-journalctl (1) - Query the systemd journal This you probably do need. The 'journal' is a 'replacement' for syslog that uses a binary format rather than plain text. This is the viewer. systemd-loginctl (1) - Control the systemd login manager Does something we should have had long ago - manage logins Try this command: systemctl help systemd-logind.service then systemctl status systemd-logind.service systemd-machine-id-setup (1) - Initialize the machine ID in /etc/machine-id systemd-notify (1) - Notify init system about start-up completion and other daemon status changes These are 'internal' to the operation systemd-nspawn (1) - Spawn a namespace container for debugging, testing and building This is a mechanism for doing the init of chroot'd subsystems Either you need to know how to use it 'cos you're setting those up, or you don't. I suspect you don't. I don't. So what about the others? The are man-5 or man-8, that is definition of file types and purposes. About as relevant as the on-disk structures involved with LVM or the various file system types and superblock layouts. Essential to the operation but ... What's more important is understanding the why and wherefore of systemd. The best way to do that, IMHO, is to read Lennart's Blog. There's a lot of it and it warrants reading over and over as your understanding grows. Don't expect to understand it all, and certainly not part XII, immediately. Heck, I'm still learning from what in systemctl(1)! Some of what parts of this thread have touched n Lennart covers in http://0pointer.de/blog/projects/three-levels-of-off.html Please note the date. Please not that its also the only useful mention of symlinking there. Its sort of 'kill with extreme prejudice' for the job. (Perhaps the systemctl command needs 'mask' option.) I'd particularly bring to your attention http://0pointer.de/blog/projects/the-biggest-myths.html <quote> Myth: systemd is difficult. This also is entire non-sense. A systemd platform is actually much simpler than traditional Linuxes because it unifies system objects and their dependencies as systemd units. The configuration file language is very simple, and redundant configuration files we got rid of. We provide uniform tools for much of the configuration of the system. The system is much less conglomerate than traditional Linuxes are. We also have pretty comprehensive documentation (all linked from the homepage) about pretty much every detail of systemd, and this not only covers admin/user-facing interfaces, but also developer APIs. systemd certainly comes with a learning curve. Everything does. However, we like to believe that it is actually simpler to understand systemd than a Shell-based boot for most people. Surprised we say that? Well, as it turns out, Shell is not a pretty language to learn, it's syntax is arcane and complex. systemd unit files are substantially easier to understand, they do not expose a programming language, but are simple and declarative by nature. That all said, if you are experienced in shell, then yes, adopting systemd will take a bit of learning. To make learning easy we tried hard to provide the maximum compatibility to previous solutions. But not only that, on many distributions you'll find that some of the traditional tools will now even tell you -- while executing what you are asking for -- how you could do it with the newer tools instead, in a possibly nicer way. Anyway, the take-away is probably that systemd is probably as simple as such a system can be, and that we try hard to make it easy to learn. But yes, if you know sysvinit then adopting systemd will require a bit learning, but quite frankly if you mastered sysvinit, then systemd should be easy for you. </quote> Personally I was glad to get rid of the mess that sysvinit had become. -- inoculatte (v): To take coffee intravenously when you are running late. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org