|
|
Subscribe / Log in / New account

GDB 13.1 released

GDB 13.1 released

Posted Feb 20, 2023 15:25 UTC (Mon) by ianmcc (subscriber, #88379)
Parent article: GDB 13.1 released

Wow, FTP still exists? I notice that Firefox seems to have removed support for it.


to post comments

GDB 13.1 released

Posted Feb 20, 2023 19:15 UTC (Mon) by madscientist (subscriber, #16861) [Link] (2 responses)

You can also use https://ftp.gnu.org/gnu/gdb/

I switched to this for my software announcements a long time ago: GDB should do the same. Even better is https://ftp.gnu.org/gnu/gdb/?C=M;O=D so results are sorted by descending modification date (newest first).

GDB 13.1 released

Posted Feb 21, 2023 20:27 UTC (Tue) by IanKelling (subscriber, #89418) [Link] (1 responses)

Thank you madscientist. I work at FSF and help maintain ftp.gnu.org, and it has been many years since we asked all GNU packages to replace ftp: with https: in announcements and current documentation.

GDB 13.1 released

Posted Feb 21, 2023 21:39 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Yes, thanks for your work Ian, very appreciated.

I mentioned this to Joel on the gdb mailing list so hopefully the next GDB release will provide https in addition to, if not replacing, ftp. Cheers!

FTP

Posted Feb 21, 2023 0:21 UTC (Tue) by skissane (subscriber, #38675) [Link] (3 responses)

FTP is dying for most use cases, yes. It isn't fundamentally flawed – plain FTP is insecure, but FTPS isn't, yet few people implemented it; using two separate ports (one for control, the other for data) is a problem, but there are solutions (e.g. with FTPS you can share the same port for both, if you use TLS session resumption). The whole "corrupting files by transmitting them in ASCII mode" business was just FTP clients with stupid defaults and nobody would change those stupid defaults, but nowadays the vast majority of FTP clients default to binary mode.

One area in which FTP is still the best option however – surviving mainframe and minicomputer systems (which are greatly diminished from their former glory, but still with us, and I'm sure at least some of them will still be here, even further diminished, in 20 years time). Most of those systems have file systems which support "record-oriented files", in which the filesystem is aware of and enforces the division of the file into records, either fixed length (with the record length defined at file creation time) or variable length (each record starts with a header giving its length, and sometimes also some flags). Examples of such systems include OpenVMS, non-Linux IBM mainframe operating systems (z/OS, z/VM, z/TPF and VSEn), IBM i (formerly AS/400), and most surviving non-IBM mainframe lines (Unisys, Fujitsu, Atos/Bull). If you want to transfer a record-oriented file from OpenVMS to z/OS, keeping the record boundaries intact – the FTP protocol can do that out of the box, HTTP(S) or SFTP don't support that.

Another area in which FTP seems to still be hanging on is scientific computing, where GridFTP is used to transfer massive data sets. GridFTP is a bunch of extensions defined to the classic FTP protocol. GridFTP is still actively used, although it has seemed to have fallen in popularity ever since its main backer (Globus) transitioned from being an open source project to a paid SaaS offering with proprietary clients. IBM Aspera performs much better (and isn't based on FTP at all), but costs a lot more $$$$.

FTP

Posted Feb 21, 2023 12:40 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (1 responses)

FTP _is_ fundamentally broken:

• Directory listings are the output of "ls". Have you ever tried having files owned by users or groups with spaces in them? Say… "Domain Users". Clients fall flat on their face trying to parse the output as they have to split fields by whitespace, which obviously fails with such user & group names.
• FTPS is even more broken (assuming you mean encrypting the control connection, too, not just the data connection). With FTPS you can only use the passive mode, and your server must not be behind any kind of NAT. Why? Because no firewall device can parse the encrypted control connection & can therefore not determine the dynamically-allocated port numbers the server & client use.

Sure, you can use it in certain circumstances, but it's not a general-purpose solution.

FTP

Posted Feb 22, 2023 7:59 UTC (Wed) by epa (subscriber, #39769) [Link]

To be fair, directory listings in http are even more broken. Typically the server will send an HTML page listing the files, which you have to parse somehow.

FTP

Posted Feb 21, 2023 17:55 UTC (Tue) by eduperez (guest, #11232) [Link]

The last mainframe I worked on (up to 6 months ago) used XCOM for all data transfers; in 25 years, I never saw FTP being used around it.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds