Vlákno názorů k článku Chrome a Firefox tlumí podporu FTP a plánují ji úplně ukončit od Kamui - Problém je, že za FTP není žádná plnohodnotná...

Výkon je implementační problém v OpenSSH, nedávno jsem to tu rozebíral v článku včetně řešení.

Ano, řešení "flákni na to third-party záplatu jako kráva a zkompiluj si to sám" je většině uživatelů na dvě věci. (I v Gentoo to je za trest, protože pokud je nějaká bezpečnostní díra v SSH, tak se prostě vydá nová verze bez toho HPN patche. Nevím, kolik lidí chce čekat na opravu díry u věci typu SSH do doby, než se upraví HPN patch.)

Ostatně vyjádření maintainerů z OpenBSD, že je výkon nezajímá, asi dost jasně napovídá, že tudy cesta k hledání náhrady za FTP zrovna nepovede.

To je problém při 0-day rozhodnout, jestli chceš výkon nebo bezpečí a pokud zvolíš to druhý, tak na pár dní zpomalit přenos?

Ano, pokud na tom výkonu závisí produkční prostředí, tak to je opravdu velký problém.

Pokud na výkonu jednoho stroje (nebo několika strojích) ždímaným nadoraz stojí produkce, není ten velký problém ve výkonu SSHFS, ale někde trochu jinde. A až ten stroj jednou klekne, to teprve bude sranda.

Přestaň už blábolit, přečti si ten článek a najdi si nějaké benchmarky. Ten výkonnostní rozdíl je při nějaké "vyšší" latenci řádový. Krom toho se vůbec se nejedná o to, že je "jeden stroj ždímaný nadoraz", ale že prostě přes normální OpenSSH na lince s latencí v řádech desítek ms víc těch dat neprocpeš, ani když se postavíš na hlavu a u toho budeš nohama žonglovat s vajíčkama. Ta linka - při stejném workflow - prostě zůstane nevyužitá, abys ty data přenesl za stejnou dobu, musel bys je rozsekat a rozdělit tu práci na desítky současně probíhajících přenosů.

Petre, zkuste si nekdy sshfs treba na gigabitove lince a srovnejte to s ftp... a pak si to zkuste 1000x paralelne... doporucuji si u toho pustit treba top a iftop a pochopite.