Are AMD HD video card users all using older versions of GNU/Linux?

[Yfrwlf]

I was just wondering what everyone was doing, since my 4850x2 won't run in Jaunty with the fglrx driver, and while the ati driver gives me something which is great, it doesn't give me my correct maximum resolution on my Samsung SyncMaster T260, and of course will not give me 3D support.

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved? So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

Thanks. :)

[deanjo]

I was just wondering what everyone was doing, since my 4850x2 won't run in Jaunty with the fglrx driver, and while the ati driver gives me something which is great, it doesn't give me my correct maximum resolution on my Samsung SyncMaster T260, and of course will not give me 3D support.

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved? So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

Thanks. :)

How are you connected to your T260? HDMI, Analog or DVI-I? I ask because the Samsung T2x0 series has broken DCC when plugged into the HDMI. Maybe post your xorg.conf here for us to see.

[bridgman]

Are users of the 4xxx and possibly 3xxx (and lower?) AMD cards using older versions of Linux until AMD gets these issues solved?

There seems to be an issue specific to X2 boards and Jaunty. Don't think we've been able to repro it in house which is why we're asking for users to accumulate their findings (particularly regression info) in a Bugzilla ticket.

So much for the same day support promise. :/ Anyone tried Karmic Koala? Probably wouldn't work on that either tho...

"Same day support" in the Linux Catalyst drivers was for new hardware, not for new distros / kernels / X servers.

The open source drivers will normally give very quick support on new kernels and X servers since they are part of those source trees and are often used by the developers who are making changes to the underlying framework.

[lordmozilla]

well i'm using radeonHD on jaunty on my hd4850. To be honest I'm really happy with it. I dont run compiz anyways, the only thing i like is to run AOE in vmware to lan with friends and red alert 2. That works fine. So i'm happy!

Fglrx 9.5 is out now? or so i read so maybe that fixes most issues with 9.4 on jaunty

[Yfrwlf]

How are you connected to your T260? HDMI, Analog or DVI-I? I ask because the Samsung T2x0 series has broken DCC when plugged into the HDMI. Maybe post your xorg.conf here for us to see.

No I'm using DVI/digital, and the ati driver is seeing 1600x1200 instead of 1920x1200. Installing the fglrx driver provided by the distro's repository breaks my system. I haven't tried the one from AMD's site since last time that broke my system as well.

and, sure thing, just a generic skimpy "automatic" xorg tho..

----------------------
Section "Device"
Identifier "Configured Video Device"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

[Yfrwlf]

There seems to be an issue specific to X2 boards and Jaunty. Don't think we've been able to repro it in house which is why we're asking for users to accumulate their findings (particularly regression info) in a Bugzilla ticket.

The Ubuntu dev's say it's a problem specific to AMD, and AMD dev's say it's a problem specific to Ubuntu. Gotta love it.

If it is a problem caused by something wrong that Ubuntu is doing, they need to fix it, agreed. I'll try a different "distro" then I guess. Wish I could simply download Xorg myself though, then I'd know nothing would be screwed up. Would really be helpful if everyone stayed on the same page as one another.

"Same day support" in the Linux Catalyst drivers was for new hardware, not for new distros / kernels / X servers.

OK. But since the kernel and Xorg are the two (main?) things that should be tracked, maybe tracking them closer would be nicer for the users that are closer to the bleeding edge is all. :)

Perhaps more standards are needed though, so that close tracking won't be so needed. Perhaps Gallium3D will help with that.

The open source drivers will normally give very quick support on new kernels and X servers since they are part of those source trees and are often used by the developers who are making changes to the underlying framework.

And again, perhaps better communication and APIs/standards/etc are needed to solve this problem, so that we'll have less broken drivers for all, less headaches for all, and more Linux goodness.

[Yfrwlf]

well i'm using radeonHD on jaunty on my hd4850. To be honest I'm really happy with it. I dont run compiz anyways, the only thing i like is to run AOE in vmware to lan with friends and red alert 2. That works fine. So i'm happy!

Fglrx 9.5 is out now? or so i read so maybe that fixes most issues with 9.4 on jaunty

RadeonHD has 3D support for hd4850 that is good enough to play 3D games with through VMWare? That's pretty amazing if so, I'll give it a try, thanks.

[bridgman]

The Ubuntu dev's say it's a problem specific to AMD, and AMD dev's say it's a problem specific to Ubuntu. Gotta love it.

You might be talking about a different problem. I'm saying "the problem with X2 boards seems to happen on Jaunty but not on Intrepid, however since we haven't seen it on any of our systems yet we don't know what the root cause is".

If it is a problem caused by something wrong that Ubuntu is doing, they need to fix it, agreed. I'll try a different "distro" then I guess. Wish I could simply download Xorg myself though, then I'd know nothing would be screwed up. Would really be helpful if everyone stayed on the same page as one another.

Do you have an X2 card ? If not, then I don't think this issue applies to you anyways.

Staying on one page is tricky when there are so many distros each with different combinations and patches; metaprojects like xorg help but unfortunately xorg doesn't include DRI and that's where most of the rapid change (and the kernel impact) takes place.

OK. But since the kernel and Xorg are the two (main?) things that should be tracked, maybe tracking them closer would be nicer for the users that are closer to the bleeding edge is all. :)

We do intend to shorten the gap between new kernel/xorg release and fglrx support over time. The open source drivers will always have an advantage there, however.

Perhaps more standards are needed though, so that close tracking won't be so needed. Perhaps Gallium3D will help with that. And again, perhaps better communication and APIs/standards/etc are needed to solve this problem, so that we'll have less broken drivers for all, less headaches for all, and more Linux goodness.

I don't know if this will ever get really easy for binary drivers; in a sense you could say that the challenge is rooted in the standards. One of the things that lets Linux evolve quickly is a willingess to replace kernel APIs more rapidly than most OSes if the change is deemed to be worthwile overall. Right now I think the major issue is priorities; once we support the core set of distros we are generally prioritizing the addition of most-requested features over support for bleeding-edge kernels and distros. I'm hoping the demand for additional features will drop off with time, allowing us to spend relatively more effort on support for new kernel and xorg versions.

[lordmozilla]

RadeonHD has 3D support for hd4850 that is good enough to play 3D games with through VMWare? That's pretty amazing if so, I'll give it a try, thanks.

Uhm watch it at 3d support. It only works with AOE and red alert cause they arent actually 3d games.

Compositing wont work though!

[Yfrwlf]

