And how do I do that when, for example, configuring a non-running system from a different system? Like, for instance, setting up embedded systems?

You don't _need_ the *ctl tools to configure a systemd system. Just use "ed -G" (or "vi" if you need some hand holding wysiwyg GUI) to edit the text configuration files. This is no different from sysvinit.

systemd and journald support live remote logging and what not, and if they doesn't all ready support reading of offline log files, they surely will. (not something I have looked at, but perhaps "systemd-journal-remote" is what you need).

The reliance on *ctl apps that have to actually run on the system is a big step back, towards Windows and how you can't really do much about the registry or event logs without a running and compatible Windows system, and for many things THE system it runs on.
This is the direction systemd/journald is taking us, and we've seen this before, with AIX. It didn't impress us then, and it doesn't now.
Those who don't know (Unix) history are doomed to repeat it.

Having to rely on systemctl is no different than to rely on eg. Bash, vi and all the nice GNU tools, without those, not much can be done.

I see no real world problem in either using the tools on the running system by using eg. ssh, or having a systemd compatible system to analyse log files on a remote system (either offline or live remote logging). In fact, I don't think this is any different from using sysvinit/rsyslog today, except that systemd offers better tools for analysing problems and much better security etc.

They didn't help me when systemd crashed and took with it the entire system. It's built as a card house, with assumptions that things don't go pear shaped, or if they do, you have time to wade through hundreds of configurations in search of the proverbial needle in a haystack.
I don't LIKE systems where you put all your eggs in one basket, and for good reason.

This is no different from a failed init that causes a kernel panic. The difference is that systemd now is thoroughly tested on *thousand of machines and keeps improving, so using it to control services will minimize all the dangers that comes from hand editing complicated, often undocumented init scripts.

systemd has superior debugging facilities and is well documented. You can actually systematically analyse what a certain run-level (called target) requires, or tell systemd to spawn a shell if it crashes. It is so much better when it comes to tracking down service/daemon troubles than static scripts.

Sure, there is something to learn about systemd before mastering it, and many people seems to loathe reading about new technology, or just doesn't have much time on their hands to learn new stuff. But neither is a systemd problem, and learning new technology and new ways of doing things, comes with the territory as SA.

Check out all the wonderful stuff one can do with systemd, journald, and all the *ctl tools; completely consistent control and behaviour across every Linux system that uses systemd. No need to learn and relearn dozens of small system peculiarities across distributions for controlling services, working with log-files, getting system info, etc. etc.

systemd is the future because it is such a good idea that most major distributions are switching to it. I will recommend all Linux SA's to put their real or imagined reservations against systemd aside, and start boning up on the subject

There is a lot to learn, not because systemd is complicated, but because it can do so many things, like resource limiting, mounting etc.

Here is a link that compares sysvinit, Upstart and systemd
http://0pointer.de/blog/projects/why.html

Come on, "On-demand socket activation for per-connection service instances" for virtual servers, how cool is that!

And what do you do when something goes wrong? Or you need access from a different arbitrary system?

That sort of questions is exactly why you should read the linked pages. So calm your fuming hate against Poettering and start reading.

