Hello.

I want constructive discussion, please leave all "x ftw and x md" out,
but instead point where i'm wrong or maybe we could change our minds
in some better way.

I'm not as much into kernel and X internal as i'd like to be, but
here's what i know:

(really basically)
1) there is a kernel, which knows how to put graphic data into
different video cards video memory and it's called "kernel video
driver",

2) there is X video driver, which knows how to call kernel video
driver to draw current X screen layout

3) there is an application of type "window manager" or something like
that, which knows about current running applications' windows and
tells X to draw those windows

Same picture is for input devices like keyboard, mouse. What the hell
X is doing here? I can see either kernel drivers or X drivers are out
of adequate architecture. Am i wrong?

This is part 1 - why another hardware abstraction layer. Please,
comment here.

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

I'm sorry for my bad English.

Temoto wrote:
>
> Same picture is for input devices like keyboard, mouse. What the hell
> X is doing here? I can see either kernel drivers or X drivers are out
> of adequate architecture. Am i wrong?
>
> This is part 1 - why another hardware abstraction layer. Please,
> comment here.
well i think its pretty obvious
1. the kernel-part driver is because not everyone wants to use X,
they just need to run httpd, or fsck (rescue disks) while still
providing a friendly user-interface (menus/framebuffer graphics).
2. the X servers exists because not all X servers supports all the
drivers.
Xgl may work with nvidia/frglx, but Xvesa is still lightweight
enough to be
used on most desktops, especially if a kernel-driver doesnt work.
3. the window manager pretty much a matter of taste, some like
KDE/Gnome are geared towards optimizing their targets (Qt/Gtk),
these cannot be "integrated" into Xserver because then the
applications
would depend on the hardware (or at minimum X-spesific-servers).

>
> Second, we-use-network. Very fine that i don't need to provide an IP
> stack, firewall to see movie and browser. It can be done through
> sockets and is configured such way by default. Very good. But why
> anyway? Why should it be possible to run X server on some other
> machine than mine? Anyone is really using it? Isn't it like dead
> concept along with mainframes? I have laptop with such an good graphic
> card, it can really draw graphic so well. Dedicated X drawing server
> is really out of business here. I have a strong opinion that this is a
> common situation. I believe it could be like branch of Xorg or config
> option that runs faster because it really relies only on local
> hardware.
>
> Why X should use network subsystem? Please, comment here.
>
this is a development thing actually, normally we can switch
between X and console but in rare cases where X doesnt release
its control over the terminal and hung, having it listens on a port
can be useful. this is common to all X servers, XVnc just extends
this to be a "remote desktop" feature.
I dont think this is spesific to linux, even windows have them.
Makes administrator's life alot easier than to dangerously sit in
front
of the server all day.

> Third, how to think different. There is a framebuffer kernel video
> driver. What is wrong with it for using it instead of X? I understand
> that all apps relay on X. It's a matter of lots code changes, i
> understand all. Just theoretically, is there something wrong? Maybe
> some performance issues? Like limiting kernel time execution or
> something... i believe this could have relatively simple solution.
>
> I'm sorry for my bad English.
Well, part 1 oughta clear this last question. kernel-drivers are basic
bootstrap enough to get a framebuffer, the X-drivers has more gui-
intensive
operations (3D, multimonitor, multicards, that complex mandlebrot in
simple
commands). Its not meant as a limitation,
ok you can play video with a framebuffer device, but you cant get them
to play on a cube or stretch across 4 monitors, this requires
intensive hardware
support which not all of us required.
its separated so you can still have office-like desktops or friendly-
servers without
burdening your hardware to much, but still be able play 3d-games once
a while.
As for which part of the hardware belongs to the kernel fb or the X
driver, thats up
to standards i think, the X developers naturally have more knowledge
into how to
tweak the hardware more (i.e Xnvidia) than the generalized
framebuffer.

Ys

