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

Re: Can't X be elemenated?

[kartikey bhatt]

>From: Mark Hahn <hahn@physics.mcmaster.ca>
>To: kartikey bhatt <kartik_me@hotmail.com>
>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!

Re: Can't X be elemenated?

[kartikey bhatt]

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 <diegocg@teleline.es>
>To: "kartikey bhatt" <kartik_me@hotmail.com>
>CC: linux-kernel@vger.kernel.org
>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" <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.
>
>
>-
>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/

_________________________________________________________________
MSN Hotmail now on your Mobile phone. 
http://server1.msn.co.in/sp03/mobilesms/ Click here.

Re: Can't X be elemenated?

[Matti Aarnio]

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

Re: Can't X be elemenated?

[Paul Rolland]

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

Re: Can't X be elemenated?

[Jesse Pollard]

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.

Re: Can't X be elemenated?

[kartikey bhatt]

what about the rest?


>From: Diego Calleja García <diegocg@teleline.es>
>To: "kartikey bhatt" <kartik_me@hotmail.com>
>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" <kartik_me@hotmail.com> 
>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!

Re: Can't X be elemenated?

[kartikey bhatt]

hey everyone who have joined this thread, my fundamental question have got
out of scope. I mean to say

1. Kernel level support for graphics device drivers.
2. On top of that, one can develop complete lightweight GUI.
3. Maybe kernel can provide support for event handling.

and I still stick to my opinion that graphics card is a computer resource
that needs to be managed by OS rather than 3rd party developers.
Just feeding in patches to provide support for AGP gart and DRI
is an adhoc solution, a stark immoral choice.
you don't know my frustration when i got PC and wasn't able to
run X until i810 agp gart support was available at kernel level.

And if you feel that I am a guy heavily dependent on X that's not true.
I just mean to say if anything is that kernel level support for graphics 
device drivers.
And X will be automatically eliminated.

and if you are feeling very unhappy about my statement X is bloat,
I really apologize for that.


>From: Paul Jakma <paul@clubi.ie>
>To: kartikey bhatt <kartik_me@hotmail.com>
>CC: torvalds@osdl.org, linux-kernel@vger.kernel.org
>Subject: Re: Can't X be elemenated?
>Date: Tue, 30 Sep 2003 19:48:22 +0100 (IST)
>
>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/

_________________________________________________________________
Get Married!  http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Search 
from 7 lakh Brides & Grooms.

Re: Can't X be elemenated?

[Tupshin Harper]

kartikey bhatt wrote:

> hey everyone who have joined this thread, my fundamental question have 
> got
> out of scope. I mean to say
>
> 1. Kernel level support for graphics device drivers.

Done

> 2. On top of that, one can develop complete lightweight GUI.

Not relevant to this list

> 3. Maybe kernel can provide support for event handling.

Why?

-Tupshin

Re: Can't X be elemenated?

[Jesse Pollard]

On Tuesday 30 September 2003 23:32, kartikey bhatt wrote:
> hey everyone who have joined this thread, my fundamental question have got
> out of scope. I mean to say
>
> 1. Kernel level support for graphics device drivers.

Ok.

> 2. On top of that, one can develop complete lightweight GUI.

don't want it in the kernel (bloat)

> 3. Maybe kernel can provide support for event handling.

already does.

> and I still stick to my opinion that graphics card is a computer resource
> that needs to be managed by OS rather than 3rd party developers.
> Just feeding in patches to provide support for AGP gart and DRI
> is an adhoc solution, a stark immoral choice.
> you don't know my frustration when i got PC and wasn't able to
> run X until i810 agp gart support was available at kernel level.
>
> And if you feel that I am a guy heavily dependent on X that's not true.
> I just mean to say if anything is that kernel level support for graphics
> device drivers.
> And X will be automatically eliminated.

don't need it/already done in the frame buffer.

