I just noticed https://lemmy.ml/u/giloronfoo@beehaw.org had proposed the same, but here’s the same but with more words ;).

I would propose you try to split the data you have manually into logically separate parts, so that you could logically fit 0.8 TB on one drive, 0.4 TB on another, and maybe sets of 0.2TB+0.2TB on a third one. Then you’d have a script that uses traditional backup approaches with modern backup apps to back up the particular data set for the disk you have attached to the system. This approach will allow you to access painlessly modern “infinite increments” backups where you persist older versions of data without doing full and incremental backups separately. You should then write a script to ensure no important data is forgotten to be backed up and that there are no overlapping backups (except for data you want to back up twice?).

For example, you could have a physical drive with sticker “photos and music” on it to back up your ~/Photos and ~/Music.

At some point some of those splits might become too large to fit into its allocated storage, which would be additional manual maintenance. Apply foresight to avoid these situations :).

If that kind of separation is not possible, then I guess tar+multi volume splitting is one option, as suggested elsewhere.

By that logic, is the compositor working any different than a trojan? Is there really a difference?

The Wayland compositor is always capturing all your keyboard and mouse as well. No permissions asked. Pretty sus.

I have 64GB RAM and my 64GB swap still gets filled to 60% over time.

It just happens so that apps end up touching some memory once that they never then use again. Better use some SSD for that instead of RAM.

I suppose it explains why people have a bad attitude about Wayland when tools providing useful functionality are described as trojans.

X11 can (…mostly…) have great security by just providing a suitable X Security module to it. It just seems it wasn’t considered that big of an issue that anyone bothered. Nokia Maemo/Meego used to rock such a module.

It’s two commands to grow the / fs on the fly:

lvextend -L+10G /dev/mycomputer-vg/root
resize2fs /dev/mycomputer-vg/root

So don’t worry about it. LVM is great :).

It doesn’t actually detect moved code, though, like git diff can? I gave it a shot and also there’s a couple issues open about it, e.g. https://github.com/Wilfred/difftastic/issues/520 .

Other than that, difftastic is quite nice.

Welcome video game streaming?

I use etckeeper to autocommit changes in /etc as git just has better and faster tools to look at the changes of a fle, compared to backup tools.

It’s just so easy to do that there hardly is any point in not doing it.

I was under the impression cross-site cookies are a standard feature per the RFC, though? Or is Patreon using some kind of non-standard extension?

I rather enjoy Tilix. It can tile a single tab without tmux and it can also give special handling to links matched from regexps. I use it to go from Python stacktraces to correct line in Emacs with just a click. It can also do Quake-like terminal, which I use alot.

The project is looking for maintainers, though, so it’s possible at some point I need to start looking for alternatives…

Just keeping a single frame buffer image can take tens of megabytes nowadays, so 100MB isn’t all that much. Also 64-bit can easily double the memory consumption, given how pointer-happy the ELISP data structures can be (this is somewhat based on my assumptions, I don’t actually know the memory layouts of the different Emacs data structures ;)).

But I don’t truly know, though. If I start a terminal-only Emacs without any additional lisp code it takes “only” 59232 kilobytes of resident memory. Still more than I’d expect. I’d expect something like 2 MB. But I’ll survive.

It comes from the words “Eight Megs And Constantly Swapping”.

Yeah, the name hasn’t aged well…

^Zkill -9 %1 is the only way.

kill -9 -1 if that doesn’t work.

There is the DJVU format for this exact use case, but you’d need to convert them to, say, pdf for many use case. Its also a bit old and perhaps not maintained, soo…

HEIF and other modern video encoders (HEIF=H265) should fare a lot better than JPEG, though.