Announcement

Collapse
No announcement yet.

Ubuntu 9.10 Off To A Great Performance Start

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

  • #46
    Originally posted by deanjo View Post
    Did you even bother actually reading my initial comment? Seems you are arguing the exact same thing now.
    You're arguing this:
    Originally posted by deanjo View Post
    And be limited to crappy performance and accept 50% 3d performance as good enough? I don't think so. Now that would really put linux gaming another 10 years behind.
    Which is exactly the same as this:
    Originally posted by deanjo View Post
    "We can't fix their crap, screw them."
    Get it?

    Originally posted by deanjo View Post
    As far as "binary blobs which are impossible to properly support" that my friend is a load of horseshit. If the X layer didn't change on a weekly basis and they actually settled on some set standards then it becomes very easy to maintain blob compatibility. It's because of this volatile type of development that you do see blobs break. In other OS's you are fully capable of upgrading kernels and video subsystems without breaking the previously installed driver.
    Hmm, seems that over a hundred kernel developers and Linus disagree with you. I guess they just don't understand? Maybe you should enlighten them.
    In fact, just last year some guy explained it like this:
    Well, there’s – the lack of an ABI is two-fold: one is we really, really, really don’t want one. Every single time people ask for a stable ABI, the main reason for wanting a stable ABI is they want to have their binary drivers and they don’t want to give out source and they don’t – certainly don’t want to merge that source into the stable kernel or the standard kernel.

    And that, in turn, means that all the people who actually do all the kernel work and maintain the kernel are basically unable to work with that piece of hardware and that vendor because if there’s any bugs whatsoever, we can’t fix them.

    So, all the commercial vendors—even the ones who used to accept binary drivers—have moved or are moving away from wanting to have anything at all to do with binary drivers because they’re completely unmaintainable.

    So, there’s one of the reasons. Some people see it as political. There is probably a political aspect to it, but a lot of it is very pragmatic; we just can’t maintain it.

    (...)

    And when you have that kind of distributed support system when – where everybody ends up being involved at some point, you really can’t afford to have the situation where only a very small subset actually has access to the code that may be causing the problem. You need to have the code out there, not because of any social issues, but simply because you don’t know who’s going to be the one who has to fix it.

    So, there’s a real reason why we need to be able to have source code which means that to all kernel developers, a binary interface is basically – it is only a bad thing. There is – there are no upsides whatsoever.

    But there’s another reason which is that we actually do end up changing things in radical ways inside the kernel and that has led to the fact that even if we wanted to have a binary interface, we simply couldn’t or we could but it would then stop us from fixing stuff and changing how we do things internally.

    And this is something you do see in other projects where, yes, they have binary interfaces for one reason or another—quite often because of commercial reasons—and that just means that they cannot fix their fundamental design. They sign up not just the binary interfaces, they also sign up to the exact design they had when they came up with that interface.

    So, there’s – that’s the second major reason why a stable ABI is not going to make – in fact, that means that we don’t even guarantee a stable API; so, even on a source level we say, “Okay, this is the API and we’ll – if you have external drivers that use this, we’ll help you fix them up when we have to change the API. But we don’t guarantee that the same API will work across versions.” And it doesn’t.

    Comment


    • #47
      Here is a very enlightening article about kernels ABI's and API's!
      http://www.kroah.com/log/linux/ols_2006_keynote.html

      Comment


      • #48
        Originally posted by bridgman View Post
        unless there is some reasonably clear benefit to the folks who will have to invest in a new model it's going to be tough to sell the change.
        You're right, and because companies see money in locking users into their system and software, Linux users will suffer. That's why I will continue to help projects like Zero Install which break down those barriers toward easy Linux software installation.

        Originally posted by curaga View Post
        Cool. Except that the happy scenario won't happen unless everyone switches to this universal format at once. And since that won't happen, it's more work. Not something that everyone can justify even if it, as you say, brings more users. That is obviously because at that point, your dream format is only "another format" and there might even be more users gainable by packaging for ubuntu.
        No, it's called a technological challenge, and just because you haven't thought of a solution after thinking about it for maybe a fraction of a second doesn't mean there isn't one. One way of doing it is simply defining a bunch of metadata about a package and then letting the manager do what it wants to with it, and making the software be flexible and not using stupid static links so that the program can be completely manipulated in any way that package manager wants to. Such a solution means you can make a package manager be compatible with multiple formats and yet still install them all, you don't have to completely switch from RPM or DEB to NEWFORMAT, hell you may not even have to switch at all if DEB or RPM were updated to be more flexible so that they could be used as universal formats. Seriously, it's not that hard, it's not that complicated, it's just that these companies aren't interested in playing nice with the rest of the Linux community.

        I'm talking about using format*S*, you don't have to force a single one on users, but you SHOULD use formats that any manager can easily adopt that are good enough formats to be worthy of the term Standard. Such formats should be promoted by the ISO, Freedesktop.org, and any other standards bodies as being of pivital importance in helping Linux interoperability.

        (that is, if the ISO wasn't already possibly sold out to M$)

        Originally posted by Kano View Post
        Sourcecode is definitely the best way for Linux, maybe a beginner does not understand this.
        Yes, because if Linux users could actually easily install programs from across the Internet instead of being controlled and limited by their distro company, that might help to increase the rate of adoption for all of Linux as a whole, it'd be horrible.

        Clearly we have different opinions of what is best.

        Originally posted by krazy View Post
        Hmm, seems that over a hundred kernel developers and Linus disagree with you. I guess they just don't understand? Maybe you should enlighten them.
        You can do whatever you want to. Those developers don't want to do it because then the distro companies can stay in control and have the focus on them instead of sharing with the Linux ecosystem. There is no technical reason for not having an API. The entire point and definition of an API is so that you can have progress while still having compatibility. Maybe you should read the definition sometime.

        This immature motive is revealed in the very opening paragraph which maybe you should actually read: "Every single time people ask for a stable ABI, the main reason for wanting a stable ABI is they want to have their binary drivers and they don’t want to give out source and they don’t – certainly don’t want to merge that source into the stable kernel or the standard kernel."

        Ooooh, so they don't WANT it just because they don't want anyone, random developers or companies, to be actually able to make drivers for their kernel without them being able to know about it, control it, and accept it. They want to be in control, and remove that control from those random individuals. So do the distro companies, they have the exact same goal. They want all the focus to be on them instead of the general Linux community itself, so *they* can be recognised and become the household name, and force everyone to have to come to them for everything.

        There's a billion parallels I could tell you about in the business world, like how car companies do the same thing by trying to make it so that every part has to come from them, for example using proprietary computer systems in their cars that require either finding and copying the program, if you're lucky enough to find the program online, or you have to go to them for simple things like "resetting it" so they can charge you $$$. They don't want competition, they don't want an open ecosystem of sharing and interoperability and standards, and it's the exact same thing with these companies that fund the kernel development. Hmm maybe who writes their paychecks has something to do with it??? Naaaaaaaah.

        So, because of these assholes, because of that reason, I can't easily install drivers, and are pushed to get all my software from Canonical instead of from the REAL developers. Yay! Linux sure is all about freedom and choice isn't it?!
        Last edited by Yfrwlf; 05-20-2009, 06:24 PM.

        Comment


        • #49
          Originally posted by Yfrwlf View Post
          There is no technical reason for not having an API.
          Yes there is. It's called Windows.

          Windows has a 'stable API' which will still run binaries from twenty years ago; as a consequence it includes about a bazillion lines of crud that no-one should be using anymore, which includes a ton of bugs, tons of security holes, and requires vast amounts of time for developers to maintain.

          The entire point and definition of an API is so that you can have progress while still having compatibility.
          You only need binary compatibility if you refuse to hand out your source code. Linux kernel developers don't want to be tied down into some fossilised API which prevents them from making major design improvements, because they've seen what that's done to other operating systems.

          'Stable APIs' are a really, really bad idea from a technical standpoint, because it ties you into bad design choices made years before. I don't know why this is so hard for some people to understand.

          Comment


          • #50
            Yup, APIs may be comfortable but they can easily fill your code with a lot of garbage. This guy here explains it much better (it's part from the link I posted above)...
            If you have any questions please go read this file. It explains why Linux doesn't have a stable in-kernel api, and why it never will. It all goes back to the evolution thing. If we were to freeze how the kernel works internally, we would not be able to evolve in ways that we need to do so.

            Here's an example that shows how this all works. The Linux USB code has been rewritten at least three times. We've done this over time in order to handle things that we didn't originally need to handle, like high speed devices, and just because we learned the problems of our first design, and to fix bugs and security issues. Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break. And we deleted the old functions as they were no longer needed, and did things wrong. Because of this, Linux now has the fastest USB bus speeds when you test out all of the different operating systems. We max out the hardware as fast as it can go, and you can do this from simple userspace programs, no fancy kernel driver work is needed.

            Now Windows has also rewritten their USB stack at least 3 times, with Vista, it might be 4 times, I haven't taken a look at it yet. But each time they did a rework, and added new functions and fixed up older ones, they had to keep the old api functions around, as they have taken the stance that they can not break backward compatibility due to their stable API viewpoint. They also don't have access to the code in all of the different drivers, so they can't fix them up. So now the Windows core has all 3 sets of API functions in it, as they can't delete things. That means they maintain the old functions, and have to keep them in memory all the time, and it takes up engineering time to handle all of this extra complexity. That's their business decision to do this, and that's fine, but with Linux, we didn't make that decision, and it helps us remain a lot smaller, more stable, and more secure.

            And by secure, I really mean it. A lot of times a security problem will be found in one driver, or in one core part of the kernel, and the kernel developers fix it, and then go and fix it up in all other drivers that have the same problem. Then, when the fix is released, all users of all drivers are now secure. When other operating systems don't have all of the drivers in their tree, if they fix a security problem, it's up to the individual companies to update their drivers and fix the problem too. And that rarely happens. So people who buy the device, and then use the older driver that comes in the box with the device, which is insecure. This has happened a lot recently, and really shows how having a stable api can actually hurt end users, when the original goal was to help developers.

            Comment


            • #51
              Originally posted by movieman View Post
              'Stable APIs' are a really, really bad idea from a technical standpoint, because it ties you into bad design choices made years before. I don't know why this is so hard for some people to understand.
              It is simple to change underlying implementation while keeping same interface. That why we have libraries between kernel and programs translating the SUS interface to kernel interface.

              Comment


              • #52
                Originally posted by suokko View Post
                It is simple to change underlying implementation while keeping same interface.
                You can do it, yes: Windows ability to run ancient DOS programs has proven that. But why would you want to?

                Again, the only reason to push a 'stable API' on the kernel is because you don't want to release your source code. If you don't want to release your code, then the onus is on _YOU_ to keep up with kernel changes, not on kernel developers to go to a great deal of extra trouble maintaining APIs that they no longer want.

                Comment


                • #53
                  Originally posted by movieman View Post
                  You can do it, yes: Windows ability to run ancient DOS programs has proven that. But why would you want to?
                  Why? Because there are a large number of applications out there that are specialized for tasks. DOS based apps are still alive and well in many industrial applications. Typically these applications are not your "on the shelf for $50" but often cost thousands of dollars and do their job rather well. Just off the top of my head I can think of 10+ applications that there is no other OS equivalent. Hardware gets old and dies and replacing it shouldn't mean having to re-invest in software that fully accomplishes the task needed.

                  Comment


                  • #54
                    Originally posted by deanjo View Post
                    Why? Because there are a large number of applications out there that are specialized for tasks. DOS based apps are still alive and well in many industrial applications. Typically these applications are not your "on the shelf for $50" but often cost thousands of dollars and do their job rather well. Just off the top of my head I can think of 10+ applications that there is no other OS equivalent. Hardware gets old and dies and replacing it shouldn't mean having to re-invest in software that fully accomplishes the task needed.
                    There wouldn't be such problems with open source. It's better to implement better API from time to time and OS projects will adapt. You don't have to keep crappy designed ABI's to make some old programs work. It's one of the reasons why OS is better then closed source.

                    Comment


                    • #55
                      Originally posted by kraftman View Post
                      There wouldn't be such problems with open source. It's better to implement better API from time to time and OS projects will adapt. You don't have to keep crappy designed ABI's to make some old programs work. It's one of the reasons why OS is better then closed source.

                      Not true at all. How many developers for example would maintain items such as dry cleaning software, oil field monitoring software, trucking software, ILS systems, weight and scale systems, custom inventory applications, seed cleaning software, etc etc etc. Many such applications would require complete rewrites add large cost to the user for a system that would mean either investing heavily in not only paying for the redevelopment of the software but also in many industrial cases would require upgrading of the hardware they are meant to be monitoring as well. When it comes to opensource such solutions are like trying to find hens teeth where they are maintained on a regular basis. Being opensource by no means of the imagination means maintained. Sure one might have the oppertunity to do so but it does not mean by any extent that will happen, especially in specialized software where the target market is small.
                      Last edited by deanjo; 05-21-2009, 10:07 AM.

                      Comment


                      • #56
                        Originally posted by deanjo View Post
                        Not true at all. How many developers for example would maintain items such as dry cleaning software, oil field monitoring software, trucking software, ILS systems, weight and scale systems, custom inventory applications, seed cleaning software, etc etc etc. Many such applications would require complete rewrites add large cost to the user for a system that would mean either investing heavily in not only paying for the redevelopment of the software but also in many industrial cases would require upgrading of the hardware they are meant to be monitoring as well. When it comes to opensource such solutions are like trying to find hens teeth where they are maintained on a regular basis.
                        If they have to be completely rewritten that's clear. If such apps are very old it will be even harder to maintain them or impossible if they're closed source and company is no more.
                        Last edited by kraftman; 05-21-2009, 10:18 AM.

                        Comment


                        • #57
                          Originally posted by kraftman View Post
                          If they have to be completely rewritten that's clear. If such apps are old it will be even harder to maintain them or impossible if they're closed source and company is no more.
                          Thus why maintaining that backward capability is important. To switch to other solutions would millions if not billions of dollars in infrastructure to redo. Saying it sucks because it's closed and hoping that someone may even have the faintest clue let alone ambition to maintain such needs exists in a "dream world" but when real life is in play it doesn't apply in practice.

                          Comment


                          • #58
                            Originally posted by deanjo View Post
                            Thus why maintaining that backward capability is important. To switch to other solutions would millions if not billions of dollars in infrastructure to redo.
                            When comes to unstable API/ABI you can usually stick with older system which remains compatible with some application.

                            Saying it sucks because it's closed and hoping that someone may even have the faintest clue let alone ambition to maintain such needs exists in a "dream world" but when real life is in play it doesn't apply in practice.
                            Yeah, theory sometimes looks nice, but it's not so nice when comes to real situation. However, you still have greater chance to do something which such old relic if it's open source. Everything depends

                            Comment


                            • #59
                              Originally posted by deanjo View Post
                              Thus why maintaining that backward capability is important. To switch to other solutions would millions if not billions of dollars in infrastructure to redo. Saying it sucks because it's closed and hoping that someone may even have the faintest clue let alone ambition to maintain such needs exists in a "dream world" but when real life is in play it doesn't apply in practice.
                              Your point is largely moot. Saying that crappy approaches to software design should be kept in place and used because they have met with large audience and _now_ the only affordable solution is to keep them in place is no more than saying 'this is the situation, face it'. It's not even an argument, it's at best a laying forth of the pitiful situation in the closed source world.

                              The 'solution' to this 'situation' is developing sustainably to begin with, and that would mean for Linux.

                              Comment


                              • #60
                                Originally posted by susikala View Post
                                Your point is largely moot. Saying that crappy approaches to software design should be kept in place and used because they have met with large audience and _now_ the only affordable solution is to keep them in place is no more than saying 'this is the situation, face it'. It's not even an argument, it's at best a laying forth of the pitiful situation in the closed source world.

                                The 'solution' to this 'situation' is developing sustainably to begin with, and that would mean for Linux.
                                Perhaps we should apply the same philosophy to hardware in the kernel too then. Think of all the additional talent that could be used in focusing on current hardware instead of maintaining old legacy hardware. Think of how much easier it would be to maintain the kernel if all that old hardware support was scrapped.

                                Comment

                                Working...
                                X