Live data from Hacker News

How Not to Support Desktop GNU+Linux, Zoom Edition

write.as

41–50 of 223 posts

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#41
post #26
post #8

People still call it GNU+Linux? Modern distros have less GNU pieces on each iteration. Might as well start calling it Gnome+Linux from now on.

“that is not the deepest way to consider the question.” — https://www.gnu.org/gnu/linux-and-gnu.html

That entire page can basically be summarized as "The GNU components in Linux distributions are becoming less significant each year, but please call it the 'GNU system' anyway because we like that name better."

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#42
post #4

I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers. It either fails to boot (KDE) or runs at about 15 FPS (Gnome). It seems a little unreasonable to be this mad at a company for not supporting an environment that doesn't work for the vast majority of hardware out there. Especially given that you can just use Zoom within Firefox.

>> I still cannot run a Wayland session on my machine w/ an nvidia 3080 with the latest drivers. You might try buying hardware that has proper Linux support. That would include graphics from AMD or Intel, and might even include Apple before nvidia gets it together.

They are probably running a distro with an old kernel and can't be "bothered" to figure out and fix the actual issue.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#43
post #28

Earlier quoted context omitted.

We're not talking about supporting things years ago though, we're talking about supporting it now which is a few years after, when it's been stable and supported across the whole ecosystem for a quite a while. That's their job, providing multi-platform video-conferencing and screen sharing. If they can't do that they could chose to drop their app and try to build a decent web version instead because this thing is qui…

Less than a year ago is NOT "quite a while". A couple years ago is also not quite a while. The fast distributions have a 2 year release cycle for their LTS releases; even longer on the slower distributions. When you have an API that has been stable and working on these distributions for _at least_ 2 of these releases, maybe I will consider using it. I'm not going to rewrite my core business every other year just to u…

You mean 3 years ago? It is a while. Definitely enough, lot of software implemented it in the meantime. Zoom is actually the only one I know that didn't

LTS distribution before that are on X11, so this discussion doesn't even apply, supporting both is definitely possible since they already support X11.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#44
post #26
post #8

People still call it GNU+Linux? Modern distros have less GNU pieces on each iteration. Might as well start calling it Gnome+Linux from now on.

“that is not the deepest way to consider the question.” — https://www.gnu.org/gnu/linux-and-gnu.html

I... don't like the argument made here.

> But the reason it is an integrated system—and not just a collection of useful programs—is because the GNU Project set out to make it one. We made a list of the programs needed to make a complete free system, and we systematically found, wrote, or found people to write everything on the list.

First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this?

Second, the work done to make an integrated OS on desktop is not done by GNU anymore[0], it is done by the GNOME/KDE dev's.

[0] Also, what does "integrated" even mean in the context of a UNIX-like OS. Doesn't that sorta defeat the point?

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#45
post #43

Earlier quoted context omitted.

Less than a year ago is NOT "quite a while". A couple years ago is also not quite a while. The fast distributions have a 2 year release cycle for their LTS releases; even longer on the slower distributions. When you have an API that has been stable and working on these distributions for _at least_ 2 of these releases, maybe I will consider using it. I'm not going to rewrite my core business every other year just to u…

You mean 3 years ago? It is a while. Definitely enough, lot of software implemented it in the meantime. Zoom is actually the only one I know that didn't LTS distribution before that are on X11, so this discussion doesn't even apply, supporting both is definitely possible since they already support X11.

No, I mean last year. The current API for screencast (the only one which might work on anything other than Gnome) uses Pipewire and even OBS didn't support it until last year.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#46

Not surprised at all. Instead of making use of the WebRTC API in the browser, they just threw us back to Skype days of needing a native client installed on your OS....

Really? They're the only commercial company that bothers to create a native client (and not a Electron app) and you complain that you would prefer to have no client at all? I don't think that's the majority opinion... I'm no fan of them (I think free apps are up to the task), but give me a native client _any day_ over something that runs in a browser. I don't want any more multi-GB RAM hoarding processes running 24h…

Native clients may be preferred for things that are mostly offline anyway like a text editor. But for something like Zoom, it just makes sense to have a good web app and ship an Electron build for the people who really need a standalone app.

The probability of browsers and by extension Electron eventually having best in class screen sharing is basically 100% since that's what almost everyone uses so there's a vested interest by some of the largest companies in the world to make it work.

This is not true for the desktop application frameworks. While Zoom did have pretty good screen sharing (on Linux) via the desktop client, it had a awful bug where it would just freeze the entire system making it unusable.

Since 99% of people are already going to have a browser open, the incremental memory usage of a webapp is actually pretty minimal. Electron apps are a bit heavier (mostly due to the fact they all ship with their own Electron version) but it's a small trade-off given the benefits such as having the chromium sandbox and cross-platform compatibility.

Even smaller things like having a more robust and secure video decoding stack is a major advantage since it sucks when 10 applications all link against an old, vulnerable version of ffmpeg.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#47
post #35
post #11

Earlier quoted context omitted.

The end of the URL got trimmed upon submition, so its pointing to the unrendered markdown URL for some reason. Here's the rendered page: https://write.as/n5r0vjolumdnuk2k.md#title

Why won't trimmed URL simply redirect to a proper one? Or throw 404 even? This seems like a webserver misconfiguration of sorts, kind of like being able to access raw PHP pages, instead of rendered ones.

I'm guessing write.as is supposed to support multiple languages, and only renders the markdown if you have .md as an extension.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#48

I believe this is not entirely Zoom's fault, I've heard a few horror stories with Wayland and screensharing over the last few years. Particularly when I once tried using OBS Studio and it just didn't work on Wayland. I also remember screenshare from things like Google Meet or Discord only being able to share other chromium tabs and not able to share the desktop or any specific applications. This whole story sounds to…

OBS works fine for me on Wayland through pipewire.

Re: How Not to Support Desktop GNU+Linux, Zoom Edition

#49

Earlier quoted context omitted.

Zoom is not as big a company as people think... They're just hustling very hard relative to the sudden explosion of use of their tools. I'd be willing to wager money that their development process involved attempting to use the correct API, finding that it either failed on a key executive's machine or the developers' own machines (possibly because of one bad driver/hardware/os configuration) but because it didn't wor…

> In January 2020, Zoom had over 2,500 employees, with 1,396 in the United States and 1,136 in international locations. It is reported that 700 employees within a subsidiary work in China and develop Zoom software. https://en.wikipedia.org/wiki/Zoom_Video_Communications#Work...

And Zoom is using that headcount to support 55 billion hours of videoconferencing a year. In contrast, YouTube is supporting only six times that much video watched annually with 40 times Zoom's staff.

"Small" is relative, but Zoom is punching above its weight for the size of its userbase and the load on its services.

Post reply on HN