You might be talking about a different problem. I'm saying "the problem with X2 boards seems to happen on Jaunty but not on Intrepid, however since we haven't seen it on any of our systems yet we don't know what the root cause is".

Perhaps, and hopefully that just means Xorg 1.6 in comparison to the version Intrepid uses (1.5?), because there were issues with fglrx working on the new 1.6 X Server apparently.

Do you have an X2 card ? If not, then I don't think this issue applies to you anyways.

Oookay...not that it matters, because if it's an issue, then it's an issue, but yes, I do have one, so it does directly effect me.

Staying on one page is tricky when there are so many distros each with different combinations and patches; metaprojects like xorg help but unfortunately xorg doesn't include DRI and that's where most of the rapid change (and the kernel impact) takes place.

"Tricky" means it's not as grown up and unified as it should be then, yes. Xorg development needs to get it's act together with a tight, unified development line, similar perhaps to kernel development or <insert tight software development project name here>, and since DRI is closely involved then of course the community and/or software is going to have to somehow adjust for that. What I mean is that perhaps if the kernel used better standards, maybe less kernel developers would need to be involved, etc.

I hope things improve in the future, is all I'm saying...

We do intend to shorten the gap between new kernel/xorg release and fglrx support over time. The open source drivers will always have an advantage there, however.

Which you could say, IMO, is a failing on several different levels or simply the system as a whole, but ultimately having a driver which is friendlier to open source will be tested by open source developers more. I hope AMD has plans to either dump it's proprietary driver and focus on open driver(s), or open up the proprietary driver. But again I'm sure there are other things that would help the process as well.

I don't know if this will ever get really easy for binary drivers; in a sense you could say that the challenge is rooted in the standards. One of the things that lets Linux evolve quickly is a willingess to replace kernel APIs more rapidly than most OSes if the change is deemed to be worthwile overall. Right now I think the major issue is priorities; once we support the core set of distros we are generally prioritizing the addition of most-requested features over support for bleeding-edge kernels and distros. I'm hoping the demand for additional features will drop off with time, allowing us to spend relatively more effort on support for new kernel and xorg versions.

Well thought out and implemented standards shouldn't require a complete overhaul every day, instead having APIs that are as stable as OpenGL for instance would be really wonderful, a lesson the kernel should take note of regarding all of it's drivers. Supporting specific distros shouldn't be needed, only the core programs like Xorg and the kernel IMO. You'll never be able to release Linux drivers on CDs, for example, if this doesn't change, which you need to do because not all kernels out there are the same version. Stability of the APIs and better planning would mean you could release a simple driver that worked across a wide range of kernels. If packaging standards got their act together, drivers on a CD in case a user needed them, like if they *weren't* using a bleeding edge kernel, would become a reality and would really help out Linux users and companies alike.

I think Linux needs more leaders to organise and push for standards in general, and that doing so will solve a lot of the mess Linux faces right now.

[Yfrwlf]

Uhm watch it at 3d support. It only works with AOE and red alert cause they arent actually 3d games.

Compositing wont work though!

Oh, I thought they were, that won't work for me then, thanks for letting me know though before I tried it only to be disappointed. :)

[bridgman]

Supporting specific distros shouldn't be needed, only the core programs like Xorg and the kernel IMO. You'll never be able to release Linux drivers on CDs, for example, if this doesn't change, which you need to do because not all kernels out there are the same version. Stability of the APIs and better planning would mean you could release a simple driver that worked across a wide range of kernels. If packaging standards got their act together, drivers on a CD in case a user needed them, like if they *weren't* using a bleeding edge kernel, would become a reality and would really help out Linux users and companies alike.


I think we already have this covered in principle; the installer package includes open source scripts, different for each distro, maintained by people from the individual distros. During installation, the kernel dependent portions of the driver are compiled using the kernel header files on the user's system.

There are a number of distros which don't use standard kernel versions, and it's not unusual for a distro to ship kernel code which won't be upstream for another 3-6 months. Fedora is going through a phase like that right now.

I agree completely that increased standardization between distros would help in a number of areas, but I don't think the lack of standardization today is due to a lack of suitable standards. The developers and distros *want* change and *want* the ability to be different since that lets them deliver what they feel is the best experience for their specific user base. The kernel API changes frequently, not because the kernel devs don't know how to manage a stable API but because they made a deliberate decision to choose faster evolution over API stability. I believe there is agreement that application-level API stability is important but I don't think the same holds for driver-level stability.

In cases where a stable API is required there are enterprise/LTS distros available which *do* keep a standard kernel and xorg version for several years, backporting changes as needed to support their customers. These enterprise distros are the primary ones used in the professional workstation market, and that's where we have historically focused fglrx support as well.

There are some architectural changes in the works which will help the situation for Linux and open source drivers, specifically the movement of modesetting and memory management out of xorg and into the kernel driver (drm). This will allow the core graphics functions to evolve in lockstep with the kernel, which is good for bleeding edge distros but introduces new challenges for enterprise/LTS distros. This will also pose a challenge for other OSes which use X but do not use the Linux kernel, such as *BSD and Solaris.

[Yfrwlf]

I think we already have this covered in principle; the installer package includes open source scripts, different for each distro, maintained by people from the individual distros. During installation, the kernel dependent portions of the driver are compiled using the kernel header files on the user's system.

There are a number of distros which don't use standard kernel versions, and it's not unusual for a distro to ship kernel code which won't be upstream for another 3-6 months. Fedora is going through a phase like that right now.

I agree completely that increased standardization between distros would help in a number of areas, but I don't think the lack of standardization today is due to a lack of suitable standards. The developers and distros *want* change and *want* the ability to be different since that lets them deliver what they feel is the best experience for their specific user base. The kernel API changes frequently, not because the kernel devs don't know how to manage a stable API but because they made a deliberate decision to choose faster evolution over API stability. I believe there is agreement that application-level API stability is important but I don't think the same holds for driver-level stability.

In cases where a stable API is required there are enterprise/LTS distros available which *do* keep a standard kernel and xorg version for several years, backporting changes as needed to support their customers. These enterprise distros are the primary ones used in the professional workstation market, and that's where we have historically focused fglrx support as well.

There are some architectural changes in the works which will help the situation for Linux and open source drivers, specifically the movement of modesetting and memory management out of xorg and into the kernel driver (drm). This will allow the core graphics functions to evolve in lockstep with the kernel, which is good for bleeding edge distros but introduces new challenges for enterprise/LTS distros. This will also pose a challenge for other OSes which use X but do not use the Linux kernel, such as *BSD and Solaris.

