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."
The website (available by clicking his name) should really include more information. It tells us that Y is the replacement for X, but offers NO reasoning. What problems does it solve? What features does it have? Can I install it alongside X? With this little bit of information, it makes me not even want to download it. Sorry.
Also, it should be noted development has stalled on this project. He says it should start up again in November.
That's all well and good, but one of the reasons that X is so successful is that you can use whatever toolkit you want, and all X really is is a network-aware framebuffer.
This leads to toolkit darwinism, which has left us with essentially GTK and QT as the two dominant toolkits. Imagine if X had been shipped with Motif as its native toolkit? Who the hell would use that in 2003?
You're doing it wrong.
What will they do after they've finished with Y and Z, they'll have no more letters of the alphabet then. It'll be a disaster
I have over 70 freaks, do you?
According to the webpage:
;-)
Y depends on:
* libSDL 1.2 (available at www.libsdl.org)
Now, doesn't libSDL again depend on X?
Note to self: get smarter troll to guard door.
UNIX desktop environments are a mess. The proliferation of incompatible and inconsistent user interface toolkits is now the primary factor in the failure of enterprises to adopt UNIX as a desktop solution.
:-)
So what do we do to solve this mess of user interfaces? Let's create yet another one! I love the way that geeks think
I don't really like this... X is mature and popular, replacing it will take a *lot* of time, and most people will not switch unless the major distributions do.
And anyway, alpha blending and an official toolkit? No. The unofficial X toolkits work well enough, and alpha blending is not very hard to hack in - it's also quite useless for anything other than eyecandy.
I doubt this project will get much highlight after this initial slashdotting.
...wouldn't it be more in keeping with tradition to call it X++?
philcrissman.com.
What's the license?
For great justice.
Everybody says X sucks, that it's bloated, that it's slow, ... and everybody wants to replace it. The best effort I've seen so far it Qt (especially Qtopia for palm devices).
I think X is like Unix : it was inadequate and bloated but computers have caught up with their demands, in terms of power and disk capacity.
Computers get more and more powerful, networks are faster and faster, and X is more and more lightweight comparatively. Combine that with decades of testing and millions of developers who have experience with it, and I can guarantee X is there to stay and evolve.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
There is no way to get consistency in a window system. People will port their favorite window managers and toolkits to whatever window system you create. MS Windows runs many of the same toolkits that X11 does. Apple is even worse, officially supporting OS 9, Carbon, Swing, and Cocoa-based applications on the same desktop, and now also X11; and in addition to all that, toolkits like Gtk+, FLTK, Swing are also being ported to native Quartz backends.
If you want consistency on your desktop, just choose to use a consistent set of applications. Most non-computer experts can't even tell the difference between an MFC, Gnome, KDE, and wxWindows application: they all look equally flaky and confusing to them. And most people incorrectly think that something is an OS X native application if it has shiny gumdrop buttons. In short, most people neither know nor care.
Read the paper. It is of shockingly good quality, both in the writing and the completeness of ideas. The writer is a college senior!
The document covers this with the obvious solution:
Some people don't like the name Y. I say hey, Y leaves us with Y Windows.. which is a good question.. why windows? Use Linux.
My Blog
Let's call it Youvert! ;-)
The preceding comments reflect the author's personal opinion and are public domain, unless explicitly stated otherwise.
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.
This guy seems to know what he's talking about and as far as I can tell he's got a proof of concept to show allready. Along with solid research and design.
I wouldn't be to fast at hand with bashing this guy - he lists all the other XFree replacements and for some like Berlin/Fresco he can clearly state why they failed and what you have to aviod to not fail the same way. And he also acknowleges XFrees benefits and sees no point in overthrowing them.
Keep an eye on this project, this could be something really interessting.
We suffer more in our imagination than in reality. - Seneca
No I don't agree, and here's why:
While people usually talk about X compatibility- that's not usually what they want. They want application compatibility. They want Mozilla, GNOME, Emacs to work on their computer *usually*.
Look at Opie and you realize that, given sufficient numbers of apps, you don't care as much about the libraries.
So what's important would be to port things like GTK and QT to the new target (however you choose to do that, be it at the X toolkit layer or the GDK layer, or whatever).
An example of the success of this method are the number of Free applications for Microsoft Windows and OS X.
While some apps talk to X directly, the number of users who will be effected is smaller.
If something else can provide the ability to use the same apps, allow same/similar features and provide some benefits, then I don't see why we can't give it a chance, even if it breaks one compatibility.
It's the infinite compatibility problem that has forced x86 down people's throats for so many years.
Sometimes you need to make a new protocol and provide a migration path.
- Serge Wroclawski
Well yes, but it allows people to transfer system relatively painlessly, should Y become accepted. Apple have been masters at this in the commercial sphere, having moved their user base first onto RISC and then from a proprietary OS to a less proprietary *nix based system every time providing a way to keep old ways of doing things unbroken. The Free Software community could learn a thing or to. An admirable effort, X Windows for all its merits and for all the work that has gone into it is still a bit of a pig although i see the human interface issues as more pressing than the architectural ones. I wish the Y guy all the best of luck with his project and ask him not to forget about putting good human interface at the core of his thinking.
... 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...
This is not particularly important since Y is a work in progress, but you can see use of a GCC C extension in Y's button.c:
.c = &buttonClass, .reconfigure = buttonReconfigure, .paint = buttonPaint, .pointerButton = buttonPointerButton, .pointerMotion = buttonPointerMotion, .pointerEnter = buttonPointerEnter, .pointerLeave = buttonPointerLeave
static struct WidgetTable buttonTable =
{
c: &buttonClass,
reconfigure: buttonReconfigure,
paint: buttonPaint,
pointerButton: buttonPointerButton,
pointerMotion: buttonPointerMotion,
pointerEnter: buttonPointerEnter,
pointerLeave: buttonPointerLeave
};
That's not necessarily a bad thing - I think GCC is one of the best compilers around. The only issue here is that that particular named struct member syntax construct has been deprecated since GCC 2.5 and may be dropped in the future. If I understand the GCC docs correctly I think the alternate C99 syntax would be:
static struct WidgetTable buttonTable =
{
};
But I could be mistaken.
True, but Linus didn't plan it as the next big thing that replaces Unix and Windows. It turned out quite well after years of work by many contributors, and the same thing might as well happen to Y. It's too early to predict anything, so in the meantime it's probably best to do as Linus says: forget about competition and just focus on writing good software.
Escher was the first MC and Giger invented the HR department.
Yes, but aren't Xouvert and DirectFB others starts ?
I'm lost in those things...
Will we have a replacement for X ? Will we have the choice when installing Linux (like KDE or Gnome) ?
Will we have a simple and light software for home users and a big, with network support, for the IT ?
I'm not sure to really understand what this news means.
Ploum.net.
That's true, as far as it goes, but is pretty much unnecessary.
The "norms" as you call them can click through a RedHat or Mandrake install if they want, and if they accept the defaults will end up with a desktop that is not so far removed in usability from a Windows interface that they will be incapacitated. At least, unless they are such complete morons that they shouldn't be allowed within spitting distance of a computer...
This notion that everybody should throw out all desktop environments except one and unify is all very well until you try to decide which should go or stay.
The whole point is to enable freedom of choice, not to turn Linux desktops into Microsoft-style dictatorships.
unless they are such complete morons that they shouldn't be allowed within spitting distance of a computer...
It's offensively mindless ramblings like that that are a) keeping Linux out of majority desktop share and b) keeping the sterotype of the arrogant geek strong in the hearts and minds of millions.
Computers are not important enough to serve as the deciding factor of one's intelligence. I would argue that social skills are a much better yardstick, and by using it on your post above, I see that you shouldn't be allowed within spitting distance of another human being (loosly assuming that you are one yourself).
Computers are just pieces of equipment that some people understand, and some don't. Could you rebuild your car's engine from scratch, or do you take it to a mechanic? Does he make you feel like an imbecile because you don't know how to tune your own fuel injectors?
The norms need some kind of consistent interface, and Linux (or *nix in general) just doesn't provide that. Yes, they can click through a Redhat install (doubtful as one of the first things to do is partition the drive, and I can't see my mother doing that), but it'll be different enough from what they know. And, then, what if they want to install a new piece of software? Do they have GTK? Probably. QT? Again, good possibility. OCaml? Ahhh...I don't know...and they sure as hell aren't. (I know, not a toolkit, but an example). All they know is when RPM tells them they need it, they won't know how to get it. And, considering how well written 90% of the install docs are, they'll never find out.
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
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
The thing is that you're assuming that all widget sets provide the same functionality (or that you can go with the least-common-denominator). In reality, that'd make for some pretty awful applications. You'd have to give up your KDE-draggable-panes (not supported under Win32), your sliders (not supported under classic Mac OS), gtk's easy layout system that provides automatic resizing support (Win32 and classic Mac OS use a pixel-based layout system). Some widget sets use infinite progress bars (XUL), some use animated icons (Windows). The two can't fit in the same space.
You're thinking of something simple, like theme engines. These *are* pluggable, and plenty exist for gtk. You can't just drop in a new widget set, though.
Xlib *was* designed so that it's easy to develop widget toolkits, though.
May we never see th
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
Well, I've only gotten as far as the critique of X at the start of Thomas' paper. This critique is a classic /. "X sucks" troll in academically semi-polished form.
Point by point:
- X has too much latency: See Packard's paper in Freenix 2003: high latency is not an inherent X attribute, even over high-latency connections.
- X requires a toolkit for ease of programming: Duh. As opposed to what, exactly?
- X needs standardized UI semantics: This is moot. You may use X+Gnome or X+KDE if this is what you desire. Either is a fairly good and fairly complete system with standard UI semantics. The existence of two such systems is no more troublesome than the simultaneous coexistence of Windows and MacOS.
- X is "an incoherent mess": When making this argument, it is always useful to confuse the protocol with the implementation. The existence of Kdrive is a nice example of how much the latter can be cleaned up. The protocol hasn't changed in 20 years except for extensions: the argument that the extensions don't work together is supremely unconvincing, supported by one lame example. freedesktop.org has made a lot of progress in a short time in refactoring and standardizing X.
- X is complex: It is. Unfortunately, it is a response to complex application requirements. Again, one lame example involving perhaps the most demanding application running is cited. And again, freedesktop.org is standardizing mechanism for dealing with the cited problems.
All of this would have been easy to avoid. Just talk to an X developer before publishing the paper. Many are quite accessible, and would undoubtedly have been happy to correct the critique.It's perfectly valid to want to write a new window system. I can think of a variety of justifications, starting with "it's nice to try something different" and "I wanted to learn some things". Trolling is hardly necessary, and hardly welcome.
Like I said in prior similar topics, for intranets, businesses really want an HTTP-friendly GUI to avoid firewall hassles. Candidates include XWT, and SCGUI (my pet). I suppose XUL could also be included. HTML forms + JS + DOM is really a pain for GUI emulation.
Table-ized A.I.
QT was developed after object oriented methodology was well understood. Its far easier to learn than Motif. There is genuine progress.
I see some flaws in the document posted.
I love research, and more than anything I love the people involved in doing research: those who create, explore and can give us future direction. But I also believe that the research must be truthful if we want to build on it.
The Y presentation paper is interesting on the ideas it introduced (we could argue whether they are new or not, since NeWS did did before, in fact, with a more extensible system) but it fails on presenting X correctly.
The document goes on to show that the X-based approach has lead to major GUI fragmentation, and how the MacOS and Windows do not have this problem.
On the screenshots where X looks bad, the author shows some old graphics program running together:, xpdf and two modern apps: mozilla/xul and gnome calculator. All of those programs have Gtk-based or Qt-based equivalents that would have made the whole experience consistent.
The screenshot should instead be presented as a proof that X can still run applications that were developed 12 years ago.
Then he shows the Mac and Windows. Again, not really honest screenshots, because even Apple is shipping two different GUI views: the brushed metal theme and the aqua theme (this combination kills me) and Microsoft is not exactly known for keeping their GUI look consistent across their product line: Office, MSN and the rest of the desktop use different styles and widgets.
So summing it up: the screenshots are presented to prove a point which happens to not be there.
Now, to make things even more interesting, here is a little bit that the author of Y might not be aware of: widget rendering on MacOS X happens on the client side, and the operation that the server supports is basically "uptade-rectangle-with-this-RGB-buffer", there is no magic of server-side widget rendering on MacOS X.
Also, doing an X protocol translator is not an easy job, but I wish them good luck pursuing this new adventure, it defintely sounds interesting.
Miguel.
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 I didn't read the whole paper, but the first 5 minutes made me go.... you know this guy actually knows something, the next 5 minutes made me go, you know this guy actually knows a hell of a lot, and the next 5 minutes after that, I was convinved that it's not a bad system to replace X Window, with.
If people actually got behind this, poked around, wrote drivers so everything didn't have to go through SDL and the other things that it needs it could really work, admitidly it'd be a bit of a shift and many things done today would have to be built as modules to the windowing system, thinking particularly things like Evas *druel*, themes and so forth.
Bigest turn-on: You could connect to a machine, run a program and no matter what it was it'd look right on your machine, somone else running the same program on the same machine would have it look right on their desktop as well.
Bigest turn-off: The number of legacy X11 appications which would totally ignore the good features of the windowing system and fact it'd probably take 10 years to get to the stage where nvidia and ati would write accelerated drivers for it.
Now of course I am a beast of my enviorment, so I'll just mourn that I saw no mention of RISC OS and say jolly well done, I don't think my masters project will be anything close to this impressive.