[TUHS] X, Suntools, and the like

[TUHS] X, Suntools, and the like

[Noel Chiappa]

    > From: "Ron Natalie"

    > I think most people will attribute the desktop metaphor to Xerox.

Strictly speaking, to Smalltalk (from PARC); things like Bravo, and the basic
user command interface on the Alto (I forget what its name was), didn't have
any concept of windows/desktop (although Bravo did use the bitmap screen).

     Noel

[TUHS] X, Suntools, and the like

[Ron Natalie]

I beg to differ.   The Star not only pioneered the WISIWYG application
presentation also the concept of the desktop.   The whole conscept of
dropping documents as icons on the desktop appears to have orginated there.
Of course, as with a lot of nifty stuff PARC and the other Xerox research
guys came up with, it never really saw wholesale product development.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Friday, March 17, 2017 9:06 AM
To: tuhs at minnie.tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] X, Suntools, and the like

    > From: "Ron Natalie"

    > I think most people will attribute the desktop metaphor to Xerox.

Strictly speaking, to Smalltalk (from PARC); things like Bravo, and the
basic user command interface on the Alto (I forget what its name was),
didn't have any concept of windows/desktop (although Bravo did use the
bitmap screen).

     Noel

[TUHS] X, Suntools, and the like

[Noel Chiappa]

    > From: "Ron Natalie"

    >>> I think most people will attribute the desktop metaphor to Xerox.

    >> Strictly speaking, to Smalltalk (from PARC)
                                             ^^^^
    > I beg to differ.  The Star not only pioneered the WISIWYG application
    > presentation

PARC _was_ Xerox. The Star was a product based on the Alto, but much of the
Star stuff was pioneered on the Alto.

For instance, WYSIWYG was one of the modes that the Alto's Bravo editor could
be run in; it definitely pre-dates the Star.

    > also the concept of the desktop.

Depending on exactly what you mean by 'desktop', that also pre-dated the Star.

I heard the multiple overlapping windows of Smalltalk (an Alto application)
likened to a collection of sheets of paper on a desktop (which is where the
term came from); clicking on one with the mouse brought it to the top, just
like pulling a particular sheet of paper out from the ones on a physical
desktop.

    > The whole conscept of dropping documents as icons on the desktop appears
    > to have orginated there.

Yes, as I mentioned:

    >> things like Bravo, and the basic user command interface on the Alto
    >> [the Exec, my brain finally coughed up the name - can't find my Alto
    >> manual at the moment] didn't have any concept of windows/desktop

The concept of having a graphical front end as the main user interface was not
from the Alto, and the Alto didn't have icons either; both came later (I'll
let the Lisa people and Star people argue that one out).

     Noel

[TUHS] X, Suntools, and the like

[Ron Natalie]

> PARC _was_ Xerox.

I know PARC was XEROX, the part of my message you edited out clearly says
that.   The quote you misattributed to me was Arnold's.

> The concept of having a graphical front end as the main user interface was
not from the Alto, and the Alto didn't have icons either; both came later
(I'll let the Lisa people and Star people argue that one out).

Yeah, well they can argue, but it's pretty clear Xerox came first.   Of
course, neither the Star  or Lisa were really full fledged commercial
products, but one might argue they are both Alto follow ons.   Jobs had seen
the Alto at PARC before Lisa was very far along.

[TUHS] X, Suntools, and the like

[Ron Natalie]

Nice thing about X was that it would talk to remote displays.    I still remember sitting in the Pentagon demonstrating that the Suntools screen lock wasn't particularly secure.
Then there was NeWS.   This was Gosling's first attempt at a deployable language.    However PostScript (even with Owen Densmore's class extensions), while a reasonable intermediary language is really sucky to actually develop.   Java was a bit more refined.

Of course, lots of things either implement X under the native window system or backdoor X with local extensions.    We got around doing high frame rate image work on X via the SharedMemoryExtension and the ability to flip buffers on the retrace interval (both extensions, but commonly implemented by many servers).

[TUHS] X, Suntools, and the like

[Nick Downing]

Hmm yes although perhaps controversially I see this as a bad feature and
one area where Microsoft actually gets it right. Despite the old issues of
"DLL Hell" which have largely been resolved by standardizing all DLLs and
in newer code by using assemblies... you have to admit that they provide a
direct, local API (indeed ABI) to every subsystem you would want to use,
here I am thinking of GDI, but also lots of things that would require
ioctls (CD burning, say) or domain specific languages (such as Postscript)
on Linux. This makes it really easy for Windows developers to use the
feature and the interface is fast and reliable. And where a domain specific
language is actually NEEDED (printing to a Postscript printer on Windows,
or RDP-type desktop remoting etc) it is easy to insert a proxy DLL or
object or device driver that does the necessary scrambling and
unscrambling. It is not so easy to go the other way as it requires
extensive emulation (think of ghostscript driving my Canon non-PS printer).

I wrote about this issue earlier using some examples like an "ESC ["
capable terminal as opposed to a memory mapped local console, or an "AT"
capable external modem as opposed to an internal "WinModem" that just
exposes its D/A and A/D converters with minimal signal processing and needs
the host to do the heavy lifting. Same thing applies to a graphics
terminal. Of course it should be programmed at a high level by specifying
shapes, etc to be drawn, regions to be blitted, clipping regions and pens
etc, a font manager, and it should be possible to load bitmaps, etc, into
its offscreen memory and/or create offscreen drawing buffers, if these
features are used correctly by applications then it is of course trivial to
add a remoting proxy driver similar to Microsoft's RDP, or indeed X Windows.

But the difficulty with X Windows is that the remoting layer is always
there, even though it is almost completely redundant today. This hurts
performance but more importantly it requires extensive workarounds as you
described, which add enormous extra complexity and in my view sharply
increase the learning curve and setup costs. Having said that, Xlib does
offer a decent API/ABI so if we just code to that it's not TOO bad, I would
like to see the rest of it deprecated though, and vendors encouraged to
implement Xlib with whatever backend seems appropriate.

The ridiculous thing here is that X setup is so damn convoluted and
incestuously tied in with the window, session and display managers, THAT IT
IS IMPOSSIBLE TO RUN X REMOTELY ANYMORE AND HAVE A FULL FEATURED DESKTOP, I
have tried many times and have had various tries at thin clients and
terminal serving in my home network and it basically fell over because
environments like Gnome do not support multiple sessions of the same home
directory, not to mention numerous other problems that mean if you login
remotely you basically just get a blank screen with a default X cursor and
maybe a context menu that can run an Xterm. Bleh! In my experience you have
to use a remoter like VNC and guess what that does, tricks X into thinking
it's running locally and then intervenes further up in the display stack to
do the actual remoting.

It's a complete dog's breakfast and frankly could never compete with
Windows in any realistic way. I use it because it is the least bad of the
available options (no way am I having advertising in my start menu and my
computer loaded with bloatware and spyware before I even open the box, and
no way am I putting up with vague messages like "Something went wrong" or
"Windows is making some checks to optimize your experience" or whatnot),
and because my computer is so fast despite being 6yrs old that X only feels
borderline sluggish, i.e. is tolerable. But so much better would be
possible with a redesign. CUPS is also a dogs breakfast and hugely
unreliable, Windows GDI printing just wins hands down for all the same
reasons. End rant.

Nick

On Mar 15, 2017 5:49 AM, "Ron Natalie" <ron at ronnatalie.com> wrote:

Nice thing about X was that it would talk to remote displays.    I still
remember sitting in the Pentagon demonstrating that the Suntools screen
lock wasn't particularly secure.
Then there was NeWS.   This was Gosling's first attempt at a deployable
language.    However PostScript (even with Owen Densmore's class
extensions), while a reasonable intermediary language is really sucky to
actually develop.   Java was a bit more refined.

Of course, lots of things either implement X under the native window system
or backdoor X with local extensions.    We got around doing high frame rate
image work on X via the SharedMemoryExtension and the ability to flip
buffers on the retrace interval (both extensions, but commonly implemented
by many servers).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170315/bdcb123b/attachment.html>

[TUHS] X, Suntools, and the like

[Tim Bradshaw]

On 15 Mar 2017, at 01:13, Nick Downing <downing.nick at gmail.com> wrote:
> 
> But the difficulty with X Windows is that the remoting layer is always there, even though it is almost completely redundant today.

It's redundant if you don't ever use machines which you aren't physically sitting next to and want to run any kind of graphical tool run on them.  I do that all the time.

--tim

[TUHS] X, Suntools, and the like

[Nick Downing]

I realized after writing that I was being slightly unfair since one valid
use case that DOES work correctly is something like:
ssh -X <some host> <command that uses X>
This is occasionally handy, although the best use case I can think of is
running a browser on some internet-facing machine so as to temporarily
change your IP address, and this use case isn't exactly bulletproof since
at least google chrome will look for a running instance and hand over to it
(despite that instance having a different DISPLAY= setting). Nevertheless
my point stands which is that IMO a programmatic API (either through .so or
.dll linkage, or through ioctls or dedicated syscalls) should be the first
resort and anything else fancy such as remoting, domain specific languages,
/proc or fuse type interfaces, whatever, should be done through extra
layers as appropriate. You shouldn't HAVE to use them.
cheers, Nick

On Mar 15, 2017 9:15 PM, "Tim Bradshaw" <tfb at tfeb.org> wrote:

On 15 Mar 2017, at 01:13, Nick Downing <downing.nick at gmail.com> wrote:
>
> But the difficulty with X Windows is that the remoting layer is always
there, even though it is almost completely redundant today.

It's redundant if you don't ever use machines which you aren't physically
sitting next to and want to run any kind of graphical tool run on them.  I
do that all the time.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170315/32bb48fd/attachment.html>

[TUHS] X, Suntools, and the like

[tfb]

On 15 Mar 2017, at 11:03, Nick Downing <downing.nick at gmail.com> wrote:
> 
> I realized after writing that I was being slightly unfair since one valid use case that DOES work correctly is something like:
> ssh -X <some host> <command that uses X>
> This is occasionally handy, although the best use case I can think of is running a browser on some internet-facing machine so as to temporarily change your IP address

I think you live in a strange alternative world, or (more likely) I do.  My world is better however.  In my world I have a machine on my desk which runs an X server (which currently is talking to the physical screen, but will I hope soon be some kind of VNC so I can push this display to wherever I need it).  I also use a large number of machines which don't have any kind of screen and on which I may want to run graphical tools.

In my experience this is what researchy type places with large-scale computing requirements have looked like essentially for ever, and it's the environment X was designed for (well, probably it was actually designed for student access at MIT but it very quickly moved into these environments).  And it works *really* well, and anything which replaces it needs to work at least as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170315/2cb03fe6/attachment.html>

[TUHS] X, Suntools, and the like

[Nick Downing]

Hmm well that DOES sound a bit patronizing, no offence taken though, I
think it's more that I almost never use graphical tools, well at least not
for any sysadmin or development type work. In the last day I ran chromium
browser, xviewer (AKA eye of gnome), xreader (AKA evince), the gimp,
libreoffice writer, and (currently) mplayer... these are all exclusively
because I HAD to work with an inherently graphical resource, so there was
no reasonable alternative but to run those programs. For anything else I
would use the command line (occasionally I do DSP type stuff with
matplotlib or gamey type stuff with pygame I guess). I can't honestly see a
use case where I would ever want to run any of those programs on a server,
since I associate all those activities with personal type stuff that only
happens on my laptop, occasionally on my home server in its role as media
centre connected to TV but not much. So that's why I say that X remoting is
irrelevant to me. At one stage I had a separate office with thin clients
(and experimental setups at home etc) but frankly it was not that useable,
not with gnome at least due to single session limitation. I also had in the
last 6 years a separate office and server at uni, I briefly ran VNC on it
and I had to do the ssh -X thing on it once or twice for whatever reason
(get an important bookmark URL, check a large Google Drive upload, that
sort of thing) but I never considered actually running a graphical app on
it since I could just git pull and run locally. So it's not that I haven't
been exposed to servers or haven't tried those commands or whatnot, it's
actually that I've attempted to use that functionality where appropriate
(got excited about it, and then disillusioned later), and really thought
about it carefully in order to optimize my setup and development costs, and
concluded that that technology is irrelevant to my workflow and not worth
the setup cost. If X were to be de-bloatified and large chunks of it
deprecated and deleted in order to make configuration simple, logical and
flexible, then that may change. Hmm.

Nick


On Mar 15, 2017 11:03 PM, <tfb at tfeb.org> wrote:

> On 15 Mar 2017, at 11:03, Nick Downing <downing.nick at gmail.com> wrote:
>
>
> I realized after writing that I was being slightly unfair since one valid
> use case that DOES work correctly is something like:
> ssh -X <some host> <command that uses X>
> This is occasionally handy, although the best use case I can think of is
> running a browser on some internet-facing machine so as to temporarily
> change your IP address
>
>
> I think you live in a strange alternative world, or (more likely) I do.
> My world is better however.  In my world I have a machine on my desk which
> runs an X server (which currently is talking to the physical screen, but
> will I hope soon be some kind of VNC so I can push this display to wherever
> I need it).  I also use a large number of machines which don't have any
> kind of screen and on which I may want to run graphical tools.
>
> In my experience this is what researchy type places with large-scale
> computing requirements have looked like essentially for ever, and it's the
> environment X was designed for (well, probably it was actually designed for
> student access at MIT but it very quickly moved into these environments).
> And it works *really* well, and anything which replaces it needs to work at
> least as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170316/0c54203c/attachment-0001.html>

[TUHS] X, Suntools, and the like

[tfb]

On 15 Mar 2017, at 13:12, Nick Downing <downing.nick at gmail.com> wrote:
> 
> Hmm well that DOES sound a bit patronizing

Sorry, it was not meant to be.  All I was trying to say was that X in fact works extremely well for the environments it is designed for (in which I now work), and for people who need to use graphical tools in those environments, and ripping out the network transparency (which seems to be what a bunch of people want to do) would be this geological step backwards in those environments: a GUI which is local to one machine is just a hugely limiting thing.  The whole reason I originally started using X was not that it was faster than Suntools (because it was catastrophically slower) but the network transparency.

I think the bloat argument is also one of those things which has been overtaken by events: X is bloated in the sense that Common Lisp is bloated: they were both a serious pain in the 1990s, but compared to anything with the word 'enterprise' in its name they now look like these svelte lightweight things which start in a tiny fraction of a second.

But I don't want to get into a fight about this and it's probably off-topic anyway (and again, sorry if I seemed patronising that was not my intention at all: probably should not send email with a cold).

--tim

[TUHS] X, Suntools, and the like

[Kurt H Maier]

