5 ms·

It means they're probably tired of maintaining standards such that their application can run on multiple distros, and have decided to shove it in a container.

by subway 9y ago

It means they're probably tired of maintaining standards such that their application can run on multiple distros, and have decided to shove it in a container. I love the idea of snaps, but good grief they sometimes have really backwards build processes -- start with a traditional rootfs, install packages, delete cruft (pray you didn't delete the wrong cruft), export and call it a day.

api 9y ago
I really sympathize with this view. At ZeroTier we try to support multiple distributions and versions of distributions going back quite a while and it is hell on wheels. It's so tempting to just build everything as a static binary and let the user figure out how to support the three different init systems that can each be configured in seven different ways. Linux has far too many distributions. They really aren't that different, so I have a hard time understanding why they exist. The community as a whole would benefit hugely if e.g. Debian and CentOS/RedHat/Fedora merged, but I understand that's not going to happen for stupid political reasons.
- beojan 9y ago
  > let the user figure out how to support the three different init systems that can each be configured in seven different ways There's really only one init system you should care about anymore, and that's systemd. If you really insist on supporting old distros, you might also support /bin/init configured through LSB compliant initscripts. So that's two init systems, each with one way of configuring them. The real solution, though, is to simply ship source code and let the distributions deal with this when they package it.
  - api 9y ago
    (1) We still get "it doesn't work on upstart based Ubuntu" questions. Lots of these are still in use. (2) "When they package it" is when exactly? Our software is GPL and has existed for years and it's not in Debian, EPEL, or Fedora. We've tried to work with distributions to get our software in there. The experience is worse than the Apple Store, and that's saying something. I've been a Linux user since 1993 so I know all about the Linux community and how these things work. The processes in place made sense in 1998 but they have not scaled.
    - beojan 9y ago
      1. Good point, that's what happens when Ubuntu decides to reinvent everything (upstart, Mir, Unity, ...) instead of using an existing solution. 2. What is your software? I'm not surprised about the RPM distros, which have always suffered from a lack of software in their repos, but with Debian have you tried filing an RFP (Request For Package) bug?
- toyg 9y ago
  > stupid political reasons TBH I wouldn't call them "stupid political reasons". Debian is basically the institutional ONG of the Linux world; RedHat is a public company; they have wildly different targets and objectives. This is not "stupid". It's like saying "Firefox and Edge should merge, but it won't happen for stupid political reasons" - no, it's because they are very different things with very different aims. Anyway, I'm curious: are you considering Snap for your products then? Sounds like a prime candidate. Although tbf I don't really know how it handles init systems.
  - api 9y ago
    I really don't want to use snap since tarring up containers is a hideous hack, but then again we have a "curl | bash" script which is also an evil hack.
    - toyg 9y ago
      Apart from the security differences, which are quite stark, the main advantage that I see is that, with Snap, the distributions take on a bit (or even a lot) of the responsibility for making a product work consistently. With a bash script, you're always on your own. That's very powerful, of course, but it's usually more of a burden. It's a bit like using a package manager vs manually installing tarballs.
    - evand 9y ago
      Sincerely curious why you think a squashfs of the app contents (without any additional operating system bits) running under seccomp and apparmor is a hack? What do you think is the ideal solution?
evand 9y ago
I wouldn't call the snap build process for Electron apps backwards: npm install -g electron-builder # for brevity, --save-dev works electron-builder --linux snap --x64 ls dist/*.snap There's no operating system rootfs in your snap. That lives in the core snap.
felixrieseberg 9y ago
Slack desktop engineer here: We're not discontinuing anything – we're just offering more options.

by subway 9y ago

api 9y ago

I really sympathize with this view. At ZeroTier we try to support multiple distributions and versions of distributions going back quite a while and it is hell on wheels. It's so tempting to just build everything as a static binary and let the user figure out how to support the three different init systems that can each be configured in seven different ways. Linux has far too many distributions. They really aren't that different, so I have a hard time understanding why they exist. The community as a whole would benefit hugely if e.g. Debian and CentOS/RedHat/Fedora merged, but I understand that's not going to happen for stupid political reasons.

beojan 9y ago
> let the user figure out how to support the three different init systems that can each be configured in seven different ways There's really only one init system you should care about anymore, and that's systemd. If you really insist on supporting old distros, you might also support /bin/init configured through LSB compliant initscripts. So that's two init systems, each with one way of configuring them. The real solution, though, is to simply ship source code and let the distributions deal with this when they package it.
- api 9y ago
  (1) We still get "it doesn't work on upstart based Ubuntu" questions. Lots of these are still in use. (2) "When they package it" is when exactly? Our software is GPL and has existed for years and it's not in Debian, EPEL, or Fedora. We've tried to work with distributions to get our software in there. The experience is worse than the Apple Store, and that's saying something. I've been a Linux user since 1993 so I know all about the Linux community and how these things work. The processes in place made sense in 1998 but they have not scaled.
  - beojan 9y ago
    1. Good point, that's what happens when Ubuntu decides to reinvent everything (upstart, Mir, Unity, ...) instead of using an existing solution. 2. What is your software? I'm not surprised about the RPM distros, which have always suffered from a lack of software in their repos, but with Debian have you tried filing an RFP (Request For Package) bug?
toyg 9y ago
> stupid political reasons TBH I wouldn't call them "stupid political reasons". Debian is basically the institutional ONG of the Linux world; RedHat is a public company; they have wildly different targets and objectives. This is not "stupid". It's like saying "Firefox and Edge should merge, but it won't happen for stupid political reasons" - no, it's because they are very different things with very different aims. Anyway, I'm curious: are you considering Snap for your products then? Sounds like a prime candidate. Although tbf I don't really know how it handles init systems.
- api 9y ago
  I really don't want to use snap since tarring up containers is a hideous hack, but then again we have a "curl | bash" script which is also an evil hack.
  - toyg 9y ago
    Apart from the security differences, which are quite stark, the main advantage that I see is that, with Snap, the distributions take on a bit (or even a lot) of the responsibility for making a product work consistently. With a bash script, you're always on your own. That's very powerful, of course, but it's usually more of a burden. It's a bit like using a package manager vs manually installing tarballs.
  - evand 9y ago
    Sincerely curious why you think a squashfs of the app contents (without any additional operating system bits) running under seccomp and apparmor is a hack? What do you think is the ideal solution?

evand 9y ago

I wouldn't call the snap build process for Electron apps backwards: npm install -g electron-builder # for brevity, --save-dev works electron-builder --linux snap --x64 ls dist/*.snap There's no operating system rootfs in your snap. That lives in the core snap.

felixrieseberg 9y ago

Slack desktop engineer here: We're not discontinuing anything – we're just offering more options.