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.
Why Windows? (Score:5, Funny)
Sounds more like... (Score:5, Funny)
Abbot: Are you using X Windows?
Costello: No, Y
Abbot: I just want to know
Costello: Y
Abbot: Look, All I want to find out is what controls your display?
Costello:: I just told you?
Abbot: Told me what?
Costello:: No, "What" is the name of the window manager....
Abbot: I am not talking about the window manager!
Oblig (Score:5, Funny)
Skinner: Not the interrogative, but rather a windowing system with the unlikely name of "Y".
Chalmers: Well that's just great, Seymour. We've been out here six seconds and you've already managed to blow the routine.
[storms off, muttering] Sexless freak.
Re:Why Windows? (Score:4, Funny)
Amazing.... (Score:5, Funny)
Re:Amazing.... (Score:5, Interesting)
I've upped various magic numbers in poolsize.conf and it appears to now be responding much faster.
Cheers,
David
Re:Amazing.... (Score:5, Funny)
Stuff (Score:3, Funny)
(aahhadabahahah why windows)
Re:Stuff (Score:3, Informative)
Re:Stuff (Score:3, Funny)
Hmm...lemme give that a try.
C:\Documents and Settings\donutz>apt-get install w3m
'apt-get' is not recognized as an internal or external command, operable program or batch file.
Oh well no fun for me
Re:Stuff (Score:5, Funny)
Y-Not? (Score:3, Interesting)
The XFree consortium already has this (Score:5, Funny)
So basically it's "Y-XFree86", right? There might be prior art here, I've heard people say that for years.
Re:The XFree consortium already has this (Score:5, Funny)
Countdown (Score:5, Funny)
Quickly followed by a name change to "Y-windash".
Yawn.... (Score:5, Funny)
Re:Yawn.... (Score:4, Funny)
Y's installed (who's on first?) (Score:3, Funny)
2: No. Y.
1: I was just wondering, what do you use?
2: Y!
1: I'm just curious, now will you please tell me what you use if you don't use X?
2: Y!
ok, that was sorta lame, how about...
tech Support: What desktop environment do you use?
user: ummm why?
tech: You use Y? Ok, so what you wanna do is...
user: What? I don't know what you're talking about.
Re:Y's installed (who's on first?) (Score:5, Funny)
Call to Programmers (Score:5, Interesting)
For any programmers out there that are even remotely interested in getting Linux On The Desktop, consider this a call. A super-awesome rock solid kernel cannot be the end-all be-all for Linux. We need to have a good windowing system, one that's faster and more reliable than the competition. From what I know, X Window could use a great amount of improvement in those areas. This is your chance to make things better, and Get It Right The First Time.
--Stephen
Re:Call to Programmers (Score:3, Insightful)
Re:Call to Programmers (Score:5, Funny)
Finally? (Score:5, Insightful)
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!
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.
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.
Re:My, aren't we opportunistic. (Score:5, Informative)
Re:My, aren't we opportunistic. (Score:5, Insightful)
Re:My, aren't we opportunistic. (Score:5, Funny)
Oh, you mean kinda like a replacement?
Y _IS_ intended to replace X (Score:5, Informative)
Re:My, aren't we opportunistic. (Score:3, Interesting)
Did you read the bit at the top? "I was on holiday in Japan when the story b
Re:My, aren't we opportunistic. (Score:5, Interesting)
You make some reasonable points.
A development restart has been planned for months; the only reason it hasn't happened sooner is that we've all been settling into new jobs and simply haven't had the spare time to get this going properly until now.
X Windows *does* have issues; I think we can all agree on that. But by the same token, we're not trying to argue that X is not useful; I'm using XFree86 on my production machine right now to good effect. But we think it can be done better.
Linus was just one guy when he started work on Linux. Other people then joined in, and made Linux what it is today.
Mark, myself, and the other chaps who were in the room when the Y concept was born are doing this because we enjoy it. Whether lots of people will join in on our little project remains to be seen.
Sure, it'll be gratifying if we become popular, but that's not what we've set out to do -- write good code.
Cheers,
David
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:About Y (Score:5, Funny)
Bah, those are the same people who designed the Death Star. Won't Y have the same design flaws?
Re:About Y (Score:5, Funny)
Re:About Y (Score:3, Interesting)
>... 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).
Great idea - is this the same th
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.
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)?
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: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:What sort of compatibility? (Score:3, Funny)
Good to see those guys back together again. I wonder if "The Unix Hater's Handbook" will be as good as "Bridge Over Troubled Waters".
Re:What sort of compatibility? (Score:3, Interesting)
Current remote X server: 272 MB. Remote (tight)VNC server: 60 MB.
Local X server: 161 MB: Local (tight)VNCviewer: 4 MB.
vnc here runs faster than running X remotely. my guess is that it's because VNC is mostly client-pull/server push oriented.
Re:What sort of compatibility? (Score:5, Insightful)
Common toolkit (Score:4, Interesting)
There is nothing like a little competition to hot things up - perhaps this will also give the languid Xfree86 project the kick up the backside it needs.
I wish the Y project the best of luck!
Re:Common toolkit (Score:5, Insightful)
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).
Yet Another Amusingly-Named X Replacement (Score:5, Interesting)
fresco [fresco.org]
YAX [linux.org] (Y Ain't X)
The Y Window System [hungry.com]
Oh never mind. What's the point?
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 o
name change suggestion... (Score:5, Funny)
CB
Re:name change suggestion... (Score:4, Funny)
or it could be:
yinx (yinx is not x)
for added confusion!
CB
Encouraging (Score:5, Insightful)
Interesting (Score:3, Interesting)
IRC channel... (Score:5, Informative)
CB
What license (Score:3, Insightful)
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
OpenGL? (Score:5, Interesting)
So - my questions would be:
1) Can Y use GLX protocols and work with existing (binary only) OpenGL drivers?
2) There is mention that Y can use hardware accelleration on 3D hardware. My concern about this is how much of the valuable 3D resources such as texture map memory it consumes. Generally, X runs plenty fast enough without using those resources and I wouldn't want to impact my 3D capabilities in order to make the 2D windowing system run ten times faster than it really needs to run.
Certainly X needs updating - it's old and it shows it's age.
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 :-)
Y?!? (Score:3, Funny)
: )
*Sigh* (Score:5, Interesting)
Here I sit back, reading slashdot on a pentium 166MMHX, with 80M of memory, through Galeon and the X Windows System on a OpenBSD machine.
I read the posts that say X is slow.
X is currently using about 5% - 7.5% of my processor. It jumps up to about 15% when I change windows. MPG123 consistantly uses more CPU then X. Galeon tends to use more CPU then X as well.
I read the posts that say X is bloated.
X is currently using 15MB of memory/8MB resident. Galeon is using about 16MB / 27 MB resident.
As for hard to set up, linux distros usually set up X for me. There are even several configuration utilities shipped with XFree86.
I also tend to use the network transparency of X, which is easily accomplished through ssh -X.
Don't know why you guys keep having problems, but may I suggest bloated OS installs and bloated WMs?
FVWM + XFree86 works for me!
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...
Re:*Sigh* (Score:5, Interesting)
I used to run X11 on a 486 with 16MB of RAM. Ran fine on that too. The basic X Window System today is no bigger than it was when I had the 486, although the toolkits (GTK or Qt) are rather larger than in the 486 days (Openlook or Motif, or (gah) Xaw).
what I want to know is ... (Score:4, Funny)
I'm also writing an X replacement. (Score:4, Funny)
Mine has a built-in web browser, MIME extractor, yEnc support and a display engine optimized for fleshtones.
I call it "The XXX Windowing System".
Y runs on X! (Score:4, Informative)
The implementation language... (Score:4, Funny)
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:Women's Windows (Score:5, Informative)
Re:Women's Windows (Score:4, Funny)
If it had been called "Y Don't You Do The Dishes, Bitch" then we might be laughing with you, and not at.
HTH -- ~Darl
Re:Women's Windows (Score:3, Funny)
find / -name *base* -exec chown us:us {} \; su -c someone 'export UP_US=thebomb' for f in great justice ; do sed -e 's/zig//g'
Re:At long last! (Score:4, 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.
Re:At long last! (Score:5, Interesting)
Hate 'em as much as I do, the one thing MS has done well is ensure compatability. Obviously there's problems; but the basic principles of windows applications are near uniform. I don't think you can say the same for a lot of OSS. Chalk it up to people being sheep, if you want, but until there's one clear leading force, Linux (sadly) won't succeed on the desktop.
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:At long last! (Score:4, Interesting)
You are simply citing the differences between OS and any company.
In Open Source Development there is a Naturally driven variations. Think if it as leaves driven before the wind. Eventually most of them end up in the same place.
With any company, you do as the boss says or you're toast. Any questions?
I think there is a lot of merit in having variations in WindowManagers. I will fight that to the death. But when you have to apply layer upon layer of Glue Code to get some really useful, it implicates a problem exists. And when the various solutions are all inconsistent and independently parallel to each other, you have another implication of a potential problem.
If done correctly, most of this new code implimentation wouldn't require a visual (user aware) change to any of the existing Window Managers. However it might provide for a more consistent approach so that all buttons, labels, etc. appear the same. Today that doesn't exist unless you choose to use only a certain base library for your graphics (eg: Qt)
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: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:At long last! (Score:3, Interesting)
As long as it's network transparent I don't care either. If I can tunnel apps over my SSH connection from one box to another then it's pretty useless for me no matter how fast it is.
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: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?
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.
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?
Re:At long last! (Score:5, Funny)
Xfree86 is over 10 years old
And that means it shoud be scrapped? Win32 is also over 10 years old, do you think we should just scrap that too?!?
Oh, wait... point taken. I'm going to go download Y now.
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?)
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:5, Funny)
Simple, Y is One Better.
Just like my amplifier, which goes to 11.
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.
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.
More comments on X History (Score:5, Interesting)
The primary problem at that time was the availability of a suitable object-oriented programming language. Everyone knew that was the future of software. The UNIX crowd preferred something related to C. C++ was very unstable, while ObjectiveC, based on on SmallTalk, was good but proprietary. The fledgeling company NeXT (in the Stanford industrial park, later absorbing Apple Computer) decided on ObjectiveC. The Stanford W/X group decided to use neither of these but invent a quasi OOP extension to C in the Xt Toolkit. And XWindows has suffered ever since.
Re:History of X (Score:5, Interesting)
"Most people do not often need network display in their windowing systems. Most X users dont use network display."
To which I respond, "Most of the peolpe I know who use X, use remote display daily. I personally use remote display daily. One of X's biggest strengths is remote network displays."
I am not necessarily a valid statistical sample and I am well aware of it. For MANY people, your statement is true, but there are a LOT of other people for which it is false.
On the other hand, your point that having a local-only core with a remote module for those who need it is ok. I agree with you as long as the protocol directly supports it and I dont have to have special software on the client but rather I just have to add a local module to use it.
Re:good idea but wrong reason (Score:5, Interesting)
Re:good idea but wrong reason (Score:5, Funny)
It should be more like a tiger-- going out and hunting down other code to kill.
Re:good idea but wrong reason (Score:4, Interesting)
Re:good idea but wrong reason (Score:5, Informative)
diversity is good (Score:3, Insightful)
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: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: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:Not his masters degree (Score:3, Informative)
Re:Not his masters degree (Score:3, Interesting)
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" abou