2013-07-15
Systemd needs sensible, non-truncated output
If you run 'systemctl status <service>', you get (among other things)
some recent log messages from the service in question. Well, in theory
you get that. In practice, well, here is part of what one of my machines
shows:
Jul 15 17:18:20 mumble123.cs.toronto.edu unbound[31622]: [31622:0] notice: in...
Yeah.
What's Unbound trying to tell me? I have no idea because systemd has
truncated the output in a useless way. I don't believe in truncating
output by default to start with but if systemd is going to do it
it should do it intelligently. Almost all of this line is useless.
Especially useless is the huge hostname, because by definition
systemctl is reporting on things from the local machine.
Of course, you may say, systemd is really just reporting some lines from syslog and chopping them off at 77 characters and thus the formatting is not its fault. Well, actually, it is. If systemd is going to truncate the output at all, it has to take responsibility for the formatting of the whole thing; effectively the rule is 'you break it, you own it'. Truncating the output is breaking it, so it becomes systemd's job to make it useful again.
Unfortunately this isn't a small issue. If you have a service
that doesn't start, these very log messages may contain important
information, information that systemd by default won't show you.
You can make systemd show you in various ways (piping the output to
something, remembering the --full argument, and probably others), but
speaking as a sysadmin, you shouldn't have to remember any of this.
Systemd should do the right thing by default because sysadmins already
have enough to keep track of and truncating the output (especially in
useless ways) is almost never what we want.
Git's petty little irritation for me
Perhaps the most common thing for me to do with people's source code is to add my own purely local changes. When the source code is in a source repo, the simplest way of doing this is to just pull a copy of the source repo and then make my own changes on top. Then sooner or later I want to update my local repo by pulling in the latest central changes.
With CVS, SVN, and even Mercurial this more or less just works, however theoretically unclean and evil it is; all three detect that I have uncommitted local changes and attempt to re-apply them on top of the updates. Usually this succeeds and if it doesn't, the convention is to stick glaring markers in the files and leave it to me to fix them up. Git insists on doing the right thing in that at least by default it utterly refuses to try to merge my uncommitted changes with the remote updates it's just fetched.
It turns out that this unusual strictness on git's part is irritatingly
inconvenient for me. I definitely don't want to actually commit my
changes because that would contaminate what is otherwise a pure upstream
repo history with a tangle of back and forth merges (even if I did it on
a branch). There is 'git stash', but it has two aspects that I don't
like; I have to remember (or be reminded) to do it explicitly and it
makes changes to the repo itself (not just the checked-out files). I
really like my repos to be exact, unchanged duplicates of the upstream.
(Yes, the changes 'git stash' makes should be harmless and should
get fixed up when I do 'git stash clear' or the like. That's two
'shoulds'.)
This is a completely petty irritation (especially given 'git stash')
and I fully acknowledge that. But I've never claimed to be entirely
rational about this stuff and yes, it irritates me.
Sidebar: When this doesn't work in Mercurial
There is one circumstance when Mercurial will not do this sort of update at all, namely when the main branch in the repo shifts. The Mercurial repo for official Firefox releases hops branches this way when a new major release comes out and as a result I get to save a patch of my changes, overwrite them all by forcing a clean checkout, and then reapply them. Fortunately this is rare.
(Also these days I've found up switching to building my local Firefox from the main development repository, which doesn't branch this way.)