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.)
_________________________________________________________________
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: [email protected]
Phone: +48 606 814 283
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)
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.
kartikey bhatt ([email protected]) 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 <[email protected]>
>From: Mark Hahn <[email protected]>
>To: kartikey bhatt <[email protected]>
>Subject: Re: Can't X be elemenated?
>Date: Mon, 29 Sep 2003 12:53:21 -0400 (EDT)
>
> > Can't X be elemenated?
>
>of course. but this has nothing to do with linux-kernel development.
>this has been done many times already.
point me to work that has been done.
>prove it.
i'll send you my test result data.
_________________________________________________________________
Answer simple questions. Win a free honeymoon.
http://server1.msn.co.in/sp03/shaadi/index.asp Sail into the sunset!
George France <[email protected]> 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
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
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
El Mon, 29 Sep 2003 20:14:56 +0530 "kartikey bhatt" <[email protected]> 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.
In article <[email protected]>,
kartikey bhatt <[email protected]> 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 [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
|
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
your graphics card (hw) is resource that needs to be managed by OS.
leaving it to 3rd party developers is an *adhoc* solution, *a stark immoral
choice*.
my friend gotta new AMD athlon with nvidia gforce 32mb shared memory,
but he is on the mercy of X people to get full support for it.
for now he has to do with generic i810 driver?
any answer for that.
my question is can't X be eleminated by providing support for
graphics drivers and other routines at kernel level?
>From: Diego Calleja Garc?a <[email protected]>
>To: "kartikey bhatt" <[email protected]>
>CC: [email protected]
>Subject: Re: Can't X be elemenated?
>Date: Mon, 29 Sep 2003 23:11:01 +0200
>
>El Mon, 29 Sep 2003 20:14:56 +0530 "kartikey bhatt" <[email protected]>
>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.
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
_________________________________________________________________
MSN Hotmail now on your Mobile phone.
http://server1.msn.co.in/sp03/mobilesms/ Click here.
On Tue, Sep 30, 2003 at 01:39:22PM +0530, kartikey bhatt wrote:
> your graphics card (hw) is resource that needs to be managed by OS.
> leaving it to 3rd party developers is an *adhoc* solution, *a stark immoral
> choice*.
But there is an API to manage cards, that is called Kernel-DRM.
> my friend gotta new AMD athlon with nvidia gforce 32mb shared memory,
> but he is on the mercy of X people to get full support for it.
> for now he has to do with generic i810 driver?
> any answer for that.
> my question is can't X be eleminated by providing support for
> graphics drivers and other routines at kernel level?
In the X 4.2+ there is ABI to support BINARY drivers for cards without
vendors needing to provide sources for those drivers. Those drivers
are presumably binary compatible at least upwards, e.g. driver done
for 4.2.1 should work at 4.3.0. That is XFree86's chosen way.
In Linux kernel there is really no "guaranteed to work" way to have
binary driver modules even in between two vendors with same source.
Vendors do tend to add patches, which may (or may not) modify critical
datastructures. A driver for 2.4.21 may or may not work on 2.4.22
kernel. A driver for non-SMP configured kernel is very nearly guaranteed
not to work on SMP configured kernel.
Often I could care less of receiving a binary-only driver for e.g. some
hardware driver, if it only would work at all of my kernels, and not only
at some year old version.
Presumably this should be possible in stable series of kernels
( the second value in kernel version number being even: 2.4.* )
but practice hasn't always been so.
Kartik, I presume you haven't been following linux lists for very long ?
Folks using hotmail and Yahoo do tend to drop their subscriptions rather
quickly mainly because of the very high volume of things at linux-kernel
list.
Look into archives about NVidian kernel drivers, and the troubles
around those. The issues being in essence that that particular
binary only driver is munging kernel memory map data thru manipulating
link chains, and what not, for which there is no internal API, and
doing all that in binary-only driver. (I have to admit my ignorance
about all details, but in essence it has scared me away from things
with NVidia cards.)
I am quite sure, that there would be a lot less furor about the issue,
if only things manipulating card were binary only, and things working
on kernel data structures were available in source. Possibly with
driver internal API and definitely stable datastructures.
Consider it like some card with binary only firmware for its internal
processor, which does have known interface data-structures. To activate
the firmware about some aspects of the new entry data, instead of poking
some IO or MMIO location, system main processor does execute that
"firmware".
The sad part, of course, is that it in essence does lock the driver
for i386, and Linux at other processors can't use the card.
On the other hand, 99%+ of Linuxes does run at i386.
/Matti Aarnio
Hello,
> my friend gotta new AMD athlon with nvidia gforce 32mb shared memory,
> but he is on the mercy of X people to get full support for it.
He is on the mercy of NVidia people !!!!
Let NVidia have documentation available, and you'll have quickly
drivers floating around !
Regards,
Paul
On Tuesday 30 September 2003 03:09, kartikey bhatt wrote:
> your graphics card (hw) is resource that needs to be managed by OS.
> leaving it to 3rd party developers is an *adhoc* solution, *a stark immoral
> choice*.
> my friend gotta new AMD athlon with nvidia gforce 32mb shared memory,
Nvidia doesn't support Linux.
> but he is on the mercy of X people to get full support for it.
Nvidia doesn't support X either.
> for now he has to do with generic i810 driver?
> any answer for that.
The problem with nvidia is that they will NOT release information on
programming their graphics board.
Without the information, no code.
No code, no driver.
No driver, no support.
Want a fix? talk to nvidia.
> my question is can't X be eleminated by providing support for
> graphics drivers and other routines at kernel level?
Sure - Already has been done.
There IS a framebuffer implementation of graphics display. And X already
supports it.
If you are talking about nvidia support.... talk to nvidia.
what about the rest?
>From: Diego Calleja Garc?a <[email protected]>
>To: "kartikey bhatt" <[email protected]>
>Subject: Re: Can't X be elemenated?
>Date: Tue, 30 Sep 2003 18:47:19 +0200
>
>El Tue, 30 Sep 2003 13:39:22 +0530 "kartikey bhatt" <[email protected]>
>escribi?:
>
> > your graphics card (hw) is resource that needs to be managed by OS.
>
>It is managed by the OS (the voodoo DRI driver, which lives in the kernel)
_________________________________________________________________
Reconnect with old pals. Relive past joys. http://www.batchmates.com/msn.asp
All it takes is a click!
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 [email protected] [email protected] Key ID: 64A2FF6A
warning: do not ever send email to [email protected]
Fortune:
Real wealth can only increase.
-- R. Buckminster Fuller
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 [email protected] [email protected] Key ID: 64A2FF6A
> warning: do not ever send email to [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 <[email protected]>
> To: Paul Jakma <[email protected]>
> Cc: kartikey bhatt <[email protected]>, [email protected]
> 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 [email protected] [email protected] Key ID: 64A2FF6A
> > warning: do not ever send email to [email protected]
> > 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 [email protected]
> > 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 [email protected]
> 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
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
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 <[email protected]>
> To: David Lang <[email protected]>
> Cc: Paul Jakma <[email protected]>, kartikey bhatt <[email protected]>,
> [email protected]
> 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
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))