Luc Calls For A Dead Linux Desktop If Keith Gets His Way

[energyman]

It's not a small one. It's a big one. You're forced to pull all driver updates, not only those you want.

wrong. You can pull just the git tree that was merged for that changes.

If you can't do that, you should not build your own kernels in the first place.

[RealNC]

wrong. You can pull just the git tree that was merged for that changes.

You're a funny guy, you know that? You assume pulling Git subtrees on top of your current stable kernel is going to work, and that everyone out there is a geek who knows not only what Git is, but how it works too.

Oh, and never mind that there's no driver ABI in Linux, which means the results are unpredictable. No sir, we just pull the Git tree.

If you can't do that, you should not build your own kernels in the first place.

BS. I'm building kernels since 1993. So any comments about what I should and shouldn't do should be directed elsewhere.

[energyman]

so in 17 years you did not figure out to:
buy hardware that works
patch kernels
or
merge git trees.

hmmm...

[RealNC]

so in 17 years you did not figure out to:
buy hardware that works
patch kernels
or
merge git trees.

hmmm...

You're off topic and a troll. Either stick to the issue at hand, or don't post. This is not about me merging git trees and patching kernels. This is about users being able to install new versions of drivers without installing a whole new kernel or needing to merge Git trees and patching kernels.

Perhaps trolling is in your DNA and you don't know better. But it's OK, we can try ripping that part out of you, if you're willing to cooperate.

[NomadDemon]

you talk talk and talk... but we still have shitty xorg and drivers performance...

i have idea, to make a mega lightweight version of xorg, but for a simple user, that dont need remote desktop and other useless stuff for "mr smith", just a simple xorg, that allows everything to works, and much faster, without 80% of useless code. wayland seems to be nice alternative, whats wrong with you guys? you forget what was your main goal? i dont care about features, while performance is sadly low

if i have to chose between performance and tv output, i chose performance
if i have to chose between stability and opencl i chose stability

like alt + tab in fullscreen games... they always end with crash, broken resolution on desktop, or cant restore app from taskbar, this sux sux sux

[nanonyme]

For God's sake, stop mixing the old DRM git tree vs kernel git tree in the mess. I already pointed out it's a separate matter. This is just about X.org's possible future demodulatisation and even Luc used kernel only as an example of doing things in the way he doesn't like.

[yotambien]

It looks like, for once, following links in Phoronix articles actually helps. It seems that my uninformed concerns about this move are pretty much the concerns voiced by people who actually know what they are talking about.

because instead of waiting for three month (or pulling a git tree) you have to wait for years or hope that the vendor gets of his ass?

Yeah, sounds so much better.

That's because, in that respect, it's much better. Vendor lazyness doesn't have anything to do with this discussion. The Windows example is put forward for a very simple reason: you can update a single driver without having to update the whole system. That drivers in Windows are closed or MS eats your children is irrelevant here.

This is not about me merging git trees and patching kernels. This is about users being able to install new versions of drivers without installing a whole new kernel or needing to merge Git trees and patching kernels.

That's it. There are some over here who apparently see no problem whatsoever in having to build the whole X server to update a driver, or recompile the kernel, for that matter. I may have been extremely unlucky, but in my experience upgrading big parts of my system with fresh code leads quite often to minor breakage here and there. Sure that one bug may have been fixed, but now suspend is borked, or the mouse doesn't wake up after entering power saving mode, or garbage is displayed when scrolling documents, or certain application suddently decides to segfault. Great.

Git can't be the accepted means to distribute software, it's just for developers, testers and enthusiastic users. If you make it harder for users to test whatever users are interested in, fewer of them will try new code. I'm not interested in breaking my system in new and colourful ways because somebody decided to tie 2D drivers to a monster like X. This is not about users' technical proficiency. That I can compile and configure my kernels doesn't mean I enjoy doing it, even less if I'm forced to do it if I just want to try out some new cool driver feature I read about in Phoronix. The same could be argued for distributions; wouldn't this affect their ability to import minor fixes without introducing new bugs everywhere else?

Somebody mentioned that this is a decision for the developers to take. Well, yes, that much seems obvious. Though it doesn't mean end users should pretty much accept whatever it comes from above and be happy no matter what. While the technical decisions obviously are taken by those who know about it (and actually put their work on it), the code is meant to be used by a lot of people, so how this kind of changes affect users must be considered (in any case, I think that's what normally happens).

[V!NCENT]

Furthemore that would break the bazaar model: release early, release often.

BTW what's so great about demodularization? Even Microsoft has been heavily working on modularising the entire Windows OS since they started working on Vista :S

[TwistedLincoln]

I'll cast another vote for keeping the drivers outside the kernel. The ability to upgrade a driver without recompiling all of Xorg is a big deal, especially if your distro doesn't ship with the latest versions right away.

