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

Why Slack is inappropriate for open source communications

dave.cheney.net

Post reply on HN
Print view View original

411–420 of 536 posts

Re: Why Slack is inappropriate for open source communications

#411

Post by vacri »

AsyncAwait wrote: post #151
27182818284 wrote: post #58

Earlier quoted context omitted.

>It is one thing to deal with one of these things, but when you have to install ten to get The modern office large office is pretty bad in this respect. Really not uncommon to see things like • Need to have Slack open • Need to keep an eye on Basecamp/pm software • Need to have Outlook open / check in on for email and calendar invites • Need Skype open because not everyone uses Slack • GitLab is open in another tab I…

As a freelancer, I have EXACTLY this problem, so I started hacking away on my own solution. Don't want to shamelessly promote myself here, but if you're interested, link is in my profile.

As an aside out of curiosity, is the client/freelancer graphic representative? Are you really in the Kimberleys with a client in Western Sahara? Just struck me as odd as there are few places on earth that are less-densely populated (while still being populated) :)

I don't have a need for the product myself, but I do like the name for it.

Re: Why Slack is inappropriate for open source communications

#412

Post by zAy0LfpBZLC8mAC »

photojosh wrote: post #403
zAy0LfpBZLC8mAC wrote: post #392

Earlier quoted context omitted.

> Being able to use any programming language with modern HTTP-based protocols is a real luxury. No, it's not, it's a huge pile of crap, because HTTP is so complicated that you essentially have to distrust any implementation of it that you haven't audited, and even then, it's questionable (plus, most implementations turn out to be buggy if you look closely, and serious vulnerabilities aren't exactly uncommon), and it…

I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller. The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it wit…

> The critical difference? Speed of development. Websockets was so blindingly quick to get working.

Now, is that websockets or is that "not C"?

I mean, speed of development certainly is valuable, but I would think that same speed of development only needs little more than an 8 bit µC (or, for that matter, is even possible on an 8 bit µC if the memory size is at the upper end of the range).

> Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to.

But that's the thing: You could if you needed to. Instead of it just being the natural thing to do. Though I guess NAT also is part of the problem here, which is another of those idiocies of the "modern internet".

Re: Why Slack is inappropriate for open source communications

#413

Post by zAy0LfpBZLC8mAC »

vacri wrote: post #408
zAy0LfpBZLC8mAC wrote: post #387

Earlier quoted context omitted.

> Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this…

> What exactly would people facepalming and walking off feel like, that this doesn't feel like it? Funny how the silent majority is alway on 'my side'. No-one ever claims that the silent majority is against them.

Where did you pull that supposed majority from?

Re: Why Slack is inappropriate for open source communications

#414

Post by ricardobeat »

panic wrote: post #356
erikpukinskis wrote: post #260

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service. With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your…

What if we had an easy-to-use home server you could just plug in and start running "apps" on? Being able to download and run services on hardware you control would avoid some of these problems.

The base Synology NAS models fit the bill - everything from blogs to office software is available from the get go. I own one but don't use them and haven't met anyone who does - there is something about hosting this on a box in your living room that feels too fragile.

Re: Why Slack is inappropriate for open source communications

#415

Post by zAy0LfpBZLC8mAC »

orangeshark wrote: post #405
zAy0LfpBZLC8mAC wrote: post #335

Earlier quoted context omitted.

> Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them. WTF? How is it even remotely sane to provide a user interface instead of an API/protocol? I don't care to learn your forum's user interface, and I don't care to poll your forum for new content. I have a mail user agent that's configured to fit my needs and that I know well how to operate, and that's where…

Why not both? Something like DFeed[1] which is used as the D programming language's forum[2]. [1] https://github.com/CyberShadow/DFeed [2] https://forum.dlang.org/

Yeah, sure, provide as many user interfaces as you like, just not instead of an API/protocol. The whole point is that everyone can choose the UI they prefer, or build their own if they like.

Re: Why Slack is inappropriate for open source communications

#416

Post by mburns »

chrisseaton wrote: post #264
cat199 wrote: post #198

Earlier quoted context omitted.

Really - what is sooo unusable about IRC? Get a good GUI client, enter some parameters into a text bar, click 'ok', then chat. exactly the same process as a web browser.. The real problem is the 'endless summer' of tablet-era people who confuse the 'interweb' with the 'internet'. There used to be much more general community advocacy and understanding of promoting open communications 'baked in' to the internet culture…

Can you easily share multi-line code, formatted in a proportional font and syntax highlighted, in any IRC client? That's something I want to do almost every hour I'm working.

Some clients will intercept multi-line messages and let you POST the content to a pastebin. That way, supported clients show pretty-printed code and unsupported client just see a URL.

Ex: https://blog.irccloud.com/pastebins/

Re: Why Slack is inappropriate for open source communications

#417

Post by jurie »

ricardobeat wrote: post #414
panic wrote: post #356

Earlier quoted context omitted.

What if we had an easy-to-use home server you could just plug in and start running "apps" on? Being able to download and run services on hardware you control would avoid some of these problems.

The base Synology NAS models fit the bill - everything from blogs to office software is available from the get go. I own one but don't use them and haven't met anyone who does - there is something about hosting this on a box in your living room that feels too fragile.

QNAP NAS models have a similar setup. In addition to their own package format (qpg? I think...), they also are getting the ability to run Docker apps natively.

I agree RE the fragility. Even on my mid-range rack mount units, I'd rather stick to just having them serve up iSCSI or NFS to something more... server like that runs the actual instances.

Re: Why Slack is inappropriate for open source communications

#418

Post by 31h »

erikpukinskis wrote: post #260

We are, temporarily, in a kind of dark ages of end-user open source software. The reason is that we shifted from software-as-a-product to software-as-a-service. With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies, and then a million people could use it, or one person could, and you wouldn't have to lift a finger. A million people could fork your…

> With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies

You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget). Then it's up to the user to pay $5/mo to host it, a process which doesn't need to take more than a few mouse clicks.

Re: Why Slack is inappropriate for open source communications

#419

Post by killin_dan »

Arathorn wrote: post #301
killin_dan wrote: post #277

Earlier quoted context omitted.

Matrix is an extremely heavy protocol, not suitable for business use imo. Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.

Given Matrix & Riot are entirely FOSS, please do spell out its obnoxiousnesses (rant here, or file on http://github.com/vector-im/riot-web/issues ) so we and the wider community can go fix it. Agreed that Riot is too heavy; we're currently doing a performance blitz on it. In terms of Matrix itself being too heavy... we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works…

At no point did I imply it's garbage because it's FOSS.

I'm always down for more FOSS, and don't ever paint me otherwise.

It's bad because the protocol is heavy and complex. Plenty of technical complications detailed in other comments.

Re: Why Slack is inappropriate for open source communications

#420

Post by bborud »

Slack is technically inept as well. Earlier today I was modifying a robot design in Fusion 360. Huge beast of a model with too many parts to bother counting. Fusion was consuming nearly 900MB of memory (and I am rounding up here). Which is unsurprising for a CAD package editing a large model.

Meanwhile my mostly idle Slack with perhaps a couple hundred users across four teams was consuming 1.3GB of memory.

Not to put too fine a point on it: it is a piece of shit software.

Post reply on HN