I guess it's worth checking if those names point to the expected binaries, but I also think it would be highly unlikely they would be anything else than just /usr/bin/ssh and /usr/bin/ssh-agent.

I highly doubt businesses would have been this fast in making the switch.

Well that's exactly the worry. Why shouldn't it be? It is their business and livehood.

As if taking down the systems is the biggest cybersecurity threat a company might have.

A great git integration can work well in an editor. I use Magit in Emacs, which is probably as full-featured Git-client as there can be. Granted, for operations such as cherry-picking or rebasing on top of a branch or git reset I most often use the command line (but Magit for interactive rebase).

But editor support for version management can give other benefits as well, for example visually showing which lines are different from the latest version, easy access to file history, easy access to line-based history data (blame), jumping to versions based on that data, etc.

As I understand it vscode support for Git is so basic that it's easy to understand why one would not see any benefits in it.

Zooming and panning a pdf is arguably more comfortable with higher frame rate.

Would that kind of provision allow me to have my code removed from a git repository history, if that git repository is hosted by a company?

I think the second point is the biggest for me: it's almost like Canonical wanted to have a single dominant store for apps, as the ecosystem they are building supports only one. And, apparently, that one server is also closed?

So if you try to make an alternative source and give instructions to people how to configure their snap installation to use it (I found this information very hard to find for some reason..), your "store" probably won't have the same packages Canonical's has, so users won't be able to find the packages and I imagine updates are also now broken?

Contrasting this with flatpak: you just install apps from wherever. Or from flathub. Or your own site. Doesn't matter. No business incentive behind—built into the tools—to make everyone use flathub.org.

And how about the actual speeds they are used with? Another poster suggested the maintenance costs of traditional speeds skyrocket as speed increases, while maglev doesn't really have a lot of stuff that wears down in the first place.

Try od (or hd) to compare short files precisely visually.

The JavaScript sent to the client can check if the resources are loaded.

I think I could easily enjoy the gesture, however it's way too easy to trigger. It's like a one centimeter movement on a tablet. E.g. the Android app switcher needs a much bigger movement to trigger app closing.