Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

jatan.blog

Post reply on HN
Print view View original

451–460 of 645 posts

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#451

Post by stefan_ »

Spooky23 wrote: post #80
dmw_ng wrote: post #32

Earlier quoted context omitted.

The bottom line is they optimize installation time by amortizing it out over the runtime life of the package, or in other words, optimizing a one time 15 second process to be a 14 second process, in return for making a many-times 1 second process a 30 second process. It makes absolutely no sense. They do this using a filesystem originally designed for embedded devices, using a driver hacked to disable threading suppo…

It’s a bad implementation. You can run inline compression on latency sensitive workloads like VDI without issue. Compression makes a lot of sense as the cost for fast high capacity SSD is usually much higher than the extra CPU cycles required to decompress.

It's not squashfs fault, it's the snap people that just have absolutely no clue. squashfs is designed for embedded systems with say 8 or 16 MiB of very slow NOR flash, so you maximize compression ratio at the expense of speed (because the flash is probably still slower).

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#452

Post by ufo »

lucb1e wrote: post #408
ChrisSD wrote: post #145

Earlier quoted context omitted.

Be aware that Testing may get security updates much later than Unstable or Stable. https://www.debian.org/security/faq#testing

Does that actually happen in practice though? And as for the severity, we're talking desktops so the most critical piece of software is the browser. Firefox is the only piece of software I download outside of the repositories to make sure the updates come directly from the source, but other than that, openssh very rarely has serious vulnerabilities, to attack Thunderbird you'd already need to mitm my traffic... it's…

It is particularly bad during the freeze before the new stable version comes out. Some updates can be delayed for months.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#453

Post by lucb1e »

timClicks wrote: post #438
lucb1e wrote: post #393

Earlier quoted context omitted.