I guess your very vague question is something about accessing Journal log files, something you probably think can be problematic since they are binary, right? No worries mate. Syslog is a first class Journal client, you can read all the usual text file stuff in /var/log/* if for some reason journalctl doesn't work, but everything else does. Journal send all messages to syslog, including early boot stuff that syslog couldn't log before.

It is just that when journalctl (and all the other cool *ctl tools) works, it is faster, easier and more secure than the usual chaotic syslog logging. So what is wrong with displaying not only an error message, but also the exact link where the error message is explained and documented? "journalctl -f" instead of "cat /var/log/messages | tail" ?
Cryptographic secure logging? That you have an actual guarantee that a message is written by the daemon it claims?

"journalctl", "systemctl" and all the other *ctl tools like localectl, hostnamectl and loginctl, are just wonderful and powerful tools, that promises some kind of consistency when it comes to Linux logging and system information gathering etc.

The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).

Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.

Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.

IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.

I really recommend reading this list of systemd myths:

http://0pointer.de/blog/projects/the-biggest-myths.html

And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html

Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.

They placed the AP's so that the heat they generated wouldn't affect the garden cress. Room temperature was computer monitored and regulated, the humidity was regulated, and they photographed the batches to document that no drying up or rot was present. They mixed the seed batches, randomized the seed selection etc etc.

The experimental setup and their elimination of errors and bias is considered to of very high quality, which is why they won a junior science prize. Their actual result meant nothing in that regard.

The first experiment was with idle AP's only broadcasting ESSID. The second experiment added some Linux laptops that ping-flooded to generate lots of network activity. The second experiment showed a clear increase in plant "damage" /lack of development.

The flame baiting, lame summery tries to make it looks like some evil diplomat tries to censor some facebook pages. But as the TFA says, this is about an imposter who has assumed a diplomats name on a fake facebook account and now post fake posts.

The point is that RDO isn't a new distro, or a specific RH flavour of OpenStack, but just plain vanilla OpenStack builds, nicely packed in RPM's and with a "yum" repository. So RH based distros like Fedora 18, CentOS, Scientific Linux can install and maintain it, just by enabling the RDO yum repo.

There is a quickstart guide and lots of documentation here:
http://openstack.redhat.com/Quickstart

All in all, this makes it really easy to test and play around with OpenStack.

I haven't seen a prototype, but a really hot technology that would fit perfectly with a watch device is two factor authentication (2FA) with one time passwords (OTP), combined with NFC, and probably some biometric stuff too.
Use it to lock or unlock your phone, tablet, pc, to encrypt your devices, and really good password management and internet authentication and secure connections. Could be used to boost credit card and on-line banking security significantly. It wouldn't matter any more if a hacker stole your password from either your pc or from a web service break in; they can't abuse the password without the iWatch too.

Look at Ubikey for a 2FA, OTP, NFC usb device:
http://www.yubico.com/products/yubikey-hardware/yubikey/

Could be integrated with your car or house lock system too, or your house lighting system.

Since it could work as a broadcasting tracking device, high end boutiques could use it to dispatch grovelling salespersons directly at the iWatch wearer when they entered the premises:-)

I really don't have the technical knowledge to praise or damn the idea, but as I understand it, there are some clever moves in this;

It appears that they rip out enough of Android that they can use the Android graphic drivers for Mir, so that every device with android drivers delivers "free" drivers for Mir too. That would give them a huge advantage in the Smartphone and Tablet arena.

QtMir, QtUbuntu, Qt/QML; it looks like Ubuntu dumps Gnome/GTK in favour of Qt5 for core OS (GUI) development. As I see it they will clone KDE/Qt, substituting the KDE parts with QtUbuntu.

Their time line seems very optimistic though.

"Yubikey" looks very interesting. I have been thinking about two-factor and OTP hardware to increase my security, but I wasn't aware of actual implementations that worked for Linux.

The point is that PA allows unobtrusive audio clues, like a gentle "ding ding" 10 minutes before an appointment, even though you are listening to fairly loud music. I like the fact the sound levels in VLC and Amarok is different from the rest of the system.
Before PA there wasn't a functional sound daemon, so everybody just turned off any sound notifications and manually set the sound level to zero to avoid a sudden blast of noise when accidental starting a web commercial, or when "System Bell" gave a extremely loud warning "DING!" just because you had been listening to load music earlier that day.

Not talking about the problems with running sound i Dosbox, or using two apps with sound at the same time, bluetooth sound, etc. PA solved all those problems, it just works and makes life easier for developers, distro makers and end users, which is the reason why all major Linux distributions have converted to it.
People trash talk PA, but it just that, trash talk, without technical argumentation, without any alternative to the many features that PA gives, and without regard to the fact that PA works well in the real world.

SystemD goes way, way beyond the wish of faster booting. It really is a Sysadmins dream come true when it comes to controlling the many services (not just daemons) that runs on modern Linux systems. "systemctl" is just a natural, UNIX like way of controlling all these services from the command line or in scripting. "init/Sys V" was perhaps a fitting system for the needs of Unix boxes in the 1980's, but modern day servers and desktop systems have other needs, and init scripts are complicated, messy and fragile to edit. SystemD is just so coherent and natural to use, and allows far superior ways of maintaining, configuring, and monitoring systems.

I think your main problem is, that make your own way of using your system, a baseline for everybody else. You may not use sound very much, but many people actually do, you probably don't use bluetooth sound on your system, but many Linux devices, like smartphones do, you may not have the need to tweak init scripts, or administrating or monitoring services on a server, but other people do.

I was an early adopter of PulseAudio since I used Fedora Core. Yes I had problems in the beginning, but only because I used my uncommon internal audio chip. When I used an old, but common and well supported SB 16 card, my problems went away. Really, if you still have problems with PulseAudio, it is because your distro or the audio chip drivers sucks.

Not only does PulseAudio works, it provides features and benefits that ALSA/ OSS /ESD /ArtsD doesn't have. PulseAudio is an elegant solution to the many problems Linux used to have with its audio system. Come on, who doesn't want individual audio level settings for each program?

I think Lennart Poettering's work on PulseAudio and Systemd is superb. PulsAudio just plain works; sound has never been so easy and flexible in Linux.
Sys V /init can't die fast enough in my opinion. Fedora, Ubuntu, OpenSuse, Arch Linux and many lesser distroes, have all ditched it in favour of modern solutions.

Claiming that Red Hat want to kill Open Source is just plain pathetic. RH is _THE_ major contributor to Linux, both with their own projects and up stream contributions. They have always been unwavering staunch in their belief and support of Open Source.

I have yet to see even one example of plagiarism among the 92 examples given. The blogger seems unable to understand that it is common academic praxis to sum up e.g. a theory from a work. Of course such a summery will bear some resemblance to the original work, otherwise it wouldn't be a summery. But as long as there are good footnotes documenting this, it isn't a problem.

One could in fact argue, that since the blogger doesn't seem to have found even one good clear case of plagiarism, the dissertation comes out strengthened.