7 ms·

I think a lot of things he listed in how things currently are (under "Upstream Projects") are either wrong or overblown. For instance, the claim that the Linux

by Arizhel 10y ago

I think a lot of things he listed in how things currently are (under "Upstream Projects") are either wrong or overblown. For instance, the claim that the Linux packaging scheme doesn't work for proprietary, closed-source software. That's just plain wrong. No, proprietary software makers can't rely on distribution maintainers to package their stuff, however there is nothing preventing them from packaging it themselves, and making it available in a 3rd-party repository. Both deb/apt and rpm/yum have had this facility for ages, and it's how a lot of Linux users get either software not supported by the distro (like media stuff that Fedora refuses to include), or software that the distro drags its feet on updating. Proprietary vendors can easily use the same system to make their software available to users, and to allow the software to be easily kept up-to-date using the existing system instead of running a separate "update checker" constantly in the background like is common on Windows systems. The main problem is that there's more than one Linux distro out there, and they're not compatible with each other. But as Google does already with Google Earth and Chrome, for instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint. Another important point is libraries. They complain about the library dependencies all being different on different distros. But there's nothing stopping proprietary vendors from statically-linking everything, which is how they usually do it anyway, both on Linux and on Windows. Sure, it bloats up the binary, but it avoids a lot of library version and dependency problems, and with modern HD and RAM sizes, it's not that much of an issue. It seems to me that they're proposing an enormously complicated and bloated system here in an effort to increase usage of desktop Linux, but this isn't going to help.

emmelaich 10y ago
> Proprietary vendors can easily use ... > there's nothing stopping proprietary vendors ... Yeah but they don't which is the whole point.
- xorblurb 10y ago
  Some of them do. Likewise, proprietary vendors can "easily" publish UWP programs for Windows. They don't. Well I'm exaggerating a little, actually some of them do.
  - lewiseason 10y ago
    > Some of them do. It's true, but they often manage to make a huge mess of it (note: entirely baseless remark based on my personal experience). More importantly, most of them don't, and that sucks. I'm not sure why they don't, but I suspect that this is not the silver bullet?
- paulddraper 10y ago
  I'm pulling from Google Chrome's apt repo right now.