I believe that in every case, some sort of standard could be implemented which gave at least basic functionality and basic communication, so that no proprietary code is ever required. If developers seriously consciously have made such decisions to break things, I hope they realise how much pain they cause down the line from them, and how they've basically made Linux be "beta software". When will it have enough features that they will finally release a stable version then I wonder, if ever?

All this really takes the wind out of my sails for being excited about programming for Linux. I'm not releasing a proprietary package for it. Community software that can hardly manage to make any standards past a binary standard is just really sad to see. Can't even make a standard so that icons for programs get created properly in all desktop environments. Sad...just sad...I wish more Linux users would be conscious of the need for standards so that companies wouldn't be able to get away with making things proprietary just so they can get attention.

[bridgman]

Just curious, why do you feel the need to create a proprietary package ? We have to because we're releasing the code in mostly binary form, but if you're releasing source then the distros recognize that they need to help with making your product fit into their package. My experience has been that they generally do this very well.

[yesterday]

Firstly, we should stop talking about Linux as a product or an operating system. Each distribution is an operating system, which uses a number of open source technologies.

Moving to another distro means moving to another OS. E.g. Fedora.

Similarly, if you want stable APIs and less structural change, chose an enterprise OS with long term support. Or choose a distribution known for conservatism. E.g. Slackware or Debian stable. Choosing Ubuntu or Fedora expecting such is silly.
Expecting these different products to just stick to each other is also silly. I want the bleeding edge of Fedora, but someone else wants the conservatism and vanilla packaging of Slackware. Should Slackware or Fedora change their philosophy just to meet some mandated homogeneity?

Secondly, it's odd you use OpenGL as something that the kernel guys should aspire to. It seems kernel hacking is as healthy as ever, and most companies involved in Linux are involved in the kernel space. OpenGL on the otherhand is about as stagnant as Duke Nukem Forever.

Standards aren't some magic cure-all. In the case of Linux you have many different companies offering many different (but similar) products. Then you have disparate products that other companies participate in. In such an environment, it's difficult to decide who creates or maintains the architectural standards. LSB is a pretty decent example. The other problem with standards is that they take a long time to solidify, and a short time to become outdated. Imagine if we had ratified TTM for the next five years, and then got stuck with a memory manager that wasn't adequate. The great strengths of Linux-based systems are flexibility and a willingness to break things "when necessary". We can argue all day about necessity, but I feel this is what allows Linux to be the most "current" of open source kernels. Most heavily governed projects suffer a high rate of developer attrition, e.g. old Solaris or MySQL. FreeBSD are doing OK but being highly centralised but also quite conservative.

Of course, it would be nice to have more coordination, but I think the current method of having a flexible environment and coordinating when necessary works much better than a overly homogenised system where we spend more time worrying about standards than technology.

[blindfrog]

One thing that bothers me with this not supporting anything bleeding edge is that well nvidia does or atleast their drivers work for example with fedora 11 that Im running. It worked with very unstable (f11) rawhide couple of months ago and it probably will work very soon with (f12)rawhide (from rpmfusion repos) nvidia drivers are always in rpmfusion but amd's keeps dropping very unpredictable, because it seems that they just keeps breaking if the distro isn't any RHEL, SLE* or *buntu.

It seems their way of doing things on "top of the stack" than
amd's "next to" is frankly a lot better. I mean it's proprietary blob anyway! If you use it I doubt you really care how invasive it is as long as it works.

[blindfrog]

Oh btw being "forced" to run xorg-x11-drv-ati drivers since Fedora 11 upgrade the video playback with XV looks stunnig! Why are the colors with fglrx driver so "washed out" compared to this free driver? Also fglrx scaling seems broken (both works fine with gl though although a bit more cpu heavier).

[Yfrwlf]

Just curious, why do you feel the need to create a proprietary package ? We have to because we're releasing the code in mostly binary form, but if you're releasing source then the distros recognize that they need to help with making your product fit into their package. My experience has been that they generally do this very well.

I do believe I said that I wouldn't create a proprietary package, ever. Linux is already somewhat niche, and programming for a niche of a niche is just suicide and silly. Of course I want every Linux user to use my software, that's one of the entire points of what I'm trying to communicate. You should be able to release one package for Linux, and be done. Right now, that happens to be a plain archived binary, which isn't ideal. The only other solution is Zero Install, which I may choose to support as well or in place of the straight up binary. ZI seems to be the furthest along in improving the Great Linux Packaging Mess, but having a universal format adopted by the main package managers themselves would be best, nullifying the need for a second manager.

Source packages help interested developers to help with your project. Binaries help users and developers alike who actually want to quickly and easily run your project. I really don't understand why this is hard concept to grasp...it's completely obvious. Right now, Windows and Mac users enjoy easily installable binary packages. That's what Linux needs. It's a feature. Do users want to be able to select from software from a MUCH bigger repository for use in their cloud software browsers (Add/Remove, Synaptic Package Manager, etc etc) a.k.a. the entire Internet instead of being confined to a small private repository? Yes. Do they want to also be able to easily install software from websites directly as well? Yes. Do developers want to have to release ONE single package, and have that get used, so that all bugs reported to them are valid and not from some tinkered customised version? Yes. So, I want such a feature, and am thus pushing for it.

Firstly, we should stop talking about Linux as a product or an operating system. Each distribution is an operating system, which uses a number of open source technologies.

Moving to another distro means moving to another OS. E.g. Fedora.

That's the great lie they want to push on you, yes. Linux programs are Linux programs. The main difference between "distros" is they choose to use different package managers that aren't compatible with a universal Linux packaging standard. But no, it's not a "different OS". Binaries can be run on any Linux system because they're all compatible. The main thing that isn't compatible between Debian and Red Hat is their stupid package format difference just because they want to be unique and the companies supporting them want to dig their own proprietary trench in order to get converts to come over to their side (the point of being "proprietary" meaning lock-in). All that is needed is for the community to recognise this deeply impacting Linux issue as a major threat, and push for standards. The companies won't do it for Linux users and developers, because they don't want it.

Similarly, if you want stable APIs and less structural change, chose an enterprise OS with long term support. Or choose a distribution known for conservatism. E.g. Slackware or Debian stable. Choosing Ubuntu or Fedora expecting such is silly.
Expecting these different products to just stick to each other is also silly. I want the bleeding edge of Fedora, but someone else wants the conservatism and vanilla packaging of Slackware. Should Slackware or Fedora change their philosophy just to meet some mandated homogeneity?

