Hacker News Reader

> Well, then we should have OS-level APIs exposed that allow for that

That's what PTYs are.

> Instead, what happened is the whole thing gets reimplemented

No, that's a feature. The fact that you can use "neutral" OS services in different ways is a good sign. They provide PTYs and others build Screen, Tmux, dtach, ... and I'm sure others have come up with creatives uses for them too.

> in user space two levels deep (one for your GUI terminal emulator, then once again for the TUI terminal emulator you run inside that—either tmux or screen

I don't think so. We have GUI terminal emulators because there isn't much terminals around anymore, so the second "level" is accidental, not essential.

As for the first "level", this is the VT100 (or something like that) specification, which is used by tons of other programs, not just Tmux and Screen.

Furthermore, the greatness of separating "levels" is that I can run those programs from anywhere. For instance, Windows Putty + GNUScreen allows me to temporary use my Windows machine which is next my Linux machine as a second screen.

If I wanted to do the opposite (use my Linux machine as a second screen for my Windows machine), I think the solution would probably a lot more heavy, or simply impossible given how old is this machine.

> So I don't understand how anyone could be passionate about it, except maybe to passionately question why we're fine with continuing to do things this way, instead of stepping back and after a sober thought concluding that this whole thing is pretty silly

In fact, at day-job I work with 3 Linux servers. I have a screen session for each, each in one full screen terminal window on its own virtual desktop. All this from a 15 years old machine running a Mandrake so outdated that I can't update it anymore (don't ask).

This software you call "silly" provides a lot of services for very cheap. From network failure protection to session sharing. Not acknowledging this is the silly thing, if you ask me.

You need some sort of "terminal server" to maintain the session and station state, and I think screen's server does that thing quite well - I don't see a good reason to integrate the "terminal server" with the OS. You could split "UI session management" and "process management" somewhat (e.g. have Docker manage the process swarm and pass stdio to screen), but that's even more splitting.

The uglier part is that screen needs to communicate the UI state to a terminal emulator. Theoretically, you could have screen expose an API and have a client-side GUI client directly display a UI, and that is even probably a good idea (I'll like a Qt tmux client that can talk to a remote tmux with JSON over SSH), but nobody bothered to implement it yet, and a "VT100 over serial" client can be used without running new software at the "user endpoint".

PTYs are "terminal servers"—they're just sucky ones from a time when a terminal had fewer expected capabilities. But, indeed, you can connect a TTY directly to e.g. a serial modem, and then the person dialling your modem will get a TTY and login(8) will accept(2) on that descriptor and serve them a login prompt.

Telnet was just a protocol for serving whatever you'd get by connecting to the serial port, but multiplexed and over IP. Users got PTYs for their "session" and then login(8) was [usually] invoked.

Then, we got IPSec, to layer your telnet PTY tunnel inside an encrypted tunnel.

But SSH kind of turned things inside-out: it encapsulated a PTY inside an auth'ed login session which it managed itself, inside a carrier (e.g. TCP) which it also managed itself. It threw out the whole PTY-as-session concept (with PTY-managed-by-a-shell job control with Ctrl+Z, multiple PTY's-stdout writers to watch background jobs, etc.), creating its own sessions in the form of SSH "channels", and allowing the user to invoke arbitrary programs on the remote (with its own sshd_config specifying what is allowed) rather than handing off to the centralized PTY "terminal server" of login(8) to decide what to do with this session based on its origin device.

Until SSH, screen(1) and tmux(1)—and script(1) and nohup(1) and watch(1) and... were all just "enhancements" you'd run on top of a PTY as basically different shells that manage the PTY's jobs differently. Like different desktop environments manage windows differently. They might use additional PTYs to do this, but it was an implementation detail, and even then mostly only a hack—added later, not in the original designs—to ensure libcurses programs would work inside these.

But with SSH, since you lost the single encapsulating PTY session-group concept, we now saw things like tmux(1) and screen(1)'s PTYs as multiple root sessions. Now it was more like SSH was the terminal server, and screen/tmux was virtual desktops. Completely different paradigm, losing the thread of what PTYs were "for" in the process.

> IPSec, to layer your telnet PTY tunnel inside an encrypted tunnel

Are we talking about SSH? Because that's SSL, not ipsec.

No, I was talking about two separate time periods. Sysadmins were defining IPSec transports to protect port 23 traffic between mainframes and their terminals for years before SSH appeared. Allowing Telnet sessions to traverse the public Internet was one of the original motivations for IPSec.

The original point of SSH was that it didn't expect the client and the server to be part of the same administrative domain—i.e. it didn't expect a sysadmin to have been involved in advance to pair the devices and define a tunnel. This is why SSH's auth didn't, for the longest time, support any kind of centralized certificate-based PKI: it was for the cases where there wasn't a central authority in common, but rather just two peers that happened to want to talk securely—perhaps without the consent of their respective sysadmins; perhaps even despite the policies of their respective sysadmins.