Isn't using the internet insecure then? I can typo bankname.example.nl as well. Not that I don't see your point: a curated list like the repositories is preferable to a system where anyone can claim any name, but I am not sure that this extrapolates to the statement that "it's insecure" as a whole. Out of interest (I don't use Ubuntu/snaps myself), is that really the case? Can I actually a publish without any checks…

> Can I actually a publish without any checks and, once I got half a million users by repackaging the deb file in snap, add some subtle malware? There is no review process or anything? This is already possible with every other distribution method. If you host your own debs, then you can easily get them to do whatever you want. Even relying on the main archive isn't great - apt is typically delivered over HTTP to make…

> apt is typically delivered over HTTP

This is a large misunderstanding of how it works. You can't MITM millions of servers around the world just because they use HTTP for downloading their apt archives.

It verifies the cryptographic signatures. That's why you need to "apt-key add" when you add a custom repository. It doesn't rely on the transport method for integrity.

> [Typo-squatting] is already possible with every other distribution method.

No, the counterpoint we're talking about is apt. In apt, not anyone can just register any package name. My question was whether that's really a thing in snap.

> If you host your own debs, then you can easily get them to do whatever you want.

I'm not quite sure what you're trying to say here. Why would I host my own deb files (in the first place, but even if I did) only to hack myself? I could just install the modified deb files directly or modify the files on-disk, no hosting needed?

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#454

Post by pengaru »

yjftsjthsd-h wrote: post #201
pengaru wrote: post #74

Earlier quoted context omitted.

With that Ubuntu has become useless trash joining the ranks of Android and its impossible to disable constant Play Store updates funneling endless unknown changes onto a machine you supposedly own.

What? The play store lets you disable auto-updates, at least per-app.

Try absolutely blocking the play store from updating itself. Even when I've jumped through all the hoops to supposedly stop this from happening, it will still randomly do an update in my experience.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#455

Post by zrm »

zrm wrote: post #139
jquast wrote: post #67

Earlier quoted context omitted.

> On-demand decompression like this has made very little sense on desktops since the mid 90s Ok, maybe not desktops? But ZFS on-disk compression is a sysadmin's frickin dream -- just one example that you can access logfiles with plaintext tools like grep while benefiting from the space savings with neglible cost, LZ4 has basically no overhead at all, https://www.servethehome.com/the-case-for-using-zfs-compress... I r…

Filesystem compression is a completely different animal than this. It has to deal with your ability to modify the file at any time. It doesn't compress the whole file together, it does it in blocks. When you launch a binary (and the system mmaps it) it doesn't have to decompress the entire file before you can start using it, only the first compression block. Compression also typically makes it faster to launch applic…

> But snap isn't reading e.g. 64kB and then giving you 128kB on demand (and then prefetching the next block) like the filesystem does, it has to read and decompress the entire 100+MB package before you can even open it. That is very silly and adds a perceptible amount of latency.

Wait, I could be wrong about this. I was deducing it from other people saying that it has to decompress the package every time you open it plus the empirically long application load times, but it turns out it's using squashfs which at least in principle could be doing the compression the same way as zfs. I haven't checked whether it does or not.

They're doing something wrong though or it wouldn't be this slow. Possibly more than one thing. Unfortunately there are a lot of different ways to screw this up, like not caching the decompressed data so it has to be decompressed again on every read even if it's already in memory, or using too CPU intensive a compression algorithm or too large a block size, or double (or triple or quadruple) caching because it's loop-mounted and then forcing slow disk reads through inefficient cache utilization, or over-aggressive synchronous prefetching, or any combination of these. Or maybe it actually is doing whole-file-level compression.

Now I'm curious which one(s) it really is.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#456

Post by CathedralBorrow »

ordinaryperson wrote: post #90
wolco wrote: post #85

Earlier quoted context omitted.

The auto update because users can't make the decision themselves is just copying windows 10 model. Do applications break after auto-updates? of course they do and that is something that is important to ubuntu users because they have to manually fix. Given the choice I would rather choose when to upgrade so I could set aside time for fixes. Ubuntu users are not windows 10 users. Why treat them in the same way?

Auto updates have existed long before Windows 10. It's great that you are diligent about updating your software regularly. But how many people do? If you agree that it's a low percentage, then why is not better for the ecosystem as a whole to improve security and compatibility?

This percentage seems to be the crux of your argument so I'm curious to know what it is. Are you relying on any data?

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#457

Post by lucb1e »

ufo wrote: post #452
lucb1e wrote: post #408

Earlier quoted context omitted.

Does that actually happen in practice though? And as for the severity, we're talking desktops so the most critical piece of software is the browser. Firefox is the only piece of software I download outside of the repositories to make sure the updates come directly from the source, but other than that, openssh very rarely has serious vulnerabilities, to attack Thunderbird you'd already need to mitm my traffic... it's…

It is particularly bad during the freeze before the new stable version comes out. Some updates can be delayed for months.

Also security updates? Wouldn't that make the new version insecure at launch until someone pushes a thousand security updates at once (making it kind of 'testing' again because none of these were in testing before and thus haven't been widely tested)?

You raise a good point since I notice I don't know the process as well as I thought I did, but it seems odd that the frozen testing repo would only get all security updates all at once months later.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#459

Post by pnako »

Firehawke wrote: post #385
littlestymaar wrote: post #363

Earlier quoted context omitted.

Debian used not to work easily on hardware that require proprietary drivers, did it change recently ? I left Ubuntu almost ten years ago, after 5 years of using it, when they started using MIR instead of Gnome2 and I replaced it with Linux Mint and I haven't looked back. This whole snap thing looks like the new weird decision made by Canonical to make their faithful users leave :/

If you have proprietary drivers, you'll need to prepare a USB stick with them downloaded onto it. They won't be on the installer image. On my older 2011-era laptop, that's the wifi and wired network that need those drivers. It's a bit of a pain.

Generally it's not the drivers but the firmware for those devices, i.e. code that runs inside the device.

I think it's an over-zealous position from Debian not to redistribute firmware. Even systems that are very strict about licensing, like OpenBSD, redistribute firmware, because they have some common sense.

Re: Ubuntu 20.04 LTS’ snap obsession has snapped me off of it

#460

Post by pnako »

koheripbal wrote: post #445
input_sh wrote: post #313

Earlier quoted context omitted.

If you're running Ubuntu's server, odds are that you're SSH-ing into the box instead of running graphical interface. Unless you specifically install snaps, I don't see how this would affect you.

Perfect. So I guess that means APT is still the same, correct?

Yeah apt is still fine and I've never seen it update anything behind my back.
Post reply on HN