It is partly the web/HTTP eating everything but also that FTP is legitimately a bad protocol and is less tolerant of horrid shit going on in layers below it (like NAT) than HTTP is.
http://sdocs.readthedocs.io/en/master/sdocs/ftpserver/vsftpd...
Strictly speaking there's nothing stopping someone from writing an anonymous sftp server that lets anyone log in as a 'guest' user or similar - it's just that nobody has (as far as I'm aware).
git:// is usually unencrypted (people have run it over TLS, but not commonly).
When we would perform a rolling reinstall of the entire worker cluster (~5500 1U pizza box servers), we would use a custom installer that would utilize Bittorrent to retrieve the necessary RPMs (Scientific Linux) instead of HTTP; the more workers reinstalling at once, the faster each worker would reinstall (I hand wave away the complexities of job management for this discussion).
I'm not super familiar with IPFS (I've only played with it a bit to see if I could use it to backup the Internet Archive in a distributed manner), but I'm fairly confident based on my limited trials that yes, you could build a Debian installer CD to fetch the required packages from an IPFS mirror. No need to even have the file index locally. You simply need a known source of the file index to retrieve, and the ability to retrieve it securely.
(Granted you can turn you can stop this client-side, but it's worth noting that your SSH client will generally identify you to a server on connect.)
The user also by default gets allowed to set up tunneling which would allow anonymous users to use your network address.
Nonsense. http is exactly like anonymous ftp and it does a much better job of it. Pretty much every anonymous ftp site started also serving their files via http decades ago -- which is why ftp is no longer needed.
Case in point: Debian makes all these files available over http. This isn't going away.
ftp://ftp.debian.org/debian/
Not quite, ftp CLIENTS have mget. The ftp protocol has absolutely no awareness of mget. In fact, ftp is terrible at downloading more than one file at a time because it has no concept of pipelining and keepalive, both things that http supports.
With a nice multi protocol client like lftp, http directory indexes work just like an ftp server:
$ lftp http://http.debian.net/debian/
cd: received redirection to `http://cdn-fastly.deb.debian.org/debian/'
cd ok, cwd=/debian
lftp cdn-fastly.deb.debian.org:/debian> ls
drwxr-xr-x -- /
-rw-r--r-- 1.0K 2017-01-14 10:44 README
-rw-r--r-- 1.3K 2010-06-26 09:52 README.CD-manufacture
-rw-r--r-- 2.5K 2017-01-14 10:44 README.html
-rw-r--r-- 291 2017-03-04 20:08 README.mirrors.html
-rw-r--r-- 86 2017-03-04 20:08 README.mirrors.txt
..[snip]..
lftp cdn-fastly.deb.debian.org:/debian> mget README*
5315 bytes transferred
Total 5 files transferred
lftp cdn-fastly.deb.debian.org:/debian> lftp cdn-fastly.deb.debian.org:/debian> mirror doc
Total: 2 directories, 43 files, 0 symlinks
New: 43 files, 0 symlinks
1031755 bytes transferred in 1 second (678.7 KiB/s)
lftp cdn-fastly.deb.debian.org:/debian>
Yes, it looks like '/usr/bin/ftp' from 1970, but it's far far far more advanced than that.
rsync -r rsync://... ./
wget -r -A 'x.csv' https://example.org/
(where 'x' is an asterisk, but HN's formatting eats it)
More work, in the sense that it's more command line options to remember, I agree, but otherwise it's easier to integrate in scripts and much more flexible than mget.
(I don't miss FTP for the sysadmin side of maintaining those servers.)
a public facing httpd that uses the default apache2 directory index can be configured to , of course, allow anonymous access and with a log level that is neither more or less detailed than an anonymous ftpd circa 1999.
Modulo UI details, the common download-only public side of public FTP servers is a pretty similar experience to a pretty barebones file download web site. Anonymous file download web sites are, to put it mildly, not rare.
In the past, I've said that this extensible nature of HTTP+HTML is what made them so successful [6], but once specialized protocols began to falter, tunneling other semantics over HTTP became not just a niceity, but also a necessity (for a diverse set of reasons, like being blocked at a middlebox, being accessible from an the browser where most people spend their time, etc).
[1] http://www.iana.org/assignments/media-types/ [2] https://www.iana.org/assignments/link-relations/ [3] https://wiki.apache.org/httpd/DirectoryListings [4] http://nginx.org/en/docs/http/ngx_http_autoindex_module.html [5] http://stackoverflow.com/a/28380690 [6] https://news.ycombinator.com/item?id=12440783
What's not to like?
It's about cost, too. HTTP can be cached very efficiently, but FTP not at all. If I were the operator in charge and I had the choice between next-to-free caching by nearly anything, be it a Squid proxy, apt-cache or nexus, or no caching and having to maintain expensive servers, I'd choose HTTP.
FTP is not nearly as trivial, plus it's a stupid, broken protocol that deserves to die. The whole thing is a giant bag of hurt.
I agree with you, but FTP has one very valid use case left: easy file sharing, especially for shared hosting. FTP clients are native to every popular OS, from Android to Windows (only exceptions I know are Win Mobile and iOS), and there's a lot of ecosystem built around FTP.
There is SCP and SFTP but they don't really have any kind of widespread usage in the non-professional world.
Nope. Nope. Nope. Not easy. Not secure. Not user friendly. Not anything good. Have an iPhone and need to FTP something? Don't have installation rights on your Windows workstation and need to FTP something? Unpleasant if not confusing as all hell.
Dropbox or a Dropbox-like program is significantly easier to get people on board with.
Any "ecosystem" built around FTP is rotten to the core. Blow it up and get rid of it as soon as you can.
Some vendors insist on using FTP because reasons, but those reasons are always laziness. I can't be the only one that would prefer they use ssh/scp/rsync with actual keys so I can be certain the entity uploading a file is actually them and not some random dude who sniffed the plain-text password off the wire.
Windows explorer has FTP built into the shell. As does every other desktop OS.
If you care about file integrity, you want to out of band to verify the signatures on the binary anyway.
Dropbox is blocked in most commercial networks and offers no assurance of anything.
Versus drag and drop file to this page. There you go. It's uploading.
That's why I said Dropbox or a Dropbox-like service, of which there are hundreds. Microsoft SharePoint is but one example.
Type ftp://ftp-site/path/to/file. Drag and drop to your hearts content.
Windows has first-class support (obviously); but Samba gives Linux and BSD support that, in modern Desktop Environments, is exactly as good. Mobile devices don't tend to have OS-level support for it, but there are very good libraries to enable individual apps to speak the protocols (look at VLC's mobile apps.)
Even Apple has given up on their own file-sharing protocol (AFP) in favor of macOS machines just speaking SMB to one-another.
Yes, it's not workable over the public Internet. Neither is FTP, any more. If you've got a server somewhere far away, and want all your devices to put files on it, you're presumably versed with configuring servers, so go ahead and set up a WebDAV server on that box. Everything speaks that.
Uh, hell no. Never ever I'd expose a SMB server to the Internet. SMB is really picky when the link has packet loss or latency issues, plus the countless SMB-based security issues.
> Even Apple has given up on their own file-sharing protocol (AFP) in favor of macOS machines just speaking SMB to one-another.
TimeMachine still depends on AFP.
No, it doesn't:
https://developer.apple.com/library/content/releasenotes/Net...
I wonder if GP is pulling our legs about WebDAV. Yuck.
Yeah, nope. Dead out of the gate. Thanks for playing.
The GP comment:
> FTP clients are native to every popular OS, from Android to Windows (only exceptions I know are Win Mobile and iOS)
To rephrase: only 1/3 of mobile OSes support FTP.
Not working on iOS is like saying "Oh, this road doesn't work with German made cars. That's not a big deal, is it?"
https://panic.com/transmit-ios/
Searching the App Store I also see some apps for SMB, but I don't know whether they have document provider extensions.
FWIW, I'm not convinced that "web-based" is a better alternative for read/write file access, assuming you mean file manager webapps. No OS can integrate those into the native file picker, so you can't avoid the inefficiency of manually uploading files after changing them. WebDAV works pretty well though, if that counts...
Imagine a file transfer protocol that defines the command to list files in a folder, but does not specify the format of the response other that it should be human-readable.
https://www.ietf.org/rfc/rfc959.txt LIST and NLST commands for example. No way to get a standard list of files with sizes and modification dates. yay!
Oh, and the data connection that is made from the server to the client. That works wonders with firewalls of today.
It was an ok spec when it was invented, but today it's very painful to operate.
It's ironic that you mention cost and caching but lot of services used for software distribution of one kind of another (e.g. Github releases) are following the "HTTPS everywhere" mantra and HTTPS can't be cached anywhere other than at the client.
No. Nexus for example can certainly cache apt, as well as Squid can do if you provision it with a certificate that's trusted by the client.
Also, Cloudflare supports HTTPS caching if you supply them with the certificate, and if you pay them enough and host some special server that handles the initial crypto handshake you don't even have to hand over your cert/privkey to them (e.g. required by law for banks, healthcare stuff etc)
For Debian, packages are secured by PGP in combination with checksums so it's not relevant for them. The debian repos are often HTTP only.
IIRC WebDAV uses GET for retrieval, so the read parts can be cached by an intermediate proxy and the write part be relayed to the server.
Gopher generally avoids most of FTP's pitfalls and it is dead easy to implement.
[1] http://shows.howstuffworks.com/techstuff/what-was-gopher.htm
edit: thinking about it not sure I agree with the anonymous part considering the swarm can be monitored. the access log is essentially publicly distributed.
code; https://pypi.python.org/pypi/noauthsftp
handy for moving files around a network
Even though you can't have anonymous sftp you can have anonymous ftps.
But perhaps we don't care anymore. The web is gradually consuming all that came before it.