Yes, in supported apps / protocols. Koreader, for example, should have 2-way sync for eBooks, and Mihon has 2-way sync for Manga.

+1 for kavita. It also has a nice webreader ui.

• LLMs are a complete dead end when it comes to actual intelligence, understanding, or sentience
• constant fearmongering from decades of media makes you afraid of sentient AI. I think it’s important to recognize that. I’m willing to bet that if people would have grown up with, say, Iain Banks’ Culture instead of Terminator, the idea of sentient AI would be exciting. (Not a value judgement, just pointing it out.)

… are entirely possible, even if rarely the right choice.

Or a CLI with clap.

Curious what you are talking about. Multi-threaded sharing of memory for example is also easy with rust, it just doesn’t let you wrote and read at the same time, and so on.

Yeah. Once you get used to the (verbose, but by no means unergonomic!) syntax, you’ll probably never be happy with another language again. Job-wise, I am currently mostly using Go, and while also a nice language, I miss the confidence and security I took for granted with rust.

Not to mention just how goddamn expressive rust can be. Let bindings like if ok/err, else return? Assign from a match on Some(Ok(x))? Filter, map, and friends on any iterator? Oh my GOD the error handling with the question mark iterator? 100% confidence that if it compiles, no error, possible null value, or case is unhandled.

And all this WHILE giving you the amazing security benefits!

Ah, damn, caught me proselytizing again.

• if your skill is so great that you would never cause the kinds of bugs the rust compiler is designed to prevent, then it will never keep you from compiling, and therefore your complaint is unnecessary and you can happily use rust
• if you do encounter these error messages, then you are apparently not skilled enough to not use rust, and should use rust

In summary: use rust.

Nice, that’s great to hear!

Ah, nice. In that case just beware to move /var/lib/private/conduwuit to /var/lib/private/continuwuity, not /var/lib/conduwuit to its counterpart

Ah crap, forgot to ping you! Sorry!!

Yep, easy decision now. Migration went smoothly, just had to move the state dir and chown it to continuwuity:continuwuity. Might be different on docker though, no idea, sorry 😄

Update: seems to me tuwunel is drama waiting to happen. See updated post for details.

Yes, completely agree. It seems that the matrix foundation could easily take a different path to allow the community to flourish and third-party servers to have a much easier time. Since I’m not federated, I wouldn’t even mind if whatever fork I’ll end up on eventually says “fuck this, we’re not following synapse specs any more”.

But yeah, I am sure selling premium accounts on matrix.org is what will save the matrix ecosystem… 🤦🏼‍♀️

Understandable.

Hm, fair enough, I actually have very little experience with XMPP. (Only through prosody, which I personally am on a war footing with.) From a cursory glance, I also couldn’t find an Android lient I’d really want to use, but of course that is subjective.

In any case: I have a matrix server up and running, and it has been a pain to get friends and family on there; I do not want to do all of that again with a new protocol/clients. As long as it’s sustainable, I want to stay with the same server installation, and that means choosing a conduwuit for me.

There’s nothing technically wrong with it, it’s just a glacial development speed. I tried contributing there myself when I wanted a specific feature (which had been requested years prior by someone else and was deemed a good idea), it took months before I even got a single comment back.

In the meantime, I had switched to conduwuit because it was a much, MUCH more active project. However, conduwuit has diverged substantially from conduit, including irreconcilable database changes, so it is not possible to migrate back, that would require starting from a fresh slate and loosing all user data.

Understandable. Funny thing is, I’m not even federated; I think that keeps me away from a lot of drama.

But yeah. The drama sucks, and so does the Matrix Foundation. So many dumb decisions, so many years old issues that could easily boost acceptance and usability, but… Nah. No better alternatives around though if you want to own your data, have proper multi-client support, and at least the option to federate.

Nice, how’s it been going?

Roger, will do.

Yeah, community driven sounds like unless there’s new drama. But yeah, currently tending towards continuwuity. Purely vibes based from snooping around both repos.

We have NixOS, Proxmox and TrueNAS in use.

• TrueNAS on a dedicated NAS host. It’s great for that, and has been super stable. The snapshotting works great, and all the little tasks associated with a NAS are taken care of without needing to spare a thought.
• Proxmox as VMS host. You haven’t mentioned it above, so I’ll leave it at this: also works really well for its purpose.
• NixOS: acouple dozen NixOS VMs runnign on the Proxmox hosts. I like the separation (i.e.: one VM <-> one task/service), but it’s not necessary, esp. if you plan on using a stable branch. I absolutely love NixOS, and would never run server applications on anything else ever again. The documentation thing is trueish. There’s not even close to the same documentation as with e.g. Arch and the Arch Wiki, but that makes sense when you think about it: instead of hundreds of lines of documentation, you hide that complexity behind an option, e.g. graphics.nvidia.enable = true; which then becomes pretty self-explanatory, at least if you are somewhat familiar with the ecosystem already. The way I’d recommend going about documentation with nix is this:
  • go to search.nixos.org/options, search for the service you would like to host. 90% of the time, the options and descriptions shown are all you need.
  • if an option is unclear, click on its “declared in” link. You’ll be taken to the module source in nixpkgs. Look at what they are doing there/the comments explaining why. Often, this resolves any ambiguity, or helps you out with your goal.
  • if that did not help, check the NixOS wiki; often, common pitfalls are documented there, together with the nix expression to fix them.
  • another great way is to search GitHub for language:nix <thing you need to do>. As a random example: I recently wasn’t sure how to configuring scaling in hyprland on NixOS, but searching for an appropriate term will quickly show you how other people have solved the same problem. It’s not really documentation, but the declarative nature of nix means it’s easy to find TONS of working examples via a github search.
  • all else failing, ask on discourse.nixos.org. Youńll usually get useful help very quickly there.

So, what’s my advice?

If you are unfamiliar with NixOS, it’s probably a bit of a headache getting a NAS to run satisfactory. Truenas works so well, there isn’t really a need for nix. But running your services in nix is great, totally recommend!

Not sure, but they also support Borg, which definitely does.