-1

How far have we come in the past 30 to 40 years. Gigs of RAM. Terabytes of disk space. Gigahertz processors. 4K and 5K flat displays.

My console has a whopping, wait for it, 80x25 characters and 16 ANSI colors. It's stuck in the seventies. Even though my graphics card has 4GB RAM, 10bit color and whatnot, the console doesn't make any use of it.

Yes, I can start X11 or use a frame buffer console. But why do I have to? What is the insurmountable problem of providing a better console with say, a modest 256 colors? We have left some other standards behind, burnt some bridges (ISA? Real Mode? Turbo button? IBM compatible?), why not finally pimp the VGA console?

Improve this question
8
  • 3
    your question is too broad and also primary opinion based at the same time. Please have a look on help center and try to re-phrase it.
    – Máté Juhász
    Dec 21, 2015 at 13:17
  • 5
    you can set the console size to other sizes you like, up to 255 x 9999. I don't think there are any technical issues in making it fancier, but what for? People that use the console typically don't care for colors and lipstick and such, they want to get something done quick, direct, and simple.
    – Aganju
    Dec 21, 2015 at 13:18
  • 2
    Terminal emulation specifications that have been around for decades (VT-100 emulation), for compatibility with older hardware like mainframe terminals (which cannot be reconfigured), devices that use Com/Serial Port communication for access, etc. vt100.net/emu en.wikipedia.org/wiki/VT100
    – Frank Thomas
    Dec 21, 2015 at 13:18
  • @Jens Why aren't you just looked around?!? fishshell.com
    – g2mk
    Dec 21, 2015 at 13:36
  • @MátéJuhász I fail to see where opinion comes into play (other than my own that 16 colors is pitiful). There must be a technical reason and that's the answer I'm looking for.
    – Jens
    Dec 21, 2015 at 13:46

5 Answers 5

Reset to default
7

Regarding Linux specifically, the usual reason I've heard is "we don't want it in the kernel". Especially when it comes to fonts and languages – no kernel developer wants to fall down the slope of adding support for TTF, antialiasing, RTL, animated emojis, eventually running all of freetype2 and ICU in kernel space.

Rather, they put in the kernel what makes sense to handle in the kernel – such as graphics drivers, along with KMS. If you use the open-source drivers with KMS support, the console will automatically switch to your native screen resolution – like a framebuffer but without any manual configuration. Practically all Linux distros I've seen boot to a high-res KMS framebuffer by default.

Once you have evdev for input and KMS for output, userspace can handle the console just fine – e.g. via kmscon or fbterm. There are even vague plans to eventually turn off kernel VT support, leaving just one tty1 for early-boot & rescue tasks, and letting userspace handle the rest.

Improve this answer
2

Consoles usually do support 256 colors, although you may have to change some settings to enable it everywhere, see e.g. http://www.robmeerman.co.uk/unix/256colours

And the 80x25 limit should go away if you just resize your terminal window, allowing you to fill your 30" screen with more characters than is comfortable to read.

Improve this answer
4
  • More than 80 characters are comfortable to read?!? baymard.com/blog/line-length-readability
    – g2mk
    Dec 21, 2015 at 13:26
  • @g2mk, I think you may be seriously underestimating how annoying it is to read 80-char lines of code. everything is line broken, so its very difficult to track block and indent levels, incentives bizarre use of fixed width whitespace, etc. You document may be appropriate for web-sites output, but not at all kosher for reading the code that makes them up.
    – Frank Thomas
    Dec 21, 2015 at 13:41
  • That link seems to refer to terminal emulators, like xterm in 256 color mode. The question is: can I get 256 colors on a console (No X11, no frame buffer), in say FreeBSD?
    – Jens
    Dec 21, 2015 at 13:45
  • @FrankThomas It's not mine document :P Line length matters most when you have to read long blocks of mono-colored text. Multi-colored code readability is a bit different - it all about coding standard and consistency. However personally I still prefer indentation above long lines.
    – g2mk
    Dec 21, 2015 at 14:02
2

Because there is no need for it.

In the days when memory was expensive and processors were slow, hardware text modes made sense as they were faster and less memory hungry. Nowadays computers are powerful enough and have enough memory that the costs of having a simple framebuffer and implementing the text display in software are negligable.

As a general rule desinging and debugging hardware is expensive, so it will only happen if there is a genunine demand for it. The legacy text modes are kept around for backwards compatibility reasons but there is no drive to introduce new ones when the requirement for high resoloution text is handled fine by software.

Improve this answer
1

In the age of VGA, 80x50 became widely supported and used by some. However, on the pitiful 14 inch monitors of the day, some people found it hard to read.

In the age of Super VGA, we pimped out at 132 column mode. Rows could be 25, 50, 60, or other values. However, there was some compatibility issues.

Now, a lot of hardware could support that. Yet you find yourself using 80x25. Why? Because you're using default settings. And the default settings is that very few people have cared.

Eventually, GRUB started to support graphics, though, so some people have tinkered with some increases. In general, such things have been a novelty. If you really want more rows and columns, there's little reason why to ask the video card to use a video mode that it calls "text", instead of using a video mode that it calls "graphics". And, over the years, we have had increases in graphics capabilities. Things like 256 color terminals, or higher colors, and even things like transparencies, do exist. We just call them "graphics" modes.

I think the point of a "text mode" is that the graphics card can load up a pre-defined font, and then display certain graphics (which we call "characters") using a small amount of memory, instead of repeatedly specifying the same combinations of pixels using a larger amount of memory. What's happened is that we've just had less reason to worry about such memory savings. Hardware acceleration standards have allowed us to use different techniques to optimize things for speed. Video cards have enough memory that they don't need to use a special video mode that is designed to try to load a bunch of pixels arranged in formats that we call fonts.

Improve this answer
1

why not finally pimp the VGA console?

You're confusing the notion of a console with the old PC-style MDA-style text mode.

This text mode is a device/display configuration that can display console text, but text output from a console can appear on any device or program that can understand the protocol the console is using. PuTTY is a program meant for this purpose that has more capabilities, such as the 256-color support you mention and ability to have screen sizes other than 80x25.

As far as why the MDA-style text mode hasn't been changed, well, graphics adapters have added more capabilities, but they kept the MDA-style text mode for compatibility. Remember that all modern AMD/Intel CPUs still boot up in 8086-compaitibility mode just in case you still want to run DOS, and DOS still expects 80x25 text mode on boot up.

Linux supports things other than MDA-style text mode or X11 for display, it can use framebuffers as a text mode, with 256-color and even image support.

Why are console capabilities stuck in the seventies?

  • A basic engineering tenet is KISS. Console capabilities are simple, so software and hardware that implements them is simple and easy to make reliable.

  • RS-232 works well with basic console I/O. There are many legacy and current devices that use 12v RS-232 and probably just as many newer ones that use 3v RS-232. It's a widely accepted hardware standard that makes console I/O an expected thing on many devices that have this hardware.

  • Thus, having console I/O as an initial I/O method on power up and a last-ditch method of communicating when all else is failed also makes sense. In this case you are usually communicating status messages or error information and don't need a lot of bells and whistles.

  • Also because of this simplicity, redirecting console I/O to a file or other device is also relatively easy. For example, on many servers, the initial power up text is not only displayed on the VGA screen, but also optionally redirected on the serial port. So this means you don't need a monitor hooked up to it, which helps in a datacenter that can potentially have hundreds or thousands of servers. It's the same for other devices that use console I/O or RS-232 like industrial equipment, etc.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .