[cogburnd02]

I see no mention anywhere of yaft. Not an in-kernel framebuffer console, but one worth knowing about nonetheless, because it offers features like sixel support which probably won’t be landing in kernel any time soon.

[Also the title is ambiguous. While technically correct by referring to the kernel as Linux, I thought it originally meant GNU/Linux (the OS) because it didn’t say (e.g.) “consoles in the Linux kernel” or “consoles in GNU/Linux”]

[georgia_peach]

Sixel is kind of a mess. Many of the newer terminals (kitty, mintty, wezterm, iterm2, et. al) have a special escape for directly sending a base64-encoded gif/png/jpeg to the terminal for rendering. More colors & more efficient.

[cogburnd02]

The main advantage of sixel is probably the fact that it’s directly backward compatible with old DEC hardware, which I happen to like to use. I could have, say, a pdf reader that renders the pdf to the screen of an actual hardware VT330 by using sixels.

[wolrah]

The question there would be, it has that advantage but at what cost?

I'm not incredibly familiar with sixels, but my basic understanding is that they're in a format that was convenient for use with dot matrix printers and were later adapted to terminal use with color support and such. This means that interacting with them is not going to be straightforward for developers familiar with any sort of modern graphics APIs on either the software or terminal ends.

If the main advantage is compatibility with old terminals that only really matter to a niche subset of retrocomputer enthusiasts I'd argue that any efforts to add graphics to the Linux terminal should be focused on a more modern design such as the base64-encoded images supported by a few terminals.

[georgia_peach]

Since the article & the comment were about framebuffer terminals, in those cases, the base64 approach is superior: full color, built-in compression, no need to pre-rasterize. For <= 16 simultaneous colors (like in the original DEC terminals) sixel is A-OK, and in certain cases, even preferable! But when I see people today dither images to 256 colors just to be able to excrete them to a soft terminal with sixel, I cringe.

Something like Ascii85 or basE91 would have been even better, but beggars can't be choosers.

[LeFantome]

What is GNU and what is not these days? Is Wayland? Is GNOME?

Have you checked out Chimera Linux? Should I refer to that system as “the Linux kernel” or “GNU/Linux”? Neither makes sense.

Personally, I find it the most sane to understand that “Linux” is the name of the kernel and a “Linux Distribution” is a curated collection of software that runs on the Linux kernel. GNU Software may or may not be involved.

For me, the whole “GNU/Linux” things has always felt desperate. It is a bit like the 70’s BSD guys says AT&T needed to call their software BSD/UNIX because so many people used BSD stuff on their systems.

[cogburnd02]

> What is GNU and what is not these days?

There is a definitive list: https://www.gnu.org/software/

> Is Wayland? Is GNOME?

Wayland never was. GNOME was at one point but isn’t any longer.

> Have you checked out Chimera Linux? Should I refer to that system as “the Linux kernel” or “GNU/Linux”? Neither makes sense.

Neither, but it would be both accurate and more specific to say that it is a Linux-based OS with BSD’s userland.

> whole “GNU/Linux” things has always felt desperate.

It’s now “desperate” to ask to receive credit for software you wrote? GNU wrote coreutils and gcc and early GNOME and those are part of pretty much any early GNU/Linux system and you think giving GNU credit for the work they put into building an OS is ‘desperate’?? No offense but screw that.

> It is a bit like the 70’s BSD guys says AT&T needed to call their software BSD/UNIX because so many people used BSD stuff on their systems.

But the BSD guys never said that..that I can tell. Unless you can provide specific examples, I can only assume this is a straw man and ignore it.