On Thu, Mar 16, 2017 at 12:12:12AM +1100, Nick Downing wrote:
> Hmm well that DOES sound a bit patronizing, no offence taken though, I
> think it's more that I almost never use graphical tools, well at least not
> for any sysadmin or development type work. In the last day I ran chromium
> browser, xviewer (AKA eye of gnome), xreader (AKA evince), the gimp,
> libreoffice writer, and (currently) mplayer... these are all exclusively
> because I HAD to work with an inherently graphical resource, so there was
> no reasonable alternative but to run those programs. For anything else I
> would use the command line (occasionally I do DSP type stuff with
> matplotlib or gamey type stuff with pygame I guess). I can't honestly see a
> use case where I would ever want to run any of those programs on a server,


Your usage habits are not natural laws.  I'm a systems administrator
too, and I use X11 forwarding every single day, on dozens of different
programs.  

It's all very well for X11's networking tools to be useless for you.
That doesn't make them useless in general, and it doesn't mean the
functionality should be deleted.

khm

[TUHS] X, Suntools, and the like

[Arthur Krewat]

I just installed the latest version of Oracle's Forms/Reports 12c for a 
customer and it uses an X-windows installer.

Guess how I remote displayed it back to my VNC session that is running 
on a "jump server"?



On 3/15/2017 12:40 PM, Kurt H Maier wrote:
> Your usage habits are not natural laws. I'm a systems administrator
> too, and I use X11 forwarding every single day, on dozens of different
> programs.
>
> It's all very well for X11's networking tools to be useless for you.
> That doesn't make them useless in general, and it doesn't mean the
> functionality should be deleted.
>
> khm
>

[TUHS] X, Suntools, and the like

[Josh Good]

On 2017 Mar 15, 09:40, Kurt H Maier wrote:
> 
> Your usage habits are not natural laws.  I'm a systems administrator
> too, and I use X11 forwarding every single day, on dozens of different
> programs.  
> 
> It's all very well for X11's networking tools to be useless for you.
> That doesn't make them useless in general, and it doesn't mean the
> functionality should be deleted.

I don't use X11 forwarding because it works bad/slow over WAN links,
but RDP/ICA works just fine over the same. Also, in X11 forwarding any
network hiccup means the X11 app you are remoting just crashes, that
does not happen in the RDP/ICA world.

The real problem is that X11 predates the "GUI desktop metaphor". In X11
forwarding you remote bitmaps (or vectors or primitives or whatever)
which belong to an app, whereas in RDP you remote bitmaps (and only
bitmaps, and never anything more than bitmaps) which belong to a "full,
self-contained, GUI desktop".

In my opinion, X11 is not appropriate for desktops --it is designed more
for a scientific workstation kind of thing--, but currently there is
just no mature alternative in the Unix/Linux world (except for Mac OS X,
of course).

-- 
Josh Good

[TUHS] X, Suntools, and the like

[Robert Swierczek]

Here is my 2 cents to add: I think both approaches have their pro's
and con's.  This is what I would like to see in an ideal remote GUI
environment (I'll use the X11 convention for display server and
application client):

Mostly stateless as in VNC, little or no round-tripping of messages.

Client application contains a very small library (not a whole GUI
rendering library as needed by remote desk-topping).  Lighter than
Xlib.  Maybe on the order of curses.  Suitable for embedded devices.

Client should be tolerant of server going down and reconnecting (as in
VNC) because of a crash or migration.

User should see their application rendered in the servers widget scheme.

Server can be implemented natively or in a browser.

Some form of remote OpenGL supported (as in JS/WebGL)


On Thu, Mar 16, 2017 at 7:04 PM, Josh Good <pepe at naleco.com> wrote:
> On 2017 Mar 15, 09:40, Kurt H Maier wrote:
>>
>> Your usage habits are not natural laws.  I'm a systems administrator
>> too, and I use X11 forwarding every single day, on dozens of different
>> programs.
>>
>> It's all very well for X11's networking tools to be useless for you.
>> That doesn't make them useless in general, and it doesn't mean the
>> functionality should be deleted.
>
> I don't use X11 forwarding because it works bad/slow over WAN links,
> but RDP/ICA works just fine over the same. Also, in X11 forwarding any
> network hiccup means the X11 app you are remoting just crashes, that
> does not happen in the RDP/ICA world.
>
> The real problem is that X11 predates the "GUI desktop metaphor". In X11
> forwarding you remote bitmaps (or vectors or primitives or whatever)
> which belong to an app, whereas in RDP you remote bitmaps (and only
> bitmaps, and never anything more than bitmaps) which belong to a "full,
> self-contained, GUI desktop".
>
> In my opinion, X11 is not appropriate for desktops --it is designed more
> for a scientific workstation kind of thing--, but currently there is
> just no mature alternative in the Unix/Linux world (except for Mac OS X,
> of course).
>
> --
> Josh Good
>

[TUHS] X, Suntools, and the like

[Nick Downing]

I think the main difference being discussed here is 3 approaches to
remote logins:
(1) the user has a single login session, effectively a console, and
can connect to it/view it/interact with it from anywhere
(2) the user creates a new login session whenever they connect to the
server from a new station (or separately from the same station)
(3) the user has a local GUI console and login session, but windows
can be created in it that connect to remotely running apps
I would say that VNC, RDP are cases of type (1) whereas standard X
remoting (where a display manager runs on a diskless client, say) is
type (2) and "ssh -X" type X remoting is type (3).

Ignoring type (3) for the moment, I would say these approaches have
the following advantages/disadvantages:
- (1) is failsafe to dropped connections, etc, where (2) is not
- (1) is helpful for remote assistance since multiple parties can view
or interact with the desktop, where (2) is not
- (2) should be IMO more efficient since all context is maintained in
the terminal and the running applications can store stuff in offscreen
memory, invoke complex drawing primitives, etc, where (1) lends itself
more naturally to doing the drawing operations locally and then
sending bitmap "patches" to the changed areas of the screen (this is
what gives it the failsafe nature and also why apparently some people
see it running faster, because of bitmap compression)
- (2) is more powerful and scriptable IMO since a new session doesn't
hurt or depend on any other session, it seems more unix-like
considering how we use ssh and subshells and so on, basically
multiuser facilities being used single-user, whereas the type (1) IMO
seems limited in scalability and might also run into performance
problems with super high resolution displays, or lesser hardware that
can't compress bitmaps quickly.

Types 1 and 2 have a direct analogue to console terminal sessions: (1)
is where the user runs "screen" (or something like "nohup") whereas
(2) is where the user does an "ssh" to the server causing the sshd to
fork a new session.

Personally, I think the type (2) should be extended to handle the use
cases of type (1) since I believe it is more efficient for context to
be stored in the terminal and drawing operations carried out there. So
the ideal way I believe to handle these cases in a "new generation,
de-bloatified X" would be to provide an optional utility like "screen"
which caches any state which has been sent to the terminal, keeping
dirty flags etc to indicate whether such state has also been forwarded
onto the real terminal, and re-generate the protocol and all drawing
commands having sent any dependencies such as offscreen bitmaps first.
That way, you could have a type (2) system, but log into shared
sessions and/or re-log into dropped sessions, migrate sessions and so
on. But since the "screen" like program would be a separately
installed, optional package, it wouldn't impact on the simplified base
system unless you wanted this function.

cheers, Nick



