"Lubuntu was formerly a distribution for low-end hardware, but we have refocused." , run good in "old" machine

Yeah, I did further texting. With a sufficiently large number of snaps, Lubuntu will have memory issues in boot due to the automounts.

Had that not been the case, the problems wouldn’t be so significant, but that single behavior ruins it for lowend hardware.

Definitely not the best option for a lightweight distro. There should be a way to disable automount at boot.

2 Likes

I do not have the impression that you know how snaps work. And your usage of the terms “static library” and “shared library” is confusing (the answer below is using your definition).

Snaps can have their own libraries which are not shared with other snaps. This avoids the so-called “dependency hell”. This approach allows you to run a snap with a library in a different version than is installed on the system.

On the other side snaps can (must) depend on other snaps. And in fact, most of the snaps depend on snapd and on the core* snaps.

Reading the documentation helps you to understand the topic. From the snap documentation

Build dependencies are required for your part to successfully build or compile on the development host, while staging dependencies are required for your snap to run.

And by the way: Also with .deb packages you can install binaries which are (compiled as shared library but) not shared with other binaries.

It is the decision of the packager how the packages are built (for snap and for .deb packages).

The memory is there to be used. Memory management is very complex and it is very hard to measure memory usage.
If you do not have enough memory, you usually have two ways to improve the situation:

  • add more memory
  • change your behaviour or usage of apps
2 Likes

“dependency hell” minimizes memory usage. If it is managed correctly it is not “hell” at all, but much more efficient memory management. In my opinion “hell” is waiting 30 seconds for firefox to startup.

The documentation is meaningless to me and could be outdated or even just wrong. I am looking at real world usage.

The snaps I have used (firefox and chrome) are so memory intensive some older machines with 4G can grind to a halt. Those same machines run fast and smooth with the .deb versions of browsers with all that “dependency hell” as you call it.

Of course a modern machine with 4G+ RAM this is not an issue. I am specifically talking about the early 1st or 2nd generation 64-bit CPUs (AMD Bobcat / 1st generation Intel core / Atom) based machines with a few Gigs of RAM. This class of machine is perfectly useful with a modern distribution unless snaps are used.

6 Likes

If memory is there to be used, then what’s the whole point of this distro? “CPU clocks are to be spent”, “fancy graphics are to be taken advantage of”…

If that were so, I’d just switch to Ubuntu.

2 Likes

I have Lubuntu on a low end Chromebox (dual core 1.4Ghz Celeron) in which I added RAM now at 16gig, so my weakest link is the processor.

Outside of a few seconds added in the initial startup on a snap, I don’t have a perceived difference in responsiveness or compute.

2 Likes

With how many snaps?

16gb of ram is plenty actually.

1 Like

Two snaps.
I think as far as processing needed, snaps are similar to say a regular deb

1 Like

But I see, you do not read documentations.

Either you did not test the Firefox snap in the last months or your hardware is very old.

If your PC has 4 GB of memory, the OS should use all of the 4 GB. If you take out 2 GB, the same OS will use 2 GB. As long as 2 GB are enough (that is the case with Lubuntu), you will not see a big difference in performance.

If a system has 4 GB of memory it will normally allocate more memory for performance reasons. As I already wrote memory management is very complex and it is therefore not easy to measure memory usage.

1 Like

Don’t forget you can just remove Snaps entirely. We left them in Lubuntu since Mozilla had Canonical move Firefox to being a Snap, and Firefox is the browser in the Ubuntu world. But we have thought about replacing it with Falkon, and we might revisit that at some point. Anyway, removing Snaps entirely is super easy on Lubuntu, and someone here even wrote a guide on how to do it, that I’ll dig up and add to this in just a bit.

edit: Found the guide. How to install firefox (non snap)

3 Likes

No I don’t read documentation from Wikipedia which is often just plain WRONG! Wikipedia is far from the golden source of knowledge.

YES EXACTALLY I am talking about very old hardware. I have stated that numerous times above.

I gave up testing firefox snaps on old hardware as 30 seconds to load a browser is just ridiculous. Also extentions don’t work, some foreign languages don’t work, bizarre access issues… the broken list is endless.

Anyway it is clearly proven for real world trial and error that snaps for modern browsers take significant memory resources such that a modern PC (roughly 7 year old or less / 4G+ RAM) is required for a pleasant experience.

2 Likes

Ok, so you only read documentation if you like what you see in it.
And you expect very old hardware to behave like new hardware when it loads software from 2022.

