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@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 <c...@endlessnow.com
<mailto:c...@endlessnow.com>> wrote:
On 7/14/20 3:19 AM, Lennart Poettering wrote:
> On Mo, 13.07.20 18:16, Christopher Cox (c...@endlessnow.com
<mailto:c...@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@lists.freedesktop.org
<mailto:systemd-devel@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