They're called standards. A web browser uses HTML standards. A FTP client uses FTP standards. FreeDesktop.org, the Linux Foundation, and other groups help create standards so that when you're in KDE and you want to run a Gnome app, for example, you can still do so. It empowers Linux users to communicate on the same page at certain points. It does NOT hamper progress, because if someone feels that the standard needs to be broadened, it can be, so that new features can be added. What version of HTML are we up to now, five? OpenGL 3? Those are standards which are quite solid, and they help everyone.

Just imagine a world without any standards, where everyone did just go and do their own thing. Lets say there were 500 different website protocols for instance, instead of having everything built on HTML. Imagine trying to function in such a world, it would be horrible, bloated, confusing, and nothing would get done. Every web-based program would have to try to be compatible with all the craziness.

I'm in no way saying that there shouldn't be different approaches, and competition, for those things are good. However, with most things, there are definite areas which are similar, and those can be shared. Those are points at which standards should be adopted.

For example, lets say you have two different file manager programs. Do they use standards? Already, yes, they use a ton of standards, because they interface with files on a hard drive managed by file systems etc etc etc, and there are standards every step of the way, that's how computers are built, otherwise you'd be screwed with pineapples. As you move up the stack from hardware to software, you encounter several different standards along the way. So, for the file manager program itself, if you recognise that there are several common needs there, and can find a way to utilise a common standard or even a common library in order to work together with other similar projects, of course that's in your interest to do so.

If everyone had to re-invent the wheel for everything, NOTHING would EVER get done.

Secondly, it's odd you use OpenGL as something that the kernel guys should aspire to. It seems kernel hacking is as healthy as ever, and most companies involved in Linux are involved in the kernel space. OpenGL on the otherhand is about as stagnant as Duke Nukem Forever.

Maybe that's why D3D is becoming more popular recently, so I sure hope that OGL can compete properly and catch back up if it really is lacking like you accuse it of being.

But guess what? Let's say that OGL, a standard, changed it's points of communication, it's API, the actual part that is a standard, and implemented OGL 3, 4, 5, 6, 7, 8, 9, 10, etc, and "moved" like you say, and none of those versions happened to at all be compatible with any other version.

a) That would be retarded, because there's no reason for it to be completely incompatible like that when they all would use nearly the exact same things, so the stable parts should have a clear API, while the new OGL calls should be added on, and what do you know, that's the way it happens to work.

b) No one would use the "standard".

The reason why: because that's not a standard. You clearly need to understand what a standard is, and how to implement one so that it doesn't impede progress and development. That's what standards are for, is to not impede progress, but to allow just the communication part to occur.

Let me give you a quick example of that. HTML again. How many programs use it? Hmm lets see, Google Maps, Google Docs, Yahoo Mail, Slashdot, all sorts of different programs and content, all using the same standard! So wow, you can have diversity and competition while using standards that are quite static. Maybe OGL needs to get it's tail into gear, maybe that was a poor example, but hopefully by now you are getting some idea of the point of standards, because without them, none of the above mentioned web apps and sites would exist!

And the rest of your comment was more of the same so I'll leave it there. Ultimately this is the on-topic point: there is nothing stopping the creation and adoption of some universal intelligent Linux binary packaging systems, the only reason they don't exist is disinterest by distro companies to play nicely with competing companies because they use their repos as a lure to get users to come to them. It's completely pointless and fragments Linux where there is no reason to do so and in an area which is critical for simplifying binary deployment by closed and open source software projects alike.

For now we're stuck with crappy archive files for the most part, which aren't very user-friendly to install at all.

One thing that bothers me with this not supporting anything bleeding edge is that well nvidia does or atleast their drivers work for example with fedora 11 that Im running. It worked with very unstable (f11) rawhide couple of months ago and it probably will work very soon with (f12)rawhide (from rpmfusion repos) nvidia drivers are always in rpmfusion but amd's keeps dropping very unpredictable, because it seems that they just keeps breaking if the distro isn't any RHEL, SLE* or *buntu.

It seems their way of doing things on "top of the stack" than
amd's "next to" is frankly a lot better. I mean it's proprietary blob anyway! If you use it I doubt you really care how invasive it is as long as it works.

It doesn't even work on the major distros, that's one of the points of this thread. I had to downgrade to kernel 2.6.27 and xorg 1.5 (using the Ubuntu Intrepid software bunch) I assume it is since fglrx won't work in the newer versions yet with my 4850x2.

Yes, Nvidia has always had quick support of the latest stuff. AMD is smaller, so they're behind in the closed source driver, but ahead in the open one still AFAIK. However, the open one doesn't have 3D, so it's a deal breaker after you plop down $1400 for a new system expecting to play some high-end Linux or Wine games.

[energyman]

I am not using GNU/Linux.
I am using gentoo. And my card (HD3870) works fine.

[Ant P.]

(re: big post about stable kernel APIs somewhere up the thread)
That's a neat idea. You should post that on the LKML, I'd love to see the reaction.

[Yfrwlf]

I am not using GNU/Linux.
I am using gentoo. And my card (HD3870) works fine.

No, you're using the Linux kernel and the GNU programs which interoperate with the kernel.

(re: big post about stable kernel APIs somewhere up the thread)
That's a neat idea. You should post that on the LKML, I'd love to see the reaction.

You're right, APIs are a stupid idea, who's needs 'em, who uses 'em. Standards and actual interoperability is for n00bs, what was I thinking. Everyone should learn to compile and spend their lives doing it, instead of actually, you know, using the program.

The kernel devs will never agree, because they are funded by companies that want to control the code, instead of letting anyone be able to make a driver for it, and you know, consequently, allowing users to be able to easily install drivers from any source.

[yesterday]

That's the great lie they want to push on you, yes. Linux programs are Linux programs. The main difference between "distros" is they choose to use different package managers that aren't compatible with a universal Linux packaging standard. But no, it's not a "different OS". Binaries can be run on any Linux system because they're all compatible. The main thing that isn't compatible between Debian and Red Hat is their stupid package format difference just because they want to be unique and the companies supporting them want to dig their own proprietary trench in order to get converts to come over to their side (the point of being "proprietary" meaning lock-in). All that is needed is for the community to recognise this deeply impacting Linux issue as a major threat, and push for standards. The companies won't do it for Linux users and developers, because they don't want it.


