Hacker News Reader

Comment by henriquez | Hacker News Reader

I dumped Ubuntu over Snap. Maybe I’m just ignorant but it seems like allowing developers to push software updates without any review invites the same sorts of issues we’ve seen on npm, with very high risks for certain use cases. I don’t want that kind of relationship with my OS, forced updates are why I ditched Windows in the first place.

Aside from the philosophical concerns I ran into a lot of glitches with various snap packages, frequently resulting in lost or corrupted data. And the sandbox approach prevented certain filesystem tweaking I previously took for granted. Overall I didn’t see the benefit and didn’t have time to futz with it.

I’m curious if there are any distros with a recent version of Gnome and also a sane package manager.

View on HN

I dumped snapd because of the maintainers absolutely refusing to allow the users to customize the update schedule, or even disable automatic updates at all.

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

https://snapcraft.io/docs/keeping-snaps-up-to-date

I didn't see anything about completely disabling automatic updates there. Closest I could find was:

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

With windows update the trick since MS enforced a similar update policy is to change the user the Windows Update service runs under to an account that doest have the required permissions.

Not sure if that would work with Ubuntu though ;)

i am surprised that this is possible under windows. for ubuntu, it should be possible to disable the daemon that runs the update checks. at worst by hacking a script where the process is started.

There's a solution you're not seeing https://ubuntu-mate.community/t/how-to-completely-remove-sna...

> forced updates are why I ditched Windows in the first place

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.

As a short term solution, you can use netguard and always have it run in lockdown mode. It works on most phones and doesn't require root. You can use it to whitelist app access to the internet (inc. blocking samsung and google play updates). It's also open source.

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

I've been using Manjaro for about a year now, after also getting fed up with Ubuntu. It is based on Arch, but just as easy to set up and get running as Ubuntu. I find its package management sane enough for my day-to-day use, and though I install packages from all over I have yet to have anything break on me. I can definitely recommend it.

Launch times and (silly, but it really bugged me) pollution of my `df` output drove me away.

Cluttering up df and mount output is a real problem. They are useful tools - cluttering their output makes them much less convenient / more time-consuming to use. I have about 8 mounts for snap and like 15 for cgroups here. And actually about 10 others that I don't remember seeing before at all. pstore? securityfs? tracefs? debugfs?

Yup, the output of df became so cluttered that it became useless. So I created this alias:

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

Adding to my dotfiles, thx!

Oh my this is awesome! Thank you. So much better.

Here's one that doesn't hide the snaps but but still keeps it not cluttered (relies on ripgrep) :

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/" }

Definitely try an Arch-based distro. I run Arch myself, but I've heard good things about Manjaro.

Doesn’t arch also allow arbitrary package upgrades straight from the developers? Again I’m pretty ignorant but my impression looking at it previously was there isn’t any sort of “peer review” by repo maintainers.

You're never forced to update. I'm don't even think Arch natively supports automatic updates. You can also tell pacman to skip a package from being updated if you're aware of a problematic update but you want to update the rest of your system.

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.

I think what he/she means is that core maintainers (or AUR maintainers) might be able to change a package without another core maintainer (or AUR maintainer) reviewing it.

Afaik, upstream packages aren't changed by Arch maintainers. It's the whole point of using Arch. And if you're using AUR, you'd better be checking the PKGBUILD (because no, it isn't verified by anybody). At the very least, you need to be checking where the package is being downloaded from.

The PKGBUILD of packages in the official repository can be changed, which people theoretically could use to inject malware. That's what I meant.

Arch is kinda the I can do everything reliably distros if you know how to set me up.

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.

> Doesn’t arch also allow arbitrary package upgrades straight from the developers?

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.

Manjaro is simply fantastic. I switched when upgrading Ubuntu failed again. Hardware detection is great, defaults are sane, and pacman is a great package manager. The AUR is also amazing.

It could be worse. Software push is how browser distribute extensions. And they are ridden with spyware [0]. Pull by maintainers, deferred rollout, veto and rollback might what saves us yet.

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

haven't had that issue for years with npm/yarn, thanks to lockfiles.

Mint!

> Maybe I’m just ignorant but it seems like allowing developers to push software updates without any review

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.

Reply on news.ycombinator.com