Yes, you should. There’s a low probability that anything bad will happen but you might as well reduce that to zero. Private trackers (should) only email you for account creation confirmation and whenever you want a password reset.
You’re right, and I suppose I was half-thinking along the lines of “we have all the pieces to solve this, but we don’t because we’re frozen in place by greed” instead of “this is something we could do with infrastructure today”. If everyone could collectively let go and re-distribute wealth and materials efficiently everyone would be much better off for it, but instead we’re stuck in some game theory hell where the optimal personal choice results in one of the worst outcomes.
Flatpak is like an alternative packaging system that exists outside of your distro’s normal packaging model, e.g. apt/dnf/pacman etc. The killer features are that Flatpaks work on any distro with a single universal package, and that the software versions will be cutting-edge without needing cutting-edge system dependencies. Flatpaks run in their own dependency network and generally don’t rely on anything from the host system - this means that you can have arbitrary software on your machine that your distro/repo maintainers don’t need to compile/quality-control/stability-test/etc. It also comes with an easy sandboxing framework out of the box as a bonus.
In my case I usually use Flatpaks to get more current versions of software without totally messing up Debian’s “Debian does not break” stability model - Debian is meticulously maintained so that its “Stable” branch only has ultra-stable versions of software, at the expense of those packages being older and frozen. If you use a distro with smaller package repos (e.g. OpenSUSE/Fedora/etc) you’ll probably appreciate finding Flatpak versions of software that you’d normally need to manually compile.
Flatpaks are cool, and they have a specific use. They’re not the end-all be-all of packaging and they’re (hopefully) not going to replace apt/dnf/pacman. As for why they hate apt I have no idea. apt is good, and you can even make it a little nicer by installing nala and using that instead of apt.
If the basis of this thread is that you’re digging for distro recommendations I’d personally steer you towards Linux Mint and OpenSUSE Tumbleweed for their ease of use. Debian is a little more difficult to set up than Linux Mint but not tremendously so. Arch is more of an “intermediate” difficulty distro where the main challenge is that your system packages are fast-moving and can break/change in small ways from day-to-day. If you aren’t comfortable with Linux you might get frustrated with minor bugs that you don’t know how to troubleshoot. Conversely, if you want to learn Linux then dealing with Arch’s shenanigans will help expose you to various parts of the system naturally.
Where’s the fun in paying someone else to do it all for you?
MergerFS+SnapRAID will give you a very similar set of features/flexibility compared to UNRAID storage. OpenMediaVault has native MergerFS+SnapRAID support and can also do ZFS - I would look at that for a comparable alternative. Otherwise, I’m very fond of a Proxmox host with a TrueNAS VM for ZFS pool management, or just managing the ZFS pool with the Proxmox host itself through this cockpit extension.
Do you have any examples? I have never seen a paywall while using this. They have a list of supported sites, though I’m not sure if all of them are guaranteed to work 24/7 or if they need frequent updates.
Seems like there’s some bitrot in the middle of the file, and whatever you’re using to play back the original file just skips it and doesn’t care enough to halt playback. You might try looking for ways to restore as much of the file as possible with something like this, assuming the mkv is a unique copy that you can’t get anywhere else.
Edit: I’m also curious if this file lives on an XFS/BTRFS/ZFS filesystem. The reflink property of these filesystems may be the reason that you can copy within the same folder without it throwing an error.
The keygen generates a key based on your system’s perceived HWID - this is sort of how Denuvo operates as well. Keys generated on one system won’t work on another. I don’t know why there’s an Android version though.
Edit: From a glance at their website it seems like this newer 80_PA is based (only?) around offline activation codes (Request Codes), where you can take a code generated from a Securom program, plug it into the keygen, and put the Unlock Code back into the program. This would work on Android/wherever as it doesn’t directly rely on the HWID being visible. The older 80_PA version worked based off of system HWIDs, and generated keys without needing request codes. The older 80_PA does include some request code decryption tools but as far as I can tell doesn’t directly translate a request code into an unlock code?
That version does not work for me either, but the copy available on cs.rin’s dedicated Fable 3 thread, posted on page 12 by arthurclg17 (thread ID 59454) does work properly. Alternatively, you can try generically defeating Securom with a DLL-based method, though it’s a little more involved. I have a guide for that here.
Semi-related, can these automations really be relied upon for quality, or is there a system to help find the best copy? When I’m downloading books I do it manually through Anna’s Archive and I always download as many unique versions of a book that I see, then open them all and compare their internals to see which one I keep. Often not many ebooks are suitable for using my own font and layouts with Koreader.
I haven’t used Kali Linux before, but hcxtools is available in the Debian repos so presumably your /etc/apt/sources.list is invalid (probably the LiveUSB has disabled non-iso sources). Can you post what is in that file?
Probably because they pack a ton of files into a handful of compressed archives, which means the full archive needs to redownload when a single file is changed. Does Steam not have a delta patching system to handle this? They already compress downloads so it’s not like a delta patch framework would cost extra CPU in comparison, and the bandwidth savings would be immense. Seems like low hanging fruit to me?
Arch is bleeding edge and frequently has minor bugs as a result. This is probably fine for power users and people who want to learn Linux but I wouldn’t give an Arch distro to someone who isn’t techy. They also likely won’t appreciate the frequent updates to applications that they depend on to actually do work.
(I used Arch for almost five years and think it’s one of the best distros)
Yeah. What repackers do is they source the game, source all the updates, source the DLC, and source the cracks, then put it all together, make sure it works, compress it into an installer, and distribute it. As an end-user you run the installer to decompress the game and then click play. Repackers don’t actually do any of the cracking themselves, they just put it all in one package and make it easy. The installer will run CPU-heavy while it decompresses their heavy compression so don’t be alarmed by that.