Announcement

Collapse
No announcement yet.

Ryan Gordon Criticizes Open-Source Drivers Again

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Wyatt View Post
    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.


    Originally posted by Wyatt View Post
    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?


    Originally posted by Wyatt View Post
    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.

    Comment


    • #32
      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.

      Comment


      • #33
        Originally posted by FreeBooteR69 View Post
        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.
        Last edited by ean5533; 08-08-2011, 01:34 PM.

        Comment


        • #34
          Originally posted by ean5533 View Post
          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.

          Comment


          • #35
            Originally posted by mirv View Post
            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.

            Comment


            • #36
              Originally posted by ean5533 View Post
              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!

              Comment


              • #37
                Originally posted by ean5533 View Post
                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.

                Comment


                • #38
                  Originally posted by deanjo View Post
                  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.

                  Comment


                  • #39
                    Packaging: missing the point again

                    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.

                    Comment


                    • #40
                      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.

                      Comment


                      • #41
                        Originally posted by Kazade View Post
                        +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!).

                        Originally posted by ean5533
                        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.

                        Comment


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

                          Originally posted by ean5533 View Post
                          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.

                          Comment


                          • #43
                            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.

                            Comment


                            • #44
                              Originally posted by AdamW View Post
                              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.

                              Comment


                              • #45
                                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/

                                Comment

                                Working...
                                X