• 1 Post
  • 13 Comments
Joined 2 years ago
cake
Cake day: August 10th, 2023

help-circle
  • I’m pretty sure it’s possible to use timeshift to create backups on another drive using rsync (instead of btrfs). They are incremental, and deduplicated, as well.

    But the other commenters are correct, timeshift is not a backup tool, it’s more for snapshots to undo system changes you may not want. In addition to that, it doesn’t do user files by default — because again, it’s not a backup tool.

    btrfs send/receive technically does what you want, using btrfs to do backups to another drive, but I don’t think any GUI app supports it. Plus, you would have to create snapshots for btrfs from the command line.

    Your best bet are apps explicitly designed for this usecase, like someone mentioned pika, or borg or restic are good choices. They don’t do BTRFS, but they do incremental, deduplicated updates in a user friendly way.





  • Should be awful for gaming. It’s possible to run x86 things with emulation, sure, but performance (especially single-thread)

    Most modern software (games excluded), is dynamically compiled. This means that it’s not all one “bundle” that runs, but rather a binary that calls reusable pieces of code, “libraries” from the binary itself. Wine is dynamically compiled.

    What makes modern x86 to arm translators special, is that the x86 binary, like an x86 version of wine, can call upon the arm versions of the libraries it uses ­— like graphic drivers. It’s because of this that the people on r/emulationonandroid managed to play GTA 5 with 30 fps via the computer version. There definitely is overhead, but it’s not that much, and a beefy machine like this could absolutely handle it.

    https://moonpiedumplings.github.io/blog/scale-22/#exhibition-hall

    The Facebook/Meta table had a booth where they had an ARM macbook that was running steam and they were installing games on it.


  • ut I honestly doubt ARM can with the overhead of emulation

    Most modern software (games excluded), is dynamically compiled. This means that it’s not all one “bundle” that runs, but rather a binary that calls reusable pieces of code, “libraries” from the binary itself. Wine is dynamically compiled.

    What makes modern x86 to arm translators special, is that the x86 binary, like an x86 version of wine, can call upon the arm versions of the libraries it uses ­— like graphic drivers. It’s because of this that the people on r/emulationonandroid managed to play GTA 5 with 30 fps via the computer version. There definitely is overhead, but it’s not that much, and a beefy machine like this could absolutely handle it.

    https://moonpiedumplings.github.io/blog/scale-22/#exhibition-hall

    The Facebook/Meta table had a booth where they had an ARM macbook that was running steam and they were installing games on it.






  • Right, but you could have just made one yourself

    And then there would be a bus factor of one. It’s not just about making a helm chart for myself, it’s about having something that can be shared with the community, that doesn’t depend on any single person to be maintained and updated.

    It’s about having an organization that provides “packages” for Kubernetes, for people/orgs that don’t have the time, expertise, and energy to maintain them.

    I greatly respect Ananace, who is in the comments of this post, and mentioned their Helm charts. The work is excellent. But looking through the commits, it’s just one person, doing something that primarily consists of bumping version numbers. Contrast this to the Matrix ESS helm chart, where the commits consist of many more contributors, and also include feature additions to the helm chart.


  • Hello Ananace! :)

    I actually have seen your helm charts many, many times before when searching for matrix, synapse, or lemmy on Artifacthub.

    An official helm chart isn’t really a hard requirement to me, even if I were to use one and it were to stop getting maintained, I could continue on my own. But an official helm chart has big community benefits that are very important to me. Like, there becomes the option of paid support, which is a must have for many entities. Also, an official organization may support a wider variety of usecases than someone making helm charts for personal use.

    I also ended up chatting with one of the core devs of Synapse about ways to improve regular Python Synapse for use with Kubernetes back in the ending of January, so hopefully it’ll improve in that direction when time allows

    Do you know anything about the claims that they have rewritten synapse in rust?


  • This helm chart is not just matrix/synapse, but also element (web ui), and “matrix authentication service”, which adds SSO/OIDC support to a normal synapse instance, which is pretty neat. I haven’t seen any helm charts that include the full matrix stack, just separate synapse or element helm charts. And helm definitely makes deploying services to Kubernetes easier than other ways of deploying applications.

    The other reason why I like an official helm chart, is because I have seen unofficial one’s be stopped being maintained by the community member(s) maintaining them. With an official one, it will (probably) be maintained indefinitely.