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
What are you talking about? QT is a toolkit that runs on top of X, and if Trolltech were to change this they'd have a bit fight on their hands. Basically, it ain't going to happen.
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.
X11 toolkits are pluggable--you plug whatever toolkit you want into the client.
If you put anything "pluggable" into the server, you need an architecture-independent runtime for it and you end up with DisplayPostscript, NeWS, or Java. Is that what you want? Then go right ahead and use them: that's what they are there for.
The hardware was much faster under Linux+X than under Windows 3.1. Yes, X on an 8MB, 25MHz PC.
I first ran Windows 3.1 on an XT. It was a 10MHz 8088 with a Hercules card. It was responsive enough to be useful. I upgraded to a 286 after awhile (I think it was a 12 MHz.) Eventually I upgraded to a 386, because then I could (cooperatively) multitask.
I still have Windows 3.1 on an old laptop (a 386SX with 4 megs of RAM). Believe me, Linux and X run far more bloated on such hardware. I have NetBSD and X on an SE/30 to this day.
I don't know why you think it's amazing that X would run on an 8 MB 386.... You definitely didn't run any of the current bloat desktops on it...
A Good Intro to NetBS
There is no such thing as X Windows, except in the mind of the ignorant. It is called 'The X Window System' or 'X'.
'X Windows' is what illiterate journalists call it, and the people whose main experience with X is reading their inaccurate prose.
A Good Intro to NetBS
... unless you have read the paper, of course, in which case it will be a pointless answer...
1. There is an explanantion of how X compatibility can be achieved, and it is pointed out that such a compatibility is required for Y to become widespread,
2. Under the requirements, he lists the kernel 2.4 ATI driver, so he is using existing XFree drivers.
3. see other posts in this thread
4. It's a framework, with a working base implementation. The paper is well written, and allows for the real work on Y to commence. Of course it will take more than one year to make it complete, but of all the "replacements" of X, this one seems to be best positioned for a possible success. After all, it took another undergraduate 4-5 months to get his hoby project to a working state to be shared with others, and it took few years before that project took off...
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.
To say the security of X is horrible because silly people have done "xhost +" is ridiculous! Doing "xhost +" should make absolutely no difference to your computer's security with respect to network attacks because your computer should have a firewall which (at least) blocks incoming and outgoing X11 connections. Anyway, if you want to run X applications on remote computers, the best way to do so is to use ssh for securely forwarding the X11 connections to/from the remote computers., e.g.
ssh -X -l login_name remote_computer
or
ssh -X -l login_name remote_computer X_program
Scroogle
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
QT was developed after object oriented methodology was well understood. Its far easier to learn than Motif. There is genuine progress.
Firstly, you are criticising X when you are actually likely using XFree86, the free non-commercial implementation of an X server. There are commercial X servers which in some cases run faster than XFree86. XFree86 writes its own device drivers but graphics hardware manufacturers have often provided little or no information to help XFree86 developers write better device drivers. The design of X is not the problem.
Secondly, the client-server design of X causes minimal delay on locally displayed, locally run applications. The X11 communications take place over the very efficient, low overhead Linux version of Unix domain sockets. Furthermore, there is the shared memory extension to X, XSHM, which bypasses the usual client-server model for XImages and XPixmaps so that applications which are locally displayed and locally run can directly read/write the data in shared memory in the X server thus avoiding client-server roundtrip communications for these common high-volume data-structures.
I use XFree86 on a variety of hardware ranging from an old 66MHz i486 PC to very recent Intel PCs, and find it runs as fast as Windows.
Scroogle
Well what can I say in response to your unsubstantiated claim, other than "you don't know what you're talking about."
GTK exists because Motif was not widely available to the potential users of GIMP. GIMP had originally been written using Motif, and then GTK was written to replace Motif so that GIMP would not have a dependency on non-free software.
And also because (by their own admission) the GIMP authors didn't know Motif that well, and thought it would be easier to just write their own toolkit that only did the few things they needed: GTK was never intended to be general-purpose.
Fast forward a few years, and GTK has bloated out to do all the things that Motif did, from i18n on down.
Gigantic waste of effort. Colossal.
You can read their own summary of the history on gimp.org.
I worked plenty with XIntrinsics and Motif at Sun, where I worked on OLIT (the Open Look Toolkit, which was their XIntrinsics toolkit) and emulation of Motif widgets in OLIT. I also implemented several Motif widgets, including the GridBag layout I designed to get around the horrors of Xi layout (this still lives on in the Java Grid layout widget).
All I can say is that I am personally quite relieved and happy that Motif is gone.