Live data from Hacker News

Disabling Snaps in Ubuntu 20.04

kevin-custer.com

351–360 of 436 posts

Re: Disabling Snaps in Ubuntu 20.04

#351
post #318

Earlier quoted context omitted.

> Half of the utilities I install out of the box on a fresh macOS are built in, and the annoying stuff that used to be editing arcane files is now easy preference settings That's been the case with KDE for 15-20 years now. KDE 3.5 was a great environment (and Trinity (TDE) is a modernized fork of it). Note that, this year, KDE added telemetry to their Plasma desktop environment. Of course, it's opt-in, so it must be…

Thanks for letting me know. It looks like the telemetry (kuserfeedback) isn’t even a dep of the Gentoo plasma-meta metapackage, so I don’t think it was even built on my system (but will double check when not on mobile). If I dabble with debian or kubuntu I will make sure to mitigate it, thank you for making it known, keep up this kind of good work! It’s a real shame that they found it necessary to even build a teleme…

The grandparent is overreacting.

1. KDE's telemetry is opt-in (as you mentioned)

2. All data is anonymized

3. You can select which information you're comfortable to share

4. If you have it turned off, the data is recorded on your hard disk.

5. That data was always recorded in order to enable other features like "Recently used documents".

Here's some explanation:

https://www.reddit.com/r/kde/comments/fmgyy9/kuserfeedback/

Honestly, KDE has been one of the most open, privacy aware and idealistic communities out there. The criticism is quite unfair.

(I used to be a KDE contributor)

Re: Disabling Snaps in Ubuntu 20.04

#352
post #9

Earlier quoted context omitted.

And it's a pretty good one since the experience with having a large catalog of useful software in Flatpaks has been awesome and largely seamless. I just wish Canonical wasn't off doing their own thing or had started out in the open from the start so it would have a chance of being a useful standard instead of the weird Canonical store.

Considering that Flatpak was essentially a hostile fork of the AppImage project motivated by Red Hat's insatiable hunger for control, I find it ironic when Flatpak supporters complain about Canonical "doing their own thing".

FlatPak has nothing to do with AppImage, is in no way shape or from a fork of it.

https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

AppImage only solves the easy part of the generic-linux-app problem, namely running the packaged appimage; it does nothing to solve the hard parts: how do you build the application so that it will actually run on generic Linux distributions, and sandboxing.

Re: Disabling Snaps in Ubuntu 20.04

#353
post #319

Earlier quoted context omitted.

If all you're looking for is the ability to get the upstream updates immediately, you can also just download the tarball version and unpack it somewhere under your home directory. Then dump a .desktop file for each in ~/.local/share/applications/ so it shows up in your app menu. No startup slowness, and you'll still get the vendor-provided updates as they're released.

I'm curious why this got downvoted -- would it not work?

I have no idea why that reply got downvoted as well. It is essentially how I installed Firefox on my Debian stable laptop , and it has been working great as far.

Re: Disabling Snaps in Ubuntu 20.04

#354

Earlier quoted context omitted.

Docker is poorly designed as well.

can you elaborate? I can google for "docker sucks" blogposts, but I trust the HN opinion to be a bit more thoughtful. Any specific pain points you can identify?

I think what the author wanted to say is that the tradeoffs made by Docker's authors are different than those he would have made.

Re: Disabling Snaps in Ubuntu 20.04

#355
post #63

Earlier quoted context omitted.

Does it force the community solution to improve? If the options are community or Canonical does that competition have benefits to both? Not sure Canonical are thinking that explicitly but maybe it’s just hedging their bets if the community solution doesn’t work out.

But this is a false dichotomy, because Flatpak is a project controlled by Red Hat. Unless by "community" project you mean AppImages.

FlatPak is a project initially hosted on freedesktop.org infrastructure with distributed copyright ownership under a copyleft license. It was initially founded by Red Hat employees but has attracted substantial support and contributions by companies such as Endless and Collabora, not to mention volunteer contributors.

The sandboxing part was spun off to the bubblewrap project, which has been adopted by the community for other purposes, such as Gnome's Epiphany browser.

https://github.com/containers/bubblewrap

https://blogs.gnome.org/mcatanzaro/2020/03/11/epiphany-3-36-...

SnapCraft on the other hand is a project that requires copyright assignment to Canonical Ltd for contributions, which presumably has the intended effects of keeping non-Canonical contributions close to zero.

https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.m...

Re: Disabling Snaps in Ubuntu 20.04

#356

> I lean more toward Flatpak as it is more performant What is "performant" supposed to mean here? Is Flatpak faster than Snap? more compact? simpler? more reliable/secure? easier to use? more efficient in terms of cpu/memory/communication/power/etc.? all of the above?

> Is Flatpak faster than Snap?

Yes, Flatpak is just bind mounts and namespaces. It doesn't have the overhead of the squashfs images.

Re: Disabling Snaps in Ubuntu 20.04

#357
post #244

Earlier quoted context omitted.

It worked very, very well on Unity. It also works with other DE like Plasma but I personally find it horrendous on other aspects. I'll probably give Budgie a go.

If my primary monitor is to the right of my secondary monitor, do applications open on the primary monitor or the 'left' monitor? Also, do applications remember which monitor they were last opened on?

That depends on the DE.

On Unity it opens on the monitor you're focusing.

Sometimes it's a bit tricky. Let's say you're focusing on a Window on your main monitor but your mouse cursor is in the secondary monitor. If you hit the meta key, the menu will show on the secondary monitor. Now, if you open an application without using your mouse it'll open on your main monitor, where you had the focused window but if you click on the app it'll open on the secondary monitor because the click changes the focus.

Some stuff is not as polished as it should be but if we take in consideration that Unity has been abandoned for 4 years and before that it wasn't developed at all as all the effort was put into Unity8, I'd say it's a pretty damn good DE.

I hated it when it came out but now I can't live without it.

Re: Disabling Snaps in Ubuntu 20.04

#358
post #280
post #120

Earlier quoted context omitted.

multiple monitor support in Linux is high on my list of reasons I keep switching back to my Windows partition.

Is multi monitor support in Linux broken? I've been going strong for ages with proprietary nvidia drivers and i3/dwm.

I wouldn't say it's broken. But Gnome Shell is made for a single monitor so working with more than one makes it a pain in the ass.

Re: Disabling Snaps in Ubuntu 20.04

#359
post #105

Earlier quoted context omitted.

Snaps certainly have some usability problems. E.g. to use videoconferencing in Chromium I had to give it rights to connect to record audio explicitly. I expect you needed to do something like that for the VS Code snap.

I did that too, and it works for one minute, every time I start the browser. Firefox it is.

It used to work, with the latest update audio doesn't work anymore in Chromium (although it does see the device), I'll have to report a bug. (snap connections does show audio-record connected)

Re: Disabling Snaps in Ubuntu 20.04

#360
post #9

Earlier quoted context omitted.

And it's a pretty good one since the experience with having a large catalog of useful software in Flatpaks has been awesome and largely seamless. I just wish Canonical wasn't off doing their own thing or had started out in the open from the start so it would have a chance of being a useful standard instead of the weird Canonical store.

Considering that Flatpak was essentially a hostile fork of the AppImage project motivated by Red Hat's insatiable hunger for control, I find it ironic when Flatpak supporters complain about Canonical "doing their own thing".

Got a source for any of those claims?
Post reply on HN