On Fri, Mar 17, 2017 at 10:29 AM, Robert Swierczek
<rmswierczek at gmail.com> wrote:
> Here is my 2 cents to add: I think both approaches have their pro's
> and con's.  This is what I would like to see in an ideal remote GUI
> environment (I'll use the X11 convention for display server and
> application client):
>
> Mostly stateless as in VNC, little or no round-tripping of messages.
>
> Client application contains a very small library (not a whole GUI
> rendering library as needed by remote desk-topping).  Lighter than
> Xlib.  Maybe on the order of curses.  Suitable for embedded devices.
>
> Client should be tolerant of server going down and reconnecting (as in
> VNC) because of a crash or migration.
>
> User should see their application rendered in the servers widget scheme.
>
> Server can be implemented natively or in a browser.
>
> Some form of remote OpenGL supported (as in JS/WebGL)
>
>
> On Thu, Mar 16, 2017 at 7:04 PM, Josh Good <pepe at naleco.com> wrote:
>> On 2017 Mar 15, 09:40, Kurt H Maier wrote:
>>>
>>> Your usage habits are not natural laws.  I'm a systems administrator
>>> too, and I use X11 forwarding every single day, on dozens of different
>>> programs.
>>>
>>> It's all very well for X11's networking tools to be useless for you.
>>> That doesn't make them useless in general, and it doesn't mean the
>>> functionality should be deleted.
>>
>> I don't use X11 forwarding because it works bad/slow over WAN links,
>> but RDP/ICA works just fine over the same. Also, in X11 forwarding any
>> network hiccup means the X11 app you are remoting just crashes, that
>> does not happen in the RDP/ICA world.
>>
>> The real problem is that X11 predates the "GUI desktop metaphor". In X11
>> forwarding you remote bitmaps (or vectors or primitives or whatever)
>> which belong to an app, whereas in RDP you remote bitmaps (and only
>> bitmaps, and never anything more than bitmaps) which belong to a "full,
>> self-contained, GUI desktop".
>>
>> In my opinion, X11 is not appropriate for desktops --it is designed more
>> for a scientific workstation kind of thing--, but currently there is
>> just no mature alternative in the Unix/Linux world (except for Mac OS X,
>> of course).
>>
>> --
>> Josh Good
>>

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 16, 2017, at 4:04 PM, Josh Good <pepe at naleco.com> wrote:
> 
> The real problem is that X11 predates the "GUI desktop metaphor".

The Mac proclaimed the bitmap screen interface to the world, but X11 (and Sunview) pretty much invented the GUI desktop metaphor.

Into the mid-late 1990s I was managing shops that were using NCD X11 network terminals to run all sorts of GUI-based office applications (WYSIWIG word processing, spreadsheets, what have you) off UNIX hosts, well before the web was anything more than a curiosity.  And that pedigree dates back to the mid-1980s, where SunOS 3 helped define the concept of diskless clients.  Which isn't quite the same thing, but all of this was happening long before, say, Windows came along. And *well* before Windows had the concept of remote GUI access.  And that was *well* *well* before those Windows machines grokked the concept of multiple-users-on-independent-graphical-desktops remote access.

Circa 1994, a batch of 20 colour NCD X terminals talking to something like an SGI Onyx would kick the living daylights out of an equivalent set of 20 80486 Windows 3.11 desktops, on compute performance, for the GUI desktop environment they provided, and overall functionality and productivity.

--lyndon

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 16, 2017, at 4:29 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> for the GUI desktop environment they provided

I forgot to clarify: the Irix [56].X desktop environment.  Which was light years ahead of everyone else at the time.

[TUHS] X, Suntools, and the like

[arnold]

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> > The real problem is that X11 predates the "GUI desktop metaphor".
>
> The Mac proclaimed the bitmap screen interface to the world, but X11
> (and Sunview) pretty much invented the GUI desktop metaphor.

I thought all this really went back to the work at Xerox PARC. The Alto
and so on; we had a few at Georgia Tech in the mid '80s, before Suns.

Arnold

[TUHS] X, Suntools, and the like

[Ron Natalie]

 
>> The real problem is that X11 predates the "GUI desktop metaphor".

> The Mac proclaimed the bitmap screen interface to the world, but X11 (and
Sunview) pretty much invented the GUI desktop metaphor.

I think most people will attribute the desktop metaphor to Xerox.

[TUHS] X, Suntools, and the like

[Tim Bradshaw]

On 16 Mar 2017, at 23:29, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> The Mac proclaimed the bitmap screen interface to the world, but X11 (and Sunview) pretty much invented the GUI desktop metaphor.

As someone who used Xerox machines: no, they didn't.

[TUHS] X, Suntools, and the like

[Josh Good]

On 2017 Mar 17, 15:19, Tim Bradshaw wrote:
> On 16 Mar 2017, at 23:29, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> > 
> > The Mac proclaimed the bitmap screen interface to the world, but X11 (and Sunview) pretty much invented the GUI desktop metaphor.
> 
> As someone who used Xerox machines: no, they didn't.

I concur that the Xerox GUI was not a "desktop metaphor". The "GUI
desktop metaphor" embodies much more than a graphical canvas where to
move a pointer to click around. It needs the concept of "unified session"
and of "private session" to happen too.

On X11, you have a root window where different remote apps from
different remote systems and from different logged users can draw
things. That's not a "desktop metaphor", that's just a "blackboard
metaphor".

A "desktop metaphor" needs the "private unified session" concept to
happen too.

X was designed at MIT way before the "desktop metaphor", which probably
was invented (as such) in the McIntosh.

-- 
Josh Good

[TUHS] X, Suntools, and the like

[Ron Natalie]

We're waffling here.   The Star had more than just a mouse to move things
around.   It had icons representing the documents on the desktop, something
that the X window managers didn't get for quite some time (and don't really
still work right).    I'm not sure how you are defining the "desktop
metaphor" but Apple and Xerox had it long before X.    X planning didn't
start until after the Lisas were on the market so, it doesn't predate them
even in design.

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 17, 2017, at 1:30 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> I'm not sure how you are defining the "desktop
> metaphor" but Apple and Xerox had it long before X.

Yeah, I think we're all using different definitions of "desktop metaphor."

In my view, the early Macs (and Windows) were bitmap overlays on a single user OS.  To me, a "desktop" is a much more virtual abstraction of the user's runtime environment from the underlying OS.  I.e., if you can't have two distinct "users" concurrently running independent GUI environments on the same hardware, it's not a "desktop."  And I realize that's a very fuzzy definition.

Let me ask you this, Ron: how would you classify the Plan 9 terminal environment? :-)

--lyndon

[TUHS] X, Suntools, and the like

[Dan Cross]

On Fri, Mar 17, 2017 at 4:44 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> > On Mar 17, 2017, at 1:30 PM, Ron Natalie <ron at ronnatalie.com> wrote:
> >
> > I'm not sure how you are defining the "desktop
> > metaphor" but Apple and Xerox had it long before X.
>
> Yeah, I think we're all using different definitions of "desktop metaphor."
>
> In my view, the early Macs (and Windows) were bitmap overlays on a single
> user OS.  To me, a "desktop" is a much more virtual abstraction of the
> user's runtime environment from the underlying OS.  I.e., if you can't have
> two distinct "users" concurrently running independent GUI environments on
> the same hardware, it's not a "desktop."  And I realize that's a very fuzzy
> definition.
>

Fuzzy indeed. I'm not sure I understand what you mean at all. "Desktop"
tends to have a fairly consistent definition in the context of user
environments: It's the graphical component of the interactive facilities of
your computer/operating system combination, in the state of the user having
logged in (if appropriate) and being in the process of using the machine.
What does that have to do with the underlying operating system supporting
multiple users with independent desktops?

