There are always "other options." If I feel I've been wronged by my neighbor, why should I have to put up with all the fuss of a lawyer and court when I have other options, like shooting him?

The whole point of this is that both multinational corporations and individuals shouldn't be given the option of paying no taxes anywhere, or a token amount. They only have other options because the rest of us are idiots for letting them have those options. Sure, idiots can be taken advantage of, but that doesn't make it right.

I'm pretty sure you don't need to know the time to calculate your position with GPS. The satellites all broadcast their idea of the time, and the only thing that matters for GPS positioning is the difference between them pairwise. If they all broadcast the wrong time, it would work just fine as long as they all broadcast the SAME wrong time.

It would also work fine if every GPS satellite just broadcast a single pulse once a second along with its position, and the receiver could measure the arrivial time difference between the pulses. It just is a lot easier to continuously broadcast the time than build such a receiver.

Once you know your position and the satellites position you can calculate the delay in arrival time and calculate the correct absolute time. If you had a GPS constellation such that one satellite gave you the time and a pulse per second, and the other satellites all gave a pulse per second, you could calculate your position and absolute time from 3 of them if you knew your general location.

Nobody dumped anything on anybody. Systemd pushes their stuff to a repository, and your distro decided that they'd rather use it than continue to do things their own way, and you decided to keep using the distro rather than doing things your own way. Sysvinit is still out there, freely licensed. If you want to use it, then use it! :)

Did you ask anybody for support, such as your distro? Sounds like it might be a bug. Or it could be a configuration issue. You can tell systemd to not care about exit codes, or even about killing processes.

You ask where would I start diagnosing what happened. I'd start by looking at the configuration and confirming that systemd isn't doing what you told it to do. After that I'd probably capture what I could (strace, etc), and post on the distro bug tracker.

The cursor is a unique ID for the entry I believe (and you can use it to request updated logs starting where you left off).

The boot ID changes on each boot, so you can associate log entries from the same boot cycle. The machine ID identifies the unique machine, and if you start 47 clones of the same container they will get different ones (I think that if you only run one instance of a container it will keep the same one). Systemd actually has a bunch of logic around hostnames that I haven't looked too closely at but it is aimed at things like clusters, containers, pxe-boots, and the like. It usually just does the "right thing" and it is trivial to just tell it to stick with one name.

Well, journalctl does that already. The default output for that one line is:
Oct 30 18:59:18 rich64 mythbackend[2361]: 2014-10-30 22:59:18.990471 C mythbackend version: tag: v0.27.4 [e4f65c8] www.mythtv.org

http://www.freedesktop.org/sof...

Sure. And if it starts with a timer unit then you need to stop that or the service will restart when the timer next triggers.

Sockets, services, and timers can all be related. That doesn't mean that the stop command doesn't work.

This is no different from having to stop xinetd if you have services that are launched from it, lest the next connection just restart the service.

There is nothing nasty about this - sockets and services are related but not identical. Maybe somebody in Debian didn't think of this, but that hardly makes it a systemd bug.

Half the problems our society face are due to strict adherence to the rule of law. The law is hard to change, and those who are trying to cause harm to people or accidentally causing harm to people change all the time. You'll never get a tax code that can't be avoided even setting corruption aside for this reason.

If you want to see an end to corruption and the like at some point the court has to rule "we've examined the senator's actions, found that it has broken no laws, and sentence him to 10 years of hard labor with no possibility of parole all the same."

Obviously anarchy has its own problems. There has to be something in-between, and you can't write down what it is, because that would be the strict rule of law. :)

Well, without using anything fancy you can get journalctl to output in a number of formats, including json (ether compact or pretty). Here is an example "line:"

{
                "__CURSOR" : "s=0fb0e8333d264abba3b59c6a8e875767;i=16c9c5;b=56b2f17d2294428fbbb58579ae947505;m=57bad70;t=506abd490de30;
                "__REALTIME_TIMESTAMP" : "1414709958991408",
                "__MONOTONIC_TIMESTAMP" : "91991408",
                "_BOOT_ID" : "56b2f17d2294428fbbb58579ae947505",
                "_UID" : "0",
                "_GID" : "0",
                "_SYSTEMD_SLICE" : "system.slice",
                "_MACHINE_ID" : "7fd75bd599233e3ce0ce5e5f00000029",
                "_HOSTNAME" : "rich64",
                "_TRANSPORT" : "stdout",
                "PRIORITY" : "6",
                "SYSLOG_FACILITY" : "3",
                "_CAP_EFFECTIVE" : "0",
                "SYSLOG_IDENTIFIER" : "mythbackend",
                "_COMM" : "mythbackend",
                "_EXE" : "/usr/bin/mythbackend",
                "_CMDLINE" : "/usr/bin/mythbackend --loglevel notice --nologserver",
                "_SYSTEMD_CGROUP" : "/system.slice/mythbackend.service",
                "_SYSTEMD_UNIT" : "mythbackend.service",
                "MESSAGE" : "2014-10-30 22:59:18.990471 C mythbackend version: tag: v0.27.4 [e4f65c8] www.mythtv.org",
                "_PID" : "2361"
}

