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.
At long last! (Score:0, Insightful)
Good timing (Score:2, Insightful)
good idea but wrong reason (Score:0, Insightful)
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
My, aren't we opportunistic. (Score:5, Insightful)
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.
What sort of compatibility? (Score:4, Insightful)
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)?
diversity is good (Score:3, Insightful)
Re:At long last! (Score:5, Insightful)
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?)
Who? (Score:0, Insightful)
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?
Encouraging (Score:5, Insightful)
Re:My, aren't we opportunistic. (Score:4, Insightful)
My pet peeve is antialiasing. You don't get it at the X-windows level, you have to build it into your app! That's why, shamefully, things like emacs look much better on Windows than on Linux.
YAANXR (Score:1, Insightful)
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.
Re:At long last! (Score:5, Insightful)
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.
Re:Call to Programmers (Score:3, Insightful)
Re:My, aren't we opportunistic. (Score:5, Insightful)
Re:Common toolkit (Score:5, Insightful)
Finally? (Score:5, Insightful)
Re:What sort of compatibility? (Score:5, Insightful)
Oh, and plenty of people still display X applications remotely. Have you set foot in any universities recently? Plenty of sites have central UNIX hosts available for people to run stuff on and display via their PC or whatever, because not everybody can have (or indeed wants) a UNIX box on their desk.
Finally, X has one thing going for it above all else at the moment - ubiquity. You can get an X server to run on more or less everything. Pipedreams about single-handedly replacing X are fine if you assume that every machine using X is a desktop Linux box, but when you take all those old VMS machines, PCs running eXceed, Suns, HP/UX boxes, and the zillions of weird applications that would still need to work properly across a wide variety of platforms, it's definitely more than "simply replacing X". You're talking about something that's more or less on the scale of replacing TCP/IP, and I don't see many people casually announcing that they're going to do that as a final year project.
Re:At long last! (Score:4, Insightful)
"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.
Re:What sort of compatibility? (Score:4, Insightful)
When something designed 20 new ideas ago is so extensible that it still fits in the modern world, perhaps they did the thinking right the first time.
Re:At long last! (Score:5, Insightful)
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.
Re:At long last! (Score:4, Insightful)
Come the revolution we'll be glad for it.
Now obviously some people do run applications remotely, but most don't. Therefore I wonder if X (or Y) shouldn't be run rootless on top of a fast local desktop rather than drag the whole desktop down by running underneath it.
Re:What sort of compatibility? (Score:2, Insightful)
Fuckin everyone who hasn't grown up in a PeeCee microuniverse of ignorance. I'm serious. I use remote X every single damn day. Remote X is essential to UNIX networking. Do you really and truly want a KVM network to sit in parallel to your Ethernet? Do you really??????
Re:Anyone else hate the term "X Windows"? (Score:1, Insightful)
What license (Score:3, Insightful)
Re:Good timing (Score:1, Insightful)
Maybe X Windows will switch to their old license.
Re:At long last! (Score:5, Insightful)
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.
Re:What sort of compatibility? (Score:5, Insightful)
Re:Yet Another Amusingly-Named X Replacement (Score:3, Insightful)
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.
Re:Common toolkit (Score:5, Insightful)
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).
Continued Misconceptions (Score:3, Insightful)
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?
What Y will need... (Score:3, Insightful)
Re:At long last! (Score:4, Insightful)
The Y proposal is very evolutionary. It uses the collective experience gained from the successes and failures of X to build a better mousetrap. I would certainly expect it to improve upon what X does while keeping those things that work and work well. A LOT has changed in terms of tools, technology, and know-how since X was designed... why not put those idea to work in a new system?
Migration strategy? anyone got one? (Score:3, Insightful)
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
You have got to be kidding me?? (Score:2, Insightful)
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!!!
Re:More comments on X History (Score:2, Insightful)
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.
Why force a consistent look and feel (Score:3, Insightful)
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?
HBHRe:OpenGL? (Score:3, Insightful)
Re:My, aren't we opportunistic. (Score:3, Insightful)
You think wrong. I think some implementations of X have issues, but I think the extremely extensible X protocol is just fine.
Linus was just one guy when he started work on Linux. Other people then joined in, and made Linux what it is today.
But Linus wrote his system to follow existing standards, which was a large part of the key to its success. I'd be much more impressed if you said "XFree86 sucks, so we're going to write a new version of X from scratch". That would be a project more like Linux. That would also seem to me to be a whole lot more likely to result in something useful in a reasonable about of time (like, while I'm still alive). Fortunately, the freedesktop project exists to do useful work while you guys run around trying to reinvent the wheel.
Sure, it'll be gratifying if we become popular, but that's not what we've set out to do -- write good code.
Well, I can't fault you there. As long as you don't mind that I'm not going to be holding my breath waiting for your project to succeed.
I do think you should maybe tone down the "this is going to be the successor to X" rhetoric. I think "this is inspired by X" might be a more realistic assessment.
Why the Y Project is obsolete. (Score:4, Insightful)
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]
Re:About Y (Score:5, Insightful)
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.
And the point of all this is??? (Score:3, Insightful)
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
Re:Y _IS_ intended to replace X (Score:3, Insightful)
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.
Re:At long last! (Score:2, Insightful)
Microsoft have killed all competitors to come along by offering a favourable OEM price on windows/DOS only to vendors who ship every computer with a Microsoft OS installed.
Even IBM wouldn't bundle their own OS/2 on their computers because it would mean adding more than a hundred US dollars to the price of each machine they sold with windows on it.