Let me ask you this, Ron: how would you classify the Plan 9 terminal
> environment? :-)


"Terminals" in the Plan 9 world are just that: terminals. They are the
physical computers users use to interact with the rest of the system (to a
first order approximation, Plan 9 can be thought of as being something like
a "timesharing system built from a network of computers"). Of note, they
tend to be single-user (modulo a few processes that may run as e.g. "none"
or whatever). They tend to present the user with a GUI that I would argue
is a "desktop": rio, acme, etc give one access to one's files and present
an interface for accessing the underlying system. While they tend not to
use the bitmapped graphical icons of other systems, I argue that limiting
the definition of desktops to being characterized by icons representing
objects such as files and applications while being present on the screen
seems like an implementation detail and unnecessarily limiting.
http://pub.gajendra.net/2016/05/plan9part1

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170317/3641ff82/attachment.html>

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 17, 2017, at 2:08 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> While they tend not to use the bitmapped graphical icons of other systems, I argue that limiting the definition of desktops to being characterized by icons representing objects such as files and applications while being present on the screen seems like an implementation detail and unnecessarily limiting.

But I didn't say a desktop requires iconic representations of objects.  I don't think the early Oberon implementations had them (but there are >20 years of memory loss between then and now).
Was Oberon a desktop?  Not to my mind.  It was a bitmapped interface vs a text-cell-based interface to a cooperating group of programs.  Conceptually I don't see any difference between Oberon and screen(1) in that regard.  Would you consider screen a 'desktop'?  And likewise, Oberon?  I'm not asking this rhetorically.  These concepts have fuzzy definitions for a lot of people, and I'm curious to see how they map out.

--lyndon

[TUHS] X, Suntools, and the like

[Dan Cross]

On Fri, Mar 17, 2017 at 6:50 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> > On Mar 17, 2017, at 2:08 PM, Dan Cross <crossd at gmail.com> wrote:
> > While they tend not to use the bitmapped graphical icons of other
> systems, I argue that limiting the definition of desktops to being
> characterized by icons representing objects such as files and applications
> while being present on the screen seems like an implementation detail and
> unnecessarily limiting.
>
> But I didn't say a desktop requires iconic representations of objects.  I
> don't think the early Oberon implementations had them (but there are >20
> years of memory loss between then and now).
>

Sorry; I thought that's what you were saying but I was wrong. But I confess
confusion. For instance, you mention Oberon here as not having graphical
icons but then in the next sentence two sentences it didn't meet your
definition of what a desktop is. So that sort of seems like a non sequitur.
What, then, is you definition? (And I'm not asking that to be combative;
I'm truly interested.)

Was Oberon a desktop?  Not to my mind.  It was a bitmapped interface vs a
> text-cell-based interface to a cooperating group of programs.  Conceptually
> I don't see any difference between Oberon and screen(1) in that regard.
> Would you consider screen a 'desktop'?  And likewise, Oberon?  I'm not
> asking this rhetorically.  These concepts have fuzzy definitions for a lot
> of people, and I'm curious to see how they map out.
>

I would definitely call Oberon's graphical interface a desktop (btw, the
graphical sorting demo was *cool*).

But I'm clearly using a different definition than you are.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170317/1f5c0672/attachment.html>

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 17, 2017, at 3:58 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> Sorry; I thought that's what you were saying but I was wrong. But I confess confusion. For instance, you mention Oberon here as not having graphical icons but then in the next sentence two sentences it didn't meet your definition of what a desktop is. So that sort of seems like a non sequitur. What, then, is you definition? (And I'm not asking that to be combative; I'm truly interested.)

Doh!  It just strikes me that the term I have been missing is "window manager."  Early Macs, Windows, Oberon, etc., were window managers.

> I would definitely call Oberon's graphical interface a desktop (btw, the graphical sorting demo was *cool*).

Oberon had many cool things!

> But I'm clearly using a different definition than you are.

Yes.  My fault.  Does "window manager" make more sense?  So "desktop" in my context means something much more dynamic than "window manager."  NeWS was the first example I can think of - an environment that could interpret and modify its environment in context.  I'm pretty sure that predated Windows and (what became) CORBA.

For me, Irix 5.2 on the Indy (circa 1993?) was the first true "desktop" environment I had hands on.

--lyndon

[TUHS] X, Suntools, and the like

[Lyndon Nerenberg]

> On Mar 17, 2017, at 4:17 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> For me, Irix 5.2 on the Indy (circa 1993?) was the first true "desktop" environment I had hands on.

And I mean this in the sense of the interactive/immersive environment.  I had been hacking on bitmapped/graphical interfaces going back to 1982 or so.

[TUHS] X, Suntools, and the like

[Steffen Nurpmeso]

Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
 |> On Mar 17, 2017, at 3:58 PM, Dan Cross <crossd at gmail.com> wrote:
 |Doh!  It just strikes me that the term I have been missing is "window \
 |manager."  Early Macs, Windows, Oberon, etc., were window managers.

Not to forget GEOS on Commodore 64, years before Windows.

--steffen

[TUHS] X, Suntools, and the like

[Andy Kosela]

On Saturday, March 18, 2017, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Lyndon Nerenberg <lyndon at orthanc.ca <javascript:;>> wrote:
>  |> On Mar 17, 2017, at 3:58 PM, Dan Cross <crossd at gmail.com
> <javascript:;>> wrote:
>  |Doh!  It just strikes me that the term I have been missing is "window \
>  |manager."  Early Macs, Windows, Oberon, etc., were window managers.
>
> Not to forget GEOS on Commodore 64, years before Windows.
>
>
Actually it was not "years before Windows".  Windows 1.0 was released in
1985, while GEOS for Commodore 64 in 1986.  If we are talking about early
"window managers" I think it is desirable to also mention early text mode
window managers like PathMinder which was released before Windows, in
1984.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170318/a5db2ef6/attachment.html>

[TUHS] X, Suntools, and the like

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

Andy Kosela <akosela at andykosela.com> wrote:
 |On Saturday, March 18, 2017, Steffen Nurpmeso <[1]steffen at sdaoden.eu[/1]> \
 |wrote:
 |Lyndon Nerenberg <[2]lyndon at orthanc.ca[/2]> wrote:
 | |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3]crossd at gmail.com[/3]> wrote:
 | |Doh!  It just strikes me that the term I have been missing is "window \
 | |manager."  Early Macs, Windows, Oberon, etc., were window managers.
 |
 |  [1] mailto:steffen at sdaoden.eu
 |  [2] javascript:;
 |  [3] javascript:;
 |
 |Not to forget GEOS on Commodore 64, years before Windows.
 |
 |Actually it was not "years before Windows".  Windows 1.0 was released in
 |
 |1985, while GEOS for Commodore 64 in 1986.  If we are talking about early

That is Wikipedia, but i bet i was not more than a quarter of
a year.  In fact i am a bit surprised, my parents divorced when
i was fourteen, and i really can remember myself using GEOS
proper.  And then, this was all in 8-bit, 64 KB, 1 MHz!  However
they did that!  With paint program, write program..

 |"window managers" I think it is desirable to also mention early text mode
 |
 |window managers like PathMinder which was released before Windows, in
 |
 |1984.

Ya, hm, i surely was a books rat at that time.

--steffen

[TUHS] X, Suntools, and the like

[Nick Downing]

