Live data from Hacker News

How Not to Support Desktop GNU+Linux, Zoom Edition

write.as

111–120 of 223 posts

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

#111
How Not to Support HTML Text, write.as Edition:

> If you're stuck using Zoom, jump on [one](https://community.zoom.com/t5/Meetings/Sharing-application-w...) [of](https://community.zoom.com/t5/Meetings/Linux-screen-sharing-...) [the](https://community.zoom.com/t5/Meetings/Unable-to-share-scree...) [..]

Why do you need JS to translate your unreadable HTML into readable HTML?

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

#112

I 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…

A Quake 3 binary compiled in 1999 still runs on Linux today. How much backward compatibility do you need? > 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 af…

> Your best bet at running 16 bit Windows applications on a modern OS is running them via Wine.

Fun fact, you can use a WineVDM-based 16bit emulator on Windows[0] that translates 16bit calls to 32/64bit calls and install it system-wide thus allowing the use of 16bit programs in 64bit Windows. Here are two examples from screenshots i have around: Microlathe[1], a small utility to build 3D models by rotating a line around an axis (i also made my own clone[3] of it) and [2]a free Smalltalk environment (Smalltalk Express - which i actually consider one of the simplest Smalltalk environments since it only contains a small subset of what you'd find in a modern one thus making it easier to grok).

[0] https://github.com/otya128/winevdm

[1] https://i.imgur.com/e26mqWP.png

[2] https://i.imgur.com/r5aQNyJ.png

[3] http://runtimeterror.com/tools/lila/

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

#113

A game developer [1] once said that Linux "accounted for 20% of auto reported crashes and support tickets." Unfortunately, this is the reality of Linux. It's very hard to support due to its fragmentation. It requires so much effort to work in a fast-changing environment that a few users even use. To make Linux easier to support, we need to make it as easy to develop as Windows, macOS, iOS, and Android. We need a unif…

And another game developer [1]

> The report quality [from Linux users] is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed. And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

Notably, of those bug reports, fewer than 1% (only 3 bugs) were specific to the Linux version of the game. That is, over 99% of the bugs reported by Linux gamers also affected players in other platforms. Moreover (quoting from the OP):

[1] https://old.reddit.com/r/gamedev/comments/qeqn3b/despite_hav... also see https://news.ycombinator.com/item?id=28978086

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

#114

I 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. Don't think this is true anymore. Old software on Windows just isn't guaranteed to work anymore. Last time I tried to play an old game on newer Windows versions, it didn't even start up despite automatic and manual installation of a ton of dependencies. I suppose the Raymond Chen stories about heroic bug fixing in third party code is a thing of the past.

You need workarounds but you can make it work. Though you can say the same thing for Linux too, it is just that Windows coming out of the box with a much richer API (e.g. for GUI functionality) makes things easier.

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

#115
post #113

A game developer [1] once said that Linux "accounted for 20% of auto reported crashes and support tickets." Unfortunately, this is the reality of Linux. It's very hard to support due to its fragmentation. It requires so much effort to work in a fast-changing environment that a few users even use. To make Linux easier to support, we need to make it as easy to develop as Windows, macOS, iOS, and Android. We need a unif…

And another game developer [1] > The report quality [from Linux users] is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed. And with bug reports from Linux players is just so…

and on zoom itself https://googleprojectzero.blogspot.com/2022/01/zooming-in-on... also see https://news.ycombinator.com/item?id=29982954 "Zooming in on Zero-click Exploits "

the researcher used the Linux client to do the RE work... so I guess it's not just for 'bug' but also for free security audit! (2 CVE were reported)

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

#116
post #111

How Not to Support HTML Text, write.as Edition: > If you're stuck using Zoom, jump on [one]( https://community.zoom.com/t5/Meetings/Sharing-application-w... ) [of]( https://community.zoom.com/t5/Meetings/Linux-screen-sharing-... ) [the]( https://community.zoom.com/t5/Meetings/Unable-to-share-scree... ) [..] Why do you need JS to translate your unreadable HTML into readable HTML?

> _Pssst, coming from Hacker News? Add a ".md" to the URL_

This might have been added after your comment.

Link with md: https://write.as/n5r0vjolumdnuk2k.md

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

#117
post #60

Earlier quoted context omitted.

1. no its not, no security fixes or new features are being developed, its entirely on life support: the changes are to just keep it limping along while distros finish transitions to wayland. https://lists.freedesktop.org/archives/xorg/2022-January/060... 2. the article is about them abusing a gnome only API when alternatives existed that would have worked better. WLR had its first commits for its desktop portal api i…

1. Even if what you were saying was true (which it is not, even your own link is just showing that bugs and regressions are still being fixed), the distros who are shipping have commited to decades of security updates. 2. "The right fucking" Gnome-exclusive API is, obviously, Gnome-exclusive, and just didn't work for me for the reasons I mentioned in my original message, and probably didn't for them either (my guess…

the last release was afaik I know just to get the majority of patches contributed out that had stagnated and to finally split xwayland out of the xserver release.

https://www.phoronix.com/scan.php?page=news_item&px=XWayland... https://www.phoronix.com/scan.php?page=news_item&px=XWayland...

its dead, the maintainers have said its dead, all major distros have either moved or will be moving in the coming year. x11 as an api will limp along due to xwayland but that's about it.

no amount of assertions will change that unless individuals/organizations step up to actual maintain it.

as for rest of your statement ./shrug I've already been very clear on the fact they were already using a gnome only api incorrectly. the generic desktop portal api not being strictly ready in 2020 due to pipewire doesn't change the fact they had a perfectly reasonable api to use inside gnome and they decided not to and were burned.

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

#118

I think this is somewhat of a self-inflicted wound by the developers of the Linux desktop here. Linux+Wayland is the only major desktop environment that requires you to use an OS-provided dialog to pick the window you want to share when screensharing from a desktop app. Now obviously there are some security benefits to this approach (though in practice I'm not entirely convinced this is a big deal since you're usuall…

This solution to require the user to pick and allow screencastig is right and justified. Chromium is doing it already nicely. Bonus, you get the actual allowance and confirmation that it must work as developer.

We see similar approaches on mobile systems. Sadly they stuffed everything into a limited number of buckets {pictures, contacts, gps} and every app requests all of them.

UNIX brought us file-permissions and multi-user and right now Linux ships cgroups and process-permissions. So Chromium wants more than allowed `max.memory`? The kernel has bad news for the memory eating resource hog.

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

#119

Earlier quoted context omitted.

> The good news is that Nvidia has finally decided to fix its drivers, it's still beta though. Can you elaborate on that?

I assume GP was thinking of Nvidia having started to work on the GBM API, available starting with nvidia 495.44: https://www.nvidia.com/Download/driverResults.aspx/181274/en...

I think there's a little irony there, considering that the same update that introduced GBM also created a pretty terrible issue where Nvidia would flood your DBUS channels with garbage until you system runs out of memory and crashes.

In other words, "fix" is a relative term.

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

#120

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.

The recommended session manager for pipewire is called WirePlumber. Not something I would think of it I were to look for it on my own. It didn't even exist a couple months back, and about 6months ago pipewire hardly worked on my laptop.

It's great that OBS works fine for you, but it's really odd that Wayland has been around for over a decade and some things people would consider basic functionality has only recently started working.

I for one hope there is something new coming where the core developers aren't so far detached from reality.

Post reply on HN