OTOH, things that update too often seem to be more than slightly broken on an ongoing basis, due to ill-advised design changes, new bugs and regressions, etc.
I'm not 100% sure when I started using putty, but I definitely used it in 2004. I still need a ssh client and terminal emulator for Windows. I still don't want to install a unix like environment just to have a terminal. I still don't want tabs in my terminal, lots of windows works just fine. I still need X11 forwarding so I can run programs on remote systems and display them on Windows (VcXsrv is an easier to get going X server than others I've used on Windows).
I might like to have something that can do whatever magic so I can gcloud and aws auth on my remote machine without cutting and pasting giant urls and auth blobs to and fro all the time; but I'm using a auth token that needs to stay connected to the windows machine. In a more integrated corp environment this would probably be keberos/active directory/magic?
(But yeah I'm still using putty, too)
I'm not really a fan of cmd or powershell, although I guess I could use them in a pinch. Wouldn't look like what I'm used to though. :p
What was meant is Windows Terminal
So I'm not using Putty since I guess ~ 2018 or so. Not insisting other should stop using it, of course.
Are there any better alternatives?
Then there's things like x11-style copy-paste.
I still use putty because it does what I need for it to do. No need to change just because MS has their own terminals application, which besides I far from trust.
But there's also trust in the rely on sense. Which at least I try to compartmentalize. I can trust Microsoft (or Google) to make an OS I can rely on to run other people's apps. If Microsoft or Google want to provide apps, they'll be evaluated as they are, not with a bias because the OS provider shipped them.
Apple routinely holds back changes for a .0 release for advertising reasons. This means that they routinely have big releases that break everything at once. Bugs could come from 4 or 5 different sets of changes. But if they spread out changes… bug sources would be way more easy to identify.
And bug fix velocity going up could mean people stop treading water on bugs, and actually get to making changes to avoid entire classes of bugs!
Instead, people think the way to avoid bugs is to avoid updates, or do it all at once. This leads to iOS .0 releases being garbage, users of non-rolling release Linux distros to have bugs in their software that were fixed upstream years ago, and ultimately to make it harder to actually fix bugs.
I do regularly install updates on my (Linux) desktop/laptop because guess what? It consistently works exactly the same afterward. Occasionally new formats like jxl images just start working everywhere or something. But otherwise it has just continued to work unchanging with no fanfare for the last decade or so. It's amazing to me how much higher quality in that way volunteer software is compared to commercial software.
If you want things not to break, you must slow down.
It isn’t reasonable to ask for these two things at once:
* lots of change
* stability
The current milieu seems dramatically skewed toward churning out low-value changes without sufficiently considering the impact to stability, causing frequent breakage, and resulting in net negative value.
Unless you mean, having thin clients use SSH as opposed to directly running serial cables throughout a building to VT100 style hardware terminals, and therefore being vulnerable to eavesdropping and hijacking?
But I think when we talk about TTY we mostly don’t refer to that kind of situation.
If someone talks about TTY today, I assume they mean the protocol and kernel interfaces being used. Not any kind of physical VT100 style serial communication terminals.
> I wrote the initial version of SSH (Secure Shell) in Spring 1995. It was a time when telnet and FTP were widely used.
> Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.
Emphasis mine.
Cheers.
rsh was common on internal networks, but almost never used on the wider Internet. telnet was everywhere all across the net.
ssh was a revelation and it replaced telnet and authenticated/non-anonymous ftp primarily.
And also sometimes rsh, but less importantly.
The command line options were almost identical for an easy switch. ssh even respected the .rhosts file! Last time I checked, that functionality was still in place.
Both the rlogin-family of commands and the telnet/ftp-family were in use across the Internet, certainly in cases where Kerberos was used. I would think telnet was more common, certainly so outside the UNIX sphere of influence, but things like Kermit also existed.
They all got SSL-encapsulated versions in time, but Kerberos solved authentication for free, and for the simpler use cases ssh had already taken over by then. And in the longer run, simple almost always wins!
ssh solved the "pass credentials in cleartext over untrusted networks" problem. Consequently it replaced telnet and ftp. It also duplicated the functionality of rsh and rcp, so those protocols became irrelevant. But that was not the important goal.
> Kerberos solved authentication for free,
This made me laugh. Kerberos didn't do anything for free. :)
Even in Athena, Kerberos had reliability problems. In the wider world, it was very hard to find a well-managed Kerberos implementation. Things are different now!
Eg: http3 support was stabilized with 1.25.1 , which came out June 2023.
I'm not sure about that, for anything besides static resources, given the rate at which various vulnerabilities are found at and how large automated attacks can be, unless you want an up to date WAF in front of everything to be a pre-requisite.
Well, either that or using mTLS or other methods of only letting trusted parties access your resources (which I do for a lot of my homelab), but that's not the most scalable approach.
Back end code does tend to rot a lot, for example, like log4shell showed. Everything was okay one moment and then BOOM, RCEs all over the place the next. I'm all for proven solutions, but I can't exactly escape needing to do everything from OS updates, to language runtime and library updates.
That and a small collection of other things are standards based and not going though changes.
I have not. It is quite the niche problem. Mostly because web performance is so bad across the board that saving a few milliseconds just isn't meaningful when your page load takes more than a second and mostly is stuck in javascript anyway. Plus everybody just uses cloudflare and having that CDN layer use whatever modern tech is best is very much good enough.
I now believe that every piece of software should be shipped as a container to avoid any system library dependencies.