Hacker News Reader

Comment by mikepavone | Hacker News Reader

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 usually pretty hosed if you've installed a malicious native app anyway...), but this kind of requirement tends to break existing abstractions.

Now on some level, that's not a big deal. Having to use a different UI flow on Wayland than everywhere else is annoying, but that's just life in software development. BUT, Linux has a relatively tiny share of the desktop market which makes it hard to justify devoting engineering resources to it. When you've only got 1% of the market, you're only going to get good adoption of a new API if you make it easy.

View on HN

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.

> I'm not entirely convinced this is a big deal since you're usually pretty hosed if you've installed a malicious native app anyway.

This specific restriction is part of a more general push for sandboxing, to limit the damage one app can do. It's probably not massively useful against actually malicious apps, because they'll probably just declare they need arbitrary filesystem access anyway. But it should be beneficial when honest apps have security flaws.

The "low marketshare" argument doesn't work as well for a communication service like Zoom, because it's important for everyone on the Zoom call to have access. If 1% of users have Linux, that means that on a Zoom call connecting 10 randomly chosen users, around 10% have at least 1 Linux user in the call.

Most users on a Zoom call aren't screensharing so I don't think this math remotely works out here.

That said, even when users of a minority platform impact the experience of a broader community you're still going to make development resource tradeoffs based on userbase. Honestly, I think Linux punches way above its weight here because software developers are much more likely to be Linux users than normal people. That said, when development for your platform is happening in developer's free time or in between official priorities*, making things easy is perhaps even more important.

*I don't know if this specifically happening at Zoom, but this kind of thing is not uncommon when it comes to Linux support in commercial apps.

EDIT: Fixed formatting

No, you have one Linux user who is now scrambling to get it to work or is using a device that will make it work. Your example sort of under cuts your argument, just imagine sending that email "I will not be attending our remote meetings due to what some may call a philosophical argument with Zoom, rest assured, I am in the right, and as soon as they see the light and correct their ways, I will start attending meetings again".

Instead, in frustration, they will reach for another device. They will use an old laptop, or a smartphone, something.

Or they will switch to Windows.

I used to be in a company that was developing _desktop software exclusively for Linux_ (not multiplatform at all -- Gtk+ based!), and they all (even the developers) used Windows workstations. They would use Windows conferencing software, Windows PIM, Windows mail clients, Windows WWW browsers, Windows IDEs. But all of them would religiously VNC into a Linux server somewhere just to test the tool they were writing. Which they would screencast to fellow developers using Windows software. Nowadays, they likely use Teams (still for Windows).

No one developer found this bizarre. They all claimed it was the same in competitors or previous jobs.

When I asked IT "can I get a laptop with Linux, not Windows?" the response was "but how will you run Outlook?".

> 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

Do you mean that you cannot share the whole desktop? The typical coding / debugging session (browser, editor, terminal) would be very difficult to do.

I mean that at an API level, you can't manually select what you want to capture whether that be a particular screen or a single window. You have to send a dbus message to the DE which will then pop up its own UI to select the thing you're going to share.

So lets say you have some cross-platform UI code for screensharing with an OS abstraction layer that has functions to get a list of potential sources (perhaps with previews) and another that starts screensharing with a particular source. That particular design works fine on Mac and Windows (except in the UWP ecosystem, but no one cares about that) and also with X11, but not with Wayland. So now it's not just about having another implementation of your OS abstraction layer for a new capture API, it's also about mucking around with the UI flow. In the grand scheme of things, this is not a huge deal, but it makes supporting the API kind of a PITA.

Reply on news.ycombinator.com