1 Like

( Let’s try to keep the topic ‘informative’ - eh? )

Remember that snap uses squashfs, which is a filesystem initially designed to save space.
i.e it stores stuff using compression.
Which also means that it must decompress on the fly, even if snap is warmed up (in place and ready).

This interesting post seems to suggest (albeit 4 years ago),
that snap i/o is twice as slow as an apt package, even when snap is warmed up on high end hardware.

4 Likes

Obviously he doesn’t expect very old hardware to behave like new hardware when it loads software from 2022. That’s why he wants to avoid the usage of the more intensive 2022 software, namely the Snap Firefox package. If one can get better performance without Snap, and they don’t mind the lessened security from doing that (because they’re careful on the Web, for instance), then that seems like a smart decision to keep old hardware alive longer.

Even with the latest fixes to the Firefox snap for faster load times, it still loads slower than the .deb Chrome package that I use, and slower than Firefox used to load as a .deb package if my memory serves me correctly. Snaps are good, when they’re used where they belong, and I very much would like to see them used more frequently in the web browser world due to the additional security they add. They just don’t always fit right on very old hardware. Thus why some of us like to remove it on said old hardware.

4 Likes

Yes. I just don’t aimlessly let others think for me. I look at the real facts and make conclusions based the evidence. I just don’t worship snaps because Canonical endorses how wonderful snaps are.

ArrayBolt3 is much better at articulating my position. I was never a good debater.

Anyway for the record I am not always against snaps. They have their place. My elderly mom who is barely computer literate but an artist has a 2020 TigerLake 8GB Laptop with Ubuntu with snaps. Why ? Because believe me she needs the added protection with a snap based web browser. She doesn’t use extensions nor non-English language components. If needed Fedora Silverblue is an option, but I don’t think it’s needed for her.

Snaps when used intelligently with new IOT devices are a really nice improvement. Getting much needed security patches easier is worth the hit to performance in many cases.

2 Likes

I have absolutely no problem if someone says: “I do not want snaps because I do not like them”. That is absolutely fine because it is a personal opinion.

However, I find it problematic when someone sells their personal opinion as facts. And if I expose these claims as false by citing sources, then of course he knows better whether such sources can be trusted.

I am still using a laptop from 2014 with 6 GB of RAM and a traditional hard disk. I was running the development version of Lubuntu on it (this year I installed Arch Linux with i3 and I am still using this device daily to watch video streams). I was also running the Firefox snap on it. Yes, it was slow to start but I am not surprised. But only the start was slow. Once started I never had problems with Firefox. I just use a few addons.

I often read that the Firefox snap is slower than the Firefox .deb version. I admit that the subjective impression actually confirms this. But when you compare apples and oranges, it is clear that there are differences. And it is even clearer if you like apples over oranges, that apples are much better than the stupid oranges.

Subjective impressions are not good to base a discussion on it. It is better to find a reproducible way to measure the start times of Firefox. A naive approach could be to measure the cold boot times:

  1. start the OS
  2. start Firefox (.deb version) and measure it with a watch
  3. reboot the OS
  4. start Firefox (snap version) and measure it with a watch
  5. repeat this procedure 100 (1000, 100000, …) times and use statistical methods for the comparison

This sounds good (and will very likely prove that snaps are slower to load, I did not test it), but you will obviously compare apples with oranges. Why? Because the .deb version is very likely using libraries which are already loaded. And the snap version needs to load first the snap dependencies (and unpacking the squashfs). And hopefully you see also why you cannot measure the memory consumption easily.

A better approach will be to measure the warm start times (assuming your system does not swap memory):

  1. start the os
  2. start Firefox (.deb version) and close it
  3. start Firefox again and measure the time with a watch
  4. close Firefox
  5. repeat the two previous steps 100 times
  6. reboot the os
  7. start Firefox (snap version) and close it (yes you have to wait probably a few seconds longer)
  8. start Firefox again and measure the time with a watch
  9. close Firefox
  10. repeat the two previous steps 100 times
  11. use statistical methods to compare the results

How much slower is the snap version compared with the .deb version? Is it negligible?

Now you have statistical data for the cold start and warm start performance of Firefox. You can collect also data about the runtime performance.

3 Likes

I’ll add this though will acknowledge it may not be helpful to this discussion…

My primary desktop for years has been a 2009 dell optiplex box with specs

dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

