|
|
Subscribe / Log in / New account

Hacking the planet with Notcurses

Author Nick Black has written an extensive book on the creation of textual user interfaces using the notcurses library; it's available under the Apache license [PDF]. "Many people asked how such a thing was useful. My usual response was that numerous devices don’t present a bitmap interface, that X11 GUIs run remotely over SSH are effectively unusable, that plenty of machines don’t have a GUI environment installed, that there are obvious applications for large outdoor displays, and that Sixel isn’t well-supported across different terminal emulators. It seems impossible in an age of gigatransistor graphics cards, but the text environment still presents perceivably less latency than most GUI toolkits."

to post comments

Hacking the planet with Notcurses

Posted Mar 19, 2020 22:20 UTC (Thu) by ballombe (subscriber, #9523) [Link] (10 responses)

For the readers that would like to use the mouse under the Linux console, I can offer some consolation.

Hacking the planet with Notcurses

Posted Mar 20, 2020 9:55 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (9 responses)

Si is it like gpm?

Hacking the planet with Notcurses

Posted Mar 20, 2020 11:10 UTC (Fri) by ballombe (subscriber, #9523) [Link] (8 responses)

Yes, except it uses the libinput library which is used by X.org and Wayland, so it supports the same devices.

Hacking the planet with Notcurses

Posted Mar 20, 2020 18:21 UTC (Fri) by fman (subscriber, #121579) [Link] (5 responses)

One would think the mouse should be handled via the terminal. As in vim, htop etc. Sounds pretty strange with gpm..

Hacking the planet with Notcurses

Posted Mar 20, 2020 23:12 UTC (Fri) by zlynx (guest, #2285) [Link] (4 responses)

The terminal code inside the kernel is messy enough already. It's kind of like having a web server in there.

I forget the project name, but a while ago there was a project to rip out the kernel console support and replace it with a user-space app. I guess it hasn't gone anywhere.

Hacking the planet with Notcurses

Posted Mar 21, 2020 0:21 UTC (Sat) by ballombe (subscriber, #9523) [Link]

At least it would be nice if copy-pasting could be done without using the TIOCLINUX ioctl;
To start with, /dev/vcsa* should be mmapable.

Hacking the planet with Notcurses

Posted Mar 21, 2020 1:46 UTC (Sat) by flussence (guest, #85566) [Link] (2 responses)

That would be kmscon. Its upstream is stone dead, and back when it was alive it felt a bit flaky. It was nice to play around with truetype fonts and full-colour on a VT for a while though.

There's kconfig options to rip out the built-in terminal emulation from the framebuffer system entirely (which weren't actually around when kmscon was a thing - I'm not sure what prompted them), but then you're reliant on wayland/X/sshd/serial working 100% of the time. Personally I have trouble keeping them above five-nines…

Hacking the planet with Notcurses

Posted Mar 21, 2020 12:05 UTC (Sat) by dezgeg (subscriber, #92243) [Link]

ChromeOS has frecon, not sure how reusable it is in general distros...

Hacking the planet with Notcurses

Posted Mar 22, 2020 13:37 UTC (Sun) by HelloWorld (guest, #56129) [Link]

There was also systemd-consoled. However it was ripped out of systemd when the original developer stopped working on it and nobody else stopped up.

Hacking the planet with Notcurses

Posted Apr 1, 2020 12:08 UTC (Wed) by mgedmin (subscriber, #34497) [Link] (1 responses)

AFAIU consolation only implements copy/paste, but doesn't provide any API for terminal applications, unlike gpm (or xterm).

Hacking the planet with Notcurses

Posted Apr 2, 2020 21:21 UTC (Thu) by jwilk (subscriber, #63328) [Link]

Mouse reporting was added in 0.0.7: https://bugs.debian.org/923181
Beware there's apparently no way to opt out from this "feature".
I switched back to gpm, which just works.

questionable licence combination

Posted Mar 19, 2020 22:39 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (3 responses)

The book starts with a picture under “CCASA4” licence. This is probably CC-BY-SA 4.0, but the “SA” in it kinda means copyleft.

This generally means that the book, as derived work, has to be under CC-BY-SA 4.0 or later. If any provisions of the Apache 2 licence are incompatible with that (the NOTICE file one might be a candidate, but I didn’t analyse this in detail), the result is illegal and nōn-distributable…

Also wondering what the “notcurses” library is. Turns out it’s been written by the author of the book, and it isn’t even packaged in Debian. Perhaps this is an attempt at getting publicity.

On the flip side, kudos for bringing more eyes on terminal programs.

questionable licence combination

Posted Mar 20, 2020 2:11 UTC (Fri) by IanKelling (subscriber, #89418) [Link]

Derivative is not a given, and this is fine if the authors allow it, like dual licensing.

questionable licence combination

Posted Mar 20, 2020 4:33 UTC (Fri) by dvdeug (guest, #10998) [Link] (1 responses)

There was a court case that ruled that a CC-BY-SA photo used as the cover image for a non-free atlas did not make the atlas a derived work, and Creative Commons approved of the decision -- https://creativecommonsusa.org/index.php/2016/04/15/court... . Hence this use of the photo would be fine.

questionable licence combination

Posted Mar 20, 2020 19:32 UTC (Fri) by mirabilos (subscriber, #84359) [Link]

Thanks for the information and the hyperlink. That is a surprisingly sensible court decision.

Hacking the planet with Notcurses

Posted Mar 19, 2020 23:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

I love text-based graphical interfaces. I've stayed for many years on Windows because of FAR Manager ( https://www.farmanager.com/screenshots.php?l=en ). I've tried to do something like it on Linux but got severely disappointed. It just didn't work at all.

First, input in text mode is screwed up. For example, FAR Manager changes the bottom bar when I press "shift", "ctrl" or "alt". This is not possible in Unix terminals, as they don't transmit modifier key states, only key presses. There's also no way to distinguish between key up/key down events. You need to go out of your way to get special events for the numpad keys (FAR used "+" key on numpad for file selection, for example). Mouse is completely fucked up. And so on.

But this is all tolerable. You can make do with emacs-style key chords in the worst case. Whatever.

The main problem for me turned out to be the fact that terminal in Unix is a fucked up mess. It started its life as a way to interface with literal line printers and barely grew since then. The protocol is entirely unidirectional (from application to the terminal emulator) as a result, and there is no way to get feedback from the terminal emulator back to the application.

This turned out to be lethal for a fluent text-based shell like FAR. If I tried to launch arbitrary programs from inside of it, it was way too easy for them to mess up the terminal state completely. I found that even trying to reset everything doesn't always work (resize events and mouse also complicated things).

I then tried to go with the terminal emulator within terminal emulator approach that screen/tmux use (I actually used tmux as my display layer). This actually worked fairly well, creating a robust layer that allowed me to at least guarantee that I can guarantee that my program's internal state corresponds to what is actually on the screen. Unfortunately, this approach fundamentally messes up the scrollback in terminal which I consider to be critical. It also was a bit bandwidth-heavy (for 2006).

I've been on a lookout for projects that try to improve text UI experience on Linux, but nobody seems to be working on the really fundamental terminal emulation layer.

As of now, I'm supporting iTerm2 on Patreon as it seems to be the only project that tries to do something about the basic terminal emulation layer. Its direct tmux support is not perfect, but it's probably something that can be evolved into a next-gen terminal emulation experience.

Hacking the planet with Notcurses

Posted Mar 20, 2020 10:53 UTC (Fri) by josh (subscriber, #17465) [Link] (3 responses)

libvterm is probably your best bet for terminal-within-a-terminal emulation, including scrollback.

Hacking the planet with Notcurses

Posted Mar 20, 2020 15:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Does it integrate with the native scrollback buffer or does it use internal storage?

Hacking the planet with Notcurses

Posted Mar 20, 2020 21:34 UTC (Fri) by josh (subscriber, #17465) [Link] (1 responses)

It has its own internal scrollback buffer, which you'd then be able to scroll back through in your terminal-within-a-terminal.

Hacking the planet with Notcurses

Posted Mar 21, 2020 0:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

It has a lot of drawbacks, like losing it if you disconnect from the host.

Hacking the planet with Notcurses

Posted Mar 25, 2020 11:41 UTC (Wed) by Seegras (guest, #20463) [Link]

I'm heavily using Midnight Commander, on urxvt. Yes, it's not possible to change the bottom bar depending on modifier, but everything else, mouse, resize +-key and other numpad-keys and so on work nicely. it's using the SLang-library which is responsible for most of it.

Hacking the planet with Notcurses

Posted Mar 20, 2020 0:23 UTC (Fri) by gb (subscriber, #58328) [Link]

I was wondering why there are so few comments? And went through the link.

And hour later I would like to thank lwn for link.

"Some people, possibly aliens, don’t favor a dark terminal background."

This book really nice. Made me recall time at university when I wrote tetris in 1:30 minutes in ncurses.

Now I am installing mc everywhere and a lot of people at work are having a lot of fun seeing it's blue background in demos I am making. It is actually good =)

Tk-like toolkit for Curses

Posted Mar 20, 2020 0:39 UTC (Fri) by dskoll (subscriber, #1630) [Link] (5 responses)

One of my favourite toolkits for making GUIs is Tcl/Tk; I'm really sad that it didn't catch on. Tk might look dated, but it so incredibly easy to whip up interfaces that resize sensibly and just work incredibly well.

There's a Tk-like kit called Ck, which unfortunately is old and pretty much unmaintained, but it lets you whip up text-based interfaces almost as easily as Tk lets you make graphical ones. I did a project using Ck and loved it.

Tk-like toolkit for Curses

Posted Mar 20, 2020 9:55 UTC (Fri) by gus3 (guest, #61103) [Link]

I use Tcl/Tk for my little personal projects. My favorite is a GUI for sending texts via SMS. Typing texts on my computer keyboard, instead of tapping a touchscreen? I'm still faster than 99% of the kids out there, esp. with punctuation and odd capitalizations! ;-)

Tk-like toolkit for Curses

Posted Mar 20, 2020 10:45 UTC (Fri) by eru (subscriber, #2753) [Link]

tkdiff which is written in it is still my go-to GUI tool for comparing files. I find it amazing how much functionality fits in a single 13060 line script. Even the speed and memory usage are reasonable by GUI program standards.

Tk-like toolkit for Curses

Posted Mar 20, 2020 13:08 UTC (Fri) by morganr (guest, #43385) [Link] (2 responses)

The claim that "X11 GUIs run remotely over SSH are effectively unusable" doesn't seem right given that I'm using a Tk application (git gui) doing just that over a VPN while working remotely. There's a noticeable (1s?) lag when opening windows compared to rendering on the same machine, but that doesn't make it unusable for me at least.

Tk-like toolkit for Curses

Posted Mar 20, 2020 23:16 UTC (Fri) by zlynx (guest, #2285) [Link]

But Tk is not like modern GUI toolkits. Tk uses X11 as X11 was originally intended to be used.

The result is not necessarily pretty but it does work pretty well.

Tk-like toolkit for Curses

Posted Mar 23, 2020 9:13 UTC (Mon) by eru (subscriber, #2753) [Link]

Some X11 applications work quite nicely over even a slower line, some others are totally unusable because they keep redrawing everything constantly. The latter kind can be used remotely with VNC, which transmits only the actually changed pieces of the display.

Hacking the planet with Notcurses

Posted Mar 20, 2020 5:44 UTC (Fri) by re:fi.64 (subscriber, #132628) [Link] (1 responses)

For anyone else curious as to what notcurses actually is: https://github.com/dankamongmen/notcurses

> What it is: a library facilitating complex TUIs on modern terminal emulators, supporting vivid colors and Unicode to the maximum degree possible. Many tasks delegated to Curses can be achieved using notcurses (and vice versa).

> What it is not: a source-compatible X/Open Curses implementation, nor a replacement for NCURSES on existing systems, nor a widely-ported and -tested bedrock of free software, nor a battle-proven, veteran library.

TL;DR it's a really nice TUI library with a better API than ncurses while supporting more modern terminal features like mouse support.

Hacking the planet with Notcurses

Posted Mar 21, 2020 3:03 UTC (Sat) by flussence (guest, #85566) [Link]

In the project's readme there's a link to the history of ncurses' ownership, which is worth reading in full (if you've got an hour or two to spare): https://invisible-island.net/ncurses/ncurses-license.html

Hacking the planet with Notcurses

Posted Mar 20, 2020 7:33 UTC (Fri) by darwi (subscriber, #131202) [Link]

Well, one of the benefits of a text environment is minimizing distractions. If text applications overdo it with colors and animations, maybe I'll just use the GUI app instead.

Hacking the planet with Notcurses

Posted Mar 20, 2020 13:08 UTC (Fri) by Moarc (guest, #137864) [Link] (30 responses)

>X11 GUIs run remotely over SSH are effectively unusable
Okay, I had to register for this one. This claim is thoroughly disputable: many people have succesfully used remote Xorg apps via SSH for decades now, and their usage model is one of the most important arguments against how Wayland does things (apart from "Unix philosophy"); RDP and VNC give a way more painful user experience than tunneled X11, though Mr Black is quite right that text-based interfaces (especially with mosh) are way more responsive than any remote GUI.

I do not mean to say that I myself oppose Wayland, but even for my unserious desktop use cases remote X11 was always a huge advantage of Linux over Windows, which has only bitmap-based solutions, and the secure ones are beyond the reach of a home user (I found FLOSS VNC servers' PKI authentication/encryption setup to be *very* painful, while SSH "just works").

And, of course, all of the above has nothing to do with notcurses itself, which might be useful in the future.

Hacking the planet with Notcurses

Posted Mar 20, 2020 13:39 UTC (Fri) by pizza (subscriber, #46) [Link] (13 responses)

> RDP and VNC give a way more painful user experience than tunneled X11

Unless you have an extremely low latency connection, this is categorically false.

X11 is a _very_ chatty protocol, and those round trip times add up quickly.

X11, xcb, and round trip

Posted Mar 20, 2020 15:36 UTC (Fri) by stephen.pollei (subscriber, #125364) [Link] (12 responses)

Xlib's synchronous calls incur avoidable round-trip latency. .. XCB makes the client-server nature of the protocol explicit in its design. The client is in charge of deciding when to flush the request buffer, when to read results and when to wait for the server to respond. Sounds like some of the waiting on round-trip times is library induced. The protocol should support pipelining etc.

X11, xcb, and round trip

Posted Mar 20, 2020 16:24 UTC (Fri) by pizza (subscriber, #46) [Link] (11 responses)

It doesn't matter what the protocol theoretically supports, or what applications or libraries can theoretically utilize. What matters is how the application you need actually behaves.

Here is a real-world example: I have a ping time of about 32ms to one remote system, with a lightly-loaded 40/2Mbit connection between us. Launching emacs took *34* seconds to fully render the window and get me to the point where I could start typing. Clicking on the menu bar takes *3* seconds to pop up the menu. Each keystroke takes about 1/2 second to appear.

I'm sorry, but that is completely, utterly unusable...

X11, xcb, and round trip

Posted Mar 21, 2020 1:26 UTC (Sat) by marcH (subscriber, #57642) [Link] (3 responses)

Funny enough I have a very similar configuration. 34 seconds seemed exaggerated so I just tried it: 10 seconds for me. Out of curiosity try this:

DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/nothanks' emacs

Don't get me wrong: it's still not usable. I use this:
https://www.emacswiki.org/emacs/TrampMode

Compatible with magit and Esc-X compile.

X11, xcb, and round trip

Posted Mar 21, 2020 1:46 UTC (Sat) by pizza (subscriber, #46) [Link] (2 responses)

> Funny enough I have a very similar configuration. 34 seconds seemed exaggerated so I just tried it: 10 seconds for me.

The first time I launched it it tool 54 seconds; the second time the 34 seconds I reported. When I just tried again now back-to-back it was in the mid-40s... DBUS_SESSION setting didn't make any appreciable difference; in all cases most of the time was spent waiting for the partially-drawn window to finish.

> Don't get me wrong: it's still not usable.

emacs seems to be surprisingly pathological, perhaps because it uses X more primitively than more modern applications that just sling pixmaps. For example, GIMP was much better over that same connection, with UI elements responding to my actions in a bit under a second..

X11, xcb, and round trip

Posted Mar 23, 2020 4:40 UTC (Mon) by mtaht (subscriber, #11087) [Link] (1 responses)

um, er, I have found a lot of the reason for bad x11 performance over tcp to be bufferbloat. tcp fills the pipe, then overbuffers & collapses.. your 40mbit link running cake? got ecn on on your tcp?

X11, xcb, and round trip

Posted Mar 23, 2020 11:34 UTC (Mon) by pizza (subscriber, #46) [Link]

I don't know about cake, but ecn is on. This side a DSL link running PPPoE, with the modem configured as a dumb bridge. The other side is municipal fiber rate-limited to a only 100Mbps.

However, when I ran those tests the link was nearly idle, so I don't expect bufferbloat to have been a factor. (When the link is saturated, especially the upstream side, it is _very_ noticeable)

emacs is was by far the most pathological application I tried, though bog-simple fixed-font xterm didn't fare much better.

Oddly enough, GIMP was the most responsive (and very nearly usable!) perhaps because it mostly just slings pixmaps everywhere instead of relying on X primitives.

X11, xcb, and round trip

Posted Mar 21, 2020 16:38 UTC (Sat) by anton (subscriber, #25547) [Link] (5 responses)

I use emacs running on a remote machine over X over ssh on a daily basis, and have done so since 1998, so it's obviously usable. I also use other X applications, in particular, xrn, but also firefox. Applications tend to become less usable remotely over time, particularly firefox, where somewhat recent versions tend to produce heavy lags even on a LAN.

Emacs tends to be quite responsive in my daily usage, except that mouseover highlights tend to cause hangs (interruptible with Ctrl-g), and I have not managed to get rid of all of them. Startup can take long these days, and first usage of a font also seems to produce lags. Anyway, let's use the startup time as a benchmark:

 7s xrn over ssh
 8s emacs 21.4 over ssh with intermediate proxy
10s emacs 24.2 over ssh with intermediate proxy
13s emacs 24.5 over ssh
13s emacs 25.2 over ssh with intermediate Proxy
10s emacs 26.1 over ssh with intermediate Proxy
It seems to me that the startup time depends much on which fonts are used.

X11, xcb, and round trip

Posted Mar 21, 2020 17:32 UTC (Sat) by pizza (subscriber, #46) [Link] (4 responses)

....are you seriously saying "it works for me and my setup, so it obviously must be good enough for everyone else?"

I've also been using emacs via tunneled X11 off and on since the late 90s, and still do so over LANs on at least a weekly basis. It works quite well in that context.

But across the public internet, with the latencies that I am forced to endure, emacs via tunneled X11 is completely unusable -- It's not the startup time; rather it's the multi-second delays that occur when interacting with the UI, neither of which occurs when using it (or other GUI applications) over VNC/RDP.

X11, xcb, and round trip

Posted Mar 21, 2020 18:18 UTC (Sat) by anton (subscriber, #25547) [Link]

It works for me across the internet (not just in a LAN), so it may be unusable for you, but not in general.

Using it in a hotel with lots of computer scientists competing for WLAN and Internet access borders on unusable for me, too, though; however, even there my experience is not a delay for every character I type, but heavy lags in unpredictable intervals (probably due to packet loss).

X11, xcb, and round trip

Posted Mar 22, 2020 14:10 UTC (Sun) by oldtomas (guest, #72579) [Link] (2 responses)

To be honest, and just as a reality check -- I went over your older posts and their quintessence is "it doesn't work for me, so it must be broken".

When presented with counterexamples, you preferred to stay where you are instead of investigating the discrepancies.

So such an answer (although not intended by the OP, as far as I can see) would seem like par for the course.

Just sayin'

X11, xcb, and round trip

Posted Mar 22, 2020 15:41 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

I'm saying "tunneled X11 may work for you, but it does not work for me (and others in my very-common situation) so you can't hold it up as the end-all-be-all universal solution for everyone while dismissing the alternative approaches that work better in those situations."

*shrug*

X11, xcb, and round trip

Posted Mar 22, 2020 17:35 UTC (Sun) by anton (subscriber, #25547) [Link]

Then it's good that I did not "hold it up as the end-all-be-all universal solution for everyone while dismissing the alternative approaches that work better in those situations."

What I fear is that claims like your "unusable" will make software maintainers care even less for remote X performance than they do now.

Ideally there would better developer support by having a version of the X libraries that simulates a configurable remote latency also for local testing, and provides some profiling to point out where the latency arises.

Or, for your alternative approaches, make them work automatically across ssh. Ideally, both.

X11, xcb, and round trip

Posted Mar 23, 2020 18:13 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

It's entirely conceivable that this problem is (to some extent) specific to Emacs.

TL;DR: It does double-buffering by asking X11 to double-buffer, instead of doing it itself. As a result, it talks to the X server whenever it wants to draw to the back buffer, which is frequently (and not necessarily related to GUI events, because Emacs was designed like a TUI application - it draws when it damn well feels like drawing). If the back buffer could somehow live on the remote side, it would probably be a lot more efficient.

Ironically, that brings us full circle. If Emacs had been designed like a GUI application from the start, it wouldn't now be losing the SSH game to TUI applications. (Or maybe it still would. Hard to say what a "GUI from the start" Emacs would even look like to begin with.)

Hacking the planet with Notcurses

Posted Mar 20, 2020 16:57 UTC (Fri) by ledow (guest, #11753) [Link] (12 responses)

(raises hand)

Sorry, I'm far from a Microsoftie, but it's necessary for my job however... RDP, Terminal Services and, yes, even VNC are far less hassle than any protocol that HAS to be tunneled to be safe (certificate-checking, etc. is performed by SSH, but in RDP it's a part of the protocol). Sure, they aren't hugely responsive but they more than make up for that in just ease-of-use. I don't think that you can say that X-over-SSH is any better or worse in terms of responsiveness, to be honest. Anything that is is largely lost amongst placebo, variability, ideal networking conditions, and individual user perception.

I manage 50-50 Linux and Windows servers. I wouldn't even bother to install a desktop environment on the Linux ones (SSH for basically everything) and the ones that do have them, I wouldn't even bother trying to X-Windows into them at all. Locally or remotely. It's just not worth the pain, let alone the hassle in setting up. Even if you could give someone some magical combined SSH+X-Forwarding tool that was single-click, it's still just not as nice.

I actually see X-Forwarding as such an antique that I'm surprised it's even still supported in a modern distro.

You have to think of all use cases - including casual use, novice-user use, remote-support use, terminal server use, low-bandwidth use, restricted access (e.g. hotels, cyber-cafe, etc.) use... and pretty quickly X-Forwarding falls apart in those respects.

Bear in mind that I log into my home via a portknock-hidden SSH port to a remote dedicated server in a datacenter, that holds an reverse-OpenVPN connection to my home network (thus punching through all NAT at home), that I then further SSH port-forward web interfaces through... just to watch TV on the go. I'm not scared of a complex setup, or tunnelling things, or remote-controlling computers. But, honestly, the last time I did X-Forwarding, it really wasn't worth the hassle over just forwarding/tunnelling an RDP or VNC port.

Hacking the planet with Notcurses

Posted Mar 20, 2020 20:04 UTC (Fri) by nivedita76 (subscriber, #121790) [Link] (7 responses)

What is the hassle in setting up? Assuming you already have an X server running on your local machine, it's as simple as ssh -Y server emacs

Hacking the planet with Notcurses

Posted Mar 20, 2020 22:32 UTC (Fri) by nix (subscriber, #2304) [Link] (6 responses)

Quite. Frankly, the environment in which remote X (and X forwarding) are useful is the one in which it was originally designed: you have a local area network and you want to run your graphical app on a big powerful machine which isn't the one you're sitting in front of (and which may well not have a screen attached at all). It works great there (though 3D is not terribly wonderful, honestly that's not likely to be the major use case for big powerful remote machines on a LAN in any case). It's not good at high-latency WANs, but then it never was.

(I do almost all my work that way, on an Emacs on a big LAN-remote server, and have for my entire working life.)

Hacking the planet with Notcurses

Posted Mar 22, 2020 10:50 UTC (Sun) by evgeny (subscriber, #774) [Link] (4 responses)

I really don't understand why people use X remotely if the response times etc are intolerable. Even within the same LAN it's annoying sometimes. Why not run the GUI app locally and provide instead remote access to the data (files)?

E.g., I mount (user-level, with sshfs) a remote directory I'm working on, and have the files appear as local ones to the locally running GUI apps. Then fusermount -u, and that's all. The only remote traffic takes place when I hit the "save" or "load" buttons, and since the file sizes are typically small, this is almost unnoticeable. Or at least predictable.

Hacking the planet with Notcurses

Posted Mar 22, 2020 13:43 UTC (Sun) by sorpigal (guest, #36106) [Link] (2 responses)

> Why not run the GUI app locally and provide instead remote access to the data (files)?

A few reasons: you can avoid needing to install and configure the program on each client, and for resource-intensive activities a beefier remote system can be better.

Hacking the planet with Notcurses

Posted Mar 22, 2020 17:13 UTC (Sun) by evgeny (subscriber, #774) [Link] (1 responses)

> you can avoid needing to install and configure the program on each client,

which is a one-time and (typically) trivial task. Commercial software with a per-client licensing is a separate story, of course. But, and also responding to your next comment,

> and for resource-intensive activities a beefier remote system can be better.

at least for this whole thread, you'll see many people complaining & comparing their performance figures not about some resource-intensive activities, but about emacs and like.

Hacking the planet with Notcurses

Posted Apr 8, 2020 22:44 UTC (Wed) by nix (subscriber, #2304) [Link]

> at least for this whole thread, you'll see many people complaining & comparing their performance figures not about some resource-intensive activities, but about emacs and like.

Emacs is an application manager as much as it is a text editor. Forking off performance-sensitive and/or memory-hungry subprocesses at the drop of a hat is downright common. (Even if you don't use magit. :P )

Hacking the planet with Notcurses

Posted Apr 8, 2020 22:42 UTC (Wed) by nix (subscriber, #2304) [Link]

I run multiple Emacsen: usually one for Gnus and one for work, under different uids. They use about 10GiB RAM each these days (Gnus is a bit of a pig and so is EDE/CEDET and I often have many hundreds of buffers open at once). My desktop doesn't have enough memory for that. They also like to talk to subprocesses which are better not "ssh BLAH" because the semantics of signal-handling across ssh sessions is screwed by the remoteness: you can't ctrl-Z one process inside an ssh you forked if you're that ssh's parent! Many of those subprocesses are things like compilations, and dammit I'd like to compile on the remote box with 20 cores and 128GiB ECCRAM and terabytes of SSD-cached storage, not the local box with 16GiB non-ECCRAM (half of which is eaten by Chrome/Firefox) and only two slow cores optimized for low power usage. (The local box has fast graphics, which is what matters for a desktop.)

The response latencies caused by doing this stuff over remote X are completely imperceptible. There's a reason I have 10GbE on the desktop! but the response times were completely ignorable even when it was only 100MbE. X is latency-sensitive above all else, and Ethernet is low latency.

Hacking the planet with Notcurses

Posted Mar 23, 2020 18:20 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

There is one other mode in which it is useful: Letting (remote) TUI applications interact with the (local) system clipboard. See for example Vim. This works well even over the public internet, because latency is basically irrelevant. A yank command taking an extra few hundred milliseconds is barely perceptible to me, and my keystrokes are buffered anyway.

Hacking the planet with Notcurses

Posted Mar 21, 2020 1:18 UTC (Sat) by marcH (subscriber, #57642) [Link] (1 responses)

> You have to think of all use cases ...

No. Only the ones that work.

> I'm not scared of a complex setup, or tunnelling things, or remote-controlling computers. But, honestly, the last time I did X-Forwarding, it really wasn't worth the hassle over just forwarding/tunnelling an RDP or VNC port.

Amazing. One of the main reasons I keep using X-forwarding despite its latency issues (depending on the application, the network, etc.), is that there is absolutely nothing to configure or startup. Just works every time.

Hacking the planet with Notcurses

Posted Mar 21, 2020 10:21 UTC (Sat) by whot (subscriber, #50317) [Link]

> is that there is absolutely nothing to configure or startup

I daresay this is the *only* reason people keep talking about X11 over the network. No-one actually cares that it's X11 that's sent over the network. Maybe the energy celebrating network-transparent X could better be invested in helping to develop a smarter replacement with the same zero configuration entry threshold.

Hacking the planet with Notcurses

Posted Mar 21, 2020 15:50 UTC (Sat) by ballombe (subscriber, #9523) [Link]

The advantage of remote X over vnc etc.is that it does not require the server to run a windows system at all.
It just need to have the X libraries installed.

Hacking the planet with Notcurses

Posted Mar 23, 2020 18:28 UTC (Mon) by ecree (guest, #95790) [Link]

> RDP, Terminal Services and, yes, even VNC are far less hassle than any protocol that HAS to be tunneled to be safe (certificate-checking, etc. is performed by SSH, but in RDP it's a part of the protocol).

Isn't this a question of Do One Thing Well?

Having "secure tunnel" and "network-transparent GUI" handled by two different processes is proper Unix design.

(Fwiw, my current remote-work setup goes vncviewer → ssh -L → x11vnc → Xvfb. It's *like* pipelines, but with sockets.)

Hacking the planet with Notcurses

Posted Mar 21, 2020 7:25 UTC (Sat) by njs (subscriber, #40338) [Link] (1 responses)

IME, for any kind of WAN situation, a decent bitmap-based remoting protocol is *way* more responsive than native X remoting. It's a bandwidth/latency trade-off: the X protocol was designed for low-bandwidth/low-latency links, while these days we usually have high-bandwidth/high-latency links, which is where bitmap-based protocols shine.

Have you tried 'xpra'?

Hacking the planet with Notcurses

Posted Mar 21, 2020 14:02 UTC (Sat) by Tov (subscriber, #61080) [Link]

Agree. Using X forwarding over wifi with intermittent drop-outs would be a particularly risky experience...

X forwarding had its place in history and is probably only still useful for old-timers using old applications. (I still "fondly" remember using a CAD program spending maybe ten minutes downloading fonts when started on a Sun X terminal on our university 10Mbit LAN. However, when running it worked fine.).

These days, I will rather use a stateless, bitmap oriented protocol.

Hacking the planet with Notcurses

Posted Mar 21, 2020 8:42 UTC (Sat) by barryascott (subscriber, #80640) [Link]

Moarc, thanks for sticking up for X11 performance, I agree completely.

I use X11 over ssh to run my editor Barry's Emacs and its fast in this config.
Barry's Emacs uses PyQt5 for its GUI interface. The editor is justing PyQt5
with any special code for X11. The only textures used are for menu items
and tool bar buttons.

Ping time from home to server in office in 15ms.
Start time is 4s, the only thing that is slower over ssh.
Once its up echo if chars shows no lag I can detect.
Menus open immediately.

To make this work I had to add compress setting to .ssh/config
Host *
Compression yes

Without compression its very slow.

The design of X11 does not force lots of round trips. In fact the design
minimises round trips. xcb took away a lot of pain point of the older API
to drive X11 protocol I understand.

X11 clients that use a lot of graphic texture, and modify them, will be slow,
but clients that are mostly text, like editors, can send that text efficiently
to the server for display.

Barry

Hacking the planet with Notcurses

Posted Mar 20, 2020 16:42 UTC (Fri) by am (subscriber, #69042) [Link] (1 responses)

One cool thing I always liked about openSUSE is that its YaST configuration tool runs as Qt application in GUI mode or as a pretty much identical ncurses UI in console mode. My understanding is that it has its own toolkit underneath to render the UI in either mode. I wish this was more common.

Hacking the planet with Notcurses

Posted Mar 20, 2020 17:41 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

It uses libyui which is an abstraction layer

https://github.com/libyui/libyui

The only known adoption outside of SUSE I am aware of is, dnfdragora, a UI for dnf using distributions (Fedora, Mageia, RHEL etc)

https://github.com/manatools/dnfdragora

Hacking the planet with Notcurses

Posted Mar 21, 2020 1:20 UTC (Sat) by marcH (subscriber, #57642) [Link] (15 responses)

> It seems impossible in an age of gigatransistor graphics cards, but the text environment still presents perceivably less latency than most GUI toolkits.

It's really not just GPUs.

There has to be some corollary to Moore's law going like this: "the more transistors, the more bloat and the less responsiveness"

Hacking the planet with Notcurses

Posted Mar 21, 2020 3:27 UTC (Sat) by flussence (guest, #85566) [Link] (14 responses)

I'm reminded of one particular sci-fi short story about the sum total of humanity's knowledge being stored in a single library, gradually going through cycles of tech miniaturisation until it ends up being a single indestructible holographic crystal “small enough to fit in a desk drawer”, with layers upon layers of indirection and search indexes needed to make sense of it. One day something in those layers stops working and nobody alive knows how to repair it, rendering the thing a paperweight. (naturally they didn't keep backups)

I feel like we're already there with most general-purpose computing hardware. Companies go out of business, or throw their products over the wall and do everything they can to pretend they never sold them to begin with, leaving nothing more than a windoze driver disk or preinstalled android blob, and nobody alive is able to get the magic sand to speak once its initial operating environment breaks down. I've got a few high-end Aureal sound cards from yester-century on my shelf with that problem — they're better sound cards than you'd get for $100 even today! But I got them for free because they don't work. Someone made a valiant effort with an ALSA driver mid-2000s but gave up halfway, and it's aged badly.

And almost every GPU from the AGP era is useless nowadays. I've got a few of those lying around; they used to run Xorg passably but can't any more. Most of the current crop of kilowatt Nvidias will join them in a few years.

Hacking the planet with Notcurses

Posted Mar 21, 2020 5:08 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> (naturally they didn't keep backups)
That doesn't sound reasonable. If anything, technological progress allows making backups easier.

Hacking the planet with Notcurses

Posted Mar 21, 2020 17:54 UTC (Sat) by tpo (subscriber, #25713) [Link] (3 responses)

>> (naturally they didn't keep backups)
>
> That doesn't sound reasonable. If anything, technological progress allows making backups easier.

You are not being sarcastic right? Because I have not ever been able to backup a Smartphone (== progress) in its entirety.

Hacking the planet with Notcurses

Posted Mar 23, 2020 18:28 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

For the average Regular Person (TM) in a developed, western country,* smartphone backups work in one of two ways:

  • You log into your iCloud account on your new iDevice, and It Just Works.
  • You log into your Google account on your new Android device, and It Just Works.

Yes, I know, there are numerous issues with that strategy. But bear in mind, the average Regular Person (TM) does not care about most of those issues, and is entirely unaware of many of them. The It Just Works factor is much more important to these people, since users are generally terrible at taking backups manually.

* This is an important qualifier. Phones in non-developed and non-western countries are very different from phones in countries that are both developed and western. In some places, the same argument applies, possibly for different values of "iCloud" and "Google." In others, the idea of backing up an entire phone to "the cloud" is ludicrous because mobile data is that expensive and home internet is either nonexistent or unreliable.

Hacking the planet with Notcurses

Posted Mar 23, 2020 18:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I have backups from my phones since 2010 to about 2014. At that time I stopped caring about losing my phone, since all the data was in the cloud anyway and I don't particularly care about losing a handful of average-quality photos. Meanwhile, my important data (financial docs, personal writings, etc) is now backed up on multiple NASes.

Moreover, it's not like books are somehow immune to destruction. A recent fire in the Russian Library ( https://www.theguardian.com/world/2015/jan/31/fire-russia... ) destroyed many books and documents that existed only as a single copy.

Digitalization would make this much less likely. And the amount of data to store most of the world's historical books is pretty much trivial by today's standards. Suppose that you want to store 130 million books (the estimated total amount), and each book is scanned in b&w without any OCR, taking around 10 megabytes. That's around 1.3PB in total - less than the capacity of an average enterprise NAS. OCRing texts would also bring that down by an order of magnitude, into the realms accessible to home users (20Tb hard drives are already here).

It's also unlikely that you'd want to store ALL of the literature, so subsets of it (like pre 20-th century English-language books) would be small enough to fit on a single SD card.

Hacking the planet with Notcurses

Posted Mar 23, 2020 20:32 UTC (Mon) by rodgerd (guest, #58896) [Link]

> A recent fire in the Russian Library ( https://www.theguardian.com/world/2015/jan/31/fire-russia... ) destroyed many books and documents that existed only as a single copy.

And that's just accidental destruction. During World War I, when German invaded Belgium, they were so incensed by Belgian resistance that they destroyed - amongst other things - a library that contained what was then around a third of the world's extant medieval manuscripts and books.

After the war, other collections donated some of their works to rebuild the collection. During World War II, Germany again violated Belgian neutrality, and decided to punish the Belgians for objecting by obliterating the same library.

(Source: Barbara Tuchman's 1914)

Hacking the planet with Notcurses

Posted Mar 25, 2020 11:51 UTC (Wed) by Seegras (guest, #20463) [Link]

> If anything, technological progress allows making backups easier.

Don't underestimate the political gatekeepers. They would have built a restrictions management into that cube of knowledge that makes this impossible.

You only have to look at phones, tablets, kindle etc. to see that "copying" and "backups" have enemies.

Hacking the planet with Notcurses

Posted Mar 21, 2020 14:17 UTC (Sat) by Tov (subscriber, #61080) [Link] (3 responses)

I realize you are just venting frustration - and can somewhat sympathize with that.

However, it doesn't really make sense, that you ramble against *both* layers of indirection *and* dedicated (proprietary) interfaces.

What is your proposed solution for saving humanity? :-)

Hacking the planet with Notcurses

Posted Mar 21, 2020 15:35 UTC (Sat) by dowdle (subscriber, #659) [Link] (2 responses)

For those complaining about the speed of X11 when tunneled through ssh, for goodness sakes try x2go. x2go doesn't provide support for 3D stuff (which includes some desktop environments) but generally speaking it is really good over a LAN and pretty darn usable over a WAN. x2go is a fork of NoMachine's NX 3 protocol. It uses ssh so no need to worry about opening up additional firewall ports. One shortcoming though is that the client is only geared toward one connection so multiple connections require multiple clients and windows. It would be so nice if the client got updated for multiple connections and a tabbed GUI. One very nice feature provided by x2go is ssh proxy which is handled in the GUI and easy to use.

Fedora and EPEL package both the x2go client and server. Debian (and it's derivatives) package the client but not the server (last I checked). The x2go project does provided repos/PPAs for Debian/Ubuntu. I'm not sure why Debian doesn't package the server?!?

Hacking the planet with Notcurses

Posted Mar 22, 2020 14:41 UTC (Sun) by pabs (subscriber, #43278) [Link] (1 responses)

A comment from one of the Debian x2go maintainers on IRC:

x2goserver is in Debian oldstable-bpo, stable and testing/unstable. As a multi-session client, people could try pyhoca-gui (it performs less as everything is done in Python)

Hacking the planet with Notcurses

Posted Mar 22, 2020 16:00 UTC (Sun) by pizza (subscriber, #46) [Link]

(I should point out that x2go is a full remote desktop solution, not unlike vnc or rdp, as opposed to "just-launch-applications-in-a-ssh-session" tunneled X11...)

At my last gig, we experimented with x2go (and others) but ultimately settled on VNC. I don't recall the selection criteria (this was going on 7 years ago) but the applications were heavyweight EDA tools running on RHEL6 with all clients (other than mine) running Windows.

Hacking the planet with Notcurses

Posted Mar 21, 2020 16:02 UTC (Sat) by excors (subscriber, #95769) [Link] (3 responses)

> I'm reminded of one particular sci-fi short story about the sum total of humanity's knowledge being stored in a single library, [...]

Anathem (by Neal Stephenson) featured a more plausible way of preserving humanity's knowledge: a kind of ritualised university system, where a large group of people would learn and become experts in a specialised field and teach the next generation, over and over for thousands of years while civilisations rose and fell around them. If humanity faced some catastrophe while civilisation was at a low point, this system would provide a pool of experts ready to find and interpret the archived knowledge needed to tackle it. An archive by itself is worthless; you need people who've spent a lifetime learning how to make use of it.

(In software terms, documentation and source code by itself is much less valuable than an active community that knows how to work with the software and is willing to teach others. The important part of open source is the people, not the code.)

Hacking the planet with Notcurses

Posted Mar 25, 2020 21:53 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

As I recall, Anathem also had the "problem" that the outside world would, on a fairly regular but infrequent basis (multiple generations or longer), sack the university and force them to start over.

On a more boring note, Stephenson's approach to formalism and platonism is deeply alarming to me. Firstly, he portrays formalism with a very crude and oversimplified explanation that makes it sound like he's confused it with fictionalism (contrast large portions of Gödel, Escher, Bach); then he jumps straight to platonism without even acknowledging intermediate positions such as nominalism or intuitionism. But the really evil thing that Stephenson does here is switching the genre halfway through the novel. We abruptly change from a low-tech sci-fi to pure fantasy, because platonism doesn't actually work in the real world and Stephenson wanted to use it anyway. If you view the book as an argument, rather than a story, this is basically cheating. And if you don't view the book as an argument, then in my opinion it does a poor job of dissuading the reader from that interpretation.

Hacking the planet with Notcurses

Posted Apr 8, 2020 22:35 UTC (Wed) by nix (subscriber, #2304) [Link]

I don't think that's any more cheating, or any more "not SF", than, say, any of Greg Egan's novels which feature entirely fictional laws of physics.

I mean this means you'd have to define Greg Egan's _Dichronauts_ as fantasy, since it has multiple things that just cannot happen in the real universe and a physics which is so weird that Egan doesn't describe it at microscopic scales because everything goes completely to hell, or rather, to infinity down there. But it's definitely SF, even if -- and this is not a spoiler because it's on about the third page -- in that universe turning your body by more than 45 degrees is as impossible as exceeding the speed of light, and there is a pair of borders on the land surface which you cannot approach because it's where the surface of the sun intersects the surface of the world! But the story is *all about* exploring the possibilities of that deeply whacko alternate physics, and dammit that is not what fantasy does. The latter part of Anathem is similarly less about the social structures of the worldbuilding and more about exploring what would happen *if* platonism were true -- that it's not true of our world is neither here nor there, that's why they call it fiction.)

What makes SF SF is not physical plausibility. It's about the tropes and tactics the author expects the reader to employ when reading it, and by that standard, _Anathem_ is pure SF.

Hacking the planet with Notcurses

Posted Mar 30, 2020 6:08 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> a kind of ritualised university system, where a large group of people would learn and become experts in a specialised field and teach the next generation, over and over for thousands of years

Cool, so he's describing medieval Europe :)

Hacking the planet with Notcurses

Posted Mar 23, 2020 1:35 UTC (Mon) by Kamilion (guest, #42576) [Link]

Oh good, something that I can use other than bearlibterminal.

http://foo.wyrd.name/en:bearlibterminal

You (Nick Black, Author of NOTCURSES) might have benefitted from a simple to grasp presentation like this:

http://foo.wyrd.name/en:bearlibterminal:design

although I'm reading the draft PDF book with interest so far.

bearlibterminal's weak point is that it's based on top of opengl. NOTCURSES seems more suitable for Vulkan-like behavior.

Quite a while ago, I cobbled together a little roguelike game using bearlibterminal.
https://files.sllabs.com/files/storage/games/pyrl/shnow_c...

Perhaps I might look into trying to port it to NOTCURSES as a distraction from the enfolding world events.
But, back to reading the pdf book...

urwid for Python

Posted Mar 23, 2020 19:56 UTC (Mon) by ber (subscriber, #2142) [Link]

In Python urwid seems to be a nice choice for terminal based applications.


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds