Discussion:
replacing X Window System !
(too old to reply)
linux cbon
2006-05-16 21:41:48 UTC
Permalink
hi,

I know it may not be the best place, sorry for that.

X Window System is old, not optimized, slow, not
secure (uses root much), accesses the video hardware
directly (thats the kernel's job !), it cannot do VNC,
etc.

The question is : what are your ideas to make a system
remplacing X Window System ?

I think that linux kernel should contain a very basic
and universal Window System module (which could also
work on Unixes and BSDs) to replace X, X.org etc.

What do you think about this ?

Thanks









=09

=09
=09
_______________________________________________________________________=
____=20
=46aites de Yahoo! votre page d'accueil sur le web pour retrouver direc=
tement vos services pr=E9f=E9r=E9s : v=E9rifiez vos nouveaux mails, lan=
cez vos recherches et suivez l'actualit=E9 en temps r=E9el.=20
Rendez-vous sur http://fr.yahoo.com/set
Michal Piotrowski
2006-05-16 21:51:41 UTC
Permalink
Hi,
Post by linux cbon
hi,
I know it may not be the best place, sorry for that.
X Window System is old, not optimized, slow, not
secure (uses root much), accesses the video hardware
directly (thats the kernel's job !), it cannot do VNC,
etc.
The question is : what are your ideas to make a system
remplacing X Window System ?
I think that linux kernel should contain a very basic
and universal Window System module (which could also
work on Unixes and BSDs) to replace X, X.org etc.
What do you think about this ?
Thanks
It's a bit off topic here.
Please try on Linux Visionaries Mailing List
http://blackwhale.net/cgi-bin/mailman/listinfo/lvml

Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
Måns Rullgård
2006-05-16 21:57:36 UTC
Permalink
Post by linux cbon
hi,
I know it may not be the best place, sorry for that.
X Window System is old,
Still being around might suggest that it has some merit, no?
Post by linux cbon
not optimized,
Wrong.
Post by linux cbon
slow,
Wrong.
Post by linux cbon
not secure (uses root much),
Would you prefer to give any random user direct access to the hardware?
Post by linux cbon
accesses the video hardware directly (thats the kernel's job !),
Debatable.
Post by linux cbon
it cannot do VNC, etc.
Most programs can't do VNC.
Post by linux cbon
The question is : what are your ideas to make a system
remplacing X Window System ?
Pointless.

--=20
M=E5ns Rullg=E5rd
***@inprovide.com
Alistair John Strachan
2006-05-16 23:23:55 UTC
Permalink
[snip]
Post by Måns Rullgård
Post by linux cbon
it cannot do VNC, etc.
Most programs can't do VNC.
I must also note that this is wrong. Many VNC implementations come with=
the=20
Xvnc server (a drop-in replacement for X, headless) and there's the xf4=
vnc=20
project which provides a few pseudo-devices for a regular X session and=
hooks=20
into the video updates (which are then sent via VNC as well as directly=
to=20
your video hardware).

--=20
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
alan
2006-05-16 22:19:16 UTC
Permalink
Post by linux cbon
hi,
I know it may not be the best place, sorry for that.
X Window System is old, not optimized, slow, not
secure (uses root much), accesses the video hardware
directly (thats the kernel's job !), it cannot do VNC,
etc.
The question is : what are your ideas to make a system
remplacing X Window System ?
I think that linux kernel should contain a very basic
and universal Window System module (which could also
work on Unixes and BSDs) to replace X, X.org etc.
What do you think about this ?
This is a topic that comes up every year or so. Every year the result is
the same. It is not going to happen.

First of all, your assumptions are incorrect. Modern versions of X are
not old, unoptimised, will do remote sessions, etc.

There are a couple of very hard problems here.

First you have to come up with a design that is better than X. That is
pretty hard. Next you have to convince all the programmers to port their
code over to use your new spiffy API. That is even harder.

Until you have a working model, or at least a design, you can blue-sky all
you want. It won't get anywhere and just waste other people's electrons.
--
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis
V***@vt.edu
2006-05-16 22:42:52 UTC
Permalink
Post by alan
First of all, your assumptions are incorrect. Modern versions of X are
not old, unoptimised, will do remote sessions, etc.
Remote sessions have been there as long as the DISPLAY environment variable - I
think even X10.4, 2 decades and more ago, could do that. I know that it worked
just fine 18 years ago with X11R1 (aah... building that from source on a 25mz
Sun3 took a little while). (Anybody know when the first instance of
pointing 'xmelt' at another user's machine for amusement was? :)

It's interesting that almost every attempt to devise something "better than X"
always seems to get as far as an Xterm-alike, an XClock-alike, a primitive
window manager, and 2 or 3 toy demo programs. Then, unless you're Microsoft
or Apple, you discover that doing a complete window system is *hard*.....
alan
2006-05-16 23:05:25 UTC
Permalink
Post by V***@vt.edu
Post by alan
First of all, your assumptions are incorrect. Modern versions of X are
not old, unoptimised, will do remote sessions, etc.
Remote sessions have been there as long as the DISPLAY environment variable - I
think even X10.4, 2 decades and more ago, could do that. I know that it worked
just fine 18 years ago with X11R1 (aah... building that from source on a 25mz
Sun3 took a little while). (Anybody know when the first instance of
pointing 'xmelt' at another user's machine for amusement was? :)
Yep. I know. Most people don't seem to know that X was designed to do
remote connections very early on.
Post by V***@vt.edu
It's interesting that almost every attempt to devise something "better than X"
always seems to get as far as an Xterm-alike, an XClock-alike, a primitive
window manager, and 2 or 3 toy demo programs. Then, unless you're Microsoft
or Apple, you discover that doing a complete window system is *hard*.....
"Those who do not learn the lessons of X are doomed to reimpliment them
badly."
--
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis
linux cbon
2006-05-17 11:47:22 UTC
Permalink
hi,

X Window System has many problems affecting directly
the kernel.

http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms=
_of_X
-Many current implementations of X manipulate the
video hardware directly.
-X deliberately contains no specification as to user
interface or most inter-application communication.
-The X protocol provides no facilities for handling
sound,
-Until recently, X did not include a good solution to
print screen-displays.=20
-One cannot currently detach an X client or session
from one server and reattach it to another.

I would add :
-X needs to be root so it opens many security holes.
-X has more code than the kernel and it is almost an
OS in itself.
-if a "closed-source" graphical card driver has
security holes, what do you do ?
etc.

Some people are working on replacement like Y windows
:
http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pd=
f
http://www.y-windows.org/

There are some questions like :
- should the next generation window versions Y,Z etc.
remain backward compatible with X ?
I think they should start something better and simpler
from scratch and not backward compatible.
- should the kernel remain pure "shell" or include
some basic universal graphical universal window system
?
I think second answer.


Regards.












=09

=09
=09
_______________________________________________________________________=
____=20
=46aites de Yahoo! votre page d'accueil sur le web pour retrouver direc=
tement vos services pr=E9f=E9r=E9s : v=E9rifiez vos nouveaux mails, lan=
cez vos recherches et suivez l'actualit=E9 en temps r=E9el.=20
Rendez-vous sur http://fr.yahoo.com/set
V***@vt.edu
2006-05-17 12:18:55 UTC
Permalink
Post by linux cbon
- should the next generation window versions Y,Z etc.
remain backward compatible with X ?
If it isn't backward compatible, people won't use it. X may suck,
but it doesn't suck hard enough that people will abandon all their
currently mostly-working software.
Post by linux cbon
I think they should start something better and simpler
from scratch and not backward compatible.
Feel free to write it. Keep in mind that X doesn't even try to do
widgets - those are done in userspace libraries. Let us know when you
have enough functionality to make converting worth thinking about.
Post by linux cbon
- should the kernel remain pure "shell" or include
some basic universal graphical universal window system
I think second answer.
Actually, you've proved the opposite. Consider if the kernel had *already*
included some universal window system (we'll call it W). At that point, you
can't easily write an X, Y, or Z if you don't like W. If anything, the
*current* W (which happens to be called X11) is *too* friendly with the kernel
already - witness all the headaches dealing with DRM and 'enable' attributes
and other hoops things have to jump through.

If anything, there should be even *less* kernel support for graphics.
That way, writing a Y or Z (or improving X) is easier to do without
destabilizing the kernel.
linux cbon
2006-05-17 12:39:37 UTC
Permalink
Post by V***@vt.edu
=20
If it isn't backward compatible, people won't use
it. X may suck,
but it doesn't suck hard enough that people will
abandon all their
currently mostly-working software.
If we have a new window system, shall all applications
be rewritten ?
Post by V***@vt.edu
Actually, you've proved the opposite. Consider if
the kernel had *already*
included some universal window system (we'll call it
W). At that point, you
can't easily write an X, Y, or Z if you don't like
W. If anything, the
*current* W (which happens to be called X11) is
*too* friendly with the kernel
already - witness all the headaches dealing with DRM
and 'enable' attributes
and other hoops things have to jump through.
=20
If anything, there should be even *less* kernel
support for graphics.
That way, writing a Y or Z (or improving X) is
easier to do without
destabilizing the kernel.
My idea is that the kernel should include universal
graphical support.
And then we would NOT need ANY window system AT ALL.
We wouldnt have 2 os (kernel and X) at the same time
like now.
It would be faster, simpler, easier to manage etc.






=09

=09
=09
_______________________________________________________________________=
____=20
=46aites de Yahoo! votre page d'accueil sur le web pour retrouver direc=
tement vos services pr=E9f=E9r=E9s : v=E9rifiez vos nouveaux mails, lan=
cez vos recherches et suivez l'actualit=E9 en temps r=E9el.=20
Rendez-vous sur http://fr.yahoo.com/set
V***@vt.edu
2006-05-17 13:19:46 UTC
Permalink
Post by linux cbon
If we have a new window system, shall all applications
be rewritten ?
No. /bin/cat and /bin/ls will survive unscathed. However, if you
have a graphical application, it will need reworking. That's a LOT
of code.
Post by linux cbon
My idea is that the kernel should include universal
graphical support.
And if we discover the API is wrong, or there's a bug, what then?

Or if you just want to try a different window manager?
Post by linux cbon
And then we would NOT need ANY window system AT ALL.
And if Gnome is in the kernel, what do all the KDE and Enlightenment
users supposed to do?
Post by linux cbon
It would be faster, simpler, easier to manage etc.
It wouldn't be faster, and it wouldn't be simpler, and it wouldn't be
easier to manage.

Come back when you've examined all the code in libX11 (that's just *one*
of the libraries), and identified *all* the locking issues, put in
schedule() calls at all the right places to allow pre-emption, and converted
it to use only 16K of stack space (that's *generous* - if it were in the
kernel, it would have a lot less than 16K available).

And consider that currently, you can update your kernel and usually not
need to make much change to your Xorg source tree, and vice versa. A bug
in Xorg doesn't force a kernel upgrade. Now imagine that you hit a bug
in Xorg that's fixed in the 2.6.28 kernel - but releases after 2.6.26 don't
boot on your hardware because of a bug with the SATA disk controller you
have.

And if my X server dies on me, I don't usually need to wait for the
entire system to reboot. If it was in the kernel, it just became a
panic/reboot rather than "init respawns gdm and life goes on".

I'm idly wondering how many years of actual system kernel hacking and
sysadmin experience you have - I know for a fact that I've been doing it
for a living since well before many frequent posters to this list were
even born (Hi, Kyle! :) And the single most important point I've learned
in almost 30 years of making a living at it is:

There is *nothing* that ruins a sysadmin's entire week as badly as a
lengthy pre-req chain. "We need to upgrade A, but that requires a new
release of B, which means we need to upgrade C as well, but the next
release of C won't work with hardware J of ours...". People who
complain about Red Hat systems having "pre-req hell" with RPMs are
wimps - I've *never* seen a pre-req chain since Red Hat 7.0 that was more
than 5 or 7 RPM's deep. IBM's AIX 3 often had pre-req chains over
100 deep - I once had a *single* bugfix against one /etc script replace
*literally* over 3/4 of /usr....)
Lennart Sorensen
2006-05-17 13:24:03 UTC
Permalink
Post by linux cbon
If we have a new window system, shall all applications
be rewritten ?
Unless you make your new system compatible with X, then all X
applications must be rewritten.
Post by linux cbon
My idea is that the kernel should include universal
graphical support.
And then we would NOT need ANY window system AT ALL.
We wouldnt have 2 os (kernel and X) at the same time
like now.
It would be faster, simpler, easier to manage etc.
So if I get a new video card I have to get a new kernel? Why can't I
just get an updated display system if my kernel works just fine. RIght
now I can boot any VGA compatible card (and many others) to text mode
and work on my system, while I figure out how to get X going on my new
card. If it was all in the kernel I am screwed if the kernel doesn't
yet support doing graphics on my new card. I know that problem from
using Windows, although at least it eventually got better at falling
back to VGA only mode if it couldn't work with a new card.

Len Sorensen
Lennart Sorensen
2006-05-17 13:20:13 UTC
Permalink
Post by linux cbon
X Window System has many problems affecting directly
the kernel.
http://en.wikipedia.org/wiki/X_Window_System#Limitations_and_criticisms_of_X
-Many current implementations of X manipulate the
video hardware directly.
Not a problem with X, just with some implementations.
Post by linux cbon
-X deliberately contains no specification as to user
interface or most inter-application communication.
Why should it? Let someone else deal with that. X has no business
getting involved in applications talking to each other.
Post by linux cbon
-The X protocol provides no facilities for handling
sound,
True. It is a display/input protocol. There are other protocols
that handle remote sound. There isn't really a reason they need to
be combined. X is event driven. Audio tends to require streams. Very
different tasks.
Post by linux cbon
-Until recently, X did not include a good solution to
print screen-displays.
Hmm, I guess I never noticed. Was this missed by anyone? Screen
captures were just fine as far as I can tell.
Post by linux cbon
-One cannot currently detach an X client or session
from one server and reattach it to another.
Some people have worked on ways to do that. Given things like DGA and
shared memory and such, some applications simply can't be detached
unless the application was written to support some kind of shutdown the
gui and then go connect to another X server and start the gui again.
Post by linux cbon
-X needs to be root so it opens many security holes.
Some implementations need to be root. I think it may be possible to run
a framebuffer based X without root, although you would also have to do
something about the keyboard and mouse drivers I imagine.
Post by linux cbon
-X has more code than the kernel and it is almost an
OS in itself.
So? That doesn't make it bad, it just has a lot of features and
includes a lot of utilities.
Post by linux cbon
-if a "closed-source" graphical card driver has
security holes, what do you do ?
etc.
Same as with anything else closed source. This is not a flaw in X.
Post by linux cbon
Some people are working on replacement like Y windows
http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf
http://www.y-windows.org/
- should the next generation window versions Y,Z etc.
remain backward compatible with X ?
I think they should start something better and simpler
from scratch and not backward compatible.
Lack of application support (which requires backwards compatibility) is
what dooms projects. If you don't want to be backwards compatible (just
through emulation is fine) then don't bother. Other than a fun hobby it
won't go anywhere ever. I think ALSA might have been doomed had it not
emulated OSS. By allowing emulation it slowly has gained support from
applications as they were ready to start taking advantages of the new
and improved interface. Linux evolves, which is why it's still here.
Starting from scratch almost never succeeds.
Post by linux cbon
- should the kernel remain pure "shell" or include
some basic universal graphical universal window system
?
I think second answer.
It should very much stay purely text based. Lots of systems have no
graphics abilities at all, and run linux very well. The simpler the
better for the kernel interface. The less special hardware support it
needs to show stuff to the user the easier it is to fix problems.

Windows is majorly annoying and broken that way. You can't really fix
anything if you can't boot as far as starting the GUI.

Len Sorensen
Felipe Alfaro Solana
2006-05-16 23:10:48 UTC
Permalink
Post by linux cbon
X Window System is old
Yep, but works pretty good. It allows for very smart and useful
things, like separating execution from presentation.
Post by linux cbon
not optimized
I wouldn't say so.
Post by linux cbon
slow
Slow? Have you ever seen Xgl?
Post by linux cbon
not secure (uses root much), accesses the video hardware
directly (thats the kernel's job !)
it cannot do VNC, etc.
What? You must be kidding. There's an X.org module which adds support
for VNC. It's built-in an I haved used it in the past to remotely
control some of my machines.
Ondrej Zary
2006-05-17 08:46:57 UTC
Permalink
Post by Felipe Alfaro Solana
slow
Slow? Have you ever seen Xgl?
It is slow. Just take any older machine (Pentium class), open any longer
web page in Firefox and scroll it up and down. Or open some other
window, move it around the screen on top of the Firefox window and see
how "fast" it really is. Then repeat the same in Windows.
How can Xgl help here?
--
Ondrej Zary
Carlos Silva
2006-05-17 09:59:11 UTC
Permalink
Post by Ondrej Zary
Post by Felipe Alfaro Solana
slow
Slow? Have you ever seen Xgl?
It is slow. Just take any older machine (Pentium class), open any longer
web page in Firefox and scroll it up and down. Or open some other
window, move it around the screen on top of the Firefox window and see
how "fast" it really is. Then repeat the same in Windows.
How can Xgl help here?
It helps! I hope that by "Windows" you ment Windows XP, cause Windows XP
on a pentium class machine, the box hardly boots, so i guess comparing
XGL and Windows XP on a current machine with a decent graphics card,
it's a good comparison. But not on a old machine, neither for windows or
Xgl.
Lennart Sorensen
2006-05-17 13:27:41 UTC
Permalink
Post by Ondrej Zary
It is slow. Just take any older machine (Pentium class), open any longer
web page in Firefox and scroll it up and down. Or open some other
window, move it around the screen on top of the Firefox window and see
how "fast" it really is. Then repeat the same in Windows.
How can Xgl help here?
Would a pentium class machine even run firefox on windows?

I think there is something very wrong with how firefox manages it's page
rendering and scrolling. It certainly eats a ton of ram with whatever
it is doing.

Len Sorensen

Döhr, Markus ICC-H
2006-05-17 00:01:45 UTC
Permalink
First of all, your assumptions are incorrect. Modern versions of X=
=20
are not old, unoptimised, will do remote sessions, etc.
=20
Remote sessions have been there as long as the DISPLAY=20
environment variable - I think even X10.4, 2 decades and more=20
ago, could do that. I know that it worked just fine 18 years=20
ago with X11R1 (aah... building that from source on a 25mz
Sun3 took a little while). (Anybody know when the first=20
instance of pointing 'xmelt' at another user's machine for=20
amusement was? :)
[...]

Although one has to admit that working with remote X terminals over a
SSH/WAN/VPN-connection is far from usefull, Microsoft=B4s RDP protocol =
does a
much better job there. However, there=B4s NX (http://www.nomachine.com/=
) and
other products but out of the box X11 it=B4s quite slow over higher lat=
ency
connections.


Just my EUR 0.02


SIEGENIA-AUBI KG
Informationswesen
=20
i.A.
=20
Markus D=F6hr
SAP-CC/BC, SAPDB-DBA

Tel.: +49 6503 917-152
=46ax: +49 6503 917-7152
E-Mail: ***@siegenia-aubi.com
Internet: http://www.siegenia-aubi.com=20
Måns Rullgård
2006-05-17 00:15:21 UTC
Permalink
Post by Döhr, Markus ICC-H
First of all, your assumptions are incorrect. Modern versions of =
X=20
Post by Döhr, Markus ICC-H
are not old, unoptimised, will do remote sessions, etc.
=20
Remote sessions have been there as long as the DISPLAY=20
environment variable - I think even X10.4, 2 decades and more=20
ago, could do that. I know that it worked just fine 18 years=20
ago with X11R1 (aah... building that from source on a 25mz
Sun3 took a little while). (Anybody know when the first=20
instance of pointing 'xmelt' at another user's machine for=20
amusement was? :)
[...]
Although one has to admit that working with remote X terminals over
a SSH/WAN/VPN-connection is far from usefull,
It depends on what programs you run. Emacs runs perfectly fine over a
slow modem. Firefox is usually very unhappy even on a fast LAN. In
general, applications that render an image locally and send that to
the X server for display will run badly over a remove connection.
Apps that send text and drawing commands to the server, and let it
take care of rendering run quite well.
Post by Döhr, Markus ICC-H
Microsoft=B4s RDP protocol does a much better job there. However,
there=B4s NX (http://www.nomachine.com/) and other products but out o=
f
Post by Döhr, Markus ICC-H
the box X11 it=B4s quite slow over higher latency connections.
RDP is more like VNC, AFAIK. It serves a different purpose.

--=20
M=E5ns Rullg=E5rd
***@inprovide.com
Döhr, Markus ICC-H
2006-05-17 11:11:22 UTC
Permalink
Microsoft=B4s RDP protocol does a much better job there. However,=20
there=B4s NX (http://www.nomachine.com/) and other products=20
but out of=20
the box X11 it=B4s quite slow over higher latency connections.
=20
RDP is more like VNC, AFAIK. It serves a different purpose.
No, not necessarily. It=B4s very possible to run only a single applicat=
ion
from an RDP serving system (as you do with X), the application gets exe=
cuted
on the server and the display is pushed to the client.


Greetz,


SIEGENIA-AUBI KG
Informationswesen
=20
i.A.
=20
Markus D=F6hr
SAP-CC/BC, SAPDB-DBA

Tel.: +49 6503 917-152
=46ax: +49 6503 917-7152
E-Mail: ***@siegenia-aubi.com
Internet: http://www.siegenia-aubi.com=20
=20
Continue reading on narkive:
Loading...