Announcement

Collapse
No announcement yet.

Ubuntu 9.10 Off To A Great Performance Start

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

  • #31
    Originally posted by krazy View Post
    If all hardware companies followed the "open source" (and open specs) linux standard for hardware support, then there would be no problem. AMD's currently doing the right thing by releasing code and hardware specs, but it will take time for hardware support to mature.
    Open source software is great, I agree, it allows others to more easily help out and submit bug fixes, it encourages transparency, and best of all, if the community as a whole doesn't like it, they can help change it, and if the dev's don't want to, it can be forked if needed. Ideally though, if it has to do with certain features or options being available, the dev's should make a plug-in system to allow anyone to piece in the modules they prefer, but that's a different subject.

    However, having all the modularity on the source level isn't the answer, because modern Linux users don't want to be bothered with compiling, and having every distro do it isn't the most free answer either as this only makes users have to go round about through them instead of from the devs, and needlessly creates duplicated effort and work when every version of a program should only have to be compiled once, and then made available for all Linux users. For example, I can't even try out Firefox Beta 3.5 cleanly because there are no packages for it right now, just a simple binary when all the other platforms have a nice juicy package they can all easily install. They get a nice feature, while Linux users suffer. In other words, right now, things suck. That's the coffee, so wake up to it.

    Originally posted by SolidSteel144 View Post
    That's a damn shame. Instead of people just getting something that works and make it their own they should just improve that software. Unity is key.
    Exactly, the original dev's are the one who should get the web traffic, bug reports, etc, and while mirrors and easy software installation systems like yum and apt-get are great, don't get me wrong, and should definitely continue to be used, those systems would have a billion times more software packages available to users if universal Linux packages were being used instead of the way things are now.

    "Oh please oh please distro company ZYX, package this new game that just came out for meeeeeeeee, it has this awesome feature XYZ!"

    "NO! We won't! If you want it, reformat your computer and install this other distro, they have it! Or, wait until the new version of our distro comes out, maybe by then it'll be available for you! Mwuhahahaha!"

    OK maybe not the mwuhahaha part, was added for dramatic effect, but you get the point. They're not the ones who should be in control, the original devs should be in control, and if they are being poofaces for whatever reason, the project can be forked or someone else can package it and/or rename it or whatever is needed.

    Any way, all software developers should demand a universal Linux package format, and help push for it, a format that existing managers are going to want to adopt. Then hopefully in the future, the universal packages will replace the proprietary stupid old-way-of-doing-things packages.

    Comment


    • #32
      I see no new major packages in karmic at all. I basically only look at: virtualbox-ose and squashfs-tools because i would like to backport the first to kanotix (only a simple change that would install the guest addons there) and squashfs-tools 4 is needed for kernel 2.6.29+ - so without they will not build any live images. You see directly what status live images have got for U development...

      Comment


      • #33
        You're advocating an universal package format, and demanding that every open source dev create packages for that format. Don't you think that increases their workload, hm?

        Say you wrote a nice utility in 1999 that is still used. Something like xsri. How would you react if, as a result of this move, you'd start getting *cough*spam*cough* hundreds of requests to create a package for this format X, because they somehow think it's *your* responsibility.

        And that's just one example. It's not the devs' responsibility at all, and it should not be. Also, if I read your post right, you want packages to be downloaded all from the original source. Thus upping bandwidth requirements, losing all the convenience of package managers, and finally, it's the Windows model.

        Comment


        • #34
          Originally posted by krazy View Post
          I think you'll find it's the other way around. Ever read the nv driver code?
          Since when is the nv driver code closed?

          Other way round again I think. Taking the nvidia driver for example, instead of contributing to an open acceleration architecture in X such as EXA or UXA, they went and implemented their own proprietary solution.
          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.

          Bullshit. Provide a link to this "Fuck you" quote.
          The quote was to relay the general attitude that closed sourced developers, not a direct quote from a mailing list. (although it has been used in several private emails) get when trying to add support for any device specific items that involve a closed source driver. This has been seen many times over the past in the kernel and xorg for example:

          http://lists.freedesktop.org/archive...ly/037098.html
          http://www.phoronix.com/scan.php?pag...item&px=NzE1Mw

          In fact, if it wasn't for Linus keeping a sane head on him a lot of the kernel devs would outright lock out closed source drivers if they had their way. You can read a crap load of attempts by kernel devs to sway Linus in this direction.

          Perhaps Greg KH relayed this best with his

          We, the undersigned Linux kernel developers, consider any closed-source Linux kernel module or driver to be harmful and undesirable. We have repeatedly found them to be detrimental to Linux users, businesses and the greater Linux ecosystem. Such modules negate the openness, stability, flexibility and maintainability of the Linux development model and shut their users off from the expertise of the Linux community. Vendors that provide closed-source kernel modules force their customers to give up key Linux advantages or choose new vendors. Therefore, in order to take full advantage of the cost savings and shared support benefits open source has to offer, we urge vendors to adopt a policy of supporting their customers on Linux with open-source kernel code.
          We speak only for ourselves, and not for any company we might work for today, have in the past or will in the future.
          Then there are items like this from a sane Linus:

          http://kerneltrap.org/mailarchive/li...7/10/10/334625
          Well, I've talked to various people, and none of the main kernel people
          end up being at all interested in a kernel that has external dependencies
          on binary blobs for tuners.

          So right now it seems like while I would personally want to have more
          vendors supprt their own drivers, if that in this case means that we'd
          have to have user-space and unmaintainable binaries to tune the cards,
          everybody seems to hate that idea.

          As such, the old and decrepit em28xx driver seems more useful to people,
          since at least it supports the limited set of hardware on its own.
          Closed source developers get amazing support when they decide to reach out to the open source community. For example, how else has there been such rapid support for VDPAU provided in Xine, MPlayer, VLC, FFmpeg and others? It was only announced in November last year!
          Now VDPAU isn't closed is it?
          Last edited by deanjo; 05-18-2009, 09:42 AM.

          Comment


          • #35
            Now VDPAU isn't closed is it?
            I don't see VDPAU in Intel, AMD, nv, nouveau drivers..

            Comment


            • #36
              Originally posted by curaga View Post
              I don't see VDPAU in Intel, AMD, nv, nouveau drivers..
              There is nothing that is stopping other drivers from incorporating VDPAU into their own drivers.

              Comment


              • #37
                Originally posted by curaga View Post
                You're advocating an universal package format, and demanding that every open source dev create packages for that format. Don't you think that increases their workload, hm?
                Might respond to the rest later, but, that was just an asinine response and I have to comment..

                No, I expect Linux developers to want users to download and use the software they write. If they didn't want users using it, they shouldn't have released it to begin with. Since they apparently do, of course they want to release it in a universally accessible format which is also easy to install. They should only have to release it in this format, and nothing else.

                If I were a developer, I'd be releasing the source code, as required by law any way under my license, as well as a binary inside a universally supported package which actually integrates into the OS better than any straight binaries or installers ever could or will. Those packages are what everyone should be supporting, you know, actual important Linux standards for everybody, instead of proprietary garbage that only helps a select few.

                Comment


                • #38
                  I guess the over-arching question is "what is the business model if there's only one Linux rather than a bunch of distros" ? Right now a good chunk of the common Linux work is done by developers working for major distros; how do those companies continue to succeed and continue funding Linux development ? Selling support contracts can be part of the solution but I don't think they're a complete solution.

                  I think most of the participants understand the drawbacks of the current model, but AFAICS maintaining a bit of proprietary differentiation is an important part of funding the ongoing work, even if the source code for that proprietary work is freely available.

                  Comment


                  • #39
                    Originally posted by deanjo View Post
                    Since when is the nv driver code closed?
                    It's not, I'm saying that it is deliberately obfuscated.

                    Originally posted by deanjo View Post
                    You will NEVER get the stubborn opensource community to be co-operative with closed source drivers. When it comes to that stuff they are extremely pig headed. Proprose such a thing and they will cry "We can't fix their crap, screw them." Closed sourced developers have tried to get a bit of help in area's to ensure compatibility instead they are greated with "Fuck you". Nvidia has accepted that and they don't expect any help from the X community at all anymore.
                    Originally posted by krazy View Post
                    Other way round again I think. Taking the nvidia driver for example, instead of contributing to an open acceleration architecture in X such as EXA or UXA, they went and implemented their own proprietary solution.
                    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.
                    So, paraphrasing: "We can't fix their crap, screw them." ?

                    Originally posted by deanjo View Post
                    The quote was to relay the general attitude that closed sourced developers, not a direct quote from a mailing list.
                    Your quotes all relate to binary blobs which are impossible to properly support. There is an open offer of help to hardware companies for linux support. See here.
                    Originally posted by deanjo View Post
                    Now VDPAU isn't closed is it?
                    Nope, and thanks to that the "closed-minded" open source devs have provided support in most of the major linux video solutions.

                    Comment


                    • #40
                      Originally posted by krazy View Post
                      It's not, I'm saying that it is deliberately obfuscated.


                      So, paraphrasing: "We can't fix their crap, screw them." ?


                      Your quotes all relate to binary blobs which are impossible to properly support. There is an open offer of help to hardware companies for linux support. See here.

                      Nope, and thanks to that the "closed-minded" open source devs have provided support in most of the major linux video solutions.
                      Did you even bother actually reading my initial comment? Seems you are arguing the exact same thing now.

                      You will NEVER get the stubborn opensource community to be co-operative with closed source drivers.
                      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.
                      Last edited by deanjo; 05-18-2009, 02:24 PM.

                      Comment


                      • #41
                        Originally posted by bridgman View Post
                        I guess the over-arching question is "what is the business model if there's only one Linux rather than a bunch of distros" ? Right now a good chunk of the common Linux work is done by developers working for major distros; how do those companies continue to succeed and continue funding Linux development ? Selling support contracts can be part of the solution but I don't think they're a complete solution.

                        I think most of the participants understand the drawbacks of the current model, but AFAICS maintaining a bit of proprietary differentiation is an important part of funding the ongoing work, even if the source code for that proprietary work is freely available.
                        So the logic is thus:

                        1) Without proprietary packages, distros wouldn't be very unique since the packaging system is much of how they differentiate themselves from others, except for the support, several software projects that they are the main directors of, and their unique "starter bundle"/iso of Linux software which may be a good starting point for many Linux users wanting to get up and running quickly with a certain set of basic software.

                        2) Getting rid of proprietary software packaging leaves you with everything else aside from the first thing.

                        3) They're quite possibly clinging to proprietary package management then as a way to be more unique.

                        Which comes at the cost of: fragmenting the Linux community, making it difficult for developers to supply Linux software for others to use, making it difficult for device manufacturers to supply easily installable drivers on CDs shipped with their products, and heavily reducing the sharing of software between Linux users.

                        Yahoo IM User: "Here, try out this cool program!"
                        AIM User: "OK! Wait, it's not in my repository, they haven't packaged it yet..."
                        Yahoo IM User: "OK, here's the package I have!"
                        AIM User: "Oh...my system can't read these kinds of packages." OR "It's not installing correctly...says that the dependencies can't be met."
                        MSN User: "Haha, I'm on Windows, basically all software packages can be shared easily."
                        Other two: *grumble*

                        If what you say, and I also hypothesis, is true, then I'm their enemy. Creating packages that are proprietary is selfish, and I and everyone else should only support packaging solutions which will grant free and open access to anyone using a package manager that adopts the open format(s). Companies pushing things to be proprietary in order to force, what do they call it...their "stream", to force everyone to have to come to them for everything? Yeah, that. That goes against everything that made the Free Software Movement great. Lock-in is exactly what Linux users are trying to escape from, so aiding an environment of lock-in and proprietary packaging for Linux is just flat out wrong.

                        Comment


                        • #42
                          Honestly I don't know enough about the pros and cons of various package managers to know if the package manager itself is an important part of distro differentiation. I suspect that it is not. Distros are mostly concerned with "delivering a complete solution" and choose the components & tools which they feel best meet their needs.

                          The primary reason for each distro staying with its current packaging systems is probably nothing more than the high cost of changing and the fact that the groups which would have to fund the work would probably be hurt more than helped. Nobody likes it when companies put their own priorities ahead of the greater good, but (a) there is usually a lot of overlap between company priorities and user priorities, and (b) we do still expect companies to fund most of the work, so we either need solutions that allow those companies to continue to prosper or we need to find another way to get the work funded.

                          My point was more that with our current understanding of business models there is probably a need to maintain some differentiation between distros rather than throwing everything completely into a common "Linux" pot. The current model is inefficient but it's the best anyone has come up with so far; there *are* barriers but they are soft and permeable; source code is there for anyone willing to pick it up and make use of it, but that requires enough time and effort that there can be some commercial payback to justify funding development in the first place.

                          I'm not trying to discourage you here; quite the opposite. In the grand scheme of things both the free software movement and what we call modern civilization are both relatively young and everyone is still learning. The fact that we have a workable system today doesn't mean things can't change or improve, but 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.
                          Last edited by bridgman; 05-18-2009, 03:13 PM.

                          Comment


                          • #43
                            The buildpkg option is nice, but the current kernel support is crap, if i had to decide which i would prefer it would be current kernel support.

                            Comment


                            • #44
                              Might respond to the rest later, but, that was just an asinine response and I have to comment..

                              No, I expect Linux developers to want users to download and use the software they write. If they didn't want users using it, they shouldn't have released it to begin with. Since they apparently do, of course they want to release it in a universally accessible format which is also easy to install. They should only have to release it in this format, and nothing else.

                              If I were a developer, I'd be releasing the source code, as required by law any way under my license, as well as a binary inside a universally supported package which actually integrates into the OS better than any straight binaries or installers ever could or will. Those packages are what everyone should be supporting, you know, actual important Linux standards for everybody, instead of proprietary garbage that only helps a select few.
                              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.

                              Comment


                              • #45
                                Sourcecode is definitely the best way for Linux, maybe a beginner does not understand this. Some projects provide also deb or rpm packages, but without diff.gz/dsc for deb or spec files for rpm they do not help much. checkinstall is able to create those too but thats not reuseable. So the best would be certainly if somebody from the project would be the distro maintainer of that package. If a package is not binary compatible then you can just recompile it if build-deps are met.

                                For commerical apps which are usually not provided as source the generation of a binary which runs on most systems is of course more problematic, but not impossible, maybe Svartalf could provide you with more infos about that. Basically you have to compile your app against a pretty old glibc and provide all used libs with it. LD_LIBRARY_PATH in a startup file will do the rest.

                                Comment

                                Working...
                                X