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) ...

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.

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.

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.

A developer submitted a PR code change for systemd userdb.

My proposals (that’s really what PRs are) are to implement a solution that meets the regulatory requirements in several jurisdictions by providing a way to store a self-reported birthdate locally on the machine. These laws also require that this date is collected during account creation (hence why I made PRs against installers) and you can enter any value here, even January 1st, 1900. There is no proof required, no ID scanning, and no external tracking. Nor do I have any desire for that to ever change.

Apparently the developer is confirmed to be just a regular guy. He thinks it’d be worse if every desktop environment implements their own solution to comply with these laws. He’s against the various laws related to this incident.

As a fallout for submitting this pull request, he has been extensively harassed. His personal information being repeatedly posted online; his information used to sign up to a lot of sites, groups, churches, car dealerships, ordering food for him; threats of murder; regular textual harassment.