There was a dude who came to our school in Melbourne Australia from the
United States, I would have been 13 so that makes it 1988. We had C64s and
this American dude loaded GEOS onto one and started using it for a bit of
stuff. We were flabbergasted as we didn't think the C64 was capable more
than just Logo or a few games, I think we might have had some terrible CBM
wordprocessor but GEOS kicked the pants off it. Sadly by this time we were
getting PC based and there was also a Mac 512k in head teacher's office
that you could use with permission. So it was not more than a novelty but I
still think that GEOS is an amazing bit of kit.
cheers Nick

On Mar 19, 2017 10:05 AM, "Steffen Nurpmeso" <steffen at sdaoden.eu> wrote:

> Andy Kosela <akosela at andykosela.com> wrote:
>  |On Saturday, March 18, 2017, Steffen Nurpmeso <[1]steffen at sdaoden.eu[/1]>
> \
>  |wrote:
>  |Lyndon Nerenberg <[2]lyndon at orthanc.ca[/2]> wrote:
>  | |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3]crossd at gmail.com[/3]>
> wrote:
>  | |Doh!  It just strikes me that the term I have been missing is "window \
>  | |manager."  Early Macs, Windows, Oberon, etc., were window managers.
>  |
>  |  [1] mailto:steffen at sdaoden.eu
>  |  [2] javascript:;
>  |  [3] javascript:;
>  |
>  |Not to forget GEOS on Commodore 64, years before Windows.
>  |
>  |Actually it was not "years before Windows".  Windows 1.0 was released in
>  |
>  |1985, while GEOS for Commodore 64 in 1986.  If we are talking about early
>
> That is Wikipedia, but i bet i was not more than a quarter of
> a year.  In fact i am a bit surprised, my parents divorced when
> i was fourteen, and i really can remember myself using GEOS
> proper.  And then, this was all in 8-bit, 64 KB, 1 MHz!  However
> they did that!  With paint program, write program..
>
>  |"window managers" I think it is desirable to also mention early text mode
>  |
>  |window managers like PathMinder which was released before Windows, in
>  |
>  |1984.
>
> Ya, hm, i surely was a books rat at that time.
>
> --steffen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/14eaad9a/attachment.html>

[TUHS] X, Suntools, and the like

[Jason Stevens]

It was a very constrained environment, but it's real power was in its WYSIWYG, and it's soft fonts.

I blame GEOS for making my c64 too productive as a kid as I so wanted one of those fancy 16bit machines.  I ended up buying used pc parts to amass my first PC, as my parents were dead set that you could do anything on the c64, and upgrading was pointless...

On March 19, 2017 7:32:39 AM GMT+08:00, Nick Downing <downing.nick at gmail.com> wrote:
>There was a dude who came to our school in Melbourne Australia from the
>United States, I would have been 13 so that makes it 1988. We had C64s
>and this American dude loaded GEOS onto one and started using it for a
>bit of stuff. We were flabbergasted as we didn't think the C64 was
>capable more than just Logo or a few games, I think we might have had
>some terrible CBM wordprocessor but GEOS kicked the pants off it. Sadly
>by this time we were getting PC based and there was also a Mac 512k in
>head teacher's office that you could use with permission. So it was not
>more than a novelty but I still think that GEOS is an amazing bit of
>kit.
>cheers Nick
>
>On Mar 19, 2017 10:05 AM, "Steffen Nurpmeso" < steffen at sdaoden.eu
><mailto:steffen at sdaoden.eu> > wrote:
>
>
>Andy Kosela < akosela at andykosela.com <mailto:akosela at andykosela.com> >
>wrote:
> |On Saturday, March 18, 2017, Steffen Nurpmeso <[1] steffen at sdaoden.eu
><mailto:steffen at sdaoden.eu> [/1]> \
> |wrote:
> |Lyndon Nerenberg <[2] lyndon at orthanc.ca <mailto:lyndon at orthanc.ca>
>[/2]> wrote:
> | |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3] crossd at gmail.com
><mailto:crossd at gmail.com> [/3]> wrote:
> | |Doh!  It just strikes me that the term I have been missing is
>"window \
> | |manager."  Early Macs, Windows, Oberon, etc., were window managers.
> |
> |  [1] mailto: steffen at sdaoden.eu <mailto:steffen at sdaoden.eu> 
> |  [2] javascript:;
> |  [3] javascript:;
> |
> |Not to forget GEOS on Commodore 64, years before Windows.
> |
> |Actually it was not "years before Windows".  Windows 1.0 was released
>in
> |
> |1985, while GEOS for Commodore 64 in 1986.  If we are talking about
>early
>
>That is Wikipedia, but i bet i was not more than a quarter of
>a year.  In fact i am a bit surprised, my parents divorced when
>i was fourteen, and i really can remember myself using GEOS
>proper.  And then, this was all in 8-bit, 64 KB, 1 MHz!  However
>they did that!  With paint program, write program..
>
> |"window managers" I think it is desirable to also mention early text
>mode
> |
> |window managers like PathMinder which was released before Windows, in
> |
> |1984.
>
>Ya, hm, i surely was a books rat at that time.
>
>--steffen

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170319/9b4243ab/attachment.html>

[TUHS] X, Suntools, and the like

[Larry McVoy]

On Fri, Mar 17, 2017 at 12:04:57AM +0100, Josh Good wrote:
> On 2017 Mar 15, 09:40, Kurt H Maier wrote:
> > 
> > Your usage habits are not natural laws.  I'm a systems administrator
> > too, and I use X11 forwarding every single day, on dozens of different
> > programs.  
> > 
> > It's all very well for X11's networking tools to be useless for you.
> > That doesn't make them useless in general, and it doesn't mean the
> > functionality should be deleted.
> 
> I don't use X11 forwarding because it works bad/slow over WAN links,
> but RDP/ICA works just fine over the same. Also, in X11 forwarding any
> network hiccup means the X11 app you are remoting just crashes, that
> does not happen in the RDP/ICA world.

I'm a huge X11 fan, use remote display all the time (I'm reading this
mail on slovax.mcvoy.com but I'm on a laptop so when mutt needs to
display a photo or a word doc or whatever, that's all remote X over
wifi, it "works" well enough that I use it a lot).

That said, whatever they did in RDP (which I'm guessing is Microsoft's
remote desktop protocol?) is awesome.  Way, way, way better than remote
display.  As Josh said, works quite well over a WAN.  I've used it to
get desktop access to windows machines in our build cluster and it works
great (I'm in the Santa Cruz mountains and my net connection is point to
point wifi to a tower, not the greatest).

> The real problem is that X11 predates the "GUI desktop metaphor". In X11
> forwarding you remote bitmaps (or vectors or primitives or whatever)
> which belong to an app, whereas in RDP you remote bitmaps (and only
> bitmaps, and never anything more than bitmaps) which belong to a "full,
> self-contained, GUI desktop".

Huh.  So is RDP better because it does bitmap to bitmap compression?

> In my opinion, X11 is not appropriate for desktops --it is designed more
> for a scientific workstation kind of thing--, but currently there is
> just no mature alternative in the Unix/Linux world (except for Mac OS X,
> of course).

I'd be stoked if X11 had an RDP extension or something.  I have no idea if
that makes sense but RDP is the shit.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] X, Suntools, and the like

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

Well there is xrdp
http://www.xrdp.org/

