Earlier quoted context omitted.
> I guess the core problem is the false advertising. Zoom "supports" Wayland-only distros... with the fine print that they only support outdated builds from before the switch to Wayland. They support the distro just fine. They might not support one of its graphical layers, but you can run Zoom on Xorg on the same distro just fine.
You can run it, but not with reasonable screen sharing support, which arguably is a part of "supporting the distro".
How Not to Support Desktop GNU+Linux, Zoom Edition
91–100 of 223 posts
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#92Earlier quoted context omitted.
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…
And yet they are not! Even multiplatform programs like OBS have better support in Linux than browsers.
> 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.
First we make dynamic linking difficult, then we complain that static linking makes everything old and vulnerable, so as to that the only viable solution is for all desktop development to move to the browser. It doesn't sound very good.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#93Earlier quoted context omitted.
You can run it, but not with reasonable screen sharing support, which arguably is a part of "supporting the distro".
My point was that distos don't map 1-1 to Xorg or Wayland; you can run the very latest Fedora with Xorg, or Ubuntu 18.04 with Wayland. They support the distro just fine, the problem is a specific graphical server.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#94I'm using a relatively simple setup (Ubuntu 21.10 on wayland, single hiDPI tablet display - no secondary gpu, no second monitor) and was frustrated to see Zoom screensharing only show the upper right quarter of the screen (presumably due to not accounting for hidpi) recently.
This said, it generally works fine, and am thankful Zoom at least exists on Linux.
--
"If you're stuck using Zoom [...] we can work to pry our organizations and loved ones away from the hapless engineering at Zoom."
I disagree with this sentiment. Zoom has been a huge enabler with it's setup to minimize video/audio latency compared to the other solutions I've seen when faciliating a global audience that doesn't necessarily have fast internet access.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#95Earlier quoted context omitted.
>> 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.
I was aware that AMD had officially supported open source linux drivers, and that Nvidia did not support Wayland. Unfortunately, I needed a machine which would work well with the existing machine learning ecosystem, and that means getting an nvidia card over AMD. It's pretty terrible that the machine learning ecosystem is centered around nvidia hardware.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#96Earlier quoted context omitted.
My point was that distos don't map 1-1 to Xorg or Wayland; you can run the very latest Fedora with Xorg, or Ubuntu 18.04 with Wayland. They support the distro just fine, the problem is a specific graphical server.
The grandparent referenced Wayland-only distros, so I assumed your comment was about Xwayland. But your point is that there aren't any Wayland-only distros?
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#97Uh, yeah, no. If you press even the most hardcore of Wayland advocates, they'll eventually admit that Wayland is not a true replacement for Xorg. They'll make the case that you shouldn't use Xorg, but at the end of the day, Wayland's development will always be a treadmill since it's goal is to be less feature-complete than the protocol it's replacing. Yes, I hate x11. Yes, I want a better window server. Wayland is absolutely, positively not it though, and I reckon I'll be sticking with Xorg for the foreseeable future (at least 5 years).
This is yet another "why won't companies take Wayland seriously!?" blogpost. You want your answer? It's because Wayland has been in development for more than a decade, with top-priority attention from the most well-funded organizations in open source. And it's still not finished.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#98I think a better title would be: How Desktop GNU+Linux sucks for desktop developers: Zoom edition Windows will happily run GUI apps written 20 years ago. GDI is still supported. MFC Apps still run. Likely VB6 apps still run. Desktop GNU+Linux switches graphics engines, breaks backwards compatibility, ships something with performance and driver issues, and complains that user software doesn't work. Frankly this post t…
> Windows will happily run GUI apps written 20 years ago.
Your best bet at running 16 bit Windows applications on a modern OS is running them via Wine. The same is true for some older 32 bit software.
I wanted to relive some memories replaying my copy of GTA (the first one) on Windows 10 the other day, gave up after about half an hour after multiple step-by-step guides for getting it to run failed, and just installed it on my work laptop that's running a flavor of Linux with Wine. The latter required one extra step - installing some library by ticking a checkbox in winetricks.
For all of Windows' touted backwards compatibility I wasn't exactly impressed. It seems to be little more than a meme at this point. What Windows does better (than other OS) is play modern games, which is why I keep it around on my desktop computer. I'm not sure it deserves credit for that though.
I don't even know what you mean by switching "switches graphics engines". The X to Wayland migration? The former has been backwards compatible for more than three decades and the latter can host the former to remain backwards compatible.
Wishy-washy terminology aside, are you absolutely confident your opinion is formed from an informed position?
There's valid criticisms to be made of desktop Linux, but I don't think those are it.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#99I 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…
You have heard these stories because there were different APIs floating around, some specific to particular compositor families. The author is offering the generic API that should work with all of them.
Re: How Not to Support Desktop GNU+Linux, Zoom Edition
#100Earlier quoted context omitted.
I'm guessing write.as is supposed to support multiple languages, and only renders the markdown if you have .md as an extension.
Which is the exact opposite of what I expect and want -- the bare filename should render, and the .md extension should get the markdown source.