It's not nearly as simplistic as you would like it to be. Firstly, binary compatibility doesn't mean jack. FreeBSD has a Linux binary compatibility, while Linux has binary compatibility for a number of different Unixes. ELF loading doesn't imply anything . Hey even Vista can run Win2000 binaries. Are they the same operating system?

There are a number of significant differences between Fedora and Debian stable, some being a much older kernel, a much older X version, and older libraries, and some libraries installed with different configurations and options. They even use different boot/init procedures. We're getting into fuzzy areas here, but I take a wholistic view of an operating system as a kernel, associated userspace tools, and base set of provided libraries and userspace applications. In this case Debian stable and Fedora are rather disparate. Fedora and RHEL5 even more so. There is no expectation that everything you want to even compile on Fedora would do so on Debian stable without some intervention, and good luck getting all your bells and whistles in Fedora working on RHEL5.

Even distributions with the same packaging system aren't necessarily compatible. Mandriva rpms don't necessarily work on Fedora boxes, and Ubuntu debs won't necessarily install on Debian boxes. Packaging standards, while useful, aren't the panacea that you believe it be. Even as it is, you can convert rpms to debs on a Debian platform.

In this sense, it makes sense to think of a distribution as an operating system because they each ship with different kernels (versions, patches etc), different userspace tools, different libraries, and different userspace applications. Sure, some may be compatible, some of the time. But that is hugely dependant on which ones you are comparing.

They're called standards. A web browser uses HTML standards. A FTP client uses FTP standards. FreeDesktop.org, the Linux Foundation, and other groups help create standards so that when you're in KDE and you want to run a Gnome app, for example, you can still do so. It empowers Linux users to communicate on the same page at certain points. It does NOT hamper progress, because if someone feels that the standard needs to be broadened, it can be, so that new features can be added. What version of HTML are we up to now, five? OpenGL 3? Those are standards which are quite solid, and they help everyone.

Just imagine a world without any standards, where everyone did just go and do their own thing. .....

Ok firstly, let me say I personally think of standards and stable/consistent APIs not necessarily one and the same different things. To me a standard is a collection interfaces and/or best practices maintained for the interests of interoperability.

HTML is a standard to allow interoperability between web-browsers.
OpenGL was presumably created to provide a way for programmers to speak to variety of different hardware devices in a uniform way.

In that sense, yes, I agree that things like package management and desktop integration should be standardised. These are domains where interoperability between packaging formats or desktops implementations are important.

I fail to see how standardisation would help the kernel though. A controlling group already sets it's direction. And what exactly does it need to interoperate with? Are you proposing some UNIX Kernel standard that requires all Unix kernels to be compatible with each other somehow? Or is this for device drivers only? Are you proposing a Unix Device Driver Standard? How realistic is this, and how neccessary? POSIX, for example, already provides a cross platform way to access various devices, so do we really need to further generalise the implementation?

Standards can add an unnecessary layer of fat to the development process. OpenGL is a pretty good example. It's a stagnant standard, and part of the trouble is its inertia. One of the problems facing OpenGL 2.0 was the maintaining backwards compatibility. This came a cost of implementing newer features, and was a pretty big disappointment to the OGL community. OpenGL 3.0 was promised to deliver some heavy improvements, but it was more of the same really. Maintaining a single framework to support legacy compatibility came at the cost of added features, performance, and usability, and OpenGL is all but relegated as the "cross-platform" option. D3D on the other hand, while not an official "standard" is almost a de-facto standard and has pretty much won the war, due to it's manoeuvrability and flexibility. People would get pissed of if OpenGL 4,5,6,7,8, and 9 changed the API every release, but they are currently pissed off that OpenGL 2 and 3 didn't change it enough.

Now, if you are commenting more on the stability between kernel versions I feel my point still stands. Yes, ideally, updated kernels shouldn't be continually changing interfaces, but sometimes this is neccessary. Maintaining legacy compatibility at the cost of significant architectural or performance improvements is pretty much the OpenGL trap. To be fair, I don't follow the driver side too much, but yes, I do remember when they updated the wireless stack, leaving me using flaky experimental drivers. That being said, I don't the kernel guys are anti-standard or anti-interface stability layer at all. AFAIK they are pretty POSIX-friendly (look at the ext4 discussions) and layers like the VFS are pretty stable (cue Rieser4 flames). And from what I understand, the stuff happening now with in-kernel graphics drivers will also provide a more standard way for other display servers to access graphics hardware.

It doesn't even work on the major distros, that's one of the points of this thread. I had to downgrade to kernel 2.6.27 and xorg 1.5 (using the Ubuntu Intrepid software bunch) I assume it is since fglrx won't work in the newer versions yet with my 4850x2.


Well expect compatibility between X/kernel versions and drivers to not be great until the new graphics stack settles down. It's not like they can work on it for 4 years then release Linux 7. They release stuff incrementally, and when structural changes are made for benefit of the system, things will break. This is unfortunate but a reality. It IS a bit of a mess, but it has less to do with lack of standards, and more to do with the previous stagnant state of Xfree86. It's only been pretty recently (2005) that the graphics stack has started to undergo improvement, so most of us expect a little pain.

[yesterday]

I am not using GNU/Linux.
I am using gentoo. And my card (HD3870) works fine.

No, you're using the Linux kernel and the GNU programs which interoperate with the kernel.No, you're using the Linux kernel and the GNU programs which interoperate with the kernel.


Which Linux kernel?
What version of X?
What system libraries (GNU and non-GNU)?

It makes much more sense to call it Gentoo.

A kernel does not an operating system make.

[AdrenalineJunky]

Which Linux kernel?
What version of X?
What system libraries (GNU and non-GNU)?

It makes much more sense to call it Gentoo.

A kernel does not an operating system make.

true - but in a discusion of drivers the main point of interest would be the kernel, though this is also where the greatest strength and weakness of OSS comes back to bite us - just because ubuntu and gentoo both use the linux kernel, doesn't mean they are the same kernel. even if you were using 2.6.29 in both, still doesn't mean they are exactly the same. could very well be a problem with a specific change/patch/whatever ubuntu has applied, or maybe its solved by a specific change/patch gentoo has applied.

although, saying you aren't using gnu/linux when you are using gentoo is inacurate, as by definition when using gentoo you are using the kernel and base system packages from GNU. not necessarily disagreeing that calling it gentoo may make more sense, but you are still using GNU/Linux.

as for the original question, no problems here with arch/2.6.29/fglrx with either a hd2600 or a hd3200.

