HN Explorer

71 comments

[ 2.1 ms ] story [ 128 ms ] thread
dsr_
It's still a 150MB web-browser + attached web app, right?
Spivak
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'.

j_s
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

jerf
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.

Jaepa
Yup. Fortunately this is not 2010 where that would more than 0.1% of the storage space on your typical machine.
danieldk
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).
toyg
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.

sgift
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.
JeanMarcS
« 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
I literally have it open right now. They've supplied slack in .deb and .rpm files for a bit now AFAIK.
owaislone
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
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
I think solving there problem of easy distribution is faaaaaaar more important than the small overhead involed.
subway
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
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
> 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
(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
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
> 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
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
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
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
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
Slack desktop engineer here: We're not discontinuing anything – we're just offering more options.
[dead] arca_vorago
More proprietary crap, do not want, both slack and snap.
teh_klev
Then don't use it. You have the freedom to choose.
khedoros1
Right up until it gets declared a requirement at your job, or some such. I don't have much of a problem with Slack personally, but if my whole team is using it as their sole IM method, then it's hard to say that I "have the freedom to choose" whether or not to use it.
teh_klev
I'm not trying to be facetious, but you don't have the freedom to choose in a private company what tools are used. You do however have the freedom to leave if you feel oppressed by being forced to use non-free software.
beal
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.
Animats
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.
toyg
Uhm, i never had an Ubuntu account and am pretty sure I tried a few snaps last time I checked out Ubuntu.
TingPing
The software center has the bug, the cli tool works fine.
popey
That was a bug, it was fixed just before Christmas.
toyg
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.
skykooler
I wonder if this will give them some impetus to get calling working properly on Linux?
davidw
Calling works fine in Chrome for me.
echlebek
I use calling in Linux all the time, including screen sharing. It seems to work fine. Korora on X1 Carbon 5G.
maguirre
I use calling too and it works fairly well. However when sharing my screen i have to share "all my monitors" does anyone know why it's done this way?
[dead] shiftoutbox
Slack came to Linux via teamwords ages ago .
sandGorgon
Firefox and Slack are only on Snap and not on Flatpak. Is there a reason why this is happening ?
bengotow
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!)

alexlarsson
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.

TingPing
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.

jcastro
Any plans on submitting this to flathub?
TingPing
No, Firefox is a security sensitive project so Flathub wants Mozilla to be the official maintainer of it.
jcastro
That's a great policy, thanks!
sandGorgon
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.

o_____________o
This is the first I'm hearing about Snap, what do you guys think of that as a platform?
toyg
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.

cmurf
I've been using a Slack flatpak for months, from flathub.org
rrggrr
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.
WD-42
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.
wasd
I wasn't able to get it working through software center but this worked.

> $ sudo snap install slack --classic

popey
Yeah, that bug is being fixed and working through the release process right now.
butz
1) Wait for browsers to implement adding PWAs to desktop 2) Write once, run everywhere 3) Everyone is happy