I still use it. I do not use it on a daily basis, but I have certainly used it this year.
If I need to copy output from a program such as top or mtr it is quite convenient to press ctrl-s in order to freeze the output while I copy it.
I think that functionality was inherited from the keyboard driver in the original IBM BIOS.
As far as I recall there is a functional difference between ctrl-s in a terminal and the pause key in BIOS/DOS/Windows.
The ctrl-s key combination only affects the terminal. The process can keep running unaffected after you press ctrl-s until it tries to write to the terminal. Only then will it block on the write system call. If a process is busy doing some processing with no output to the terminal, that can continue after pressing ctrl-s.
The pause key will however block the processing entirely. As I recall it, once pause is pressed an interrupt is generated. And control flow does not return to the running process after that. Instead the keyboard driver will wait for a different key to be pressed before returning to the program context which was interrupted by the pause key.
I'm just using plain ssh. I have of course configured it to only permit public key authentication.
Using a VPN is another possibility, for that I would need a different port open. So in terms of security the question then becomes whether I would trust the VPN or ssh more.
I have tried noexec for /tmp on Ubuntu, and there were things which broke as a result. As far as I recall there are certain package upgrades which needs to exec something from /tmp during the upgrade.
The recommendation to use noexec for /tmp isn't new. I think I came across that recommendation in the late 90s. But it was never widespread enough to be officially supported.
Removing wget and curl won't prevent downloading files. It's possible to download files using just bash internals.
While I was away from home for a few days I was able to access data on a machine at home using ssh. Thanks to having IPv6 both at home and in the place I was staying this worked without needing to mess with fragile NAT or port-forwarding setups.
I am wondering if t-strings are going to be supported by the gettext function found in the Django translation library.
A bug I have frequently seen is f-strings being used like this:
gettext(f'Hello {name}')There is no way passing an f-string to gettext in that way could ever work as intended. However it sounds like the different semantics of t-strings means that the library could be extended to work with t-strings. So maybe in the future it would be valid to use like this:
gettext(t'Hello {name}')
Julie Hughes