I’ve used this to ‘terminal server-ize’ our Oracle on Linux installs, as our DBA’s were used to Oracle on Windows (I know, I know, they also used to run it on Netware....) So the upshot is that on Windows you just fire up the rdp client, and connect into the Linux machine, and it’ll greet you with a login screen, login, and you have your desktop.  On the backend it’s the virtual X framebuffer, and xrdp does some vnc/mstsc type translation in the middle.

It’s great for sharing out desktops, or if you have those old ‘windows terminals’ that can at least talk to a MS Terminal server.  It’s incompatible with the citrix stuff, but it’s pretty cool.

Sent from Mail for Windows 10

From: Larry McVoy
Sent: Friday, 17 March 2017 8:14 AM
To: Josh Good
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] X, Suntools, and the like

On Fri, Mar 17, 2017 at 12:04:57AM +0100, Josh Good wrote:
> On 2017 Mar 15, 09:40, Kurt H Maier wrote:
> > 
> > Your usage habits are not natural laws.  I'm a systems administrator
> > too, and I use X11 forwarding every single day, on dozens of different
> > programs.  
> > 
> > It's all very well for X11's networking tools to be useless for you.
> > That doesn't make them useless in general, and it doesn't mean the
> > functionality should be deleted.
> 
> I don't use X11 forwarding because it works bad/slow over WAN links,
> but RDP/ICA works just fine over the same. Also, in X11 forwarding any
> network hiccup means the X11 app you are remoting just crashes, that
> does not happen in the RDP/ICA world.

I'm a huge X11 fan, use remote display all the time (I'm reading this
mail on slovax.mcvoy.com but I'm on a laptop so when mutt needs to
display a photo or a word doc or whatever, that's all remote X over
wifi, it "works" well enough that I use it a lot).

That said, whatever they did in RDP (which I'm guessing is Microsoft's
remote desktop protocol?) is awesome.  Way, way, way better than remote
display.  As Josh said, works quite well over a WAN.  I've used it to
get desktop access to windows machines in our build cluster and it works
great (I'm in the Santa Cruz mountains and my net connection is point to
point wifi to a tower, not the greatest).

> The real problem is that X11 predates the "GUI desktop metaphor". In X11
> forwarding you remote bitmaps (or vectors or primitives or whatever)
> which belong to an app, whereas in RDP you remote bitmaps (and only
> bitmaps, and never anything more than bitmaps) which belong to a "full,
> self-contained, GUI desktop".

Huh.  So is RDP better because it does bitmap to bitmap compression?

> In my opinion, X11 is not appropriate for desktops --it is designed more
> for a scientific workstation kind of thing--, but currently there is
> just no mature alternative in the Unix/Linux world (except for Mac OS X,
> of course).

I'd be stoked if X11 had an RDP extension or something.  I have no idea if
that makes sense but RDP is the shit.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170317/635f8a11/attachment-0001.html>

[TUHS] X, Suntools, and the like

[Michael Parson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

>On Fri, 17 Mar 2017, Larry McVoy wrote:

<snip>

>> I'd be stoked if X11 had an RDP extension or something.  I have no idea if
>> that makes sense but RDP is the shit.

On Fri, 17 Mar 2017, jsteve at superglobalmegacorp.com wrote:

> Well there is xrdp
> http://www.xrdp.org/

I'm a fan of this project.

> I’ve used this to ‘terminal server-ize’ our Oracle on Linux
> installs, as our DBA’s were used to Oracle on Windows (I know, I
> know, they also used to run it on Netware....) So the upshot is that
> on Windows you just fire up the rdp client, and connect into the Linux
> machine, and it’ll greet you with a login screen, login, and you
> have your desktop.  On the backend it’s the virtual X framebuffer,
> and xrdp does some vnc/mstsc type translation in the middle.

I'd describe xrdp as a VNC client that you connect to via RDP.

> It’s great for sharing out desktops, or if you have those old
> ‘windows terminals’ that can at least talk to a MS Terminal
> server.  It’s incompatible with the citrix stuff, but it’s pretty
> cool.

For whole-desktop sharing, yes, it's very nice.  Occasionally I try and
come up with ways to share a single app with it, to avoid the issue
where a network hiccup kills the app and you lose work.  Copious spare
time and all that...

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] X, Suntools, and the like

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |On Fri, Mar 17, 2017 at 12:04:57AM +0100, Josh Good wrote:
 |> On 2017 Mar 15, 09:40, Kurt H Maier wrote:
 |>> Your usage habits are not natural laws.  I'm a systems administrator
 |>> too, and I use X11 forwarding every single day, on dozens of different
 |>> programs.  
 ...
 |> I don't use X11 forwarding because it works bad/slow over WAN links,
 ...
 |I'm a huge X11 fan, use remote display all the time (I'm reading this
 |mail on slovax.mcvoy.com but I'm on a laptop so when mutt needs to
 |display a photo or a word doc or whatever, that's all remote X over
 |wifi, it "works" well enough that I use it a lot).

And it makes it possible to run browsers in a separate KVM into
which you log in with X11 forwarding enabled, for very insecure
things, and if your machine is strong enough.  Matthew Dillon of
DragonflyBSD posted[1] a nice recipe of separating privileges via
several different user accounts on the same machine (as in "ssh
dfw1 at localhost -n \"setenv DISPLAY :0.0; firefox\""), onto
which i added the additional KVM separation; a pain on my small
box with todays internet, however.  But possible.  And i am hoping
for improved virtual graphics, they are working on that!

--steffen

[TUHS] X, Suntools, and the like

[Steffen Nurpmeso]

  ...
 |things, and if your machine is strong enough.  Matthew Dillon of
 |DragonflyBSD posted[1] a nice recipe of separating privileges via
 |several different user accounts on the same machine (as in "ssh
 |dfw1 at localhost -n \"setenv DISPLAY :0.0; firefox\""), onto
  ...

Sorry, i had forgotten the link, it is

  [1] http://lists.dragonflybsd.org/pipermail/users/2015-August/291195.html

--steffen

[TUHS] X, Suntools, and the like

[Tony Finch]

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>
> And it makes it possible to run browsers in a separate KVM into
> which you log in with X11 forwarding enabled, for very insecure
> things, and if your machine is strong enough.

Nice! If you want a less-DIY more-packaged version of this idea, have a
look at https://www.qubes-os.org/intro/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Easterly or northeasterly 5 to 7, occasionally gale 8 in southeast.
Moderate or rough, occasionally very rough in southeast. Thundery showers.
Good, occasionally poor.

[TUHS] X, Suntools, and the like

[Steffen Nurpmeso]

Tony Finch <dot at dotat.at> wrote:
 |Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |> And it makes it possible to run browsers in a separate KVM into
 |> which you log in with X11 forwarding enabled, for very insecure
 |> things, and if your machine is strong enough.
 |
 |Nice! If you want a less-DIY more-packaged version of this idea, have a

Indeed there was also a nice thing on VDE2 which i searched but
could not find, so i posted the second best i remembered.. ^.^

 |look at https://www.qubes-os.org/intro/

This sent me on an interesting journey, reiterating all the Xen
/ KVM / etc. things, and which lead me to Librem, and i think
i will participate in one of the next batches of a Librem 13 --
i still haven't replaced my main machine that died more than one
and half a year ago.  I wanted to go Zenbook for quite some time
(ever since), but this indeed looks very nice, too.

