fwiw, I used Kopia for around a year, but eventually the backup got corrupted with a BLOB not found error and there was no way to fix it.

similar to this issue, except that nothing would fix or improve the situation https://github.com/kopia/kopia/issues/1087

and because it seemed to be an issue with the repo (not just with a snapshot), the remote copy was also borked. I couldn’t even list the snapshots.

I’ve since migrated to Rustic (though Restic might be more reliable today).

This seems to be the a similar issue too, but I was nowhere near the scale of this user. There are other similar reports that may or may not be linked to the same root cause, so it’s hard to say how rare this problem is.

deleted by creator

Isn’t that creating hardlinks between source and dest? Hard links only work on the same drive. And I’m not sure how that gives you “time travel”, as in, browsing snapshots or file states at the different times you ran rsync.

Edit: ah the hard link is between dest and the link-dest argument, makes more sense.

I wouldn’t bundle fs and backup compression in the same bucket, because they have vastly different reqs. Backup compression doesn’t need to be optimized for fast decompression.

yeah, more often than not I notice the bottleneck being the storage drive itself, not rsync.

yeah, it doesn’t, it’s just for file transfer. It’s only useful if transferring files somewhere else counts as a backup for you.

To me, the file transfer is just a small component of a backup tool.

It works fine, my issue with it it’s just not efficient. If you want a “time travel” feature, your only option is to duplicate data. Differential backups, compression, and encryption for off-site ones is where other tools shine.

I tried portainer for a while, but it was almost useless to me, as I’d always end up in the command line anyway. So I dropped that and any other dashboard idea.

Yeah, I have everything as compose.yaml stacks and those stacks + their config files are in a git repo.

it might be worth watching this PR for memos, which adds encryption at rest. I can’t vouch for it, as I didn’t read the code but I do use memos and might consider this if it’s merged.

https://github.com/usememos/memos/pull/5130

This is not E2EE, but I don’t think E2EE is that important if you’re hosting your own data. And clients can use TLS for encryption in transit.

How can you say it’s saturated when chrome has an effective monopoly. If you look at browser engines, there’s basically only 3 for desktop, with one of them targeting only Macs.

yeah, screw that, I only get frustrated and/or angry. And even if I have the patience to eventually I beat it, it’s just not worth it.

I also have no idea if my place has PVC or galvanized steel plumbing; or its designed electrical load. Why should users care about the DBMS.

There are valid reasons for not wanting the whole database e.g. storage constraints, compatibility with ETL pipelines, and incorporating article updates.

What bothers me is that they – apparently – crawl instead of just… using the API, like:

https://en.wikipedia.org/w/api.php?action=parse&format=json&page=Lemmy_(social_network)&formatversion=2

I’m guessing they just crawl the whole web and don’t bother to add a special case to turn Wikipedia URLs into their API versions.

Disagree. When it’s inherited, the gray value is not applied, because it’s defined somewhere else. It’s not a default in this case.

… the default might change…

That’s getting into application state management and heavily dependent on what kind of form it is.

What I wrote above reflects what web forms usually follow, and they don’t use faded values for defaults, because in the context of a form, defaults are just values that were pre-populated and get no special styling.

Those TrueNAS fields seem gray because they’re disabled (since it’s inherited), not because those are defaults.

For the web, there’s no reason to make them faded out / grey if they’re default values.

Those fields can just be pre-populated with those default values, which is unambiguous and get sent with the other user-edited fields.

Fading text either means placeholder (does not impact the value attribute) or disabled (locked / read-only)

Otherwise, defaults belong to labels, not in the input text.

That looks like a placeholder text, which is everywhere in forms and very much not the default. Like “John Smith” on name fields, you’re expected to enter your value.

For those using it on Android, a reminder that the older app is not maintained anymore and you might want to replace it with Catfriend1/syncthing-android.

But also - maybe wait for the app v2.0 to be released to upgrade the desktop client at the same time; I don’t know if using v2.0 on the desktop would work with the v1.x app.

So?