SSH's "on the spot, look at my keys" auth has become so ubiquitous that sysadmins seem to have forgotten that, most of the time, they do control the administrative domain both devices are under, and can in fact just pair them using e.g. client certificates issued by a private X.509 CA. Fingerprint-based auth should be seen as a last resort, not a first resort; and, likewise, Telnet shouldn't be seen as a last resort, but rather a core tool serving a core purpose in a layered design: enhancing a "local-equivalent" (LAN or VPN) IP link into being a PTY session, upon which any number of things can be run. (For example, "dial-in" MUDs, of which a number still exist.)

> PTYs are "terminal servers"—they're just sucky ones from a time when a terminal had fewer expected capabilities. But, indeed, you can connect a TTY directly to e.g. a serial modem, and then the person dialling your modem will get a TTY and login(8) will accept(2) on that descriptor and serve them a login prompt.

In a way, but ptys both don't do the "UI state" thing well, and don't do the "server" thing well - you can't really "take over" the controlling side of a pty easily.

> Now it was more like SSH was the terminal server, and screen/tmux was virtual desktops.

In the normal use of SSH+screen (`ssh -t foobaz screen -r`), SSH just tunnels the VT100-over-serial over the network, and provides the needed authentication and routing.

There are advantages of putting functionality into other elements.

"The terminal" ... isn't. A TTY is a device, not an application. A terminal emulator provides access to an emulated terminal, and the beauty of screen and tmux is that you can drop these on any emulator (xterm, rxvt, konsole, gnome-terminal, xfce-terminal, etc., etc.) and have it Just Work. Or run either outside or inside (or both, if you're a masochist) an SSH session.

