151–160 of 323 posts
Wouldn't it be better if the multi-platform wrapper for Webkit web view was a separate project? Should be useful, if it doesn't exist already.
Earlier quoted context omitted.
There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing? (Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom ( http://newsroom.grasswire.com ) and some other communities ( http://fpchat.com ) have repurposed it for that.
I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job. In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access. Quick review of the globally federated protocols: Email is too slow and bulky a…
I suppose the difference between our points of view is that I would much rather have a better tool than a publicly accessible archive of message history.
Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (Instant/Live was a plus back then). And the only innovation over IRC was a backlog and buddy list. I wonder when the Trillian of Slack+Zulip will come out. I hope Trillian (which still exists) is already working on it.
We have had thousands of years to work out our nuances over interruptions and social signals when around the same campfire.
But suddenly (and from the past 20-30 years suddenly) we have phone conferences where half the conversation is "no, sorry, you go ahead" and email going from killer app to no longer being a way to get a reply in ten minutes but two days because the signal to noise ratio hit a tipping point somewhere around 2006. (No it's not spam, that's mostly a done problem. It's co-worker spam that's clogging our minds of not our inboxes)
So the differences between Zulip and Twitter and Slack and IRC and Microsoft bloody communicator why does it not know about tabs ffs! (Sorry). The difference with all of these is not their technology - it's pretty much the same all the time - but their social utility.
One day some comms package will get it all together (I think there is too little context to get it right yet) and we will all go"of course".
Until then we will try each different social choices baked into the code - rooms or tags or whatever. Maybe the next step is to have rooms for something, open cry for others.
Who knows - maybe we should look at pubs bars, libraries and streets for inspiration.
Whatever it is - Zulip is not the right solution nor is it the best - it is one more random mutation in the evolution of remote communication.
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…
You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
"The Zulip desktop app is a C++ application written with the Qt toolkit. It is a lightweight wrapper around a Webkit web view: it loads the zulip webapp as a single page full-screen webpage. The desktop app provides some native integrations: tray icon and Dock support, notifications, and more." Wouldn't it be better if the multi-platform wrapper for Webkit web view was a separate project? Should be useful, if it does…
"You can install a Zulip server on a system with 2G of RAM, but for production use we recommend a system with 4GB of RAM or more." Something has gone horribly wrong when a chat server can barely run on 2G. edit: As a frame of reference, here's what Inspire IRCd needs: > A network with 3000-4000 locally connected clients and 10000 open channels experiences a constant 1-4% CPU use with 70MB of RAM use. This won't go up…
See https://news.ycombinator.com/item?id=10280246 . Historically most users were using the single cloud installation at zulip.com, and so having this significant fixed memory overhead wasn't a problem. I expect someone will do the work the fix this before long; it shouldn't be hard.
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…
So Zulip was acquired in March 2014 http://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-st... You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
I think my blog post covers pretty well why we open sourced Zulip: https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a....
Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (Instant/Live was a plus back then). And the only innovation over IRC was a backlog and buddy list. I wonder when the Trillian of Slack+Zulip will come out. I hope Trillian (which still exists) is already working on it.
Earlier quoted context omitted.
So Zulip was acquired in March 2014 http://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-st... You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
Just to clarify, most users of Zulip were using the central cloud service (zulip.com). Kevin's experience is from one of the Zulip customers who had "Zulip Enterprise" (aka a Zulip server in their own data center -- which is also the basis of the "self-hosted production server" installation process you see now is based on). So "turning it off" in this case refers to their discussions about their internal deployment,…