Selten so viel Stuss gelesen...

[Käx]

"Begründet wird dies mit Sicherheitserwägungen und der prinzipiell schwierigen Pflege von FTP, das den heutigen Anforderungen zum Dateitransfer nicht mehr genügt."
Sicherheit: FTPS mit TLS 1.2 ECDHE AES-GCM schlagmichtot...
Pflege: Viel simpler als FTP geht nicht...
Anforderungen: Ja, da stimme ich zu... Eine TCP Verbindung pro Übertragung, sprich PASV, is veraltet und führt zu mieser I/O Performance. Multiplexing FTP wär' a Hit! Alles auf Port 990 und gut is. Da eh verschlüsselt reicht eigentlich UDP.

Fakt: Nirgendwo gibt's so wenig Overhead wie bei FTP.

Dass irgendwelche Load-Balancer keinen Support für FTP haben is eine andere Geschichte, jedoch kein Fehler des Protokolls. Gerade bei FTP liese sich durch dynamische PASV Anweisungen die Last spielend verteilen ohne dass man am FTP-Server rumfummelt.

HTTPS taugt ned wirklich für File-Transfer -und damit meine ich vA Uploads. Jeder, der damit mal zu tun hatte, weiß das.

SFTP löst so manche Probleme, is aber technisch afaik auch nur getunneltes FTP.

Naja, Karten auf'n Tisch. Mir is egal, wie die Ihr Zeug verteilen. Aber bitte ned mit irgendwelchen fadenscheinigen (faktisch falschen) Argumenten FTP schlechter reden als es is.

[picaschaf]

Schön, dass du einige der Pfuschlösungen des FTP Protokolls aufgezählt hast. Und warum ist nun FTP aus deiner Sicht geeigneter für diesen Anwendungszweck als ein HTTPS Download mit dem alle Standardtools klarkommen?

[freebyte]

Käx schrieb:
--------------------------------------------------------------------------------
> Pflege: Viel simpler als FTP geht nicht...
> [...]
> Fakt: Nirgendwo gibt's so wenig Overhead wie bei FTP.

FTP hat Vorteile (einfache implementierung eines Clients, permanenter Kommandokanal, zeilen- und textorientierte Verarbeitung) die es für kernel.org nicht ausspielen kann.

Da geht es entweder darum, einen grossen tarball abzuholen oder Teile des Source zu synchronisieren.

Für ersteren Fall kann man die sowieso bestehende http-Infrastruktur incl. kommerzieller HTTP-CDNs mitnutzen und für den zweiten Fall nimmt man besser sowas wie git oder rsync.

Hier gibt es also keinen wirklichen Grund, im weltweiten Distributionsnetz noch ein weiteres Protokoll mitzuschleppen.

> Naja, Karten auf'n Tisch. Mir is egal, wie die Ihr Zeug verteilen. Aber
> bitte ned mit irgendwelchen fadenscheinigen (faktisch falschen) Argumenten
> FTP schlechter reden als es is.

Dass die Begründungen des Teams nicht sonderlich kompetent klingen, dem stimme ich zu.

fb

[mapet]

Käx schrieb:
--------------------------------------------------------------------------------
> SFTP löst so manche Probleme, is aber technisch afaik auch nur getunneltes
> FTP.
>
"DESCRIPTION
sftp is an interactive file transfer program, similar to ftp(1), which
performs all operations over an encrypted ssh(1) transport. It may also
use many features of ssh, such as public key authentication and
compression. sftp connects and logs into the specified host, then enters
an interactive command mode."

Es ist ähnlich, hat aber mit ftp nix zu tun, da es komplett über ssh läuft.

[Bonita.M]

> Sicherheit: FTPS mit TLS 1.2 ECDHE AES-GCM schlagmichtot...

Und auf welher PKI setzt das auf?
HTTPS verwendet die im Browser installierten Zertifikate.

> Pflege: Viel simpler als FTP geht nicht...

FTP macht Probleme mit Firewalls, es braucht explizite Unterstützung für NAT und FTPS funktioniert mit keinem vom beidem.

> Anforderungen: Ja, da stimme ich zu... Eine TCP Verbindung pro Übertragung,
> sprich PASV, is veraltet und führt zu mieser I/O Performance. Multiplexing
> FTP wär' a Hit! Alles auf Port 990 und gut is. Da eh verschlüsselt reicht
> eigentlich UDP.

Wenn Du einen Server mit Bottleneck am Server hast, dann gibst Du mit mehreren TCP-Kanälen einzelnen Clients mehr Priorität. Das wäre ungerecht und das will man nicht.

> Fakt: Nirgendwo gibt's so wenig Overhead wie bei FTP.

HTTP hat auch kaum Overhead - und geht durch jede Firewall.

> HTTPS taugt ned wirklich für File-Transfer -und damit meine ich vA Uploads.

HTTP kennt PUT und Du kannst ausgehend von einem Formular Datei-PUTs machen.
Und ansonsten setzt WebDAV auf HTTP PUT auf.

> Naja, Karten auf'n Tisch. Mir is egal, wie die Ihr Zeug verteilen. Aber
> bitte ned mit irgendwelchen fadenscheinigen (faktisch falschen) Argumenten
> FTP schlechter reden als es is.

Das FTP-Protokoll hat einfach ein völlig vergurktes Design.