Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>You can’t audit them, hold them, modify them or even point snap to a different store.

In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.



That is, as long as the package publisher distributes the source. While it's the case for the some standard repositories, packages in "restricted" (some of "multiverse" too) and third-party apt repository can be published in binary-only mode. You have no ability to at the source in those circumstances, even if you apt-installed them.


You are not required to publish source packages, most of the third party repos I use either don't have them or they are surprisingly useless because I don't have the build environment they were executed in.


I'm not sure how this is relevant. You're not required to publish source debian package either, yet there is still a nice command to use in case the source package exists.


Sure because Snap is designed to be able to distribute closed source applications. Part of the reason Snap and Flatpak exist is that distributing binaries on Linux is an enormous pain.


So allow viewing sources for the open source packages. If sources aren't available, then the user can easily opt not to install the binary.


Still it's an improvement over the current situation. Using snap IMHO only makes sense with closed-source or Open-source software that you don't want to self-compile but at the same time there is only a package available for a different distribution. So a typical installation procedure might be to forcibly install it with dpkg while ignoring the dependencies which cannot be resolved automatically. (Or worse, convert rpm to deb and then install it...) Of course the source is still downloadable, on the other hand, reproducible builds are anyway far from standard. I would prefer snap any time over other more crude installation methods if compiling is not viable.


> distributing binaries on Linux is an enormous pain.

It doesn't have to. Packaging using FPM [0] allows many targets (deb, rpm, etc) and using ELF2deb [1] (shameless plug) allows packaging any files to a .deb with no effort.

[0] https://github.com/jordansissel/fpm

[1] https://github.com/NicolaiSoeborg/ELF2deb


That's not the difficult part. The hard part is compiling a program that doesn't depend on Glibc 2.X when your users only have 2.6 or use Musl or whatever.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: