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 find it highly unlikely that I would consider another future desktop additions. It would be more prudent to patch and hack on the labors that have already been provided ensuring both stability and security before adding other extensions. The whole damn planet has gone desktop happy.
Would you care to explain why the new X licence is better then the GPL licence (which is what you imply)? I don't feel I know enough about the subject to comment either way, but when making a contentious (on /. at least) statement like that it'd be helpful if you could explain your reasoning! (And I'm curious anyway ;-) )
Thank God. Finally, someone has decided to quit bitching about X Window and finally implement a system of their own.
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
Did you ever notice that *nix doesn't even cover Linux?
Fantastic. New users find the selection of different toolkits for X confusing and inconsistent both in appearance and behaviour. One standard toolkit will help with newbie usability greatly - though whether it will stand the test of time remains to be seen. Windows seems to be doing just fine with it's standards though, so I rather suspect the same will apply to Y.
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!
biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
So why is it going to succeed where these failed? :
fresco
YAX (Y Ain't X)
The Y Window System
Oh never mind. What's the point?
Stick Men
Apache2's default configuration doesn't scale gracefully to the load generated by a slashdotting.
I've upped various magic numbers in poolsize.conf and it appears to now be responding much faster.
Cheers,
David
I think a lack of standardization/uniformity is what's hurting the Open Source movement. You can't get that many people together, and have them agree on -one- way to do things. Everyone is out to push their own little twist. The result is a bit chaotic to anyone looking from the outside. (And to some from the inside as well, I'm sure.)
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.
About a year ago, I had started work on something I called YX (yes, the pun was intended). It didn't get very far, I'm glad that someone is working on such a project. I definitely intend to help with this project, though.
I have discovered a truly marvelous
Howdy.
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
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)
For Y to be remotely usable for me, it would need good support for OpenGL on nVidia and ATI graphics cards...for which (annoyingly) we only have binary drivers.
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.
www.sjbaker.org
One extra thing to consider would be configurability. My XF86Config file is a beast, since I have a laptop with three pointer devices, and S-Video and RGB connections out to the tv and projector. I can't reconfigure my video on the fly like I can with Windoze. Help!
>... 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 thing the are doing with Fresco? Fresco also has SVG.
> 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.
This may be an SFQ, but shouldn't the application choose its own look and feel? I have various Java apps, some use the Metal L&F and others use the Windows one. Why force me?
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!
Your statement is based on an implied statement something like this:
"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.
Free Online Dark Fantasy RPG - http://www.blackmud.com
I was at Stanford during the development of W/X, as a user of early version, but not a developer of X. It was a time of rapidly evolving technology, so some standards they guessed right, while others were kludges. The technology was the workstation, a computer small enough to put into the office (the size of half-height file cabinet) and enough power to run UNIX. PCs were way too underpowered to run UNIX and bit-mapped graphics. Apollo (absorbed into HP) was the UNIX king, but all its standards were proprietary. Sun was just a couple years old and its standards were half-open, half-proprietary- a practice they continue to this day. DEC (absorbed into HP) was willing to tolerate UNIX on its min-VAXes, but not write all the missing parts- especially window graphics. So they essentially delegated that to Stanford and MIT with hardware and R&D grants. So there was a lot of R&D then on how to do client-server computing and graphics.
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.