Can't X be elemenated?

Can't X be elemenated?

[kartikey bhatt]

Hi Linus.

I read your reply to a person worried about the future of linux. It was a
satisfactory reply; I hope to get a satisfactory reply for this one also.

Can't X be elemenated?

I mean to say kernel level support for graphics device drivers and special
routines for accessing it directly; rest will be done by user space widget
libraries (or say a kernel space light widget library which can be 
customized
by user space libraries).

Why am I asking this?

1st. X is bloat. Though it's good for server environments. For desktop pcs
it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose from
either to run X or compile 2.6.0-test6.

2nd. It's process based client/server architecture is a bottleneck. It's not
as interactive as is supposed to be.

3rd. Most important. I can't impress or convince my window(crash)(TM) user
friends, relatives (who saw X running on my pc) to use Linux.

4th. I want to see desktop being ruled by Linux.

"Present" is in our hands; we are ruling servers.
You said "Linux, world domination fast".
If my wish is fulfilled, I am sure, one day, You (Mr. Linus) and I will
be saying "Linux, world domination completed".


		-Kartikey Mahendra Bhatt.

(Sorry for raising this question during feature freeze. But the
consequences in last few days have forced me to ask this question.)

_________________________________________________________________

Re: Can't X be elemenated?

[Leonard Milcin Jr.]

kartikey bhatt wrote:

> Hi Linus.
> 
> I read your reply to a person worried about the future of linux. It was a
> satisfactory reply; I hope to get a satisfactory reply for this one also.
> 
> Can't X be elemenated?
> 
> I mean to say kernel level support for graphics device drivers and special
> routines for accessing it directly; rest will be done by user space widget
> libraries (or say a kernel space light widget library which can be 
> customized
> by user space libraries).

Yeah. I have read some time ago here "Why not insmod kde?".


-- 
Leonard Milcin Jr. "thervoy"
PGP Key ID: 33553569C9E17BBF
E-mail: thervoy@post.pl
Phone: +48 606 814 283

Re: Can't X be elemenated?

[Gábor Lénárt]

On Mon, Sep 29, 2003 at 04:51:50PM +0200, Leonard Milcin Jr. wrote:
> >Can't X be elemenated?
> >
> >I mean to say kernel level support for graphics device drivers and special
> >routines for accessing it directly; rest will be done by user space widget
> >libraries (or say a kernel space light widget library which can be 
> >customized
> >by user space libraries).
> 
> Yeah. I have read some time ago here "Why not insmod kde?".

:) Funny ;-) So we want another windows where communication on quite deep
level of the system is associated with windows and hells like this to
discover basic security design problems? :) No. kernel is about the core
of the system, 'window' and likes are user space stuffs, kernel is NOTHING
to do with windows and likes. However it would be nice, if XFree used
framebuffer of the kernel beause eg switching between X and console terminals
are not always dead-lock free and other problems can arise as well ...

