Are command line interfaces for an OS obsolete?

[Solar]

For one, note that while XenOS made resource "cost" a big part of his argument, I actually prefer the text interface because of its versatility and expressiveness. So whether I run a CLI in raw text mode or in a xterm doesn't matter to me (that much).

We might still be just talking about different things here but...

Well, the local CLI and the SSH CLI are separate, a server could be running headless and without any memory use for graphics (including the LFB), and still allow SSH.

Only if it has a CLI. A GUI-only system could possibly tunnel its GUI through a SSH connection, but SSH in the original meaning -- "secure shell", logging in remotely and execute commands -- requires a CLI.

However I was talking about the RPi not needing GUI/CLI at all for remote control. You need something for remote control (assuming you want to control it remotely), but neither GUI/CLI is a requirement. So the remote control wouldn't happen over SSH.

I don't get what you're saying here.

Anyway. You might want to take a step back here and reconsider what the thread is / was about. You want to create a GUI-only system. You've heard some criticism from us, but it's your system, go right ahead. We don't say it cannot be done, we just doubt that it will be that well-received.

The subject of the thread, however, was if command line interfaces are obsolete, in general. Not if you could create a system without them, but if a clear case could be made that we shouldn't even bother with them anymore.

And I think this discussion has shown that, while your ideas might result in a usable OS, there's still demand for CLI's today, just not from you.

[Schol-R-LEA]

For one, note that while XenOS made resource "cost" a big part of his argument, I actually prefer the text interface because of its versatility and expressiveness. So whether I run a CLI in raw text mode or in a xterm doesn't matter to me (that much).

