Ryan Gordon Criticizes Open-Source Drivers Again

[ean5533]

Damn, man, what's got your panties in a bunch today? It would be hard for you to have had a worse day than me; why not lighten up a little?

I'm trying to keep the conversation civil. Everyone was being respectful until you came in with your negative attitude. I really don't care how hard your day was, your disrespect steers the conversation towards throwing around insults.

Anyway, since you were more focused on the "BSD is not Linux" argument than trying to understand why I said that: what you're suggesting is a poor idea is, in fact, just how OSX packaging works. It's wasteful as all get-out and I'll never dare say I like it, but it exists in significant deployment and it unequivocally works. All humour aside, this isn't something you can just dismiss with "how it feels" arguments.

It's also the way Windows packaging works, typically. And again, it's irrelevant, because Linux doesn't have a set of standard libraries like OSX and Windows have. In Windows, you can always be assured that user32 will be there -- always. On OSX, libSystem will be there, always. On Linux? No guarantees about anything. So what libraries do application developers package? Everything, right down to X libraries? Your tarballs will be insanely large and complex. Just pick an arbitrary depth and then hope it covers "enough" of your customers?

Which is why it's a tarball that anyone can install without the package manager or maintainer's blessing.

This still doesn't do anyone any good. When Joe goes and downloads a tar'd executable from CoolGames.com and tries to run it, he's not going to understand why the program is crashing as it fails to find libcairo. The executable won't tell him anything useful, won't help him install dependencies, and leaves him stranded.

Unless of course you're proposing tarballs with all libraries bundled in -- in which case, see my last paragraph about not knowing what to bundle.

[FreeBooteR69]

This still doesn't do anyone any good. When Joe goes and downloads a tar'd executable from CoolGames.com and tries to run it, he's not going to understand why the program is crashing as it fails to find libcairo. The executable won't tell him anything useful, won't help him install dependencies, and leaves him stranded.

Unless of course you're proposing tarballs with all libraries bundled in -- in which case, see my last paragraph about not knowing what to bundle.

If CoolGames.com would list the required dependancies to use their software Joe would just use his package manager to install them.

[ean5533]

If CoolGames.com would list the required dependancies to use their software Joe would just use his package manager to install them.

That's not a reasonable expectation for end users. Yes, many current Linux users are smart enough to "sudo apt-get install <the stuff that the site says I need>", but they shouldn't have to be. That's the whole problem: it requires users to be computer savvy, which instantly cuts out a significant segment of the market, and thus keeps them away from Linux. On Windows you just pop in the install disk and it works. Having to manually install libraries is not something that users should be required to do in order to play the latest version of Angry Birds (or whatever example game you want to use).

Of course, the appearance of something like a Desura (or Steam*) client on Linux could make a lot of those problems go away.

*Note: Sorry, I couldn't help myself.

[mirv]

That's not a reasonable expectation for end users. Yes, many current Linux users are smart enough to "sudo apt-get install <the stuff that the site says I need>", but they shouldn't have to be. That's the whole problem: it requires users to be computer savvy, which instantly cuts out a significant segment of the market, and thus keeps them away from Linux. On Windows you just pop in the install disk and it works. Having to manually install libraries is not something that users should be required to do in order to play the latest version of Angry Birds (or whatever example game you want to use).

Of course, the appearance of something like a Desura (or Steam*) client on Linux could make a lot of those problems go away.

*Note: Sorry, I couldn't help myself.

So long as [insert client name here] doesn't attempt to install things itself. Perhaps it might work with Ubuntu, but I personally don't want such a client touching any more than necessary to run (which basically means touch nothing other than the games!). Let [insert client name here] handle the games, and the distro package manager handle [insert client name here]. That's how I see it anyway.

[ean5533]

So long as [insert client name here] doesn't attempt to install things itself. Perhaps it might work with Ubuntu, but I personally don't want such a client touching any more than necessary to run (which basically means touch nothing other than the games!). Let [insert client name here] handle the games, and the distro package manager handle [insert client name here]. That's how I see it anyway.

Agreed. It should be trivially easy for Desura to maintain a list of required libs for each game. Then when the user installs a game, Desura just gives a shout to apt-get or yum to install those packages, leaving Desura totally out of the mix of messing with system libs.

[mirv]

Agreed. It should be trivially easy for Desura to maintain a list of required libs for each game. Then when the user installs a game, Desura just gives a shout to apt-get or yum to install those packages, leaving Desura totally out of the mix of messing with system libs.

