zyga

snaps work on anything that has systemd so I don't quite know where you got the idea is that it is mostly limited to ubuntu.

There are several reasons but at some point we can use user namespaces to remove them. I'm not particularly a HN person so I won't go into details but it's possible to drop the setuid bits sooner rather than later.

It's still work in progress but snaps genuinely make packaging easier. There are rough edges, especially on the desktop, but those are all being worked on, in collaboration with flatpak actually.

It will take a while but in the future it will not be any worse at runtime and it will be much, much easier to package and run apps across releases and OSes

IIRC GNOME removed support for snaps from gnome-software so this was the only way forward.

It will be on the next reboot/login. Due to some bugs setting up PATH is hard (harder than other variables and much harder than it should be) so we did the best we could (require a logout/reboot)

Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates).

Sure, you can do static linking, you just don't have to and this is not how snaps work.

It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.

With my upstream developer hat and Ubuntu developer for about a decade hat on I really call BS on this. This is very hard in practice. It's hard even when you know things very well just because it is very complex and involves multiple pieces moving across multiple organisations and people.

Snaps, flatpak and appimage really make the aspect of distribution of free software less crazy. It is a hard problem to solve, we will get some things right and some things wrong. We will learn in the process. Eventually the platform may become useful for proprietary software but it will first and foremost improve for FOSS.

If you are on a niche distribution you are missing out 10s of thousands of applications because it is packaged for Debian or Fedora and not for your system. If you are on Debian stable you miss out that important update or that new feature that you won't have for the next months or more. If you are on the packaging side you know how it is like in the trenches.

I really cannot believe anyone who has done packaging or upstream development to not acknowledge those real world issues. Packaging is extremely hard because we all made it so.

This is a step towards making it less hard.

Hey there.

In snapd (which is implemented in mostly go) we have this problem a lot. The real issue is that certain system calls fail if more than one thread exists in the calling process. One of those is setns(2), as is documented in the manual page.

What I ended up doing is to use a small C preamble that parses command line arguments, figures out where to go and uses setns before the go code even begins initializing.

This solved the particular case we were working on but in my opinion golang's opinionated approach to threading is not suitable for writing many system tools in it.

My wishlist item for golang 2.x is a build mode where threading is 100% under developer control but this seems to be at odds with the design for non-blocking IO.