[systemd-devel] vt220 default for serial console still relevant?

Tue Jul 14 20:04:32 UTC 2020

On 7/14/20 1:48 PM, Daan De Meyer wrote:
> I just tried vt241 and didn't get colorized output in konsole. I looked around a 
> bit and it doesn't really seem supported at all by terminal emulators (or at 
> least none that I found). I also tried TERM=xterm-256color with 8 different 
> terminal emulators and got colors with all of them. My workflow is simply "mkosi 
> qemu -nographic" (with a modified mkosi that adds console=ttyS0 and overrides 
> TERM for serial-getty at ttyS0 in the vm)." That connects my terminal emulator to 
> the serial console of the vm. I then execute "ls -l --color /" in the vm and get 
> colored output every time in whatever terminal emulator that I try.
> 
> I'm probably missing something but I'm wondering what an example terminal 
> emulator would be where xterm-256color would not work at all (even st worked 
> perfectly and that is supposed to be pretty barebones afaik). Or is it just that 
> color is a commonly supported subset of xterm and stuff breaks down with other 
> escape codes instead? Or maybe qemu is doing some kind of translation that 
> magically makes every TERM setting work in whatever terminal emulator I try? 
> Apologies if this seems ignorant, I have no experience at all with this domain.

So, some info (not necessarily direction).  Old guys like to talk...

So, speaking of things of old, but not ancient old, when handling server 
equipment via serial, you normally do three things.  You route the BIOS (legacy) 
out the serial port, you send the kernel boot messages out the serial port and 
you establish a getty for login on the serial port.

Just being honest, the "server world" decided everything was Microsoft 
Hyperterminal (up to Windows XP, what many considered to be "ansi", 80x25) 
during the PC revolution.

So.. Windows doesn't come with Hyperterminal anymore, which makes sense since 
PCs in general don't have serial ports (apart from USB-serial dongles).

So, can you, or should you adopt a serial console solution (ansi, 80x25)?  IMHO, 
this is still interesting.  Especially in the Linux world.  Consider that 
network equipment still speaks serial for console, the concept (still, even 
though this in a old concept) of using, for example, ssh to serial console 
controllers for full out of band access might still be appealing.

Why?  Well, for many reasons.  Cabling is much less (that is, less dense) as you 
can use flat velum for quite some distance for serial.  Since you're having to 
somehow deal with network devices anyway, by have all done serially, you have 
"one stop" shopping for out of band (more on this in a bit) console access.

Bonus, no high cost of licensing, for example, iLO or iDrac ent.  But noting 
that you don't get virtual media with a serial console head solution either.

But still, if running remote facilities and you need true out of band, and by 
that I mean the ability to reconfigure everything, including the network, it 
could be just the thing you need.

But ssh? Network reconfigure?  That's not going to work.  Often times those same 
ssh to serial console devices have additional serial support usually with a 
option of a modem (yep... old school I know).  Back in the day, using a callback 
modem (added security) your infrastructure could reach out to you and you could 
indeed reconfigure the whole datacenter, soup to nuts.  Something lacking in 
general today.

About your other comments, systemd sits in user space and can query (depend 
upon) terminfo.  Then, it should be able to support "whatever" terminfo has 
defined.... which could include custom terminals by the way that an end user has 
added.  And while all of that sounds incredibly ancient/old, I was on a project 
post 2000 that had to do exactly that (of course, even that might sound too old).

Btw, as weird as it sounds, where I work today, and I'm not the network admin, 
the network admin has purchased a ssh to serial console controller with callback 
modem.  And he's in his early 30's.

Btw, when I used to help manage an entire datacenter (same time as contract 
below) with those ssh to serial controllers, I just let the the linux TERM 
remain as it was mostly compatible with the ANSI from the host BIOS (at least 
I'm pretty sure).

With regards to that post 2000 project, I was interfacing with an old accounting 
package called datamodes.  Company wanted a solution where by people at home 
could ssh into this character based gui, have all the key sequences (and I do 
mean all, every Fn, Ctrl, Shift, Alt combo) and have the ability to print to 
their local printers from that ssh terminal session.  All of this was doable 
with good old fashioned terminal handling from the ancient of days.  But I did 
have to craft my own terminfo entry.  Loosely based off the scoansi terminal 
(one of the most complete terminal definitions out there, but not totally 
complete).  The end users were already running a terminal emulator that had a 
SCO ansi mode.

(even back then, datamodes had a "Windows" solution, but for the company I was 
contracting to, it was too expensive)

> 
> Daan
> 
> On Tue, 14 Jul 2020 at 18:22, Christopher Cox <ccox at endlessnow.com 
> <mailto:ccox at endlessnow.com>> wrote:
> 
>     On 7/14/20 3:19 AM, Lennart Poettering wrote:
>      > On Mo, 13.07.20 18:16, Christopher Cox (ccox at endlessnow.com
>     <mailto:ccox at endlessnow.com>) wrote:
>      >
>      >>> No vt220 does not support colour. I used to work on one and it is
>      >>> monochrome hardware.
>      >>> Xterm and konsole support extensions beyond vt220 that add in the
>     colour support.
>      >>
>      >> Not sure how much (offtopic) history we want to get into.  I used the VT240
>      >> in my college graphics class.  The VT241 was the color variant.
>      >>
>      >> See: http://terminals-wiki.org/wiki/index.php/DEC_VT240
>      >>
>      >> I still meet programmers what hard code ansi sequences rather than querying
>      >> termcap/terminfo.  You know what they say about those who "assume".
>      >
>      > Hmm, if vt241 is a bettre featured terminal type, and both xterm and
>      > the Linux console a superset of it, and the terminal widely available
>      > in termcaps and stuff we can certainly change our default TERM to be
>      > vt241.
>      >
>      > Daan, if this all is the case, could you prep a PR?
> 
>     I would think shooting for something low is actually good.  Let the individual
>     configure for something "better".
> 
>     I'm not sure I'm ready to say monochrome is obsolete.  There can be beauty in
>     simplicity and function.  My preference, aim low, and allow easy configuration
>     upward.  You could take the opposite stance of course, it's just that it could
>     cause some frustration.
> 
>     Just my opinion though.  I'm old and I think about a lot of things like
>     terminals, "proxies" and callback modems... things of value, but most do not
>     understand or care about anymore.
> 
> 
>     _______________________________________________
>     systemd-devel mailing list
>     systemd-devel at lists.freedesktop.org <mailto:systemd-devel at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 