You can do it but I wouldn’t recommend it for your use-case.

Caching is nice but only if the data that you need is actually cached. In the real world, this is unfortunately not always the case:

1. Data that you haven’t used it for a while may be evicted. If you need something infrequently, it’ll be extremely slow.
2. The cache layer doesn’t know what is actually important to be cached and cannot make smart decisions; all it sees is IO operations on blocks. Therefore, not all data that is important to cache is actually cached. Block-level caching solutions may only store some data in the cache where they (with their extremely limited view) think it’s most beneficial. Bcache for instance skips the cache entirely if writing the data to the cache would be slower than the assumed speed of the backing storage and only caches IO operations below a certain size.

Having data that must be fast always stored on fast storage is the best.

Manually separating data that needs to be fast from data that doesn’t is almost always better than relying on dumb caching that cannot know what data is the most beneficial to put or keep in the cache.

This brings us to the question: What are those 900GiB you store on your 1TiB drive?

That would be quite a lot if you only used the machine for regular desktop purposes, so clearly you’re storing something else too.

You should look at that data and see what of it actually needs fast access speeds. If you store multimedia files (video, music, pictures etc.), those would be good candidates to instead store on a slower, more cost efficient storage medium.

You mentioned games which can be quite large these days. If you keep currently unplayed games around because you might play them again at some point in the future and don’t want to sit through a large download when that point comes, you could also simply create a new games library on the secondary drive and move currently not played but “cached” games into that library. If you need it accessible it’s right there immediately (albeit with slower loading times) and you can simply move the game back should you actively play it again.

You could even employ a hybrid approach where you carve out a small portion of your (then much emptier) fast storage to use for caching the slow storage. Just a few dozen GiB of SSD cache can make a huge difference in general HDD usability (e.g. browsing it) and 100-200G could accelerate a good bit of actual data too.

Is that built-in, or do you have to configure it yourself

It’s the official bang for Startpage. You can’t configure custom bangs in DDG; Kagi can do that.

I agree, which is why I’ve been happy to continue using DDG.

I’ve found DDG/bing’s results to be quite lacking.

If I can’t find something I can just add a quick !g to my already existing query and look it up on Google instead, which I’ve found rather convenient.

Yeah I used to do the same (but with !s).

It’s much more convenient to just have good search results to begin with though. Kagi uses the Google index and a few others and you have your own filtering and ranking on top.

In the beginning I felt tempted to do !s a few times too but the results were always worse, so I quickly unlearned doing that.

Executing bangs is also a lot quicker with Kagi; DDG is kind of a slog.

Chances are that it doesn’t work there either. What actually does the OC is the kernel; the GUIs merely write the desired values into the correct files in /sys.

Ecosia being any better in this regard would be news to me. They also rely on ads for funding.

Oh they’ve been getting worse for sure but Bing is still worse. I’ve used the Bing index via DuckDuckGo for years and it’s quite bad.

I now use Kagi which uses both Google and Bing indices (among others) and it’s much better and I think most of that is because the Google index is used.

Have you heard of peertube?

It’s slightly overkill for your purposes but it is basically a self-hosted Youtube with a similarly nice UI and everything.

Oh great, shitty bing search results with tree NFTs.

I missed that; OP is from a Lemmy instance indeed.

I think it’s the other way around then: those hashtags turn into actual hashtags when federated to the microblog fediverse. I verified this with mastodon. Only works in the title though because post bodies don’t get federated in Lemmy for some reason.

If you talk about “a GUI for systemd”, you obviously mean its most central and defining component which is the service manager. I’m going to assume you’re arguing in bad faith from here on out because I consider that to be glaringly obvious.

systemd-boot still has no connection to systemd the service manager. It doesn’t even run at the same time. Anything concerning it is part of the static system configuration, not runtime state.
udevd doesn’t interact with it in any significant user-relevant way either and it too is mostly static system configuration state.

journald would be an obvious thing that you would want integrated into a systemd GUI but even that could theoretically be optional. Though it’d still be useful without, it would diminish the usefulness of the systemd GUI significantly IMHO.
It’s also not disparate at all as it provides information on the same set of services that systemd manages and i.e. systemctl has journald integration too. You use the exact same identifiers.

It’s a microblog post. You can simply @ a Lemmy community and the very same post becomes a Lemmy post in that community too.

It’s quite useful to reach i.e. a niche audience and you shouldn’t make fun of people utilising the fediverse to its full extent.

If you wanted a distro where everything is set up for you OOTB, not requiring tinkering, you should not have installed Arch mate.

As mentioned, those are entirely separate and even independent components.

Systemd (as in: pid1) only “manages” them insofar as that it controls their running processes just like any other service on your system.

systemd-boot doesn’t interact with systemd at all; it’s not even a Linux program.

The reason these components have “systemd” in their name is that these components are maintained by the same people as part of the greater systemd project. They have no further relation to systemd pid1 (the service manager).

Whoever told you otherwise milead you and likely had an agenda or was transitively mislead by someone who does. Please don’t spread disinformation further.

Without knowing what you’ll use it for, neither.

Both don’t sound ideal though w.r.t. power consumption.

The OS is Android but “degoogled”, so no Google espionage services or play store etc. It’s quite nice actually.

I’m pretty sure you can flash the stock FP4 ROM too though.

All of those are entirely separate components; I have no idea what you’re attempting to imply here.

For anyone else reading along: This person is talking out of their ass.

That should be our new slogan:

NixOS: Your Emacs’ bootloader.

LACT and Mangohud can do that pretty well

This is a configuration declaration abstraction issue. Systemd timers and services are more like primitives.

In NixOS, we have an abstraction that allows simple declaration of a service and timer that runs some script.

As an example, I use this to export my paperless for backup daily in a way that is safe (paperless itself cannot run during that time, guaranteed by systemd) and simple:

https://github.com/Atemu/nixos-config/blob/ca0d39eb98c62424208487f973573478268048b4/modules/paperless/module.nix#L59-L95

(Even without NixOS domain knowledge you should be able to follow what’s going on here.)

All that’s needed in order to cause a systemd timer to be created for this service is to declare the startAt = "daily"; at the bottom.