[energyman]

That's the great lie they want to push on you, yes. Linux programs are Linux programs. The main difference between "distros" is they choose to use different package managers that aren't compatible with a universal Linux packaging standard. But no, it's not a "different OS". Binaries can be run on any Linux system because they're all compatible. The main thing that isn't compatible between Debian and Red Hat is their stupid package format difference just because they want to be unique and the companies supporting them want to dig their own proprietary trench in order to get converts to come over to their side (the point of being "proprietary" meaning lock-in). All that is needed is for the community to recognise this deeply impacting Linux issue as a major threat, and push for standards. The companies won't do it for Linux users and developers, because they don't want it.



They're called standards. A web browser uses HTML standards. A FTP client uses FTP standards. FreeDesktop.org, the Linux Foundation, and other groups help create standards so that when you're in KDE and you want to run a Gnome app, for example, you can still do so. It empowers Linux users to communicate on the same page at certain points. It does NOT hamper progress, because if someone feels that the standard needs to be broadened, it can be, so that new features can be added. What version of HTML are we up to now, five? OpenGL 3? Those are standards which are quite solid, and they help everyone.

Just imagine a world without any standards, where everyone did just go and do their own thing. Lets say there were 500 different website protocols for instance, instead of having everything built on HTML. Imagine trying to function in such a world, it would be horrible, bloated, confusing, and nothing would get done. Every web-based program would have to try to be compatible with all the craziness.

I'm in no way saying that there shouldn't be different approaches, and competition, for those things are good. However, with most things, there are definite areas which are similar, and those can be shared. Those are points at which standards should be adopted.

For example, lets say you have two different file manager programs. Do they use standards? Already, yes, they use a ton of standards, because they interface with files on a hard drive managed by file systems etc etc etc, and there are standards every step of the way, that's how computers are built, otherwise you'd be screwed with pineapples. As you move up the stack from hardware to software, you encounter several different standards along the way. So, for the file manager program itself, if you recognise that there are several common needs there, and can find a way to utilise a common standard or even a common library in order to work together with other similar projects, of course that's in your interest to do so.

If everyone had to re-invent the wheel for everything, NOTHING would EVER get done.



Maybe that's why D3D is becoming more popular recently, so I sure hope that OGL can compete properly and catch back up if it really is lacking like you accuse it of being.

But guess what? Let's say that OGL, a standard, changed it's points of communication, it's API, the actual part that is a standard, and implemented OGL 3, 4, 5, 6, 7, 8, 9, 10, etc, and "moved" like you say, and none of those versions happened to at all be compatible with any other version.

a) That would be retarded, because there's no reason for it to be completely incompatible like that when they all would use nearly the exact same things, so the stable parts should have a clear API, while the new OGL calls should be added on, and what do you know, that's the way it happens to work.

b) No one would use the "standard".

The reason why: because that's not a standard. You clearly need to understand what a standard is, and how to implement one so that it doesn't impede progress and development. That's what standards are for, is to not impede progress, but to allow just the communication part to occur.

Let me give you a quick example of that. HTML again. How many programs use it? Hmm lets see, Google Maps, Google Docs, Yahoo Mail, Slashdot, all sorts of different programs and content, all using the same standard! So wow, you can have diversity and competition while using standards that are quite static. Maybe OGL needs to get it's tail into gear, maybe that was a poor example, but hopefully by now you are getting some idea of the point of standards, because without them, none of the above mentioned web apps and sites would exist!

And the rest of your comment was more of the same so I'll leave it there. Ultimately this is the on-topic point: there is nothing stopping the creation and adoption of some universal intelligent Linux binary packaging systems, the only reason they don't exist is disinterest by distro companies to play nicely with competing companies because they use their repos as a lure to get users to come to them. It's completely pointless and fragments Linux where there is no reason to do so and in an area which is critical for simplifying binary deployment by closed and open source software projects alike.

For now we're stuck with crappy archive files for the most part, which aren't very user-friendly to install at all.



It doesn't even work on the major distros, that's one of the points of this thread. I had to downgrade to kernel 2.6.27 and xorg 1.5 (using the Ubuntu Intrepid software bunch) I assume it is since fglrx won't work in the newer versions yet with my 4850x2.

Yes, Nvidia has always had quick support of the latest stuff. AMD is smaller, so they're behind in the closed source driver, but ahead in the open one still AFAIK. However, the open one doesn't have 3D, so it's a deal breaker after you plop down $1400 for a new system expecting to play some high-end Linux or Wine games.


wow, that whole posting is so wrong and so full with really, really bad ideas - you should stop talking about this. You ridicule yourself.

I give you an example why distributions have more differences then just package managers:

expat. Expat had a change in namening (and minor abi change). Distribution A uses old expat, Distribution B uses new expat. While A&B are identical in every other aspect, the expat difference makes apps compiled for A using expat (and that are a lot) fail on B and vice versa.

Your HTML example is rotten through its core. There are how many HTML standards? We are at what? 4.1 or something? And each html renderer shows the same page a bit different. HTML is a good example why standards don't work the way YOU think they do.

OpenGL - another thing you don't understand. Opengl was not invented by SGI to make it easy to program different hardware easy. It was invented to make programing for THEIR hardware easy. That Opengl had so much success afterwards is a whole other can of worms.

c) gnome apps & kde apps. Yes, you can use a gnome app in kde. That 'standard' has nothing to do with freedesktop. Or 'standards'. The gnome app starts all it needs to run in the background, so you suddenly have 'both' desktops running - only gnome incomplete. Interaction between apps from different desktops is...not very satisfying - and the standard every app has to follow is ICCCCC (whatever how many C...)M. Which is a bitch and very, very broken.

d) the linux kernel. People smarter than you have explained many times why stable 'api's for external modules are a very bad idea. Just go to a lkml archive of your choice and look for yourself. Some hints:
bug fixing
cruft
speed
are keywords to look after. I am pretty sure you never really read any of the threads, based on the observation how you confuse even basic stuff.

e) 'crappy archive files' are easy enough to install. The best thing - they prevent idiots from installing infested crap from dubious sources. Again, a problem you seem to have missed.

f) I am using gentoo. Not gnu/linux. I am using X - not gnu. I am using KDE - not gnu. Most of my system tools are not gnu. python? not gnu. Perl? not gnu. java? not gnu. star? not gnu. bzip2? not gnu. qt? not gnu. Do I need to continue?Nobody uses 'gnu/linux' - it would be a system with gnustep as gui.