Temoto wrote:
>
>I'm not as much into kernel and X internal as i'd like to be, but
>here's what i know:
>
>(really basically)
>1) there is a kernel, which knows how to put graphic data into
>different video cards video memory and it's called "kernel video
>driver",
>
>2) there is X video driver, which knows how to call kernel video
>driver to draw current X screen layout
>
>3) there is an application of type "window manager" or something like
>that, which knows about current running applications' windows and
>tells X to draw those windows
>
>Same picture is for input devices like keyboard, mouse. What the hell
>X is doing here? I can see either kernel drivers or X drivers are out
>of adequate architecture. Am i wrong?

You are wrong.

There are some very good reasons why this "dual layer" architecture still
makes sense. Typically, a graphics chip vendor has a large number of
devices, but those devices are in families. All of the devices in a family
will have essentially the same hardware initialization sequences, but
different capabilities in the drawing primitives.

By encapsulating the hardware initialization stuff in one layer, but
putting the drawing support in another, the vendor can introduce new
drawing capabilities by changing just one layer. For those keeping score
at home, this is also exactly how Windows works: the miniport handles the
hardware initialization and memory management, and the display driver
handles only the drawing.

Further, by putting the hardware initialization in the kernel, it enables
graphical systems other than X to use the hardware. Most of the non-X
windowing systems don't care all that much about 2D acceleration, so the
division doesn't hurt them.

>Second, we-use-network. Very fine that i don't need to provide an IP
>stack, firewall to see movie and browser. It can be done through
>sockets and is configured such way by default. Very good. But why
>anyway? Why should it be possible to run X server on some other
>machine than mine? Anyone is really using it? Isn't it like dead
>concept along with mainframes?

Just because YOU don't need it doesn't mean it isn't used. There are still
places where you have a massive central server with inexpensive display
systems around the building.

>I have laptop with such an good graphic
>card, it can really draw graphic so well. Dedicated X drawing server
>is really out of business here. I have a strong opinion that this is a
>common situation. I believe it could be like branch of Xorg or config
>option that runs faster because it really relies only on local
>hardware.
>
>Why X should use network subsystem? Please, comment here.

You might want to scan through some of the X.Org source code. If the
client and server are on the same machine, it doesn't use a network stack.
There's a direct connection.

>Third, how to think different. There is a framebuffer kernel video
>driver. What is wrong with it for using it instead of X? I understand
>that all apps relay on X. It's a matter of lots code changes, i
>understand all. Just theoretically, is there something wrong? Maybe
>some performance issues? Like limiting kernel time execution or
>something... i believe this could have relatively simple solution.

The kernel video driver is very simple, as kernel code should always be. It
knows how to initialize the hardware, and it knows how do to a few simple
functions. It doesn't know how to get your graphics chip to draw lines, or
do solid fills, or pattern fills, or screen-to-screen blits, or font-based
text drawing, or solid lines, etc. All of that knowledge is embedded in
the X server driver.

That stuff is complicated. If the driver has a bug, it's going to be in
the drawing code. Better that the drawing bug be in a user-mode component
tht can be killed and restarted, rather than in a kernel driver that
requires a reboot.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Temoto writes:
>Second, we-use-network. Very fine that i don't need to provide an IP
>stack, firewall to see movie and browser. It can be done through
>sockets and is configured such way by default. Very good. But why
>anyway? Why should it be possible to run X server on some other
>machine than mine?

Are you confusing X server and X client here? The X server is the
program that does the graphics, and the one you use runs on a machine
close to the monitor you are looking at (your machine in your
terminology), the client can run on any machine in the world.

> Anyone is really using it?

I use it every day.

In the office I have a small, quiet, and energy-efficient X terminal
(or "thin client" in current marketing-speak), and every single
program, including the window manager runs on other machines.

At home I have a PC that's as fast as any of the servers I am
connecting to, but I still use that feature to run programs like emacs
and xrn on those servers; that's because these machines have other
resources/features that my home PC does not have; in particular, files
reside there that don't reside on my home machine, and some of these
machines have a different hardware architecture or version of some
software than on my home PC.

>Isn't it like dead
>concept along with mainframes? I have laptop with such an good graphic
>card, it can really draw graphic so well. Dedicated X drawing server
>is really out of business here.

The keyboard, screen and mouse of my laptop are worse than on my X
terminal. Ok, maybe I could connect an external screen and keyboard
and mouse that are as good as the ones I use on the X terminal, but
then I would have to disconnect them when I take the laptop with me.
Also, my laptop is noisy: It's disk is hearable (although not very
loud), and sometimes its CPU fan spins quite noisily. So I definitely
prefer my current setup with the X terminal.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Temoto writes:
>
> Second, we-use-network. Very fine that i don't need to provide an IP
> stack, firewall to see movie and browser. It can be done through
> sockets and is configured such way by default. Very good. But why
> anyway? Why should it be possible to run X server on some other
> machine than mine? Anyone is really using it? Isn't it like dead
> concept along with mainframes? I have laptop with such an good graphic
> card, it can really draw graphic so well. Dedicated X drawing server
> is really out of business here. I have a strong opinion that this is a
> common situation. I believe it could be like branch of Xorg or config
> option that runs faster because it really relies only on local
> hardware.
>
> Why X should use network subsystem? Please, comment here.

This is actually incredibly useful, and I use it every day -- being
able to run gnumeric on my laptop, with the display appearing on my
desktop, makes life much, much easier for me. I think this is
definitely one of the differences between somebody who grew up on
Windows and somebody who grew up on Unix: having to actually be
physically at a computer to work with it seems horribly limiting to an
old Unix person, while working any other way seems useless to an old
Windows person.

> Third, how to think different. There is a framebuffer kernel video
> driver. What is wrong with it for using it instead of X? I understand
> that all apps relay on X. It's a matter of lots code changes, i
> understand all. Just theoretically, is there something wrong? Maybe
> some performance issues? Like limiting kernel time execution or
> something... i believe this could have relatively simple solution.

Does the framebuffer driver support acceleration?

On Aug 18, 6:50*pm, Joe Pfeiffer wrote:
> Temoto writes:
>
> > Second, we-use-network. Very fine that i don't need to provide an IP
> > stack, firewall to see movie and browser. It can be done through
> > sockets and is configured such way by default. Very good. But why
> > anyway? Why should it be possible to run X server on some other
> > machine than mine? Anyone is really using it? Isn't it like dead
> > concept along with mainframes? I have laptop with such an good graphic
> > card, it can really draw graphic so well. Dedicated X drawing server
> > is really out of business here. I have a strong opinion that this is a
> > common situation. I believe it could be like branch of Xorg or config
> > option that runs faster because it really relies only on local
> > hardware.
>
> > Why X should use network subsystem? Please, comment here.
>
> This is actually incredibly useful, and I use it every day -- being
> able to run gnumeric on my laptop, with the display appearing on my
> desktop, makes life much, much easier for me. *I think this is
> definitely one of the differences between somebody who grew up on
> Windows and somebody who grew up on Unix: *having to actually be
> physically at a computer to work with it seems horribly limiting to an
> old Unix person, while working any other way seems useless to an old
> Windows person.

There is crossplatform VNC. I've heard that its protocol is much more
network friendly than one of X.
Anyway, you're limited to screen and keyboard/mouse. There is no
remote sound and printers in X. Those are equally part of user
interface along with screen and keyboard.

> > Third, how to think different. There is a framebuffer kernel video
> > driver. What is wrong with it for using it instead of X? I understand
> > that all apps relay on X. It's a matter of lots code changes, i
> > understand all. Just theoretically, is there something wrong? Maybe
> > some performance issues? Like limiting kernel time execution or
> > something... i believe this could have relatively simple solution.
>
> Does the framebuffer driver support acceleration?

No, but i'm trying to be positive.

Is there anything stopping it to support? Maybe it should stay
lightweight nice console option.
Is there anything stopping writing another "heavy framebuffer",
supporting modern videocards features? I guess no.

