Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Not to Support Desktop GNU+Linux, Zoom Edition

write.as

Post reply on HN
Print view View original

101–110 of 223 posts

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

#101

Post by mikepavone »

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.

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

#102

Post by Shared404 »

yjftsjthsd-h wrote: post #78
Shared404 wrote: post #44

Earlier quoted context omitted.

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

> First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Yes . GNU/Linux, Busybox/Linux, and Android/Linux are all different things, and all perfectly good descriptions.

Fair point. I feel like you could make a case for $DE/Linux on desktop, $COREUTILS/Linux on server and Android/Linux on mobile then whenever greater precision is needed.

That said, how often do you need to distinguish between the Coreutils in use? If you say Linux server, unless you specify something out of the ordinary, everyone will assume you have GNU or Busybox coreutils - which doesn't matter that much, you can do pretty much anything with either afaik - and whatever server software is in use. Or on desktop, you can just mention the distro in question and everyone will know or be able to find out all of the above. Why specify every single time?

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

#103

Post by aidenn0 »

There are many good points, but the article says "Wayland has been in development for all this time, and the inevitability of a complete switchover is known" for a time period starting in 2008?

Mir was a potential competitor as late as 2017. Today I have yet to successfully run plasma5 under Wayland with success on my home workstation, despite trying annually since 2018.

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

#104

Post by yjftsjthsd-h »

Shared404 wrote: post #102
yjftsjthsd-h wrote: post #78

Earlier quoted context omitted.

> First of all, I mostly use Alpine for Linux servers, so I guess that should be referred to as Busybox/Linux according to this? Yes . GNU/Linux, Busybox/Linux, and Android/Linux are all different things, and all perfectly good descriptions.

Fair point. I feel like you could make a case for $DE/Linux on desktop, $COREUTILS/Linux on server and Android/Linux on mobile then whenever greater precision is needed. That said, how often do you need to distinguish between the Coreutils in use? If you say Linux server, unless you specify something out of the ordinary, everyone will assume you have GNU or Busybox coreutils - which doesn't matter that much, you can…

Honestly you probably should prefer to specify by distro, and use the userspace+kernel convention only when you specifically care or it matters for some reason. If I say Fedora, I probably don't need to say "Fedora GNU/Linux", since GNU and Linux (as well as RPM and systemd) are implicit in "Fedora". On the other hand, "Debian" usually means "Debian GNU/Linux" but Debian has a living HURD version (Debian GNU/HURD) and a basically-dead FreeBSD version (Debian GNU/kFreeBSD), and experimental work has been done to allow replacing its coreutils with... I think the Rust rewrite? So there it can be useful to specify.

And, of course, the other reason is because we are Hackers and hackers love their pedantry;)

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

#105

Post by Beltalowda »

DarthNebo wrote: post #7

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....

You can use the browser version too, no? I used it a few times for job interviews in the last few months, and seems to work well enough in Firefox.

The link for the web version is easy to miss below a big "download zoom" button though.

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

#106

Post by badsectoracula »

jatone wrote: post #60
AshamedCaptain wrote: post #58

Earlier quoted context omitted.

1. X11 is definitely maintained, unless you are thinking of XFree86. Xorg's last release 2 weeks ago. Many LTS distros containing it are preparing releases with it _right now_ and they will also be supporting it for at least one decade, probably way more. I would bet that Wayland will become unsupported way before (at least some implementation of) X11 does. 2. This entire article is about avoiding the Gnome private A…

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…

> no its not

Yes it is, the mail you linked at was about a new standalone X server (ie. not XWayland) release by its new maintainer.

> no security fixes

The very previous version released just last month[0] has security fixes.

> or new features are being developed

Two versions before that[1] added a bunch of new features.

[0] https://lists.x.org/archives/xorg/2021-December/060842.html [1] https://lists.x.org/archives/xorg/2021-October/060799.html

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

#107

Post by faisal_ksa »

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 unified Linux platform with a friendlier developer experience. Something similar to Android (which has Linux kernel inside it).

[1]: https://twitter.com/bgolus/status/1080213166116597760 Also, see: https://news.ycombinator.com/item?id=18845205

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

#108

Post by ModernMech »

matheusmoreira wrote: post #59
RcouF1uZ4gsC wrote: post #33

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.

I can't find it now, but I remember there was a video of someone upgrading windows from like Windows 3 all the way to the latest Windows... maybe it was 7? I forget how long ago this was. But each time they upgraded Windows, they showed that the programs installed in the original OS still worked. I think they did it with Doom installed in 3, and showed that it still worked after 20 years of upgrades. That's some impressive backwards compatibility.

Does anyone know the video I'm thinking of? I'd love to watch it again.

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

#109

Post by Shared404 »

yjftsjthsd-h wrote: post #104
Shared404 wrote: post #102

Earlier quoted context omitted.

Fair point. I feel like you could make a case for $DE/Linux on desktop, $COREUTILS/Linux on server and Android/Linux on mobile then whenever greater precision is needed. That said, how often do you need to distinguish between the Coreutils in use? If you say Linux server, unless you specify something out of the ordinary, everyone will assume you have GNU or Busybox coreutils - which doesn't matter that much, you can…

Honestly you probably should prefer to specify by distro, and use the userspace+kernel convention only when you specifically care or it matters for some reason. If I say Fedora, I probably don't need to say "Fedora GNU/Linux", since GNU and Linux (as well as RPM and systemd) are implicit in "Fedora". On the other hand, "Debian" usually means "Debian GNU/Linux" but Debian has a living HURD version (Debian GNU/HURD) an…

All valid points!

> And, of course, the other reason is because we are Hackers and hackers love their pedantry;)

Some things never change :P

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

#110

Post by ho_schi »

As an aside, the Flathub package is another incredible example of how much volunteer labor Zoom benefits from, but neither takes advantage of internally or passes along back to their users. I guess they would rather continue having to maintain iffy support for 7 distributions than make a Flatpak release official which would cover them all…and make updates automatic.

It is incredible that their all still companies which try to support specific Linux distributions. YOU SHALL NOT! And it was never an acceptable or useful practice. Release the source or at least the binaries and allow redistribution. But how? Put the necessary information into the usual README.txt (e.g. dependencies) and LICENSE.txt (e.g. copyright ACME, redistribution allowed). Thank you :)

In addition you can - but don't must - maintain a Flatpak for all distributions.

PS: Even Valve did that mistake and fixed it quickly - many years ago. Look at your ~/.steam you will find there a file which allows redistribution.

Post reply on HN