Every community I care about is dead
I feel piracy for demo purposes is fully justified if you buy it after you like it. People always say vote with your wallet but it’s more like gambling with your wallet if you don’t get to see and touch the product before you make the purchase. Giving proper demos should be more common with digital media.
Arch has made a lot of mistakes, and their most recent one where they bricked everyone’s GRUB loader is the one that caused me to stop using it as a general recommendation. This sort of thing would never happen in Debian, and pretending that “every distro makes massive mistakes!” is disrespectful to distros that actually put a ton of effort into making sure these things don’t happen. Sweeping those mistakes under the rug is harmful to new users who don’t know what they’re signing up for when they download the distro that you are sugarcoating, and that is the primary reason to make sure that anyone considering Manjaro is aware of its past so they can make their own decisions.
Security updates aren’t delayed in Manjaro, they’re pushed through out of band.
Manually. Also read as: delayed. The comment from Arch’s security team that you are minimizing is part of the reason why this is a bad idea: “They just forward our security advisories without reading them. Leaving critical security issues to rot in their “stable” repositories while only pushing forward issues that are publicized or users telling them about”. Once again, why would I trust the Manjaro team to be on top of security when they can’t figure out how to keep an SSL cert alive? Their security mailing list hasn’t even been updated in a year.
Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.
You are dodging the real dependency problem by focusing on this half. The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage. AUR packages are built with Arch Linux’s repos in mind and no care whatsoever for the versions of packages that Manjaro holds. Updating your AUR packages frequently will all but guarantee that you will eventually run an AUR update that requires a dependency with a newer version than Manjaro provides, and that app will break (or worse, the AUR package is a dependency for other apps which will cause further breakage). Even Manjaro knows this: “Using AUR also implies Arch stable branch - which is only achievable by using Manjaro unstable or testing branch.”. Also take it from their team: “The AUR is neither officially supported by Arch nor Manjaro. If you do use the AUR on Manjaro, use our unstable branch. Problem solved.”
That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.
Yes very sad that a member of Arch’s security team made a warning about Manjaro’s security 5 years ago and still we have people pretending that it’s “flamebait” because that’s a convenient excuse to dismiss it.
The receipts that I just linked show far more than 2 mistakes. I don’t care whether they have fixed them or not, I care that they have made so many. Trust arrives on foot and leaves on horseback. Distro forks are nothing special, so why use the one with a history of bad management? Use Arch proper or any of the countless Arch forks that use the real Arch repos, which will inherently sidestep a lot of issues that Manjaro created for itself.
You say that delaying packages makes things more stable but there is a clear history of that not being the case, which has already been described in the links I posted. This is most importantly true in terms of delayed security updates. You also don’t understand how the AUR works in conjunction with outdated Manjaro packages, which will cause dependency problems and lead to breakage. This is a very simple cause and effect so I’m not sure how you think you can try to assert “everyone else must misunderstand how dependencies work”.
As for the last bit, no Arch is obviously not being hurt when Manjaro is called out. If anything I’ll bet Arch wishes Manjaro would stop tripping over itself and giving Arch a bad name. They are already sick of Manjaro users using the AUR and complaining every time it breaks their packages, and you can read what Arch’s security team thinks about Manjaro here on r/archlinux (image mirror here if you don’t want to visit that site).
Manjaro is one of the few distros I’ll actively campaign against. They’ve made countless mistakes and questionable decisions in the past, and their repo/packaging lifecycle is known to cause a lot of issues: One, Two, Three, Four. Go for EndeavourOS or Garuda Linux if you want the idea of Manjaro but managed by competent people.
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.
I use a few packages from Homebrew and don’t have any problems with it. By default it installs itself into /home/homebrew or something which I didn’t like so I put it into ~/Applications/Homebrew instead using these steps. It warns that you may be forced to compile software if you do it this way but I’m down to clown so whatever.
The biggest problem I have with it is that you’ll need to keep it updated alongside your regular packages, which I do by aliasing a simple upgrade command that runs all my package manager upgrades.
I would also recommend ungoogled-chromium as an alternative to Brave, which does have its own official Flatpak (not marked as such but it’s linked to in the ungoogled-chromium project github).
I’ll add that if you want to archive games forever, storing repacks is a good idea because of their extreme compression. From what I’ve observed, Fitgirl trends towards heavier compression while DODI trends towards faster install times.
KaOsKrew is another respected repacking group that you can trust.
If you’re familiar with What.CD and its shutdown, the power users and their local copy of that music archive moved over to redacted.ch (stats) and orpheus.network (stats). They’re private torrent trackers so they’re invite-only, but TMK they both still offer interviewing as an entry option: RED, OPS. The interviews mostly consist of technical audio information and private tracker rules. The main downside is that these trackers expect you to seed an equal amount back, so you don’t get a free pass to download everything without limits. Of the two, Orpheus is a lot easier to maintain “ratio” on since it gives you incremental credit just for having a large seedbase (even if no one is downloading from you). Ideally you should be on both if you’re serious about music collecting, but these days they are largely just mirrors of each other.
If you don’t want to get dirty in the private tracker world, I’d recommend Soulseek and RuTracker.
It looks like the answer is a resounding no.
Try this answer. I guarantee there is a way to read the file front to back while skipping errors, but I run so much data redundancy that I don’t have any experience with it.
Okay cool. I would be wary of that drive just in case, and I would definitely schedule weekly SMART short tests and monthly BTRFS scrubs on it if you go with BTRFS in the future. EXT4/XFS/etc do not have a concept of data checksums, which means they can’t scrub and check for bitrot - this might be problematic if you find that your disk starts causing bitrot because you won’t know where it’s happening.
I follow Backblaze’s rules on detecting impending drive failure:
If any of these SMART metrics are higher than 0 I’d expect failure soon and take precautions.
It goes without saying but the number of errors you should get on a scrub is ideally 0. Bitrot happens from time to time which is why you should keep some data redundancy/backups so you can repair it when it’s detected, but that number seems higher than normal. Your disk may be going bad if you’re getting that many read errors; I’m not sure. I believe you’re already backing up data off this drive but yeah I would get everything important off the drive ASAP, then run a SMART short test and a SMART long test to see if that reports that anything is wrong. The disk may be fine but better to be safe than sorry.
Back to the video file, I’m assuming it was not one of the ones that BTRFS fixed automatically? The only real options for data recovery are to rescue the file minus the bad blocks with e.g. ddrescue (which I don’t personally have familiarity with) or something similar, or to encode through the errors with ffmpeg if it will let you.
Fair enough. I would at least try to get the damaged file off of the disk so you can potentially fix it later, or just have it available to play in its broken state. For the future you should probably be running monthly BTRFS scrubs to detect bitrot sooner, and potentially you should have some backups or data redundancy so you can repair the bitrot when it’s detected.
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.
Make sure to check ProtonDB for a game if you’re having problems. I think jsdz’s answer should work. For extra context, SwGame-Win64-Shipping.exe is a DRM-free executable whereas starwarsjedifallenorder.exe has Origin/EA DRM baked in. Setting your launch option to "path/to/SwGame/Binaries/Win64/SwGame-Win64-Shipping.exe" %command% like they report in ProtonDB should work.
(There’s actually some tiny bits of DRM in SwGame-Win64-Shipping.exe but they allow runtime even when they fail so it’s similar to DRM-free for practical purposes)
My general advice to Linux newbies is just to use your computer as a computer. It’s important that you get everything you need working, and over time you’ll get more comfortable with how things work in a standard workflow. In ~half a year you might want to explore beyond your workflow and try to make optimizations etc, in which case you’ll have a much better idea of what is not working and what you want to improve. On a related note I’d also strongly recommend picking a distro and sticking with it for a while, even if someone says your distro sucks. Don’t distrohop endlessly when you don’t even know what you want. Linux Mint is an excellent distro that will not hold you back even if you are an expert, so don’t mind anyone saying Arch is the king or Debian is where it’s at.
I can only speak from experience but from my understanding most people’s knowledge of Linux is derived solely from wanting to do something and then figuring out how to do it, instead of studying a list of “things you must know to use Linux”.
Running FOSS is practical for the long term, even beyond moral judgments. Proprietary software starts strong with lots of funding, but it only gets worse and worse as it goes along. Open source starts slower but plays the long game. You can take a look at something like Windows itself for an example of the gradual infestation of ads and user-hostile features/tracking. It’s never going to get better. The only hope for proprietary users is for a new proprietary app to be created and start off more user-friendly because they need to attract users. Once they have the users they’ll restart the cycle again.
I’m curious to know more about your “certain date” requirement - this sounds like it might be an XY problem. As for general advanced backup programs, I have two easy recommendations that are similar in featureset:
The most important parts of real backup software IMO is the ability to compress your backups, version your files with rolling/pruning snapshots, and version your files efficiently with only deltas between them taking extra space. You can also encrypt your backup if you want to store it with a remote party, or run integrity checks to check for bitrot.
Reflinks with BTRFS and ZFS start off with behavior similar to hardlinks, but when you modify one of the files it doesn’t change the other one. Hard links share the same inode and edits to one file must affect the other.
Example:
File A: 10GB
File B: Reflink’d to File A
10GB total space used, 10GB shared between A and B.
Modify 1GB of File A
1GB of new blocks created, 11GB total now used. 9 GB still shared between A and B.
How would Amazon track a voucher? It’s a physical scratch off code, sealed by Mullvad before they send it over to Amazon. More importantly, if you think that was possible why would Mullvad be unaware of it and/or lie about it? Just go with the vouchers if you want untraceability. They’re also cheaper in USD than other methods IIRC, at $29/6 months and $57/12 months.