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.
...A replacement for my antiquated X Windows.
Maybe the XFree86 4.4 licensing problem would bring more people to using Y.
God, I hate this. Yes, X could do with replacing because it's very old and crufty, but I hate the fact that a major factor in people wanting to change is the X license change.
It's the GPL that should be changed, not the X license, but very few people are brave enough to admit it, because they don't want to distance themselves from their open source friends.
graspee
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)?
Yeah GPL and Xfree 4.4 may not be compatible with each other. but that doesn't mean one has to change for the other. that applies to both Xfree and GPL. If someone is starting a fork or a brand new project that doensn't mean its necessarily bad. Diversity is good. just like we have KDE and GNOME its better to have alternatives. Just my thought.
So how is Mark Thomas and why should we care about this? New GUIs are a dime a dozen these days. Unless he's the same Mark Thomas that is the comedian/satirist why should we care?
Oh whoopy. It's yet another GUI system that will die a slow lingering death because nobody will actually use it... X is slow, crufty and old but it works and is supported.
Can anybody say bad publicity attempt for a random project?
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 wonder how RMS would feel/feels about the fact that 1) and 2) are LGPL'ed. They really oughtn't be, in his world-view.
... and some modularity."
Option 3) is really kind of a joke, afaict. More of a McDonald's order than a programming project. "I would like
Still, this headlined Y project does seem to mostly be an attention-grab.
Not to be pedantic, but since X exists, this would have to be getting it right the second time, at least...
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?
Because "X Window System" is inconveniently long to say or type, and "X" is not sufficiently descriptive to be clear, people use the term "X Windows". I have no problem with this; everyone understands what is meant by it.
The Y web site doesn't tell me what license this is to be realeased under. Anyone here know?
Interesting question. I believe that technology is not the decisive factor (otherwise X would have been replaced years ago). Maturity is and critical mass of end users is too. Historically, unix systems came with X-windows. So all unix gui applications are written to work at least on that. There is no incentive for the developers of these applications to support experimental alternatives.
Consequently these alternatives rarely gain critical mass and are typically abandoned in a half finished state. Enough of a proof of concept to inspire other developers but typically too impractical to be of any use to end users. This is too bad because with the current state of XFree86, on the fly changing of resolution still is a novelty (not implemented in most mainstream distros) and so are many other features that ship ready to use with other popular windowing systems (for the past decade or so). If you hack your xfree86 system this way or that way you can bolt on most of the stuff but the point is that this is not an easy process and is mostly unsupported by tools. I clearly remember the days that you had to hack your xfree config file to get the bloody mouse working properly (a standard ps/2 wheelmouse). Currently most distros fix this by generating the config file themselves instead of using the crappy tools that come with xfree86. This seems to be the only way for linux vendors to pretend that xfree is easy to use.
I think it is both admirable and foolish to attempt to fix this. Predictably the attempt will fail. I have some hopes that the recent xfree fork might bring some changes. The whole licensing debacle might speed things up a little.
Jilles
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).
X isnt slow: What is layered on top is slow
X is a standard: People break that standard with layers on top.
XFree is old: My wife is over 10 years old too.. so what? ( X11 is even older )
Xlib sux: Ok, ill give you that one.. but programmers arent forced to use low level libraries.. Ever hear of QT?
---- Booth was a patriot ----
The essential program for Y which will let it get anywhere has to be an X server. Then people can migrate to it without being disconnected from their X applications. Something nice with a rootless mode, like X runs on MacOSX.
"You know you want me baby!" - Crow T Robot
Guys, the reason why we are all still using X is not because windowing systems are so hard to create, it is because we all have so much software invested in X now which would somehow need to be ported over.
No, an X emulation layer is not going to solve it. What is the point in having a new window system if all of my apps get bogged down by an emulation layer? Why bother?
I wish the Y developers the best of luck. But first they must put down their C++ compilers, crack open the source to Qt, GTK etc and have a good look inside and see how these toolkits work and realise that they can't change anything above this software layer. They can only work inside the widget toolkit layer and below. People (developers!) are not going to switch the toolkits their applications use.
--
Simon
Quick questions what's harder to rewrite? the legalese of XFree's newest licensing or a windowing system?
I don't think XFree will keep the language that's in the licensing once they get enough pressure from the distros.
A rewrite of something as complicated as X (and everything that depends on it!) Go read some joelonsoftware and get some opinions on ground-up rewrites.
I'd rather see concerted efforts to overhaul the driver effort and acceleration rather than recreate the world.
Rewrite X: booo!
Refactor X: yaaay!!!
Once again Stanford takes credit for stuff they didn't do. Sure they worked on W, but X whether you like it or not is MITs baby. Stanford did not decide on the Xt toolkit, it was MIT.
Stop with this whole Stanford nonsense, and please give credit where credit is due: MIT. (or blame whichever some people think may apply)
Also C++ nor ObjectiveC where used because of the perceived performance penalty. Remember C++ was perceived as being dog slow for years.
Because consistent look and feel is very important? Because it speaks volumes for the overall design that has gone into the OS? Because it's aesthetically pleasing?
One cannot put these things aside as unimportant, because they are surrogates for cues that people use on a day-to-day basis for things like selecting a mate or procuring products such as food. Some examples that spring to mind:
People are animals. Sophisticated and intelligent animals, but animals nonetheless. To treat the basic instincts we all possess as "trivial" is to ignore the basic truth of existence.
Maybe a quick experiment would help: drive up and down the strip in a late model civic with a nice paint job. Now repeat the process in a Ferrari which has every body panel painted a different color: yellow, red, silver, black, blue and white. Any idea which will get noticed for all the wrong reasons?
HBH"Smart is sexy." -- D. Scully ("War of the Coprophages")
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.
How many people swap out the engines in a car that still runs fine? How many people are still running Windows 98 on old hardware and will upgrade their OS when they buy a new PC?
Whether things freeze at XFree86 4.3, the X people return to sanity and things continue onto 4.4, or Y replaces X altogether... Joe User (especially at a corporate desktop) is going to notice the brand of underlying windowing system about as often as a husband notices the brand of shoes his wife is wearing.
The distros will make up their own minds. For the commercial ones, the default will be the one they feel helps their distro meet the qualifications of: does it go, does it look nice, and does it run on standard unleaded?
- Greg
Start a happiness pandemic
But there's a difference between a successor and a replacement. According to the grandparent, a replacement would be another implementation of the X standard. Y is an attempt at an implementation and definition of a new windowing standard.
It is a replacement for X, in that it performs the same role, but it's not a replacement for X, in that it doesn't fulfil its role in the same way.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face