Hacker News new | ask | show | jobs
by toyg 2019 days ago
With a bit of effort it’s a solved problem, however as soon as that was sorted, developers started using snaps and flatpaks that just Do Not Care about your system settings... and we’re back at square -1, because now you won’t even get consistency between Gtk apps and Gtk apps.

The Linux desktop sometimes is like a bad comedy sketch.

4 comments

Well now I've gone from not caring about snap/flatpak (only selling point seemed to be ease of install; I've never had a problem with arch & the AUR) to making mental note to steer well clear if the temptation ever began to set in.
Yes snap is bad. Compared to the AUR qhere you can read the build script, snap is compiled by someone else and the build script isnt available to perform yourself, at least as far as I looked.
The advantage here is that malware can't be shipped as part of the build process.
I tried Ubuntu for a couple of weeks because I felt that the installation procedure for Arch would take some time for me to set up and I wanted to be up and running a bit faster.

After 4 weeks and every app having so many hoops to jump through because of snaps to get them working together I jumped ship and went back to Arch and the AUR. It's just such a difference in user experience. I feel that Ubuntu is doing a big disservice with snaps (haven't used flatpack that much) to the Linux Desktop community. If it's impossible for me to understand how to use it efficiently, then there is no way in hell I will point my father towards Ubuntu.

Out of curiosity, which apps do you use that come packaged in a snap? My Ubuntu 20.04 tells me this:

  $ snap list
  Name                 Version                     Rev    Tracking         Publisher   Notes
  canonical-livepatch  9.5.5                       95     latest/stable    canonical  -
  core                 16-2.48                     10444  latest/stable    canonical  core
  core18               20200929                    1932   latest/stable    canonical  base
  gnome-3-28-1804      3.28.0-19-g98f9e67.98f9e67  145    latest/stable    canonical  -
  gnome-3-34-1804      0+git.3556cb3               60     latest/stable    canonical  -
  gtk-common-themes    0.1-50-gf7627e4             1514   latest/stable/…  canonical  -
  snap-store           3.38.0-55-geb45541          498    latest/stable/…  canonical  -
I think it's the bare minimum before utterly removing all support for snaps [1].

I installed everything I need either as .deb or docker. BTW, slack has a deb on its download page.

I installed another 20.04 on my old laptop from 2006 yesterday because I read that its kernel would finally support again the old ATI X1600 graphic card. It does. When I run emacs and thunderbird from terminal it told me "command not found" and something along the lines of do you want to install as a snap or with apt? I run the apt commands.

[1] https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-...

Thunderbird, Kdenlive, Darktable, Gimp, KeePassXC, VLC, Minecraft

Those are the ones I remember. I needed to install them via snap because the deb packages were too old to be able to open my files which I copied over from my Arch installation.

This prompted my to investigate. I'm on Thunderbird 68 and the latest release seems to be 78. I think I only need the features of Thunderbird from 15 years ago, so that's ok.

VLC is 3.0.9.2 and GIMP is 2.10.18. No Kdeenlive, Darktable and Minecraft. I'm using KeePassX (not XC) version 2.0.3.

Of course I would install snaps if I absolutely needed an app distributed only as snap but I'd rather use debs.

> I'm using KeePassX (not XC) version 2.0.3.

Note that KeePassXC is the continuation of KeePassX, which is defunct (last release in 2016, only two commits since for new Qt versions)

I mean, it's just back to the state of windows where even most of Microsoft's apps aren't consistent with each other
Windows actually used to be decent and fairly consistent, but I agree that it's gone to shit in the last decade. They botched scaling to HiDpi and fragmented their UIs in the sad attempt to chase convergence with touch UIs.
did it ? except win 3.1 (but then I was a small kid) I remember a huge majority of apps having their own little fancy skins in 98, XP, etc
Majority? Not as I recall it. Some, yeah - famously winamp, which made it compulsory for music players (hence generating a river of tacky UIs). But in my world the majority of apps had the good old “top-bar-menu-icons, File menu, Edit menu, etc” format.
They are my last hope to get a decent UI now.
Do snaps/flatpaks really not look at your local configs? Thats... terrible. I've avoided them already anyway because they seem like wholly unnecessary (and quite significant) bloat.
Flatpak does respect your GTK+ Theme - but you have to either have it installed in ~/.local/share/themes or youbhave to download your theme as flatpak package aswell. But that implies that someone has to maintain the flatpak packge.

While the most popular themes are available, more "niece" themes are missing. Do a `flatpak remote-ls flathub | grep --color "org.gtk.Gtk3theme"` to see all available themes.

Note: I'm maintaining a theme on flathub.

Maybe it's just me, but distro repo usually has only esoteric and metro themes, so if I want something usable, it ends up in .local.
No, probably because that's outside their scope and so they're not allowed to read them.
Surely the sane thing to do security wise would be to mark each flatpak as needing config files foo and bar, and sticking those into the sandbox as well on launch. The app itself doesn't need filesystem access at runtime. Linux apps suddenly not reading standard config files on my system would be a pretty big downside.
I think part of the issue is that technically you cannot guarantee that config files written by the system-installed toolkit can be safely used by the flatpak-shipped toolkit. This said, I think flatpak actually makes an effort to use the ones available in the user’s home folder, whereas snap just does its own thing and screw everyone else.
They do by the way of an xsettingsdaemon (so not accessing directly) for security reasons. The obstacle instead is that they are self-contained, so they should not depend on the theme files outside their system. Hence, they will read what theme you are using and then inside their system look for a matching one.