sjellis 10y ago
> The main problem is that there's more than one Linux distro out there, and they're not compatible with each other. But as Google does already with Google Earth and Chrome, for instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint. Google is quite an unusual case, though: they need to provides comparatively little end-user support for those products (relative to the absolutely huge sizes of the company and the user-bases). They already have the resources to build Linux versions, and they probably want them for their large internal pool of Linux users any way, but it is not business-critical to them whether Google Earth or even a given version of Google Chrome work well for you as a Linux user on your particular system. AFAIK they don't have to provide training, phone support or even a huge amount of detailed docs as part of offering the Linux builds of the products. For companies with proprietary, licensed products, particularly the really feature-rich ones that focus on business or professional users, the product has to work without glitches or quirks on every platform that they support. When it doesn't, things rapidly get expensive: diagnosing bugs in the field and shipping fixes is still frequently time-consuming and labour-intensive. Even maintaining a test process for five Linux distributions to validate releases is not going to be cheap, and probably not cost-effective. They also need developers, QA and support staff with a working knowledge of two families of Linux. And if they did it, they would consistently get requests for supporting more distributions, and have to keep politely saying "no" over and over again... It does make economic sense for some companies to produce Linux versions of their products today, but I think that it's fair that each of them is unusual in some way. The situation needs to change for the economics to work for the average ISV.
pantalaimon 10y ago
It's funny you mention Chrome, as they disable hardware based video decoding on Linux, but not on Chrome OS where they control the whole ecosystem.
oconnor663 10y ago
Running 3rd party packaging repos does work, and we do it at Keybase, but it's surprisingly annoying. Distro upgrades disable your repo by default, and your packages need to install a cronjob to detect when it happens and fix it. And because that scenario is difficult to test, you inevitably get bugs like this one: https://bugs.chromium.org/p/chromium/issues/detail?id=660145 https://bugs.chromium.org/p/chromium/issues/detail?id=660145 So it works, but I really wish we didn't have to maintain it.
- majewsky 10y ago
  > Distro upgrades disable your repo by default Have you considered filing a feature request with the distributions about this? I can see why they do it this way, but there are certainly ways around this problem. (For example, a repo's metadata could include references to the identical repo for other OS versions, so that an upgrade can automatically switch to the appropriate repo.)
- Arizhel 10y ago
  This definitely sounds like a bug to me. Assuming your company is maintaining 3rd-party repos for both the older and newer versions of the distro, doing a distro upgrade should, logically, switch to your repo for the newer OS version automatically, so it's completely seamless to the user. If the distro isn't doing that, that seems like an oversight.

by Arizhel 10y ago

emmelaich 10y ago

> Proprietary vendors can easily use ... > there's nothing stopping proprietary vendors ... Yeah but they don't which is the whole point.

xorblurb 10y ago
Some of them do. Likewise, proprietary vendors can "easily" publish UWP programs for Windows. They don't. Well I'm exaggerating a little, actually some of them do.
- lewiseason 10y ago
  > Some of them do. It's true, but they often manage to make a huge mess of it (note: entirely baseless remark based on my personal experience). More importantly, most of them don't, and that sucks. I'm not sure why they don't, but I suspect that this is not the silver bullet?
paulddraper 10y ago
I'm pulling from Google Chrome's apt repo right now.

sjellis 10y ago

> The main problem is that there's more than one Linux distro out there, and they're not compatible with each other. But as Google does already with Google Earth and Chrome, for instance, it's not that hard to just target RH/Fedora and Debian/Ubuntu/Mint. Google is quite an unusual case, though: they need to provides comparatively little end-user support for those products (relative to the absolutely huge sizes of the company and the user-bases). They already have the resources to build Linux versions, and they probably want them for their large internal pool of Linux users any way, but it is not business-critical to them whether Google Earth or even a given version of Google Chrome work well for you as a Linux user on your particular system. AFAIK they don't have to provide training, phone support or even a huge amount of detailed docs as part of offering the Linux builds of the products. For companies with proprietary, licensed products, particularly the really feature-rich ones that focus on business or professional users, the product has to work without glitches or quirks on every platform that they support. When it doesn't, things rapidly get expensive: diagnosing bugs in the field and shipping fixes is still frequently time-consuming and labour-intensive. Even maintaining a test process for five Linux distributions to validate releases is not going to be cheap, and probably not cost-effective. They also need developers, QA and support staff with a working knowledge of two families of Linux. And if they did it, they would consistently get requests for supporting more distributions, and have to keep politely saying "no" over and over again... It does make economic sense for some companies to produce Linux versions of their products today, but I think that it's fair that each of them is unusual in some way. The situation needs to change for the economics to work for the average ISV.

pantalaimon 10y ago

It's funny you mention Chrome, as they disable hardware based video decoding on Linux, but not on Chrome OS where they control the whole ecosystem.

oconnor663 10y ago

Running 3rd party packaging repos does work, and we do it at Keybase, but it's surprisingly annoying. Distro upgrades disable your repo by default, and your packages need to install a cronjob to detect when it happens and fix it. And because that scenario is difficult to test, you inevitably get bugs like this one: https://bugs.chromium.org/p/chromium/issues/detail?id=660145 https://bugs.chromium.org/p/chromium/issues/detail?id=660145 So it works, but I really wish we didn't have to maintain it.

majewsky 10y ago
> Distro upgrades disable your repo by default Have you considered filing a feature request with the distributions about this? I can see why they do it this way, but there are certainly ways around this problem. (For example, a repo's metadata could include references to the identical repo for other OS versions, so that an upgrade can automatically switch to the appropriate repo.)
Arizhel 10y ago
This definitely sounds like a bug to me. Assuming your company is maintaining 3rd-party repos for both the older and newer versions of the distro, doing a distro upgrade should, logically, switch to your repo for the newer OS version automatically, so it's completely seamless to the user. If the distro isn't doing that, that seems like an oversight.