Obsoleteness of X concept - X

This is a discussion on Obsoleteness of X concept - X ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Obsoleteness of X concept

  1. Obsoleteness of X concept

    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.

  2. Re: Obsoleteness of X concept


    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

  3. Re: Obsoleteness of X concept

    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.

  4. Re: Obsoleteness of X concept

    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

  5. Re: Obsoleteness of X concept

    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?

  6. Re: Obsoleteness of X concept

    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.

  7. Re: Obsoleteness of X concept

    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.



  8. Re: Obsoleteness of X concept

    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?

  9. Re: Obsoleteness of X concept

    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

  10. Re: Obsoleteness of X concept

    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.

  11. Re: Obsoleteness of X concept

    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

  12. Re: Obsoleteness of X concept

    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

  13. Re: Obsoleteness of X concept

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

  14. Re: Obsoleteness of X concept

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

  15. Re: Obsoleteness of X concept

    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

  16. Re: Obsoleteness of X concept

    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

  17. Re: Obsoleteness of X concept

    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.

  18. Re: Obsoleteness of X concept

    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.

  19. Re: Obsoleteness of X concept

    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.

  20. Re: Obsoleteness of X concept

    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


+ Reply to Thread
Page 1 of 2 1 2 LastLast