> Yes obviously it can be worked around by tens of thousands of people. We weren't discussing that. This is about the default which is clearly an insane default in 2024.
But what you're advocating isn't changing the default, it's changing the purpose of reset.
If people want something to clear the scrollback buffer then a new standard, and thus tool too, should be implemented. And in fact there are other ways to clear the scrollback buffer. You're just insistent on complaining that one very specific tool which is intended for a whole other purpose also clears the scrollback buffer slightly quicker...
> Rubbish. There are obviously other options:
> * Don't upgrade their software (almost certainly the case already).
That might not be an option. Some financial systems still use older style null terminals in places.
> * Install a version of `reset` that has the delay.
Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
> * Add an option to `reset` to add the delay.
That's not really practical on most systems because `reset` is just a symlink to `tset`
> * Stop using a physical terminal.
That's about as unhelpful a suggestion as it comes.
> If you're ever wondering why it will never be the year of Linux on the desktop, it's because of attitudes like yours.
Please don't make personal attacks. Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
If you bothered to do even the smallest amount of research on me, you'd realise that I'm massively in favour of modernising the command line. I've written a next generation shell that, frankly, leaves most others in the dust. And I'm not working on a terminal emulator that can in-line multimedia and other interactive GUI components. The problem here isn't my attitude, it's that the arguments in favour of changing `reset` are bullshit nonsense that both misunderstand the purpose of `reset` and also risk breaking a whole plethora of hardware because of that misunderstanding of yours.
>That might not be an option. Some financial systems still use older style null terminals in places.
But how many of those setups require a custom TERM and are unable to install a different package for reset.
>Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
The amount of people who need that delay is miniscule compared to the people who don't. Normal users don't need the delay, only exotic setups, which is why the default does not make sense.
>That's not really practical on most systems because `reset` is just a symlink to `tset`
Then stop doing that.
>That's about as unhelpful a suggestion as it comes.
Not really. It has practical benefits and avoids down time of having to get it repaired or replaced.
>Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
His comment was about your attitude of tailoring the system to a niche group instead of tailoring it to the billions of potential desktop users out there.
Let me be clear, I’m not against support your requirements. I’m saying ‘reset’ is the wrong tool to do that.
It’s like complaining that a text editor has no support exporting files as a PNG just because a subset of people happen to use that text editor for ASCII art.
If you want better support for clearing scrollback then that problem lies with ‘clear’, not ‘reset’.
Just as terminal capabilities lie with ANSI escape codes, not the TERM string.
The issue here is the pair of you are asking for the wrong thing then ignoring literally everyone else on HN and proceeding to make up insanely stupid claims about affected users (“billions of desktop users” lol) and call everyone else out for being unsupportive. Perhaps if you bothered to listen to people you might actually learn something.
Windows has also maintained backwards compatibility to a ridiculous extent, and there have been a bunch of "year of the Windows desktop", so I don't think it is detrimental that Linux does the same.
The issue is not about maintaining reasonable backwards compatibility. It's about refusing to fix things and using ridiculous backwards compatibility as an excuse.
1. Even Windows doesn't maintain full backwards compatibility all the way to the 90s, which is what you are advocating.
2. You could even fix this in a backwards compatible way if you wanted!
Also I never said anything about "full backwards compatibility". I just think this specific compatibility is worth preserving because your justifications are weak (by your own admission, you're only arguing about it because you enjoy arguing with people on the internet).
> 2. You could even fix this in a backwards compatible way if you wanted!
It has been. You objected to those backwards compatible fixes.
I've also suggested a way of patching `reset` without relying on buggy usages of `$TERM`. That also apparently isn't good enough for you.
> you're only arguing about it because you enjoy arguing with people on the internet
Not at all. Firstly I clearly stated a second reason so that isn't the only reason. And secondly, that's orthogonal to whether or not I'm right. If I didn't enjoy debating I wouldn't bother but I would still know that maintaining this delay is idiotic.
> It has been. You objected to those backwards compatible fixes.
It has not. If I install a default Linux distro, the default configuration is to insert stupid delays everywhere.
I have to go out of my way to remove them. That. Is. Dumb.