g) stable 'apis' are only a problem fro ATI and NVIDIA. And both are on very thin ice already. Why cater for someone who might have to stop what they are doing if anybody of the core contributers decides to sue them?

h) zeroinstall is not a solution - it will just make it easier for idiots to destroy their system.

in conclusion: you don't know what you are talking about. You parrot some crap you read on slashdot. You never really thought through the mess.

[deanjo]

"e) 'crappy archive files' are easy enough to install. The best thing - they prevent idiots from installing infested crap from dubious sources. Again, a problem you seem to have missed."

Sorry, but that is not at all the case. If every file was scrutinized by the end user and actually knew what they were looking at then that statement would hold water.

[energyman]

an idiot that can not do ./configure&&make&&make install is nicely prevented from installing crap - until they see a oh-so-easy-and-friendly zeroinstall installer.

[deanjo]

an idiot that can not do ./configure&&make&&make install is nicely prevented from installing crap - until they see a oh-so-easy-and-friendly zeroinstall installer.

Uhhuh and all make files contain a nice uninstall capability don't they? Of course that doesn't prevent "dubious" code from being injected into your system from a modified tar ball taken from who knows where. At least with packages they are usually signed and easily uninstalled.

[curaga]

Which do you think is more likely, to find tampered source or a tampered binary? Binary of course, because with source it's way more likely someone will actually find it out.

[monraaf]

Which do you think is more likely, to find tampered source or a tampered binary? Binary of course, because with source it's way more likely someone will actually find it out.

Like the unofficial Catalyst drivers some people download from unofficial websites :D

[Yfrwlf]

an idiot that can not do ./configure&&make&&make install is nicely prevented from installing crap - until they see a oh-so-easy-and-friendly zeroinstall installer.

Linux will definitely be successful on the desktop with that attitude, no doubt about it. You should open a window once in a while in that basement.

[energyman]

people can install apps easily with the installation tool of their distribution. No need to deal with tar balls. If they think they need a tarball - it helps to.. you know, use it from the original homepage, not some russian blog. And zeroinstall helps you what? hm? which problem does it solve? none that could not be solved better without that really bad crutch.

Also I really recommend you these two links:
http://www.over-yonder.net/~fullermd/rants/userfriendly/userfriendly1.php
http://www.over-yonder.net/~fullermd/rants/winstupid/winstupid1.php

read and think about it.

[Yfrwlf]

people can install apps easily with the installation tool of their distribution. No need to deal with tar balls. If they think they need a tarball - it helps to.. you know, use it from the original homepage, not some russian blog. And zeroinstall helps you what? hm? which problem does it solve? none that could not be solved better without that really bad crutch.

Also I really recommend you these two links:
http://www.over-yonder.net/~fullermd/rants/userfriendly/userfriendly1.php
http://www.over-yonder.net/~fullermd/rants/winstupid/winstupid1.php

read and think about it.

Every version of every Linux program will never be in every software repository. That's why you need to unfortunately deal with compressed archives for now. A package is easier than dealing with a compressed archive, because it actually integrates with your desktop. That's the point of Zero Install. DEBs and RPMs are dumb and fail, as you have to make one for every different version because they reference dependencies through language not standardized when it should be, so only extremely popular Linux developers will take the time and effort to do so, when it's so much easier just releasing a compressed archive of the binaries (tarball). I hope that Zero Install will thus start to gain more traction as a better solution than a tarball in the future. Also, if there were Linux packaging standards that the major package managers made themselves compatible with, your "repository" would have no bounds other than the bounds you set for it. That would be a much greater software freedom. Your access to software is one factor that deems how "free" it really is.

Any way, packaging standards are fairly unrelated to this topic, which is about Xorg standards, but really I just wanted to know if other users were having to stick with older kernels and Xorgs who are on newer cards, while still having 3D functionality. I want the open source drivers to improve like anyone else does, but I also need 3D now, and wondered what others were doing to get it.

[Wyatt]

Oh wow, I haven't written this much in a while.
Every version of every Linux program will never be in every software repository.
You do realise that that is a good thing, right? There's no reason to keep deprecated and unsupported software floating around in package managers, too; we already have enough problems with things like that.
That's why you need to unfortunately deal with compressed archives for now.
Where "you" is "the package maintainer." With a decent package manager, a user will be able to find pretty much anything they could want and never need deal with format issues. Can you name something the average user would want that isn't found in your PM?
A package is easier than dealing with a compressed archive, because it actually integrates with your desktop.
Before you go railing for standardisation, please define this "integrates with your desktop" phenomenon.
That's the point of Zero Install.
No, the point of ZeroInstall is ostensibly to allow a user to install software that hasn't been provided already in userspace. However, there are things that I don't want in every user's default $PATH. Why should users be allowed to circumvent that without me knowing and possibly screw their accounts up? Or worse, use an exploit to escalate privileges? Come to think of it, ZeroInstall isn't just a bad idea, it's a terrible idea.
DEBs and RPMs are dumb and fail, as you have to make one for every different version because they reference dependencies through language not standardized when it should be, so only extremely popular Linux developers will take the time and effort to do so, when it's so much easier just releasing a compressed archive of the binaries (tarball).
While I'm not a fan or user of a Deb- or RPM-based distro, I don't see how this automatically makes them "dumb and fail." Hell, even I know that there's a debhelper script that makes debs pretty easy. Even better, the alien utility converts between a bunch of different binary package formats, so if you can make a tarball, you're set. Write a shell script for building your packages and call it a day.
I hope that Zero Install will thus start to gain more traction as a better solution than a tarball in the future.
For reasons stated and more, don't hold your breath.
Also, if there were Linux packaging standards that the major package managers made themselves compatible with, your "repository" would have no bounds other than the bounds you set for it. That would be a much greater software freedom. Your access to software is one factor that deems how "free" it really is.
You know, as a user, I think you really need to think about why things aren't in your package manager already. If you understand the role of your distro, then it shouldn't be a very deep thought, either. ;)