Yes, the Xen hypervisor approach is more like the supercomputer
compartments that some of the members of this list know about.
But, you know, if possible i really want to avoid such a huge
installation as a base system, i would prefer a small NanoBSD, or
a minimal-installation Linux (because i am a loser and prefer
a very good performing base system with binary security update
support), say, nothing more than the kernel, iptables, iproute2,
VDE2, qemu (minimal), openssl and openssh.  And it needs X.
And i have found out that AlpineLinux offers a Xen Dom0
installation image: likely that it ships with Python preinstalled,
and Python and me is no-no-no.  (If at all avoidable, that is.)
KVM/Qemu you can drive with a few shell scripts.

You know, i am so undecided.  If someone would come around with
a modern mobile phone with a quad-processor and say 8GB RAM (free)
and a "Lapdock-station" that has a good keyboard and monitor, and
the possibility to boot a "normal" operating system "directly via
KVM/xy" (when plugging in), then i really would be satisfied.  I/O
performance is what counts for me -- and here SSD and a virtual
machine with dedicated partition is much better than anything
i ever had before! --, CPU power i miss only when compiling, but
having four or even eight truly parallel threads would surely make
this acceptable -- i am used to two-core 1.4 GHz Core 2...
Yet of course noone will mix the markets of phones and laptops.

And what do you mean by DIY?  Isn't it a pretty common abstraction
to have several users with different privileges?  It must be
doable, of course -- if i recall correctly, switching users on
a Mac freezes anything of the current user, for example, and the
graphical firewall tool either allows ssh or not, so that the
scenario shown wouldn't even work (when using the Mac-GUI-provided
ways of doing things).

--steffen

[TUHS] X, Suntools, and the like

[Arthur Krewat]

On 3/16/2017 8:13 PM, Larry McVoy wrote:
> I'd be stoked if X11 had an RDP extension or something. I have no idea if
> that makes sense but RDP is the shit.

Check out VNC - you run a "server" on the remote side, and the VNC 
client on the client side. The advantage is that everything you run 
stays running on the remote side.

I use this setup all the time for a security-conscious Fortune 100 
company I consult for, as well as personally.

Now, of course, it can be argued that VNC has it's security problems, 
some of which stem from X11 itself. For example, I can't tell you how 
many people do an "xhost +" either manually or (to my horror) in 
.vnc/xstartup - But that's X11's problem not VNC.

Add "ssh -X" to all of this.

[TUHS] X, Suntools, and the like

[Larry McVoy]

On Fri, Mar 17, 2017 at 10:39:21AM -0400, Arthur Krewat wrote:
> 
> On 3/16/2017 8:13 PM, Larry McVoy wrote:
> >I'd be stoked if X11 had an RDP extension or something. I have no idea if
> >that makes sense but RDP is the shit.
> 
> Check out VNC - you run a "server" on the remote side, and the VNC client on
> the client side. The advantage is that everything you run stays running on
> the remote side.

Unless VNC has evolved it's just nowhere near as snappy as RDP.  Can anyone
speak to that?

[TUHS] X, Suntools, and the like

[Tim Bradshaw]

On 17 Mar 2017, at 16:21, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Unless VNC has evolved it's just nowhere near as snappy as RDP.  Can anyone
> speak to that?

There are variants of the protocol and some of the commercial clients & servers were significantly faster than the original one, but my impression was that RDP was better.

VNC doesn't do anything like the same job as X of course: any screen-or-window-image-shipping protocol like that would need an enormous amount of extra baggage on the side of it to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170317/164a8894/attachment.html>

[TUHS] X, Suntools, and the like

[Steve Nickolas]

On Fri, 17 Mar 2017, Larry McVoy wrote:

> On Fri, Mar 17, 2017 at 10:39:21AM -0400, Arthur Krewat wrote:
>>
>> On 3/16/2017 8:13 PM, Larry McVoy wrote:
>>> I'd be stoked if X11 had an RDP extension or something. I have no idea if
>>> that makes sense but RDP is the shit.
>>
>> Check out VNC - you run a "server" on the remote side, and the VNC client on
>> the client side. The advantage is that everything you run stays running on
>> the remote side.
>
> Unless VNC has evolved it's just nowhere near as snappy as RDP.  Can anyone
> speak to that?
>

I use X redirection to run some apps, but it can get dog slow with 
anything involving rich bitmaps.

I use VNC to remote into my Linux boxen and my neighbor's PC for quick 
tech assistance.  Again, terrible choice for anything involving bitmaps, 
but it's a bit better for apps that use non-system fonts.

I use RDP for accessing my friend's encoding rig (Win10).  Still dog-slow 
for bitmap stuff, but for anything else it's fast as hell even when the 
latency of the Internet is taken into consideration.

For stuff that may require working with graphical previews (such as 
trimming videos for remote encoding) I use NX.

-uso.

[TUHS] X, Suntools, and the like

[Robert Brockway]

On Fri, 17 Mar 2017, Josh Good wrote:

> The real problem is that X11 predates the "GUI desktop metaphor". In X11
> forwarding you remote bitmaps (or vectors or primitives or whatever)
> which belong to an app, whereas in RDP you remote bitmaps (and only
> bitmaps, and never anything more than bitmaps) which belong to a "full,
> self-contained, GUI desktop".

Personally I've always strongly preferred that remote apps display on the 
same desktop as local apps.  This offers seemless integration, especially 
if the various servers share /home.

Putting remote apps in a box always struck me as klunky.  Different people 
prefer each of these approaches and there is no need to force everyone in 
to one solution.  Losing the ability to remote display individual apps 
would be a great leap backwards for me, and for lots of others.

FWIW I believe RDP does support per app remote display.

Cheers,

Rob

[TUHS] X, Suntools, and the like

[Josh Good]

On 2017 Mar 19, 16:11, Robert Brockway wrote:
> On Fri, 17 Mar 2017, Josh Good wrote:
> 
> >The real problem is that X11 predates the "GUI desktop metaphor". In X11
> >forwarding you remote bitmaps (or vectors or primitives or whatever)
> >which belong to an app, whereas in RDP you remote bitmaps (and only
> >bitmaps, and never anything more than bitmaps) which belong to a "full,
> >self-contained, GUI desktop".
> 
> Personally I've always strongly preferred that remote apps display on the 
> same desktop as local apps.  This offers seemless integration, especially 
> if the various servers share /home.
> 
> Putting remote apps in a box always struck me as klunky.

Remoting single GUI apps can be useful in a scientific workstation and
similar settings (for example, managing some turbine in a power plant,
etc.). But remoting full, integrated desktop environments is more useful
for clerical office work and for remote administration of GUI-based
operating systems, or for remote administration of some workflow which
involves several GUI applications in a tool-chain kind of workflow.

IMHO.

-- 
Josh Good

[TUHS] X, Suntools, and the like

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Well, I’m not even going to get into the deficiencies of Microsoft, I spent the last twenty years of my life beating head against those.   DLL hell did not go away with the common runtime environment, the solution was a giant kludge.   The one thing I have to say about the common runtime framework is it makes so much sense it’s amazing that Microsoft came up with it…want to link programs together…just put them in the same directory.   Very UNIX like in philosophy.   Don’t get me started about GDI+…makes a lot of sense but it is inordinately slower than the legacy system and the font processing is a joke, nowhere near as complete as the original.

 

Anyhow MS Windows sucks as badly as you blame X.   You have to reach deep into it’s guts to get performance out of it as well.   Also, while you think all the world’s a workstation, a lot of industry is going the other way and you find out had bad Windows sucks at remote application  running when any performance is required.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170315/a1e6ac2a/attachment.html>