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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"?
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)
> 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.
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.
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.
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 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 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.
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.
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.
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
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.
This is becoming so often it's embarrassing really.
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.
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.
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.
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.
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!
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).
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]
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.
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.
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.
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.
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.
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.
> 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 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.
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.
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.
> 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.
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?
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.
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.
Ooof, I'd hope they would have improved CPU use when handling lots of GIFs. Tusky and Mastodon's web frontend handle pausing offscreen GIFs pretty well, my fan doesn't spin up at all (unlike Slack's desktop client last I used it).
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.
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'.
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.
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.
In my experience, yes, I see the misconception frequently. I think it stems from Microsoft using the name "Virtual memory size" for swap space in earlier versions of Windows.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 ?
> 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.
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
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.
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.
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 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.
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.
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.
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.
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?
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).
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.
242 comments
[ 6.6 ms ] story [ 273 ms ] threadWhen a company switches from their own e-mail server to hosted Google Mail, their uptime improves.
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.
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.
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.
Except that you could work from home, check your e-mail using mobile.
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.
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.
Hackers like to pretend that presentation doesn't matter, but in the end presentation is the only thing that matters.
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.
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...
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)
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.
- Phone apps from the jump - Easy ability to upload files - Search includes the content of those files - Editing
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.
Post-mortems are interesting.
My best guess is summer vacation :) it's at least true for my company who was one of the featured outages
TL;dr- complex systems are complex, and trying to understand them isn't usually possible for outside parties.
Bridges are also super handy for integrating with IRC, Slack and similar.
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
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.
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.
Is it stated in the pricing page that you get better error handling if you pay?
https://rocket.chat/
Disclaimer: I've done a GSoC project with them last 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...
What is the A part of Stack's SLA?
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.
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.
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 work on Zulip.)
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 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.
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
Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?
This abusive resource usage has created a dislike of Slack among a subset of its users.
I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
Using the browser based version often is less resource intensive.
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.
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.
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.
Not sure why you think OP can’t say “Slack sucks”.
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.
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.
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.
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.
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.
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/
- "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.
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.
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.
(I work on Zulip.)
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.
[1] https://www.nytimes.com/2019/06/19/style/slack-replace-email...
(emphasis mine) Is that marketing-speak to lessen the loss of trust?
(Exception being 3 guys in the UK and one guy in the US, who is not an admin or owner)
I expect an economic downturn worst than the Depression in the 30's.
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.
I'm thinking more of collaboration - when the solution isn't necessarily known and there's a lot of back and forth.
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.
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.
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.
Of course they do have some funded fast followers now; eager to take on any defecting users.
Being able to draw on the screen is so valuable for remote pair programming—Hangouts/Skype don’t cut it
But we still rely on Slack for general messaging and chat rooms.
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.