4 ms·

Vanishingly small...the Linux community are usually fan-faring increases in usage on a fractional part of a percentage increase, ~ 2%. And to me, how could the

by jabits 7y ago

Vanishingly small...the Linux community are usually fan-faring increases in usage on a fractional part of a percentage increase, ~ 2%. And to me, how could they anyway, I can't find "a Linux desktop". There are many, which one would they port to? And as a shareholder, I would not want them to waste the money at this point...

dependenttypes 7y ago
> ~ 2%. 2% of the human population are 154 million people. Sure, not everyone has a computer, so let's say 66 million people, this is the population of France. > There are many, which one would they port to? You don't actually need to support a specific desktop environment. Any UI program that you write will work just fine on KDE, GNOME, DWM, etc
- curt15 7y ago
  >Any UI program that you write will work just fine on KDE, GNOME, DWM, etc But which versions of which libraries do you target? Every distribution has its own menagerie. There is no well-defined "Linux platform" like there is with Windows (https://docs.microsoft.com/en-us/windows/win32/api/ https://docs.microsoft.com/en-us/windows/win32/api/).
  - gmueckl 7y ago
    Core libraries like glibc and Xlib are pretty well defined. You need to ship your own copy of the widget library of choice, but that isn't a big deal. You could even ship an Xlib copy and rely on the fact that there is an X server speaking the same protocol. It's all perhaps a bit messy, but it works.
  - dependenttypes 7y ago
    Just static link? Or do what windows software does, so ship dynamic libraries with your application. I do not see the issue. > There is no well-defined "Linux platform" There actually is! https://en.wikipedia.org/wiki/Linux_Standard_Base https://en.wikipedia.org/wiki/Linux_Standard_Base
  - disintegore 7y ago
    If your software is FLOSS, that's an integration problem for distro maintainers to solve and it hinges on said libraries being versioned properly. The bigger distros usually have 10,000+ packages and those are downloaded, installed and updated automatically which cannot be said of almost all Windows and OS X software. Really, only Android and iOS offer a similar experience. If your software is proprietary (or not popular enough to be found in most repos), there's always container technologies like Snap/AppImage/FlatPak/etc. As a Windows dev I find both of these to be vastly superior to the standard Windows practice of shipping every DLL that's not in system32 alongside your executable, on top of whatever VC++ redistributables and/or .NET framework might not be present on the system.
- gmueckl 7y ago
  That is only true on X. With the wayland protocol, the DE also becomes the display server. And because of barndoor sized holes in the standard wayland protocol, apps will either have enormous testing effort or be limited to a DE or two.
  - japanoise 7y ago
    And that's why wayland will never replace X
  - dependenttypes 7y ago
    Most programs use existing libraries like SDL, GTK, QT, etc, which handle wayland integration on their part.
frankohn 7y ago
> And to me, how could they anyway, I can't find "a Linux desktop". There are many, which one would they port to? This was the very reason that prevented Google to release Google Chrome for Linux.
- finder83 7y ago
  Maybe I'm missing your point, but Google Chrome is available on Linux and is available on pretty much any distro I've tried (and has been for many years).
  - jtl999 7y ago
    If I remember right from years ago (2008-2010) the initial release of Chrome was just for Windows, and the Linux version was in beta for quite a while as just "Chromium" without much Google "cloud" integration.
- dredmorbius 7y ago
  Sarcastic or ignorant?
  - aiCeivi9 7y ago
    Both. GP knows Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs. Clearly supporting diverse (fragmented) linux ecosystem is not easy at all.
    - rstuart4133 7y ago
      > Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs. At least on Debian, it plays perfectly well with the Distro's package management. They use it to auto update google-chrome in preference to their roll their own on effort Windows. The same update system works perfect well on all Debian derived distro's. I'm not familiar with an rpm based distro to say for sure, but I imagine the situation is the same. So "fragmented" means supporting 2 very well tested distribution systems rather than rolling their own - and having the "take out all Macbooks" problems they did on OSX.

by jabits 7y ago

dependenttypes 7y ago

> ~ 2%. 2% of the human population are 154 million people. Sure, not everyone has a computer, so let's say 66 million people, this is the population of France. > There are many, which one would they port to? You don't actually need to support a specific desktop environment. Any UI program that you write will work just fine on KDE, GNOME, DWM, etc

curt15 7y ago
>Any UI program that you write will work just fine on KDE, GNOME, DWM, etc But which versions of which libraries do you target? Every distribution has its own menagerie. There is no well-defined "Linux platform" like there is with Windows (https://docs.microsoft.com/en-us/windows/win32/api/ https://docs.microsoft.com/en-us/windows/win32/api/).
- gmueckl 7y ago
  Core libraries like glibc and Xlib are pretty well defined. You need to ship your own copy of the widget library of choice, but that isn't a big deal. You could even ship an Xlib copy and rely on the fact that there is an X server speaking the same protocol. It's all perhaps a bit messy, but it works.
- dependenttypes 7y ago
  Just static link? Or do what windows software does, so ship dynamic libraries with your application. I do not see the issue. > There is no well-defined "Linux platform" There actually is! https://en.wikipedia.org/wiki/Linux_Standard_Base https://en.wikipedia.org/wiki/Linux_Standard_Base
- disintegore 7y ago
  If your software is FLOSS, that's an integration problem for distro maintainers to solve and it hinges on said libraries being versioned properly. The bigger distros usually have 10,000+ packages and those are downloaded, installed and updated automatically which cannot be said of almost all Windows and OS X software. Really, only Android and iOS offer a similar experience. If your software is proprietary (or not popular enough to be found in most repos), there's always container technologies like Snap/AppImage/FlatPak/etc. As a Windows dev I find both of these to be vastly superior to the standard Windows practice of shipping every DLL that's not in system32 alongside your executable, on top of whatever VC++ redistributables and/or .NET framework might not be present on the system.
gmueckl 7y ago
That is only true on X. With the wayland protocol, the DE also becomes the display server. And because of barndoor sized holes in the standard wayland protocol, apps will either have enormous testing effort or be limited to a DE or two.
- japanoise 7y ago
  And that's why wayland will never replace X
- dependenttypes 7y ago
  Most programs use existing libraries like SDL, GTK, QT, etc, which handle wayland integration on their part.

frankohn 7y ago

> And to me, how could they anyway, I can't find "a Linux desktop". There are many, which one would they port to? This was the very reason that prevented Google to release Google Chrome for Linux.

finder83 7y ago
Maybe I'm missing your point, but Google Chrome is available on Linux and is available on pretty much any distro I've tried (and has been for many years).
- jtl999 7y ago
  If I remember right from years ago (2008-2010) the initial release of Chrome was just for Windows, and the Linux version was in beta for quite a while as just "Chromium" without much Google "cloud" integration.
dredmorbius 7y ago
Sarcastic or ignorant?
- aiCeivi9 7y ago
  Both. GP knows Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs. Clearly supporting diverse (fragmented) linux ecosystem is not easy at all.
  - rstuart4133 7y ago
    > Chrome for Linux exists but ignores that its need for auto-update doesn't play well with distros package management and it also statically-links or ships 3rd party libs. At least on Debian, it plays perfectly well with the Distro's package management. They use it to auto update google-chrome in preference to their roll their own on effort Windows. The same update system works perfect well on all Debian derived distro's. I'm not familiar with an rpm based distro to say for sure, but I imagine the situation is the same. So "fragmented" means supporting 2 very well tested distribution systems rather than rolling their own - and having the "take out all Macbooks" problems they did on OSX.