I'd argue that we shouldn't be adding code (in general, not limited to fish) to support old hardware such as this (or see the crazy list of systems supported by OpenSSL)
A lot of pain in systems comes from unbound backwards compatibility
A lot of pain in systems comes from unbound backwards compatibility
> Specifically, (pseudo-)serial devices, like the Linux console VT, initialize the rows and columns of the tty device to zero. That confuses fish since it now believes that nothing will fit on a line. Fish expects to be running inside a terminal emulator (xterm, konsole, iTerm2, etc.) which sets the tty width and height to the correct values.
So it's not only old hardware. It applies to modern hardware when you're using console to access a Linux server, which is not at all uncommon for data centers or headless servers.
There are libraries which still protect their PDP-10 compatibility despite being maintained and refactored for current generation systems.
OTOH, every good software should build upon its foundation. When you have good foundation and a good interface to it, touching it is almost unnecessary in the long term.
It's not just a matter of backwards compatibility, but also forwards. Right now the common term type is xterm (or variants thereof like xterm-256color). 20 years ago it was vt100. Will it still be xterm in 10 years from now? Considering Xorg itself is claimed obsolete by its own maintainer makes me wonder if it will be.
Good thing we already have a mechanism to support smooth alternatives for terminal types.
The greater sins I see today are assuming line length and assuming background colour.
You never know when some customer will put you in front of a vt220 and ask you to solve some arcane issue, and I sure am happy that at least some people care about helping others even if they don't have that specific hardware themselves.
And lastly, "breaking with the traditional way of doing shell stuff" doesn't necessarily mean "doesn't work on old hardware", just means that the shell UX will/can be different, but similar.
I go out of my way to make sure fish still compiles on ancient versions of operating systems (with the most recent compiler you can get on them) and still remains functional in the kernel console (no X), and others on the team go to even further extremes. We’ve argued for weeks over changing the names of variables that might break older fish scripts, even though fish isn’t really a non-interactive scripting language.
You’re going to have to qualify that statement.
Yeah with utmost certainty not gonna happen for the vast, vast majority of jobs.
It's not about arguing in their place. It's about thinking where our collective (includes the mentioned developers, me, and you as well) wants to take its technology. What afffects you, affects me and vice versa. We're not as seperate as you make out.