Slack was down(status.slack.com)
status.slack.com
Slack was down
https://status.slack.com/2019-07/b31a6510b8caabcc
242 comments
True, it's really bad UX that cost me and a coworker each 30 minutes this morning. Nobody expects the backend to be completely reliable, but the client should be trustworthy when it comes to reporting the status of the backend.
Eventually the status bar appears saying they're having an issue.
Yep, and from the status message, you can get to Twitter inside the Slack client and read memes directly from Elon Musk's timeline instead of going through your organization's dedicated meme channel.
Weird, it took me to a status page saying they were having trouble.
[deleted]
Since twitter went down the other week hackernews is now the primary 'is it down?' news site.
I don't think this is the appropriate forum for "is down" postings.
Post-mortems are interesting.
Post-mortems are interesting.
They're upvoted because people can't resist making the same tired "see? we are over-reliant on {Slack,Github,Cloudflare,etc}!" comments.
My favorite are the conspiracy theories as to why the outages are seemingly so close together in this Summer of 2019. All kinds of imaginative reasons abound.
My best guess is summer vacation :) it's at least true for my company who was one of the featured outages
My best guess is summer vacation :) it's at least true for my company who was one of the featured outages
My best guess is that "sequencing creates narratives." It's like in baseball, how a player who hits .333 over the season will have 0-10 and 10-10 stretches where he either can't hit everything or demolishes every pitch he sees. You'll often see sports news come up with stories for why this is happening, and most of the time it's just "this is how statistics work".
TL;dr- complex systems are complex, and trying to understand them isn't usually possible for outside parties.
TL;dr- complex systems are complex, and trying to understand them isn't usually possible for outside parties.
Not entirely true regarding sports, 538 has done some decent analyses of basketball shooting and found that hot and cold shooting is often true, the same is likely true for baseball. Streaks are naturally occurring, both for randomness and due to other, harder to explain factors.
See, we're over-reliant on HN for making these types of comments!
And yet it is the first place I checked to verify my experience
I suggest https://downforeveryoneorjustme.com/, slack its own self, or https://www.isitdownrightnow.com/ or https://hosting.review/check-if-website-is-down/ or https://www.isitwp.com/uptime-checker/. No need to fill this site with three or four postings with non-substantial comments.
It is appropriate if Slack being down affects software other than Slack. We can learn how to avoid outages in our own products happening due to 3rd party services such as Slack becoming unavailable.
I would love if threads like this became "how to make your Slackbots more resilient" or "high-availability messaging by archiving your Slack threads" or an actually interesting conversation topic. Instead of just complaining that Slack is popular and on-premise solutions never have technical problems, I'd love to hear some real solutions.
I've been fairly content with Matrix, the ecosystem has improved massively in the last couple months, reducing resource usage on the server I use and adding additional e2e encrypted clients besides Riot.
Bridges are also super handy for integrating with IRC, Slack and similar.
Bridges are also super handy for integrating with IRC, Slack and similar.
Agreed
I use https://downdetector.com/
I've often experienced issues with sites that say "everything's sunshine and rainbows" on their status pages, only to find that many other customers are experiencing the same problem.
I've often experienced issues with sites that say "everything's sunshine and rainbows" on their status pages, only to find that many other customers are experiencing the same problem.
Except that time when cloudflare took down even the downdetector.
People just copy what gets engagement.
ex. After an earthquake affecting a large population, you'll see stories about other irrelevant earthquakes leading you to believe a frequency is higher and then that kind of headline dissipates but nothing has changed at all
ex. After an earthquake affecting a large population, you'll see stories about other irrelevant earthquakes leading you to believe a frequency is higher and then that kind of headline dissipates but nothing has changed at all
If you're a community driven project or organization using Slack, then take a look at https://zulipchat.com/ for something that sucks less, and is open source software. I've found it much more pleasant to use and less buggy than Slack.
Wish we wouldn’t use such language, “sucks less” is highly subjective and your opinion but we don’t need to disparage Slack in order to make a point that alternatives like Zulip are available.
Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?
Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?
2GB of RAM use for 6 open tabs in Slack is pretty awful, their desktop client has set the bar to compete with Slack on performance very low.
This abusive resource usage has created a dislike of Slack among a subset of its users.
This abusive resource usage has created a dislike of Slack among a subset of its users.
They actually just fixed that in 4.0: https://slackhq.com/introducing-a-more-efficient-slack-deskt...
I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
400MB? Not bad for a chat client that sends a few bytes of text.
Still 10 times more compared to Telegram) Not to mention transfer speed and bandwith usage.
This is on my Mac, whose apps aren't exactly known for memory efficiency.
Fantastical, a calendaring app, is sitting at 333MB.
1Password is taking up 168MB in the background.
Finder, which I don't even have a window open for, is eating 127MB.
I'm not saying 400MB is amazing or anything, but it's a significant drop from the gigs of memory wasted by previous versions.
Fantastical, a calendaring app, is sitting at 333MB.
1Password is taking up 168MB in the background.
Finder, which I don't even have a window open for, is eating 127MB.
I'm not saying 400MB is amazing or anything, but it's a significant drop from the gigs of memory wasted by previous versions.
Aren't your coworkers sharing 10 MB gifs all day long?
The reason I don't like twitter because of all the dumb reaction gifs.
Still can't blame the browser when it consumes a gigabyte of ram, when we ask it to show us a gigabyte of gifs
400MB for what basically is a client for a proprietary version of IRC is ridiculous. How much memory did BitchX use ?
while I don't remember how much memory did BitchX use, I do remember that a whopping 8 megs of ram was enough to run mIRC with 20+ channel tabs without serious glitches. And those precious megs were used not only for the irc client but also for the OS itself.
I have irssi reporting 25232 mem used
Half a gig for IRC + gifs
Seriously. Oh, good, now it's only 4-5x as large as it has any right to be, even allowing for modern software bloat...
Such is the nature of slightly optimized Electron apps, T-Mobile Digits Desktop app is a similar resource hog.
Using the browser based version often is less resource intensive.
Using the browser based version often is less resource intensive.
Tried that, they actively employ darkpatterns to coerce users onto desktop apps. I even asked them to stop asking for an app install on their links that you open from inside the webapp and they told me to get stuffed and use the desktop app.
Yea, I use Matrix integration when I deal with Slack, that way I have my choice of client and there isn't any code of Slack's running on my machine.
Strange, after declining message about "native" desktop app, I've never seen it again. No other issues as well. Firefox 69 on Windows, one paid and one free workspace.
How is CPU and I/O use on the newest version?
I can honestly say that I have never checked or cared about how much RAM Slack uses. Or any other software for that matter. It's certainly not an issue that I'd use as the basis for deciding which team communication tool to use.
Yeah see the people that are caring about this are caring because it has used up all of their available RAM, has pushed stuff into Virtual Memory, and it is causing performance problems for their system. Or, if they are IT, it is causing performance problems on their users' systems.
This is a pretty reasonable complaint when you're talking about a system with 2gb, and a chat application that uses 1.5gb of memory...or heck, a 16gb system when you have programs that legitimately need as much memory as you can give them and are being starved of it. Nobody would begrudge this usage if it was necessary for the task, but it isn't. Not even close.
Edit: Apparently this is better than it used to be, but there have been times when Slack also ate up CPU like crazy. Which, again, no biggie if you have plenty to spare, but when you don't...and even then, if you have plenty to spare, you're still going to be annoyed with Slack if it's eating all of your battery because the CPU is working really really really hard at...um...dunno? If it were mining bitcoin/monero without your knowledge or consent then at least it would be DOING something.
This is a pretty reasonable complaint when you're talking about a system with 2gb, and a chat application that uses 1.5gb of memory...or heck, a 16gb system when you have programs that legitimately need as much memory as you can give them and are being starved of it. Nobody would begrudge this usage if it was necessary for the task, but it isn't. Not even close.
Edit: Apparently this is better than it used to be, but there have been times when Slack also ate up CPU like crazy. Which, again, no biggie if you have plenty to spare, but when you don't...and even then, if you have plenty to spare, you're still going to be annoyed with Slack if it's eating all of your battery because the CPU is working really really really hard at...um...dunno? If it were mining bitcoin/monero without your knowledge or consent then at least it would be DOING something.
CPU nomming is a worse problem IMO, as your fans spin up and battery life shrinks. Other chat clients don't use notable resources, its suprising that Slack hasn't had much pushback over its heavy resource usage thus far.
"Virtual memory" is not a synonym for swap space: https://news.ycombinator.com/item?id=2937597
Thank you for the gentle correction. I will now also start using "thrashing" more accurately.
Same with MS Teams, and there isn't even a way to disable notifications per channel. So if people ping the channel and you are ini tyou will get a notification. It drives me insane but no progress since August 2018. They did add a way to send unicorns to people though. Priorities...
In MS Teams you can click the '...' next to a channel and then click 'channel notifications'. The options allow you to mute 'all new posts' and also to mute 'channel mentions'.
Their new version seem to use less RAM, it's still Electron but with a lot of lazy-loading's
[deleted]
I'm sitting at 341MB after all day heavy usage, let's not exaggerate here :)
as mentioned in another reply -- the slack client memory hog issue was fixed in the latest update.
zulip is electron also.
Engineers grew up on chat (IRC, AIM/MSN/ICQ, Jabber/XMPP, etc.) and have opinions about what it should look and feel like. When a company raises billions for a product that feels like using dinky Fisher-Price software that you could have written better and gotten rich off instead, and moreover when their product is forced upon you by your workplace and it becomes a major distraction and headache...
Ire, jealousy, hate... There are a lot of bad feelings towards Slack.
These are not necessarily my feelings, but I'd be lying if I said I didn't dislike them just a little.
Ire, jealousy, hate... There are a lot of bad feelings towards Slack.
These are not necessarily my feelings, but I'd be lying if I said I didn't dislike them just a little.
I grew up with all of these and I have no issues with Slack. It's much more convenient and useful than any of the above.
We pay for Slack and I’ve lost some time this morning coordinating with my team. 2 weeks ago it was screen sharing that was down. It’s infuriating.
Not sure why you think OP can’t say “Slack sucks”.
Not sure why you think OP can’t say “Slack sucks”.
Some reasons, playing devil's advocate:
1. While today's incident was unfortunate, Slack has been historically reliable.
2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity.
4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
1. While today's incident was unfortunate, Slack has been historically reliable.
2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity.
4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
Playing the devil's advocate's advocate:
> 1. While today's incident was unfortunate, Slack has been historically reliable.
Screen sharing and video have not been reliable in the past month. With several public incidents.
> 2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
I feel very little sympathy for an engineer who make couple of hundred thousands per year. Not accounting stock options, vacation, and work environment. And Slack won't fire the culprit.
> 3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity
We invest our own time building integrations. Why should be doing that for Slack and not for the competition?
> 4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
I don't think OP's "It sucks" is dismissive or rude. You can be nice and still thinking something sucks. It helps no one to lie by choosing less explicit words.
> 1. While today's incident was unfortunate, Slack has been historically reliable.
Screen sharing and video have not been reliable in the past month. With several public incidents.
> 2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
I feel very little sympathy for an engineer who make couple of hundred thousands per year. Not accounting stock options, vacation, and work environment. And Slack won't fire the culprit.
> 3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity
We invest our own time building integrations. Why should be doing that for Slack and not for the competition?
> 4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
I don't think OP's "It sucks" is dismissive or rude. You can be nice and still thinking something sucks. It helps no one to lie by choosing less explicit words.
You’re supposed to be soft on a company during an outage? That’s exactly when you’re supposed to be considering alternatives!
Similar peeve is when people say “don’t politicize this tragedy.” No, politics is how we decide to act, a tragedy is exactly when we should be the most political. The Boeing 737 crashes is when we should excoriate and eliminate the rot at Boeing and the FAA, not six years later after some respectful silence.
Similar peeve is when people say “don’t politicize this tragedy.” No, politics is how we decide to act, a tragedy is exactly when we should be the most political. The Boeing 737 crashes is when we should excoriate and eliminate the rot at Boeing and the FAA, not six years later after some respectful silence.
"suck less" is a specific software development philosophy https://suckless.org/philosophy/
It's also not what op meant.
If the original commenter would have meant that, he probably would have recommended using https://tools.suckless.org/sic/ and not some web application which is categorized as "stuff that sucks" See: https://suckless.org/sucks/web/
They're a $17 billion company. They'll be just fine.
Their valuation is actually extremely sensitive to usage patterns right now, however. If they lose $1m of business, it's not like they're worth $1m less. That million bucks is not only used in an assumption for making that money over and over for the next couple decade, but also as an indication of growth for more adoption. I don't know the exact model that gets used, but it's likely that losing $1m in business today causes hundreds of millions in loss for their market cap.
I don't mean it in a disparaging way. Most software sucks to some degree so the goal is to find something that "sucks less". Pretty much everything can always be improved on.
"more pleasant to use and less buggy."
Borrowing from Lin Manuel-Miranda's Thomas Jefferson:
> These are wise words, enterprising men quote 'em > Don't act surprised, you guys, 'anaphor wrote 'em
It's a nicer way to convey the same idea, without triggering a combative emotional response in reaaders.
Borrowing from Lin Manuel-Miranda's Thomas Jefferson:
> These are wise words, enterprising men quote 'em > Don't act surprised, you guys, 'anaphor wrote 'em
It's a nicer way to convey the same idea, without triggering a combative emotional response in reaaders.
If saying slack sucks "trigger[s] a combative emotional response in reaaders," I don't think it's the speaker that needs to re-evaluate their choices in life.
Slack is a multi-billion dollar valued company, we're not kicking them while they're down
Except in the literal sense.
Lindsey Graham, a 64-year-old conservative U.S. senator, just said China's ability to influence the U.S. film industry "sucks," so I don't think the language has the swear-word power it used to.
[deleted]
Some other open Slack alternatives I know about include:
Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta.
Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support.
Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess.
Apologies for any inaccuracies or omissions; I'm not an expert in the space.
[1] https://matrix.org/ [2] https://zulipchat.com/ [3] https://rocket.chat/ [4] https://mattermost.com/
Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta.
Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support.
Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess.
Apologies for any inaccuracies or omissions; I'm not an expert in the space.
[1] https://matrix.org/ [2] https://zulipchat.com/ [3] https://rocket.chat/ [4] https://mattermost.com/
None of these will:
- "replace email"
- "increase productivity"
- "centralize communication"
None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time.
But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise.
Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare.
Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
- "replace email"
- "increase productivity"
- "centralize communication"
None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time.
But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise.
Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare.
Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
Honestly, chat at an organization only seems to replace phone calls, and only partially. Which is not a bad thing, but I'm not sure it's even a good idea to try to replace email.
Question about the requirements of those alternatives (and slack i suppose). Zulip for example says if you have > 100 users you need a machine with 4GB RAM and 2 CPUs. Why does a chat app need a lot of processing power? I guess most of the messages are simple text, and IRC could handle thousands of users ages ago. What is the processing used for ?
The Zulip server uses very little CPU, but the RAM is important. (I work on Zulip.)
Here's what the docs say, for reference (excerpt of https://zulip.readthedocs.io/en/latest/production/maintain-s... ):
> For an organization with 100+ users, it’s important to have more than 4GB of RAM on the system. Zulip will install on a system with 2GB of RAM, but with less than 3.5GB of RAM, it will run its queue processors multithreaded to conserve memory; this creates a significant performance bottleneck.
> chat.zulip.org, with thousands of user accounts and thousands of messages sent every week, has 8GB of RAM, 4 cores, and 80GB of disk. The CPUs are essentially always idle, but the 8GB of RAM is important.
As a practical matter, I think 4GB of RAM is not a lot to ask for a service that 100+ users are actually concurrently using all day. That's a small fraction of the RAM the clients are consuming; and you can get a suitable cloud machine from Digital Ocean (simpler pricing than AWS, so good for a quick price check) for $20 USD/mo.
On the implementation side, it turns out that a lot of moving parts go into a full-featured chat app. Here's a partial architecture diagram, plus detailed exposition: https://zulip.readthedocs.io/en/latest/overview/architecture... Database, plus caches, plus code for lots of features x running in a number of processes, adds up to a few gigs of memory.
Here's what the docs say, for reference (excerpt of https://zulip.readthedocs.io/en/latest/production/maintain-s... ):
> For an organization with 100+ users, it’s important to have more than 4GB of RAM on the system. Zulip will install on a system with 2GB of RAM, but with less than 3.5GB of RAM, it will run its queue processors multithreaded to conserve memory; this creates a significant performance bottleneck.
> chat.zulip.org, with thousands of user accounts and thousands of messages sent every week, has 8GB of RAM, 4 cores, and 80GB of disk. The CPUs are essentially always idle, but the 8GB of RAM is important.
As a practical matter, I think 4GB of RAM is not a lot to ask for a service that 100+ users are actually concurrently using all day. That's a small fraction of the RAM the clients are consuming; and you can get a suitable cloud machine from Digital Ocean (simpler pricing than AWS, so good for a quick price check) for $20 USD/mo.
On the implementation side, it turns out that a lot of moving parts go into a full-featured chat app. Here's a partial architecture diagram, plus detailed exposition: https://zulip.readthedocs.io/en/latest/overview/architecture... Database, plus caches, plus code for lots of features x running in a number of processes, adds up to a few gigs of memory.
Well my question is why they consume so much memory/CPU? What makes these services so different from earlier chat systems? Are these users continuously doing video chat with each other or keep sockets open? For simple text chat, 4GB of RAM seems absurdly high, considering how irc was able to handle thousands of users 3 decades ago.
IRC is essentially stateless. The server doesn't remember what messages people have sent; so it can't tell you what was said last night when you come online in the morning, or what was just said in some channel you weren't previously listening to. That work gets pushed out to clients, and to add-on services.
The IRC server also doesn't store images or any other kind of file people want to show each other. There are lots of good practical reasons to want to share images in a conversation (e.g., screenshots), plus of course silly GIFs. That work also gets pushed out to add-on services.
When people say here that Slack or Zulip etc. are a much better user experience than IRC, I think those two things -- message history, and images -- are major reasons for that.
Message history means a database that gets big, and images mean a lot of data too. There's a large working set of both of those that you want fast access to. That means providing adequate RAM.
The IRC server also doesn't store images or any other kind of file people want to show each other. There are lots of good practical reasons to want to share images in a conversation (e.g., screenshots), plus of course silly GIFs. That work also gets pushed out to add-on services.
When people say here that Slack or Zulip etc. are a much better user experience than IRC, I think those two things -- message history, and images -- are major reasons for that.
Message history means a database that gets big, and images mean a lot of data too. There's a large working set of both of those that you want fast access to. That means providing adequate RAM.
It seems appropriate to also mention https://mattermost.com/ as a valid Open Source alternative to Slack.
We use this at work alongside Gitlab.
Works perfectly.
'Bot' scripts can also be added to do things like tell a channel when a repo has been pushed etc. Very handy.
Works perfectly.
'Bot' scripts can also be added to do things like tell a channel when a repo has been pushed etc. Very handy.
I've spoken before about how much I like Zulip. I don't know if it's any more stable or available than Slack, but I do like that the fundamental concepts exposed by Zulip actually encourage focused, productive conversation (something that always feels like a losing battle in Slack).
> then take a look at https://zulipchat.com/ for something that sucks less, and is open source software.
I really want to like Zulip Chat. It has everything all the alternatives have + self-hosting, but as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with.
I already have to put up with 10+ electron apps slowing down my Macbook. I shouldn't have to make space for another to do the same.
I really want to like Zulip Chat. It has everything all the alternatives have + self-hosting, but as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with.
I already have to put up with 10+ electron apps slowing down my Macbook. I shouldn't have to make space for another to do the same.
> as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with.
FWIW I use Zulip every day -- I work on Zulip, and naturally we use it among ourselves -- and I never touch the Electron client, because I prefer the experience of a browser tab.
Chrome's task manager (shift-esc) reports that tab is using 281M right now. Less than Gmail, or some old GitHub tabs (>1G, yikes!), or a freshly-started VS Code (... oh wow, or my Emacs which is at 337M. Wasn't expecting that.) Not sure how that compares to the Electron app.
As another reply pointed out, there is also a terminal client! You might enjoy trying it: https://github.com/zulip/zulip-terminal
FWIW I use Zulip every day -- I work on Zulip, and naturally we use it among ourselves -- and I never touch the Electron client, because I prefer the experience of a browser tab.
Chrome's task manager (shift-esc) reports that tab is using 281M right now. Less than Gmail, or some old GitHub tabs (>1G, yikes!), or a freshly-started VS Code (... oh wow, or my Emacs which is at 337M. Wasn't expecting that.) Not sure how that compares to the Electron app.
As another reply pointed out, there is also a terminal client! You might enjoy trying it: https://github.com/zulip/zulip-terminal
There's a terminal client for it: https://github.com/zulip/zulip-terminal
Zulip desktop is working to move from a electron's webview to Browserview. Slack has completed that migration and seems to have received a good control on its memory usage after that. Hopefully, once Zulip migrates it stops being a resource hog.
10+ electron apps seems excessive, what other Electron apps are you running? I think Slack is the only one I'm running (that I know of)
Well, on my Macbook I still have Slack (Since work colleges still use it) and I use Discord, Trello, Keybase, VS Code, Dropbox for Mac, Ledger Live, Skype, InVision Studio, Framer and Nylas Mail.
I just migrated off of and removed Atom, GitKraken and Github Desktop to only use VS Code but I don't think I am able to open Chrome or Firefox without it swapping out to my SSD. I have to kill two or three other apps to recover my RAM usage just to stop the constant freezing when using either browser. After sometime browsing the internet, I see a list of swap-files everywhere and eventually I run out of space.
So when I see another Electron app to use instead of Slack, I usually avoid it and I try to find another usable alternative if I can.
I just migrated off of and removed Atom, GitKraken and Github Desktop to only use VS Code but I don't think I am able to open Chrome or Firefox without it swapping out to my SSD. I have to kill two or three other apps to recover my RAM usage just to stop the constant freezing when using either browser. After sometime browsing the internet, I see a list of swap-files everywhere and eventually I run out of space.
So when I see another Electron app to use instead of Slack, I usually avoid it and I try to find another usable alternative if I can.
I run VSCode, Slack, Discord, GitHub, and my company's own app. There are others out there that I would use but my memory pressure is already too high.
Plenty of popular project management / task-tracking tools are very memory heavy too, and also so slow to load that one's reluctant to close their tab(s). Plus if I close them I sometimes have trouble finding WTF I need again. Jira, Asana, both major offenders. Can easily eat many hundreds of MB of memory. It's entirely fucking absurd for what they do and the content they deal with. Harsh (and harsher) language justified.
While don't have any info or even anectada about the other, JIRA is even more bloated on the server side - we had JIRA hosted on premises and it was used mainly for tasks and tickets in a team of 5 people. This "metric" (team size) limits the amount of tasks/tickets that would be processed. Anyway, the JIRA itself needed 2 cores and 8 GB of ram just for that. This is really even beyond absurd.
I would guess from my experience with my colleagues that they're running at a minimum vscode and some kind of electron git app.
I only use Electron apps if I like them too much or if they're unavoidable. The only two I have running all the time are Slack and InVision.
The Pony community moved to Zulip a few months back and we've been very happy with the switch. It's far from perfect, but almost everyone who uses it regularly agrees that it's been a marked improvement as a communication medium compared to IRC or Slack.
Has anyone tried Twist ( https://twist.com/ )? It looks a lot like Zulip but with a nicer UI. I think it is crazy that Slack has not invested more in first-class threaded, context-aware conversations.
Tried it. While the interface looks 'nicer' at first glance, it fits far less content on the screen. It also had more of an email-y vibe while Zulip has more a chat-y vibe, which I personally prefer.
Beyond that, Zulip is open source and self-hostable, while Twist is not.
Side note, we have a chat about self-hosting set up on Zulip at https://homelabos.zulipchat.com/ with 85 members and growing. It's been great for new users to be able to come in and catch up on old discussions in a way that isn't possible with non-threaded platforms.
Beyond that, Zulip is open source and self-hostable, while Twist is not.
Side note, we have a chat about self-hosting set up on Zulip at https://homelabos.zulipchat.com/ with 85 members and growing. It's been great for new users to be able to come in and catch up on old discussions in a way that isn't possible with non-threaded platforms.
That's great to know! I look forward to trying Zulip at some point, it seems to get a lot of love in this thread.
But... we pay managed solutions like Slack so we have 100% uptime...
We don't pay for 100% uptime. We pay so that we don't have to put the time into operating a service. That way we have more of our time to focus on our business problems.
If you're willing to tolerate these kinds of outages, you don't have to spend much time operating a service, either.
The problem is the time spent talking to the users.
If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc.
"Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.
If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc.
"Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.
While that's generally true, chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Besides, when Slack goes down all the time, your IT guys are going to have to deal with users complaining anyway.
> your IT guys are going to have to deal with users complaining anyway
Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us."
This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful.
> chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client.
Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.
Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us."
This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful.
> chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client.
Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.
Actually it's only two nine's, which means Slack can be down for 52 minutes every year.
> 1. We purposely made our commitment to the ‘fourth 9’, viz. 99.99% uptime guarantee in contrast to the typical SLAs which tend to offer 99.90%. We believe that extra availability makes a difference: the ‘fourth 9’ is important when your team relies on Slack every day. You need Slack at least 9,999 out of every 10,000 minutes. [1]
[1]: https://get.slack.help/hc/en-us/articles/204113126-Service-L...
> 1. We purposely made our commitment to the ‘fourth 9’, viz. 99.99% uptime guarantee in contrast to the typical SLAs which tend to offer 99.90%. We believe that extra availability makes a difference: the ‘fourth 9’ is important when your team relies on Slack every day. You need Slack at least 9,999 out of every 10,000 minutes. [1]
[1]: https://get.slack.help/hc/en-us/articles/204113126-Service-L...
99.99 is four nines, not two. https://uptime.is/four-nines
Assuming the failures are deterministic across workspaces (is that true?) Slack has been down for over an hour for some workspaces, since the problem started at 10:54 AM EDT.
What is the A part of Stack's SLA?
What is the A part of Stack's SLA?
I think you mean 4 nines.
You pay for "close" to it, but no chat app is going to have 100% uptime at scale.
A frequent use case seems to be internal chat for medium size companies. I’d wager that for a majority of the user base it doesn’t need to work ”at scale”. Hopefully, outages like this will serve as a reminder.
[deleted]
My company uses Zulip and I'm very happy with it.
Alternatively, there's also Rocket.Chat, which is also open source, you can self host it or pay for the cloud plans (which have special rates for certain kinds of organizations, such as OSS).
https://rocket.chat/
Disclaimer: I've done a GSoC project with them last year.
https://rocket.chat/
Disclaimer: I've done a GSoC project with them last year.
If you start using it using the Cloud solution, can you then later easily migrate to the On-Premise version?
Yep, definitely. Here's details: https://zulipchat.com/help/export-your-organization
(I work on Zulip.)
(I work on Zulip.)
Friendly note: on-premises.
It's not just about chat. It's also about the integration we have set up with many different applications. I'll check this out hopefully it integrates with stuff!
Zulip is way better when you have people in many timezones.
Thanks! Is it easy to integrate with existing user base?
Not sure if this answers the question you have in mind, but it's easy to migrate your data (users, channels, their membership, message history, etc.) from Slack to Zulip:
https://zulipchat.com/help/import-from-slack
(I work on Zulip.)
(I work on Zulip.)
Thank you - hadn't come across that one.
I am a huge fan of zulip
I really don't like the heavy dependence on Slack that my (and a lot of other) company has. The outage is frustrating.
See, I love it. I work for a mostly-remote company and before Slack we had an IM product but it was a 1:1 chat. Having an always-on chat room for the entire team, knowing other teams use the same product and I can pop into their chat room, spinning up channels for project teams, etc. It's been a huge boost to our company.
And since so many companies have settled on the same solution, when I'm working with a client I can join their Slack workspace too. That cuts down on the numerous quick phone calls and long email threads that we used to have.
Slack vs Teams vs IRC vs anything else, I don't care. It's not about the product. But my company (and most of our clients) didn't have this capability before Slack even though IRC existed for decades, so I'm going to give Slack some credit.
And since so many companies have settled on the same solution, when I'm working with a client I can join their Slack workspace too. That cuts down on the numerous quick phone calls and long email threads that we used to have.
Slack vs Teams vs IRC vs anything else, I don't care. It's not about the product. But my company (and most of our clients) didn't have this capability before Slack even though IRC existed for decades, so I'm going to give Slack some credit.
It seems that you could take any old-school internet tech, add some flashy GUI, slap "for enterprise" label and you get a great and popular solution that solves the problem noone ever could solve. Maybe it's time for gopher for enterprise
That's really what it comes down to. Email existed forever, but no one really liked it until Gmail made it flashy. Smartphones existed forever but no one really liked them until Apple/Google made them flashy. Search existed forever but no one really liked it until Google made it flashy.
Hackers like to pretend that presentation doesn't matter, but in the end presentation is the only thing that matters.
Hackers like to pretend that presentation doesn't matter, but in the end presentation is the only thing that matters.
Sorry, you are wrong. This is pure revisionism.
Blackberry was absolutely massive before the iPhone, email has always been the largest use of the internet (until media became possible), and Google search became successful because it actually worked, unlike everything available at the time.
I do agree with your sentiment, though. To the user, the UI is the product.
Blackberry was absolutely massive before the iPhone, email has always been the largest use of the internet (until media became possible), and Google search became successful because it actually worked, unlike everything available at the time.
I do agree with your sentiment, though. To the user, the UI is the product.
I owned several Windows Mobile phones, one Blackberry, and one Palm device before iPhone and Android came out. I know the history. They were not popular devices. Even just looking at Blackberry sales by themselves, sales of these devices pre-iPhone were absolutely insignificant [1].
Same thing with email. Hotmail/Yahoo/AOL pre-dated Gmail by quite a long time, but Gmail now owns something like 80% of all webmail traffic.
I think your confusion might be where I said "these things existed but no one really liked them" maybe you read "these things didn't exist before"?
[1] https://www.statista.com/statistics/266240/global-revenue-of...
Same thing with email. Hotmail/Yahoo/AOL pre-dated Gmail by quite a long time, but Gmail now owns something like 80% of all webmail traffic.
I think your confusion might be where I said "these things existed but no one really liked them" maybe you read "these things didn't exist before"?
[1] https://www.statista.com/statistics/266240/global-revenue-of...
Lots of old technology is really good but has a bad user interface. There is something to be said for packaging up something in a nice, good looking, easy to use way. I mean, look at how many companies use Sumologic and hosted ElasticSearch for log ingestion. Theoretically speaking, with grep, regex and python you could make all the graphs and charts yourself, there is no real reason to purchase these (pretty expensive) services if you are willing to put in the work. The problem is the amount of work required to do what you say successfully is massive.
Agreed. Easy to use UX is what sells tech and gets it used en masse.
Pretty tangential, but I observed that exact phenomenon recently after looking at the recent VR headsets: Oculus Rift and HTC Vive existed for at least a few years. Tried them, was pretty fun, but tangling with wires, having to have a powerful PC on hand, that 1-2min set up every time before you want to use it, it was all killing the usability for me.
Then Oculus Quest comes out earlier this year. Pretty much similar tech (a few differences, no need for PC, but can be used with one through easy sideloading), but no wires and no need for a PC connection. Every time I want to use it, I don't need to fiddle with my PC. I put the headset on, it wakes up in a few seconds at the exact spot I left it last time. I put it down, it goes to sleep in 15 seconds.
I ended up spending an hour or two almost every day for the past two months playing with it, as opposed to the previous headsets (most of which were left on the shelf a few weeks after the initial purchase). The only major advantage that Quest has over previous gen is easy and frictionless UX.
It got to the point where every single friend of mine who tried it at my place ended up purchasing their own headset the day after. And those people were some of the biggest VR skeptics, after their experiences with original Vive and Rift.
Pretty tangential, but I observed that exact phenomenon recently after looking at the recent VR headsets: Oculus Rift and HTC Vive existed for at least a few years. Tried them, was pretty fun, but tangling with wires, having to have a powerful PC on hand, that 1-2min set up every time before you want to use it, it was all killing the usability for me.
Then Oculus Quest comes out earlier this year. Pretty much similar tech (a few differences, no need for PC, but can be used with one through easy sideloading), but no wires and no need for a PC connection. Every time I want to use it, I don't need to fiddle with my PC. I put the headset on, it wakes up in a few seconds at the exact spot I left it last time. I put it down, it goes to sleep in 15 seconds.
I ended up spending an hour or two almost every day for the past two months playing with it, as opposed to the previous headsets (most of which were left on the shelf a few weeks after the initial purchase). The only major advantage that Quest has over previous gen is easy and frictionless UX.
It got to the point where every single friend of mine who tried it at my place ended up purchasing their own headset the day after. And those people were some of the biggest VR skeptics, after their experiences with original Vive and Rift.
So, what you're saying is there's tons of technologies lying around that are a solid UI and some extra features away from being valuable to normal people. But somehow doing those things and making lots of money is bad?
No, of course not. Neither adding some minor extra features (that make a huge difference for the end-user) nor profiting from it is bad. My concern was that there is so much good tech that is not being utilized just because it lacks enterprisey look and marketing attention.
Take slack as an example: ircd with logging enabled + elastic search/sphinx/lucene + web frontend (use any existing web irc client and integrate that with elastic search results). MVP really seems as a one guy one weekend project. And that was lying underutilized for decades. While my original comment was just a snarky remark, I really think that there are other areas where such a (relatively) simple MVP could allow huge productivity boost to many businesses and allow them to use an existing tool that right now is just too hard/too complicated to use by a wide audience.
And of course the market will reward those that will find the right solution and come up with a great UX improvement to that tech. The hard part is creating the GUI that is both efficient and easy-enough , and the hardest part is of course finding the right tool and the right problem to solve. (edit: formatting)
Take slack as an example: ircd with logging enabled + elastic search/sphinx/lucene + web frontend (use any existing web irc client and integrate that with elastic search results). MVP really seems as a one guy one weekend project. And that was lying underutilized for decades. While my original comment was just a snarky remark, I really think that there are other areas where such a (relatively) simple MVP could allow huge productivity boost to many businesses and allow them to use an existing tool that right now is just too hard/too complicated to use by a wide audience.
And of course the market will reward those that will find the right solution and come up with a great UX improvement to that tech. The hard part is creating the GUI that is both efficient and easy-enough , and the hardest part is of course finding the right tool and the right problem to solve. (edit: formatting)
> ircd with logging enabled + elastic search/sphinx/lucene + web frontend
Slack is way more than that, though.
My recollection is that even the initial version of Slack was more than that.
At this point, it's enough that "let's extend ircd" isn't exactly a practical answer. Either they maintain their own incompatible fork of ircd or they try to force their business desires into the irc protocol.
There's plenty of things that are "just X plus some paint" if you don't look at them deeply. That usually does an extreme disservice to the difficulty of the "plus some paint" part, and often represents a failure to understand the features involved.
Slack is way more than that, though.
My recollection is that even the initial version of Slack was more than that.
At this point, it's enough that "let's extend ircd" isn't exactly a practical answer. Either they maintain their own incompatible fork of ircd or they try to force their business desires into the irc protocol.
There's plenty of things that are "just X plus some paint" if you don't look at them deeply. That usually does an extreme disservice to the difficulty of the "plus some paint" part, and often represents a failure to understand the features involved.
While you are obviously right, I still believe that the MVP one weekend project I described in parent post would still cover a large fraction of use-cases. You could then improve on that and add some "minor" (minor in the sense of dev-time) improvements like syntax highlighting using some free (as in beer) libs for that.
I am not trying to imply that I could "clone" Slack over the weekend by putting together ircd+elastic and then adding some JS cruft on top of that. But I do imply that just that would be enough as an MVP and as something that would make usage of self-hosted IRC possible for a wider, non-technical audience. I also believe that this itself would cover the functionality actually used by many slack users (at least my personal anecdata from 8 smallish companies supports that)
And I also can't stress this enough: I am not trying to say that Slack was created over the weekend or devalue a really impressive and massive effort they've put to get the scale, the functionality and the UX.
I also work fully-remote and the dependency on Slack (prioritized over email) makes it near impossible to communicate with my coworkers during outages because I can't just go over and talk to them.
My deploy on our staging environment fails because the bot can't post the deployment status update on Slack, so yeah, there's that.
...sounds like you need to revisit your CI pipeline. Your build shouldn't fail when your chat tool is down.
This is the first Slack outage where it's really affected me. My team has gone all-in on Slack as our communication mechanism. Though now I get to walk around and talk to people in person, so it's not all bad.
You can apply the same logic to email and the internet in general.
Comparing one proprietary service to federated and open services? I'm not following you
While email as a whole is indeed federated, email service for a single company is usually not, that is you have a single provider and when that provider happens to have technical issues your email might be down. While obviously you could use other provider (or even free email) almost immediately to send emails, you will not be able to receive/access emails that are sent to your primary address/domain until the provider resolves their issues.
>you will not be able to receive/access emails that are sent to your primary address/domain until the provider resolves their issues.
You won't be able to receive new e-mails, but if you use a local client like thunderbird, you can still access your old e-mails.
With slack down, I can only access the messages that I (luckily) have cached locally.
You won't be able to receive new e-mails, but if you use a local client like thunderbird, you can still access your old e-mails.
With slack down, I can only access the messages that I (luckily) have cached locally.
Except that email has built in retries and feedback. Also it's expected to be async, so if a server is down for an hour, most people don't even notice.
> email has built in retries and feedback
Yes it has and it is a great thing - hopefully no messages would be lost assuming that downtime is relatively short. This still does pose a (possibly minor) problem when some mails are urgent.
Yes it has and it is a great thing - hopefully no messages would be lost assuming that downtime is relatively short. This still does pose a (possibly minor) problem when some mails are urgent.
It doesn't really matter how open and federated email is if all mail in/out of your mailbox has to go through one provider. If my company's Exchange server went down, email would stop.
Likewise for Internet service... if my local AT&T connection went down, it doesn't matter how open and resilient the Internet is, I'm not getting online until it's fixed.
Likewise for Internet service... if my local AT&T connection went down, it doesn't matter how open and resilient the Internet is, I'm not getting online until it's fixed.
I used to work for a relatively small dev-shop (9 persons) and we had two independent internet connections from two providers to avoid such problems. This was because done that way because there was only one fiber provider that wasn't really reliable (3+ hours downtimes every 1-2 months) and mobile tethering wasn't really an option as well because of nearby powerlines that made the reception quite a problem - to the point where our sales guy had to go outside the building during some calls. Luckily there was a second ISP - not really fast (10mbps was the best they could do) and quite expensive (we've paid more than twice more for that 10mbps than for a gigabit fiber), but still cheaper than having 9 people not able to work while waiting for the "main" ISP to solve their problems.
When this happens I just switch to tethering from my cell phone. Redundant enough.
So when Slack is down, just text your coworkers. Problem solved.
> f my local AT&T connection went down, it doesn't matter how open and resilient the Internet is, I'm not getting online until it's fixed.
Except that you could work from home, check your e-mail using mobile.
Except that you could work from home, check your e-mail using mobile.
[deleted]
Mailservers are also down very often.
When a company switches from their own e-mail server to hosted Google Mail, their uptime improves.
When a company switches from their own e-mail server to hosted Google Mail, their uptime improves.
No, Slack is more like sunlight, which also exhibits a single point of failure for most orgs. While the sun does go down, it somehow seems more reliable.
> Slack is more like sunlight
Yep. It's pleasant at first and a genuinely useful tool when used correctly, but if you're not judicious with your usage, you could get burned.
Yep. It's pleasant at first and a genuinely useful tool when used correctly, but if you're not judicious with your usage, you could get burned.
I remember there's a Slack architecture case study by AWS[0]. I was a little bit surprised that the architecture can hold such huge traffic.
As a comparison, Discord use's tech stack is more niche and cutting edge[1], but they seem to know very well what they are doing.
It's interesting because AWS use Slack's architecture as a case study because it's a little bit mediocre, that their major potential customers can understand and use. I just don't think AWS will ever use Discord's architecture as a case study...
[0] https://aws.amazon.com/solutions/case-studies/slack/ [1] https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b
As a comparison, Discord use's tech stack is more niche and cutting edge[1], but they seem to know very well what they are doing.
It's interesting because AWS use Slack's architecture as a case study because it's a little bit mediocre, that their major potential customers can understand and use. I just don't think AWS will ever use Discord's architecture as a case study...
[0] https://aws.amazon.com/solutions/case-studies/slack/ [1] https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b
discord is also primary on GCP, afaik?
"Some workspaces might be experiencing issues with messages sending and loading."
(emphasis mine) Is that marketing-speak to lessen the loss of trust?
(emphasis mine) Is that marketing-speak to lessen the loss of trust?
I think it was actually true- I am signed in to two workspaces -- one paid plan and one free -- and only the latter has been unavailable so far.
For me it was actually the opposite. I was thinking that only paid workspaces were impacted, which would be mildly funny
I know nothing about Slack's infrastructure, but in practice Slack issues affect different workspaces differently. I always imagined that a workspace resides in just one of many "clusters" (at the very least, maybe paid/enterprise vs free are separate?). Just speculation though.
You could also have italicized the "messages sending and loading" I think :)
There are a lot of such issues recently on many major websites/services. Is it just me or are those more frequent than a few years ago?
Absolutely feels like that, if it's true would be a task for DownDetector or similar sites with their datasets.
However, this may be the result of increased dependence on centralized services which gain more and more traffic, which is more difficult to handle and even simple Regex rules (see Cloudflare outage recently) can break everything. To be honest, I don't want to ever be in charge of keeping such complex systems online.
However, this may be the result of increased dependence on centralized services which gain more and more traffic, which is more difficult to handle and even simple Regex rules (see Cloudflare outage recently) can break everything. To be honest, I don't want to ever be in charge of keeping such complex systems online.
Seems like an open-source self-managed solution would be preferable at this point.
In my experience, in-house hosted products have had much more frequent outages than the SAAS alternatives. Then when there is an outage, it's down for hours instead of minutes.
[deleted]
RAM prices go tumbling
The new update was actually _very_ good for my RAM usage. Still a lot for a chat app but significantly less than before.
RAM prices crash
January is the only month that slack didn't have a downtime this year. They must have some serious infrastructure issue.
Usage climbing as they become a mainstream choice... what we call a "nice problem to have".
Of course they do have some funded fast followers now; eager to take on any defecting users.
Of course they do have some funded fast followers now; eager to take on any defecting users.
I heard about this news on IRC. Can barely remember the last Freenode outage - must have been years ago.
Why hasn't Slack built a P2P fallback for Enterprise teams?
Slack server knows at least which clients has recently been active in a chatroom, so the server could send that information to clients (per privacy opt-in) who can then make a best-effort attempt to send their new messages to the recently-active clients.
Perhaps that's just self-hosting with extra steps. At some point, isn't it cost-effective to offer customers a SaaSBox that they can deploy as a minimal-functionality on-prem backup to the cloud service?
Slack server knows at least which clients has recently been active in a chatroom, so the server could send that information to clients (per privacy opt-in) who can then make a best-effort attempt to send their new messages to the recently-active clients.
Perhaps that's just self-hosting with extra steps. At some point, isn't it cost-effective to offer customers a SaaSBox that they can deploy as a minimal-functionality on-prem backup to the cloud service?
One of those frustrating situations where i think my message is sent, but it isn't, and sometimes I'm getting responses and sometimes not.
Half failing is way worse than completely failing.
Half failing is way worse than completely failing.
Slightly offtopic : As a remote engineer, I wonder if half-duplex voice (kind of like a CB radio) would be superior for communication vs typing everything?
E.g. when I have an idea, I just talk, that comment is recorded and made available to the chat room.
I'd like to get back some of the nuance of language that just isn't possible with text.
There'd have to be some easy way of playing back the voice snippets in order that were posted to the chat room.
Maybe Discord is superior to Slack for this.. I've never used it.
E.g. when I have an idea, I just talk, that comment is recorded and made available to the chat room.
I'd like to get back some of the nuance of language that just isn't possible with text.
There'd have to be some easy way of playing back the voice snippets in order that were posted to the chat room.
Maybe Discord is superior to Slack for this.. I've never used it.
It takes much longer to listen to an audio recording than it does to read a sentence. And in certain cases, compose one.
Agree, because the audio is richer.
A slight pause, a 'hmmmm', a chuckle, can infer the statement as a question, or at least give a hint as how confident the statement is, instead of a proclamation.
Otherwise, without inflection, every sentence can read as a definitive statement. Zero nuance, and we end up with places like Twitter. It's awful for discourse.
A slight pause, a 'hmmmm', a chuckle, can infer the statement as a question, or at least give a hint as how confident the statement is, instead of a proclamation.
Otherwise, without inflection, every sentence can read as a definitive statement. Zero nuance, and we end up with places like Twitter. It's awful for discourse.
Nuance is great and all but when you're deal with a lot of information you want to convey information as clearly and unambiguously as possible. Audio just doesn't have the information bandwidth that writing does.
How so?
What can be said with writing can also be said with speech.
But with speech, you also have verbal queues, pauses, tone, inflection, that implies so much more.
What can be said with writing can also be said with speech.
But with speech, you also have verbal queues, pauses, tone, inflection, that implies so much more.
Because you can read a sentence much quicker than you can listen to an audio clip of that same sentence. The inflections don't convey as much unambiguous information as actual words. Was that sigh because someone was tired, frustrated, or just needed to take a breath?
Used to really like full-duplex voice in Nextel phones eons ago.. it was good for initiation conversations, which would then pull people into whatever chat we needed at the time. Not sure we'd use it the same now, but we were running our own servers at the time, things weren't quite stable yet, and some of us were frequently out of the office.
I've wanted to build a proper calling-tree & follow client for Pagerduty (or, own platform) because there's still a need for non-technical notifications in an org where people just won't visit a status page... or when sales/tech support need to know sooner, rather than later, than an environment is suddenly down.
I've wanted to build a proper calling-tree & follow client for Pagerduty (or, own platform) because there's still a need for non-technical notifications in an org where people just won't visit a status page... or when sales/tech support need to know sooner, rather than later, than an environment is suddenly down.
Discord's voice features are only really live and full duplex. Think more like party line / conference bridge than sending recorded snippets. There also isn't a built-in way to record such voice communications. That said, there are many other chat platforms which either support voice snippets in conversations (Facebook Messenger, WhatsApp, Signal) or even are focused on sending voice snippets (Voxer, Viber).
This is very common on WeChat, from what I can tell most people communicate with voice snippets.
Interesting to explore, but probably not as good for search/copy pasting, etc. (or it needs to come with automated transcription).
I propose the hashtag #SlackOff.
I honestly don't know how Slack can tout themselves as the email killer [1], when they seem to have rather consistent downtime.
[1] https://www.nytimes.com/2019/06/19/style/slack-replace-email...
[1] https://www.nytimes.com/2019/06/19/style/slack-replace-email...
I've worked in organizations where exchange is down more than it's up. shrug
I see lot of frustration and alternatives provided for slack. However, I'm genuinely curious about the degree of dependence on slack for team based communication? Do people not use email anymore? We have slack at my company as well and yes it was frustrating, but we have email list. Thing just works.
P.S I don't work for slack or have any affiliation.
P.S I don't work for slack or have any affiliation.
Now we can put slack into the list of Major league tech companies which cannot keep the services up and running 24/7.
Cloudflare Facebook and its group of companies Azure cloud Google Cloud , twitter etc etc
AWS, eyes are you now :)
Cloudflare Facebook and its group of companies Azure cloud Google Cloud , twitter etc etc
AWS, eyes are you now :)
S3 went down for nearly an entire workday a few years ago. It legit pretty much broke everything. We all went home because there was no way to do any work.
Funny enough, that S3 outtage busted Slack's file feature.
oh yeah, Netflix was down along with a loads of companies when aws had its issues, but the list i put out was the ones in last few months ;)
Is it really that hard to spin up an IRC server for moments like these? I too have had to switch to Skype communications today. I wish people used IRC in the first place so I could write my own bots.
I've been meaning to figure out how to do this for my office. From what I can understand, setting up the IRC server is easy, making it "secure" is kinda hard, getting slack features like shared history (so you can log out, back in, and see your messages) is fairly hard. I've only done cursory glancing over blogs though.
Also I would need to help my coworkers choose and settle on a client. Particularly one for the phone. I used to use androidIRC but I kept getting booted from channels cause when it was in my pocket it would spam connect/disconnects.
Also I would need to help my coworkers choose and settle on a client. Particularly one for the phone. I used to use androidIRC but I kept getting booted from channels cause when it was in my pocket it would spam connect/disconnects.
You can write bots in Slack. Actually they tout that as a big feature.
problem is, non devs don't use IRC.
Yep down here too.
https://status.slack.com/2019-07/b31a6510b8caabcc
Downdetector reporting a lot of AWS complaints simultaneously.
NA is all green per -- https://status.aws.amazon.com/
Any alternatives to Slack with parity screensharing functionality?
Being able to draw on the screen is so valuable for remote pair programming—Hangouts/Skype don’t cut it
Being able to draw on the screen is so valuable for remote pair programming—Hangouts/Skype don’t cut it
My Android tests on my test device started failing at the same time. Is Slack app's background service flooding my network?
My charger blew the electricity off at the same time. Got back online without slack working, I thought I broke the internet
That's a cool post-mortem story, thanks for contributing!
Removing Slack app fixed the issue. Very weird coincidence.
With Slack unable to send messages, I had to contact people via trembles Skype for Business
I would love it if I could use Skype, but Skype has been consistently crashing on my machine for the last month. And even when it opens, it almost never works correctly.
Well, since ( according to ) Slack is the be all and end all of business communication and killed email, I can only imagine the absolute caos throughout the World that's going on right now.
I expect an economic downturn worst than the Depression in the 30's.
I expect an economic downturn worst than the Depression in the 30's.
Since we have GSuite at work, figured I'd post my first thread to chat.google.com and imagine that's our plan for #SlackDown. Don't imagine anyone will notice and that life will carry-on. Even created #general ;-)
It's a really viable fallback - I did the same thing this morning. The only difference is the team / channel aspect. While Google Chat supports those features, the effort to seamlessly fallover to "backup channels" is harder than DM-type stuff.
Quick! Analyze whether there was any correlation between number of bugs created (in Github repos, for example) and the Slack downtime.
Ponder for a second how many bits of sensitive information and competition secrets are right now on Slack.
The recent rise in Slack downtime might be enough to actually cause significant churn.
what also sucks is that they don't offer an 'offline' mode to read existing msgs! (update - this works on IOS but not on the desktop..for me at least)
I had to reload so many times. I emailed instead
[deleted]
And there was much rejoicing.
... and productivity is up
"destroy the skynet" john connor
The way it's handled in the app is also not ideal to say the least - only indication that something is wrong is that the text you are trying to send is greyed out.