Y Window System Project Started 512
cuppm writes "Y, Mark Thomas's final year project for his masters degree, is back in active development (outlined here). Here is the email I received: '...Y development is about to start up again. If you are interested in participating, the website is at: http://www.y-windows.org/. There are links to mailing lists there, and you can download the latest development snapshot, which should compile this time :o). I apologise if I did not respond to your email personally. I was on holiday in Japan when the story broke, and by the time I got back I had over 80 emails about the subject, many of them in depth. If you had specific points that you'd like to raise, I suggest re-raising them on the y-devel mailing list.' So for all those who think it's time for a X replacement, here's your shot. And for those X lovers, use Y's extensibility to make it X compatible." See our previous story for more background.
Re:Women's Windows (Score:5, Informative)
Re:Women's Windows (Score:2, Informative)
Re:Women's Windows (Score:2, Informative)
Re:At long last! (Score:4, Informative)
History of X (Score:5, Informative)
Stanford had an operating system called V where they developed a windowing environment called W. MIT needed such a windowing environment for the Athena project and borrowed the W system from Stanford. They made so many improvements over time that it no longer resembled the W system so they named it the X Windows system. Over time 11 versions were developed as more and more Unix companies got interested. But by then MIT had its needs met so an X Consortium was formed that developed the X11 system from revision 1 to 6 reaching the X11R6 release that we have now.
Re:good idea but wrong reason (Score:5, Informative)
Google is your friend (Score:1, Informative)
About Y (Score:5, Informative)
About Y
I've got tired with the state of desktop GNU/Linux. Most of the problems that I see with it can be traced back to the underlying window system, X. So I decided to write its successor...
Y was my final year project for my masters degree at the Department of Computing, Imperial College, London. I set out to design and begin the implementation of a modern windowing system. The Y design has the following features:
Network Transparency
Contrary to popular belief, supporting network transparency does not reduce the speed of the window system on local hosts. Further, with Y's in-server knowledge of widgets, applications run over a slow network can appear almost as responsive as local applications (especially when compared to an X application).
Modularity (plug-in style: dynamically unloadable and reloadable)
Unload an old video driver, load a new version. On the fly. No restart in sight.
In-server implementation of widgets
Y specifies a core set of widget classes. Objects of these classes are stored in the server, where they are closer to the user and thus more responsive from the user's point of view.
Consistency and Themeability
Y widgets use the currently loaded theme to render themselves. Since all server widgets are using the same theme, all widgets appear consistent throughout the desktop. Client applications can also use the theme's drawing operations, allowing specialised widgets to make themselves fit in with the look-and-feel.
Support for hardware acceleration
The Y design can make use of hardware acceleration to speed up rendering operations. This can even include the use of 3D-accelerators' textures to draw windows with (someone has already implemented a prototype of this which is very smooth).
Better internationalisation, localisation, and accessiblity
In-server widgets means there can be exactly one current language, one complex input method system for languages that require them, and one set of accessibility features.
Some more information can be found in my individual project report. If you have any more questions, ask them on the appropriate mailing list.
The current implementation is, however, very basic. It needs a lot more work before it will be usable on a day-to-day basis.
Re:Stuff (Score:3, Informative)
Re:At long last! (Score:5, Informative)
This is all taken from the PDF file.
I for one, am all for standardizing a window system. That's not saying that we can't have competiting Window managers, but there is standard of the communication to the windows system. This is (IMO) what is holding back Linux from the desktop.
Quick and Dirty Mirror (Score:2, Informative)
Re:Not his masters degree (Score:3, Informative)
IRC channel... (Score:5, Informative)
CB
Re:What sort of compatibility? (Score:1, Informative)
1) It's easier than building their own Xlib implementation
2) To retain X network transparency easily
Re:My, aren't we opportunistic. (Score:5, Informative)
Re:Who? (Score:3, Informative)
X is not a GUI system. It is a display system. Ratpoison, for instance, requires X to run, since it runs in graphical mode as opposed to text mode, but is not a GUI.
As such replacing X really has nothing to do with replacing your GUI.
There is something to be said, however, for occasionally replacing old, crufty systems with newer shiney ones that work better.
In the case of X though, since it's function is so low level, arguements as to what is meant by "better" abound.
KFG
Re:Call me lazy (Score:5, Informative)
I don't see the big deal, myself -- if you want to use their code, you use their license -- but if people want to get apopletic about it, they're welcome to do so.
Re:What license (Score:5, Informative)
The Y communication library and the YC++ library, being the contents of the
libY and libYc++ directories in this archive, are licensed according to the
terms of the GNU Lesser General Public License, contained in the file
COPYING.LGPL.
The yiterm program, being the contents of the clients/yiterm directory in this
archive, are licensed according to the terms of the Common Public License,
contained in the file COPYING.CPL.
The remainder of the files in this archive are, unless otherwise stated in the
file, licensed according to the terms of the GNU General Public License,
contained in the file COPYING.GPL.
(C) 2003 Mark Thomas
Re:good idea but wrong reason (Score:4, Informative)
Of course, at this point, Motif is pretty much dead, at least on the free Unix desktop, because it was succeeded by more technologically advanced widget sets. I don't think that we will see any migration away from X until the alternatives provide a similar jump in technology.
Re:At long last! (Score:1, Informative)
Re:Stuff (Score:2, Informative)
Go to preferences [slashdot.org] and choose 'Light'
Why not http://www.fresco.org/ (Score:2, Informative)
http://www.fresco.org/
Y _IS_ intended to replace X (Score:5, Informative)
Re:OpenGL? (Score:5, Informative)
NO WE BLOODY WELL DON'T!! why dont people RTFM and find out that XFree86 have been writing their own accelerated (yes, 3D as well) drivers for ATI cards since time began... as they release the specs. sure, ati also make their own, but XFree86 also make them. and they also work on FreeBSD. also, incase you didn't notice, the linux kernel even ships with the radeon and ati Direct Rendering Modules.
if i have to point this out ONE MORE TIME on slashdot, i swear to god i'm gonna explode...
i wouldnt think for a minute that binary only drivers would work with Y... but i'd like to hear how different at the level of the source code, the drivers are from teh XFree86 ones... i.e., how hard will it be to port over XFree86 drivers? (assuming no license issues, which there will be since Y windows is GPL)
this is one of the most exciting projects i have ever seen... and it has appeared at JUST the right time with the XFree86 team being assholes, and the FreeDesktop.org guys without a useable server... they are almost on a par.
if someone could make an X11R6 compatibility layer on top of this thing... everyone oculd start using it (once drivers are made) and that is all the encouragement anybody needs to start porting their programs (or toolkits). but porting a toolkit kinda defeats the purpose, as this new implementation is trying to get rid of the need for multiple toolkit.
but to be quite honest, the thing i am most excited about is the license... fully GPL (probably someone will advice them to go LGPL)... which means no more jokes about GNU/Linux needing to be called GNU/XFree86/Linux :-)
Re:At long last! (Score:4, Informative)
Since the terms 'client' and 'server' tend to be redefined every year or two by the Xfree team, nobody else really knows which is which any more. X interfaces directly with video drivers and also with the window managers.
The problems are fairly numerous and unfortunately difficult to fix:
Single-threaded X is forced to share its timeslice with every client (?) program, which leads even people like Linus to complain about GUI latencies on 4-way systems with top of the line hardware. [kerneltrap.org] Not so cool. Kernel 2.6 contains some hacks to kludge around this problem, but the underlying issue still hasn't (yet) been addressed. Considering Xfree's Design by Committee creed, it never will be fixed. You might say that X is rotten by design. You might more accurately state that X is 1980 technology, and wasn't meant to do the things that modern users expect as a matter of course (eg. 3D low latency, non-stuttering graphics). There isn't an elegant solution aside from ditching X entirely.
From the other end, the Xfree API is a big mess of kludges. Extensions have proven an excellent tactic to obfuscate and uglify code.
Y runs on X! (Score:4, Informative)
Re:Gonna have to call it "Y Win - - -s" (Score:2, Informative)
Re:Call me lazy (Score:5, Informative)
You may ask "what GPL code is so all-fire important?". Well, QT for one (and by extension all of KDE). I'm sure several key components of Gnome as well, though I dunno for sure if the new XFree and the LGPL clash. And once you've eliminated all the window managers (most are GPL), then why do you need XFree86 at all?
Re:Flashier subsystem? huh? (Score:5, Informative)
X does have some problems. The set of actual problems with X, and the set of perceived problems with X are more or less disjoint.
X is not slow. X is not a memory hog. X's feature set is not outdated. It does, however, have a very weird way of handling color, has some protocol peculiarities, and the default interface library (xlib) makes it hard to write fast apps. Most of these things can be fixed without ditching X. For example, there is an extension called XFixes which fixes certain problems with the protocol. There is a new interface library called XCB which is more "low-level" and makes it easier for toolkit authors to identify potential performance issues. Freedesktop.org's new X server will incorporate compositing and OpenGL-acceleration, to make X competitive with Longhorn, all within the existing X framework!
Re:My, aren't we opportunistic. (Score:3, Informative)
Of the software hosted at FreeDesktop, the site has this to say: "None of this is "endorsed" by anyone or implied to be standard software, remember that freedesktop.org is a collaboration forum, so anyone is encouraged to host stuff here if it's on-topic." The software section of FreeDesktop is in essence a "sourceforge" for desktop related software.
There's no one talking about the "Sourceforge" replacement for AOL Instant Messenger, even though Sourceforge hosts the Gaim project (currently the most active project there). Ditto for the software at FreeDesktop. The purpose of FreeDesktop is not to create an X replacement, even though it happens to host some independent projects that seem to lean in that direction.
You're probably talking about the X server software that Kieth Packard is developing there. This is not a full X implementation. It's just the server. You also need X libraries. This is another project at FreeDesktop, but it's just getting started. And beyond this you still want the X clients, X fonts and servers, etc.
It's got minor involvement with those desktops. Originally FreeDesktop was meant to be a collaboration zone, and for a while it worked well to get some common standards for icons and desktop entries. But it's become quite muddled of late. Some people have gotten the impression that any software hosted on FreeDesktop (such as D-BUS) is some sort of standard that must be used by both Gnome and KDE. This is simply not true.
Of certaintly, neither Gnome nor KDE are actively involved in any X11 replacement.
Re:My, aren't we opportunistic. (Score:3, Informative)
Now go load IE6 or a current Mozilla on that old Windows box, and compare it to Mozilla on a decently small WM on X11. You should be enlightened.
Re:MicroSoft sue Lindows but not XWindows? (Score:3, Informative)
The X11 most people are familar with was developed in 1985 and really appeared in 1986. It had a different (worse, imho) rendering model (the old one had a current point and moveto/lineto like PostScript). It also introduced the seperate window manager process, Visuals, multiple colormaps, and the wacky font-naming scheme with the dashes (before that fonts were named things like "fixed12" for the 12-pixel tall fixed-pitch font).
Re:At long last! (Score:2, Informative)
It's the latency (Score:4, Informative)
One of the first sections in the original "Y Window System" paper listed the problems with X. It started off with "X is slow." However, it made a very specific allegation. It was not that X is slow per-se, but that it is highly sensitive to latency. Yeah, we all run X11 applications on our local desktop, and they're lightning fast. We can even run X11 applications from machines close by on the LAN. But very few people ever try to run X11 applications across 20 hops of the internet. Unless you have somehow ensured very low latency connections, you're gonna have lag city.
The X Protocol is very verbose. It's one of the reasons that there have been projects to try to compress or otherwise remove redundancy from the protocol. But, at some level, it's the protocol itself which needs rethinking when it comes to speed.
My two cents...
The rest of the story (Score:4, Informative)
However, I'll demonstrate by answering them.
> X is too slow
On the contrary, I fnd it's quite fast with a good accelerated AGP card. The network transparency is a very nice feature that I use regularly.
The original document outlining Y specifically says that X is fast. Locally. But you try running a very interactive X11 application across a many-hop internet connection with lots of latency and then you'll see just how slow it is.
This is one of the problems with X, that the protocol is very sensitve to latency and is very verbose. Unnecessarily so, IMHO.
Does that mean the speed issues are such that you shouldn't use it on a desktop? Certainly not, as testified by the thousands of people who use it for such every day.
That's why we have things like GTK.
Again, this is addressed directly by the PDF:
> Xfree86 is over 10 years old
So am I. So is UNIX. So are most of the theories in Computer Science. Shound we throw them away?
Of course not. But age can certainly bring problems. Again quoting the PDF:
In summary, X is just fine.
For many purposes, yes. But it's starting to show signs of not being able to cope with what window systems are being asked to do in the last 5 or so years. It's worth revisiting now and again.
Re:About Y (Score:2, Informative)
There's a ton of information about how this works in this [ic.ac.uk] PDF.
From what I've read, it's exactly what I want (and have been advocating.) My money was on PicoGUI, but hey - competition is good.
Re:At long last! (Score:1, Informative)
The server is the part with a listening socket. Eg, your "X" process.
Clients are programs that connect to a server and speak the X protocol. These are the programs that use X.
This should be a pretty clear explanation of the terminology, that anyone with any idea of how X works should understand.
Second, XFree does not "redefine" anything. X is a protocol and set of libraries to which XFree86 conforms.
If you knew anything about X you would not be spewing forth such ignorance.
Re:Flashier subsystem? huh? (Score:3, Informative)
Re:Call to Programmers (Score:2, Informative)
It is a little early in the game to have such grandiose expectations. Fortunately the developers appear more level-headed. Still, they too might be letting their enthusiasm get ahead of them
After a brief skim of Mark Thomas's paper, I have a number of concerns with the direction the project is taking. Up front I'll admit to being heavily influenced by the Cocoa libraries from Apple/NeXT, but they are light years ahead of everything else.
I have been programming Cocoa for three years now, mostly in my own time between course work. I am just starting to learn X in school, and let me tell you, it is a depressing step backwards. There is no doubt that X is in sorry need of replacement, for the sake of programmer effectiveness as well as for feature parity.
Still, you cannot just start up a new replacement project willy nilly and expect not to fall into all of the same traps. I'm sure that the X developers felt that they were future-proofing to some extent, and they must have succeeded, but why start up a whole new project just to end up in the same place in another ten years? You might as well just work with what you have.
Alternately, if this is a research project to explore new design principles, then I wholeheartedly encourage the team. In which case it is even more important for them to set out their goals and project development order, otherwise it's unclear how they will be able to assess their own success.