Slashdot Mirror
Y Window System Project Started
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.
Three points:
a)it looks like the only reason development started again was because of all the Xfree86 licensing hubbub(which isn't going to be around much longer, because Xfree86 will most likely cave). If the project did not have the merits to succeed before, I do not see how things have changed in such a way that it will be successful long-term, and this was a blatant "look at me" attempt. Y was dead, FreeDesktop was humming along quietly.
b)Most of the "I'm going to replace Xwindows" projects are doing so because its supposedly "slow" and "bloated", and we see a large number of posts in every Xwindows-related story on slashdot claiming the same thing. Most of them are wrong.
c)We already have an interesting, viable alternative(FreeDesktop)...and it's got heavy involvement with the major developers of Gnome and KDE, the two most popular desktop systems. Everyone is playing Chicken with Xfree86, while hedging their bet(and strengthening their position with Xfree86) by starting work with FreeDesktop. Y is nowhere to be seen in all of this, especially if it's only got one guy- versus a whole group of some of the best Linux programmers around.
Please help metamoderate.
For the folks asking "What's wrong with X?", I suggest you seek out the X windows chapter of that seminal work on the subject, "The Unix Haters Handbook" by Simson Garfinkel, et al.
Me? I take a cue or two from the output of 'xdpyinfo'. When something requires more than 20 different extensions to fit in the modern world, it's perhaps time for a re-think.
But if Y is going to work, the some level of backwards compatibility might be reasonably expected. Personally, I would suggest library level shimming rather than protocol level (that is, Y windows should come with a libX11 that implements the X API but talks to a Y server).
I'm a little surprised, in fact, that Apple didn't do such a thing for OS X. Rather than toss in an X server, they could have supplied a libX11 that simply implemented all of the calls in DPDF. One less bell to answer, one less egg to fry.
An X server is still nice for remote display situations, but honestly: Who does that anymore (and could they not be accomodated with VNC)?
While we're at it, more questions:
1. How hard is it to port an application to Y? (Is Mozilla going to come any time soon?)
2. How fast is it on older machines/PDAs? Is it mostly designed for new, beefy systems? (I noticed the 3D accel stuff, but is it required?)
1. 2.
I would encourage students to look through the source code. To grasp and understand what goes on behind the scenes for a windowing system, before the project gets enormous. Besides the tar file is pretty small, maybe you can contribute while the project is in it's infancy and not intimidating.
"It takes many nails to build a crib, but one screw to fill it."
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.
Most agreed. If this project does take hold and considerable development efforts begin, I believe this could be the answer for Linux finally taking over on the desktop/workstation market.
X's bear of UI's make unnecessary duplicate effort on both parties (ie: KDE/Gnome). While they both might be good, a lot of code functionality is duplicated between them. If this was removed and put into the window server (Y), it could drastically improve usability and turnaround times for next development releases.
I think the $75,000 question is what can we (userbase) do to help promote the development and adoption of this? I, for one, would love to join the development team and if ample time is available, I just might do so. I highly encourage other coders who have time to spare to join as well.
# fuser -v
#
Programming can be fun again. Film at 11.
Don't DRI's GEM, XEROX Star, GEOS, DesqView, NeXTStep, BellCore's MGR, Sun NeWS, MultiTOS, AmigaOS, Plan 9 rio count, and Berlin/Fresco count?
"one thing MS has done well is ensure compatability "
Should read " enforce conformity "
OSS should support a standard "default" for things -- but still allow customization. I guess some people would argue that's what RedHat is.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
this is the question that is going to make or break y windows (or berlin or whatever the "next" window manager is)
if you want an example of a successful transition of a key technology look at two examples from apple. that's right, apple.
it was a lot of work to keep that backwards compatibility, but it's what made the transition work.
so. the lesson: invest a lot of time and effort into backwards compatibility. lots.
2 1337 4 u!
>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.
>X places to much burden on the programmer (XLib)
No argument that raw Xlib is a bit hard to use. That's why we have things like GTK.
>X has no standard
I have no idea what this means. X IS the standard for unix-like operating systems.
>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? Having been enhanced and debugged for 10 years is a big plus, rather than a minus.
In summary, X is just fine. Y may eventually be better, and they're welcome to try to get it there, but these arguments haven't won me over. It's wonderful to have alternative implementations to point out the flaws in existing systems (so that they in turn improve), but to say the new system is fundamentally "better", well, that's going a few better arguments than this.
Unified theming is great, as long as you don't touch any configuration options ever, seeing as how everything from fonts to colors to widget shapes and menus have to be set not once but twice. So yes, it looks decent in the exact default configuration. This is worse than Windows, where you can at least configure look and feel and have it applied universally. The closest thing to a solution (though it's a hack) that I've seen was the guy who implemented a Gtk engine that rendered using Qt (or was it the other way around?). At least then things will generally work.
But it's little things like Gtk2 reversing Cancel and OK buttons - mix apps, and all of a sudden half your apps have Cancel on the left and half have Cancel on the right. Great usability there. Yes, I realize you can probably configure all these things and tweak it all to actually be consistent and correct, but the process can take ages and lots of fudging with text files or finding utilities to change theme configuration (anybody else ever notice how impossible it is to change Gtk settings when you are running KDE? Maybe this is just a Mandrake thing, but it never works).
As for Windows - you are right, some of these apps do render custom widgets. But font rendering is always 100% consistent because it's not done separately at the toolkit level (and to me this is probably the most important visual issue for consistency - ever notice that even when Gtk and Qt should be rendering fonts the same there always seem to be minor differences?), and most apps still respect basic color schemes and menu choices (new Office-style menus aside). And at least the choices are generally aesthetically appealing and consistent with color schemes and so on - I can tolerate the Office-style menus, even if I don't love them.
Sorry if this came out as a rant, but I don't think I could disagree more about it not mattering. This Y project is making the right architectural decisions (or at least some of them, I dunno yet about the rest). Implement an X server for compatibility as an extension on top of the new system, and you can still run all the zillions of X apps out there until they've been properly replaced with Y apps, and you could get to the dogfood stage much sooner. I've known plenty of geeks who like Linux but don't use it as their day-to-day desktop OS in part because of the aesthetic issues I've mentioned above - and in part for other reasons, stability and performance of basic 2D rendering still sucking compared to Windows (at least when you use Gtk/Qt etc. - I realize that Xlib/Xaw/Motif and similar widget sets are extremely fast, but modern apps don't use them).
Y was designed to
a) learn something about network programming
b) implement a replacement for X11 of which Mark Thomas think that it is:
1) too slow
2) place too much burden on the programmer
3) no standard toolkit
4) reaching its software lifespan
5) too complex.
ad 1) It is correct that X11 is unusable on less than 10 Mbit connections (this could be changed, see below).
ad 2) Unless you use the raw network protocol, it does not place burdon on the programmer. It is true that everything above Xlib was ill design (especially the Xt, and athena widgets), but this crap has been replaced long before. -- The only environments that still use Xt are Motif and KDE apps. In contrast GTK and GNOME use the raw Xlib.
ad 3) It is true that the toolkit (Xt, Xaw etc) should have been implemented on the server-side. But this was not possible until now; what X11 indeed needs is a toolkit on the server-side. Of course this toolkit should be extensible, that means that it should be possible to dynamically add new widgets to the set of available widgets living in the address space of the X11 server. Moving the toolkit to the server would also reduce the network overhead thus addressing problem #1. Of course, this requires more memory on the server-side as the server must now be linked with an interpreter language such as Mono, Java, Guile.
Another drawback would be that the actual widget-communication protocol would essentially be proprietary.
Note that Y only defines a small set of widgets on the server-side and that there's no mechanism to dynamically extend this set. So the communication overhead with Y is almost the same as X11 (it may be better or worse in some areas).
4) I think it's clear that this is a nonsense argument. For example no one would seriously argument linux, as it is 10 years old now, has thus reached the end of its lifespan.
5) Yes, some functionality provided by the X11 client libraries and by certain X additions was complex. But most of this crap has already been thrown out, e.g.: Xprint, Xt, DisplayPostscript, the broken X11 I18N implementation.
What Y promises to deliver is:
1) A non-dynamically extensible object-based system on the server side implemented in raw C
2) A message passing system that is as efficient as X11's (it may be better or worse in some areas, see the Clock example which has a huge overhead).
3) Yet another toolkit implemented in C, but this time on the server-side
4) Modularity. This is indeed a strong point for the Y system (compared to XFree86). However, the new Xserver [www.freedesktop.org] attempts to address this issue, too.
5) A client library for C++. Whow. Ehm, what is wrong with Qt? Should all people throw away their work just because somebody thinks that some software has reached the end of its lifespan (whatever that may mean!)?
Anyhow, I suggest to read Mark Thomas proposal anyway. It isn't that bad; at least Y has a theoretical background; in contrast to other attempts such as picoGUI [www.picogui.org]
This may be an SFQ, but shouldn't the application choose its own look and feel?
I suspect that the outcome of this is a little less worrisome then you think. I really have no idea what this means, but I've been thinking of something along these lines with X for a while now, which may or may not be what Y is doing.
Currently to draw an input box in X, at the protocol level there is a lot of work -- lines must be drawn, areas filled with color, a font must be selected, and any existing text must be entered in. Subwindows for accepting user input are defined, events to control focus, mouse, and keyboard are captured and transferred back and forth. GTK hides this from the programmer by defining a function to call to do all that for the user, but all of this is done on the local GTK library in the client, either by rendering into a pixmap and transmitting the whole pixmap to the server, or by breaking it down into the above mentioned components and transmitting those instructions.
Now, imagine if the X server itself was linked to GTK. That entire protocol stream of traffic can be reduced to a single command "draw a gtk text box here of this size with this starting text in this font" many of which can be defaults. Beyond just the savings in that initial display of the widget, the number of events can be drastically cut down as the server-side gtk library now handles the events that deal strictly with the operation of the widget. The end result is something like HTML and javascript. You could define a dropdown box which only has one event with the client software after the initial construction: "onchange". All of the clicking and picking items could be done within the server itself.
The biggest issue with this is making sure that the existing protocol never changes, only grows by adding new items (thus gtk-client 1.1 will work with gtk-server 1.2, just not use all the 1.2 features), otherwise versions everywhere must match or the thing goes down in flames.
If I have been able to see further than others, it is because I bought a pair of binoculars.