I think it’s worth giving the ycombinator post a read.

Any reason why you can’t buy a 2TB SSD and have both a 1TB and 2TB? I have another comment on this thread outlining the complexities of caching on Linux.

L2ARC is not a read cache in the conventional sense, but something closer to swap for disks only. It is only effective if your ARC hit rate is really low from memory constraints, although I’m not sure how things stack up now with persistent L2ARC. ZFS does have special allocation devices, though, where metadata and optionally small blocks of data (which HDDs struggle with) can go, but you can lose data if these devices fail. There’s also the SLOG, where sync writes can go. It’s often useful to use something like optane drives for it.

Personally, I’d just keep separate drives. A lot of caching methods are afterthoughts (bcache is not really maintained as Kent is now working on bcachefs) or, like ZFS, are really complex are not true readback/writeback caches. In particular, LVM cache can, depending on its configuration, lead to data loss if a cache device is lost, and LVM itself can occur some overhead.

Flash is cheap. A 2TB NVMe drive is now roughly the cost of 2 AAA games (which is sad, really). OP should just buy a new drive.

Not all docker containers contain a shell binary.. You can still propose an issue to moby, the upstream of docker, though.

Yes, probably. It is possible to flash and use dasharo (a downstream fork of coreboot) onto a modern MSI Z790A motherboard, which gets you pcie gen 5, 14th gen intel, and so on. I’m not sure if the necessary code to get it running has been upstreamed into coreboot yet. https://docs.dasharo.com/unified/msi/overview/

From there, you can use corna’s me_cleaner to disable (and clean) the management engine. There are reports of it working on alder lake: https://docs.dasharo.com/unified/msi/overview/

Here’s a full tutorial on disabling your ME on modern systems: https://github.com/mostav02/Remove_IntelME_FPT?tab=readme-ov-file#neutralizing-me-and-flashing-via-fpt

To be honest, though, I wouldn’t bother unless you’re doing it for fun. I’m not sure if this entire process necessarily works on the Z790+14th gen intel anyway.

To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go:

https://github.com/flathub

https://docs.flatpak.org/en/latest/hosting-a-repository.html

Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…

https://github.com/flathub/flathub/issues/813

It’s a good thing for the owners of the codebase, but often, a bad thing for the community (even if the community contributes to said codebase).

For example, FOSS maintainers sometimes will (want to) relicense to protect their income stream:

https://github.com/CaffeineMC/sodium-fabric/issues/2400

https://github.com/LizardByte/Sunshine/pull/150

While corporations might literally have maintainers sign away their rights so they can take the work from their own community:

https://lwn.net/Articles/937369/ (canonical requires a CLA, though this + the subsequent re-license might have happened anyway)

https://lwn.net/Articles/935592/ (RPM spec files are MIT licensed at the Fedora level. There are likely chnages to RPM files contributed by the community that are now source-restricted in RHEL)

https://networkbuilders.intel.com/docs/networkbuilders/accelerate-snort-performance-with-hyperscan-and-intel-xeon-processors-on-public-clouds-1680176363.pdf (See section 2.2. Previously, this work was BSD)

Mixed bag, really.

If a new user installs malware from flathub while trying out mint for the first time, they’ll probably blame mint instead of flathub. Nobody will say “damn, I should have listened to that warning” while their “discrod” app rm -rf’s their entire PC away, they’ll instead claim Linux is crap and go somewhere else. Doing this helps keep mint safe, and definitely encourages unverified FOSS apps to hurry up and get verified.

I used to be a Kagi subscriber because I believed in their image for Orion. Their strong views on privacy, imo, directly conflict with their action to keep the product closed source “because it’d slow them down”, so I ended up unsubscribing. Good to see I unsubbed just in time.