Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Group FaceTime calls didn’t exist at the time. That wasn’t added until 2018 and required iOS 12.

Remember that Slack does simultaneous multiple participants screen sharing plus annotations plus HD video feeds from all participants plus the entirety of the rest of the app continues to function as if you weren’t on a call at all simultaneously.

It’s an extremely powerful application when you really step back and think about it. It just looks like “text” and boring business software.





> Group FaceTime calls didn’t exist at the time. That wasn’t added until 2018 and required iOS 12.

And CU-SeeMe did that in the early 90s with even worse hardware: https://en.wikipedia.org/wiki/File:CU-Schools.GIF

Even more broadly, group calls were sufficiently widely implemented to get themselves standardised 29 years ago: https://en.wikipedia.org/wiki/H.323

> It’s an extremely powerful application when you really step back and think about it. It just looks like “text” and boring business software.

The *entire operating system of the phone* is more powerful, and ran on less.


Why don’t you just go ahead and tell me what specs you think Slack should run on and link me to an example program that has 100% feature parity that stays within those specs?

Showing me a black and white <10FPS group video call with no other accompanying software running simultaneously in the 90s is pointless.

Showing me that someone thought of a protocol is pointless. Just look at the history of HDTV. We wouldn’t really describe HDTV as being available to consumers despite it existing in the early 1990s.

I’d also like you to show me a laptop SKU sold in the last 10 years that is incapable of running Slack. If Slack is so inefficient you should be able to find me a computer that struggles with it.

Finally, I’ll remind you that Slack for mobile is a different application that isn’t running in the same way as the desktop app and uses fewer resources. The latest version of it will run on very old phone hardware, going all the way back to the iPhone 8 (2GB RAM), and that’s assuming you even need the latest version for it to function.


> Why don’t you just go ahead and tell me what specs you think Slack should run on

1 Ghz processor, 512 MB RAM (might even manage 256 MB), 1080p monitor. And "a graphics accelerator", "a sound card", and "a webcam and microphone".

Probably even less on the RAM and CPU.

> and link me to an example program that has 100% feature parity that stays within those specs?

Windows 2000. Or XP.

That's the point. The OS supports all the apps needed to do whatever.

Making Slack into a monolithic blob to do all is just an example of the inner platform effect.

But if you insist: IE 7 would have been able to do all this. It's an app. It's also an example of the inner platform effect.

> Showing me a black and white <10FPS group video call with no other accompanying software running simultaneously in the 90s is pointless.

You should've thought of that before trying to "well akshually" me about which versions of FaceTime support multi-user video calling.

You want video calling? We had that 30 years ago on systems with total RAM smaller than current CPU cache, with internal busses whose bandwidth was less than your mobile's 5G signal, on screens smaller than the icon that has to be submitted to the App Store, with cameras roughly comparable to what we now use for optical mice, running over networks that were MacGyvered onto physical circuits intended for a single analogue voice signal.

Out of everything you list that Slack can do, the only thing that should even be remotely taxing is the HD video calling. Nothing else, at all. And the only reasons for even that to be taxing is correctly offloading work to the GPU and that you want HD. The GPU should handle this kind of thing trivially so long as you know how to use it.

All the "business logic" you mention in the other thread… if you can't handle the non-video business logic needed to be a server hosting 2000 simultaneous users on something with specs similar to a Raspberry Pi, you're not trying hard enough. I've done that. Business logic is the easy part for anything you can describe as "chat". Even if you add some minigames in there and the server is keeping track of the games, it should be a rounding error on a modern system.


If these applications only hogged memory when under stress (outgoing screencap plus video, multiple streams incoming, display to 3+ monitors) you might have a point. But that's not the case so you don't.

Meanwhile I can play back multiple 1080 videos on different monitors, run a high speed curl download, saturate my gigabit LAN with a bulk transfer, and run a brrfs scrub in the background all most likely without breaking 2 GB of RAM usage. MPV, VLC, and ffmpeg are all remarkably lightweight.

The only daily application I run that consumes a noticable quantity of resources is my web browser.


If you didn’t babysit your task manager would you know which program used more RAM or not?

This argument is just so endless and tiring.

Saturating my bandwidth or running a btrfs scrub isn’t accomplishing the business logic I need to do my job, that’s what my web browser is doing.


So is it the "business logic" or is it the multiple HD streams that are supposed to account for the resource consumption? You've changed your story. But do please explain how the "business logic" to handle the chat box, UI, and whatever else is supposed to justify the status quo.

People making excuses for poorly designed software is what's tiring.


The problem with that kind of feature/benefit based thinking is that it won't correlate with code or computational footprints well. That's like justifying price of cars with seatback materials. That's not where the costs are.

Modern chat apps like Slack, Discord, Teams, etc. are extremely resource intense solely by being skinned Chrome showing overbloated HTMLs. That's it. Most of the "actual" engineering of it is outsourced and externalized to Google, NVIDIA/Intel/AMD, Microsoft/Apple, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: