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."
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.
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.
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
That's not the issue. The issue is that the toolkits are inefficient in their usage of the X protocol. This is partially if not totally because of the crapfest that is xlib. Xlib is so terribly inefficient and poorly designed that even the best-written toolkit will have some performance problems if it uses xlib. With XCB now getting ready to go primetime, performance with X might finally start to improve.
...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!
honestly... am I the only one who's sick of seeing this same damn ascii art over and over again?
it was funny the first time, I think we need to start modding it overrated now
(yes, I am aware this is slashdot, no I'm not new here, before you ask)
being vague is almost as cool as doing that other thing...
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.
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
I mean, they make Debian/stable look like the very model of cutting-edge experimentation. You won't get any fancy XGL stuff, but if you need enhanced support for your Sun IPX running twm, xclock and xbiff - well, then, they're your go-to guys.
I'd like to say I wish them luck, but I don't really. They spent years doing their darnedest to alienate their talent pool and end users alike, and it wouldn't hurt my feelings to see that dog laid to rest.
Dewey, what part of this looks like authorities should be involved?