- Gábor (larta'H)

Re: Can't X be elemenated?

[Erik Hensema]

kartikey bhatt (kartik_me@hotmail.com) wrote:
> I read your reply to a person worried about the future of linux. It was a
> satisfactory reply; I hope to get a satisfactory reply for this one also.
> 
> Can't X be elemenated?
> 
> I mean to say kernel level support for graphics device drivers and special
> routines for accessing it directly; rest will be done by user space widget
> libraries (or say a kernel space light widget library which can be 
> customized
> by user space libraries).

Please take a look at directfb, work is underway to port Qt to it, so
potentionally you could run KDE on the framebuffer console.

It's however quite offtopic here.

-- 
Erik Hensema <erik@hensema.net>

Re: Can't X be elemenated?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Mon, 29 Sep 2003 20:14:56 +0530, kartikey bhatt said:

> Can't X be elemenated?

And replaced with what?

Don't point me at "experimental development systems".  I can't use something
that's just now getting to the "display a window" stage. I need something that
will *already* support a Mozilla port (or equivalent), my mail reader, an
equally functional [A-Za-z]term emulator, and have enough backward
compatibility/emulation that I can tunnel X connections from other machines
from other vendors and use their GUI tools (yes, some of us still have Solaris,
Tru64, IRIX, and AIX boxes and need to deal with them on a regular basis - and
those vendors haven't bought into the "replace X" kool-aid yet).

And I'm not convinced that much of the trouble is X's fault, as opposed to
a poor implementation of X:

http://xcb.cs.pdx.edu/

Any discussion of replacing X needs to understand why Berlin isn't the
dominant windowing system currently.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Can't X be elemenated?

[George France]

Hello,

On Monday 29 September 2003 10:44 am, kartikey bhatt wrote:
> 
> <snip>
>
> 1st. X is bloat. Though it's good for server environments. For desktop pcs
> it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose
> from either to run X or compile 2.6.0-test6.
>
> <snip>
>

Bloat???  I run X on my handheld device with 16MB of flash and 32MB of DRAM.

--George

Re: Can't X be elemenated?

[Erik Bourget]

George France <france@handhelds.org> writes:

> Hello,
>
> On Monday 29 September 2003 10:44 am, kartikey bhatt wrote:
>> 
>> <snip>
>>
>> 1st. X is bloat. Though it's good for server environments. For desktop pcs
>> it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose
>> from either to run X or compile 2.6.0-test6.
>>
>> <snip>
>>
>
> Bloat???  I run X on my handheld device with 16MB of flash and 32MB of DRAM.
>
> --George

This belongs on lkml why?

- Erik

Re: Can't X be elemenated?

[Erik Steffl]

George France wrote:
> Hello,
> 
> On Monday 29 September 2003 10:44 am, kartikey bhatt wrote:
> 
>><snip>
>>
>>1st. X is bloat. Though it's good for server environments. For desktop pcs
>>it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose
>>from either to run X or compile 2.6.0-test6.
...

   running X does not prevent you from compiling kernel (I did it with a 
lot lower spec'd machines before). It's true that on low end machine the 
kernel compile prevents you from doing much else but that's true 
regardless of X. Some X apps eat quite a lot of memory and if you run 
openoffice and mozilla (and gnome or kde or enlightement) you end up not 
being able to do anything else. But that's not problem of X, it's a 
problem of specific applications. I have been using X (under linux) 
since times of 486 & 128MB RAM and it's been quite OK (=responsive), 
given that appropriate apps are chosen.

	erik

Re: Can't X be elemenated?

[Diego Calleja García]

El Mon, 29 Sep 2003 20:14:56 +0530 "kartikey bhatt" <kartik_me@hotmail.com> escribió:

> 1st. X is bloat. Though it's good for server environments. For desktop pcs
> it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose from
> either to run X or compile 2.6.0-test6.
> 
> 2nd. It's process based client/server architecture is a bottleneck. It's not
> as interactive as is supposed to be.

You might want to discuss that with X people. It's been demonstrated that the
client/server model is noy a bottleneck...in fact there're benchmarks which show
X being almost as fast as the windows GDI... (using the shared memory extension)

> 
> 3rd. Most important. I can't impress or convince my window(crash)(TM) user
> friends, relatives (who saw X running on my pc) to use Linux.

I can impress them quite well running the X server in a different machine :)

> 
> 4th. I want to see desktop being ruled by Linux.

It's already ruling my desktop 8)

But you might want to talk with X developers. Linus it's just the kernel
maintainer.

Re: Can't X be elemenated?

[bill davidsen]

In article <LAW11-F18b4SaFMwr9y00007564@hotmail.com>,
kartikey bhatt <kartik_me@hotmail.com> wrote:
| Hi Linus.
| 
| I read your reply to a person worried about the future of linux. It was a
| satisfactory reply; I hope to get a satisfactory reply for this one also.
| 
| Can't X be elemenated?
| 
| I mean to say kernel level support for graphics device drivers and special
| routines for accessing it directly; rest will be done by user space widget
| libraries (or say a kernel space light widget library which can be 
| customized
| by user space libraries).
| 
| Why am I asking this?
| 
| 1st. X is bloat. Though it's good for server environments. For desktop pcs
| it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose from
| either to run X or compile 2.6.0-test6.

So you have the config wrong... I compile a kernel while reading mail
with Kmail, which I use so I can follow links which my text mailer
ignores (and thereby avoids any eveil content). I use a PII-350 with
96MB for my 2.6 test box, and it frequently is also running real work as
well.

Did you forget to enable swap or something?
| 
| 2nd. It's process based client/server architecture is a bottleneck. It's not
| as interactive as is supposed to be.

That's silly, servers don't need X, in many cases they don't even have a
console device.
| 
| 3rd. Most important. I can't impress or convince my window(crash)(TM) user
| friends, relatives (who saw X running on my pc) to use Linux.

And you don't give good demos, either. If you want to impress Windows
users, try the "uptime" command.
| 
| 4th. I want to see desktop being ruled by Linux.

Doing without X isn't the answer. And except on some embedded
application, the cost of memory is so low there just isn't any reason to
worry about it, it's only an issue on really old boxen, and those are
will served by just using a console, not by trying to save a few bytes
by eviscerating the kernel.
| 
| "Present" is in our hands; we are ruling servers.
| You said "Linux, world domination fast".
| If my wish is fulfilled, I am sure, one day, You (Mr. Linus) and I will
| be saying "Linux, world domination completed".
| 
| 
| 		-Kartikey Mahendra Bhatt.
| 
| (Sorry for raising this question during feature freeze. But the
| consequences in last few days have forced me to ask this question.)
| 
| _________________________________________________________________
| 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/
| 


-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

[OT ]Re: Can't X be elemenated?

[Helge Hafting]

kartikey bhatt wrote:
> Hi Linus.
> 
> I read your reply to a person worried about the future of linux. It was a
> satisfactory reply; I hope to get a satisfactory reply for this one also.
> 
> Can't X be elemenated?

Trivially.  X is a stand-alone app, this is as easy as not running
it.  (Or not installing it, if you don't want to spend the disk space.)
That means no GUI apps, but there are plenty of programs that
don't need the GUI.

> I mean to say kernel level support for graphics device drivers and special
> routines for accessing it directly; rest will be done by user space widget
> libraries (or say a kernel space light widget library which can be 
> customized
> by user space libraries).
> 
Then you move the "bloat" to the kernel, where it does more
damage than were it is now.  No real win, but definitely loss.

> Why am I asking this?
> 
> 1st. X is bloat. Though it's good for server environments. For desktop pcs
> it's too heavy. On my machine (PIII500 with 128MB RAM) I have to choose 
> from
> either to run X or compile 2.6.0-test6.

You're wrong.  X is lightweight.  I remember running it on a 386
with 8M RAM - much faster than windows 3.1 of that time.

I guess you're merely running some very heavy apps.
1. Get a lightweight window manager.  There are many
    to chooce from, such as icewm, fwwm, twm, openbox,...
    Don't run heavy stuff like enlightenment.  It looks good,
    but it is meant for bigger machines than yours.
2. Avoid gnome and kde whenever possible.  These two wants more
    than 128M.  And possibly more cpu too.
3. Make sure you have a x server that uses acceleration
    (Check the x server log) and make sure you aren't
    running an IDE disk in pio mode and without
    interrupt unmasking. (take a look at hdparm)

You should now have a lean fast system compared to windows.

> 
> 2nd. It's process based client/server architecture is a bottleneck. It's 
> not
> as interactive as is supposed to be.
Likely some other problem, see above.


> 3rd. Most important. I can't impress or convince my window(crash)(TM) user
> friends, relatives (who saw X running on my pc) to use Linux.
> 
Can't do that with an ill-configured system.  Oh, and make sure
the comparison is sensible - are they running windows on
128M 500MHz machines too?

> 4th. I want to see desktop being ruled by Linux.
> 
Linux is good enough for that already.  Companies are changing
to linux on the desktops as a cost-cutting measure - no
licences and slightly lower demands for hardware. And there
is enough apps too!  (Not as many as for windows, but _enough_,
more is coming.)

Now, "good enough" is no reason to stop getting better.  But
integrating X into the kernel is not the way to go, particularly because
it don't buy us much.

X not in the kernel means a fault in X don't take out the kernel
(crashing the machine) either.  Seems you like that aspect of
it. Also, X supports networking as is.  Try running apps
remotely with windows - you'll have to buy third party
software first and it isn't as good.
I routinely log in to my office pc from home, and run GUI apps
over and ADSL line.  It just works.

> "Present" is in our hands; we are ruling servers.
> You said "Linux, world domination fast".
> If my wish is fulfilled, I am sure, one day, You (Mr. Linus) and I will
> be saying "Linux, world domination completed".
:-)

Helge Hafting

Re: Can't X be elemenated?

[Paul Jakma]

On Mon, 29 Sep 2003, kartikey bhatt wrote:

> 1st. X is bloat.

This isnt true.

[paul@fogarty paul]$ cat /proc/`pidof X`/status | grep ^Vm
VmSize:    47700 kB
VmLck:         0 kB
VmRSS:     22580 kB
VmData:    25540 kB
VmStk:        72 kB
VmExe:      1488 kB
VmLib:      1580 kB

X is actually quite tiny, ~3MB of exe+lib. The data size is due,
vastly, to the X /clients/ using the server (in the above case RH9
GNOME + windowmaker + xchat2 + galeon + few xterms).

Here's Xipaq (tinyX handheld X server):

~ $  cat /proc/`pidof Xipaq`/status | grep ^Vm
VmSize:     5072 kB
VmLck:         0 kB
VmRSS:      3164 kB
VmData:     1788 kB
VmStk:        16 kB
VmExe:       848 kB
VmLib:      2028 kB

That's Xipaq, exe is smaller, but libs are bigger, balances out to 
~3MB again. However, the data segment is much smaller, < 2MB compared 
to > 25MB for the desktop case. The handheld runs the GPE 
(http://gpe.handhelds.org) environment.

So perhaps you could come to the conclusion that 'X' (in the X server
sense) is not bloat, but that the /clients/ on modern desktops are?

> Though it's good for server environments. For desktop pcs it's too
> heavy. 

You are misinformed. See above.

> 2nd. It's process based client/server architecture is a bottleneck.

Why do you think so? For large amounts of data, X clients can use 
shared memory. Further, even if they must transfer data (ie 
pixmaps/pics) across the socket connection, the X server can cache 
it, and the client can use it by reference. (ie a once off cost).

Also, local X clients use unix sockets - blazingly fast.

> It's not as interactive as is supposed to be.

Have you tried 2.6.0-test6? The interactivity problems were the 
kernel's fault more than that of 'X'.

> 3rd. Most important. I can't impress or convince my
> window(crash)(TM) user friends, relatives (who saw X running on my
> pc) to use Linux.

You wont impress /anyone/ with "just X" (ie just the X server) -
cause all you'll get is a tiled background of tiny X logos and an X
mouse pointer.
 
> 4th. I want to see desktop being ruled by Linux.

"X" isnt the obstacle.

To be able to constructively criticise something you first need to 
/understand/ it. You dont.

Most of you what you complain about, bloat and heavyness, is due to
the desktop environment - not X itself. Try running GPE
(http://gpe.handhelds.org) or (easier/actually practical too for a
desktop) Xfce (http://www.xfce.org)

Finally, this isnt a kernel problem.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam@dishone.st
Fortune:
Real wealth can only increase.
		-- R. Buckminster Fuller

Re: Can't X be elemenated?

[Krishna Akella]

Definitely, having the kernel support the GUI features is bad idea IMHO.
but, What X lacks is a _standard_ toolkit, _complete_ widgetset for developers.
We have
acrobat using Motif distributed along with the reader, xfig "needing"
preinstalled Motif, Xaw using Athena, Gnome apps using gtk, KDE apps using
QT... and so on. Moreover, there is no standard interface for
communication between these apps using myriad toolkits. And all of this is
a duplication of effort that can be totally avoided.

As an app programmer, one is always faced with the question, "which
toolkit do I use?". And there is never an easy answer. I guess its high
time for ppl to realize this. If any thing, this is definitely one thing
thats slowing down the acceptance of Linux as a Desktop OS.

-krishna

On Tue, 30 Sep 2003, Paul Jakma wrote:

> On Mon, 29 Sep 2003, kartikey bhatt wrote:
>
> > 1st. X is bloat.
>
> This isnt true.
>
> [paul@fogarty paul]$ cat /proc/`pidof X`/status | grep ^Vm
> VmSize:    47700 kB
> VmLck:         0 kB
> VmRSS:     22580 kB
> VmData:    25540 kB
> VmStk:        72 kB
> VmExe:      1488 kB
> VmLib:      1580 kB
>
> X is actually quite tiny, ~3MB of exe+lib. The data size is due,
> vastly, to the X /clients/ using the server (in the above case RH9
> GNOME + windowmaker + xchat2 + galeon + few xterms).
>
> Here's Xipaq (tinyX handheld X server):
>
> ~ $  cat /proc/`pidof Xipaq`/status | grep ^Vm
> VmSize:     5072 kB
> VmLck:         0 kB
> VmRSS:      3164 kB
> VmData:     1788 kB
> VmStk:        16 kB
> VmExe:       848 kB
> VmLib:      2028 kB
>
> That's Xipaq, exe is smaller, but libs are bigger, balances out to
> ~3MB again. However, the data segment is much smaller, < 2MB compared
> to > 25MB for the desktop case. The handheld runs the GPE
> (http://gpe.handhelds.org) environment.
>
> So perhaps you could come to the conclusion that 'X' (in the X server
> sense) is not bloat, but that the /clients/ on modern desktops are?
>
> > Though it's good for server environments. For desktop pcs it's too
> > heavy.
>
> You are misinformed. See above.
>
> > 2nd. It's process based client/server architecture is a bottleneck.
>
> Why do you think so? For large amounts of data, X clients can use
> shared memory. Further, even if they must transfer data (ie
> pixmaps/pics) across the socket connection, the X server can cache
> it, and the client can use it by reference. (ie a once off cost).
>
> Also, local X clients use unix sockets - blazingly fast.
>
> > It's not as interactive as is supposed to be.
>
> Have you tried 2.6.0-test6? The interactivity problems were the
> kernel's fault more than that of 'X'.
>
> > 3rd. Most important. I can't impress or convince my
> > window(crash)(TM) user friends, relatives (who saw X running on my
> > pc) to use Linux.
>
> You wont impress /anyone/ with "just X" (ie just the X server) -
> cause all you'll get is a tiled background of tiny X logos and an X
> mouse pointer.
>
> > 4th. I want to see desktop being ruled by Linux.
>
> "X" isnt the obstacle.
>
> To be able to constructively criticise something you first need to
> /understand/ it. You dont.
>
> Most of you what you complain about, bloat and heavyness, is due to
> the desktop environment - not X itself. Try running GPE
> (http://gpe.handhelds.org) or (easier/actually practical too for a
> desktop) Xfce (http://www.xfce.org)
>
> Finally, this isnt a kernel problem.
>
> regards,
> --
> Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
> 	warning: do not ever send email to spam@dishone.st
> Fortune:
> Real wealth can only increase.
> 		-- R. Buckminster Fuller
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Can't X be elemenated?

[David Lang]

different toolkits exist becouse people are solving different problems.
which set of people do you propose telling that their desires don't
matter?

you can produce X programs just useing the Xlib libraries, which are
available on every system and don't require all the bloat of the higher
leve tools, but do you really want to? the higher level toolkits exist to
make life easier for the programmer, is the difficulty in selecting which
toolkit to use really so bad that you want to eliminate all of them
instead?

this is like sayign that it's to hard to choose a fullscreed text editor,
you have vi, elvis, vim, emacs, openoffice, abiword, joe, ... choosign
between them it to complicated so lets eliminate all of them and everyone
will jsut use ed instead.

David Lang

On Tue, 30 Sep 2003, Krishna Akella wrote:

> Date: Tue, 30 Sep 2003 12:30:13 -0700 (PDT)
> From: Krishna Akella <akellak@onid.orst.edu>
> To: Paul Jakma <paul@clubi.ie>
> Cc: kartikey bhatt <kartik_me@hotmail.com>, linux-kernel@vger.kernel.org
> Subject: Re: Can't X be elemenated?
>
> Definitely, having the kernel support the GUI features is bad idea IMHO.
> but, What X lacks is a _standard_ toolkit, _complete_ widgetset for developers.
> We have
> acrobat using Motif distributed along with the reader, xfig "needing"
> preinstalled Motif, Xaw using Athena, Gnome apps using gtk, KDE apps using
> QT... and so on. Moreover, there is no standard interface for
> communication between these apps using myriad toolkits. And all of this is
> a duplication of effort that can be totally avoided.
>
> As an app programmer, one is always faced with the question, "which
> toolkit do I use?". And there is never an easy answer. I guess its high
> time for ppl to realize this. If any thing, this is definitely one thing
> thats slowing down the acceptance of Linux as a Desktop OS.
>
> -krishna
>
> On Tue, 30 Sep 2003, Paul Jakma wrote:
>
> > On Mon, 29 Sep 2003, kartikey bhatt wrote:
> >
> > > 1st. X is bloat.
> >
> > This isnt true.
> >
> > [paul@fogarty paul]$ cat /proc/`pidof X`/status | grep ^Vm
> > VmSize:    47700 kB
> > VmLck:         0 kB
> > VmRSS:     22580 kB
> > VmData:    25540 kB
> > VmStk:        72 kB
> > VmExe:      1488 kB
> > VmLib:      1580 kB
> >
> > X is actually quite tiny, ~3MB of exe+lib. The data size is due,
> > vastly, to the X /clients/ using the server (in the above case RH9
> > GNOME + windowmaker + xchat2 + galeon + few xterms).
> >
> > Here's Xipaq (tinyX handheld X server):
> >
> > ~ $  cat /proc/`pidof Xipaq`/status | grep ^Vm
> > VmSize:     5072 kB
> > VmLck:         0 kB
> > VmRSS:      3164 kB
> > VmData:     1788 kB
> > VmStk:        16 kB
> > VmExe:       848 kB
> > VmLib:      2028 kB
> >
> > That's Xipaq, exe is smaller, but libs are bigger, balances out to
> > ~3MB again. However, the data segment is much smaller, < 2MB compared
> > to > 25MB for the desktop case. The handheld runs the GPE
> > (http://gpe.handhelds.org) environment.
> >
> > So perhaps you could come to the conclusion that 'X' (in the X server
> > sense) is not bloat, but that the /clients/ on modern desktops are?
> >
> > > Though it's good for server environments. For desktop pcs it's too
> > > heavy.
> >
> > You are misinformed. See above.
> >
> > > 2nd. It's process based client/server architecture is a bottleneck.
> >
> > Why do you think so? For large amounts of data, X clients can use
> > shared memory. Further, even if they must transfer data (ie
> > pixmaps/pics) across the socket connection, the X server can cache
> > it, and the client can use it by reference. (ie a once off cost).
> >
> > Also, local X clients use unix sockets - blazingly fast.
> >
> > > It's not as interactive as is supposed to be.
> >
> > Have you tried 2.6.0-test6? The interactivity problems were the
> > kernel's fault more than that of 'X'.
> >
> > > 3rd. Most important. I can't impress or convince my
> > > window(crash)(TM) user friends, relatives (who saw X running on my
> > > pc) to use Linux.
> >
> > You wont impress /anyone/ with "just X" (ie just the X server) -
> > cause all you'll get is a tiled background of tiny X logos and an X
> > mouse pointer.
> >
> > > 4th. I want to see desktop being ruled by Linux.
> >
> > "X" isnt the obstacle.
> >
> > To be able to constructively criticise something you first need to
> > /understand/ it. You dont.
> >
> > Most of you what you complain about, bloat and heavyness, is due to
> > the desktop environment - not X itself. Try running GPE
> > (http://gpe.handhelds.org) or (easier/actually practical too for a
> > desktop) Xfce (http://www.xfce.org)
> >
> > Finally, this isnt a kernel problem.
> >
> > regards,
> > --
> > Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
> > 	warning: do not ever send email to spam@dishone.st
> > Fortune:
> > Real wealth can only increase.
> > 		-- R. Buckminster Fuller
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Can't X be elemenated?

[Krishna Akella]

On Tue, 30 Sep 2003, David Lang wrote:

> different toolkits exist becouse people are solving different problems.
> which set of people do you propose telling that their desires don't
> matter?
>
> you can produce X programs just useing the Xlib libraries, which are
> available on every system and don't require all the bloat of the higher
> leve tools, but do you really want to? the higher level toolkits exist to
> make life easier for the programmer, is the difficulty in selecting which
> toolkit to use really so bad that you want to eliminate all of them
> instead?
 "eliminate all of them". I never said that. Infact its all about choice
and freedom that we are using Linux/GNU.

> this is like sayign that it's to hard to choose a fullscreed text editor,
> you have vi, elvis, vim, emacs, openoffice, abiword, joe, ... choosign
> between them it to complicated so lets eliminate all of them and everyone
> will jsut use ed instead.
 again - eliminating all - is a premise you have made. What I was talking
about was the lack of standards. Interoperability is a _desirable_
feature.
> David Lang

Re: Can't X be elemenated?

[David Lang]

they already interoperate (the X layer is where all the different layers
interoperate), this apparently isn't good enough or you wouldn't have
started this thread.

so what is it that you want?

David Lang


 On Tue, 30 Sep 2003, Krishna Akella wrote:

> Date: Tue, 30 Sep 2003 13:46:00 -0700 (PDT)
> From: Krishna Akella <akellak@onid.orst.edu>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Paul Jakma <paul@clubi.ie>, kartikey bhatt <kartik_me@hotmail.com>,
>      linux-kernel@vger.kernel.org
> Subject: Re: Can't X be elemenated?
>
>
>
> On Tue, 30 Sep 2003, David Lang wrote:
>
> > different toolkits exist becouse people are solving different problems.
> > which set of people do you propose telling that their desires don't
> > matter?
> >
> > you can produce X programs just useing the Xlib libraries, which are
> > available on every system and don't require all the bloat of the higher
> > leve tools, but do you really want to? the higher level toolkits exist to
> > make life easier for the programmer, is the difficulty in selecting which
> > toolkit to use really so bad that you want to eliminate all of them
> > instead?
>  "eliminate all of them". I never said that. Infact its all about choice
> and freedom that we are using Linux/GNU.
>
> > this is like sayign that it's to hard to choose a fullscreed text editor,
> > you have vi, elvis, vim, emacs, openoffice, abiword, joe, ... choosign
> > between them it to complicated so lets eliminate all of them and everyone
> > will jsut use ed instead.
>  again - eliminating all - is a premise you have made. What I was talking
> about was the lack of standards. Interoperability is a _desirable_
> feature.
> > David Lang
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Can't X be elemenated?

[Pavel Machek]

Hi!

> different toolkits exist becouse people are solving different problems.
> which set of people do you propose telling that their desires don't
> matter?

Well, qt and gtk solve pretty much same problem,
their existence seems like historical accident to me.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Can't X be elemenated?

[Giacomo A. Catenazzi]

Pavel Machek wrote:

> Hi!
> 
> 
>>different toolkits exist becouse people are solving different problems.
>>which set of people do you propose telling that their desires don't
>>matter?
> 
> 
> Well, qt and gtk solve pretty much same problem,
> their existence seems like historical accident to me.

Hmm. World (also in linux kernel) is not so efficient!
There are more tools for same task/problem. Maybe in the long run only one tools 
per problem will survive, but the diversity is good, also at cost of the 
duplicate work.

Do you want only one distribution for user, one for small companies, one for 
schools,...? Do you want only one web server implementation? Only one filesystem 
per task (only one journaling FS)?
Are they all "historical accident"?

ciao
	giacomo

Re: Can't X be elemenated?

[Pavel Machek]

Hi!

> >>different toolkits exist becouse people are solving different problems.
> >>which set of people do you propose telling that their desires don't
> >>matter?
> >
> >
> >Well, qt and gtk solve pretty much same problem,
> >their existence seems like historical accident to me.
> 
> Hmm. World (also in linux kernel) is not so efficient!
> There are more tools for same task/problem. Maybe in the long run only one 
> tools per problem will survive, but the diversity is good, also at cost of 
> the duplicate work.

It is not where you have competing interfaces.

> Do you want only one distribution for user, one for small companies, one 
> for schools,...? Do you want only one web server implementation? Only one 
> filesystem per task (only one journaling FS)?
> Are they all "historical accident"?

Well, I'm pretty glad there's only one glibc, and only one http
protocol, and only one X protocol. And it would be way better if there
was just one toolkit commonly used on Linux.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

[OT] Re: Can't X be elemenated?

[Giacomo A. Catenazzi]

Pavel Machek wrote:

>>Do you want only one distribution for user, one for small companies, one 
>>for schools,...? Do you want only one web server implementation? Only one 
>>filesystem per task (only one journaling FS)?
>>Are they all "historical accident"?
> 
> 
> Well, I'm pretty glad there's only one glibc, 

only one glibc, but there are some implementation of libc. Also in this list we 
discuss about a tiny libc for init process, but you are right, it solve another 
problem (be small and simple). But from such discussion I worried to know that 
there exist so much implementation of libc.

> and only one http protocol, and only one X protocol.

You speak about protocols (but there are also incompatible extention), but you 
know that there exists a lot o toolkit to handle http links...

> And it would be way better if there
> was just one toolkit commonly used on Linux.

better? More efficient yes. But you know... GNU/Linux comunity will start a long 
(more years) flameware to choose the best solution, the best protocol,...
so IMHO it is good that we have different toolkits (so I think less flames, more 
work). But I agree that in long period we should switch to one toolkit (as we 
switched (nearly) all to glibc, xfree86 (but yet a new fork?), gcc(egcs style),...

BTW IIRC the discuttion was about qt and gtk. IIRC the KDE and gnome comunities 
are approaching methods and protocols, so in future maybe we will have only one 
toolkit, but not to correct an "historical accident" but because evolution.

ciao
	giacomo

Re: Can't X be elemenated?

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> Well, I'm pretty glad there's only one glibc, and only one http
> protocol, and only one X protocol. And it would be way better if there
> was just one toolkit commonly used on Linux.

There are a few problems with the common toolkits.  Both Qt and GTK
are huge bloated things that tend to take over the entire application.
You have to do everything centered around the GUI toolkit.  If neither
one fits the model of your application, it is sometimes easier to roll
your own toolkit.  Actually, that was how GTK started its life.

The other toolkits are either non-free, immensely ugly, or both.

-- 
Måns Rullgård
mru@users.sf.net

Re: Can't X be elemenated?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Tue, 07 Oct 2003 14:52:36 +0200, mru@users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)  said:

> The other toolkits are either non-free, immensely ugly, or both.

Keep in mind that in some cases, "non-free" is considered an advantage.  A
company that's trying to build a large expensive software package may choose a
toolkit precisely because it is *not* GPL'ed, so using it doesn't require
shipping your expensively produced source code....

Remember why the LGPL exists....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Can't X be elemenated?

[Jesse Pollard]

On Tuesday 07 October 2003 07:18, Pavel Machek wrote:
[snip]
> > Do you want only one distribution for user, one for small companies, one
> > for schools,...? Do you want only one web server implementation? Only one
> > filesystem per task (only one journaling FS)?
> > Are they all "historical accident"?
>
> Well, I'm pretty glad there's only one glibc, and only one http
> protocol, and only one X protocol. And it would be way better if there
> was just one toolkit commonly used on Linux.
> 								Pavel
Ah... Only one sized screwdriver....

Actually, I prefer multiple -- each competing to try and gain dominance.

Motif does it all... Unfortunately, it tends to be very SLOW... and HUGE
about 3MB memory footprint (before it starts running...) the last time I
looked.

QT/GTK... originally designed for different purposes. QT had "propriataryness"
taint at the time, and GTK came from the GIMP style (and without the taint).
I believe these were aimed at supporting C++ coding, and less about 
portability to other Unixes.. (QT/GTK wouldn't even compile on SGI/Solaris at
the time - they should by now)

Both are nearly equal now (due to common goals), though cut/paste could be
improved (same is true with Motif - and I know focus control is terrible in
Motif; they even document that it is unreliable).

And yet.. there are times when I need something VERY light weight, and
globally portable. So I started my own for a specific application where
cut/past don't apply (xdm/screen locking). For the reasons of avoiding
NFS/shared library access problems, I staticly link xdm. That was where
I first saw the bloat with Motif. (I HAD to use the shared libraries).
Static linking with my application specific toolkit gave the binary
the same size (within 10k) of the Motif equivalent... but not when the
shared libaries were included.

A focused. application specific toolkit can be very small. Mine is only 6,141
lines long. Quite fast, and does everything needed for a Kerberos 5 aware
xdm, with hardware preauthentication. Even provides an updated issue file
(required by the lawyers).

Do I intend this to be general purpose? Hell no. But the others just didn't
meet the requirements. I like xaw (and the 3d extensions were nice). Too bad
it isn't being supported anymore.

Re: Can't X be elemenated?

[Pavel Machek]

Hi!

> > > Do you want only one distribution for user, one for small companies, one
> > > for schools,...? Do you want only one web server implementation? Only one
> > > filesystem per task (only one journaling FS)?
> > > Are they all "historical accident"?
> >
> > Well, I'm pretty glad there's only one glibc, and only one http
> > protocol, and only one X protocol. And it would be way better if there
> > was just one toolkit commonly used on Linux.
> > 								Pavel
> Ah... Only one sized screwdriver....
> 
> Actually, I prefer multiple -- each competing to try and gain
> dominance.

> Motif does it all... Unfortunately, it tends to be very SLOW... and HUGE
...
> 
> QT/GTK... originally designed for different purposes. QT had "propriataryness"
...
> 
> Both are nearly equal now (due to common goals), though cut/paste could be
> improved (same is true with Motif - and I know focus control is terrible in
> Motif; they even document that it is unreliable).
> 
> And yet.. there are times when I need something VERY light weight, and
> globally portable. So I started my own for a specific application
> where

Well, in one of previous mails I said that "one per goal" is the right
thing. So it is okay for "small" toolkits to exists, but I do not like
qt vs. gtk, because they have identical goals.

Anyway, this is off-topic for linux-kernel, and I guess we should end
here.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Can't X be elemenated?

[David Lang]

On Tue, 7 Oct 2003, Pavel Machek wrote:

> >
> > And yet.. there are times when I need something VERY light weight, and
> > globally portable. So I started my own for a specific application
> > where
>
> Well, in one of previous mails I said that "one per goal" is the right
> thing. So it is okay for "small" toolkits to exists, but I do not like
> qt vs. gtk, because they have identical goals.
>
> Anyway, this is off-topic for linux-kernel, and I guess we should end
> here.

*BSD and Linux have the same goals (at least as close as GTK and QT do),
does this mean that Linus should not have started writing Linux?

David Lang

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Can't X be elemenated?

[Pavel Machek]

Hi!

> > > And yet.. there are times when I need something VERY light weight, and
> > > globally portable. So I started my own for a specific application
> > > where
> >
> > Well, in one of previous mails I said that "one per goal" is the right
> > thing. So it is okay for "small" toolkits to exists, but I do not like
> > qt vs. gtk, because they have identical goals.
> >
> > Anyway, this is off-topic for linux-kernel, and I guess we should end
> > here.
> 
> *BSD and Linux have the same goals (at least as close as GTK and QT do),
> does this mean that Linus should not have started writing Linux?

I'm not saying that work on GTK or QT should not have started. I
understand why they did. Still its a pity.

Anyway Linux vs. FreeBSD is completely another situation, because
Linux is clearly dominant. I have no problem with that. But GTK vs. QT
have roughly equivalent usage... Thats bad.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Can't X be elemenated?

[jlnance]

On Tue, Oct 07, 2003 at 12:07:51PM -0700, David Lang wrote:
> *BSD and Linux have the same goals (at least as close as GTK and QT do),
> does this mean that Linus should not have started writing Linux?

FWIW, Linus released Linux before it was announced that BSD was going
to be free.  I am sure that had there been a free BSD around, then
Linus would not have bothered.  The question then becomes should Linus
and everyone else have just quit and waited for BSD to arive.  I dont really
know how to objectivly answer that question.  However I do remember
the state of Linux when the BSD announcement happened.  It seemed like
it was so close to being "done" that it didnt make sense to quite and
throw all that work away.  Everyone was saying 1.0 by Christmas.

It ended up being a lot more work than people imagined.  A couple of
Christmases past before 1.0 happened.

Jim

Re: Can't X be elemenated?

[David Lang]

On Tue, 7 Oct 2003, Pavel Machek wrote:

>
> Hi!
>
> > >>different toolkits exist becouse people are solving different problems.
> > >>which set of people do you propose telling that their desires don't
> > >>matter?
> > >
> > >
> > >Well, qt and gtk solve pretty much same problem,
> > >their existence seems like historical accident to me.
> >
> > Hmm. World (also in linux kernel) is not so efficient!
> > There are more tools for same task/problem. Maybe in the long run only one
> > tools per problem will survive, but the diversity is good, also at cost of
> > the duplicate work.
>
> It is not where you have competing interfaces.
>
> > Do you want only one distribution for user, one for small companies, one
> > for schools,...? Do you want only one web server implementation? Only one
> > filesystem per task (only one journaling FS)?
> > Are they all "historical accident"?
>
> Well, I'm pretty glad there's only one glibc, and only one http
> protocol, and only one X protocol. And it would be way better if there
> was just one toolkit commonly used on Linux.

true, there is only one glibc, but there is not just one c library (uclib,
etc) and while there is only one http protocol there is not just a single
webserver api (netscape, IIS, apache 1.3, apache 2.0 all have different
api's)

there do need to be common points, in the case of GUI's on *nix X is the
common point, the toolkits used to write programs don't need to all have
the exact same api.

David Lang

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Can't X be elemenated?

[J.A. Magallon]

On 09.30, Krishna Akella wrote:
> Definitely, having the kernel support the GUI features is bad idea IMHO.
> but, What X lacks is a _standard_ toolkit, _complete_ widgetset for developers.
> We have
> acrobat using Motif distributed along with the reader, xfig "needing"
> preinstalled Motif, Xaw using Athena, Gnome apps using gtk, KDE apps using
> QT... and so on. Moreover, there is no standard interface for
> communication between these apps using myriad toolkits. And all of this is
> a duplication of effort that can be totally avoided.
> 
> As an app programmer, one is always faced with the question, "which
> toolkit do I use?". And there is never an easy answer. I guess its high
> time for ppl to realize this. If any thing, this is definitely one thing
> thats slowing down the acceptance of Linux as a Desktop OS.
> 

You can even choose a toolkit that goes beyond Linux:

http://www.gimp.org/~tml/gimp/win32/downloads.html
http://wwws.sun.com/software/star/gnome/
http://www.software.hp.com/products/GNOME/

And the same happens with Qt, I suppose.
Nowadays motif is used just for portability between Linux and other systems,
like IRIX or HPUX,
but it looks like the 'other' are moving to Gnome or KDE. So in a few years acrobat
will use gtk or qt, many oldies like xfig will be superceded by new apps,
and you real standards will be GTK and Qt.

And about interoperability, take a look at:

http://freedesktop.org/

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre5-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

Re: Can't X be elemenated?

[Jesse Pollard]

On Tuesday 30 September 2003 14:30, Krishna Akella wrote:
> Definitely, having the kernel support the GUI features is bad idea IMHO.
> but, What X lacks is a _standard_ toolkit, _complete_ widgetset for
> developers.

Obviously you have never programmed an X application. The STANDARD toolkit is
the X intrinsics.

It is complete. Now if you want fancier displays, add the athena widget set.
Or something with more bloat- Motif/Qt/KDE/...

Hell, I even wrote one for a specific application - MUCH faster than any of
the bloated ones on Motif/Qt/KDE... it is even faster than the athena set
because I eliminated everything that didn't apply to my application. It was
also only 10% of the size of any of them.

> We have
> acrobat using Motif distributed along with the reader, xfig "needing"
> preinstalled Motif, Xaw using Athena, Gnome apps using gtk, KDE apps using
> QT... and so on. Moreover, there is no standard interface for
> communication between these apps using myriad toolkits. And all of this is
> a duplication of effort that can be totally avoided.

Yes there is. They ALL work together. Write to the X standard and you won't 
have any such problems.

So? It is about choice. It is about standards. Motif is a standard. KDE/QT
is another (just not the same).

Inter-application communication is defined by the X protocol using the ICCM
standard. As far as I know they all do that.

> As an app programmer, one is always faced with the question, "which
> toolkit do I use?". And there is never an easy answer. I guess its high
> time for ppl to realize this. If any thing, this is definitely one thing
> thats slowing down the acceptance of Linux as a Desktop OS.

There is always an easy answer. Use the one approprate to the problem.

Of course you must know the problem, and you must know the tools you have
available. without that you better start learning.

One of the BEST things about X is that it is platform independant. This
gives me the ability to cut and paste from a QT application (kmail) into
a Motif terminal window, or even into an Xaw based xterm (or into TGIF, a
diagraming tool). I can even cut and paste from Mozilla without serious
problems.

Each application may be running on a completely different system.

You really need to go an learn some X programming.

Re: Can't X be elemenated?

[John Bradford]

Quote from Paul Jakma <paul@clubi.ie>:

> You wont impress /anyone/ with "just X" (ie just the X server) -
> cause all you'll get is a tiled background of tiny X logos and an X
> mouse pointer.

On the other hand, seeing a heavyweight application being controlled
on a 4MB 486 over a compressed 9600 serial link will usually impress
technical people who are used to other systems and have never seen
anything like that before - what other windowing systems support
remote display over a network, and running of the windowing system
recursively?

John