1. 26
  1.  

  2. 17

    Maybe I’m an outlier, but I’m incredibly tired of this garbage of trying to transplant exploitative for-profit concepts into Linux distributions?

    I’m using free software because I neither want this, nor need this.

    (That Ubuntu is slowly trying to force people into using Snap is the straw that breaks the camel’s back. I’d rather move to another distribution than deal with this shit.)

    1. 6

      I don’t understand what you mean by “exploitative for-profit concepts”. Could you expand on that?

      1. 7

        If you look at the various “app stores”, they are pretty much full with this dystopian hellhole of apps that want full control over the device and your personal data (either immediately or at some later point in time when you put effort into using it) to sell your information and display ads.

        The app store vendors’ half-hearted attempt of cutting back on this surveillance capitalism with these feel-good permission info screens doesn’t solve the primary issue:

        These are untrustworthy applications built by untrustworthy companies – I wouldn’t want to run them even if I had the world’s best sandbox running on my device.

        Packages in Linux distributions simply don’t have the issue: The expectation is that the developers are trustworthy and have their users’ interests in mind.

        Sandboxing is simply not an useful tool to encourage ethical behavior – it makes things users want either hard or impossible, while not being powerful enough to actually curtail harmful behavior if it existed.

        1. 3

          Packages in Linux distributions simply don’t have the issue: The expectation is that the developers are trustworthy and have their users’ interests in mind.

          And even in some cases where developers do send analytics data or put ads in applications (e.g. as Zeal used to do), some distributions patch the upstream code to remove this code.

          However, I still think there is a place for application bundles. Some distributions just move slowly or people are bound to LTS versions. Desktop applications tend to get stale in such a setup and it’s nice to be able to install applications out-of-band. macOS had a long history of application bundles before code signing, sandboxing, and app stores. However, when an application is not provided by a distribution, you probably want signed bundles (just as distributions GPG-sign package metadata), and possibly sandboxing (though I don’t think sandboxing is good enough yet to allow arbitrary untrusted applications).

          1. 4

            I think the approach of projects offering their own repositories with current versions of their software is a pretty good idea.

            1. 3

              It is a lot of repeated work for each distribution.

              1. 1

                But if projects offer their own repositories, aren’t we back to one of the problems you cited with app stores?

                These are untrustworthy applications built by untrustworthy companies – I wouldn’t want to run them even if I had the world’s best sandbox running on my device.

                Packages in Linux distributions simply don’t have the issue: The expectation is that the developers are trustworthy and have their users’ interests in mind.

                From what I understand, there are a few problems with using distro repos for such software:

                1. They’re necessarily slower than the developer’s release cadence, and the developer of the upstream software has limited control over providing new versions to package maintainers
                2. They’re beholden to the library versions provided by other package maintainers. If a dependency of your software isn’t up to date, that means that either the package maintainer, or you, need to adapt to the API of that older version for just that platform.
                3. Maintainer-provided/applied patches make your software on that platform deviate from upstream or in the worst but rarest case, introduce new bugs specific to that platform.

                I think providing software bundles for some applications do address these problems (although introduce other problems as well), and are useful in the case of fast-moving desktop applications. I don’t think they obviate package repos at all, nor should distros move towards obviating package repos. They solve different problems.

            2. 1

              Is snap/flatpak’s goal really to make running untrusted software less dangerous? I was under the impression that their only aim was to make distribution easier and to mitigate security issues the software itself may have.

          2. 4

            I’m using free software because I neither want this, nor need this.

            This is why we have community-driven distributions. In Debian, for example, maintainers are required to vet packages and also disable any minor privacy invading function.

            I also add external sandboxing to daemons as part of the packaging. Sadly some upstream developers strongly reject the idea of sandboxing.

            1. 2

              Yeah, I’ll probably end up running Debian in the mid-term; considering that synaptic is a hard requirement for me.

              I probably need to patch the font rendering though, which is pretty annoying that Ubuntu still seems the only distribution that gets that right out of the box.

              In the long-term I’m looking for an operating system that is a meaningful upgrade to the current repository system (like distri) that has a Rust-only userland (which enables me to actually understand and modify the code I’m running, unlike C/C++).

              1. 0

                I also add external sandboxing to daemons as part of the packaging. Sadly some upstream developers strongly reject the idea of sandboxing.

                I understand this impulse, personally. It has nothing to do with the intent of the packager. It’s all about the odd fallout that the sandbox system in question can lead to. Chasing bugs from a user running your software in some sandbox you’ve never tried would really be aggravating. In part because the packager isn’t who the users complain to. It’s the author.

              2. 2

                if you are interested in packing stuff and not control, I think appimage is a better system anyway. Basically just an elf file with a squashfs appended.

                1. 8

                  I think normal package repositories have been perfectly fine for the last 2 decades and are mostly fine today.

                  For the future, I’m looking forward to something like distri.

                  1. 2

                    If I’m developing software I don’t want to have to generate packages for N different distributions.

                    Distributing my software in some way that doesn’t depend on the OS is appealing (though I prefer the Go approach of just statically compiling).

                    1. 3

                      If I’m developing software I don’t want to have to generate packages for N different distributions.

                      So don’t. That’s the distributions’ problem, not yours.

                      1. 3

                        Distros don’t accept your software unless it’s already popular. Most Linux users prefer to install software from the distribution, so how does it get popular?

                        The simple answers are:

                        • Be part of an existing social connection so that demand can build up even before your software becomes widely-used, or, better yet, become a hard dependency of an already popular package. This is a “good old boy network,” and we should not stand for that.

                        • Package, with distro packages yourself. This requires a bunch of work to support even the popular ones, and leaves the unpopular distros out in the cold.

                        • Package, as a static binary or a hand-rolled installer. This has zero support for the security mitigations that motivated dynamic linking in the first place. This, along with source packages annotated with dependency metadata in a standard format, seems to be the go-to for new languages though.

                        • Distribute source code. The biggest downside of this approach is that there doesn’t exist a standard way to define the dependencies of a source tarball, so installation is a pain.

                        1. 1

                          That last one depends greatly on your development environment. requirements.txt works reasonably well for python. Go has a standard way to define its dependencies too.

                          But there is a middle ground answer to your question… while distros don’t accept and distribute your software ‘till it’s popular, you can add PPAs, COPRs, or bsd ports on your own. These let you define dependencies in the ways that make sense for what you are targeting and don’t require official approval.

                          1. 1

                            But there is a middle ground answer to your question… while distros don’t accept and distribute your software ‘till it’s popular, you can add PPAs, COPRs, or bsd ports on your own.

                            I literally listed that as option 2.

                            1. 1

                              Sorry. I didn’t read it that way. Obviously a mis-read.

                          2. 1

                            Distros don’t accept your software unless it’s already popular.

                            None of this is generally true. Most distributions will accept any package for inclusion as long as it fits within their project guidelines and–much more importantly–someone has committed to maintaining the package going forward.

                            This has nothing to do with popularity, it has to do with whether or not any volunteer OS package maintainer feels it’s worth their time to support. If you can’t get an existing maintainer to take an interest in your software, then you might have to step up to be a maintainer yourself. If that sounds like too much work to be worth it, then your software is probably not as valuable as you think it is.

                          3. 2

                            But I may also have the competing desire to make my software easy to use and install.

                            Compiling my code statically solves this problem without me having to faff around with a bunch of different distros.

                            Now I mostly use Julia and there’s a nice project (Artifacts system, Yggdrasil) where more and more non-julia dependencies are being (mostly) statically compiled and made available as packages that the Julia package manager can deal with. In my opinion, this is a much better way of distributing software than the traditional linux package managers.

                            Nix and distri are similar to the Julia way of doing things.

                            Though the Julia system is also cross platform to Windows and BSD in many cases, where of course Nix and distri are not.

                            1. 3

                              Compiling statically just replaces one problem with another: now there’s bloat and extra bundled libraries that won’t get security patches when their system copies get patched by the distribution.

                              Honestly, just be content to relinquish control. Let distributions do whatever they want. And if they don’t want to package your software, maybe your software just isn’t that important, or maybe it’s not important to them to have the latest release packaged every day.

                              1. 2

                                If some other schmuck wants to distribute my software some other way, then more power to them, but it’s not unreasonable to want to be able to easily run my software on a bunch of different linuxes without faffing around.

                                And I’m not convinced by the arguments about bloat and security (and I am not the only one: https://ro-che.info/articles/2016-09-09-static-binaries-scientific-computing)

                              2. 2

                                Yggdrasil

                                You briefly made me think “Holy shit, that’s still aound?!

                                The Yggdrasil I remember: https://en.wikipedia.org/wiki/Yggdrasil_Linux/GNU/X

                                1. 2

                                  I hope (and kinda expect) that this new Yggdrasil will last a bit longer. The reproducible research effort aims for decades of reproducibility ;)

                              3. 1

                                It is when distribution quality issues are then sent to you, or they don’t update in a timely manner…

                                1. 2

                                  My attitude when this happens with Octave is still the same: sorry, not my problem. Please talk to your distro managers instead.

                                  We have pretty good packagers, though.

                              4. 2

                                If I’m developing software I don’t want to have to generate packages for N different distributions.

                                Isn’t that pretty much a solved issue with OBS and similar services? And if people want to use your software, they will start packaging it either way, so there isn’t that much effort required from our side.

                                I prefer the Go approach of just statically compiling

                                My approach is too avoid software written in Go (as well as PHP and Node.js) in general due to software quality/mindset issues. :-)

                                1. 2

                                  OBS

                                  I’m not familiar with this, but it looks like I would still have to find out the name of all my dependencies on each distro and so on: https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.package_formats.html

                                  I’m not interested in doing that. But if I don’t do that, my software is typically harder to install on $linux than on windows.

                                  I just want to ship a binary and I don’t want to get any grief about Debian’s ancient libc or whatever. I want to give you an x86 binary and have it run on any linux with a compatible kernel ABI. It’s very annoying wanting to use some decade old software and having to fight to get things to run.

                                  avoid Go

                                  You do you. I also prefer to statically compile C and Rust code.

                                  1. 1

                                    And if people want to use your software, they will start packaging it either way

                                    This seems to be based on the assumption that your users are all programmers.

                                    1. 1

                                      My approach is too avoid software written in Go (as well as PHP and Node.js) in general due to software quality/mindset issues. :-)

                                      You’re missing out on quite a lot of high-quality software due to those mindset issues.

                                      1. 1

                                        Can’t think of any.

                            2. 3

                              It would be interesting to further compare this with Firejail and bubblewrap – both allow you to isolate any piece of software running on your system, i.e. they don’t necessarily tie you to a single distribution mechanism. I’ve used Firejail for Firefox with great success.

                              1. 2

                                Yeah, heads up with firejail. Use a SELinux sandbox(1) instead ;-) I’ve tried it and the result is really worth it, in my opinion. I’m using it often, for lots of sites I don’t trust (which is close to anything, these days)

                                1. 1

                                  heads up with firejail. Use a SELinux sandbox(1) instead

                                  Why?

                              2. 1

                                Here is a docker run command that lets you run Firefox from within a container:

                                docker run --rm -it --net=host --shm-size=2g -e DISPLAY -v $XAUTHORITY:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix [image]
                                

                                In the container, just start “firefox” from the command line and it will pop up on the screen of the host.

                                Installation of Firefox depends on your the image you use. If you use Debian:10-slim for example, you can install Firefox with:

                                apt-get install --no-install-recommends firefox-esr -y
                                

                                It works quite nicely and probably gives less permissions to the browser then Flatpak and Snap.

                                1. 4

                                  As far as I can tell, you’re running Firefox as root in the container? If you mount any local volumes, that allows creating suid files on the host, among other things.

                                  Docker (still) isn’t security software, it’s a convenient dependency wrapper.

                                  1. 2

                                    Isn’t the recommendation to run with a less privileged user, even if you have user namespaces?

                                  2. 1

                                    The gist I’m getting from this is that both implementations have some pretty serious flaws and that someone should create a 3rd standard that mixes the best of both.

                                    1. 1

                                      I hope people realize that containers are not for security, but for (bundly!) dependency handling! There are proper way to sandbox software under Linux, and that would be using SELinux.