1. 6
  1.  

  2. 2

    That would have been an interesting timeline to visit. In our timeline the Linux console is regressing, they recently removed the scroll back buffer (i.e. shift-pageup does nothing).

    1. 3

      Just wait until the kernel implementation is removed altogether and moved into logind.

      1. 3

        I’m somewhat in two minds about that. Back in the old days, the kernel just spoke a very primitive protocol to an RS-232 or similar and all of the clever terminal logic was implemented in hardware in the terminal. In the slightly less old days, IBM PCs (though not most other microcomputers) had a hardware text mode for the monitor and the OS started talking to that and so needed to emulate a bunch of terminal features but got others for free from BIOS services. In the modern world (and on early ’90s UNIX workstations), the simples interface that the hardware provides is a frame buffer.

        This difference made the built-in terminals very slow on Linux on 32-bit SPARC workstations and meant that a lot of work was needed to make them fast on UEFI systems (which don’t have the old BIOS text mode).

        I’d generally much rather see the kernel provide a dumb framebuffer and run a userspace program to handle the terminal. A userspace program can do things like allocate a file for persistent logging, use malloc on pageable memory to get large amounts of back trace support, incorporate a TrueType Font renderer without security issues and so on. It has to shunt data to a device fast enough that users won’t notice, which is quite easy with an X server running on a dumb framebuffer and a terminal emulator running in a separate process and so should be fairly trivial without X11 in the way.

        The one case where this might be problematic is recovery. On Linux, with the initrd infrastructure, that’s far less of an issue than on something like *BSD (where you’d be left without a terminal if the root filesystem didn’t mount) because you can bundle the userspace program and are only stuck if you’re in a situation where the kernel can’t successfully launch a statically linked program from memory (and if your system is that badly broken, having a terminal emulator in the kernel probably won’t help).

        Windows NT never assumed that the hardware supported text mode and so boots a recovery mode with the simple GUI and ConPTY running in userspace.

        1. 2

          *BSD (where you’d be left without a terminal if the root filesystem didn’t mount)

          Interestingly, FreeBSD can easily do “initrd”/“initramfs”. The loader can load -t md_image your.file, the kernel can mount an FS from that ramdisk as the root fs, and the userspace there can ask the kernel to reroot (reboot -r) into your actual system. It’s just that nobody uses this in normal circumstances because the loader can just load required kernel modules directly from the disk :)

          1. 1

            I’ve used this to boot a FreeBSD kernel that was loaded via JTAG and which then mounted most of the FS via NFS, but it’s not part of the normal workflow. I believe that, now that the reroot stuff has landed, it’s easier to make this a default part of the FreeBSD process (you could boot from your ramdisk and then, once you’ve validated that you can mount /, unmount it and throw away the pages used for the ramdisk. This isn’t part of the normal boot flow though.

            1. 1

              I believe that all your requirements are exactly the features of kmscon. It needed kms or other framebuffer device, and then as a user, you replaced the getty with kmsconvt. It supported UTF-8 glyphs and had a proper configuration file.

              More details at the archlinux wiki

          2. 2

            You’re joking, but there was such a replacement from one of systemd’s devs in the form of kmscon. As far as I remember it was discontinued at one point, but I don’t recall the reason.

            I would love to see a modern replacement for the tty susbset, even coming from the systemd team.

          3. 2

            they recently removed the scroll back buffer (i.e. shift-pageup does nothing).

            Really!? What was the motivation for that change?

            1. 3

              Announcement. tl;dr: was declared broken and therefore removed.

              1. 1

                I would also like to find that out. Just haven’t had time to check.

              2. 1

                It has always been kinda iffy… if you switch between VTs it stops working anyway… (edit: i mean like it would be cleared)

                But what they should do is just pass through shift+pageup to the application if they aren’t going to do anything with it. Then programs like my nested terminal emulator could handle the scrollback itself.

                1. 1

                  Do they actually eat shift+pageup now? Well you can always rebind the command in your nested terminal to something else. My tmux reacts to bare pageup on its own (tmux is smart about it, sending pageup into a text editor inside still works fine)