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."
the inherent insecurity of the X driver model.
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
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.
Its like a fasionable thing to do nowdays.
Join with me in tagging this story "technobabble."
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!?
what exactly is a roll-up in software engineering terms?
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.
...when is Apple going to update the their version of X11 to reflect this, or are we stuck with XFree86?
Same with OpenBSD, building -stable X via release(8). Hopefully they can more easily patch X this way too.
This guy is hilarious!
Looks like they got sick of all us bitching os /. about it. Hmm, I wonder.
I am so sick of windows, I wish that it would be more stable.
Thats what MicroKernals are all about - modularisation!!!! So they must be better!!!
(Puts on asbestos suit and ducks for cover)
I am Slashdot. Are you Slashdot as well?
The X server stuff is really annoying. The raster graphics are horrible. I realize that redesigning the rendering system will be arduous and time consuming. But I think it wold be nice if the *nix rendering system would advance past the 70's.
system if yer gonna slap proprietary binary-only drivers on it?
"I may not have morals, but I have standards."
The PCI identifier is not something that comes with the release, that is a number assigned to the card based on its position on your motherboard.
Join Tor today!
...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).
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!
but one hopes the close association with gnome doesn't force the same dependency graph nightmare onto x.org. I have built X from source. It took ages, but it built without errors. Gnome is always seems to need just another library, utility or other piece of gunk.
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?
Comment removed based on user account deletion
A comment on X from Theo De Raadt
from the OpenBSD misc@ mailing list.
> http://marc.theaimsgroup.com/?l=openbsd-misc&m=114 657401630096&w=2
>
> If I understand correctly from what I've been told, this is not a
> hardware
> issue but an 'X' issue.
It is the job of the operating system to shield the hardware from userland processes. That's what every operating system does. Some do a better job of this than others. But when an operating system fails to do this shielding, it is almost always a bug in the operating system.
However, in this case, we cannot solve this in the operating system. The X developers have created an X server which *REQUIRES* access the raw hardware. Therefore all the operating systems developers have given the X server such access, by creating a "hole" in their operating system, which permits the X server to access any chip-level registers it wants. This is called the "device drivers in userland" model. It violates all the security models you will hear of in a university class. Having done so, they place operating system designers in the situation of choosing between the two options: "Our users cannot run X" or "there must be a hole in our operating system". Guess which choice every vendor makes? We provide a sysctl to let the user decide -- that is what the aperture sysctl is for. And we admit that is a cop-out. That's because there is no operating system level solution to the problem. At least we did not cop out as far as other vendors, who let any root process play with the any registers. We only let one root process play with the registers at a time. This is not a strong solution, but it the best we can do. But let me be clear -- the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this >10 year old problem! They spend way more time chasing the latest vendor binary loaded device driver, than they do solving this obvious problem. (Translation: They don't want to change how X works, because it would break the vendor binary drivers from ATI and NVIDIA. That is part of what happens when X developers get jobs at vendors). What Loic found is just one example of perhaps 50 other serious & equivelant security problems. Or maybe more. Most modern video chipsets can DMA all over the address space if requested. Many have processors that code could be loaded into, even surviving reboots. If there is a one bug in the X server, your machine is compromised. How does this get solved? If the X server did not require direct hardware access these problems would go away immediately. This requires that a proper abstraction be designed, so that a kernel device driver did the nasty register bits, and then communicated via a sanitized channel to the X server. This is the obvious seperation model that all other Unix things use. Unix processes use read() and write() to modify files. You don't see them talking directly to SATA chipsets do you? If they show up and provide a simple specification for such an abstration layer between a "kernel video driver" and a "X video driver", and helped us a little bit with the registers, the problem would go away almost immediately. That requires them to do some clever design, but it is clear they know more about past, current, and future video chipsets. They know the hardware, and we do not. They can solve this for all X-running operating systems today, or they can cop out and not solve it ever. They've had 10 years, and yet every year they get more entrenched in the entirely insecure model of "gigantic process running as root, which accesses registers like mad". This problem is ENTIRELY the X group's fault! They have failed us. Ten years ago they were laughing at Microsoft for moving their video subsystem into their kernel, but now the joke is on the X developers, because what Microsoft did solved all these driver security problems! This is 100% an X
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?
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 are already using the modular X.org. This is old news.
That's great. Now, if only someone could reorganize the Linux kernel so that it would consist of multiple, smaller, independently managed and released subprojects as well.
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.
This seems like a fork.
:p
Does anybody have more details:
When the fork took happened?
Why?
Which developers went to X.org and which stayed to XFree86?
What's the difference in the philosophy?
>> it looks like the open source comminity has choosen to silence it to death.
The "open source community" takes whatever the 4 major distributions distribute.
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?