Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zulip Server 1.9: HipChat import and much more

blog.zulip.org

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Zulip Server 1.9: HipChat import and much more

#41

Post by TheDong »

Polyisoprene wrote: post #13

We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?

> more of a tech demo than a product

It is neither a tech demo nor a product, it is a mature open source project.

In fact, in my mind tech demos tend towards having fewer mature components.

> Redis, Postgres, Rabbitmq and Memcached just to run a chat

That set of dependencies seems quite normal to me for a mature project. Mastodon (the most popular open-source-twitterish-thing) has a similar set of dependencies, and is also effectively just chat as you say.

Discourse, a popular open source forum, is also basically just chat, and has a similar set of dependencies.

In the case of zulip, you can even use a hosted version and avoid running anything yourself.

I don't understand why its totally normal set of dependencies turns you off so harshly. I'll happily take a project using redis/postgresql/etc instead of trying to build its own versions of those baked into the binary because components like postgres/redis/etc have great documentation, tooling for metrics and monitoring, etc... If the project bakes its own stuff in itself to avoid taking on dependencies, I doubt it will either be as good or as easy to manage.

Re: Zulip Server 1.9: HipChat import and much more

#42

Post by sien »

woolvalley wrote: post #27

How does it compare to mattermost?

Exactly.

We're looking at paying for Slack and mattermost seems to offer most of what Slack does and is something that would be pretty easy to run. It's slick. Well documented and installs nicely in a container.

Has anyone here used Mattermost?

https://mattermost.com/

Re: Zulip Server 1.9: HipChat import and much more

#43

Post by tabbott »

erinnh wrote: post #28
nicholasjbs wrote: post #21

We (the Recurse Center) have been using Zulip since early 2013, and it is the core of our online community. Zulip is excellent both for small teams (we use it for our team of 7) and big groups - we also run a realm with over 1,000 users posting 10s of thousands of messages monthly. I can't recommend it highly enough.

How do you handle high availability for Zulip? Last I looked that was a problem for it.

Zulip founder here.

It's definitely possible to run a Zulip server with essentially no downtime. E.g. the main zulipchat.com service has had approximately 10 user-facing outages with a median duration of 5-10 minutes over the last 5 years (there was one while we still only had a few hundred users that lasted overnight), most of them in the middle of the night. Happy to talk more about this for anyone curious; there are some fun stories (like migrating from MySQL to Postgres as our primary database technology with We don't have a public uptime SLA for zulipchat.com uptime yet, but we're happy to make them for individual customers (and I suppose we should add one).

If you're self-hosting, our commercial support offerings will help you setup your servers in a way that achieves your uptime goals; because Zulip is so stable, usually folks just go with a hot spare (our enterprise customers generally only report downtime related to server upgrades, which is usually avoidable).

Re: Zulip Server 1.9: HipChat import and much more

#44

Post by jfrankamp »

aidenn0 wrote: post #38
jfrankamp wrote: post #37

Earlier quoted context omitted.

What is the advantage of threads over just more specific top level channels. e.g. in their example why not #annual-summit-name-tags etc. One immediate thing slack does wrong is it makes channels too hard to make and destroy and leave and join, but if that was fixed... What is the advantage of the nesting?

zulip ends up being a bit like e-mail where you can add people to threads and they immediately have the history. I've used mattermost, not slack, but that basic model fixes a lot of issues I have with mattermost.

A more specific slack channel (and I assume mattermost channel) is a thread that you can add people to any time and they will immediately have history. Or put in the inverse, a Zulip thread that is too general is a channel with information overload and becomes useless. Does the nesting have intrinsic value over simply more top level channels?

Re: Zulip Server 1.9: HipChat import and much more

#45

Post by Polyisoprene »

hobbescotch wrote: post #19
Polyisoprene wrote: post #13

We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?

This would certainly make it easier https://github.com/zulip/docker-zulip/blob/master/docker-com...

Well, it’s not fewer components regardless how you package it. Running docker compose wasn’t enough to get into a fully configured system to be able to evaluate it even.

Re: Zulip Server 1.9: HipChat import and much more

#47

Post by austinjp »

rekwah wrote: post #39
jtchang wrote: post #36

Earlier quoted context omitted.

Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

Is this a common workflow? Googling suggests almost religious feelings about this.

Re: Zulip Server 1.9: HipChat import and much more

#48

Post by tabbott »

grizzles wrote: post #46

Judging from the zulip.org server it looks like there is a need for a chronological topic decay feature.

Zulip founder here; I'm curious why you think that?

Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep the complete history, both of messages and topics, because it's useful for search and following up on things. Personally, I regularly reply to a conversation whose last message was a month or more ago to follow up with new information (often after getting there from one of the permanent links in our issue tracker). Because the context is all there and available with just a single click on the topic, I find it to be a really nice workflow.

Re: Zulip Server 1.9: HipChat import and much more

#49

Post by rekwah »

austinjp wrote: post #47
rekwah wrote: post #39

Earlier quoted context omitted.

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

Is this a common workflow? Googling suggests almost religious feelings about this.

Anecdotally, I feel it's less common than merge commits. There are plenty of places driven by the "Merge Pull Request" button in GitHub and that's the default functionality.

In personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.

Post reply on HN