Tell HN: Slack decides to close down IRC and XMPP gateways • Hacker News Board

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#141

Post by StudentStuff » Wed, Mar 07, 2018, 10:52 PM UTC

jodrellblank wrote: post #84

dijit wrote: post #54

Earlier quoted context omitted.

That's absolutely gargantuan. How can any general purpose application justify 4G of memory, half of a factory macbook pro's memory. To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users. How much memory was it? 3G. Per "instance" of which…

It takes a lot of memory to slowly and jerkily send plain text over the internet, and not quite keep up with typing when autocomplete-ing usernames, you know. Stop expecting so much of your computers /s

Things like IRC don't support embedded images, so lets build our own protocol with blackjack and everything else! Oh wait, its a slow morass :(

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#142

Post by avtar » Wed, Mar 07, 2018, 10:53 PM UTC

cornholio wrote: post #68

jbob2000 wrote: post #20

Earlier quoted context omitted.

Most accessible users use JAWS on windows. I focus on accessibility a lot for my job. In fact, we have an entire department dedicated to accessibility design, implementation, and testing. The reason why accessible users use JAWS is that it works across the entire OS and all the programs you have installed; start menu, PowerPoint, web browser, control panel, Google, etc. etc. The problem with the native accessibility…

I find it unbelievable that a software costing $1000 is the de facto standard. What is their moat, what exactly does it offer that it's impossible to replicate using existing libraries and APIs?

I work at an accessibility research centre in Toronto. When people consult Occupational Therapists for their a11y needs the government here will subsidize a percentage of the software (and hardware?) costs. As far as I know JAWS gets recommended, NVDA doesn't :/

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#143

Post by stuaxo » Wed, Mar 07, 2018, 10:54 PM UTC

Something that is quite "fun" is to accidentally leave a few slack tabs open in the browser, while running pycharm.

(If you like watching the computer slow to a crawl and have to power it down).

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#144

Post by gray_-_wolf » Wed, Mar 07, 2018, 10:55 PM UTC

nopacience wrote: post #32

Slack was fine, now it is time to move back to IRC. Some people like slack or telegram because they provide an API for BOTs. Something IRC has been open to since the begining. Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx). Today a family member, not technical and 60+yrs asked about "that tool" that is like whatsapp however it allows users that just joined a group to read old…

is it true what I've heard about irc and how it completely ignores stuff like encoding?

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#145

Post by LeoPanthera » Wed, Mar 07, 2018, 10:55 PM UTC

cyphar wrote: post #70

FooBarWidget wrote: post #46

Everybody here is disappointed at Slack, and I like open protocols and open platforms just like everybody else, but I still have a contrarian view. Instead of blaming Slack, why not accept that the open protocols indeed suck? IRC does not specify encoding, netsplits are a common issue, file sending sucks, etc. XMPP also has file sending problems, does not play nice with mobile, is fragmented (not every client impleme…

There are open protocols like Matrix which are superior to Slack in that they are decentralised, have support for full e2e encryption, entirely self-hostable, don't store your data outside of the home-servers used for communication, etc. Riot is a perfectly fine client (looks just like every other chat application), and there are weechat plugins as well as native applications as well. Open protocols exist, and people…

I really wanted to like Matrix but it expects you to independently verify the keys for each device every person is using. If they get a new device, new keys to verify.

This is crazy. The keys should be per person, not per device.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#146

Post by ocdtrekkie » Wed, Mar 07, 2018, 10:56 PM UTC

Froyoh wrote: post #63

Time to use Discord

Discord has all the same problems Slack does. It's a proprietary VC-funded app without a sustainable business model.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#147

Post by aluhut » Wed, Mar 07, 2018, 10:56 PM UTC

jodrellblank wrote: post #84

dijit wrote: post #54

Earlier quoted context omitted.

That's absolutely gargantuan. How can any general purpose application justify 4G of memory, half of a factory macbook pro's memory. To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users. How much memory was it? 3G. Per "instance" of which…

It takes a lot of memory to slowly and jerkily send plain text over the internet, and not quite keep up with typing when autocomplete-ing usernames, you know. Stop expecting so much of your computers /s

mIRC takes 24MB!

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#148

Post by dangom » Wed, Mar 07, 2018, 10:57 PM UTC

zeveb wrote: post #128

castis wrote: post #21

Earlier quoted context omitted.

They're not basically electron apps. they _are_ electron apps. And it's completely absurd that mine is currently using 1514MB of memory. If I weren't required to use Slack on a day-to-day basis, I absolutely wouldn't solely on principle.

I just use emacs-slack[0]; my entire emacs usage is currently a fraction of yours. On X, this means emacs-slack displays images, emoji &c. just like the web or pseudo-native clients do. [0] https://github.com/yuya373/emacs-slack

I guess this is about to break because of the current announcement?

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#149

Post by godot » Wed, Mar 07, 2018, 10:57 PM UTC

dijit wrote: post #54

jsmthrowaway wrote: post #34

Earlier quoted context omitted.

I remember when Slack in a Chrome tab committed 3-4 GB. Sounds like they've made improvements. Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.

That's absolutely gargantuan. How can any general purpose application justify 4G of memory, half of a factory macbook pro's memory. To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users. How much memory was it? 3G. Per "instance" of which…

I know most of this thread has been about making fun of Slack, but I wanted to write a somewhat serious response to this.

I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.

Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.

Re: Tell HN: Slack decides to close down IRC and XMPP gateways

#150

Post by AlexandrB » Wed, Mar 07, 2018, 10:57 PM UTC

Dunedan wrote: post #41

Well, another day of being disappointed by Slack. Aside from missing native clients mentioned in other comments my biggest pain point is their awful implementation of threads. Every time I think: They must be kidding, they can't be serious, that's just a bad dream. A few examples: - The only place where you get noticed about responses to threads is the "New Threads" view, which makes it easy to miss responses, when y…

Slack threads are like a bad version of email built into an OK IRC client.