Ryan Gordon Criticizes Open-Source Drivers Again

[elanthis]

+1 on all the stuff on packaging (well, on everything, but packaging in particular), I wish everyone just used .deb and be done with it.

If only the format itself were the sole problem. Unfortunately, the braindead use of the packaging system by every last single distro is also part of the problem. Good luck getting many debs built for Ubutunu vX to install on Ubuntu v(X+2). Or on Debian, or many other dpkg distributions (even ones derived from Ubuntu, in some cases!).

Two words: dependency management.

Which also shouldn't be necessary for most apps. Your desktop should have the core set of all desktop libraries any reasonable application is ever going to require. Something like what the LSB mandates, except actually useful, modern, and supported.

If you are going to have optional components, make them large, broad components -- groups that include many packages. An "SDL" component should include SDL itself, SDL_ttf, SDL_net, SDL_image, OpenGL, OpenAL, etc. Then at least manual dependency management is simple; the box says it needs OpenGL 3.2, SDL 1.3, and GTK 2.16, rather than needing to list out 79 individual, cryptically-named packages.

Said system even makes it easier and more reliable even when automatic dependency management is in place, for that matter, as well as making it easier for developers to select, install, and test against a minimum base, as well as making it easier to determine which versions of which distros might comply.

[Chewi]

Thank you, AdamW, I totally agree. I said as much but couldn't be bothered to set it out quite so clearly!

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.

I'm all for Desura, while I wouldn't use it myself, I think it will suit many users and could solve these problems as you say. But what you've just described is essentially what distributions do.

[blackiwid]

I dont agree most of it

Hi I dont understand this guy. Most of the stuff is not like he says in my oppinion.

1. drivers, ok they are slow for 3d stuff etc, but why is the openes a problem? the intel drivers are only open, ok no game more than tetris work with them, but thats mostly a hardware problem. Amd the fglrx is way more unstable then the open radeon drivers they are pretty much rock solid, if you not try the newest magic they are 100 rock-solid no crash at all.

Then he says yes yes it would work if the companys would make them from ground blabla. so nobody hinders them. So he should say, the companys that refuse to support a opensource operation system with open drivers suck and are a risk for linux.

Each guy who dont care at all about freedom and gpl and that stuff just buys a nvidia card and uses the proprietary driver anyway. So trying to forbit users to care about openess is big time bullshit.

2. packaging system: so yes lets define one default, so ok I am good with that lets use deb uih some others dont want that? hmm so it can not work when you think that to en end we need one linux with 20 year staying apis, and nobdoy with a brain can want that.

3. Most of that problems only exist because they dont make opensource games in the first place. I dont understand that stuff at all, I dont trust companys so my point would be I dont install some binary stuff which I cannot look into it. So its a trojan or not.
A compromise could be that the games get selled as closed source but with a garantie that the sourcecode gets released in a few years but that should that no good will thing, that should be in the offer. so you can then check when you compile it, does the binary that gets created have the same md5sum than the thing that got sold a few years ago, and if not we would know we cannot trust that company in the future.

Another alternitive would be to create some kind of a sandbox in which games work a bit like android, where programmes list all the rights they need to work. So that you could kind of savely run that games. Wine seems to have some kind of sandbox mechanism, so even wine games that work good would maybe be better then native ports.

I live at the moment with the thought that I have a gaming maschine with windows or a console in the future and one or two machines with linux on it, all with working suspend and that would be the setup, but to infect a linux which I use to work and install there maybe some trojan or rootkit with it, comes not on my machines.

[ean5533]

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.

Good reading. All points that seem obvious after you're read them.

If one takes everything you've said at face value, the sad conclusion is that the divided world of Linux is fundamentally hostile to 3rd party vendors, and will remain hostile as long as it remains divided. That's quite a depressing realization to have.

[Luke_Wolf]

You could make it so that it's installing the library, instead of relying upon package names, which if memory serves yum can do, because I had to do that to compile something a while back, don't know about the others.

In terms Slackware, I don't know about Gentoo or Arch, we can sure as heck compile and package the libraries required ourselves just so long as you give us the list of dependencies you're relying on.

