Slashdot Mirror
X.Org Releases First Modular Source Roll-Up
NewsForge is reporting that X.Org has released their first modular roll-up release. From the article: "All X11R7.0 derivative ("modularized") releases divide the source code into logically distinct modules, separately developed, built, and maintained by the community of X.Org developers. This concentrates and accelerates development time, supporting continuous modification, testing, and publication of each module.The new modular format offers focused development, and rapid and independent updates and distribution of tested modular components as they are ready, freed from the biennial maintenance release timetable."
I could not be happier. Modular design clarifies architecture and simplifies targeted enhancements. Better X, faster. What's not to like?
this
This should make it a whole lot easier on the Gentoo user machines - we will no longer have to recompile the entire X.Org source on every update.
I heard rumours of KDE going a similar route in the future.
'For we walk by faith, not by sight.' II Corinthians 5:7
Whether or not that's true, I can't say. But it should be easier to revamp the X driver model without impacting the rest of the code now that it's all been properly modularized.
A monolithic system with poor or unstable interfaces is a maintenance nightmare. Maybe this explains why in the end XFree86 was so slow in supporting new hardware drivers. I still remember having had to patch the sources manually for my ATI Radeon 9600XT card, just because the PCI ID of that card was still not in the release quite some time after the card was on the market. Really bad.
With a modular built, they can now change one part, like the drivers, with little fear of introducing problems in other parts. High time this happened. I am looking forward to the things to come.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You don't understand what modular means in this case. It only means that the various components of X are now in separate autotooled packages. There hasn't been any change in the existing modules, only now they are available separately rather than as part of a single monolithic tarball with a monolithic build system.
Its like a fasionable thing to do nowdays.
That'll still help. Not having to download the entire source tarball to fix one package lowers the cost of entry for people interested in making changes.
X.org has been modular for a while -- X11R7.0 was already modular in December 2005. The real news here is that X.org released X11R7.1, not that they've gone modular.
One thing I'd like to see is an ordered list of dependencies. I still do manual builds on one system, to stay in practice. Building X11R7.0 was so painful, I stuck with X11R6.9. When using a distro that does the heavy lifting, X11R7.0 is great, but sorting out the dependencies in dozens of modules is a PITA if you're trying to build it manually. I bet the distro maintainers are cursing the X.org people.
So they broke it up into pieces and a we are now celebrating the
release of the pieces rollde together into a monolithic whole!?
Accelerated indirect GLX has been a until recently been a unattainable holy grain for a long time now in regards to X.
What this will allow you to do would be allow users to gain some benifits from having hardware acceleration for 3d and multimedia application even when running applications remotely over a network.
Another way to put it is that applications gain their acceleration not from the hardware directly, but from the Xserver they are running on, which then itself then uses the hardware acceleration.
It's not going to be as fast or efficient as direct rendering, but it's much more flexible and usefull in a wider context.
It is another stepping stone to having a fully realised opengl-based X server.
This is probably very much due to Redhat's AIGLX specificly and xgl development in general.
LOL... yeh... because bandwidth is what is preventing people from hack X. Its not the insanity of Scheiffler's design, or the arcana of Gettys' et.al implementation.
yeh, its the bnandwidth thats stopping people from just sitting down and whacking X...
... hi bingo
Um It's not the bandwidth, but the pile.
Which is easier to repair and inspect. A modern skyscraper or a 1000 small homes in a suburb?
given the same number of people in each team which do you think would done first and with a higher quality?
Which is easier for the less trained to be brought up to speed on?
i thought once I was found, but it was only a dream.
Go play the game Katamari Damacy. Then imagine that each random thing you add to your proto-star is one little piece of the Xorg whole. You can imagine that the server is a cow if you like.
"I may not have morals, but I have standards."
Not having to download the entire source tarball to fix one package lowers the cost of entry for people interested in making changes.
Or more likely, being able to build a distribution without twm, xedit, xeyes, xman, xvfb, and the billions of other useless utilities that clog up and XWin installation could make for smaller, more focused builds that assist projects that are focused only on producing an end product. (Damn Small Linux is a good candidate in my mind.)
Previously, the X build system was so monolithic in nature that you couldn't not build all these stupid little widgets. Now that things are more modularized, you can build only what you need and throw away the rest.
Javascript + Nintendo DSi = DSiCade
"I may not have morals, but I have standards."
X seems to work OK for me, and doesn't seem substantially less functional than the Windows or Mac OS models.
Let's just let Keith Packard do the talking: http://keithp.com/~keithp/talks/usenix2000/render. html
...freed from the biennial maintenance release timetable.
This is just a fancy way of saying packages will be breaking on a weekly basis.
Don't blame me, I didn't vote for either of them!
XFree86 4.6.0 has been released. I thought that project was dead but appearently it isn't completely (yet).
If you just want a strawman argument that X as it existed in 2000 is not very good today, I don't think you'll get much disagreement.
No it's not. Every PCI device has a unique number assigned to it, made up of a vendor code and a product number. The pciids project maintains a useful list of these IDs.
In addition, each device plugged in to your system gets a PCI address, but that is entirely dependent on your particular system.
Run "lspci -vv" one day and you can have a look at the information supplied.
Carpe Daemon
I've always wanted there to be a way of connecting to X sessions via RDP.
Yes - RDP is heavily underdocumented, and it's a Windows thing.
BUT . . .
There are a huge number of dumb "Citrix" terminals out there in corporate land that only use RDP. If Linux could support these dumb clients connecting, it would remove one of the large costs of migrating to Linux desktops.
To put it into some perspective, I've been involved in 2 major projects to migrate the desktop from Windows/Citrix to Linux, only to be stopped by the cost of having to replace every single dumb terminal.
Is this a stupid idea? Or could it really get wings and start to fly? My X knowledge isn't strong enough to figure out the best way forward.
Cheers
Duncan
NX helps your situation in general. But to answer your specific question:
Does the functionality exist right now to fully buffer that window so that it doesn't have to completely redraw each time?
Yes, its been in X since as long as I can remember. Look for turning "Backingstore" and "Saveunders" on for your specific graphics card. Usually in the video device section of your X configuration file you put...
Option "Backingstore" "yes"
But you might have more hoops to go before getting the full save-unders.
That's interesting, thanks. I don't follow Qt development :-/ but it's good to hear Cairo has competition.