Reading the thread with the discussion on it, seems there was real contempt towards letting the user decide not to update their packages.

"After a refresh, the next refresh can be delayed by up to 60 days, after which a refresh will be performed regardless of the refresh.hold value."

Not sure if that would work with Ubuntu though ;)

Samsung has followed suit w/ Android. Once an update is available, the user can defer it three times before the phone is rebooted. Not even Apple pulls this crap.

In the long term, just avoid samsung products that don't respect your authority as the owner.

> alias df='df -x tmpfs -x squashfs -x devtmpfs'

function df { OUTPUT=$(/usr/bin/df $@) snaps=$(echo ${OUTPUT} | rg "^.+/snap/(.+)/.+$" -r '$1' | tr '\n' ' ') printf "\x1b[33m\x1b[1mFILTERING SNAP MOUNTPOINTS:\x1b[0m\x1b[33m\n$snaps\x1b[0m\n\n" >&2 echo $OUTPUT | grep -v "/snap/" }

And yes, Arch takes in the upstream vanilla packages, though there are testing phases before updates reach stable repos. I'm not sure any of this is a bad thing. It also means you don't have to wait 6-12 months for the newest version.

Updates are only installed when you run pacman (or a pacman wrapper/replacement). But I guess you mean changes to a package in the repository with "package upgrades straight from the developers".

There are two sources for arch packages:

- The official repository, - The AUR repository

The later one does indeed allow maintainers to arbitrary update or remove packages. It provides just a way for _users_ to provide custom packages to other users. The responsibility for reviewing them lies with the person using them. This is clearly communicated. Also most AUR packages do not contain any code but just install instructions which pull the code/binaries from their original source (e.g. github/github releases/the website of the project for which the package is). So reviewing them is normally quote doable. The only annoying to review AUR package I can remember is tor-browser.

With regard to the official package thinks are actually pretty similar as far as I know (but I don't rally know) except that not everyone can publish thinks there and you have a group of "trusted" core maintainers.

In the end arch is a distro by the "experienced" Linux user for the "experienced" Linux user without to much financial backing.

Not that there still are thinks like a security group which tracks CVE's and similar but it's fully based on volunteers.

This makes it quite a fascinating choice as any choices wrt. maintenance comes from some dev wanting to use it on their system.

But yes if you don't trust the core maintainers don't use it.

Also it might not be appropriate to be used on cooperate systems due to company policies wrt. legal liability reasons.

Still you also trust many other software maintainers solely based on a good reputation and for arch it's in the end the same.

Also besides pacman and probably some other minor thinks Arch doesn't do any code. It's just provides code other people wrote (sometimes with publicly known patches) to the user, sometimes pre-compiled.

No.

> “peer review”

I am not sure what you mean, and I don't know that much about Arch developer and Arch maintainer protocols; but the whole thing is more transparent than Debian: everything, including the PKGBUILDs and the rare patch is accessible through public git repos very accessibly and visibly linked from the web page of each Arch package. Debian also has public git repos AFAIK, but finding them and navigating the directory hierarchy is more difficult.

[1] https://blocked.cdn.mozilla.net/

When you create a snap package and post it to the Snap Store, you only get the default limited rights for your snap. For example, your application is not able to access external disks. But if your application has a real case to do so, then you need to request to have that access added to your snap.