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?
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.
Did you actually apply the crack over top of the original files? You say you’re running the executable in the CODEX directory, but the CODEX directory would be where the temporary crack files are, not where the game is expecting them. You can also try installing the latest repack from KaOs, which you can find on 1337x by searching for “skyrim repack kaos”. The repack will auto-crack everything so you can be sure that at least that is done correctly.
The video is clickbait and a few of the distros are in categories just for dramatic effect. I personally share Chris’s criteria for “pointless” distros however, and I hope that his main “clickbait motive” was trying to stop people from hopping around from gimmick distro to gimmick distro when the real magic has always been with the Debian/Arch base underneath the hood. I don’t care to give Chris the attention he wants so I’d rather answer your questions instead of talk about the video directly:
I agree that Debian and Arch are “S-tier” distros. Not that they’re better than everything else for every usecase but they are very high quality community-run distros with large package bases, and they accomplish their mission statements with ease. If you’re a Linux power user for long enough you may eventually settle into one of these two distros because they give you a lot of room to mold your configuration without being opinionated by downstream distro maintainers.
Linux Mint is very good, and it’s probably the only “fork distro” that I recommend people use because it makes Debian/Ubuntu very simple and usable for new users, and it’s done so for many years with a great track record. I currently run Debian Stable but if you put a gun to my head and said “you can only run Linux Mint from now on” I’d be fine with it. Specifically, I prefer the LMDE edition but the normal version is good too.
You can run cutting-edge gaming stuff on Debian Stable and Linux Mint by using Flatpak Lutris/Steam, which uses its own cutting-edge Mesa package instead of the system’s, and you can also install a cutting-edge kernel on these stable distros by using Debian backports or e.g. XanMod. I prefer using stable distros like Debian Stable and pulling cutting-edge versions of your important packages through Flatpak or other means, which gives you a “stable base and rolling top”.
I think the general usecase for Arch has diminished from half a decade ago due to Flatpak’s popularity, and IMO a stable base setup makes more sense if you can get everything important that you need from Flatpaks. With Arch, not only are the programs you care about bleeding-edge, everything is bleeding-edge, and you may end up with annoying bugs from packages you didn’t even know existed.
If you want a more modern version of the Linux desktop without the bleeding-edge of Arch I think OpenSUSE Tumbleweed is a great cutting-edge distro. They have extensive automatic testing that ensures high system stability even while living near the edge of package freshness. The main downside is OpenSUSE’s smaller package base compared to Debian/Arch-based distros.
ZFS and BTRFS could update their codebase to account for these (if they haven’t already), but I agree that their extra mechanical parts worry me. I really don’t care about speed - if you run enough HDDs in your RAID then you get enough speed by proxy. If you need better speeds then you should start looking into RAM/SSD-caching etc. I’d rather have better reliability than speed, because I hate spinning rust’s short lifespan as-is.
I no longer use Arch, but this wouldn’t have happened to me because I used vanilla Arch. On Manjaro it can happen at any moment that an AUR package silently depends on a new part of a dependency not implemented in the older versions. The AUR does not care to figure out which exact version dependencies are needed for a program, because you are expected to always have an up-to-date Arch system before installing. If the AUR cared about Manjaro compatibility they would need to mark every dependency with a minimum version number, but that’s a lot of effort and the AUR understandably doesn’t care about supporting Manjaro’s repos. If Manjaro stood up its own AUR this would no longer be a problem.
(Personally, I don’t think AUR packages are a good idea for system stability/security even on vanilla Arch, but it is understandable that people like them for their convenience.)
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.
Usually torrents remain seeded because private tracker users are encouraged to seed everything forever. In addition, often if a private tracker has a bonus system they will offer extra bonus points for seeding low-seed torrents, and some even automatically mark torrents as freeleech if they’re below ~5 seeds, encouraging people to revive its seed count in a targeted manner.
One potential advantage is that many private trackers are meticulously-curated. The more people that are on a tracker, the harder it is to quality control every single upload. Most of the top-tier trackers aren’t just a dumping ground for data, they have tons of categories and slots for each potential piece of data to go, and if a better piece of data can fit in that slot then the previous one needs to be reviewed, deleted, and replaced.
Another reason is that private trackers often have many rules to facilitate the overall health of the tracker and its swarms, e.g. minimum quality for uploads, minimum seed times, required ratios etc. If anyone could get an account they could break the rules over and over after being banned.
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?
A couple nits to pick: BTRFS doesn’t use/need journaling because of its CoW nature - data on the disk is always correct because it doesn’t write data back over the same block it came from. Only once data is written successfully will the pointer be moved to the newly-written block. Also, instantaneous copies from BTRFS are actually due to reflinking instead of CoW (XFS can also do reflinking despite not being CoW, and ZFS didn’t have this feature until OpenZFS 2.2 which just released).
I agree with the ZFS bit and I’m firmly in the BTRFS/ZFS > Ext4/XFS/etc camp unless you have a specific performance usecase. The ability to scrub checksums of data is so invaluable in my opinion, not to mention all the other killer features. People have been running Ext4 systems for decades pretending that if Ext4 does not see the bitrot, the bitrot does not exist. (then BTRFS picks up a bad checksum and people scold it for being a bad filesystem)
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.