Slack comes to Linux as a snap
techcrunch.com
techcrunch.com
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.
npm install -g electron-builder # for brevity, --save-dev works
electron-builder --linux snap --x64
ls dist/*.snap
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.
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.
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.
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.
(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. 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?
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.
Even when it's the "native" app, it's kind of still running in a browser (it uses Electron).
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'.
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 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
But either way its an option that probably wouldn't exist otherwise.
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.
https://github.com/evanyeung/terminal-slack
https://github.com/regisb/slack-cli
https://github.com/juanpabloaj/slacker-cli
etc.
That got rid of the last thing I felt was lacking when I started using weechat.
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.
> $ sudo snap install slack --classic
(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!)
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.
Various versions of firefox as flatpak are here: https://firefox-flatpak.mojefedora.cz/
Getting some of those on flathub is a work in progress.
And there has been discussions about getting an official one from Mozilla.
I'm asking about why it was chosen not to.