• 0 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: February 10th, 2024

help-circle
  • The command you’re looking for is btrfs send. See man btrfs-send.

    I know of at least one tool, btrbk, which automates both automatic periodic snapshots and incremental sync, but here’s an example manual process so you can know the basic idea. Run all this in a root shell or sudo.

    As initial setup:

    • Create a btrfs filesystem on the sender drive and another on the receiver drive. No need to link them or sync anything yet, although the receiver’s filesystem does need to be large enough to actually accept your syncs.
    • Use btrfs subvolume create /mnt/mybtrfs/stuff on the sender, substituting the actual mount point of your btrfs filesystem and the name you want to use for a subvolume under it.
    • Put all the data you care about inside that subvolume. You can mount the filesystem with a mount option like -o subvol=stuff if you want to treat the subvolume as its own separate mount from its parent.
    • Make a snapshot of that subvolume. Name it whatever you want, but something simple and consistent is probably best. Something like mkdir /mnt/mybtrfs/snapshots; btrfs subvolume snapshot /mnt/mybtrfs/stuff /mnt/mybtrfs/snapshots/stuff-20250511.
    • If the receiver is a separate computer, make sure it’s booted up and running an SSH server. If you’re sending to another drive on the same system, make sure it’s connected and mounted.
    • Send/copy the entire contents of the snapshot with a command like btrfs send /mnt/mybtrfs/snapshots/stuff-20250511 | btrfs receive /mnt/backup. You can run btrfs receive through SSH if the receiver is a separate system.

    For incremental syncs after that:

    • Make another separate snapshot and make sure not to delete or erase the previous one: btrfs subvolume snapshot /mnt/mybtrfs/stuff /mnt/mybtrfs/snapshots/stuff-20250518.
    • Use another send command, this time using the -p option to specify a subvolume of the last successful sync to make it incremental. btrfs send -p /mnt/mybtrfs/snapshots/stuff-20250511 /mnt/mybtrfs/snapshots/stuff-20250518 | btrfs receive /mnt/backup.

    If you want to script a process like this, make sure the receiver stores the name of the latest synced snapshot somewhere only after the receive completes successfully, so that you aren’t trying to do incremental syncs based on a parent that didn’t finish syncing.


  • zarenki@lemmy.mltoLinux@lemmy.mlThis looks cool but can it game?
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    15 days ago

    “Dynamically compiled” and dynamic linking are very different things, and in turn dynamic linking is completely different from system calls and inter-process communication. I’m no emulation expert but I’m pretty sure you can’t just swap out a dynamically linked library for a different architecture’s build for it at link time and expect the ABI to somehow work out, unless you only do this with a small few manually vetted libraries where you can clean up the ABI. Calling into drivers or communicating with other processes that run as the native architecture is generally fine, at least.

    I don’t know how much Asahi makes use of the capability (if at all), but Apple’s M series processors add special architecture extensions that makes x86 emulation be able to perform much better than on any other ARM system.

    I wouldn’t deny that you can get a lot of things playable enough, but this is very much not hardware you get for the purpose of gaming: getting a CPU and motherboard combo that costs $1440 (64-core 2.2GHz) or $2350 (128-core 2.6GHz) that performs substantially worse at most games than a $300 Ryzen CPU+motherboard combo (and has GPU compatibility quirks to boot) will be very disappointing if that’s what you want it for. Though the same could to a lesser extent be said even about x86 workstations that prioritize core count like Xeon/Epyc/Threadripper. For compiling code, running automated tests, and other highly threaded workloads, this hardware is quite a treat.


  • With one of these Altra CPUs (Q64-22), I can compile the Linux kernel (defconfig aarch64 with modules on GCC 15.1) in 3m8s with -j64. Really great for compiling, and much lower power draw than any x86 system with a comparable core count. Idles at 68W full system power, pulls 130W when all cores are under full load. Pulling out some of my 4 RAM sticks can drive that down a lot more than you’d expect for just RAM. lm_sensors claims the “CPU Power” is 16W and 56W in those two situations.

    Should be awful for gaming. It’s possible to run x86 things with emulation, sure, but performance (especially single-thread) suffers a lot. I run a few containers where the performance hit really doesn’t matter through qemu.

    Ampere has a weird PCIe bug that results in either outright incompatibility or a video output filled with strange artifacts/distortion for the vast majority of GPUs, with the known good selection that aren’t bugged being only a few select Nvidia ones. I don’t happen to have any of those Nvidia cards but this workstation includes one. Other non-GPU PCIe things like NICs, NVMe, and SAS storage controllers work great, with tons of PCIe lanes.


  • Depends on what you consider self-hosted. Web applications I use over LAN include Home Assistant, NextRSS, Syncthing, cockpit-machines (VM host), and media stuff (Jellyfin, Kavita, etc). Without web UI, I also run servers for NFS, SMB, and Joplin sync. Nothing but a Wireguard VPN is public-facing; I generally only use it for SSH and file transfer but can access anything else through it.

    I’ve had NextCloud running for a year or two but honestly don’t see much point and will probably uninstall it.

    I’ve been planning to someday also try out Immich (photo sync), Radicale (calendar), ntfy.sh, paperless-ngx, ArchiveBox (web archive), Tube Archivist (YouTube archive), and Frigate NVR.


  • The 6-month release cycle makes the most sense to me on desktop. Except during the times I choose to tinker with it at my own whim, I want my OS to stay out of my way and not feel like something I have to maintain and keep up with, so rolling (Arch, Tumbleweed) is too often. Wanting to use modern hardware and the current version of my DE makes a 2-year update cycle (Debian, Rocky) feel too slow.

    That leaves Ubuntu, Fedora, and derivatives of both. I hate Snap and Ubuntu has been pushing it more and more in recent years, plus having packages that more closely resemble their upstream project is nice, so I use Fedora. I also like the way Fedora has rolling kernel updates but fixed release for most userspace, like the best of both worlds.

    I use Debian stable on my home server. Slower update cycle makes a lot more sense there than on desktop.

    For work and other purposes, I sometimes touch Ubuntu, RHEL, Arch, Fedora Atomic, and others, but I generally only use each when I need to.


  • zarenki@lemmy.mltoTechnology@lemmy.worldBuy Once Software
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 months ago

    Just go through F-Droid or Flathub and look at the long list of apps that haven’t been updated in years.

    “not updated in years” didn’t used to be considered a bad thing. Why is it one now?

    If something works well for me as it is and runs locally in a way that doesn’t open itself up to remote exploits, I don’t necessarily need it to keep changing all the time. Even if it would be nice if it had more features, the software works fine for me as it is. I don’t need those updates now or this year.

    The only true “need” is that it doesn’t stop working for me when the various platforms or compilers change. I used to use a Python2 program, and I could keep using it for about a decade after its last update, but eventually I did need to move past it because Python3 had long since replaced it and distros stopped shipping Python2. A year or two of no updates it’s nothing.


  • If the only problem is that you can’t use dynamic linking (or otherwise make relinking possible), you still can legally use LGPL libraries. As long as you license the project using that library as GPL or LGPL as well.

    However, those platforms tend to be a problem for GPL in other ways. GPL has long been known to conflict with Apple’s App Store and similar services, for example, because the GPL forbids imposing extra limits that restrict user freedom and those stores have a terms of service that does exactly that.



  • If it was a community addition why would it matter? And why would they remove the codecs.

    You don’t have to be a corporation to be held liable for legal issues with hosting codecs. Just need to be big enough for lawyers to see you as an attractive target and in a country where codec patent issues apply. There’s a very good reason why the servers for deb-multimedia (Debian’s multimedia repo), RPM Fusion (Fedora’s multimedia repo), VLC’s site, and others are all hosted in France and do not offer US-based mirrors. France is a safe haven for foss media codecs because its law does not consider software patentable, unlike the US and even most other EU nations.

    Fedora’s main repos are hosted in the US. Even if they weren’t, the ability for any normal user around the world to host and use mirrors is a very important part of an open community-friendly distro, and the existence of patented codecs in that repo would open any mirrors up to liability. Debian has the same exact issue, and both distros settled on the same solution: point users to a separate repo that is hosted in France which contains extra packages for patent-encumbered codecs.


  • I stopped using Arch a long time ago for this same reason. Either Fedora (or derivatives like Nobara) or an atomic/immutable distro (like Bazzite, Silverblue, Kinoite) is probably the way to go.

    I used to feel like Ubuntu was a good option for this, but it no longer is: too often they try to push undesirable changes that need manual tweaking to fix after release upgrades. Debian Stable is generally good for low-maintenance use but doesn’t keep up as well with newer hardware or newer updates to video drivers and mesa, which makes it suboptimal for typical gaming use. Debian Testing can be prone to break things in updates (in my experience, worse than Arch does).

    I saw another comment recommend Rocky/RHEL, but note that their kernel doesn’t support btrfs. Since you mentioned a root snapshot, I expect you probably use it.


  • I was only talking about high core count and high (relatively speaking) single-core performance. The DeepComputing Framework board is neither. Its JH7110 is only 4 cores and a rather old processor, which seems like an odd choice for a product releasing in 2025. At least the software support is great since distros have been working with VisionFive 2 and Milk-V Mars for years.

    It’s also the only currently-available Framework 13 board with fewer than 6 cores, though core count isn’t remotely comparable between architectures. At this price ($209 for lone board with 8GB RAM, $799 for full laptop) I’d prefer to see something at the very least comparable to SpacemiT K1, which has 8 cores and vector support, and is on the Banana Pi BPI-F3 (8GB version is $95).


  • I’m only aware of one RISC-V system where I can say the core count is there: the Milk-V Pioneer board and its 64-core SG2042 processor from two years ago. It’s comparable in price to a 64-core ARM Ampere CPU+motherboard (USD$1500 for the board), which seems somewhat reasonable when not considering the performance of each core. Hopefully the C930 core described in this article leads to more systems that aim for multi-core performance.

    Most RISC-V development boards are only 4 cores or fewer, with just a few popping up in the last year with 8 cores and nothing higher besides the SG2042. The best single-core RISC-V performance so far is on the SiFive P550 but it’s only 4 cores and comes on a development board that costs USD$500 (plus another $150 for tariffs if shipping to the US). You could easily get a 12-core AMD CPU and motherboard combo for less than that.




  • Unfortunately, DMCA takes an extreme stance when it comes to anti-circumvention. Even personal backup doesn’t have a strong legitimacy case under it, especially not when it comes to the tools that enable it.

    Very related to this, LockpickRCM is a tool whose entire purpose is to extract your own Switch keys for the titles you own, and in turn is far more useful for people who want personal backups than those who are pirating the games. Still got a DMCA takedown two years ago, and though it never went to court it’s extremely unlikely any court would have ruled in their favor if it did.