I've become mostly indifferent to what language something is written in
In a comment on this entry, Opk wrote (in part):
Will be interesting to hear what you make of git-series. I saw the announcement and somewhat lost interest when I saw that it needed rust to build.
I absolutely get this reaction to git-series being written in Rust, and to some extent I share it. I have my language biases and certainly a program being written in some languages will make me turn my nose up at it even if it sounds attractive, and in the past I was generally strongly dubious about things written in new or strange languages. However, these days I've mostly given up (and given in) on this, in large part because I've become lazy.
What I really care about these days is how much of a hassle a program is going to be to deal with. It's nice if a program is written in a language that I like, or at least one that I'm willing to look through to figure things out, but it's much more important that the program not be a pain in the rear to install and to operate. And these days, many language environments have become quite good at not being pains in the rear.
(The best case is when everything is already packaged for my OSes.
Next best is when at least the basic language stuff is packaged and
everything else has nice command line tools and can be used as a
non-privileged user, so '
go get ...' and the like just work and
don't demand to spray things all over system directories. The worst
case is manual installation of things and things that absolutely
demand to be installed in system directories; those get shown the
exit right away.)
In short, I will (in theory) accept programs written in quite a lot
of languages if all I have to do to deal with them is the equivalent
<cmd> install whatever', maybe with a prequel of a simple
install of the base language. I don't entirely enjoy having a
$HOME/.<some-dir> populated by a pile of Python or Ruby or Perl
or Rust or whatever artifacts that were dragged on to my system in
order to make this magically work, but these days 'out of sight, out
There are language environments that remain hassles and I'm unlikely to touch; the JVM is my poster child here. Languages that I've never had to deal with before add at least the disincentive of uncertainty; if I try out their package system and so on, will it work or will it blow up in my face and waste my time? As a result, although I'm theoretically willing to consider something written in node.js or Haskell or the like, in practice I don't think I've checked out any such programs. Someday something will sound sufficiently attractive to overcome my biases, but not today.
(As mentioned, I generally don't care if the program is available
as a prebuilt package for my OS, because at that point there's
almost no hassle; I just do '
apt-get install' or '
and it's done. The one stumbling block is if I do '
and suddenly three pages of dependent packages show up. That can
make me decide I don't want to check out your program that badly.)
In the specific case of git-series and Rust, Rust by itself is not quite in this 'no hassle' zone just yet, at least on Fedora; if I had nothing else that wanted Rust, I probably would have ruled out actively looking into git-series as a result. But I'd already eaten the cost of building Rust and getting it working in order to keep being able to build Firefox, and thus at the start of the whole experience adding Cargo so I'd be able to use git-series seemed simple enough.
(Also, I can see the writing on the wall. People are going to keep on writing more and more interesting things in Rust, so sooner or later I was going to give in. It was just a question of when. I could have waited until Rust and Cargo made it into Fedora, but in practice I'm impatient and I sometimes enjoy fiddling around with this sort of thing.)
This casual indifference to the programming language things are using sort of offends my remaining purist insticts, but I'm a pragmatist these days. Laziness has trumped pickiness.
(Not) changing the stop timeout for systemd login session scopes
I wrote earlier about an irritating systemd reboot behavior, where systemd may twiddle its thumbs for
a minute and a half before killing some still-running user processes
and actually rebooting your machine. In that entry I suggested that
/etc/systemd/user.conf (or in
a file in
user.conf.d) would fix this, and then reversed myself
in an update. That still leaves us with the question: how do you
change this for user scopes?
The answer is that you basically can't. As far as I can tell, there
is no way in systemd to change
TimeoutStopSec for just user scopes
(or just some user scopes). You can set
/etc/systemd/system.conf (or in a file in
then it affects everything instead of just user scopes.
(It's possible that you're okay with this; you may be of the view that when you say 'shut the machine down', you want the machine down within a relatively short period even if some daemons are being balky. And aggressively killing such balky processes is certainly traditional Unix shutdown behavior; systemd is being really quite laid back here. This is an appealing argument, but I haven't had the courage to put it into practice on my machines.)
As you can see in
systemctl status's little CGroup layout chart,
your user processes are in the following inheritance tree:
user.slice -> user-NNN.slice -> session-N.scope
You can create systemd override files for
user.slice or even
user-NNN.slice, but they can't contain either
TimeoutStopSec directives. The former must go in a
section and the latter must go in a
[Service] one, and neither
section is accepted in slice units. There is a 'user@NNN.service'
that is set up as part of logging in, and since it's a
unit you can set a
TimeoutStopSec in systemd override files for
it (either for all users or for a specific UID), but it isn't used
for very much and what you set for it doesn't affect your session
scope, which is where we need to get the timeout value set.
If you want to use a really blunt hammer you can set
/etc/systemd/logind.conf (or in a
However, this has one definite and one probable drawback. The
definite drawback is that this kneecaps
tmux, and any
other way of keeping processes running when you're not logged in,
unless you always remember to use the workarounds (and you realize
that you need them in each particular circumstance).
(I don't know what it does to things like web server CGIs run as
suexec or processes started under your UID as part of
delivering mail. Probably all of those processes count as part of
the relevant service.)
The probable drawback is that I suspect systemd does this process killing in the same way it does it for reboots, which means that the default 90 second timeout applies. So if you're logging in with processes that will linger, you log out, and then you immediately try to reboot the machine, you're still going to be waiting almost the entire timeout interval.