Discussion:
replacing X Window System !
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,

On 16/05/06, linux cbon <***@yahoo.fr> wrote:
> 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
linux cbon <***@yahoo.fr> writes:

> 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?

> not optimized,

Wrong.

> slow,

Wrong.

> not secure (uses root much),

Would you prefer to give any random user direct access to the hardware?

> accesses the video hardware directly (thats the kernel's job !),

Debatable.

> it cannot do VNC, etc.

Most programs can't do VNC.

> 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
On Tuesday 16 May 2006 22:57, M=E5ns Rullg=E5rd wrote:
> linux cbon <***@yahoo.fr> writes:
[snip]
>
> > 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
On Tue, 16 May 2006, linux cbon wrote:

> 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
On Tue, 16 May 2006 15:19:16 PDT, alan said:

> 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
On Tue, 16 May 2006, ***@vt.edu wrote:

> On Tue, 16 May 2006 15:19:16 PDT, alan said:
>
>> 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.

> 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
On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:

> - 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.

> 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.

> - 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
--- ***@vt.edu a =E9crit :=20
> On Wed, 17 May 2006 13:47:22 +0200, linux cbon said:
>=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 ?


> 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
On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:

> 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.

> 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?

> 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?

> 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....)
Panagiotis Issaris
2006-05-17 14:10:38 UTC
Permalink
***@vt.edu wrote:

>On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
>
>
>
>>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.
>
>
Wouldn't porting GTK+ and Qt be enough for the majority
of the graphical applications?

With friendly regards,
Takis
Ondrej Zary
2006-05-17 14:19:10 UTC
Permalink
Panagiotis Issaris wrote:
> ***@vt.edu wrote:
>
>> On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
>>
>>
>>
>>> 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.
>>
>>
> Wouldn't porting GTK+ and Qt be enough for the majority
> of the graphical applications?

And maybe some compatibility layer for the other?

--
Ondrej Zary
Olivier Galibert
2006-05-17 14:23:38 UTC
Permalink
On Wed, May 17, 2006 at 04:10:38PM +0200, Panagiotis Issaris wrote:
> ***@vt.edu wrote:
>
> >On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:
> >
> >
> >
> >>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.
> >
> >
> Wouldn't porting GTK+ and Qt be enough for the majority
> of the graphical applications?

You'll need OpenGL/GLX and SDL too to stand a chance.

And in any case, porting gtk+ includes porting gdk, and gdk isn't much
more than a very thin layer over libX11 with some added functionality.
So in practice it is a better idea to have a libX11-compatible API
(and if possible ABI), which will give you gdk/gtk/Qt/Motif for "free"
(not GL/SDL though), and then change gtk/Qt where appropriate to use
your own features.

OG.
Bob Copeland
2006-05-17 14:46:48 UTC
Permalink
On 5/17/06, Olivier Galibert <***@pobox.com> wrote:
> So in practice it is a better idea to have a libX11-compatible API
> (and if possible ABI), which will give you gdk/gtk/Qt/Motif for "free"
> (not GL/SDL though), and then change gtk/Qt where appropriate to use
> your own features.

If only there was a way to get all of that for free without doing any
work at all :)

Bob
Lennart Sorensen
2006-05-17 13:24:03 UTC