Anyway, @topic
I've actually been using the git drivers for Xv, not bothering with things that need 3D, and have been getting by quite swimmingly considering they're pre-alpha drivers in my case (haven't pulled more recent ones in weeks, and uptime reports 58 days). That's an HD2600, btw.

[Yfrwlf]

You do realise that that is a good thing, right? There's no reason to keep deprecated and unsupported software floating around in package managers, too; we already have enough problems with things like that.

Yes, what was I thinking, it's great having to package one program over and over again for every version of every distro out there, easy!

You've got your head in the sand and you just aren't getting it.

Users are always stuck on older versions of software instead of the latest releases, unless it's Firefox or security-related. They should be able to have the latest version easily if they want it, but right now they can't, because my first paragraph was sarcasm and you will never be able to accomplish this, not to mention it's a waste of time and energy to compile things five billion times.

Ugh responding to these comments is getting really old. It comes down to this:

A) If you like the way things are now, with being stuck on certain versions because the developers, if you are LUCKY, may have released one package specific for your Linux installation, with forcing developers to deal with packaging software for several versions of a thousand different distros instead of just releasing ONE package, the way it should be, like with Zero Install, if you don't think that's a headache and don't realise that your selection of easy to install software packages would be greatly expanded if packaging was done correctly and distro companies weren't assholes, fine, good for selfish little you.

B) If you know that your choice of easy to install Linux software is being reduced because of a lack of universal software packaging standards, and you'd rather not give developers one more headache to worry about when writing software for Linux, because you think Linux needs all the software it can get, and you'd like to create an atmosphere of true software freedom for Linux users, instead of being in walled gardens until they INSTALL A DIFFERENT OS to gain access to more Linux software when there should be no need to do so, and it's not just for you but you want this for OTHERS too and for Linux to succeed on the desktop, which effects ALL Linux users, go you! Thanks for caring!

You're type A. I'm type B. I care, you don't.

No, the point of ZeroInstall is ostensibly to allow a user to install software that hasn't been provided already in userspace. However, there are things that I don't want in every user's default $PATH. Why should users be allowed to circumvent that without me knowing and possibly screw their accounts up? Or worse, use an exploit to escalate privileges? Come to think of it, ZeroInstall isn't just a bad idea, it's a terrible idea.

Wow. Yeah, attack Zero Install for some random reason, and say it's not for easy installation of Linux programs. How narrow minded can you possibly get. The "point" of Zero Install is for several reasons, that's because it has several features, and ideally a package manager would be able to be very configurable so that you can specify exactly where and how you want to install packages. Universal Linux Packages need to be dumb, with lots of metadata defining things, so that managers are free to put everything where they want to.

Whatever you may think about Zero Install, it's just one program and anyone could make a manager deal differently with Zero Install files, but perhaps the actual packages need more information to allow administrators or computer users to be able to install them how they want to.

Regardless, that wasn't the point, the point was at least someone is trying to address the issue even though the solution is for the existing managers to adopt at least one universal format. They don't care about your freedom though, because they want you tied to proprietary packages. That's one way they get businesses attracted to their platform and thus their support, by having their package repos big so that users are won over by it's size.

You know, as a user, I think you really need to think about why things aren't in your package manager already. If you understand the role of your distro, then it shouldn't be a very deep thought, either.

Um, how about to get users access to Linux software, the software they want, ASAP? The role of an OS should be to get the hell out of the way, and get users to what they want. That's how Linux will be successful, and making your manager compatible with one or more universal package formats would greatly help accomplish this.

I recognise a feature when I see it, but apparently you don't. For the sake of Linux adoption, I hope more users will push for universal Linux packages.

[Wyatt]

I wish I could say you were trolling at this point, but you put so much effort into it. Are you for real? And I'm asking an honest question here: do you actually believe the things you're saying here?

I sincerely hope not. It's honestly incredibly insulting if you do. That you would have the gall to insinuate anything remotely close to the idea that distros are bad or out to get you? Distros that spend all of their time taking flak from both users and upstream, trying to unite a bunch of things that only coincidentally at times work together into a solid, stable and usable release that is pleasing to people like you? Distros that spend countless hours testing, verifying, and testing again, to at least make the best effort they can to ensure that a bad package doesn't get into the public repositories and ruin productivity for thousands of users? Distros that make tough calls like moving to X.org 1.5 and the HAL config system, or choosing to go with KDE 4.0 despite the issues? You would really have the nerve to sit there at your desk and belittle those efforts with something as feeble as "But I can't get the newest software easily?" I can't even properly articulate in words just how insulting that is.

Ignore me if you must. Degrade my opinions, refute my arguments with platitudes, and even dare to say something as ridiculous as "I care, you don't." But don't even go there with devs and distros. I'm not a fan of a lot of distros, and in fact, don't really like a lot of them, but I respect the work they do and why they do it. Your distro isn't a monolithic gestalt entity that is unapproachable; that "holds you back" from the "software [you] want, ASAP" and to think that way is just tragic.

But if you truly do not understand; if you truly don't see any of my points, then it's for the best if we stop this. Maybe you'll understand in time.

[energyman]

why is it bad to not have the lastest version of appX? Most people do not need to care about version numbers. For almost all users it does not make a difference if they have gcc 4.3.2. 4.1.2 or 4.4.0 installed. Same for X. Or gnome (ok, with the latest version there might be a handfull of options less).
Security? Well, the distros backport the patches so that argument is instant fail.

[AdrenalineJunky]

agreed ^^^

as long as you use a little common sense when you pick your distro you probably shouldn't run into a whole lot of problems with not being satisfied with your package version.

and if its really that important to you use something like arch or sidux...

[Yfrwlf]

Yes you're right, easily installing any version of any app on any distro would be a horrible feature. You love your walled gardens, so stay in them then, have fun. I just thought it would be great if Linux users of a particular distro, say Ubuntu or Moblin or Android or whatnot, could easily install and run any Linux software, but I'm insaaaaaaaane I guess. ^^

Guess I'll stick to Zero Install and simple binary packages then, instead of other systems which could easily exist which would be a lot friendlier to the user. ZI is pretty nice tho once you install it.

[energyman]

there is an easy way:
./configure&&make&&make install

Now, if crapbuntu. shitdora and suckse would start installing headers by default, that would remove almost all problems people have with manually compiling stuff.

There is no need for crutches like 'zeroinstall'. And 'one package working everywhere' is not working unless you make use of static binaries - memory waste and security problems, here we come - or every package bringing everything it needs with it - yeah, dll hell just like in windows, also: security problems still there.

as soon as distros stop acting idiotic (something you can not expect from 'lets break everything' fedora or 'lets make packages worse, never work with upstream and screw debian over' ubuntu).

[storma]

I would suggest to you to look at "Linux from scratch". Try doing what you want in a distro and then get back to us.

There is a reason why Debian stable is so long in between releases.

[Kano]

The main problem with Debian stable is the kernel, therefore i tend to combine it with the latest kernel.