Could you please name a single model of SFF PC that exposes a serial connection via RJ45 port?
This reads like such an arbitrary wish without a reasoning WHY you would want this. I'm sure OP has a reason for preferring it, but what makes the 80x25 superior in their opinion?
Had to get a CRT to see what the hell was going on.
Also, it should still be possible to connect a serial mouse to a modern system thanks to adapters. I still have serial to PS/2 and PS/2 to USB adapters floating around in a tackle box.
To be fair, they listed reasons to need a 80x25 terminal, but not reasons to need a 80x25 console. I'm a bit unclear as to why they could not use a regular 80x25 term in their graphical session.
Heh. [Most] PS/2 to USB adapters aren't.
They don't actually adapt the PS/2 protocol to USB, they just adapt the pins. The USB _hardware_ on the host does the emulation. However, the new generations of USB chips stopped bothering with the PS/2 emulation so these adapters are now useless.
I bought a used slideable rack-mounted LCD last year for my home server rack, and its keyboard with touchpad use PS/2. That's how I found that out.
I actually always disliked the modeset that the author remembers fondly, but it is always sad to lose part of our history for arbitrary reasons and especially so if it breaks a ungoverned consistency.
To use your example: Real mode still exists and you can use it, and firewire is effectively the father of Thunderbolt (and granddaddy to Thunderbolt 3-4); so its removal really does feel unnecessary without additional context.
Serial mice is masochism, but people do dislike that PS/2 is gone, for good reasons.
More than half the code I've been paid to write in the past 2-3 years has been written in vim running on a vtty with no X and no mouse. It's my favorite way to work, although occasionally it's impractical.
I think serial mice should still work as well - https://wiki.alpinelinux.org/wiki/Serial_mouse
I don't see why it shouldn't be possible? It seems like a reasonable thing to want to be able to change and even force resolutions to whatever your hardware will support, especially if there's a large amount of old software out there which expects a certain resolution. Old computers are very nice to have, but increasingly difficult to find and find working parts for. They also tend to come with some pretty big trade offs in terms of size, noise, and energy inefficiency. It'd mean a lot of less than ideal hardware just to get back something that people already had.
For me, the worst things about the Linux graphical console are lack of scrollback and horrible performance. Linux still has scrollback in VGA text mode, and of course it is super fast because each character is only 2 bytes. In graphics mode you can only fix this by running a program that provides its own graphical terminal, like kmscon or fbterm.
The best thing about the graphical console is ability to use bigger fonts, so your characters can be smooth and not pixelated. I like the Terminus fonts. As long as performance isn't a problem it's better to increase font size than to decrease the resolution.
Dumb question: when I boot a modern systemd-based distro installer in terminal mode, am I using "VGA text mode" or "graphics mode"? Do I have to be literally using VGA to use VGA text mode?
EDIT: I read TFA and it seems like the answer is that I probably have never used VGA text mode.
If you're doing a BIOS boot, you might be using VGA text mode, if you haven't loaded a framebuffer driver. VGA text mode works over BNC, DVI, HDMI, DP, etc, if that was your question, you don't need a VGA connector. EGA text mode might be similar enough to also work, but that's outside my depth.
I'm not sure that Linux uses it, but VGA has nice things to accelerate scrolling. You can set the top of the screen down into the buffer, and then set a line number where it resets to the top of the buffer. If you set the line stride so that it evenly divides the buffer (typically wider than the line width), it makes scrolling and wrapping around the buffer very simple and elegant.
UEFI GOP doesn't provide any mechanism for a buffer larger than what's displayed, so scrolling requires copying. :(
If the system you're using (ARM??) doesn't have a particular fbdev driver, it still works thanks to the simpledrm weirdness. But if you want very particular results, you're gonna need to ship a driver for your card, to tell the card what to do, to tell the monitor what to do. The complaint seems to be that architectures change? I dunno what to tell you man. I hate technology too, but it do be changin'.
Personal preference are tautological.
Maybe I don't understand something, so please explain?
And let's chuck into the dustbin of history fiddling with IRQ dipswitches to disambiguate your mouse, video, disk, and audio controllers; the "turbo" button; "It is now safe to turn off your computer"; CGA/EGA/VGA/HGA/MCGA/SVGA/XGA, RLL/MFM/SCSI/IDE, and while we're at it, TSR programs like sound drivers, mouse drivers, etc. Let's not even discuss OS/2.
You know what sucked? Booting up into CGA and not being able to figure out how to escape that abomination. Why not pine for that?
All of this trash is behind us and frankly I think we're better off for it. If you want to go play with obsolete computers, then finding some old computers and some old computer junkies who still enjoy that junk is the right way to go. Personally, I had my fun, but I like our modern machines so much more than those old smokey capacitor poppers. But I have to admit, I almost miss compiling my own kernel. Almost.
I remember desperately trying to put drivers in high memory, because Wing Commander 2 needed more memory if I was to get the precious images of the joystick moving. Slowly removing items, one by one from my autoexec.bat file, desperately hoping it was going to work, but then the creeping realisation that I would have to unload my soundcard drivers if I wanted a chance.
Or the time our bios randomly wiped its memory and my dad was convinced I had destroyed the harddrive. Thankfully I was told by a family friend that I would only have to turn on the BIOS and set it to # 31 (because somehow hard disk sizes, sectors, et cetra were all standardized) in order to access our precious 95 megabyte hard disk.
Oh, and only some hard drives were standard like that. For others, you needed to set sectors, tracks and landing zone manually. Happy fun times if your CMOS battery ran out.
Needless complexities have simply crept in other parts of the machine.
There are all sorts of disabilities that might necessitate a console with large text, and setting a specific size (in this case 80x25 because it used to be a standard) isn't such an outrageous demand.
The author knows a solution: set a specific resolution and select a specific font. The problem is that they can't pick that resolution, even though they could before, because on UEFI and non-amd64 the common GPU configuration parameters don't work in Linux.
We should default to a modern system, but the kernel should have a standard way of configuring the boot console. For every person who wants 80x25 mode, there's someone with a weird device that outputs three pixel high fonts because the default resolution is bugged, and both need the same override to fix their issues.
Another example is dropping support for 32-bit x86. "But how will I run Linux on my PC from 2001?". Or the resistance to Rust in Linux because LLVM doesn't support the PDP-8 architecture.
Actually there _is_ a lot to be missed about those times, in spite of all the "progress" we've made since then.
$ qemu -curses …
Some years ago, I had a headless system running QNX in a control application. About 30% of the CPU time was being consumed by something. It turned out that the system had a very minimal VGA controller, not connected to anything. The QNX boot image was capable of running with no console at all, which was the intent. But it found the VGA controller and launched a screen saver. The screen saver worked by shifting the entire screen one pixel at a time, which, with this minimal VGA controller, was a very slow read from VRAM, one byte at a time. This was so slow that it ate up a huge amount of CPU time.
This being QNX, it wasn't at high priority, so the real time stuff preempted it.
throwaway1777•2h ago