Sorry if I am sounding like a broken record on this, but did you look at my post regarding Oberon, and do you have any comments regarding it? Would you find this sort of text interface a reasonable compromise? Do you think the more fluid approach towards both handling CLI commands (i.e., the fact that it isn't a strictly line at a time, serial interaction mode, but allows commands to be edited and repeated more easily than, say, BASH history and autocompletions) and UI development (no specialist tools for menu and icon creation, always having a text option for more complex commands without having to use xterm) of any value? Could you see a lightweight way to apply this to remote operation, via (e.g.) a curses-based interface with a selection of hotkeys in place of mouse actions, and would it be of use to you?

I am guessing that vim has shell-invocation extensions which do much the same thing - that is to say, you already have something like this, so an interface that is nothing but this isn't necessary for you personally - but I am curious to hear what you have to say about the idea in general.

[Korona]

Running gnome-terminal on your workstation while being ssh'd into a server means that you're still using a CLI or TUI, not a GUI. (I doubt anyone would claim that non-graphical terminals are superior to graphical terminals, except for emergency shells. We're all running a terminal emulator on a graphical compositor while using the CLI.)

[xenos]

I think most people are running GUI on their laptop (or at least in graphics mode), so much if not all of the cost is already paid.

The point is that you "pay the cost" on one machine, namely the one that runs the GUI. But then you don't need a GUI on every machine. You can connect to IoT devices which have no GUI. For the IoT devices it clearly matters to have just a TUI, while on the other device it does not matter much whether one uses a GUI and something like X terminal to connect.

For one, note that while XenOS made resource "cost" a big part of his argument, I actually prefer the text interface because of its versatility and expressiveness. So whether I run a CLI in raw text mode or in a xterm doesn't matter to me (that much).

In fact, versatility and expressiveness are also big arguments for me. So also on those machines where I do have a graphical desktop, run my browser, watch videos etc. I prefer many non-GUI tools because they actually made my work easier and faster. (I am grateful to a visiting PhD student, who was using these tools when I was still using KDE and many GUI tools, and I was impressed by how he could complete many tasks more easily.) The most important changes for me:

• Use XMonad as window manager. While this is not a CLI or TUI application in the strict sense, it uses (mostly) keyboard commands - switching desktops, moving windows between desktops, changing focus, moving between monitors, changing desktop layout (it arranges and resizes windows automatically - no mouse fiddling required), launching programs.
• Use VIM. I was using mostly KWrite before (and Kile for writing LaTeX - for that I use now "vim-latex"). It clearly took some time to learn keyboard commands, but VIM has great tutorials. And they really speed things up. Delete a sentence? das. Indent current paragraph? =ip. Delete everything from cursor to end of the line and start typing something new? C. Define a new command, e.g., F9 to find the next occurrence of "\emph{", find the matching "}", delete both of these? :nnoremap <F9> /\\emph{<CR>%xNdf{. Also it has highly flexible syntax highlighting, some of them I wrote myself (but I have done that also for KWriite before).
• Use VIM plugins to speedup workflows further. I already mentioned "vim-latex", which is one of the most useful ones for me, since I use LaTeX a lot, in particular for work, and it defines a ton of helpful keyboard shortcuts and macros that make my workflow easier. Typing "EEQ" to start inserting an equation, while already having my hands at the keyboard and typing, is just much more convenient than using the mouse and open a menu as in Kile. Another big speedup is YouCompleteMe, with semantic completion engines supporting most of the languages I use (LaTeX, C++, Python - to name just a few) and one can add more as Python plugins if desired (the LaTeX one I customized). The newest versions even support smart Unicode completion. Plus, it even recognizes and marks syntax errors. Then there is "tagbar", which can display a (textual) sub-window with stuff like section headings in LaTeX or functions and classes in C++, so essentially like an IDE would do, but even in text mode. Even more IDE features - if I invoke a LaTeX or C++ compiler through VIM and there are errors, it shows them in a sub-window and allows me to jump to the error locations, also opening files if necessary. (It "understands" the error locations from the compiler error messages.)
• There's many other things I rather do on the command line than in a GUI. Listing (sorting, formatting and wildcard filtering) of directory contents? ls is my friend. Tools like grep, sed and wget / curl are inevitable for me. VLC player comes with a "curses" TUI, which I prefer, because I don't need a separate window for stuff like the playlist, but can have it as a tab or pane in a tmux'ed terminal. Even for browsing I sometimes prefer lynx because it works faster and gives me more overview if I can just read the website text without any images around. The reason why I still use GUI browsers is rather because there are websites which unnecessarily use graphical-only UI for "aesthetics" without actual benefit.

As for VIM, when working on a graphical desktop, I actually prefer GVIM over VIM in a terminal - but with all GUI elements such as menu, scroll bars, buttons etc. disabled, so that essentially it is again a pure text window with no graphical elements whatsoever. The reason is that it supports things like an "I-beam" cursor in insert mode and more text formatting options to use for syntax highlighting (such as italics or a colored wavy line under the text, which most people know from spell checking, but which I also use for syntax errors and warnings - in different colors). Still I prefer a "lightweight" (Athena) GUI option that, e.g., uses bitmap fonts (still Unicode, of course).

Sorry if I am sounding like a broken record on this, but did you look at my post regarding Oberon, and do you have any comments regarding it?

I'm not the one you asked, but I looked at some deeper information on Oberon and I kind of like the approach. The user experience would probably have the same benefits from CLI / TUI I mentioned above, simply because it is integrated into the system by design. Probably it can be achieved at a lower than OS level as well, just having lots of "terminal-editor-hybrid windows" in which applications run. In fact, the VIM integrated terminal is something like that. Of course it would still be a graphical system from the point of view of resource usage, but for those use cases where that is anyway needed (web browsing, videos) this is no drawback, of course. Also I liked the browser on the screenshot you posted.

[Schol-R-LEA]

Probably it can be achieved at a lower than OS level as well, just having lots of "terminal-editor-hybrid windows" in which applications run. In fact, the VIM integrated terminal is something like that.

A fair number of Gnu Emacs users do precisely this, using the editor as their main (or even sole) UI. Though it is only 'lightweight' compared to a desktop environment such as KDE or Gnome.

For my own part, I use XFCE4 as my GUI for both my desktop and laptop, and use Chrome for web browsing, because w3-mode isn't really a complete web browser by any stretch of the imagination. While I own an RPi3, I've not used it much recently, nor have I been doing much actual programming in general, because Depression is one hell of a drug.

[Solar]

...did you look at my post regarding Oberon, and do you have any comments regarding it?

I skimmed over it the first time, and it didn't click for me. Seeing your request, I read it again in detail... and it still didn't click for me. I don't quite see what it "does" for the user experience. It's an interesting technical approach, but I don't see which problem it solves.

[eekee]

Oh, I have to respond to this thread, advertising myself as I do on my wiki user page as "the offspring of James T. Klik and Lino Commando!" The one feature of my OS which I will implement regardless of other changes is a 2-pane display, with a command line in the bottom pane. The top pane would be drawn by the current foreground app, being text or graphics as needed. It's an attempt to fuse the strengths of both GUI and CLI.

Hi,

I think Solar made a perfect argument for CLI. It's always better to use command line remotely than messing around with X11 forwards or RDP.

I keep flip-flopping over this issue. In favour of remote-GUI, I have had good experiences with remote-X, back when security needs were lighter. Plan 9 does it more simply and with a better-designed security model. Against it are the constraints it places on data flow from program to GPU, and perhaps resulting complexity and difficulty of achieving high performance.

Not even Ken Thompson, who used an ed-like editor to the end of his career, saw a need to put a text-only remote interface on Plan 9. Of course, he probably had less driver trouble than we do on PCs.

I intend to go the remote-GUI route, but with such a heavy command-line presense, it's inevitable that many tasks will be accomplishable using only the command line.

And also you can work a LOT faster in CLI than in any GUI, simply because you have a command history and shortcuts, plus with one command you can do something at once that would require dozens of clicks on different windows. Also it's easy to put commands in a batch file, while I haven't seen any good solution for batching GUI operations (anyone used MacOSX Automator? Just terrible, and that's the best tool I've seen so far.) So I'm sure too CLI will never be obsoleted.

Me too! In fact, I'm thinking of the GUI portion of my interface as visualization and auxiliary control. While I'd hate to be without the GUI part, the CLI is technically dominant.

Just an interesting fact, even Windows is moving forward CLI from GUI more and more with every release. Just think about how much CLI support Win Vista had, and how much more Win 7 had (think about the additions of netshell, powershell, diskpart etc. etc. etc.). And now they have rewritten the terminal application for Win 10. I really doubt they would do that if there wasn't a real need and pressure from the users.

I'm very much enjoying the mouse-based copy-paste of Win10 terminal! I can't understand why open sourcers never made the same innovation to get away from the insanity of selection=clipboard.

Cheers,
bzt

Cheers!

There was an undertone of "one or the other" to the discussion, which got us sidetracked. A good OS, IMHO (and I think I did make this point above), would integrate CLI and GUI. In a perfect world, there wouldn't be GIMP on the one hand and imagemagick on the other -- the two would be merely two different ways to use one and the same application. Same for elinks and firefox, mutt and thunderbird, and so on.

I have to agree here!

As for "obsolete"... I consider it a significant win that I can use text-only connections to remote machines this way. I can remote-access systems in my home network from my smartphone.

What about RDP or Teamviewer? Nothing CLI specific here.

Ayup! I know sysadmins who were still happy with remote X a couple of years ago. One of them found Wayland's bad design hurt him, Wayland apps suffer input synchronization problems over remote X, but that's just a measure of how stupid "progress" can get in the POSIX/FOSS space.

On the other hand, I know another sysadmin who prefers to use an ed-like command-line editor and shell-script mail client on his phone. His argument is these programs were designed for poor keyboards, slow networks... and something else I can't remember.

I think he has something of a point. I can't get on with ed or sam -d, (the command-line editor my friend uses on his phone,) but I did quite a lot with a Forth block editor on my tablet a few weeks ago. The difference is the block editor displays the block after each change. It's much like the next point. Actually, the editor and key/command-controlled apps of colorForth were what inspired my 2-pane concept.

Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time. If I have the data available on my Windows machine, I might just dump it in Excel and filter until I have the data set I want.

This is exactly my problem with Unix tools. I worshipped Unix and the Unix command line years ago, but I just cannot do without iterative filtering. At best, I send simply filtered output to a file, then figure out another command to filter the file contents, then maybe repeat again, but it's cumbersome when you can't edit in-place. It's better in text editors where you can run successive commands on the current text. Acme perhaps makes it easiest, of the text editors I've tried, but Excel is probably better again because it's designed for this use. Certainly my apps will be designed for it.

Text interfaces depend on much less OS infrastructure.

Sure, less OS infra, but equal amount of infra nonetheless, mostly firmware.

Pretty-much. Maybe we don't have to care about the complexity, but it's there.

If you're using a ANSI-standard serial terminal or emulator, then you'll also run into bugs caused by poor serialization. Also compatibility, very few terminal emulators have ANSI-compliant keyboard emulation. The rest do vt220 and call it "ansi". There have been other compatibility problems.

Fixed-pitch text does make some programming simpler, but it's a hack.

I would like to say there's one really good thing about text interfaces in terminal emulators: all text can be copied. It's nasty when GUIs disallow text selection. Unfortunately, the way in which programs format text for display often makes a mess of the copied text.

This matter of the program formatting text for the terminal also makes problems for smaller terminals, such as phones. It's the same as text files where arbitrary spaces are replaced with new-line codes, just so they can be dumped to a terminal without proper drivers! I mean that, even though it's Unix-hate. The feature-greed and corporate competition which ruined RTF and complexified HTML don't mean the lowest common denominator is good.

I'm not sure how much this has to do with looks, but rather utility. TUI just doesn't make efficient use of the screen, with GUI you can have easily a lot more info visible at any given time.

What? WHAT? Dude, just WHAT do you... OHHHHHH I get it! You're comfortable with menus. I am very much not! The elements blur into each other, finding the right sub-menu is a headache, and opening sub-menus is a special kind of torture! Well, that's all a bit of an exaggeration these days, I seem to have healed somewhat in the last 20 years. Still, I view menus as a last resort, and an interface which depends on them alone as poor. Thus, I am dependent on keybindings which take time to learn just like CLI, and, getting to the point, toolbars which take abominably large amounts of screen space!

To be honest about menus, there's no getting away from them really. Even a list of file names is a sort of menu, no matter how it's displayed. I just have to deal with it, but I prefer to minimize such dealings as far as is practical.

What about RDP or Teamviewer? Nothing CLI specific here.

Both are far more intensive of resources, particularly network bandwidth, than a simple SSH session. For remote access to a server, nothing beats a CLI session over SSH. And to secure RDP adequately you are going to have to tunnel it through SSH anyway, so you are just adding another unnecessary layer.

Okay, this I can't argue with. I've known lots of sysadmins with bandwidth issues. Some of them even like the sam text editor because it's easier on the network than vi over ssh. It takes whole commands from 'samterm', can work on many large files at once...

Early in idea development, I wanted all apps in my OS to be like sam, having separate terminal and back-end portions, but not like sam in that the backend can stay running when the terminal exits. I tend to forget about it these days, but maybe I can bring it back. It could make the design really alien, but I'm kind-of doing that anyway.

Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time...

Well that could be it, then -- your experience, or lack of experience, with people who actually "grok" the other side of the argument. Personally, I'll whip up quite complex RegEx's without hestiation, simply because I am using them in my prefered environment (Vim) all the time. Having to go through Excel (of all things...) would aggravate me to no end. Kind of a "speed bump".

I used various regexp languages (Unix, Vi, grep, ...) in Unix for 15 years, then another 10 years in Plan 9 with its single regexp syntax for everything, and I still can't write regexps well enough to be comfortable. I'm fairly good, but I often have to debug my regexps, which is Not Fun outside of an editor like I described above. It's especially necessary for the editor to undo well.

Interestingly, on Windows I can't remember when is the last time I touched cmd.exe, months ago.

cmd.exe is so braindead that it's effectively useless anyway.

Indeed. I've been using 9pm under Windows, a port of some Plan 9 userspace. It's very old, and the port of the shell was never even finished, so it's really quite bad, but it's still more powerful and polished than cmd!

(Kind of like trying to explain alternative drive access mechanisms. People know drive letters -- which suck -- and single root systems -- which also suck. And think the argument is about making a system more like Windows, or more like Linux, when in actual fact it's about making it better than either of them.)

YES! But is it heretical to say environment variables make either one suck less?

% d=`{pwd}
% cd $s
% mv xyzzy* $d

And outputting the very earliest error messages (before LFB) and then halting as text, when something goes horribly wrong at first stages, doesn't count as CLI/TUI.

But the CLI / TUI is all what you have at that point to recover the system. If you've never seen text mode until that point (as in Windows Recovery Console, for example), and your system is geared so certain things basically require a GUI to operate on, you're stumped.

Um... I don't yet know anything about Windows Recovery Console, but I wasn't stumped when trying to get an older machine to work with a 4k monitor the other day. RDP was no use, so I just started a VNC server.

OTOH, the fact that RDP was no use does illustrate a serious problem with GUI: E.v.e.r.y s.i.n.g.l.e i.t.t.y b.i.t.t.y f.e.a.t.u.r.e has to be provided for separately and must take up space in the UI, (even if only in a menu,) so "rarely used" features get dropped. In this case, there was no facility to open the controls for the hardware screen from the remote GUI.


Apologies for not reading the whole thread, I have to get away from the computer.

Stray thought I didn't have room for: If not for Steve Jobs' ego and power in '82, we all might have been using well-integrated CLI & GUI all along. Look up the Canon Cat, which is what the Mac was meant to be before Jobs parasitized it to fix his own failed project. Graphical programs never got developed for it, but it had the hardware and firmware for them.

Oh and the last post's about Oberon. Acme was inspired by it. I have used Acme very extensively, and Oberon briefly. Acme is extraordinarily powerful in very little code, a huge revelation after the clumsiness of VIM and Emacs. I haven't used Oberon enough to really evaluate it, but I suspect it's less powerful due to the presence of non-text areas. Acme has more places to type commands. Both use the mouse to complement commands, you can launch arbitrary commands, scripts, or one-liners with the mouse. From experience, I have to say this is a huge improvement over just the command line!

[linguofreak]

I'm very much enjoying the mouse-based copy-paste of Win10 terminal! I can't understand why open sourcers never made the same innovation to get away from the insanity of selection=clipboard.

I haven't tried out Windows Terminal yet, but I've never made heavy use of selection=clipboard in Linux. Mostly I've used Gnome/Mate Terminal, where text copying is pretty much the same as with any other GUI application for the past couple decades, highlight text and hit Shift-Ctrl-C to copy, hit Shift-Ctrl-V to paste. The only difference is the addition of the shift key to the shortcut to disambiguate it from pre-existing console shortcuts.

And in any case, the selection=paste mechanism was introduced, IIRC, by X, so it's a GUI thing, just from before modern GUI conventions had stabilized.

Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time. If I have the data available on my Windows machine, I might just dump it in Excel and filter until I have the data set I want.

This is exactly my problem with Unix tools. I worshipped Unix and the Unix command line years ago, but I just cannot do without iterative filtering. At best, I send simply filtered output to a file, then figure out another command to filter the file contents, then maybe repeat again, but it's cumbersome when you can't edit in-place. It's better in text editors where you can run successive commands on the current text. Acme perhaps makes it easiest, of the text editors I've tried, but Excel is probably better again because it's designed for this use. Certainly my apps will be designed for it.

I just tend to do something like this:

Code: Select all

$ filter | less
#Inspect output in less
#q to exit less
$ filter | less #brought up with up arrow through command history, not actually typed
$ filter | filter2 | less #edit previous command line to add filter 2
#Inspect output in less
#Lather, rinse, repeat

I would like to say there's one really good thing about text interfaces in terminal emulators: all text can be copied. It's nasty when GUIs disallow text selection. Unfortunately, the way in which programs format text for display often makes a mess of the copied text.

Sometimes it's not so much an issue of "selection disallowed" as "the text is presented as an image", but yes, yuck.

What? WHAT? Dude, just WHAT do you... OHHHHHH I get it! You're comfortable with menus. I am very much not! The elements blur into each other, finding the right sub-menu is a headache, and opening sub-menus is a special kind of torture! Well, that's all a bit of an exaggeration these days, I seem to have healed somewhat in the last 20 years. Still, I view menus as a last resort, and an interface which depends on them alone as poor. Thus, I am dependent on keybindings which take time to learn just like CLI, and, getting to the point, toolbars which take abominably large amounts of screen space!

I actually have more of the issues you describe now than I did before. Thanks to Apple, UI design is now performed primarily by the fashion industry, not the computing industry (so to speak), and what all the cool kids are wearing this year is flat interfaces with much more hue and saturation contrast than brightness contrast, and absolutely no drop shadows. It *looks* cool, but trying to disambiguate foreground from background is a pain in the Equus Africanus.

[eekee]

Mostly I've used Gnome/Mate Terminal, where text copying is pretty much the same as with any other GUI application for the past couple decades, highlight text and hit Shift-Ctrl-C to copy, hit Shift-Ctrl-V to paste. The only difference is the addition of the shift key to the shortcut to disambiguate it from pre-existing console shortcuts.

Aaaa! Mutating common keybindings like that is toxic! It's much worse than coming up with another binding entirely, because you mess with everybody's muscle memory. If you're okay with it, you never used copy/paste enough to develop muscle memory with the standard keybindings. Or, maybe you learned them both together. What do you think a heavy GUI user, perhaps a writer, is going to feel when trying to use something without the keybindings he's used to? I can tell you: literal actual physical pain!

This shift-ctrl-x/c/v nonsense is a big part of the reason I was so disappointed and pained when Linux desktop morons started slavishly immitating Windows in the late 90s. In the 80s and 90s, just-about everyone but Microsoft had a sensible set of keybindings which did not conflict with traditional text-editing keybindings*, but Microsoft (in their infinite wisdom) had to make them conflict. Then, the "We're going to conquor Microsoft" idiots, with their complete lack of ability to produce innovations for themselves, had to imitate it! They had to immitate the ONE stupid system which had built-in conflicts with the traditional command-line. Such huge amounts of WHYYYYYYYYYYYYY!

*: They're not exactly emacs keybindings, (thank you Gnu,) some of them predate emacs, and emacs doesn't even support a couple of the most common and useful ones.

It's an old rant now, but still relevant as I illustrated with the heavy GUI user. The overarching problem of WinGnoKDE conflicting with traditional bindings can still bite. I sort-of stopped caring when I got sick of Linux around 2009, but then my usage changed and I had to start caring again. I was happy doing 99% of my work with Plan 9's traditional bindings + mouse-based selection and mouse-button chording, but when I found myself missing a social game which ran on Linux with WinGnoKDE bindings, I soon ran into trouble again. It was bad because Microsoft (in their infinite wisdom) made the traditional delete-word keybinding *close the window* instead!

Perhaps it's because these traditional bindings developed on mainframes with serial terminals and Microsoft were never mainframe developers, but Apple weren't either, and they got it right. It's very nice to be able to use the system standard cmd-c/v in Apple terminal. (But I still miss being able to cut text on the command line. Plan 9's good that way.)

I'll probably support Windows keybindings in my OS's command line, seeing as I'm using WIndows these days. It shouldn't be hard to make it selectable, actually. If I'm not mistaken, it's easiest to make keybindings selectable en-masse in a command-line system where the programs don't try to take over the keybindings themselves or implement new ones. Gnu readline seems to get it. Gforth doesn't, I'll be happy when I'm finished with it. (And what is it with readline and all the other programs failing to recognize the alt/meta key in the form in which every terminal defaults to sending it? Gforth on Android even fails to support alt from its own terminal. Staggering!)



On another note entirely, one of my Win10 machines booted into safe mode the other day. (I think it was a Win10 machine, it *might* have been my one Win7 computer.) I'd forgotten about safe mode. It got me thinking, if safe mode was good enough, why did MS implement Windows Recovery Shell? (Or whatever they call it.) Thinking about it, I would be impressed by a system which could be completely fixed from the GUI, but I suspect it would still require textual input, and some tasks would still be better scripted. Command-line tools have huge natural advantages here.

[bzt]

I can't understand why open sourcers never made the same innovation to get away from the insanity of selection=clipboard.

Maybe old habits die hard, but I would hate not having two independent clipboards. Ctrl+C and Ctrl+V is one, and select+middle click another one. I'm using both for nearly 20 years now, and I love that I can use them simultaneously!

Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time.

Present! Using regular expressions is like riding a bicycle. You only learn that properly once, and after that it comes to you naturally. I would never replace grep/cut/sort/unique/etc. with a complex, iterative filter GUI form or an Excel sheet.

If you're using a ANSI-standard serial terminal or emulator, then you'll also run into bugs caused by poor serialization. Also compatibility, very few terminal emulators have ANSI-compliant keyboard emulation. The rest do vt220 and call it "ansi". There have been other compatibility problems.

That's sadly true. I hate that termcap mess. That's why my OS is not ANSI compliant, but VT220 compliant. If your terminal can't send VT220 keycodes, throw it out, and use a proper terminal emulator! I mean, even PuTTY has configurable keycodes.

About GUI over SSH, I was just thinking. Xlib uses a tokenized protocol, which could be simply and effectively sent over the network. RDP is a different kind of beast, it compresses the entire screen buffer and sends that, frame by frame producing huge network traffic. How about Wayland? As far as I know it only operates on shared buffers (shared between the application and the compositor). How would you send that to a remote GUI? RDP-style? Is it even possible to set a remote display for Wayland?

Cheers,
bzt

[Korona]

Perhaps surprisingly, protocols that compress bitmaps are faster than those that send drawing operations, due to the fact that they require less synchronization. At least, that applies to the existing protocols. RDP and VNC can be made pretty fast while X over ssh only works over low latency connections.

[bzt]

Perhaps surprisingly, protocols that compress bitmaps are faster than those that send drawing operations, due to the fact that they require less synchronization. At least, that applies to the existing protocols. RDP and VNC can be made pretty fast while X over ssh only works over low latency connections.

Yes, that's seem surprising because my every day experience is the opposite. X11 is MUCH MUCH faster, more responsive and requires magnitudes less bandwidth even if not used directly but through an SSH tunnel. Working with VNC consoles across half world on the other hand are pain in the a$$, while using an SSH console just works as if it were a local console So my experience is (in order of effectiveness): 1. SSH, 2. X11, 3. X11 over SSH tunnel, 4. VNC.

However this does not answer my original question: does Wayland have a remote display option, and if so, how is it implemented, is it token or bitmap based?

Cheers,
bzt

[Korona]

Have you tried RDP? I also had more success with RDP than with VNC. (But of course, plain ssh is orders of magnitude better; luckily I do not even need RDP anymore as I do not need to log in into Windows servers anymore.)

Wayland delegates the responsibility to draw windows to the client (instead of the server as in X11 w/o extensions). Hence, non-bitmap based remote desktops would be much harder to accomplish. I could imagine a remotely-rendered Vulkan surface but it certainly requires lots of engineering work.

[bzt]

Have you tried RDP? I also had more success with RDP than with VNC. (But of course, plain ssh is orders of magnitude better; luckily I do not even need RDP anymore as I do not need to log in into Windows servers anymore.)

Nope, not really, only VNC for VGA consoles on enterprise grade kvm-switches as I was a UNIX guy in my entire life. I never got my hands dirty with using a primarily desktop OS as a server I don't think a GUI only OS (like the Windows NT Server) makes a good server just because the marketing department labelled it as "server". Btw, out of curiousity, I've checked out rdesktop once under Linux and I've tried to forget it as soon as I could (it wasn't a throughout test and I definitely have no maintenance experience with it either).

Wayland delegates the responsibility to draw windows to the client (instead of the server as in X11 w/o extensions). Hence, non-bitmap based remote desktops would be much harder to accomplish. I could imagine a remotely-rendered Vulkan surface but it certainly requires lots of engineering work.

I see, thank you very much for the info! Is it still possible to forward the entire compositor's screen through a VNC server? I guess it is, I see no reason why it shouldn't be.

Cheers,
bzt

[Seahorse]

CLI is not dead. CLI and GUI are complimentary.