On Aug 18, 9:50*am, Tim Roberts wrote:
> Temoto wrote:
>
> >I'm not as much into kernel and X internal as i'd like to be, but
> >here's what i know:
>
> >(really basically)
> >1) there is a kernel, which knows how to put graphic data into
> >different video cards video memory and it's called "kernel video
> >driver",
>
> >2) there is X video driver, which knows how to call kernel video
> >driver to draw current X screen layout
>
> >3) there is an application of type "window manager" or something like
> >that, which knows about current running applications' windows and
> >tells X to draw those windows
>
> >Same picture is for input devices like keyboard, mouse. What the hell
> >X is doing here? I can see either kernel drivers or X drivers are out
> >of adequate architecture. Am i wrong?
>
> You are wrong. *
>
> There are some very good reasons why this "dual layer" architecture still
> makes sense. *Typically, a graphics chip vendor has a large number of
> devices, but those devices are in families. *All of the devices in a family
> will have essentially the same hardware initialization sequences, but
> different capabilities in the drawing primitives.
>
> By encapsulating the hardware initialization stuff in one layer, but
> putting the drawing support in another, the vendor can introduce new
> drawing capabilities by changing just one layer. *For those keeping score
> at home, this is also exactly how Windows works: the miniport handles the
> hardware initialization and memory management, and the display driver
> handles only the drawing.
>
> Further, by putting the hardware initialization in the kernel, it enables
> graphical systems other than X to use the hardware. *Most of the non-X
> windowing systems don't care all that much about 2D acceleration, so the
> division doesn't hurt them.

What if we go more further and embed second layer into new kernel
drivers?
Not only initialization, but drawing too.

> >Second, we-use-network. Very fine that i don't need to provide an IP
> >stack, firewall to see movie and browser. It can be done through
> >sockets and is configured such way by default. Very good. But why
> >anyway? Why should it be possible to run X server on some other
> >machine than mine? Anyone is really using it? Isn't it like dead
> >concept along with mainframes?
>
> Just because YOU don't need it doesn't mean it isn't used. *There are still
> places where you have a massive central server with inexpensive display
> systems around the building.

Remote desktop can handle those.

> >I have laptop with such an good graphic
> >card, it can really draw graphic so well. Dedicated X drawing server
> >is really out of business here. I have a strong opinion that this is a
> >common situation. I believe it could be like branch of Xorg or config
> >option that runs faster because it really relies only on local
> >hardware.
>
> >Why X should use network subsystem? Please, comment here.
>
> You might want to scan through some of the X.Org source code. *If the
> client and server are on the same machine, it doesn't use a network stack..
> There's a direct connection.

Yes, they even make use of shared memory, that kills network argue.

> >Third, how to think different. There is a framebuffer kernel video
> >driver. What is wrong with it for using it instead of X? I understand
> >that all apps relay on X. It's a matter of lots code changes, i
> >understand all. Just theoretically, is there something wrong? Maybe
> >some performance issues? Like limiting kernel time execution or
> >something... i believe this could have relatively simple solution.
>
> The kernel video driver is very simple, as kernel code should always be. It
> knows how to initialize the hardware, and it knows how do to a few simple
> functions. *It doesn't know how to get your graphics chip to draw lines, or
> do solid fills, or pattern fills, or screen-to-screen blits, or font-based
> text drawing, or solid lines, etc. *All of that knowledge is embedded in
> the X server driver.
>
> That stuff is complicated. *If the driver has a bug, it's going to be in
> the drawing code. *Better that the drawing bug be in a user-mode component
> tht can be killed and restarted, rather than in a kernel driver that
> requires a reboot.

This could be like separate process 'graphic driver'. Like on
microkernels.
And it could be even proprietary, supplied by videocard vendor. But
only a tiny driver, UNIX way. Not a all-in-one bloatware.

> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

On Aug 13, 6:23*pm, Temoto wrote:
> [cut]

Now thanks to responders i see three major parts that X is compound
of.

1) video driver, renderer

For video drivers there are solutions like, well, drivers in Windows.

2) remote desktop (even if it goes to local desktop in optimized way,
such as shared memory)

For remote desktop there are solutions like VNC.

3) generalized UI, hardware abstraction (program that wants to
interact with user, interacts with X instead of kernel and drivers)

Hardware abstraction is nonsense for me, since there are configurable
makefiles, plugins, versioning and so much abstraction possibilities
to build, say, window manager running just fine directly with video
drivers. And this layer is not complete, because there is no sound and
printers support in it. Maybe something important too.
Actually i hate this point most of all. Because i see least of
usefulness here.

And i feel this is not UNIX "one small program making small job
perfectly" way. In my imagination's perfect world, X should be
splitted into three separate programs, handling those three separate
tasks. Oh well better in 2 separate programs since third is not
needed. Oh well just become a video driver.

Isn't that right?

Temoto wrote:

> Further, by putting the hardware initialization in the kernel, it enables
>> graphical systems other than X to use the hardware. Â*Most of the non-X
>> windowing systems don't care all that much about 2D acceleration, so the
>> division doesn't hurt them.
>
> What if we go more further and embed second layer into new kernel
> drivers?
> Not only initialization, but drawing too.
Bad idea as the complicated part is the drawing part. Kernel Code could not
be exchanged that easily as user mode (ok, there are kernel modules). But
much more important: code running in kernel mode is always much more
dangerous than user mode. There is definitly much better code isolation and
protection against bugs and wormholes for user mode. Keep the kernel as
simple as possible.

Compare this to the old printer driver model of windows which also had
kernel mode drivers. That's one of the biggest sources for BSOD's on
Windows!

That is also one of the reasons why I don't like nvidia and ATI drivers for
X11, as they pack much too much into kernel mode. But currently there is no
alternative, as they didn't open their sources/docs until recently. Things
are changing at least for ATI.

>> Just because YOU don't need it doesn't mean it isn't used. Â*There are
>> still places where you have a massive central server with inexpensive
>> display systems around the building.
>
> Remote desktop can handle those.
Not always in the way you want. Think of a big multi user system. VNC is a
bad idea as it just copies the screen of the graphics card. So VNC is nice
for remote support of windows clients and for console display of virtual
machines.
RDP has nice compression, but is only avail for M$ Servers and how they got
it into their Windows Server is a big mess. Some programs do not work with
it or need much struggling with permissions and registry.

NX is very nice, but gee it uses X11 underneath!

> This could be like separate process 'graphic driver'. Like on
> microkernels.
> And it could be even proprietary, supplied by videocard vendor. But
> only a tiny driver, UNIX way. Not a all-in-one bloatware.
Better they open their source code, and or open their documentation. Both
ATI and NVIDIA proprietary drivers have big pitfalls and sometimes don't
even run with some kernels. Separation in a different process is already
the concept of X11. Also the X.Org Server is already modularized with an
API for connecting proprietary drivers.

Sincerly,
Klaus

Temoto writes:

> On Aug 18, 6:50*pm, Joe Pfeiffer wrote:
>> Temoto writes:
>>
>> > Second, we-use-network. Very fine that i don't need to provide an IP
>> > stack, firewall to see movie and browser. It can be done through
>> > sockets and is configured such way by default. Very good. But why
>> > anyway? Why should it be possible to run X server on some other
>> > machine than mine? Anyone is really using it? Isn't it like dead
>> > concept along with mainframes? I have laptop with such an good graphic
>> > card, it can really draw graphic so well. Dedicated X drawing server
>> > is really out of business here. I have a strong opinion that this is a
>> > common situation. I believe it could be like branch of Xorg or config
>> > option that runs faster because it really relies only on local
>> > hardware.
>>
>> > Why X should use network subsystem? Please, comment here.
>>
>> This is actually incredibly useful, and I use it every day -- being
>> able to run gnumeric on my laptop, with the display appearing on my
>> desktop, makes life much, much easier for me. *I think this is
>> definitely one of the differences between somebody who grew up on
>> Windows and somebody who grew up on Unix: *having to actually be
>> physically at a computer to work with it seems horribly limiting to an
>> old Unix person, while working any other way seems useless to an old
>> Windows person.
>
> There is crossplatform VNC. I've heard that its protocol is much more
> network friendly than one of X.

Never mind that you've somehow jumped from arguing that using a gui
application across the network to arguing that there's a way to do it
better, AFAIK X is more flexible. No idea which is more
network-friendly.

