TwilightKiddy

Have you actually read the thread? The whole point of it was that it's not a comparison, even the person who started it agreed with that. Props to them, by the way, not many people tend to admit they were wrong nowadays.

I'm all ears for your "debunking", love. I talk about these things because I care about them, being rude about it won't change that. If anything, it makes me want to talk about it more.

There is another reply to this comment where I said I'm not using it. If you are interested in something specific why not just go type the package name into their repository search thingy?

https://search.nixos.org/packages

If your script somehow shuts them down faster than plain old SIGTERM, putting it under /usr/lib/systemd/system-shutdown/ might be a good idea. Check man 8 systemd-shutdown for more info on that.

Individual services can override the default 90 seconds timeout. But then you can override their override if you think you are smarter, of course.

I entrust you with this horror, go figure out what to blame.

#! /usr/bin/env bash
shutdown_start=$(journalctl -b -1 -u systemd-logind --grep="System is (powering down|rebooting)" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP)
shutdown_start=$((shutdown_start / 1000000))
units=$(journalctl -b -1 --since=@$shutdown_start --output=cat --no-pager --output-fields=UNIT JOB_TYPE=stop CODE_FUNC=job_emit_start_message)

for u in $units; do
    stopping_start=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_start_message _SYSTEMD_UNIT=init.scope)
    stopping_end=$(journalctl -b -1 --since=@$shutdown_start -u "$u" --output=cat --no-pager --output-fields=_SOURCE_REALTIME_TIMESTAMP JOB_TYPE=stop CODE_FUNC=job_emit_done_message _SYSTEMD_UNIT=init.scope)
    duration_human=$(systemd-analyze timespan $((stopping_end - stopping_start))us | tail -1 | sed 's/.*: //')
    printf "%s\t%10s %s\n" $((stopping_end - stopping_start)) "$duration_human" "$u"
done | sort -rn | cut -f 2

Speaking about Gentoo, you don't "have to" compile everything, but let's just say it's strongly encouraged. Most of the compilation is automated though, think AUR on steroids. If you don't want to touch anything, you can go with defaults for all the software and you'll get basically what you get on any other distro.

The thing is, though, if you are not being a little funny with your software, why the hell are you running Gentoo? So, it's entirely optional, but it's the main reason one would use Gentoo, otherwise you get a stock standard system with stupidly long updates.

I can't speak for Nix, though, I haven't touched it myself, but from what I know from those around me running it, it's pretty much the same thing, unless you want something cool, you don't have to suffer.

At least it tells you how long it'll take before it decides to SIGKILL whatever is holding the shutdown sequence.

It's pretty much the same thing as everywhere, you have a bunch of lovely people who package and test things, nothing too weird. What you are describing is LFS.

Precisely the reason why I'm not using Fcitx, on a touchscreen there is nothing better than flick input for Japanese.

I've been using it for a while, haven't noticed the candidate box margins being weird until you mentioned it.

You can make the font for the candidate box larger to fill the unoccupied space, but that sounds like a bad solution.

It's developer opened an issue for improving that part of the keyboard not that long ago, probably there is something in the works. You may want to voice your concerns there.

angry Gentoo and NixOS noises