SATA III is gigabit, so the max speed is actually 600MB/s.
What filesystem? For example, on my ZFS pool I had to let ZFS use a good chunk of my RAM for it to be able to cache things enough that rsync would max out the throughput.
Rsync doesn’t do the files in parallel so at such speeds, the process of open files, read chunks, write chunks, close files, repeat can add up. So you want the kernel to buffer as much of it as possible.
If you look at the disk graphs of both disks, you probably see a read spike, followed by a write spike on the target, instead of a smooth maxed out curve. Then the solution is increasing buffers and caching. Depending on the distro there’s a sysctl that may be on by default that limits the size of caches to prevent the “I wrote a 4GB file to my USB stick and now there’s 4GB of RAM used for it and it takes hours after finishing the transfer before it’s flushed to the stick”.
Any reason the VPN can’t stay as-is? Unless you don’t want it on the unraid box at all anymore. But going to unraid over VPN then out the rest of the network from there is a perfectly valid use case.
The ads come from an ad network where there is very little visibility into what’s going to be displayed in your app. And bad people also keep managing to get their ads published even though the ad network doesn’t allow them
And it all ties into the whole targeted advertising, where they also make sure very few people get the bad ad, and tries to target people they think may be more susceptible to these kinds of tactics. Depending on the amount of interactivity allowed, the ad can even display two different things if it deems you too savvy to fall for it.
It’s basically unescapable unless you only use apps without ads, or pay for the ad-free versions.
The whole advertising industry is sketchy, more news at 10.
If we allow derivatives, I’d say SteamOS despite being Arch. It’s putting Linux in non-technical people’s literal hands and it’s not a locked down and completely different platform that happens to run Linux like Android is. It’s almost designed by Valve to give people a taste of Linux by the addition of its desktop mode, and people that would be modding consoles are now modding SteamOS and learning how much fun an open platform can be. I’ve seen people from sales talk about their Decks on my work Slack.
Otherwise, NixOS, no contest. It’s been a really long time since we’ve last seen a fundamentally different distro that’s got some real potential. For the most part, Arch, Debian and Fedora do similar things with varying degrees of automation and preconfiguring your packages, but they’re still very package oriented. We’ve been mostly slapping tools like Ansible to really configure them to our liking reproducibly, answer files if your package manager has something like that. And then NixOS is like, what if the entire system was derived from evaluating a function, and and the same input will always result in the exact same system? It’s incredibly powerful especially when maintaining machines at scale. Updates are guaranteed to result in the exact same configuration, and they’re atomic too, no halfway updated system the user unplugged the system in the middle of.
(a) Yes. Instance admins have the ultimate say in what’s on their server. They can delete posts, entire communities, ban remote users and delete remote users. At least they had the decency of notifying you!
Since lemmy.ca owns the post, lemmy.world can’t federate out the removal, so it’s only on lemmy.world.
(b) You have to go appeal to lemmy.world. Each instance have its own independent appeal process.
That’s the beauty of the fediverse: instances can all have their rules to tailor the experience to their users, and it doesn’t have to affect the entire fediverse. Other instances linked to lemmy.ca can still see and interact with your post just fine, just not lemmy.world.
Distro packages and to some extent Flatpaks, use shared libraries which can be updated independently of your app.
So for example, if a vulnerability is discovered in say, curl, or imagemagick, ffmpeg or whatever library an app is using: for AppImages, this won’t be fixed until you update all of your AppImages. In Flatpak, it usually can be updated as part of a dependency, or distributed as a rebuild and update of the Flatpak. With distro packages, you can usually update the library itself and be done with it already.
AppImages are convenient for the user in that you can easily store them, move them, keep old versions around forever easily. It still doesn’t guarantee it’ll still run in distros a couple years for now, it guarantees that a given version will forever be vulnerable if any of its dependencies are because they’re bundled in, it makes packages that are much much bigger than they need to be, and you have to unpack/repack them if you need library shims.
Different kinds of tradeoffs and goals, essentially. Flatpak happens to be a compromise a lot of people agree on as it provides a set of distro-agnostic libraries while also not shifting the burden entirely onto the app developers. The AppImage developer is intentionally keeping Wayland broken on AppImage because he hates it and wants to fulfil his narrative that Wayland is a broken mess that won’t ever work, while Flatpak developers work hard on sandboxing and security and granular permission systems.
It would be if it wasn’t for NVIDIA, as usual. On Intel/AMD, you assign the seats, the displays light up and you’re good to go, pretty much works out of the box, especially on Wayland.
But for NVIDIA yeah maybe a VM is less pain since NVIDIA works well with VFIO.
For maximum performance you probably want to skip virt-manager, virt-viewer has a hardcoded FPS cap.
If you use QEMU directly and use virtio-gpu paired with the sdl or gtk display, and OpenGL enabled, you can run Ubuntu at 4K144Hz no problem. The VM is near imperceptible, and it works out of the box, that’s not even touching the crazy VFIO stuff.
It doesn’t seem to have any outrageously complicated dependencies to work, just C++, Boost and a few other recognizable names, at least at a glance. They also seemingly have an ArchLinux package, which means it’s likely to at least be buildable on latest everything. Mint will fall in between, so the odds it’ll compile are pretty good.
It’s not even always necessarily about trust, but risk management as well. I’ve definitely coded a crash handler that exposed my database credentials in it. There’s also the network aspect of it: your ISP/job/coffee shop can see the DNS request and TLS server name from the telemetry ping. That can be used to track you, or maybe you trigger some firewall alarm at work because of the ping.
We’ve kind of just started accepting that most apps will phone home and that there’s constantly some chatter on the network from all those apps. But if you actually start looking at what all your devices and apps are doing in the background with say, a PiHole, it’s pretty shocking.
I’m not that paranoid and would certainly accept some level of telemetry if asked nicely. “Hey I’m a small dev, I appreciate receiving detailed crash reports to make the app better”. And as a developer, users might be willing to offer way more than what would be reasonable to do in the background. I might even agree to submit a screenshot on crash, but if and only if I’ve been asked before and told what it’s used for, and I get the option to disagree if I’m going to be handling private information and don’t want to risk my data be part of a stack trace.
RAM is the kind of thing you’re better off having too much than not enough. Worst case the OS ends up with a very healthy and large file cache, which frees up your storage and makes things a bit faster/lets it spend the CPU on other things. If anything, your machine is future proofed against the ever increasing RAM hungriness of web apps. But if you run out of it, you get apps killed, hangs or major slowdowns as it hits the swap.
The thing with RAM is that it’s easy for 99% of your workload to fit comfortably, and then there’s one thing you temporarily need a bit more and you’re screwed. My machine usually uses 8-12/32GB of RAM but yet I still ended up needing to add swap to my machine. Just opening up the Lemmy source code and spinning up the Rust LSP can use a solid 8+GB alone. I’ve compiled some AUR packages that needed more than 16GB of RAM. I have 16 cores so compiling anything with -j32 can very quickly bring down a machine to its knees even if each compile thread is only using like 256-512MB each.
Another example: my netbook has 8GB. 99% of the time it’s fine, because it’s a web browsing machine, and I probably average on 4GB usage on a heavy day with lots of tabs open. But if I open up VSCode and use any LSP be it TypeScript or Rust, the machine immediately starts swapping aggressively. I had to log out of my graphical session to compile Lemmy, barely.
RAM is cheap enough these days it’s nice to have more than you need to not ever have to worry about it.
Keep in mind, defederation is bidirectional. You can end up on an instance that doesn’t defederate anybody but is being defederated by some major instances and end up worse off. Also, communities are bound to an instance so even if your instance doesn’t defederate with another, the instance that hosts the community might, which also doesn’t solve anything.
Also lemmy.ml had to restore from backup monday because postgres shat itself, so if the post is from monday or around, it’s possible it was simply lost due to the technical problems.
There’s also some federation problems with 0.19.0 and 0.19.1, so it’s possible it’s been attempted to be delivered to lemmy.ml but failed due to load or whatever.
You didn’t give any details or examples so we can only speculate. We troubleshoot federation by establishing patterns, like from what instance are the missing comments from, what instance hosts the community.
Addendum: I’ve also been experiencing occasional ghost posts, and I’m on my own instance, so there might be some stuff going on that’s unrelated, because I sure didn’t do anything. If they were deleted or retracted I would see them because I’m admin, I see everything.