Yep, just what I thought. Desura could add or remove any supported package manager it wants that way, and simply display any error message for an unsupported package manager (or at the user's request). Desura (or whatever) does some of the lifting, publishers just support Desura (or whatever), and users can play games without as many hassles. Let's hope!

[deanjo]

Agreed. It should be trivially easy for Desura to maintain a list of required libs for each game. Then when the user installs a game, Desura just gives a shout to apt-get or yum to install those packages, leaving Desura totally out of the mix of messing with system libs.

That isn't easy to do either as package names and what provides is not consistent across distros (or sometimes even versions of distros) either.

[ean5533]

That isn't easy to do either as package names and what provides is not consistent across distros (or sometimes even versions of distros) either.

Yeah, I thought about that a few minutes after I posted. Still, I don't think the problem is insurmountable. Desura could maintain their own list of package names and map them to their equivalents in various distros.

MADE UP EXAMPLE WITH FAKE PACKAGE NAMES: So say a game needs cairo; there would be a mapping showing that on Debian the corresponding package is "libcairo2", while on Fedora it's just "libcairo".

How complicated this mapping needs to be would depend on how complicated the package names are between distros (and apparently between versions; I didn't realize major libs would change naming schemes between distro versions). Of course this limits you now to officially supporting only specific distros, but I think as long as the big names were covered (Debian, Ubuntu, Fedora, SUSE) it would be fine. All the derivative distros like Mint that build off of those big names would probably get a free ride. I doubt, for example, that Mint has any core libs named differently than in Ubuntu. (But I've been wrong before)

As for the smaller distros... well, anyone running Arch probably isn't going to be installing Desura. And if they are, those guys are smart enough to compile their own dependencies.

[AdamW]

I'm continually amazed at how many clearly smart people completely miss the point when it comes to packaging.

"I understand there are holy wars about text editors, and desktop environments, and toolkits. But this feels like something we should agree on, standardize, and stop thinking about. I can't say if one technology is better than the other, but it feels like it's entirely a question of ego that prevents unification."

It's...just...no.

The package format really isn't that important. To illustrate this, let's take a thought experiment.

Let's say Debian and Ubuntu switch to RPM tomorrow.

Great! Right? Third parties can just ship a single RPM, and everyone will be happy.

Except...hang on. They make an RPM which installs just fine on Ubuntu, then they start getting bug reports from Fedora users that it doesn't work on Fedora. The dependencies are wrong. The package refuses to install because it's looking for 'libfoo', but in Fedora the package is called 'foo'. Besides, it was compiled against libbar 2.0, but Fedora has libbar 2.1, which isn't ABI compatible!

Then the SUSE users start chiming in. They have a totally different set of dependency problems.

The package format really doesn't matter. The point, when you reduce it down to its essence, is quite simply: distributions are different.

Well, duh. That's what distributions are _for_.

The 'problem' here is essentially insoluble: you're never going to be able to create a single dynamically-linked package which works across all distributions. If you could, there wouldn't be any point in multiple distributions existing at all, because _it would mean that all the distributions were pretty much the same thing_. As long as multiple distributions actually exist, it will not be possible to simply deploy a single dynamically-linked build of any vaguely complex bit of software across all of them.

Even mitigating this is a far more complex problem than 'let's all use the same package format'. Every so often there's an attempt to mitigate it by agreeing on a common base that will be present in the same format across all distributions, so that third party software can rely on that set of libraries and so on existing, being in the same places, and of the same (or at least compatible) versions across all distributions. Exactly one of these efforts - LSB - has ever even remotely succeeded. All the others failed miserably. It just doesn't work.

In the end, if you want to ship a single build of your software as a third party - instead of shipping and maintaining multiple builds or relying on distributors to do the integration for you (which is the way it's supposed to work), you're going to want to make it an almost entirely static build, limiting dependency on shared components to the most widely established bits like libc that you can more or less assume are always going to be there. And if you're going to do that, why bother using a package format at all? The point of package formats is to enable a) dependency management and b) organized updates. As a third-party provider of a static bit of software you're not going to be able to take advantage of either of those mechanisms, so there's precisely zero point in using a 'native' package format. Just put the thing in a tarball.

If you want native packages, work with distributions to make it possible. If you think this is too much trouble, go static. Accept that this is an unavoidable consequence of the existence of multiple distributions, accept that multiple distributions exist _because people want there to be multiple distributions_ - i.e. they have different ideas as how choice of software, software versions, naming schemes, package splits and all that stuff that _is what a distribution DOES_ should be handled. Accept that this isn't going to change until people no longer actually care about all of those things.

Or go write web apps, where there actually is a common platform and you don't have to worry about this stuff.

[moonlitfire]

I don't think everyone is EVER going to agree on a gold standard for packaging. The whole reason it's "fragmented" in first place is because people don't agree on how things should be done. Other than that Icculus is spot on everything else I think, especially the point on vendors making their own stinking drivers open source.