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.
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
#
Would you people please stop seeing this project as a X replacement (by which I mean that it is yet another X implementation, much like the freedesktop.org implementation)? By taking simple cursory glance at the website, I've easily determined that the relationship between X and Y is more like the relationship between *nix and Plan 9. This is an evolution of the graphical subsystem on *nix, not a replacement for X. It frees itself from the limitations of the architecture and mindset of X to take advantage of new hardware and ideas for graphical interfaces.
// file: mice.h
#include "frickin_lasers.h"
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?
It's interesting that you choose X extensions as the primary thing to bang on. It could be argued that X extensions are somewhat akin to kernel modules, but I don't see huge numbers of people clamouring for a return to the days when all your device drivers had to be built and linked specifically into the kernel rather than dynamically loaded on demand when they were needed. My Linux boxes here need 20+ kernel modules to work properly, so how do X extensions differ? Yes, some of them are pretty much bags hung on the side, but the core functionality of X is still available without, well, nearly all of them.
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.
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.