Ubuntu 9.10 Off To A Great Performance Start

[Yfrwlf]

Awesome.

Hopefully AMD will have either closed or open source driver support for my 4850 X2 under newer versions of Linux by then including for 2.6.28 (Jaunty). :X

Whatever happened to the "same day support" stuff. :P

[bridgman]

Same day support with Catalyst drivers was for new GPUs, not for new OS versions.

For new kernel / X / distro versions we said that we expected gradual reduction of the time from new kernel/server/distro availability to Catalyst support, although our first priority will still be the enterprise distros most of our customers use.

Support for 9.04 is currently at "early look" stage per the release notes, ie it runs but has not been through a full engineering/QA pass. I don't think we have been able to repro the X2 problems on our systems yet, so accumulating good information in a Bugzilla ticket (one, not many) will help the developers. I took a look through the Bugzilla system and didn't see *any* applicable tickets, so creating one would be a good start.

This appears to be a regression related to Jaunty but even that info is not 100% consistent, so accurate info about "works with this combionation, doesn't work with that combination" will help.

[Yfrwlf]

Same day support with Catalyst drivers was for new GPUs, not for new OS versions.

OK, I'll certainly give you that, and Ubuntu even had a notice saying that upgrading to the newer version would break your closed source graphics drivers.

However, while it is impossible to track what random devs are rolling out, a new X server isn't really random and is what AMD needs to be tracking any way. Hopefully things will be a lot better and easier with Gallium3D, but it just would have been nice to see better communication and tracking in this situation between AMD and X Server 1.6, but I guess you sort of address that in the next comment...

For new kernel / X / distro versions we said that we expected gradual reduction of the time from new kernel/server/distro availability to Catalyst support, although our first priority will still be the enterprise distros most of our customers use.

What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.

Support for 9.04 is currently at "early look" stage per the release notes, ie it runs but has not been through a full engineering/QA pass. I don't think we have been able to repro the X2 problems on our systems yet, so accumulating good information in a Bugzilla ticket (one, not many) will help the developers. I took a look through the Bugzilla system and didn't see *any* applicable tickets, so creating one would be a good start.

In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.

I've created and added to bugs about this issue on Launchpad, which is a fairly nice bug tracking system that I like, but I'm sure there are many others. I haven't created any bugs anywhere else yet like for X Server or whatnot.

This appears to be a regression related to Jaunty but even that info is not 100% consistent, so accurate info about "works with this combionation, doesn't work with that combination" will help.

Yep, I've filed bugs already, thanks for the suggestion though.

[deanjo]

What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.

Won't happen, with linux you have too many distro's with differing POV's. They have tried standardization, it's called the LSB, but again you have a bunch of pig headed people in the distro's that seem to see that as a "infringement of freedom of choice" and let politics such as community developed vs corp developed distros inpeed the much needed standardization of key base foundations. Anybody remember United Linux and how it failed?

In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.

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.

[SolidSteel144]

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.

[krazy]

What is needed is tracking of X, and standardisation among distros, for both the open and closed drivers. Linux users shouldn't have to worry about what distro they are running, nor should AMD, because there should be standards in place to allow for universal easy Linux driver installation. I hope AMD is helping to push for that, maybe even help plan/program such a thing to help it come to pass faster. Partnering with other companies to get this done would of course be best.

There is already a standard in place allowing for "universal easy Linux driver installation". It's called "open source code".
Unfortunately with closed-source drivers such as fglrx, only the vendor has the ability to get the driver tracking the evolving X APIs. This is why the open source radeon/radeonhd drivers already work with the new X server.

In other words, to continue from what I said above, it shouldn't be AMD's problem to fix a distro, it should be that distro's problem to correctly follow the standards and protocols the community brings to bare. AMD should only have to follow standards and help push for better ones. Track Xorg and the kernel and any other important APIs your driver needs to correctly interface with or whatnot, and be done with it.

Nope. It's the distro's job to package the software for easy installation (and to develop packaging tools etc.).
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.

[krazy]

You will NEVER get the stubborn opensource community to be co-operative with closed source drivers.

I think you'll find it's the other way around. Ever read the nv driver code?

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."

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.

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.

Bullshit. Provide a link to this "Fuck you" quote.
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!

[bugmenot]

I'm intrested in the boot time of the new ubuntu alpha. Fastboot(async hardware probing) from the Intel Moblin project is enabled by default from kernel 2.6.30. This would in theory speed up the bootup process. I'm curious for real life examples.

[kraftman]

Bullshit. Provide a link to this "Fuck you" quote.
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!

Exactly. Guess who helps nvidia making their installer? OS community

[Yfrwlf]

Won't happen, with linux you have too many distro's with differing POV's. They have tried standardization, it's called the LSB, but again you have a bunch of pig headed people in the distro's that seem to see that as a "infringement of freedom of choice" and let politics such as community developed vs corp developed distros inpeed the much needed standardization of key base foundations. Anybody remember United Linux and how it failed?

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.

That's extremely hurtful to all who are involved with Linux. A lack of standards hurts everyone, including open source programs as well, as constant recompilation shouldn't be required and isn't something normal users can do, the ones that Linux is trying to target now for it to ever be popular on the desktop.

