I also have several virtual machines which take up about 100 GiB.

This would be the first thing I’d look into getting rid of.

Could these just be containers instead? What are they storing?

nix store (15 GiB)

How large is your (I assume home-manager) closure? If this is 2-3 generations worth, that sounds about right.

system libraries (/usr is 22.5 GiB).

That’s extremely large. Like, 2x of what you’d expect a typical system to have.

You should have a look at what’s using all that space using your system package manager.

EDIT: ncdu says I’ve stored 129.1 TiB lol

If you’re on btrfs and have a non-trivial subvolume setup, you can’t just let ncdu loose on the root subvolume. You need to take a more principled approach.

For assessing your actual working size, you need to ignore snapshots for instance as those are mostly the same extents as your “working set”.

You need to keep in mind that snapshots do themselves take up space too though, depending on how much you’ve deleted or written since taking the snapshot.

btdu is a great tool to analyse space usage of a non-trivial btrfs setup in a probabilistic fashion. It’s not available in many distros but you have Nix and we have it of course ;)

Snapshots are the #1 most likely cause for your space usage woes. Any space usage that you cannot explain using your working set is probably caused by them.

Also: Are you using transparent compression? IME it can reduce space usage of data that is similar to typical Nix store contents by about half.

You should worry about that in any case. The writing has been on the wall for quite some time now.

Google is only going to “respond” by doing things it’s explicitly ordered to comply with and of course extremely reluctantly; only doing the bare minimum that could be seen as complying.

They sure as hell aren’t going to open up the google surveillance services unless explicitly and specifically forced to do so by a court.

This is entirely untrue.

Any part that is already open source will eternally be open source.

Only in the state that it is right now. Google could at any point simply stop releasing the source code with no warning and make all further modifications proprietary.

there are rules about using open source code in projects that requires them to also be open source.

That is only true for copyleft licenses. Licenses that are merely “open source” (also called “permissive”) such as the Apache License 2.0 which the AOSP is licensed under do not give two hoots about what you do with the code as long as you give appropriate credit.

The only part of Android that has a copyleft license is the Linux kernel (GPLv2) and I wouldn’t really consider it part of the AOSP in practice.

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.

Basically what I wanted to ask is whether they’re taking this seriously and are doing demanding stuff or whether they’re just starting out with basic things. Also how important gaming vs. Unreal is to them; would they care if it took a bit longer to e.g. compile shaders if that meant 20% more fps?

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.

The Elipsa is, like almost all >8” screens, designed specifically to be an e-note rather than just an e-reader.

I don’t need that functionality but having it doesn’t hurt.

I’m done with uni but being able to take hand-written notes with a pen every now and then could be useful from time to time.

For that reason, I’m pretty sure it too lacks physical buttons.

I’ve actually looked into it and it appears you can turn pages by just tapping and even adjust where you touch to perform which action.

It’s not as good as a button but this would be fine by me.

What I don’t want is weird swiping gestures that don’t work half of the time. A tap OTOH should be simple enough to get right.

Image quality should be roughly as good as anything else out there.

Hm, I’d expect the image quality to be determined in part by firmware magic which would mean there’d still be differences.

I’ve seen a review since writing the previous message and it compared the screen side-by-side with a similarly-sized Amazon tablet and there were significant differences in contrast.

Apparently in 2022, kobo specifically ADDED the ability to use your device without logging in (https://blog.the-ebook-reader.com/2022/02/10/how-to-use-kobos-new-sideloaded-mode/), which is a move in the RIGHT direction for once.

Neat, that sounds like exactly what I want from the device.

Supernote

Will look into that.

I’m also aware of ReMarkable which I heard has a big hacking community around it. By chance, I actually spoke with someone who showed off theirs and how it’s just a plain Linux+systemd environment today. The GUI is just a plain old systemd service that runs the GUI binary and when they restarted it, the GUI restarted.

The biggest issue with these devices is that they really are made for writing rather than reading and are missing handy features such as a frontlight.

Not the above guy, but I’ll share my thoughts too.

Much appreciated :)

if you have an Android device with F-Droid

Yeah I think that’s how I heard of it ;)

Although it has a gorgeous 8" display, I found it to be somewhat unergonomic to hold, and it has a notoriously bad battery life.

I think battery life isn’t that important of a factor for me. As long as it’s in the range of “I need to charge it every once in a while” rather than “I need to make sure to charge this every day”, it’s probably fine.

Comfort is more important but hard to judge without actually holding it.

From what I’ve been told, 7" is about the size of an actual BW manga page.

From what I gather online, Manga is apparently printed on JIS B5 paper which is 257mm x 182mm which has a 12.4" diagonal but the small hand books Manga you typically see is B6 which is 128mm x 182mm (8.7" diagonal).

The diagonal isn’t really that meaningful though as the aspect ratio of JIS B paper and e-readers is different. A 10.3" reader with 4:3 aspect ratio is 157mm x 209mm and an 8" one 122mm x 163mm.

While 8" is almost wide enough for B6, it’s not nearly tall enough, even for B6. 10.3" is quite a bit larger than it needs to be for B6 and quite a bit smaller than B5 which sounds much more ideal.

I use the “fit to width” option, which makes the page fit the whole width of the screen (and display about two-thirds of the height of the page at any time); I end up pushing the “next” button twice for each page, but as I like to read slowly, I don’t mind at all.

Ah, that doesn’t fit my style unfortunately. Manga is also frequently laid out a way where some elements might be the entire page tall.

You don’t. It’s very easy to bypass the account registration on a new Kobo. You don’t even have to turn on the Wi-Fi.

Neat thanks, that’s what I’ll do then.

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.