Also, it's nice to be able to remove all the drivers you don't need without recompiling if you're trying to save space on an embedded system.

[allquixotic]

I'll cast another vote for keeping the drivers outside the kernel. The ability to upgrade a driver without recompiling all of Xorg is a big deal, especially if your distro doesn't ship with the latest versions right away.

Also, it's nice to be able to remove all the drivers you don't need without recompiling if you're trying to save space on an embedded system.

A few things:

1. I don't think anyone is proposing moving anything into or out of the kernel that isn't already there. The kernel/userspace boundaries are actually going to stay relatively the same, regardless of what degree of modularity we have in userspace. I think you meant X server instead of kernel in your first paragraph.

2. It isn't a vote, unfortunately. The people with commit access to the Xorg freedesktop repositories are the only ones whose "votes" actually count. You can always fork it, but we've been down that road before, and it wasn't easy (although it worked out better in the end).

3. You will always be able to remove all the drivers you don't need without recompiling, even if things are demodularized to the extent that Keith proposes. No one is suggesting that we statically link all the DDXes into one enormous X binary. As long as the drivers each have their own separate files, all you have to do is remove them. So free space on embedded systems is not an argument against the demodularization of X; even the most extreme advocates of demodularization still have a design where you can, at least, delete individual driver binaries that you don't need. And if you do statically link (you'd have to force the configure script to do so), you can exclude drivers from building at all by passing the correct configure flag at build-time. The point is, embedded systems are the least affected by this change. Of all the types of system that we have out there, embedded are probably most in favor of demodularizing X, because it doesn't hurt them in any way, and maybe even helps them by reducing dynamic loading and allowing the possibility of static linking, which can reduce CPU cycles on startup.

Note that I don't actually support demodularization, but I don't see any disadvantages for the embedded people. It's ordinary desktop users and the distributions that serve them that will lose out from this change. I'll summarize in my own words why that is.

At present, a distribution can evaluate different versions of different drivers (in userspace, at least), to determine which drivers contain the least bugs, while still being compatible with the existing infrastructure. Sometimes there really are multiple stable versions to choose from, and sometimes you can just choose between a git build (which happens to be compatible with the rest of your stack) and the latest stable. You get this choice precisely because the driver isn't a part of the X server: you can replace this driver without affecting any other piece of software on the system. Granted, there may be an even newer driver that is incompatible with some part of your stack, but this only happens some of the time.

With demodularized X, there is no tractable way for a distribution to take different versions of drivers from different times and ship them together. You might settle on version <1> of Xorg because the core server is good; you might want version <2> of Xorg because the Radeon driver is good; and you might want version <3> of Xorg because it fixes a major bug in Nouveau. Good luck grafting the code of different Xorg versions into a custom tree that takes bits and pieces of various unstable APIs into account. Even within the demodularized Xorg server itself, the chances of you getting a combination of software in a single git revision that contains the optimal set of functionality and correctness for all hardware is practically impossible. Luc was spot on to point this out, although I think he was referring to the larger concept of the stack. But even within the Xserver itself this would be a problem!

We have a bit of catch-22 it seems. We don't have the manpower for robust QA on the open source stack, which means that any given version of a driver is very likely to be chock-full of bugs and brokenness -- even "stable" releases. Since we can't rely on any particular version to be production-quality, distributors have to "version shop", attempting to find a version whose exposed functionality works correctly on the most-used applications in their distro. Sometimes they may have to go several versions back; sometimes they may have to use a git build to get what they need. But having this flexibility is absolutely critical to shipping a distro with good drivers, because we can't just blindly say, "use the latest stable" and pretend like that's going to be the best -- quite often, there's a showstopper for a very common use case, which is simply unacceptable.

But the downside to modularization is that it increases the amount of overhead developers have to wade through. The code becomes bloated with #ifdefs for old code paths that have been deprecated; old interfaces have to be implemented with nasty hacks to work out an impedance mismatch with new APIs. Developers have to make a near-synchronous commit to multiple git repositories to make an API change that touches the kernel, libdrm, and the DDX. By increasing developer overhead, they have even less time to test things, and the chance of buggy code paths increases exponentially as the number of code paths increases. Developers therefore can't perform the degree of testing we'd like, resulting in buggy drivers, which makes everyone allergic to blindly using the latest release of everything. So then when they propose demodularization, all the users are strongly against it, because they perceive that their freedom of version choice (and the same freedom as it applies to distros) will evaporate, effectively forcing distros to find a version of X that exposes the least bugs, rather than mixing and matching drivers to create an optimal release.

All of these problems only appear when the number of video cards supported by your software stack is greater than 1; therefore, it doesn't apply to embedded systems, which are always hand-tailored to the particular hardware they're to be used on.