4 ms·

« this will open Slack up to users of Linux-based services like ArchLinux, OpenSUSE, Solus, Debian, KDE Neon and others. » I don’t get it. I use the slack app o

« this will open Slack up to users of Linux-based services like ArchLinux, OpenSUSE, Solus, Debian, KDE Neon and others. » I don’t get it. I use the slack app on my Debian for almost a year. Am I missing something ?

taoistextremist 9y ago
I literally have it open right now. They've supplied slack in .deb and .rpm files for a bit now AFAIK.
- owaislone 9y ago
  Their hope is that they won't have to maintain for multiple packaging formats and distros. Just ship 1 snap and cover everything. That's what they hope to get out of it.
wjoe 9y ago
Similarly been using it on Arch for a few years. Looks like they only advertise downloads for Ubuntu and Fedora on their sites, but in the end they're just deb and rpm files. And in the end deb and rpms are just archives of files. I guess snaps, flatpak, etc remove the step of needing someone to make a package or otherwise work out the dependencies and steps needed to install it on a given other distro, but chances are non-deb/rpm based distros either have their own maintaners that do these things, or the users are happy to work it out themselves. Technologies like snaps do solve the issue of developers having to think about supporting different distros, but they add extra overhead too. I'd rather they just provide a tar and a list of dependencies and use a package from AUR myself.
- kahnpro 9y ago
  I think solving there problem of easy distribution is faaaaaaar more important than the small overhead involed.
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.

taoistextremist 9y ago

I literally have it open right now. They've supplied slack in .deb and .rpm files for a bit now AFAIK.

owaislone 9y ago
Their hope is that they won't have to maintain for multiple packaging formats and distros. Just ship 1 snap and cover everything. That's what they hope to get out of it.

wjoe 9y ago

Similarly been using it on Arch for a few years. Looks like they only advertise downloads for Ubuntu and Fedora on their sites, but in the end they're just deb and rpm files. And in the end deb and rpms are just archives of files. I guess snaps, flatpak, etc remove the step of needing someone to make a package or otherwise work out the dependencies and steps needed to install it on a given other distro, but chances are non-deb/rpm based distros either have their own maintaners that do these things, or the users are happy to work it out themselves. Technologies like snaps do solve the issue of developers having to think about supporting different distros, but they add extra overhead too. I'd rather they just provide a tar and a list of dependencies and use a package from AUR myself.

kahnpro 9y ago
I think solving there problem of easy distribution is faaaaaaar more important than the small overhead involed.

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.