For another example of such modularity, there's rlwrap, a readline wrapper. If you're used to the functionality of readline integration with your shell (bash, korn, zsh, etc., etc.), and suddenly find yourself using a tool that lacks this (Oracle's client comes to mind), you have the option of wrapping the command in a utility which offers that missing functionality.

There's something to be said for modularity.

Another is that if screen, or tmux, offers a feature set you prefer, you're welcome to use whichever better suits your needs (or muscle memory).

https://packages.debian.org/search?keywords=rlwrap

Exact same feeling I have about web apps.

We could be using an app-centric XML-like language¹ for the UI, and an app-centric protocol versus a stateless² one where we apply hacks like cookies and WebSockets to. Instead we're hacking on top of a document-oriented system, and the hacks feel like they're 10 layers deep now.

¹ Similar to XAML or XUL, in concept and example.

² Statelessness is a great default, but when you need it, it shouldn't be an awful hack.

It is funny how we've regressed. For CRUD apps that don't do anything graphical, the current crop of web apps don't do anything better than a mainframe and a 3270 terminal did 50+ years ago. And the man-hours required to produce and maintain them is much higher.

That is an extreme simplification. Modern crud apps run from essentially any network in the world on hardware of every conceivable form factor and vendor. The protocol is open and so obvious it is routinely taught to middle school children.

All of those things are significantly different than a mainframe/term setup

I disagree. TN3270 runs on essentially any network in the world, and has existed for quite some time. I am scoping this down to CRUD apps that are text and labels.

50 years ago it ran only on a single proprietary physical medium on bespoke hardware.

Amdahl was an option.

I'm currently on my phone on a streetcar in San Francisco. I'm pretty confident there's one of those platforms I could access now with the greatest of ease, and the other would take some doing.

If you don't care about "making it pretty", you can make a cookie-cutter 3270-style UI pretty easily.

For CRUD apps that don't do anything graphical, the current crop of web apps don't do anything better than a mainframe and a 3270 terminal did 50+ years ago.

It's not actually true (unicode alone is a big improvement), but even if it was, so what? If a technology already fulfilled those needs pretty well, why would you expect major improvements to arise? The improvements come from the fact that you don't have to restrict yourself to text and labels.

> why would you expect major improvements to arise?

Maybe not, but you certainly shouldn't expect a regression, which is exactly what we're witnessing.

I would. A more general system will (almost?) always be less efficient than a single-purpose system, at that specific purpose.

I don't think modern CRUD apps are necessarily more general. They're just built on top of many more layers of broken abstractions.

You don't think that modern CRUD apps do anything besides showing text and labels?

I mentioned the man hours to build and maintain. That should have been an area for progress. It wasn't.

Can't argue with you there, I have no idea how much time it took on a 3270. That said, are you thinking about the time to build and maintain it from scratch? Because there are plenty of CRUD frameworks to remove 90% of the work. Of course, those have to be built and maintained as well, but then again, so did the 3270 terminals.

I first heard the "but ... the Web is just Mainframe terminals" realisation about 1997-98 or so.

And there's a fair bit of truth to that.

I'd like to see that too.

We could be using an app-centric XML-like language¹ for the UI, and an app-centric protocol versus a stateless² one where we apply hacks like cookies and WebSockets to.

You can: just write a C# or whatever app, and use some stateful protocol.

In any case, I find the whole "layers deep" to be a major overstatement. WebSockets are essentially framed TCP sockets, with a single initial handshake that looks like HTTP. They are not a "layer" over HTTP or anything like that.

I was talking about web apps. Of course I can use something different, just not on the web. (Since Silverlight is dead, that is.)

I suspect that the prevalence of graphical IDE tools, followed by container mania reduced the demand for anything like that.

Graphical IDEs moved the idea of a session away from terminals, and the ephemeral nature of containers discouraged attaching sessions to them at all.

So things like screen and tmux are now popular only with a niche crowd. Granted, it's one that has strong representation here on HN.

A detachable session of an IDE could be a killer feature. Especially if the "terminal" would be your favorite editor.

Sublime Text does this in a limited way by opening up in the state you left it, i.e. including unsaved changes, pane layout modifications, etc.

Many editors are capable of that.

What I'm talking about is running an IDE as a server and being able to connect to the same session e.g. from different machines which do not run a copy of IDE.

Imagine running all the real-time code analysis tools on a beefy corporate server while the editor component runs on your laptop. Imagine attaching to someone else's session to collectively debug a problem or review code, right in the IDE. Imagine your laptop losing connectivity / running out of power, being reconnected and recharged, and connecting right back to the IDE that never lost its state. Imagine running the IDE, or parts of it, in preconfigured and isolated containers / VMs.

Atom's Nuclide remote feature does that. We edit codebase on remote servers.

The alternative, and maybe a better way to do this, is a FUSE-like system, like Expandrive. Lazily fetches files from remote.

http://eclim.org/eclimd.html

> The most mature usage scenario that eclim provides, is the running of a headless eclipse server and communicating with that server inside of vim.

Tramp mode in emacs is the closest I have seen to something like this. The dream is a beefed up cloud server hosting and executing code, while you just use your local resources to run emacs

I have a system service for Emacs, which starts up headless and invokes emacs-server. When I want an Emacs window, I just run `emacsclient -c` (I usually have one for programming and one for email).

I've occasionally had X crash. After waiting for my desktop to reappear, I can reattach to my dtached DVTM session, spawn new emacsclient windows and be back to exactly where I was. The main application I use which doesn't do this is my browser, which is tied to the X session.

I do all of this locally, but at an old job I had to use a Windows desktop. Since we had Linux servers for development, I used them to run emacs-server. Each day I'd boot my Windows machine and use Cygwin/X to spawn a fresh Emacs window, picking up right where I left off the previous day. Just make sure to avoid GTK+ for the GUI, since there's a longstanding bug which prevents reattaching after an X server quits. I just used the Lesstif GUI instead.

You can effectively do this with emacs server.

I run xpra on servers and attach to them. This works far better than X-forwarding.

I warmly recommend xpra, although it is another screen/tux/not-a-builtin

> I warmly recommend xpra, although it is another screen/tux/not-a-builtin

But it does allow one to attach to running X applications, unlike screen or tmux.

It is much, much easier to develop application features in user-land than in kernel-land. PTYs are fine, and the fact that multiple screen-ish solutions exist is proof of this and a fantastic result.

Kernel development is much harder, and in-kernel applications increase the attack surface area of kernels.

EDIT: One important aspect of the difference in development difficulty of user- vs. kernel-land is that we would not get as much diversity of solutions if they had to be in-kernel.

>These two terminal multiplexers are really an end-run around unfulfilled wants in the way that the console subsystem should work by default.

I beg to differ. These aren't an end-run around anything, but rather a continuation of a long-standing tradition of isolating terminal events from processes. The fact of existence of a multi-variate number of tools to modify the application-execution environment shouldn't really be a critical point in ones evaluation; this is like complaining about window managers existing, because no true window manager exists.

If you want them enabled by your os just install this on your server

http://byobu.co

As far as I know Byobu is just a nice wrapper on top of screen/tmux to make it more user-friendly for beginners. How would that relate to concerns raised by the OP?

> So I don't understand how anyone could be passionate about it, except maybe to passionately question why we're fine with continuing to do things this way, instead of stepping back and after a sober thought concluding that this whole thing is pretty silly.

Most systems programmers are bought all the way into the Unix/worse-is-better mindset and are too afraid to ever question whether things could be designed with proper abstractions.

> too afraid to ever question whether things could be designed with proper abstractions.

That's fairly arrogant. Have you ever considered that we simply looked at the alternatives, observed the hell that followed, and beat a hasty retreat to well-tested abstractions that have withstood generations of change? It's not like nobody's ever tried anything else: NT, Haiku, parts of Darwin, various experimental research systems... really, if you want the anti-unix, go use Microsoft's stuff. OLE, COM, etc; nothing's a file, everything does more than one thing (poorly), they gave up on the legacy of teletype long ago.

But no, we're not huddled in the corner afraid of the world because our stuff sucks so terribly, we're relying on simple, composable layers because everything else breaks when you try to scale it up.

By criticizing Unix I did not mean look at Windows etc....

There are systems which take the good parts of the Unix philosophy (composability, uniformity) but abandon the bad parts (text, hierarchical files, mutability, the name based permission model, etc.).

There are various research crowds such as the FP and capabilities people are usually at the forefront of this but the research to production cycle is very long since Unix is entrenched. In my experience a lot of systems programmers are reactionaries and make this cycle longer than it should be, but that is the subjective part.