You CAN also look at the GGI project (http://www.ggi-project.org/)

They have an interesting approach (only slightly superseded by the
framebuffer driver) - They are/were looking at dividing the graphics
resource into its' components. Clock drivers, video registers drivers, GPU
interface drivers, graphic event queue driver. Last time I was looking
(shortly after the framebuffer introduction) they wanted to be able to mix
and match the components to the actual devices on the video board (since
many of them use the same fundamental components) and eliminate the "one
driver one video device" aspect.

It may even be suitable for embeded devices... though I think they kinda
got too large since then.

They also support X.

> and if you are feeling very unhappy about my statement X is bloat,
> I really apologize for that.

Not unhappy, it just indicated a bit of experience lacking.

Re: Can't X be elemenated?

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 1 Oct 2003, kartikey bhatt wrote:

[...]
> 2. On top of that, one can develop complete lightweight GUI.

I wonder how such a move would impact the users of other free OSes like
FreeBSD. They use the same X afaik.

I think you might get locked into this new gui like in the trap. X is not
lightweight but it is kind of universal. This means, you can get app
written originally for Solaris or SGI and in most cases you "just
recompile" it and it's available on Linux. Just like this. And if you
started forcing new gui, some people would stay with X and some would
switch - all of this might do nothing good to growing the number of 
applications that could run on Linux.

Such a lightweight gui is nowadays needed only on some very specific
platforms, IMHO. Those with less memory and cpu, like handhelds and other
embedded applications.

Think of MS Windows family - they are a real bloat but they are more or
less unified. Not that I admire the way MS did it but I think I can still
run 16-bit apps on Win 2000 (if I really wanted to trash filesystem with
old dlls). This ability to accumulate applications over long period of
time shouldn't be discarded. In reality, you would probably have ended
with a small number of people using lightweight gui and the rest of people
staying with X, which has better support and good number of developers.
Right now, the only real alternative is - in my opinion -
QTopia/QTEmbedded/Opie. You can try to run this on your PC (I think I have
read somewhere on the net it is possible). 

If, on the other hand, you would like to see what happens to less used
guis, try looking on this:

http://hack.org/~mc/mgr/index.html

MGR has nice minimalistic look but isn't in very active development today.
Guess why? It aimed to be 10x faster than X for example, but today
hardware has more power and X has improved too.

On the other hand, if all you need is terminal emulator and some other
similar apps, you may find what you are looking for. But I really think
all of your problems come from some badly written driver or an app eating
too much memory. Not X as a kind of gui but poor implementation.

[...]
> you don't know my frustration when i got PC and wasn't able to
> run X until i810 agp gart support was available at kernel level.

You know, while waiting for the support to come, you can use some cheap
old pci card. I have seen used Matrox Millenium 2 for about $4. I myself
use mm2/agp and it gives me great desktop, excellent for reading and
writing texts and watching tv. Just enough power to work. Very stable,
sharp etc. On the other hand they tend to be treated like a trash because
of not having support for all these fancy 3d things.

And next time before buying a mobo, try to ensure it is already supported
under Linux. The same applies to onboard sound and ether.

[...]
> and if you are feeling very unhappy about my statement X is bloat,
> I really apologize for that.

I don't feel unhappy with this but I think you can do much better - since
my old matrox w/4m ram has no problems with handling me without hickup.

How about trying some development version of X from CVS? Or asking about
your chipset on X-related newsgroup?

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBP3schBETUsyL9vbiEQLznQCdFxF3xMja6bp667Jw9oVLV4hnjp4AoPYo
YYl31jQtxtTzloiBZmb1yzdw
=iZ5a
-----END PGP SIGNATURE-----

Re: Can't X be elemenated?

[Helge Hafting]

kartikey bhatt wrote:
> hey everyone who have joined this thread, my fundamental question have got
> out of scope. I mean to say
> 
> 1. Kernel level support for graphics device drivers.
> 2. On top of that, one can develop complete lightweight GUI.
> 3. Maybe kernel can provide support for event handling.
> 
> and I still stick to my opinion that graphics card is a computer resource
> that needs to be managed by OS   rather than 3rd party developers.

The card is managed by the os - X has to ask the kernel nicely to get it.
(Try starting another X server inside an xterm and see how
that is refused.)

The details of drawing the windows is something the os don't
need to worry about though - that is the job of X.

Please explain whats wrong about "3rd party developers".  Depending on
how you look at it, all of linux is "3rd part developers" except from Linus.

> Just feeding in patches to provide support for AGP gart and DRI
> is an adhoc solution, a stark immoral choice.

Explain the immoral part. Committing a crime is (usually) immoral.
Designing software in a way you dislike isn't.

> you don't know my frustration when i got PC and wasn't able to
> run X until i810 agp gart support was available at kernel level.
> 
So?

Having graphichs in the kernel would *not* change this at all.
You would still have to wait for graphichs support for your card.
The kernel would still have to support i810 agp gart.

Linux doesn't support every graphics solution in existence.  That is
a fact of life.  Wheter the missing part is in kernel or somewhere
else doesn't matter at all.  It either works or it don't.

> And if you feel that I am a guy heavily dependent on X that's not true.


> I just mean to say if anything is that kernel level support for graphics 
> device drivers.
This sentence didn't make sense to me.  Syntax error? :-)


> And X will be automatically eliminated.
Sure.  Having the kernel provide graphichs would eliminate X, if the
kernel would support all the stuff X supports.  But whats the
_point_ of eliminating X?

1. It wouldn't be faster
2. You wouldn't get support for more cards this way
3. It wouldn't be better in other ways either

Using X for graphichs is nice however, for several reasons:

1. Separation of kernel and graphichs system.  This means
    we can trivially run without graphichs if we don't need it.
    And yes - there are many such uses for linux.  The desktop
    is merely one of many places where you find linux.
2. There would be fewer graphichs developers for linux with
    the graphichs in-kernel.  Today X is used not only by linux people,
    it is also used by other unices like bsd, and others too.
    A bsd/os2/... X developer working on X today will benefit linux
    too.  That won't happen with a graphichs system internal to linux.


Helge Hafting

Re: Can't X be elemenated?

[Herbert Poetzl]

On Thu, Oct 02, 2003 at 10:57:42AM +0200, Helge Hafting wrote:
> kartikey bhatt wrote:
> >hey everyone who have joined this thread, my fundamental question have got
> >out of scope. I mean to say
> >
> >1. Kernel level support for graphics device drivers.
> >2. On top of that, one can develop complete lightweight GUI.
> >3. Maybe kernel can provide support for event handling.
> >
> >and I still stick to my opinion that graphics card is a computer resource
> >that needs to be managed by OS   rather than 3rd party developers.
> 
> The card is managed by the os - X has to ask the kernel nicely to get it.
> (Try starting another X server inside an xterm and see how
> that is refused.)

X :2 (not refused ...)

> The details of drawing the windows is something the os don't
> need to worry about though - that is the job of X.
> 
> Please explain whats wrong about "3rd party developers".  Depending on
> how you look at it, all of linux is "3rd part developers" except from Linus.
> 
> >Just feeding in patches to provide support for AGP gart and DRI
> >is an adhoc solution, a stark immoral choice.
> 
> Explain the immoral part. Committing a crime is (usually) immoral.
> Designing software in a way you dislike isn't.

depends on the moral standards ...

best,
Herbert

Re: Can't X be elemenated?

[Jesse Pollard]

On Thursday 02 October 2003 13:18, Herbert Poetzl wrote:
> On Thu, Oct 02, 2003 at 10:57:42AM +0200, Helge Hafting wrote:
> > kartikey bhatt wrote:
> > >hey everyone who have joined this thread, my fundamental question have
> > > got out of scope. I mean to say
> > >
> > >1. Kernel level support for graphics device drivers.
> > >2. On top of that, one can develop complete lightweight GUI.
> > >3. Maybe kernel can provide support for event handling.
> > >
> > >and I still stick to my opinion that graphics card is a computer
> > > resource that needs to be managed by OS   rather than 3rd party
> > > developers.
> >
> > The card is managed by the os - X has to ask the kernel nicely to get it.
> > (Try starting another X server inside an xterm and see how
> > that is refused.)
>
> X :2 (not refused ...)

Thats because X asked nicely, and was given another vertual terminal, and
started server #2... By default it attempts to start 0; and that is refused.

Specifying a different server number will permit it to be run, if there are
available VTs.

You should be able to run at least 7, if they don't have login prompts on
them.

Re: Can't X be elemenated?

[Erik Steffl]

Helge Hafting wrote:
> kartikey bhatt wrote:
> 
>> hey everyone who have joined this thread, my fundamental question have 
>> got
>> out of scope. I mean to say
>>
>> 1. Kernel level support for graphics device drivers.
>> 2. On top of that, one can develop complete lightweight GUI.
>> 3. Maybe kernel can provide support for event handling.
>>
>> and I still stick to my opinion that graphics card is a computer resource
>> that needs to be managed by OS   rather than 3rd party developers.
> 
> 
> The card is managed by the os - X has to ask the kernel nicely to get it.
> (Try starting another X server inside an xterm and see how
> that is refused.)

   that has nothing to do with kernel. If you are running display 0 and 
start another X (without specifying display, it default to 0) it doesn't 
work since there cannot be two servers on same machine both being 0. You 
can start another X server with different number (e.g. startx -- :1 or 
whatever number is not used yet).

	erik

Re: Can't X be elemenated?

[Ihar 'Philips' Filipau]

kartikey bhatt wrote:
> hey everyone who have joined this thread, my fundamental question have got
> out of scope. I mean to say
> 

   And we meant to answer.

> 1. Kernel level support for graphics device drivers.

   Already done. Look for DRI/DRM/framebuffer.

> 2. On top of that, one can develop complete lightweight GUI.

   That's not a kernel stuff - but it is already done - google around 
for microwindows nanogui - you will find links for light-weight GUIs.

   Bringing this into kernel space will make it only slower. On 
performance critical pathes people avoid simple calls - and you want to 
bring here system call...

> 3. Maybe kernel can provide support for event handling.

   Already in place for last two decades - poll()/select().

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML