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."
Way-kewl feature list, but about like driving in the Bradshaws: more rock than road.
Lacking <sarcasm> tags,
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
No, it's not a problem of bandwidth, you dumbass.
Modularized code is easier to inspect, study and debug.
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."
Which is easier to repair and inspect. A modern skyscraper or a 1000 small homes in a suburb?
I don't want to shit on your OpenSores-parade, but the skyscraper is.
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!
I can see why you think that the skyscraper is, but there is more to a skyscraper than a house. Think of it this way, inspecting a single module like say a kernel module is much easier than inspecting the entire linux kernel. Why? Rules that apply in modules and functions available for that type of module from a logic perspective are easier to train someone on. They don't need to be experts on every aspect of the system. Likewise, someone could study twm and not care how the radeon driver works. In the skyscraper analogy, someone would need to know commerical building codes and understand how a skyscraper's foundation might have trouble supporting the weight whereas a single house doesn't need as good of foundation or electrical wiring or whatever.
Modules are the reason we have Object Oriented languages. Sure, C++ and other languages can be a pain in the ass at times, but it makes it easy to write code once and reuse it in a shitload of places. It also simplifies unit testing which is very important for mission critical applications. I think xorg is a very important piece to any modern linux/UNIX distribution for desktops, embedded devices and occiasionally servers. Long term, the direction xorg is going will work out nicely. If you've followed the xorg progress since it forked off the xfree86 code, you'll know they've had some annoying bugs between versions. The seperation might allow them to either avoid the bugs or at least repair them sooner.
MidnightBSD: The BSD for Everyone
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.
Build a skyscraper & 1000 houses, populate them.
Come back in 5 years and see which you prefer to sort out.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
the linux kernel does not offer you a stable well defined binary interface so that you can compile a single module without knowing anything but the version of the kernel you are compiling for.
I can use a module compiled by NVIDIA in my Xorg 7 even if they didn't know what options the debian packagers used to compile my Xorg.
On the other hand it is _impossible_ to compile a module for a 2.6.x.y kernel and have it to work on most kernels. (In fact NVIDIA has to give away some sources, plus a binary blob, and you need to compile it yourself)
I really wish the linux kernel was modular in the Xorg is!
Anyway... the "damage" extension was supposed to fix the bandwidth issue (if there was any, IANA Xdeveloper) by limiting transferred data to parts of the screen that were "damaged." I don't think modularisation has anything to do with performance. It's about code maintainability/flexibility.
I like to program in Xlib to do various little utilities and games.
Does anyone know if the core Xlib API has changed going to R7?
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
This has been done for a few years now. Take a look at Cairo. It's (approximately) the PDF imaging model, like Quartz. It has a variety of backends, including win32 (with GDI+), vanilla X11, XRender, Quartz and hardware-acccelerated OpenGL (via GLitz).
GTK stable has been using Cairo for drawing for almost a year now. The Xlib API (wrapped up as gdk_*) is deprecated. I imagine KDE will have a cairo backend at some point too.
Erm, nothing ever stopped distributors from simply throwing away those binaries after they'd been built. The fact that twm, xeyes etc are still shipped is more to do with inertia and UNIX history than any real technical problems.
Comment removed based on user account deletion
Does the functionality exist right now to fully buffer that window so that it doesn't have to completely redraw each time? It seems like the Composite extension would solve that problem, but it doesn't seem to be fully ready for production yet.
Dewey, what part of this looks like authorities should be involved?
No, that would be the slot ID, which as others have pointed out, is *completely* different from the VendorID/ProductID tuple burned into every PCI device's ROM to uniquely (or in the case of a few vendors, not so uniquely) identify just what a particular PCI device is.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
it makes it easier for distros to get fixes in.
/. does to unsuspecing websites).
With debian (and its derivitives) all of the xfree86 packages were built from one source package drawing off the X11 tarball and its monolythic build system.
so while as a sibling post said distros can (and do to some extent though perhaps not as much as they should) split stuff up after building. the single source package means that they all have to go in or none of them do to avoid a source/binary desync (something debian avoid due to problems for anyone who wan'ts to rebuild debian and potential licenseing issues with some packages). For debian that translates as
1: more work for autobuilders (especially significant for testing-proposed-updates, secure-testing and stable-security).
2: unnessacery new versions of packages for end users (last time a security bug happened in stables X it did to the security distribution server what
3: longer waits to get enhancements into testing.
4: longer package build times for anyone who wants to fix anything
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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
You can't even BUILD a skyscraper to begin with unless you've got some seriously special purpose training and certification to go with it. Such tradesmen are more specialized than anyone in IT and paid more too. This is in stark contrast to the undocumented Mexicans building the typical single family home in suburbia.
A Pirate and a Puritan look the same on a balance sheet.
This is an idiotic analogy. The skyscraper is far easier to inspect. It consists of a few hundred very similar floors and the framing to support it. All of its materials are the same age and located in the same spot.
... You get the idea.
The houses are spread out over many hundreds of acres of land, each one with different architecture, different soil conditions, different age and building materials, different pests, different occupants, each one with unique requriements when arranging inspection visits. Some houses will be wood-framed, some might be steel-framed, some might be ram-earth, some might be adobe,
Which is easier for the less trained to be brought up to speed on?
You've got to be kidding.
Try a bit harder the next time you attempt an analogy? Maybe one involving cars?
Actually the architects and engineers and general contractor (and hopefully the foremen) are the experts. The rest are mostly general laborers - often illegal aliens, most are just typical union laborers with no particular specialty aside from general pipefitting (which pays well in and of itself) and welding. They are not experts in skyscraper design - the designers (architects) and engineers and hopefully the foremen are. The laborers just do what they're told and cobble together what the engineers and blueprints tell them to.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Well, actually KDE will use Arthur that is part of Qt4, which is the same thing. It uses a pplug-in system which means that you could even use Cairo if you really wanted, but what I've read so far in KDE-lists etc. nobody seems very interested in doing that because Arthur already seems to do everything that Cairo does.
That's interesting, thanks. I don't follow Qt development :-/ but it's good to hear Cairo has competition.
As a programmer I would prefer smaller chunks of code. The key to X.Org's success or failture with a modular design is this - documentation. Most of the time I will not need to know how other parts work but if I do need to look at another module, there better be some good documentation.
Plus programs aren't skyscrapers or houses. Code is something completely different.
This building analogy is not really working out.
You got me thinking (and searching), and I found Xrdp (http://xrdp.sourceforge.net/). It seems a little hackish (it sets up a VNC session which is then translated to RDP), but seems to be a start.
But X can now do all the things he was talking about in that article, so nothing in that article is evidence that there's a problem with today's X.
First off, that's simply not true. For instance, X still has severely lacking text rendering support. X does not support access to glyph structures and such things. Yes, you can do it via freetype, but FT is not X. Nor does X or FT provide any text layouting routines. Which is frankly ridiculous. Laying out and kerning bidirectional text is not some high-level functionality that should be relegated to a high-level library. It's a quite fundamental and basic thing that all apps need to do.
Secondly, just because Cairo exists now doesn't invalidate the criticism. Cairo is still relatively slow and immature software. This needs to be contrasted against what Packard is reffering to, which is that the Display Postscript API on NEXTSTEP was developed in 1987, and is in principle identical to Cairo, with the exception of compositing which is a more recent thing.
The fact that it took 18 years for X to catch up to that is not a strawman, it's an indication that something is seriously flawed either with X, or with the X development process as it was. Even Java, seven years ago, had all the same functionality that Cairo now provides. (and could layout text to boot)
Now it's true that X is progressing a lot better now. And I'm glad for it. But it is a far from being the cutting-edge of windowing systems it was when it was introduced. If you can't find anything wrong with today's X, then you either haven't looked hard enough, or you haven't looked at the alternatives.
And naturally it is immature given how new it is.
But neither is an argument for throwing it out and developing something new instead, which would then surely be even more immature.
Took 18 years to catch up to what??? X has NEVER been 18 years behind any widely deployed graphics system. That's even MORE of a strawman than the earlier arguments. If you want to argue that X doesn't have a comprehensive superset of the features of all other graphics systems, and doesn't outperform all of them, fine. I won't dispute that. I also don't think it's a very useful or interesting criticism.In other words, if you want to be constructive, propose specific features or areas of improvement that are not addressed by X together with commonly available libraries. Don't just rant about things missing from the core of X. That's the point of it being the "core"; other things build up around it to add additional features.
Some of the "all talk and no code" XFree86 project members were upset about things like XRender. The people doing the real innovation were long fed up with this and other things.
Pretty much all of them.
Pretty much none.
One of them is an actual project has the support of just about everybody. The other one is XFree86.
On a side note, have you been living under a rock?
Which has absolutely nothing to do with which library it is implemented in. The fact is that the functionality is available in a widely available library commonly used with X. So what if it's not in Xlib? The end user doesn't care which library it's implemented in, and there's little reason for a developer to care much either.
Ok, so first you say that everything Keith Packard (who certainly knows more about X than either you or me) brought up there was implemented. And when I point out things he brought up which are not, you tell me that they don't need to be.
Secondly, which library widely available and commonly used with X does text layouting? Why does Qt have their enginge for it and Gnome another, and any lesstif or whatever apps have to do it themselves as well.
And naturally it is immature given how new it is. But neither is an argument for throwing it out and developing something new instead, which would then surely be even more immature.
I wasn't the one to advocate throwing it out.
Took 18 years to catch up to what???
Did you read? As I said, NEXSTEP's Display Postscript system.
X has NEVER been 18 years behind any widely deployed graphics system. That's even MORE of a strawman than the earlier arguments.
That's just a denial and a particularily weak one at that, as I gave several examples. So what the heck is your position? You think Cairo is great but you refuse to accept the fact that the same API (that it indeed is modelled on) was introduced 18 years ago? That's just denying reality. NEXTSTEP was indeed widely deployed. And Java AWT even more so.
In other words, if you want to be constructive, propose specific features or areas of improvement that are not addressed by X together with commonly available libraries. Don't just rant about things missing from the core of X. That's the point of it being the "core"; other things build up around it to add additional features.
That's also ridiculous. Basically nothing can be missing from X, because you've now expanded your definition to include "commonly availabel libraries". Of course, you and I know perfectly well that any major deficiency in X is usually already augmented by libraries. If it wasn't, people wouldn't be using X at all. For instance, the aforementioned text-layouting code. There is no reason for all software that uses X to reinvent the wheel. Bidi is bidi and kerning is kerning. Text layout is all the same and, I should be provided at a lower level, and KeithP certainly seems to think so as well.
Yet you first say that that this had already been implemented, and that X is just fine. When I point out that's wrong, you say it doesn't matter since "commonly available" libraries provide that functionality. (which they did in 2000, as well) In fact, according to your argument now, it doesn't even belong in X. (Which is strange, since it already has font support which is pretty deprecated. )
Besides which, it's a moot point because the question was whether everything brought up in that link had been implemented or not. So I take it you concede now that it isn't in X?
And I don't care if I'm not being "constructive" or not. At least I'm making a consistent and coherent point, unlike your position which seems to be that X cannot be criticized for anything, and that you should change your argument as you go along to counter any criticism.
"...when is Apple going to update the their version of X11 to reflect this, or are we stuck with XFree86?"
When volunteers step up to the plate to make it happen. (X11 isn't exactly Apple's highest priority; it's more of a way for Apple to get their foot in the door at Unix shops, so they can sell them Quartz/Aqua later on down the line.) I think there was one (1) main person working on porting Xorg to Darwin, and that guy got swamped with other projects. He put out a call for more devs in December, but I don't know if anyone responded.
And with the new Composite, Fixes, Damage extensions, the Xorg server is poised to be as pretty as Aqua.
X in general has been woefully understaffed compared to other big open source infrastructure projects (gcc, kernels). But that means there are HUGE opportunities for new developers to make a difference! Who knows, ya might get a free MacBook out of it!