Simple, they just require the same certification for travellers entering their own country. If all of the schengen area area doesn't cooperate, then they can't certify anybody, and any traveller from spain gets quarantined.

Let them land, and then quarantine them, and then bill the airline for it. Just make it a landing fee - $10k per passenger not certified as not being from West Africa or something like that. Or you could just set the landing fee at $10k*1000 passengers paid prior to departure, and then refund $10k for every one of those 1000 passengers who either wasn't on the plan or was certified.

And as you've already pointed out 47x I really could care less whether this is legal.

And that is why there is a good chance we'll end up having an Ebola epidemic break out. People are afraid to break the law even when it makes obvious sense to do so. Politicians instead just downplay the whole thing so that in the more likely event that this blows over they can just point to the chicken little crowd and tell them I told you so. If things blow up they'll just point to the constitution and say that because the holy document says we must commit suicide, we had to do it.

man systemd.kill

KillMode=
                      Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none.

                      If set to control-group, all remaining processes in the control group of this unit will be killed on
                      unit stop (for services: after the stop command is executed, as configured with ExecStop=). If set to
                      process, only the main process itself is killed. If set to mixed, the SIGTERM signal (see below) is
                      sent to the main process while the subsequent SIGKILL signal (see below) is sent to all remaining
                      processes of the unit's control group. If set to none, no process is killed. In this case, only the
                      stop command will be executed on unit stop, but no process be killed otherwise. Processes remaining
                      alive after stop are left in their control group and the control group continues to exist after stop
                      unless it is empty.

                      Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=).
                      Optionally, this is immediately followed by a SIGHUP (if enabled with SendSIGHUP=). If then, after a
                      delay (configured via the TimeoutStopSec= option), processes still remain, the termination request is
                      repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option). See kill(2) for
                      more information.

                      Defaults to control-group.

So, you can have it your way... :)

Agree that nfs isn't always as well-tested in systemd. I had an NFS-root box running systemd and there were some growing pains. However, I found the systemd/dracut/networkd devs very responsive to bugs around this.

I think that saying that systemd is not "all baked" is a fair statement. If you have fairly generic needs it works great, but if your needs are more exotic you might have to deal with the odd bug. I haven't found any to be terribly difficult to fix.

Imagine a copy of zlib bundled with every application Google distributes. Is that better or worse than using the system library? Any distro maintainer could answer that one.

Sure, you can do all this stuff with a clever traditional init.d script. However, do you want the same function tweaked 75 ways in your scripts, or a standard way of doing it in your service manager? If the private-tmp feature in systemd has a bug it can be fixed for all services at once.

But yes, those are largely all linux kernel features that systemd is merely exposing. In practice it means that people will actually use them now.

Sure, but a variation on his config would work with any distro, so this lets upstream lock down a service file and benefit everybody who uses systemd on any distro. It does overlap a bit with SELinux, but not everybody uses SELinux and this is a much more lightweight way of hardening a service.

man systemd.service:
Type=...One of simple, forking, oneshot, notify or idle.

If set to simple...systemd will immediately proceed starting follow-up units.
If set to forking...systemd will proceed with starting follow-up units as soon as the parent process exits.
Behavior of oneshot...it is expected that the process has to exit before systemd starts follow-up units.
Behavior of dbus...systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired.
Behavior of notify...systemd will proceed with starting follow-up units after this notification message has been sent.
(Idle is just simple but delayed and run sequentially so that the console log isn't interleaved - not really recommended for general use.)

The behavior you describe is only the case for simple units. Forking is preferred if a daemon forks when it is ready. dbus/notify are obviously ideal ways to handle things as the daemon can explicitly communicate readiness. Other options include simple daemons with an execstartpost that polls for readiness (unit isn't considered started until this finishes), or having a separate unit that polls for readiness and that is made the dependency of other units.

If what you said was true systemd would almost never work. One thing you quickly discover using systemd is that failure to specify dependencies often causes problems, because systemd launches services VERY QUICKLY in parallel. I used to openrc in parallel and there is a big difference between having a bash script launching a bunch of bash scripts which launch daemons in parallel, vs having a program written in C launch a bunch of daemons in parallel. If you didn't have any dependencies you could have your daemons all firing off in the span of a few milliseconds.

Actually, when I first started messing with systemd 1.5 years ago the first thing I noticed was how fast the shutdowns went. That was a far more dramatic improvement than startup was in my experience. I find shutdowns are still quite quick - the biggest slowdown I have on my main box is that I run a large multi-volume btrfs filesystem and that can take 10s of seconds to unmount. The rest takes very little time to shutdown, and this is a host that runs a bunch of containers that are all themselves running systemd, and those have to shut down before the host can shut down (each container is a service).