Linux should be all about standards, it's ironic that standards are pushed heavily in other areas, and that lock-in is looked down upon, yet in critical areas like package management, the lack of standards is awful and heavily impedes everyone's freedoms, yet it's perfectly OK?

You know what I think, is that distros and the companies behind them don't want a Linux program to be a Linux program, they don't want to respect the developers and use the code as they intended it and rename the program to something else if they change it, they want to keep Linux a moving target and keep package management proprietary to their versions of their own "distro". The problem is, if you could just go download *Firefox*, and it would be *Firefox from Mozilla*, or if you downloaded Xorg, and it would be the original thing from those devs, if all Linux software was clearly labeled with packages that had clear dependencies on the *original* versions of other programs, what would that mean?

Distros would die. Those companies would die with them unless they focused on their other ways of making money. There would no longer need to be a "distro" because it would all be Linux, and no one would have to beg a distro for a repository so they could install software. Instead they could go directly to the source, the devs/community, or use any one of a billion different Linux software mirrors that *anyone* can use regardless of what they were running as long as it was Linux.

Diversity is good, competition is great, and the various differences in Linux ARE good, don't get me wrong. What is bad is when things aren't labeled, when the sources for software aren't respected, so as to keep everyone on the same page and to give the software projects that are most widely used their appropriate light and attention from the community. Those individual software projects should be the focus of the community, NOT a distro, like they're so special when all they did was compile what some dev's offered just because of the refusal to
make a universal Linux packaging system/format.

There is already a standard in place allowing for "universal easy Linux driver installation". It's called "open source code".

You point out something important here, which is that traditionally a lot of the modularity in Linux allowing for compatibility and interoperability has been implemented on the source code level. I understand that. However, that way sucks, because it would mean users have to *compile* to get that compatibility. If Linux is going to be a desktop OS for normal users, while having complete freedom to install what they want, this can't stand.

For now, this is what will have to happen to solve this problem as far as I can figure:

1) Programs which are very modular need to work on creating an ABI for their core system, if possible and if it is felt necessary, meaning plugins. Lets take imagemagick as an example:
a) core imagemagick program - the core bit that everyone will use, and should not be modified. If it is, like with any program, a different name for the program should be used.
b) jpg support - should be a module, if the intention is to cut down on size, etc
c) png support - etc
2) Because of the fact that space isn't so much an issue any more with computers these days, the developers may choose to wrap nearly all or all of their library into one big package. Either way, have a clear naming convention so that other packages can correctly call upon your program's name and version number if it's a dependency.
3) Package your software using at least one universal Linux packaging format so that ALL Linux users, not just Ubuntu users, will have access to your software. Help create a universal packaging format/API/ABI/whatever that all packaging managers can adopt if needs be. Don't release your code for a proprietary system, demand standards so everyone can be free to use it.

IMO, as I said before, I blame the distro companies for not wanting this to happen, otherwise they lose some of the power and uniqueness that many of them currently have. The solution for these companies is to:

1) Be a support company for Linux as a whole.
2) Be a development/bounty company for Linux as a whole.
3) Get your "own" software project(s) and back it/them, or in other words provide specialised and focused development and support of one or more software projects, like so many other companies do.
4) Kill the term "distro", and instead provide your images as they were intended: as "just another specific selection of Linux software that we like to have as our base OS installation, but feel free to easily install software from any repository or any website to add to it, as we support Linux packaging standards so you can do that".

Linux can either continue jailing it's users who don't know how to compile, or it can get in gear with the 21st Century, and provide real freedom by simply respecting the community and it's developers and users and getting a system together for real software sharing.

Nope. It's the distro's job to package the software for easy installation (and to develop packaging tools etc.).

Who are you, the Linux software foreman? I know how it works now, believe me, and I'm saying that the way it works now sucks. Linux will remain fragmented if things stay that way. "Sorry, you have to reinstall this different Linux OS if you want this software, because it's not in the repositories." How many times have you wanted, say, a newer version of OOo, or to try out a newer Xorg, or a newer <insert program here>, but couldn't because they only offered source code? Maybe you're totally OK because you love spending all your time searching for dependencies so you can spend all your electricity re-compiling programs that should have only needed to be compiled once by the actual developers of the programs or for anyone interested in software development?

The way Linux is now sucks, and if you want to support freedom for desktop users, or any users that don't want to bother with compiling software like I do, then you will support a unified package format and for it to be adopted by the current popular package managers. I want Linux to grow exponentially, not be artificially be walled off from one another, unable to easily share programs with each other and for dev's to share programs with the community, just because some retarded companies refuse to help the community make some real standards for packaging and adopt them out of fear that they won't be relevant any more if no one is forced to come to them begging for software that should be easily freely available directly from the real devs.

Oh, and btw, you don't even need to bother with a "no this feature is not needed!" response, because if you want to continue compiling your own programs, be my guest. Linux needs to continue to be an environment that makes compilation easy, even a lot easier than it is now, to help spur Linux software development. But, this feature would in no way prohibit you from doing so. This would be a *feature* that should be added. There is no harm in that. This whole system causes nothing but frustrations for not only end users, but developers, especially when distro #73258 user #3 comes crawling to them with a bug that is completely not their fault because this distro modified their program without renaming it and introduced bugs into it.