It was originally a beta install of 17.10 (ie. back in 2017) , and soon was release-upgraded every 6 months sitting on the development cycle. I use both firefox (for most sites) & chromium (for anything google related), meaning I started using browsers packaged as snap in mid-2019 (when Chromium switched), and some time later firefox too.

As I’ve stated before, snap browsers were originally slow to load post boot, but that has been drastically improved. As I’ve also stated before, I no longer notice any difference when operating between browsers when they were snap packaged, as compared with deb packaged.

Anyway, that box’s PSU died a lot of weeks ago now, and I’ve been forced to use another box. Not having internet for numerous weeks & other life issues have also delayed my getting a new ‘second-hand’ box to replace it, but until I do, I’m using a different box with the specs

dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

This box is a 2008 dell; and externally looks very different, but as I record my hardware (for QA testing purposes) the key details are identical to my dead primary box. It has numerous Lubuntu installs I do re-install QA-testing on regularly, but whilst I have files & changes on those installs - none of my private keys exist on those installs so I’m not leaking sensitive personal data if I need to file bug reports etc. Instead on this box, the OS I treat as ‘my own’ is a Debian bookworm install (ie. testing).

This current Debian box has deb packages of both chromium and firefox, and I see no difference in speed between this box and my old (by not turning on) primary box (or if I reboot, select Lubuntu jammy, Lubuntu kinetic which use snap packages & compare, nor if I select the Lubuntu focal which has deb firefox too)

Personally - I much prefer my normal Ubuntu install over this Debian box I’m having to use until I get my replacement. (I’ve been very tempted to add my keys to one of the Lubuntu installs, but they change release regularly & I’ll forget which has them, eg. focal will soon switch to become my lunar install system, so I’ve resisted doing it)

If there is a speed difference between deb packages of browsers & snap packages on these old core2quad CPUs, I sure can’t pick it, and I suspect these 13-14 year old boxes would be considered low-end these days.

FYI: I also (only yesterday) wiped my Debian bookworm install on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600) which is only a slightly newer box & returned it to Lubuntu. I can’t really pick differences in using that box either, but that’s as a USER, and not someone using a ‘stopwatch’ and a small sample size. That box has OpenSuSE & Fedora installs too, and to me those are the same as Ubuntu/Debian too.

Note: I think of my Lubuntu installs as Ubuntu installs; so I usually write it the way I have. Probably 80% of the time I’m using the Lubuntu session (meaning LXQt from Lubuntu), but most of my non-QA installs are multi-desktop as well; so I can select & login with Xubuntu/Xfce on occasion, Ubuntu-MATE/MATE too if I wish, even Ubuntu/GNOME for a brief change (some boxes have Ubuntu-MATE replaced by Kubuntu/KDE instead)

I still consider Lubuntu as suitable for low-end amd64 hardware, and FYI: the boxes I’ve mentioned in this thread are boxes I use; meaning they’re near my most powerful! Many of my QA-test boxes are less powerful (ie. core2duo’s).

If anyone is interested why I’m not opting to use the HP 8200 with it’s i5-2400; its nvidia card is inconsistently noisy & I prefer using the core2quad and its quieter video card; and I’ve no intention of moving cards around

3 Likes

Thank you very much, Humpty, for providing that resource. I agree, we must keep this informative, and your post provides quite some interesting info.

I don’t think the fundamentals of that post have changed at all during these years, honestly speaking.

1 Like

Nobody here is selling personal opinions as facts. And nobody is providing false sources.

1 Like

I apprecaite your input, and I agree with 1 snap the difference is not so big. The main issue with snaps is if you install too many (and this amount varies depending on your specs), which could turn your PC from slow to boot to, directly, non-bootable.

The snaps mounting on boot is a big issue for desktop uses if someone pretends to use snaps for a wider set of apps.

Flatpaks, in the meanwhile, don’t slow down your PC except for the lack of resource sharing (which is not completely true either, as flatpaks do share resources between themselves.

2 Likes

Yes, Flatpaks highlight storage space. Also, let’s not forget about complexity (which all package systems have to deal with).

This blog said Flatpak is no more desirable than Snap. I love the way it uses the example of “…For a calculator.”
There’s a bit about Snap too.

“Canonical started converting their basic desktop apps like the GNOME Calculator to Snap in Ubuntu 18.04…”

and whether due to complaints or integration problems,

“…quietly converted them back to normal apps in Ubuntu 20.04.”

2 Likes