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

Dropbox has open-sourced Zulip

zulip.org

Post reply on HN
Print view View original

291–300 of 323 posts

Re: Dropbox has open-sourced Zulip

#291

Post by tabbott »

spb wrote: post #182
tabbott wrote: post #28

Earlier quoted context omitted.

Zulip doesn't have a strong dependency on Ubuntu 14.04. It would be less than a day's work to have it support any additional version of Debian or Ubuntu (precise/wheezy would be quite easy since we've run both in production). It's probably also not hard to support something RHEL-based too but that'd be a bit more work. RAM usage could also be brought down a lot for smaller environments with a bit of work; most of it…

>we run a set of like 15 queue processing workers that each import the entire application Where would one start if they were looking to disable that?

Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/32 to track improving the worker setup.

If you're interested in helping I'm more than happy to give you a bunch of pointers for how to do it :)

Re: Dropbox has open-sourced Zulip

#293

Post by noelsusman »

new299 wrote: post #254
kevinr wrote: post #149

We've been using Zulip internally for a couple of years now. We've used IRC and Jabber, looked at Slack and Hipchat and Skype and Lync, and somehow keep coming back to Zulip. It lets us have real, ongoing, and substantive conversations, with a large number of participants, without being overwhelmed. I sometimes feel like Twitter is actually a better comparison for Zulip than Slack---in Zulip like on Twitter, it's eas…

I'm sure it's a great communications tool, however since Rice joined Dropbox's board ( http://www.drop-dropbox.com/ ) I'd have severe concerns using anything released by Dropbox. Even if it's open source. And while I apologize for a tangential comment, people should be aware of the politics promoted by their software vendors. Hopefully if it's a truly valuable tool it will be forked and audited.

Do you boycott every company that has any questionable people on their board? This feels like cherry picking because of how high profile Rice is. Her only crimes are being in the Bush administration and doing her job, and being on the board of an oil company. That's pretty weak.

Re: Dropbox has open-sourced Zulip

#294

Post by tracker1 »

latch wrote: post #183
tracker1 wrote: post #161

Earlier quoted context omitted.

Redis does have persistence options... I was just thinking Redis is often used as a more advanced memcached, while also supporting pub/sub channels and acting as a mq broker with a frontend... was just thinking in terms of reducing the requisite services, since rabbitmq requires erlang and it's own services as well as memcached. http://redis.io/topics/persistence http://python-rq.org/

In fairness, your parent introduced the word "persistence" to this discussion, but I think you're misunderstanding queues if you think the two are interchangeable. Two things you often want are at-least-once delivery and the ability to queue messages without requiring the consumer to be connected. It requires a fair amount of work to get this to work in Redis. It's not simple configuration.

I believe that you can already do this with python-rq, I understand what persistence means in terms of message queue patterns. There are several persistent queue systems that build on top of redis as a backing store... I was mainly questioning the use of 3 different servers, where 1 would be able to handle the workload.

Re: Dropbox has open-sourced Zulip

#295

Post by e12e »

jallmann wrote: post #249
e12e wrote: post #216

Earlier quoted context omitted.

Sigh, sorry to hear that. I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 :-/ It seems obvious multimedia calls is part of our future, and I refuse to let that be dictated by corporate lock-in -- be that Skype/Lync, Hangouts or whatever Facebook will launch when they enable videochat. And any…

> I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 I guess you could try to run H.323 through a $protocol bridge, but I don't know why you would want to. Retrofitting modern features onto H.323 does not seem like fun. Because if SIP suffers from being too general, H.323 suffers from being way t…

Right. Interesting that XMPP in many ways reimplemented some of the problems of both IRC and USENET wrt. federation.

> Retrofitting modern features onto H.323 does not seem like fun. Because if SIP suffers from being too general, H.323 suffers from being way too specific in its architecture and technology requirements -- read through some of the associated specs, eg H.245, and it's not hard to see why SIP won. For the longest time, there was not even the notion of URI addressing...

Sorry to hear that. My general thought was that for a personal system, it would be way lower barrier to use existing h.323 server/clients, than to make a whole new protocol -- and that's probably true.

But if it has been effectively abandoned for a while, SIP might be better -- even if what one might effectively end up with is "proprietary" SIP, as one picks a subset that works for a particular use-case.

Personally I have to complementary goals: The first, and most important, is to build something that allows group chat with archiving, hopefully integrated with optional audio/video and some kind of media sharing (be that wiki, or something more traditional like straight up sharing of files/documents) [But it it should be obvious that by uploading to a wiki with shared authentication/authorization, one would only need to share an url over chat].

The second goal would be to enable federation, at least among those with the know-how/interest in running their own nodes.

Oh, and goal zero would be to retain control, so self-host (although option to get it "on tap" as a service would be nice), and Free/Open software/protocols.

In the end, perhaps XMPP along with just video/audio via WebRTC turns out to be the least worst option. I'm a little worried that the "web-centric" solutions like Mozilla Hello/together.js etc is difficult to pair up with command line clients, bots and/or make accessible for those that need it (eg: braille terminals). I guess audio might be preferred to braille in the general case, even for asynchronous messages, but text is very flexible (eg: text-to-speech system exists).

Re: Dropbox has open-sourced Zulip

#296

Post by darkarmani »

Wow. Good luck installing this. I'm not touching it. It needs to do all sorts of hokey things to work. It needs puppet and git to work? You can't just install python packages, it installs them from a ppa. Deployment is a huge mess. It doesn't have to be this hard.

Re: Dropbox has open-sourced Zulip

#297

Post by lwf »

darkarmani wrote: post #296

Wow. Good luck installing this. I'm not touching it. It needs to do all sorts of hokey things to work. It needs puppet and git to work? You can't just install python packages, it installs them from a ppa. Deployment is a huge mess. It doesn't have to be this hard.

Thanks for the feedback. We prioritised getting this into a state where it can run in dev and production based on the existing deployment processes we used in our own environment.

I'm working on a Debian package[1], and we expect to iterate on the deployment process in general.

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800052

Re: Dropbox has open-sourced Zulip

#299

Post by lwf »

mapletune wrote: post #255

Does anyone know if Zulip has support for directory integration? whether it's OpenLDAP or MS AD. Hell, even RADIUS would be ok by me... @@

LDAP is supported:

https://github.com/zulip/zulip/blob/b69c6228af03634061cba29f...

Also, generic webserver-side REMOTE_USER authentication is supported.

Re: Dropbox has open-sourced Zulip

#300

Post by talves »

manigandham wrote: post #140

Side note: Please STOP using tiny font weights. Text becomes ridiculously hard/painful to read. There's no reason to use a font-weight of 200 (or anything less than 500) on body text, save that for the headlines. http://i.imgur.com/r7a794n.png

The problem is not so much the font weight as the font itself. Time to abandon 'Humbug' on that site which is translating to SourceSansPro-Light-webfont at font-weight: 300.
Post reply on HN