yote_zip

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

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).

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

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.)

yote_zip, 1 year ago (edited 1 year ago)

The link I posted is for Firefox. The Chrome version is here, and it looks like it should continue working with MV3. (Obviously, the better solution is to stop using Chrom*. Mozilla is modifying Manifest V3 so adblockers/etc will continue to work in a post-MV3 world).

Edit: Added dev’s comments/issue-link on MV3

yote_zip, 1 year ago (edited 1 year ago)

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.

yote_zip, 1 year ago

You should submit some issues for those sites with these steps - maybe they’ll add them to the list. The addon supports 453 sites at the moment by my count, so I’m sure they’d love for you to tell them about more sites that haven’t been bypassed yet.

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

Note that in this benchmark, bcachefs had a debug variable turned on that allegedly severely hampered performance. Bcachefs has released an update to disable this variable but Phoronix hasn’t redone benchmarks yet. I wouldn’t put much value into any bcachefs-related comparisons from this current benchmark.

yote_zip, 1 year ago

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)

yote_zip, 1 year ago

I switch around a bit. New is nice because there’s a deterministic order, but you also won’t have any comments to read. Every once in a while I scroll through active to see which posts have gotten discussion.

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

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?

yote_zip, 1 year ago

I wasn’t able to get the gsettings method to work (I’m on Wayland KDE), and that article doesn’t say anything about theming QT Flatpaks. Also, after “installing” my GTK theme as a flatpak via the method described, it still wasn’t available to my GTK Flatpaks via the GTK_THEME method. The steps in the itsfoss.com article do work, though there’s been a lot of squabbles about the “proper” way to expose themes to Flatpaks. Regardless, this all goes back to my point that theming Flatpak is clunky and should be much smoother.

yote_zip, 1 year ago

Right, I understand it’s not supposed to be used in “proper” usage, but it does work for all my GTK apps and the gsettings method does not work for me. Unless I’m supposed to store it somewhere else because I’m on KDE.

yote_zip, 1 year ago (edited 1 year ago)

I do have xdg-desktop-portal-gtk on Debian Stable, which is currently at 1.14.1-1. I’ll look around to see if there’s more documentation on this method, because I would prefer to not use the debug variables if possible.

Edit: I launched with GTK_DEBUG=interactive and I can see the theme inside the Flatpak gets set to Adwaita-empty instead of my actual theme, which does get properly returned via gsettings get org.gnome.desktop.interface gtk-theme

yote_zip, 1 year ago

That gets my normal GTK theme properly. I found a little more discussion on this here. Nothing very actionable but I did also confirm that my xdg-desktop-portal-gtk is running. It seems like this is supposed to be working, but I have a mostly stock Debian 12.1 KDE install and something seems to be wrong somewhere in the chain. I’ve also tried multiple GTK Flatpaks with the same results.

Edit: Also, I have both my themes folder exposed and the theme installed as a Flatpak via the linked script.

yote_zip, 1 year ago

Aside from philosophical issues my experience with Flatpak has been excellent. There’s some theming steps you need to do to make them feel like regular apps, which I feel is clunky design. No Flatpak-induced instability from what I can tell. Setting up directory permissions is sometimes slightly annoying but Flatseal makes it trivial, and most Flatpak permissions are set up properly out of the box these days.

I haven’t noticed any start-time delays when launching Flatpaks as opposed to regular apps - I don’t know if they’ve fixed that or if my system is just too powerful. The only app that I’ve personally noticed is weird is VSCodium, which has trouble escalating to admin permissions when you’re trying to edit privileged files. I still use the regular version for that reason.

yote_zip, 1 year ago

It’s simple and solid enough to give to people who don’t know what they’re doing, and its Debian/Ubuntu base makes it flexible enough to not slow down power users who want to start modifying it. Other distros that might fit this bill keep shooting themselves in the foot and going off in weird directions, while Linux Mint has been a reputable no-BS distro for a very long time. It’s a workhorse distro without any gimmicks and that’s the point.

yote_zip, 1 year ago

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)

yote_zip, 1 year ago

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).

yote_zip, 1 year ago

They’re available as an option. You can source from any of Fitgirl, DODI, or KaOs if they have the game you want. Other repackers do exist and they’re all generally trustworthy, but those 3 put out a lot of content and have a good track record. ElAmigos is another good one that puts out a lot of releases.

yote_zip, 1 year ago

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.

yote_zip, 1 year ago

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.