As for this Universal Package nonsense, it's wrong, very bad idea, unless you want to turn Linux into a *BSD, which sucks for the rest of us. I mean for instance Dependency Resolution: Most people might like it as see it as a good idea, but as a Slacker, I don't. As long as I'm told what's required by a program, I'm more than happy to resolve dependencies by hand, It results in a cleaner system than loading just gobs of packages into the dependency list just for the hell of it. Here's another case, what if everybody was stuck using Pulseaudio back during the early days of Pulseaudio, would you have liked that?

I'm sorry but this is Linux, we're more powerful than *BSD because we lack a stable hardware api and thus can turn tighter, being able to turn tighter we can develop more because everything is up for grabs, If I don't like the current audio, display server, init system, etc, I can make my own, and other people who think the same can support me, This is a strength, it is by no means a weakness, and hey if you don't like their developments.. Guess what? since this is Linux not *BSD you don't have to accept them, you can use a distro that doesn't use them or spin your own.

And Okay one final argument against universal package format, let's say we do go with .rpm, .deb, .t?z or whatever even though your format is universal, your packages won't be. We see this right now with .RPMs, this is not the fault of the RPM format, and it's not actually a fault, but since different distros operate differently, (again a strength not a weakness) you can install the package but It's not likely to work, unless it's a bit of software that is generic and has standardized places to install to, say /opt, or in the case of flash /usr/{lib,lib64}/mozilla/plugins/

[del_diablo]

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.

Lets separate this into 2 problems:
1. Actual breakage due libary upgrade
2. Unsane dependancy managment dening a working package from being installed
The first requirement to a new package system would be to force the package manager to not be able to block packages or minor version differences. Package needs libGUI2.0.1 and max version is set to version 2.0.2, and my system ships 2.0.03? Frankly, then install the lib and stop complaining!
I have seen this a few times, and the lack of a "ignore the issue and install anyhow" button annoyed me each time.
Now, if there is some actual lib differences that cause breakage, the package managers job is to find them, and not "a bit different versions". And if it actually happens, then we suddenly got a valid bug report out of nowhere, instead of the package manager denying installation because it can.

[pingufunkybeat]

There is NO need for a universal package format.

Everything that such a package format would accomplish can already be accomplished by using alien.

The fact that it does not work just shows that it wouldn't work with a universal package format either.

[deanjo]

3. Most of that problems only exist because they dont make opensource games in the first place. I dont understand that stuff at all, I dont trust companys so my point would be I dont install some binary stuff which I cannot look into it. So its a trojan or not.
A compromise could be that the games get selled as closed source but with a garantie that the sourcecode gets released in a few years but that should that no good will thing, that should be in the offer. so you can then check when you compile it, does the binary that gets created have the same md5sum than the thing that got sold a few years ago, and if not we would know we cannot trust that company in the future.

Another alternitive would be to create some kind of a sandbox in which games work a bit like android, where programmes list all the rights they need to work. So that you could kind of savely run that games. Wine seems to have some kind of sandbox mechanism, so even wine games that work good would maybe be better then native ports.

I live at the moment with the thought that I have a gaming maschine with windows or a console in the future and one or two machines with linux on it, all with working suspend and that would be the setup, but to infect a linux which I use to work and install there maybe some trojan or rootkit with it, comes not on my machines.

Do YOU personally audit ALL the code on your system? If not then you are living under a false sense of security. There have been cases where even when the source was open it had nefarious code that has undiscovered for years.

[pingufunkybeat]

Do YOU personally audit ALL the code on your system? If not then you are living under a false sense of security. There have been cases where even when the source was open it had nefarious code that has undiscovered for years.

That's a fallacy right there.

He didn't claim that it is impossible to plant nefarious code into FLOSS projects.

His point still stands -- he CAN inspect the code, and there are many people (especially companies) who DO inspect it.

[deanjo]

His point still stands -- he CAN inspect the code, and there are many people (especially companies) who DO inspect it.

But the reality is that he is still trusting someone else to make sure the code is OK which is what 99.9999% of end users do.