15 Mar
2017
15 Mar
'17
11:03 a.m.
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(a)tfeb.org> wrote:
On 15 Mar 2017, at 01:13, Nick Downing <downing.nick(a)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
15 Mar
15 Mar
12:03 p.m.
New subject: X, Suntools, and the like
On 15 Mar 2017, at 11:03, Nick Downing <downing.nick(a)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.
1:12 p.m.
New subject: X, Suntools, and the like
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(a)tfeb.org> wrote:
On 15 Mar 2017, at 11:03, Nick Downing
<downing.nick(a)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.
2:37 p.m.
New subject: X, Suntools, and the like
On 15 Mar 2017, at 13:12, Nick Downing <downing.nick(a)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
4:40 p.m.
New subject: X, Suntools, and the like
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
4:52 p.m.
New subject: X, Suntools, and the like
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
16 Mar
16 Mar
11:04 p.m.
New subject: X, Suntools, and the like
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
11:29 p.m.
New subject: X, Suntools, and the like
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(a)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
17 Mar
17 Mar
1:15 a.m.
New subject: X, Suntools, and the like
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(a)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(a)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
>
16 Mar
16 Mar
11:29 p.m.
New subject: X, Suntools, and the like
On Mar 16, 2017, at 4:04 PM, Josh Good
<pepe(a)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
17 Mar
17 Mar
12:05 a.m.
New subject: X, Suntools, and the like
On Mar 16, 2017, at 4:29 PM, Lyndon Nerenberg
<lyndon(a)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.
5:55 a.m.
New subject: X, Suntools, and the like
Lyndon Nerenberg <lyndon(a)orthanc.ca> wrote:
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
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. 
12:56 p.m.
New subject: X, Suntools, and the like
> 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.
3:19 p.m.
New subject: X, Suntools, and the like
On 16 Mar 2017, at 23:29, Lyndon Nerenberg <lyndon(a)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.
8:17 p.m.
New subject: X, Suntools, and the like
On 2017 Mar 17, 15:19, Tim Bradshaw wrote:
On 16 Mar 2017, at 23:29, Lyndon Nerenberg
<lyndon(a)orthanc.ca> wrote:
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
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.
8:30 p.m.
New subject: X, Suntools, and the like
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.
8:44 p.m.
New subject: X, Suntools, and the like
On Mar 17, 2017, at 1:30 PM, Ron Natalie
<ron(a)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
9:08 p.m.
New subject: X, Suntools, and the like
On Fri, Mar 17, 2017 at 4:44 PM, Lyndon Nerenberg <lyndon(a)orthanc.ca> wrote:
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
On Mar 17,
2017, at 1:30 PM, Ron Natalie <ron(a)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.
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.
10:50 p.m.
New subject: X, Suntools, and the like
On Mar 17, 2017, at 2:08 PM, Dan Cross
<crossd(a)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
10:58 p.m.
New subject: X, Suntools, and the like
On Fri, Mar 17, 2017 at 6:50 PM, Lyndon Nerenberg <lyndon(a)orthanc.ca> 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.)
Was Oberon a desktop? Not to my mind. It was a bitmapped interface vs a
On Mar 17,
2017, at 2:08 PM, Dan Cross <crossd(a)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).
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.
11:17 p.m.
New subject: X, Suntools, and the like
On Mar 17, 2017, at 3:58 PM, Dan Cross
<crossd(a)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
11:22 p.m.
New subject: X, Suntools, and the like
On Mar 17, 2017, at 4:17 PM, Lyndon Nerenberg
<lyndon(a)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.
18 Mar
18 Mar
3:45 p.m.
New subject: X, Suntools, and the like
Lyndon Nerenberg <lyndon(a)orthanc.ca> wrote:
|> On Mar 17, 2017, at 3:58 PM, Dan Cross <crossd(a)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
4:59 p.m.
New subject: X, Suntools, and the like
On Saturday, March 18, 2017, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
Lyndon Nerenberg <lyndon(a)orthanc.ca
<javascript:;>> wrote:
|> On Mar 17, 2017, at 3:58 PM, Dan Cross <crossd(a)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
11:05 p.m.
New subject: X, Suntools, and the like
Andy Kosela <akosela(a)andykosela.com> wrote:
|On Saturday, March 18, 2017, Steffen Nurpmeso <[1]steffen(a)sdaoden.eu[/1]> \
|wrote:
|Lyndon Nerenberg <[2]lyndon(a)orthanc.ca[/2]> wrote:
| |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3]crossd(a)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@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
11:32 p.m.
New subject: X, Suntools, and the like
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(a)sdaoden.eu> wrote:
Andy Kosela <akosela(a)andykosela.com> wrote:
|On Saturday, March 18, 2017, Steffen Nurpmeso <[1]steffen(a)sdaoden.eu[/1]>
\
|wrote:
|Lyndon Nerenberg <[2]lyndon(a)orthanc.ca[/2]> wrote:
| |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3]crossd(a)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@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
19 Mar
19 Mar
7:20 a.m.
New subject: X, Suntools, and the like
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(a)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(a)sdaoden.eu
<mailto:steffen@sdaoden.eu> > wrote:
Andy Kosela < akosela(a)andykosela.com <mailto:akosela@andykosela.com> >
wrote:
|On Saturday, March 18, 2017, Steffen Nurpmeso <[1] steffen(a)sdaoden.eu
<mailto:steffen@sdaoden.eu> [/1]> \
|wrote:
|Lyndon Nerenberg <[2] lyndon(a)orthanc.ca <mailto:lyndon@orthanc.ca>
[/2]> wrote:
| |> On Mar 17, 2017, at 3:58 PM, Dan Cross <[3] crossd(a)gmail.com
<mailto:crossd@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(a)sdaoden.eu <mailto:steffen@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.
17 Mar
17 Mar
12:13 a.m.
New subject: 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:
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).
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".
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
3:16 a.m.
New subject: X, Suntools, and the like
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(a)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:
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).
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".
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
23 Mar
23 Mar
7:16 p.m.
New subject: X, Suntools, and the like
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(a)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
17 Mar
17 Mar
12:39 p.m.
New subject: X, Suntools, and the like
Larry McVoy <lm(a)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
12:45 p.m.
New subject: X, Suntools, and the like
...
|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
4:49 p.m.
New subject: X, Suntools, and the like
Steffen Nurpmeso <steffen(a)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(a)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.
18 Mar
18 Mar
3:43 p.m.
New subject: X, Suntools, and the like
Tony Finch <dot(a)dotat.at> wrote:
|Steffen Nurpmeso <steffen(a)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
17 Mar
17 Mar
2:39 p.m.
New subject: X, Suntools, and the like
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.
4:21 p.m.
New subject: X, Suntools, and the like
On Fri, Mar 17, 2017 at 10:39:21AM -0400, Arthur Krewat wrote:
On 3/16/2017 8:13 PM, Larry McVoy wrote:
Unless VNC has evolved it's just nowhere near as snappy as RDP. Can anyone
speak to that?
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.
4:29 p.m.
New subject: X, Suntools, and the like
On 17 Mar 2017, at 16:21, Larry McVoy <lm(a)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.
5:42 p.m.
New subject: X, Suntools, and the like
On Fri, 17 Mar 2017, Larry McVoy wrote:
On Fri, Mar 17, 2017 at 10:39:21AM -0400, Arthur
Krewat wrote:
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.
On 3/16/2017 8:13 PM, Larry McVoy wrote:
Unless VNC has evolved it's just nowhere near as snappy as RDP. Can anyone
speak to that?
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. 
9:39 p.m.
New subject: X->VNC->RDP experience [was Re: X, Suntools, and the like
It has been almost 20 years since I seriously used X remotely. Even then it
was mostly xterms. Almost everything I do in Linux is from bash. I run X
locally mostly if I'm trying to figure out how a new release of Fedora has
changed configuration files -- I run the settings apps to see what they do
to the files. What follows is a bit off-topic from TUHS perspective.
About 1999 I began to need to administer a bunch of Windows servers, mostly
on a local network, sometimes across town, sometimes farther away. I
gravitated to using VNC for Windows and soon used it occasionally for Linux
and, eventually, OS X. My primary desktop environment became Windows, using
PuTTY for ssh.
Back then, my remote access was mostly across POTS (56k) and BRI (128k)
connections.
Since then, I've tried most of the Windows clients and servers. For my
purposes UltraVNC (uvnc.com) is much superior to the others. The client is
robust across remote connections using ssh tunnels. The server was the first
to work reasonably on Vista and tends to keep up with Microsoft better than
the others, in my experience. Tiger (Tight) was my second favorite(s), and I
still use them occasionally, mostly on older machines that I setup before
using Ultra.
The biggest VNC drawbacks from my perspective have been
- security (alleviated by ssh tunneling)
- lack of macOS versions as robust as UltraVNC on Windows
- Windows with RDP interfering with VNC server
With recent macOS, Apple includes a pretty good basic VNC client, “Screen
Sharing”, and a very good VNC server as “Apple Remote Desktop”. Screen
Sharing doesn’t feel as responsive as the better clients on Windows, e.g.,
TightVNC and UltraVNC, and omits refresh options and other useful features.
(Reportedly, there are plans for UltraVNC for macOS. There is a Java version
of TightVNC that will run on macOS, but overall doesn’t seem as responsive
as Screen Sharing. I just discovered while writing this that there is a
TigerVNC dmg, so I plan to try that.)
When I upgraded an XP Pro machine to Vista Pro, I discovered that Vista Pro
wouldn't allow the UltraVNC server to run. That forced me to get acquainted
with RDP, and I was pleasantly surprised.
I knew that RDP had existed, but also knew that RDP was based on ITU-T
T.128. With all the complexity associated with T.120, I had stayed away from
RDP. (20+ years ago I wrote a chapter in Mainstream Videoconferencing,
http://notes.technologists.com/notes/2008/02/14/mainstream-videoconferencin…,
trying to make T.120 more accessible than the ITU-T docs. The T.128 doc is
at http://www.itu.int/rec/T-REC-T.128-200806-I/en.)
T.120 work started when the principals assumed that videoconferencing over
POTS (H.324) would become prominent, and T.120 was intended to work on POTS
connections. So it is not surprising to think of RDP as "snappy" on cascaded
WiFi connections.
I use RDP quite a bit to access Windows machines that don't allow/interfere
with UltraVNC server. (Just now I tried to get UltraVNC server to work on a
machine running Windows 10 Pro, and failed.)
Besides that Windows VNC interference, the main disadvantage of RDP in my
experience is lack of (freely available?) servers for Windows Home, macOS
and Linux.
When my primary Windows laptop failed, I decided to try a MacBook Pro.
Mostly I've liked it and have liked the RDP client. Some people disparage
the (Microsoft supplied) RDP client as inferior to the Windows client. The
specifics of their complaints don't matter on my MacBook, but I can imagine
they would be bothersome on an iMac or other larger screen.
Charlie
-----Original Message-----
From: Larry McVoy
Sent: Friday, March 17, 2017 11:21 AM
To: Arthur Krewat
Cc: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] X, Suntools, and the like
On Fri, Mar 17, 2017 at 10:39:21AM -0400, Arthur Krewat wrote:
On 3/16/2017 8:13 PM, Larry McVoy wrote:
Unless VNC has evolved it's just nowhere near as snappy as RDP. Can anyone
speak to that?
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. 
19 Mar
19 Mar
6:11 a.m.
New subject: X, Suntools, and the like
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
11:56 a.m.
New subject: X, Suntools, and the like
On 2017 Mar 19, 16:11, Robert Brockway wrote:
On Fri, 17 Mar 2017, Josh Good wrote:
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
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.
2597
days inactive
2605
days old
40 comments
21 participants
participants (21)
-
Andy Kosela -
arnold＠skeeve.com -
Arthur Krewat -
Charles H Sauer -
Dan Cross -
Jason Stevens -
Josh Good -
jsteve＠superglobalmegacorp.com
-
Kurt H Maier -
Larry McVoy -
Lyndon Nerenberg -
Michael Parson -
Nick Downing -
Robert Brockway -
Robert Swierczek -
Ron Natalie -
Steffen Nurpmeso -
Steve Nickolas -
tfb＠tfeb.org -
Tim Bradshaw
-
Tony Finch