Post observed.

I just booted up my copy and to remediate what I’m going out on a limb and assuming is the problem, you’d want to run level 3.

It reads and rewrites every block on the device which, if your slow ssd operations on boot are due to the ssd controller having to try to read a block a bunch of times in order to actually get the contents of the block and pass it down the bus, will speed up the ssd operations that reference frequently read blocks. Like the ones used during the decryption and boot process.

That wiki article is incredibly out of date. The reference for only using level 1 or 2 is from 2013.

E: also I like 4 because ssd endurance is not a big deal and ssds lowkey suck and need to be tested before I use em.

It’s sorted by length because you invoked the blame flag. The blame flag lists the output by start time.

Systemd is multithreaded so it’s not like all this stuff happens in sequence. If that were the case you’d have a computer that takes five minutes to boot.

The tpm is the thing that takes the longest because it has to check a bunch of shit. You can’t do anything about the tpm because you’re using it for encryption and measured boot.

You’re also looking at the wrong thing. Look at all the 3s sections where the system is fiddle fucking around with the ssd. Run spinrite lvl3 or 4 so all those sectors the ssd has to try to read 69000 times get rewritten and see if that doesn’t speed things up.

E: spinrite lvl3

It’s not possible to avoid llm use in volunteer open source development if you prioritize software quality and security.

Whether we want it or not, people looking for bugs are using llms. They are finding phenomenal numbers of bugs. Implementing the fixes has created a huge workload.

Whether we want it or not, the Wayland people have decided that a new, piecemeal system for graphical desktops that relies on many disparate implementations of protocols is what we will use going forward. This has created a tremendous workload because there are now many different channels through which bugs and updates must be handled.

In this situation a volunteer development community must rely on every work saving tool they can just to keep up. For the person in the trenches there is no alternative.

If you prioritize quality as measured by the extent to which your software supports the various Wayland doohickies or security as measured by active exploitable bugs, you have to use llms.

These conditions will eventually remove the structure of incentives for open source development.

None of the above is a value judgement.