3 ms·
You're actually making the opposite argument that you think you're making: if the scp command stops working, from a "corporate" perspective, from all intents an
by disruptiveink 5y ago
You're actually making the opposite argument that you think you're making: if the scp command stops working, from a "corporate" perspective, from all intents and purposes, it means that "our server no longer works with scp due to an update". Regardless of implementation details, the opposite will then happen: whoever is in charge will request for "SCP to be fixed", which will actually mean turning on SFTP support.
Removing options from "corporate" users usually results in saner choices being made, because you stop being able to bikeshed the implementation details. People have a server and they need a way to transfer files. If you have two protocols that can be used, arbitrary decisions will be made. If the readily available tools all break, there is no more decision to be made – whatever needs to be enabled will be enabled.
- pilif 5y agoif regular ssh is available, nothing stops people from building pipes with tar on both ends. This will be integrated into additional tools (future "show HN - scp replacement written in $FANCY_LANGUAGE that works even when sftp is disabled") and will be the "new way" of doing things because it won't require any configuration change on the server. Never underestimate the inertia of server configurations.
- nybble41 5y ago> (future "show HN - scp replacement written in $FANCY_LANGUAGE that works even when sftp is disabled") Too late: https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol https://en.wikipedia.org/wiki/Files_transferred_over_shell_p... In KDE this is implemented as a standard protocol handler ("ioslave") and you can access it from most KDE apps using URLs like "fish://user@server/": https://docs.kde.org/trunk5/en/kio-extras/kioslave5/fish/index.html https://docs.kde.org/trunk5/en/kio-extras/kioslave5/fish/ind...