My research group at Stanford uses Zulip for instant messaging. I like it A LOT more than Slack. I'll list a few of the features I think most contribute to why Zulip > Slack (IMHO). Also, I'm not affiliated with the maintainers of Zulip at all. I am just a big fan of their software :).
- Zulip has something called a "topic" which is basically a Slack thread but with a name/subject-line. Unlike Slack threads though, every message you send has to be sent in a topic. Zulip makes it much easy to context switch between these topics too. Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.
- The Zulip UI offers a lots of nice features compared to Slack too. For one, you can see the number of unread messages in each topic directly from the main page. Zulip also supports multi-line messages so you don't have to send a bunch of message one right after the other to break up text, you can add line breaks directly to your message.
- Zulip has a "message drafts" features which is nice when you want to draft a message (or multiple messages), but will send it later. Zulip will hang onto your drafts until you need it.
- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.
- Zulip has full color syntax highlighting when embedding code-snippets into messages! It has support for basically every programming language I can think of (including brain-fuck!).
- Zulip has support for latex equations in messages.
- Zulip is open-source! You can use the version of Zulip hosted at zulipchat.com or you can deploy your own Zulip server by grabbing the source code from github (https://github.com/zulip/zulip).
- In the time since I have switched from Slack to Zulip (about 1 years ago now), Slack has gone down 3-4 times and has had other connectivity issues; Zulip had maybe 1-2 minor interruptions that I can think of in that time.
My research group (at MIT) also uses Zulip for messaging.
While I agree with everything jremmons said (hi john), it's important to note that their mobile apps are so bad that they're basically unusable - there's a particularly aggravating bug in the iOS app where if you don't open the app for a while, it forces you to load and scroll through days of messages to read the most recent ones.
> every message you send has to be sent in a topic. ... Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.
After some short period of playing with Zulip with a colleague of mine I found this feature to be confusing, at least for new users: it is way too easy to disregard the concept of topics and start writing to the random topic that happens to be selected in user's client atm, and in the end the conversation mess keeps being a (slightly rearranged) mess.
This is where the topic editing feature comes into play; any user can change the topic of a message sent recently, and if someone posts something in a wrong topic, it can be moved to a different topic.
Also, after a while this paradigm grows on you and by forcing you to think of a relevant title for your conversation, it forces you to have more cohesive conversations in my view.
And, lastly, it is possible to send messages without any topic (it defaults to (no topic)). :)
I’ve been wondering about this. Instead of topics, why not use hashtags? I know in Slack the hashtags indicate the channel, but they don’t need to. So instead of having set topics, you could just add a tag to messages to indicate the topic.
When a user is forced to make a decision on something like ‘topic’ just to send a quick message, you’re more likely to get randomly assigned, meaningless topics. Random hashtags, on the other hand, are no big deal. Because you have to actively search for the ones you want.
This has been the paradigm since Web 2.0 and it seems to have worked pretty well.
Random topics are no big deal in Zulip either. You can either a) edit the name of the topic at any time if needed or b) create a new topic as topics are cheap
I'll also add that one of my favorite features is the vim-like keyboard shortcuts. It makes navigation very quick, and I love being able to easily quote an entire message by just hitting `>`. The full markdown and keyboard shortcuts are fantanstic to have.
I loved google wave -- it was great and ahead of its time. I think it was a major mistake that google let it go and that the apache wave foundation never got it going. it is too late now but really a greatly missed opportunity.
(2) It tried to be an all-in-one comm platform, and because of that it excelled in none of what it tried to do.
(3) Poor UI performance was the death sentence of it. If you can't use it fluently, it's not good for real-time. Poor UI design did not help, on top of that.
It was an interesting experiment, but not all experiments end up with a successful product. I hope the ideas will be unearthed at some moment and reused with a greater effect.
Real-time email is a contradiction in terms, as (at least for me) being asynchronous is one of the main defining features of email. Essentially any chat app, from IRC to Slack, can be called "real-time" email. To me, the phrase "real-time email" sounds like calling a submarine an "underwater car".
IMs hit the sweet spot between fully real-time (like the phone) and fully async (like paper mail).
The UI is built for efficient real-time communication, but the underlying data model (the log, notifications, statuses, etc) allows for very easy async communication.
I think someone could make a great product by just adding IM-like UI features on top of an existing email backend. Email is pretty fast these days to work as mostly-instant communication.
I agree! Check out https://delta.chat. I use it every day for emailing. Subject lines are the ellipsized first words of your body and every message is a new email.
slack threads suck I might look into Zulip though, this seems interesting. Having subchatrooms compiled into one giant chatroom is also how I organize my gmail as well. So you have the option to look at individual rooms or just one room to see the same content
I wish it had color text input support. At my last job, they were looking to replace IRC with RocketChat, and that was a big let down. I even submitted a PR for "Colored Markup" (https://github.com/RocketChat/Rocket.Chat/pull/8639/commits)
The use case at the last job, was that I had an IRC bot that had a lot of stuff to deal with support stuff, like DNS configuration for the Hosted Exchange offerings (2010 and 2013 were offered), and it would do colored text for good and bad configurations. Just made it easier to point out the issues.
Well, IRC clients allow for more customization for the end users, RocketChat - there was very little. The dev team didn't want to add hacks on to it and would only update when RC would release a new version.
Minor nit: I wish the "With great data come great neural networks" graph in the blog post had data points from real experiments instead of the hand-wavy curves that are drawn. I know the goal is to give intuition about DNNs v. classical methods, but I don't think I've ever seen a version of this graph with real data! I doubt the real curve would be infinitely differentiable like the ones plotted :P.
>> Neural networks have recently met success because of the rise and availability of large amounts of data.
I think that the improvement in computation power has had at least as much of an impact on the field as data! The only reason people have even bothered to collect the amount of data they have is because the DNNs that need the data are finally cost effective to run on modern hardware.
I feel like this article does not substantiate its core claim, "clever coders can beat tech giants." The main evidence given by the authors is that because Google lost to a much smaller company, Fast.ai, on a toy problem (training a model to 93% accuracy on the CIFAR-10 dataset) that small-time AI researchers can beat the big guys at their own game. This feels like a straw man argument and I'm not convinced.
That said, I do think smaller, independent AI research groups can be impactful even if they aren't going to beat Google in a head-to-head competition; they just have to find problems the tech giants aren't working on yet :).
Jeremy from fast.ai here. I think it's tough to really substantiate this claim fully in a mainstream tech publication, without getting into details that are likely to be rather dull for much of the audience. However, I do think that the claim is a reasonable one, and there's more details to substantiate it in this article I wrote: http://www.fast.ai/2018/04/30/dawnbench-fastai/
Training small-ish datasets quickly is definitely not a toy problem. Most folks I know using neural nets in practice are using datasets of ~100MB. Some people do have giant datasets, but it's not the norm. And being able to train them quickly and cheaply is great for running experiments, as well as making the field more accessible to people with fewer resources.
If you're only interested in training larger datasets, this competition showed that the fastest Imagenet training on a single machine, and the fastest on publicly available infrastructure, also was done by fast.ai. The only better results were on TPU Pods, which are TPU machine clusters that are not publicly available. (It wouldn't be terribly hard to show similar results with a cluster of GPU machines, although it wasn't something that we have spent time on ourselves as yet.)
I strongly disagree with your claim that small groups can only compete with tech giants on stuff that tech giants aren't working on. There is a large amount of empirical evidence both now and throughout history that this isn't correct, and you have shown nothing to substantiate this claim. (I heard similar claims when Google first appeared: "a small group of Stanford researchers can't beat Yahoo.")
The reason T-Mobile looks so bad is because the T-Mobile trace was from a 3G network with very poor conditions, while the others (AT&T and Verizon) were from LTE networks under relatively good conditions. You shouldn't compare the quality of the carriers from our results.
A practical issue I've seen with high-bandwith non-TCP transports (including video over RTP) is how they behave in the presence of multiple other streams on the line; when bandwidth becomes limited often you get one winner and a bunch of loser streams. Does salsify address this at all?
It's not a focus of this project, but in a different project we have set up some pretty careful measurements (running every few days) to test whether this happens to different congestion-control schemes, including ones like CUBIC (Linux's default for an Internet stream socket) and Sprout (which Salsify's transport protocol is based on).
The bottom line is that TCP CUBIC is actually pretty bad for reasonable-length flows, and Sprout is empirically better (at the cost of getting a lot less throughput!).
I guess one key thing to note here is that Salsify is not a "high-bandwidth" transport -- one of the main goals is to wait until the network is ready for a frame (killing off encoder outputs if necessary) to avoid overloading the network and provoking packet loss or queueing delay.
Video over RTP can mean a lot of things, including totally unresponsive traffic that doesn't vary the sending rate in response to congestion signals at all. If an app does this, yeah, life can suck.
I just remember going through a log and seeing 3 RTP streams that had gotten into sort of a harmonic oscillation pattern where they each would observe congestion at different times and back off in turn, and then one stream would consume most of the bandwidth until it's backoff triggered, then another stream would do the same.
I have zero more detail on how they were managing backoff though as this was like 6 years ago with some random video-meeting software that probably doesn't exist anymore (I think there were 100s of video meeting companies that started and died from 2010-2013).
These are encapsulation and signaling protocols, but don't really cover the questions of when to send each compressed video frame, how big it should be on the wire, and how to write an encoder that can compress it to hit that target size accurately. Some of the schemes we compared against (WebRTC reference implementation in Chrome, Hangouts, FaceTime, Skype) certainly use various parts of the standard protocol suite (with different engines to decide when and how much to send). But the call setup and encapsulation are not the focus here -- I'm sure we could do Salsify within SIP or WebRTC if necessary.
I have used tesseract and in my experience unless you train it for the particular type of text you want to recognize (font, background color, etc.) it will do quite poorly (including the recent lstm based versions). Would be great to see how it stacks up against these APIs though.
The supplied models are trained on document-like images, so I wouldn't expect it to do particularly well on things like street signs. My experience with the new lstm based versions is that it's very much competitive with closed source solutions for document-like OCR.
The cost savings are not the main advantage of AWS Lambda compared to EC2 (AWS recently announced EC2 will bill on a per second basis and a minimum of 1 minute). Instead, I'd argue that the programming interface, managed operations, and scalability are what makes it a better tool for these types of tasks! I'm looking into running other more general computations on Lambda right now as part of my PhD! (stay tuned for more soon). Until then, check out ExCamera (https://www.usenix.org/conference/nsdi17/technical-sessions/...) and PyWren (https://github.com/pywren/pywren).
- Zulip has something called a "topic" which is basically a Slack thread but with a name/subject-line. Unlike Slack threads though, every message you send has to be sent in a topic. Zulip makes it much easy to context switch between these topics too. Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.
- The Zulip UI offers a lots of nice features compared to Slack too. For one, you can see the number of unread messages in each topic directly from the main page. Zulip also supports multi-line messages so you don't have to send a bunch of message one right after the other to break up text, you can add line breaks directly to your message.
- Zulip has a "message drafts" features which is nice when you want to draft a message (or multiple messages), but will send it later. Zulip will hang onto your drafts until you need it.
- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.
- Zulip has full color syntax highlighting when embedding code-snippets into messages! It has support for basically every programming language I can think of (including brain-fuck!).
- Zulip has support for latex equations in messages.
- Zulip is open-source! You can use the version of Zulip hosted at zulipchat.com or you can deploy your own Zulip server by grabbing the source code from github (https://github.com/zulip/zulip).
- In the time since I have switched from Slack to Zulip (about 1 years ago now), Slack has gone down 3-4 times and has had other connectivity issues; Zulip had maybe 1-2 minor interruptions that I can think of in that time.