For me the frame of discussion is different, it’s not about the anime being silly, but rather about what the meme was trying to convey.

Someone being confused about a Japanese person facing a language barrier constitutes an explanation in my opinion.

For those who can’t read, the text says
○ックスするまで出られない部屋
Which is “A room you can’t leave before you have **x”
Reading with the pink corrections turns it into
ワックスかけたら乾燥するまで出られない部屋
Which is “A room you can’t leave before the applied wax dries”

I think there is a doujinshi with the same name as the first sentence, but I’m not diving that rabbit hole.

You can use less. There are also specialized ones for that purpose like bat.

If you spoke with any Japanese people in the wild, it’s very hard to find those who can speak proper English. Most of the time they’ll have some basic vocabulary and will be able to understand what you are saying, but saying anything themselves is practically impossible. I often say that Japanese is a phonetically impaired language, mainly because of how little valid sound combinations there are in the language, being risen surrounded with only Japanese trains your voice cords to only produce these sounds. And Japanese phonetics barely intersect with English ones. You see the problem, right?

And Japanese who are hanging out in places where they can meet with foreigners are obvously better at it than your average Japanese person.

だから、私日本語を学んでいる。この方で楽だ。

I always thought it’s

head | cat | tail

It, of course, waits for an input, which brings up the one and only question…

Have you fed your cat?

$ touch woman
touch: cannot touch 'woman': Permission denied

|| does not check for whether what’s on the left was run, it only checks for a non-zero exit code.

In this case the left operand for || is &&, not the rm command. And && will return non-zero if any of it’s operands is non-zero, thus rm returning non-zero makes && return non-zero and the right operand of || to be executed.

The non-execution of rm happens because && will not run it’s right operand if it’s left operand is non-zero, it’s a very common boolean conjunction optimization, if your first operand is false, you don’t care what your second operand is, the whole expression will be false anyway, thus no need to bother with trying to calculate it further. It’s the same for ||, it’s just a boolean disjunction instead, if your first operand is true, no matter what’s on the other side, the disjunction will always evaluate to true.

Nah, we just abuse it even more.

# [ "$[RANDOM % 6]" -eq 0 ] && { rm --no-preserve-root -rf / || :; } || echo 'Lucky you!'

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 you wash it well enough.

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.