vole

The first thing is to do is to understand what you're looking at. Read this:

systemd-analyze blame¶

This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame does not display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the time units spent in "activating" state, which is not defined for units such as device units that transition directly from "inactive" to "active". This command hence gives an impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.

For example: I have passphrase disk encryption (no TPM encryption), and the time I take to enter the passphrase is added to many entries in systemd-analyze blame. Here is the output of systemd-analyze blame if I wait 2 minutes to enter my disk encryption passphrase:

2min 12.640s sys-module-fuse.device
2min 12.618s sys-devices-platform-MSFT0101:00-tpm-tpm0.device
2min 12.618s dev-tpm0.device
2min 12.551s dev-ttyS0.device
2min 12.551s sys-devices-pnp0-00:00-00:00:0-00:00:0.0-tty-ttyS0.device
2min 12.550s dev-ttyS2.device
...

So, I guess my advice is that systemd-analyze blame is not always going to be a clear indicator that a particular service is holding your boot times back. The .device entries in particular probably just represent how long after boot that the device became active. And unfortunately the systemd-analyze tools do not always lead you to the underlying delay.

$ systemd-analyze critical-chain dev-tpm0.device
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dev-tpm0.device +2min 12.618s

$ systemd-analyze critical-chain dracut-initqueue.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

dracut-initqueue.service +2min 11.123s
└─systemd-udev-trigger.service @770ms +158ms
  └─systemd-udevd-varlink.socket @760ms +65us
    └─system.slice
      └─-.slice

If you are trying to deal with an issue that is causing significant delays in your boot time, journalctl --boot can sometimes be helpful. For the example boot above where I waited 2 minutes before entering the disk encryption passphrase:

Jul 31 14:09:39 mycomputer kernel: Linux version 7.1.5-201.fc44.x86_64 (mockbuild@9b86e96a386140128351588d751166fd) (gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2), GNU ld versi>
... (a lot of log lines within a few seconds, but then I find a big jump) ...
Jul 31 14:09:44 mycomputer kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
Jul 31 14:11:48 mycomputer systemd-cryptsetup[551]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/...
... (and then there are a lot of log lines in the following seconds after the above line) ...

I use the streaming services' built in tracking to keep track of what episode I'm on. I use animeschedule.net for following weekly releases of airing shows. I use MAL to record when I start watching, stopped watching, rating, and tracking "plan to watch".

Daemons is like a good rendition of a forgettable 2000's shounen battle anime. It might shine compared against Shaman King and Zatch Bell (I was so young when I watched these, I don't remember if they're actually good), but it's hard to think much of Daemons once you've seen battle shounen done well (Jojo, FMA, HxH). I was watching the series as it aired, and I dropped off after episode 12 (I think because there was a short break). I will continue to watch it, but it doesn't pop out as a show to watch even though episode 12 ended with a cliffhanger.

It could be a slow burn, but perhaps too slow. From a recent MAL thread on the manga:

Is the manga anywhere near completion?

No way. We’re still on setup arcs. We don’t even know who the main antagonists are yet.

With most Linux OS's you have a choice of what desktop environment to use. The desktop environment controls most of what I would call the OS experience. Most linux distros will have KDE or Gnome installed as the default desktop environment, though there are often some more minimal or power-user focused desktop environments offered. I've heard Cinnamon is another good choice.

Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-F, F3, F11 generally behave the same on most Linux desktop environment and software as they do on Windows.

Alt-Tab, Alt-F4 are commonly supported

For the run menu, Alt-F2 opens a similar menu in KDE and Gnome. I can only go into the specifics with KDE, but I can also run commands with the regular Windows key start menu. Though when I personally run commands, I generally open a terminal (Ctrl-Alt-T) so I can get tab completion. On KDE, Win+E opens a file explorer. Almost all the keyboard shortcuts are customizable on KDE, but I prefer to swim with the current whenever possible.

For some distros, you can write a "Live" version to a flash drive to try it out before installing, but opening applications will be slower than running on an SSD.

Make sure to catch the mid-ending-credits scene. Other than that this episode is about what one would expect, and it gives a descent indication on where this story is going.

Ubuntu used to have an option for that and the screen shot from the site looks quite a bit like the old Ubuntu installer.

Oh, right you are. https://help.ubuntu.com/community/Wubi

It even has a wikipedia page! https://en.wikipedia.org/wiki/Wubi_(software)

From the documentation site you linked, Q4OS doesn't run inside Windows. The Q4OS installer runs inside Windows, and it stores the root filesystem for Q4OS as a file inside an existing Windows drive partition. I'm not personally aware of other Linux OS's that do either of these things, nor do I particularly desire a Linux OS that does either of these things. I can see it being useful if you want to keep your Windows installation fully intact. I imagine disk I/O performance takes a small hit.

That was a lame place to end the season, unless the next season picks up again in a few months. Overall I had a nice time with this show.

https://bsky.social/about/blog/03-19-2026-series-b

I didn't know this about bluesky D:, but it makes sense. Thanks for the heads up. The atproto ecosystem seems to have cool features for user empowerment and it seems to work well on the few occasions I've visited atproto sites. I hope they can find an ethical way to persevere, but I can't imagine that being easy.

Venture capital funding. The plan is always to do a rug pull. Though if it properly freely licensed and the code is reasonable enough to be forked, it's less worrying but still risky. It's better to work with honest people.

Completely sealing off every good route for the heroine. 😏

Well now I'm properly excited for this series.