6 ms·

The article mentions vocal advocates (for tmux, although which doesn't matter). Meanwhile, I've always thought it was unfortunate that tmux and screen even exi

• tyingq 9y ago
  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.
  • nine_k 9y ago
    A detachable session of an IDE could be a killer feature. Especially if the "terminal" would be your favorite editor.
    • lgierth 9y ago
      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.
      • nine_k 9y ago
        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.
        • chenglou 9y ago
          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.
        • secretasiandan 9y ago
          http://eclim.org/eclimd.html 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.
        • jmfurlott 9y ago
          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
        • chriswarbo 9y ago
          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.
    • AlexCoventry 9y ago
      You can effectively do this with emacs server.
    • willvarfar 9y ago
      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
      • u801e 9y ago
        > 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.
• Slackwise 9y ago
  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.
  • tyingq 9y ago
    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.
    • kasey_junk 9y ago
      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
      • tyingq 9y ago
        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.
        • kasey_junk 9y ago
          50 years ago it ran only on a single proprietary physical medium on bespoke hardware.
          • tyingq 9y ago
• arielb1 9y ago
  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".
  • derefr 9y ago
    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.
• astrobe_ 9y ago
  > 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.
• alsadi 9y ago
  If you want them enabled by your os just install this on your server http://byobu.co http://byobu.co
  • adambyrtek 9y ago
    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?
• kmicklas 9y ago
  > 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.
  • yjftsjthsd-h 9y ago
    > 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.
    • _ibu9 9y ago
      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.
• dredmorbius 9y ago
  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 https://packages.debian.org/search?keywords=rlwrap
• dredmorbius 9y ago
  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 https://packages.debian.org/search?keywords=rlwrap
• cryptonector 9y ago
  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.
• mmjaa 9y ago
  >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.