> Anyway, you're limited to screen and keyboard/mouse. There is no
> remote sound and printers in X. Those are equally part of user
> interface along with screen and keyboard.

Not having sound in X was a terrible oversight, no question (though
I've got no idea how it could reasonably have been included).
Printing is very different, and it's perfectly reasonable in a
networked enviroment that the printers be on different machines from
either my compute server or my workstation.

Joe Pfeiffer writes:
>Printing is very different, and it's perfectly reasonable in a
>networked enviroment that the printers be on different machines from
>either my compute server or my workstation.

Yes. But the printer I want to use at the moment is usually
relatively close to my workstation/X-terminal, whereas the compute
server might be very far away, and may not even know about the printer
I want to use. E.g., if I'm at home, and I use a client running on
one of the machines in the office, the printer I typically want to use
is my home printer, but the machine at the office does not know about
it.

It's even more extreme if I run programs on servers of other
organizations, which may be physically very far away, and where we
don't want everyone on that server to be able to print on our local
printers, nor do I want to bother the server's admin with configuring
our local printer on that server.

So it would be a good idea to piggyback printing onto one of the
typical connections between the user and the compute server, i.e.,
either X or ssh.

AFAIK there was some work on printing in some X Consortion version of
X; googling for it, I find mentions of:

|X Print Extension Protocol
|X Version 11, Release 6.4
|
|X Print Extension Library
|X Version 11, Release 6.4

However, according to this
extension is deprecated.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Joe Pfeiffer writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Another thing that's close to the user that would be nice
>> to have would be support for removable storage (nowadays mostly USB
>> sticks).
>
>USB sticks are something else different enough from the gui that I
>don't see why it should be integrated.

X is a connection between the remote machine and a machine close to
the user. It would be convenient if the remote machine could talk to
a USB stick plugged into the machine close to the user. One way to do
this would be by piggybacking the traffic to the USB stick onto the X
traffic; an alternative would be to do it through ssh.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Joe Pfeiffer writes:
>>Printing is very different, and it's perfectly reasonable in a
>>networked enviroment that the printers be on different machines from
>>either my compute server or my workstation.
>
> Yes. But the printer I want to use at the moment is usually
> relatively close to my workstation/X-terminal, whereas the compute
> server might be very far away, and may not even know about the printer
> I want to use. E.g., if I'm at home, and I use a client running on
> one of the machines in the office, the printer I typically want to use
> is my home printer, but the machine at the office does not know about
> it.
>
> It's even more extreme if I run programs on servers of other
> organizations, which may be physically very far away, and where we
> don't want everyone on that server to be able to print on our local
> printers, nor do I want to bother the server's admin with configuring
> our local printer on that server.
>
> So it would be a good idea to piggyback printing onto one of the
> typical connections between the user and the compute server, i.e.,
> either X or ssh.

The thing is, X wants to move stuff to your workstation, not nearby
workstations.

Your example of being able to print at home is one that resonates with
me -- except that I've got two desktops and two laptops at home, and
only one of the four has a printer. Tunnelling IPP over ssh,
similarly to how we tunnel X, does have some appeal, thnough...

At work, we use print servers, so it's not at all uncommon for me to
run a program on one computer, show its gui on my workstation, and
print on yet another machine.

> AFAIK there was some work on printing in some X Consortion version of
> X; googling for it, I find mentions of:
>
> |X Print Extension Protocol
> |X Version 11, Release 6.4
> |
> |X Print Extension Library
> |X Version 11, Release 6.4
>
> However, according to this
> extension is deprecated.

Wasn't aware it was now deprecated, but I sure never had any luck with
it...

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Joe Pfeiffer writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> Another thing that's close to the user that would be nice
>>> to have would be support for removable storage (nowadays mostly USB
>>> sticks).
>>
>>USB sticks are something else different enough from the gui that I
>>don't see why it should be integrated.
>
> X is a connection between the remote machine and a machine close to
> the user. It would be convenient if the remote machine could talk to
> a USB stick plugged into the machine close to the user. One way to do
> this would be by piggybacking the traffic to the USB stick onto the X
> traffic; an alternative would be to do it through ssh.

Tunneling more through ssh does sound interesting...

Joe Pfeiffer writes:
>The thing is, X wants to move stuff to your workstation, not nearby
>workstations.

Well, often your workstation knows how to print on the printer you
want to print on, even if that printer is connected to a different
machine.

Ok, that's not true of my X-terminal at the office, but if there was
printing through X, it would know how to print.

>Your example of being able to print at home is one that resonates with
>me -- except that I've got two desktops and two laptops at home, and
>only one of the four has a printer.

But I guess all four can use that printer, right?

>> AFAIK there was some work on printing in some X Consortion version of
>> X; googling for it, I find mentions of:
>>
>> |X Print Extension Protocol
>> |X Version 11, Release 6.4
>> |
>> |X Print Extension Library
>> |X Version 11, Release 6.4
>>
>> However, according to this
>> extension is deprecated.
>
>Wasn't aware it was now deprecated, but I sure never had any luck with
>it...

From what I read, it seems to have somewhat different (and more
ambitious) goals than what I outlined.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Joe Pfeiffer writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> X is a connection between the remote machine and a machine close to
>> the user. It would be convenient if the remote machine could talk to
>> a USB stick plugged into the machine close to the user. One way to do
>> this would be by piggybacking the traffic to the USB stick onto the X
>> traffic; an alternative would be to do it through ssh.
>
>Tunneling more through ssh does sound interesting...

I guess the tunneling part is the easy part, but one would probably
have to mount the stick in some way on the remote system, and it
should only be accessible by the user. If we want near-universal
support (i.e., many platforms) for that, that's quite a lot of work.
In Linux, one can probably implement it through FUSE.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Joe Pfeiffer writes:
>>The thing is, X wants to move stuff to your workstation, not nearby
>>workstations.
>
> Well, often your workstation knows how to print on the printer you
> want to print on, even if that printer is connected to a different
> machine.
>
> Ok, that's not true of my X-terminal at the office, but if there was
> printing through X, it would know how to print.
>
>>Your example of being able to print at home is one that resonates with
>>me -- except that I've got two desktops and two laptops at home, and
>>only one of the four has a printer.
>
> But I guess all four can use that printer, right?

Yes -- my point exactly. While working on a school machine from home,
I don't necessarily want to print from the machine I'm working from.

As you say above in the post I'm responding to, the machine I'm on
knows how to print to other machines on my network -- but this seems
like an argument for tunnelling IPP over ssh, not printing from X.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Joe Pfeiffer writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> X is a connection between the remote machine and a machine close to
>>> the user. It would be convenient if the remote machine could talk to
>>> a USB stick plugged into the machine close to the user. One way to do
>>> this would be by piggybacking the traffic to the USB stick onto the X
>>> traffic; an alternative would be to do it through ssh.
>>
>>Tunneling more through ssh does sound interesting...
>
> I guess the tunneling part is the easy part, but one would probably
> have to mount the stick in some way on the remote system, and it
> should only be accessible by the user. If we want near-universal
> support (i.e., many platforms) for that, that's quite a lot of work.
> In Linux, one can probably implement it through FUSE.

Come to think of it, now that your bring up FUSE, it would probably be
pretty straightforward to do it with sshfs.

Temoto wrote:
>
>There is crossplatform VNC. I've heard that its protocol is much more
>network friendly than one of X.

That statement is provably false.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Temoto wrote:

< snip >

> There is crossplatform VNC. I've heard that its protocol is much more
> network friendly than one of X.

You have heard wrong

> Anyway, you're limited to screen and keyboard/mouse.

Wrong

> There is no remote sound

Wrong

> and printers in X

Pray tell, what is the remote printer sitting on the network in my setup
doing then? As well as the remote scanner and the remote fax?

> . Those are equally part of user
> interface along with screen and keyboard.

Fine. Please, demonstrate that you know what you are talking about then

< snip >
--
This problem was sponsored by Microsoft