by Anonymous Coward writes:
on Sunday August 17, 2003 @01:36PM (#6717512)
Frankly, it may be worth jettisoning a lot of the XFree86 baggage and starting anew.
Y [ic.ac.uk], an X Windows replacement, looks extremely well designed and this guy wrote a pretty complete implementation for his thesis.
Why not port the useful bits of X - like the hardware drivers - over to this already-established well-designed base instead of trying to hack XFree86 into something of similar quality?
(Well, the obvious answer, ``to keep the applications`` is fair enough. But a compatibility module wouldn't be too hard, and worth the benefit in the long run.)
Fresco, which got renamed to Berlin, which got renamed to Fresco, seems mostly delayed due to a schizophrenic attack.
Anyway, Fresco|Berlin is merely a GUI built on top of the GGI/GII interface. XGGI does much the same, but works with X instead.
The problem with X is that it is too bulky. We need a RISC GUI, with layers which supply the X API. GGI/GII seems like a good foundation. KGI does, too, but development with KGI is too stop-go.
Anyway, switching protocol isn't the solution. Neither is a simple re-implementation, or the addition of new code. What you need is a compartmentalization of the code, so that each part of the code can run efficiently and quickly.
Think of it this way:
X can't exploit clustering or SMP, because everything is built into one server, or packed into humungus libraries the size of a Moa (and about as fast)
Even though it's more modular, these days, there seems to be no feature to swap out modules that aren't actively in use, to conserve memory - they're brought in at load-time, not just-in-time
Even though X is client-server, X has no capacity to balance the workload according to the available resources of the client and server (a-la MOSIX)
There is very minimal "accelerated" code for specific processors or graphics cards, which is why it is much slower than many proprietary implementations. (Even the Gnu C Library has a fair chunk of accelerated code!!)
X is pixel-only, which makes using vectors, curved shapes, or indeed anything non-pixel, a horrible pain -- it also makes anti-aliasing horrible, as you can't supersample a quantized system
It's very very hard to take advantage of new features or capabilities with X, as the alpha-channel fans have discovered -- you can bolt onto it in a heirarchical manner, but X isn't very extensible laterally
I like the X protocol, but I think we should abandon the concept of having just one server that supplies the whole protocol and also nothing but the protocol -- break X into fast-acting independent components which can be added or removed on-the-fly, producing a protocol that is shifting to do exactly what you want, not merely everything the designers could think of
X can't exploit clustering or SMP, because everything is built into one server, or packed into humungus libraries the size of a Moa (and about as fast
Umm... stop me if I'm wrong, but processing power shouldn't be a significant factor in a GUI. If the thing's taking more than 5% of the CPU in the first place, something's very wrong (either a piss-poor skinning system or a broken GUI layer).
(Shudder!) You've never seen some of the code I've been hired to debug, then! Be very very grateful. (I reduced one GUI layer from 10 megs to 1, trippled the performance, and massively improved the maintainability. Then I was told that I'd just slaughtered 15 years worth of work by the company's pet development team.)
Fresco, which got renamed to Berlin, which got renamed to Fresco, seems mostly delayed due to a schizophrenic attack.
Schizophrenia [narsad.org] is a disorder characterized by delusions, hallucinations, disorganized speech and catatonic behavior. I'm guessing that's not what you had in mind?
When designing a replacement, it's worth giving thought to the relevant protocols for sound, and storage local to the machine the server is running on. That is, if I launch a server somewhere with, e.g. a local CD-ROM, the applications I use should be able to see and use the contents of the CD-Rom.
I have looked at Y before and i am sorry, but the idea of having complete standardization in interfaces is a windows like idea, and frankly not a very good one.
I have tried out 17 window managers before settling on one that i liked (Fluxbox [fluxbox.org]). If you standardize the wm, the next big thing will be hacks to over ride the default wm , and a windows like situation will ensue.
Yes, dropping alot of the baggage from X would be nice, but i dont thing that Y is the right idea.
Yes, but name another window manager where you can operate an Athlon-XP 1700 from a beat-up old thinkpad 385 (P5 100Mhz) at the speed of the Athlon? In fact, brainless X terminals still live on in Unix labs across the world.
You've never really worked with WTS/Metaframe, have you? They're kinda slow and -massive- resource hogs on the server end. A Linux server driving Xterms can support many more users comfortably than a Windows box driving citrix clients.
Why not just run Y and have an X-server program built for it for 'legacy' apps? You could also write a 'blank' window and use a foreign toolkit in a more 'raw' way. This isn't my field, so I might be wildly off-base.
I think the problem you'll run into is what part of XFree is "essental features" and what part is "useless baggage". You may not think much of network transparancy, but you may be shocked to learn that someone else figures there's no need for native GL support or monitor calibration baggage.
If I have seen farther than others, it is because I was standing on the
shoulders of giants.
-- Isaac Newton
Drop XFree86, use Y instead (Score:5, Informative)
Y [ic.ac.uk], an X Windows replacement, looks extremely well designed and this guy wrote a pretty complete implementation for his thesis.
Why not port the useful bits of X - like the hardware drivers - over to this already-established well-designed base instead of trying to hack XFree86 into something of similar quality?
(Well, the obvious answer, ``to keep the applications`` is fair enough. But a compatibility module wouldn't be too hard, and worth the benefit in the long run.)
Re:Drop XFree86, use Y instead (Score:1)
Re:Drop XFree86, use Y instead (Score:5, Interesting)
Anyway, Fresco|Berlin is merely a GUI built on top of the GGI/GII interface. XGGI does much the same, but works with X instead.
The problem with X is that it is too bulky. We need a RISC GUI, with layers which supply the X API. GGI/GII seems like a good foundation. KGI does, too, but development with KGI is too stop-go.
Anyway, switching protocol isn't the solution. Neither is a simple re-implementation, or the addition of new code. What you need is a compartmentalization of the code, so that each part of the code can run efficiently and quickly.
Think of it this way:
Re:Drop XFree86, use Y instead (Score:1)
Umm... stop me if I'm wrong, but processing power shouldn't be a significant factor in a GUI. If the thing's taking more than 5% of the CPU in the first place, something's very wrong (either a piss-poor skinning system or a broken GUI layer).
Re:Drop XFree86, use Y instead (Score:2)
Re:Drop XFree86, use Y instead (Score:2)
Schizophrenia [narsad.org] is a disorder characterized by delusions, hallucinations, disorganized speech and catatonic behavior. I'm guessing that's not what you had in mind?
Re:Drop XFree86, use Y instead (Score:2)
Re:Drop XFree86, use Y instead (Score:1)
I have tried out 17 window managers before settling on one that i liked ( Fluxbox [fluxbox.org]). If you standardize the wm, the next big thing will be hacks to over ride the default wm , and a windows like situation will ensue.
Yes, dropping alot of the baggage from X would be nice, but i dont thing that Y is the right idea.
Re:Drop XFree86, use Y instead (Score:3, Insightful)
That is what X was designed for.
Re:Drop XFree86, use Y instead (Score:1)
You've never really worked with WTS/Metaframe, have you? They're kinda slow and -massive- resource hogs on the server end. A Linux server driving Xterms can support many more users comfortably than a Windows box driving citrix clients.
What about an X server for Y? (Score:2)
Re:Drop XFree86, use Y instead (Score:2)
Re:Drop XFree86, use Y instead (Score:1)
At the risk of sounding glib, erm... "We will anxiously await hearing updates on your progress, then."
Re:Drop XFree86, use Y instead (Score:2)