Post 9oUPP0WLBXup0BJReC by dthompson@toot.cat
 (DIR) More posts by dthompson@toot.cat
 (DIR) Post #9oUHuzDUllnwaiEfdQ by dthompson@toot.cat
       2019-10-31T14:10:06Z
       
       1 likes, 0 repeats
       
       took a look at https://appimage.org/ and watched the video about how it works. I like the relatively simple design of stuffing a compressed disk image into an ELF file. I don't like how there's no story for *how* you build those images and the level to which you assume that certain things are on a target system. in order for them to have a story here they'd have to invent their own package manager, which is a bad idea for sure. therefore I think what would be more interesting is to take the good part of appimage (stuffing a disk image into an ELF file) and use something like guix to provide the reproducible tool chain for generating the contents of the disk image.
       
 (DIR) Post #9oUHzzI9uvjQGwnlwW by clacke@libranet.de
       2019-10-31T14:39:59Z
       
       0 likes, 0 repeats
       
       @dthompson I would be delighted if guix supported appimage as yet another bundle format!
       
 (DIR) Post #9oUK12dr9CmgrNa4eG by dthompson@toot.cat
       2019-10-31T14:57:49Z
       
       0 likes, 0 repeats
       
       also I interpret portions of the appimage marketing as somewhat distro hostile, like this:"AppImage format is ideal for upstream packaging, which means that you get the software directly from the original author(s) without any intermediaries, exactly in the way the author(s) intended. And quickly. "like, okay, it is true that if you want the latest version of something the quickest way would be to grab an appimage from the author, but by framing it as "the way the author intended" it implies that the work of distributions is inauthentic and of lesser value. that is dumb.
       
 (DIR) Post #9oUKyfrUyJODaHOfgW by kai@ajin.la
       2019-10-31T15:13:54Z
       
       0 likes, 0 repeats
       
       @dthompson consider that there are ancient packages in Debian…but my favorite thing about appimages is that (so far so good) they just work.Of course there are tradeoffs with this setup, which try to be solved by flatpak and snappy. But both of those formats require a pre-installed infrastructure, where as appimages will run solo.TrueOS (formerly PC-BSD) has been using appimage-like packages for years and works very well imho.
       
 (DIR) Post #9oUMjzBh2LJn5PxzXs by dthompson@toot.cat
       2019-10-31T15:33:38Z
       
       1 likes, 0 repeats
       
       @kai the fundamental issue is that each image bundles an unknown number of dependencies, which makes it unclear what software is affected by security issues. even if you were to know which images are affected, you are now dependent on each upstream author to provide fixes for the embedded dependencies. whereas the distro model explicitly tracks the connections between applications and shares commonalities, which makes efficient security updates possible.
       
 (DIR) Post #9oUMzH1sz2l4lWfXsG by kai@ajin.la
       2019-10-31T15:36:25Z
       
       0 likes, 0 repeats
       
       @dthompson right, that's exactly what flatpak and snappy solve by including a known system base.It's a matter of efficiency either way. What is more precious: bandwidth and disk space, or your time? 😋 (This probably reads as much more snarky than I actually mean it. Suffice to say, I'm glad appimage-like containers exist.)
       
 (DIR) Post #9oUNCsdyRh7ZBlyMmO by dthompson@toot.cat
       2019-10-31T15:38:51Z
       
       0 likes, 0 repeats
       
       @kai they don't actually solve it, though. each one still bundles an unknown number of dependencies, but less than it would otherwise. those tools, too, are only useful for edge cases where you care about the latest and greatest more than potential security risks.
       
 (DIR) Post #9oUNKynZRj4qauK7Qu by kai@ajin.la
       2019-10-31T15:40:20Z
       
       0 likes, 0 repeats
       
       @dthompson security is always a spectrum
       
 (DIR) Post #9oUP7OKBwZLlcHEK6S by dthompson@toot.cat
       2019-10-31T15:00:27Z
       
       1 likes, 0 repeats
       
       things would really suck if the standard way to get software on linux was to use appimage!  appimage's usefulness is for edge cases like "I want to use the latest version of Krita the moment it is released."
       
 (DIR) Post #9oUPKflcP9IjTfOLc8 by clacke@libranet.de
       2019-10-31T16:02:31Z
       
       0 likes, 0 repeats
       
       @dthompson For analogy: The Director's Cut is not always the better movie. Editors exist for a reason. 😀
       
 (DIR) Post #9oUPLspnJ2CmIKvF2G by technomancy@icosahedron.website
       2019-10-31T15:36:53Z
       
       1 likes, 0 repeats
       
       @dthompson I use AppImages for my single-player games, and they're a nice fit for small isolated things that aren't worth a distro packager's time to bother with, but I would never consider using them for anything hooked up to a network or exposed to hostile input
       
 (DIR) Post #9oUPOzgaHyW0Pf66yW by roptat@framapiaf.org
       2019-10-31T15:04:45Z
       
       0 likes, 0 repeats
       
       @dthompson isn't appimage designed to support non free software on Linux? It would make sense that for a company, the many distributions make it hard to target Linux users. There are so many package formats, and nobody wants to do the work for them 😢
       
 (DIR) Post #9oUPP0WLBXup0BJReC by dthompson@toot.cat
       2019-10-31T15:08:01Z
       
       1 likes, 0 repeats
       
       @roptat proprietary software is a big use-case for it, but there's also free software use cases, like making it easy to use the latest and greatest version of Blender or Krita without having to wait for a distro to catch up.  I think that's all well and good because there are trade-offs to each.  personally, I'm interested in portable application bundles so that I can easily share games that I've made with Guile that would never make it into any distro's repositories. if I don't provide pre-built bundles, no one will ever try my games because it's too much work to compile it all from scratch.
       
 (DIR) Post #9oUPQDJr5NUYzB326C by dthompson@toot.cat
       2019-10-31T15:10:23Z
       
       1 likes, 0 repeats
       
       @roptat I think dependency bundling is a security nightmare and thus is only worth the risk in very special cases. it should never be the default way to get software on linux.
       
 (DIR) Post #9oUPSeD05AjKxe0BsW by dthompson@toot.cat
       2019-10-31T16:04:07Z
       
       0 likes, 0 repeats
       
       @kai sure but I think bundling dependencies in opaque (as in no graph representing the dependency relationships) disk images for each application is not a sustainable position to be in if you're responsible for the security of an entire operating system, but having an appimage or two for specific pieces of software is manageable.
       
 (DIR) Post #9oUPcq9IXlIAtB89qq by clacke@libranet.de
       2019-10-31T16:05:57Z
       
       0 likes, 0 repeats
       
       @kai @dthompson The ancient packages in Debian still benefit from the latest point versions of their dependencies. Ancient AppImages wouldn't'
       
 (DIR) Post #9oUufTdtZIqM6X3CPA by grainloom@cybre.space
       2019-10-31T16:04:43Z
       
       0 likes, 0 repeats
       
       @dthompson It's not really true though, because you might need a version compiled with different flags.The best way would be something like a Nix or Guix build, with binary substitutes if you don't have the resources to compile it on your own.
       
 (DIR) Post #9oUufVMx9GTnSZ8hH6 by dthompson@toot.cat
       2019-10-31T16:10:08Z
       
       1 likes, 0 repeats
       
       @grainloom yeah I think guix transcends the traditional distro setup by allowing for both a stable base system *and* bleeding edge leaf packages without compromising on security.  it has also made good progress on supporting the appimage-like/docker-like model for the cases where you are a developer that needs to distribute software to an unknown target system, and it has *more potential* then appimage or docker precisely because it's a full fledged package manager whereas the other tools only speak in terms of disk images.
       
 (DIR) Post #9oUukL86e6rH9OV4me by sl2c@cybre.space
       2019-10-31T17:18:59Z
       
       0 likes, 0 repeats
       
       @grainloom @dthompson the idea of Nix/Guix builds is that they're supposed to be pure functions of the build inputs so it makes sense for binary resources to widely exist regardless IMHO
       
 (DIR) Post #9oUukLURJ4isGewuau by zenhack@mastodon.xyz
       2019-10-31T18:00:51Z
       
       1 likes, 0 repeats
       
       @sl2c @grainloom @dthompson what I'd love to see is a tool integrated with guix/nix that builds an appimage like package, but also embeds enough metadata to:* Discover what packages it contains, so auditing for vulnerabilities is easy.* Reconstruct the build environment automatically.I'd like to be able to just do something like `guix- appimage reproduce /path/to/executable`
       
 (DIR) Post #9oUumj6oSllM6F28Jc by zenhack@mastodon.xyz
       2019-10-31T18:10:49Z
       
       0 likes, 0 repeats
       
       @sl2c @grainloom @dthompson possibly somewhat incendiary: the distro model for getting software for users securely frankly sucks. If we can't seriously offer a better answer to users to the problem of "how can I be sure to not get burned by malware"  than "only install software from the app store^W^W repository," why should a non technical user care about theoretically being able to run whatever software they want?
       
 (DIR) Post #9oUumjqthQcsPAaw9A by grainloom@cybre.space
       2019-10-31T18:20:56Z
       
       1 likes, 0 repeats
       
       @zenhack @sl2c @dthompson Guix even makes sure that you can bootstrap the whole system from a trusted binary seed (that is becoming smaller and smaller each month), you cannot get that from any other model but a distribution with purely functional packages
       
 (DIR) Post #9oUuogs9kUWrk779PM by zenhack@mastodon.xyz
       2019-10-31T18:13:30Z
       
       1 likes, 0 repeats
       
       @sl2c @grainloom @dthompson ultimately I want us to move to a model where most software is obtained directly from upstream, but subject to POLA to the point where doesn't really need to be trustworthy on the first place.
       
 (DIR) Post #9oUurV73vXqA8jQVnc by dthompson@toot.cat
       2019-10-31T18:22:11Z
       
       1 likes, 0 repeats
       
       @zenhack @sl2c @grainloom I agree that this is a good long-term goal. a goal that probably can't be achieved with linux. I support the distro model because it's still the best system available on the systems we have, but even in this situation we can move towards more upstream provided software. for example, both guix and nix support "channels" so maybe the Blender foundation could make a blender channel that has the freshest stuff for example.
       
 (DIR) Post #9oUuvTb1VZyWatKueW by zenhack@mastodon.xyz
       2019-10-31T18:31:13Z
       
       1 likes, 0 repeats
       
       @dthompson @sl2c @grainloom I don't think we need to junk the kernel, though it might involve apps needing to talk to different apis -- stuff like cloudabi or wasm+wasi. The Sandstorm model but for desktops instead of web apps.Running existing apps, designed for an ambient authority world, is a much harder problem.
       
 (DIR) Post #9oZFYMtUwxRMELXY3s by davidak@chaos.social
       2019-11-02T22:39:13Z
       
       1 likes, 0 repeats
       
       @clacke @dthompson https://github.com/matthewbauer/nix-bundle has experimental support for creating AppImages with Nix in addition to other formats.
       
 (DIR) Post #9oZFli9jD6oNwAUgfw by clacke@libranet.de
       2019-11-03T00:06:22Z
       
       0 likes, 0 repeats
       
       @davidak @dthompson Awesome! TIL.