Slashdot Mirror
Y: A Successor to the X Window System
impto writes "Whenever someone brings up the topic of replacing X, everyone always says that's nice, but where's the code? Well, Mark Thomas put his money where his mouth is and produced a replacement that maintains network transparency while adding many of the features that people desire from X such as alpha blending and a built-in toolkit. It still needs a bit of work to be as featureful as X but it's a fresh start that takes advantage of current technology and ideas. Read the paper here in PDF (1.7MB) or PS or grab the source and start hacking."
./configure --without-x
The document covers this with the obvious solution:
4. It's a final year project. Sorry, but this guy's just an undergraduate student, no offense but I find it highly unlikely he can come up with something superior to X, QT and GTK (all of which this system supposedly replaces) in a year of work.
I was under the impression Linus started work on Linux while an undergraduate student?
Think nothing is impossible? Try slamming a revolving door.
Now, doesn't libSDL again depend on X? ;-)
No, it doesn't. There is an X backend to SDL, but it can also do the fun stuff on its own, as well, and runs on many platforms. From the FAQ:
And from the website:
Thus, not only can his example be made to work under X (theoretically), but it will also work on pretty much every other OS you'd want to use it on, and some you wouldn't. Also, in addition to being runnable anywhere, it can also run directly on the Linux framebuffer, which means that all that needs doing is hardware acceleration for the framebuffer, and then Y, as well as many other SDL apps (perhaps with slight modification), will run quite well without having to have X loaded. That, to me, sounds like a good thing.
--Dan
all X really is is a network-aware framebuffer.
I disagree. VNC could reasonably be called a network-aware framebuffer. X, however, provides drawing primitives, color management, font rendering, windowing...
May we never see th
I first ran X on a 386-25 with 8mb ram too. I agree with almost everything you said. People that think X is slow are trying to run GNOME, KDE, or maybe E with a bloated configuration, a crappy video driver, and quite probably all their libraries compiled with debugging on. X is a wonderful thing, lightweight, fast, powerful, and it runs fine on hardware that any recent version of Windows (or Mac OSX) wouldn't even attempt to run on.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Thank you *very* much for pointing this out.
For some reason, people (generally folks new to X) consistently manage to completely misunderstand how X works, and happily rant about it. Among the issues:
Problem: X has bad 3d support.
Answer: No, it doesn't. Manufacturers have just barely put out drivers, and still don't have great install procedures. Starting with a new system would make this problem orders of magnitude worse.
Problem: X uses lots of memory.
Answer: No, it doesn't. Try running pixmap_mem (and the analyze script that comes in the same package) on your system. Unlike Windows apps, X11 apps store pixmaps in the server. X11 newbies frequently confuse this with X using a lot of memory. Combine this with the fact that Unix memory utils multiple-report memory usage of shared libraries, and report device mapping as memory usage, and people look at X and say ("Oh, it's blowing 30MB of memory in overhead."). No, it isn't. Trust me.
Problem: X11 is inefficient.
Answer: No, it isn't. X11 is pretty damned efficient. Today's pixmap-laden interfaces can run much more slowly over a network than the original interfaces, whicch were mostly big, flat-color rectangles, but the same is true of VNC and similar.
Problem: X's multiple-widget set system is a bad idea.
Answer: No, it isn't. People look at X and think "Gosh, I don't want to use Athena apps." The thing is, the widget-independent design of X has been a huge boon. X11 dates to 1987. If we had been unable to advance through widget sets, we'd still be using ugly, grotty Athena. But, you say, this ignores the fact that Windows and Mac OS have advanced through the years! Nope. First, Windows widget sets *have* broken user-level compatibility on a regular basis. Menus in Office XP now work a lot differently than menus in 1987 did. Second, some widget sets are hamstrung by initial design flaws. The classic MacOS widget set does not include a slider widget, for example. As a result, years of application developers misued the scrollbar widget, made up their own widget (which led to even worse user interface problems), or just went without. The ability of X11 to evolve has let things like KDE's tearable panes come to the fore. Also, when it comes to APIs...the modern, easy-to-use APIs of GTK and Qt blow away the horrific Macintosh Toolbox API (note: I am not a Cocoa developer, so things may have improved) or the almost-as-grotty Win32.
Problem: X11 is hard to use.
Answer: No, it really isn't. Occasionally, piss-poor setup on the part of distro makers has made things more of a pain than it should be. If a user isn't interested in remote windowing, he shouldn't have to worry about xauth or xhost. This is largely a problem of the past.
The main "problem" with X11 is actually newbies to it making a bunch of claims about software that they haven't used and don't understand. They've frequently just come off of a decade of Windows use, and expect things to work in precisely the same way, and are horrified when there are differences.
The majority of people I've seen complaining about X11 are Johnny-come-lately types. Most of the older folks who have been using it for a while just don't care enough to respond to the complaints, which they see as pretty uninformed.
Now, there are things about X11 that aren't that great. X11 supports an *extremely* rich color model. If you're using Xlib (which you shouldn't be doing unless you're writing a widget set), it is a royal pain in the butt to support every color model available. This was done to handle the vast array of hardware that X11 has been run on.
X11 doesn't support a great way to share identical pixmaps from different apps. This is really hard to do in a secure way.
Basically, I'm reminded of the SSL discussion that came up recently. Everyone wants to run out and rewrite SSL to be simpler, faster, easier. They don't understand that the stuff in SSL is there because it *needs*
May we never see th
Read the paper. (I went to his project presentation and helped review the paper before it was submitted, so I don't need to. :) All of the details you want are clearly presented there.
:-)
And development has stalled until November because he's just finished his 4-yr Masters degree and is taking a well-deserved holiday before starting his new job.
Cheers,
David
1. Y has been designed so that an X compatibility layer would be possible to implement. You wouldn't get many of the benefits from using Y, but it would provide backwards compatibility. I'm pretty sure that's mentioned in the project report.
:-)
2. Wrong. Hardware interfaces for new drivers can always be derived from the X source code (where available); if it becomes big enough, then the companies may well be willing to describe their specs for a Y developer, too.
3. The KDE and GNOME desktop projects have a lot of code which is no-longer needed if adapted to run under Y. The applications could probably be adapted to Y with relatively little effort.
(I'm not an X/GNOME/KDE coder; the above may be an exaggeration one way or the other.)
4. ``this guy`` is a friend of mine. I know him, he's smart. He aced a first at one of best university's in the UK and got a prize for this project.
You are clearly only questioning the fact that an undergrad could develop something worthwhile when nobody else did. I'd much rather you'd debate the quality of the work rather than baselessly disparaging the person who created it.
Oh, and it wasn't a year of work, it was 9 months, tops. And he still had 8 other courses to do at the same time along with a break to do the requisite 8 final exams.
Cheers,
David