Slack comes to Linux as a snap(techcrunch.com)
techcrunch.com
Slack comes to Linux as a snap
https://techcrunch.com/2018/01/18/slack-comes-to-linux-as-a-snap/
71 comments
« 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 ?
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.
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.
Slack desktop engineer here: We're not discontinuing anything – we're just offering more options.
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
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.
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.
> 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.
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.
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.
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.
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.
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?
> 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.
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.
(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.
(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.
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?
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?
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.
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.
I think solving there problem of easy distribution is faaaaaaar more important than the small overhead involed.
I literally have it open right now. They've supplied slack in .deb and .rpm files for a bit now AFAIK.
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.
I just run it in the browser (on Windows) ... the slack app has the tendency to consume ever larger amounts of RAM if I let it run for a while. I have the feeling they just append each new message and never clear old messages out of memory, but I never cared enough to actually check. Just banning it back into the browser solved it.
https://slack.engineering/introducing-electron-to-the-window...
Even when it's the "native" app, it's kind of still running in a browser (it uses Electron).
Even when it's the "native" app, it's kind of still running in a browser (it uses Electron).
For you Flatpak users out there Slack is also available on Flathub as well.
https://flathub.org/apps.html
https://flathub.org/apps.html
It's still a 150MB web-browser + attached web app, right?
Well yeah, it's not like how it's packaged changed the underlying design.
If you want a lightweight version of the slack client and don't fell like using the IRC or XMPP bridges you can use Epiphany (or Chromium) to install the website an an 'App'.
If you want a lightweight version of the slack client and don't fell like using the IRC or XMPP bridges you can use Epiphany (or Chromium) to install the website an an 'App'.
I find just pinning the tab (right-click on tab, select Pin Tab) on Firefox does what I need it to do. I mention this because I suspect many people are unaware the feature exists.
Pinning a tab gives it permanent priority on the left-hand side of the tab list, and elides the title from the tab, so it is just the favicon. It also blocks CTRL-w from closing the tab; you have to actually right-click and either unpin or close the tab. That may sound trivial, but was the biggest problem I had running it in the browser before, it got caught in my periodic tab cleanups accidentally. Now I never accidentally close it.
Pinning a tab gives it permanent priority on the left-hand side of the tab list, and elides the title from the tab, so it is just the favicon. It also blocks CTRL-w from closing the tab; you have to actually right-click and either unpin or close the tab. That may sound trivial, but was the biggest problem I had running it in the browser before, it got caught in my periodic tab cleanups accidentally. Now I never accidentally close it.
There is also wee-slack[0], a plug-in for weechat specifically that does more than the IRC gateway
[0] https://github.com/wee-slack/wee-slack
[0] https://github.com/wee-slack/wee-slack
eul.im is a closed-source commercial lightweight chat client launched 6 months ago; the author spent a few months advertising on related discussions until snagging a bit of critical feedback. https://hn.algolia.com/?query=eul.im&sort=byDate&type=commen... https://news.ycombinator.com/item?id=15597468 (apparently it still downloads a 180MB embedded browser https://github.com/eul-im/eul/issues/60)
There is also https://github.com/bkanber/Slackadaisical (no development since initial October appearance) CLI and:
https://news.ycombinator.com/item?id=15597508 >nikisweeting: https://github.com/saenzramiro/rambox [...] https://github.com/meetfranz/franz [...] share one Electron instance for all your chat services
There is also https://github.com/bkanber/Slackadaisical (no development since initial October appearance) CLI and:
https://news.ycombinator.com/item?id=15597508 >nikisweeting: https://github.com/saenzramiro/rambox [...] https://github.com/meetfranz/franz [...] share one Electron instance for all your chat services
Filesize on snapcraft.io is right around 150MB[0]
[0] https://snapcraft.io/slack/
[0] https://snapcraft.io/slack/
Yup. Fortunately this is not 2010 where that would more than 0.1% of the storage space on your typical machine.
Still dog slow on my 20C/64G box. :/
I can imagine. Then this is probably not the best option for that box. The WebApp, or Emacs-Slack(https://github.com/yuya373/emacs-slack), or Slackadaisical(https://github.com/bkanber/Slackadaisical) would probably be a better option.
But either way its an option that probably wouldn't exist otherwise.
But either way its an option that probably wouldn't exist otherwise.
But you know as well as anyone else that the problem with browser-based apps is that they take hundreds of megabytes of memory. And unfortunately, memory is still scarce (no thanks to Intel for not supporting LP-DDR4 in mobile SKUs).
Meh, LP is nice to have but you can live fairly happily without.
My real beef with electron apps is that they invariably lack support for all sorts of goodies (accented-character menus, OS-specific shortcuts, text auto-expansion, etc etc...) that regular desktop apps just get as standard.
My real beef with electron apps is that they invariably lack support for all sorts of goodies (accented-character menus, OS-specific shortcuts, text auto-expansion, etc etc...) that regular desktop apps just get as standard.
Slack's UI makes me insane. As a snap, or otherwise the lack of customizability, lack of minimalism and inability to size the UI to my liking makes me hate using it. I'm stuck with it and it feels like chat prison.
There's a lot of third party command line clients :
https://github.com/evanyeung/terminal-slack
https://github.com/regisb/slack-cli
https://github.com/juanpabloaj/slacker-cli
etc.
https://github.com/evanyeung/terminal-slack
https://github.com/regisb/slack-cli
https://github.com/juanpabloaj/slacker-cli
etc.
snap install slack-term
;)
You may want to check out https://get.slack.help/hc/en-us/articles/201727913-Connect-t...
I've had good luck with this plugin for Weechat.
https://github.com/wee-slack/wee-slack
https://github.com/wee-slack/wee-slack
If you happen to be using gnome I wrote a small script that uses the relay plugin so you can get native notifications even if your weechat is remote: https://github.com/Fingel/weelisten
That got rid of the last thing I felt was lacking when I started using weechat.
That got rid of the last thing I felt was lacking when I started using weechat.
The fact that they provide an irc gateway is the only saving grace for me. Really not looking forward to the day they retire it. But I'm sure it'll come.
This is the first I'm hearing about Snap, what do you guys think of that as a platform?
I like it quite a bit, even applied for the related dev-advocacy job (and was resoundingly ignored; rightly so, I might add). It removes the complexity layer of having to deal with multiple packaging systems, and it isolates the app at the user level which helps with dependencies.
The only issue I see, really, is that it does not appeal to the traditional Linux userbase, the greybeards and neckbeards who are used to all the packaging esoterica. It’s a user-friendly concept that happens to be very developer-friendly too, but has no appeal for the sysadmin crew, which is still the majority in Linux land. So it risks being ignored.
The only issue I see, really, is that it does not appeal to the traditional Linux userbase, the greybeards and neckbeards who are used to all the packaging esoterica. It’s a user-friendly concept that happens to be very developer-friendly too, but has no appeal for the sysadmin crew, which is still the majority in Linux land. So it risks being ignored.
Firefox and Slack are only on Snap and not on Flatpak. Is there a reason why this is happening ?
I can’t speak for Slack, but I ship Mailspring for Linux as a Snap (and not a Flatpak) because snap provides a unified approach to automatic updates and the app is updated frequently. It’s an a major win from a developer perspective, because users that have to install the new deb / rpm / flatpak manually are almost certainly going to fall behind and then file bugs / have issues that take up time to triage.
(I know there’s a way to do autoupdate with Flatpak, but it is not tested and maintained as part of Flatpak itself, and when I looked it seemed to be a proof of concept with no production use!)
(I know there’s a way to do autoupdate with Flatpak, but it is not tested and maintained as part of Flatpak itself, and when I looked it seemed to be a proof of concept with no production use!)
I'm not sure what you mean by the flatpak comment. "flatpak update" is the (built-in) command update all your installed flatpaks.
What is not built in is a daemon that regularly runs this, because the idea is to integrate that with the UI. So, the application installation ui you use (gnome-software or kde discover) will regularly call this update for you, however you configure it.
What is not built in is a daemon that regularly runs this, because the idea is to integrate that with the UI. So, the application installation ui you use (gnome-software or kde discover) will regularly call this update for you, however you configure it.
Slack is packaged as flatpak on flathub:
https://flathub.org/apps.html
Various versions of firefox as flatpak are here: https://firefox-flatpak.mojefedora.cz/
Getting some of those on flathub is a work in progress.
Various versions of firefox as flatpak are here: https://firefox-flatpak.mojefedora.cz/
Getting some of those on flathub is a work in progress.
There has been a Firefox Flatpak for a long time: https://firefox-flatpak.mojefedora.cz/
And there has been discussions about getting an official one from Mozilla.
And there has been discussions about getting an official one from Mozilla.
Umm..I did implicitly mean official. Sorry, if I made it seem as if it was technically not possible.
I'm asking about why it was chosen not to.
I'm asking about why it was chosen not to.
I'd like to hear from anyone that is using snaps. I'm currently using Ubuntu 17.10 and have heard of them but haven't noticed them anywhere. Is it something I should consider using? Generally happy with slack in the browser currently.
There's a "bug" which requires a Ubuntu account to load "snaps". It hasn't been fixed, despite claims that a Ubuntu account is unnecessary for that function.
They worked fine in my experience. The isolation is a nice concept, although it pollutes /etc/mtab (each app will appear as a mounted volume). It definitely helps developers not having to worry about .deb and .rpm, you configure a snap and then Ubuntu has automated services that will do all heavy lifting for you.
I wonder if this will give them some impetus to get calling working properly on Linux?
Calling works fine in Chrome for me.
1) Wait for browsers to implement adding PWAs to desktop
2) Write once, run everywhere
3) Everyone is happy
I've been using a Slack flatpak for months, from flathub.org
is this like nix?
arca_vorago(1)