Chápu, že hlavně kvůli konkurenčnímu boji musí přidávat podporu i pro takovéhle formáty...
Ale pořád nechápu, proč zrušili například podporu ftp (obecné prohlášení o "nezabezpečenosti" protokolu jsem četl, ale to není důvod ke kompletnímu odstranění podpory celého protokolu - podívejte se, kolik zrcadel linuxových distribucí běží na http a ověření integrity dat se řeší přes checksumy a podpisy)
FTP je mrtvy protokol. Smirte se s tim :-) Ono to neni jen o (ne)bezpecnosti, nesmime zapominat ze zijeme v prostredi, kde komunikace je mrsena NATy... a ono zrovna NATu v kombinaci s FTP nebyva vzdy dokonale fungujici dvojka. HTTP temi neduhy netrpi... i kdyz samozrejme s ohledem na ochranu soukromi se i u tech zdrcadel postupne na HTTPS prechazi, zeano.
Se tam kvůli NATu přidalo jedno zatržítko navíc "Pasivní režim".
A funguje to dobře.
S rozšiřováním IPv6 dává FTP zase smysl.
A co to je obecne? FTP je na pamatovo obmedzenych zariadeniach pouzitelnejsie, ako ked METAR zacal presmerovavat http na https.
Ono i avioniku je zadouci cas od casu obmenit za modernejsi reseni. S prechodem na 8.33 kHz kanalovani na leteckych frekvencich se zrovnatak musely vymenovat treba i vysilacky, zeano... a svet se kvuli tomu nezhroutil :-) (a taky se vas nikdo neptal). I u METAR dat je zadouci zabezpecit nejakou integritu prenosu - a te s FTP bez dalsiho nedocilite.
Ad „je zadouci zabezpecit nejakou integritu prenosu - a te s FTP bez dalsiho nedocilite“
SSL (a.k.a. TLS) je sice asi nejrozšířenější způsob zabezpečení integrity a důvěrnosti na síti, ale zdaleka ne jediný. Zabezpečit se to dá i na úrovni IP nebo Ethernetu. Pak člověk může klidně používat telnet a FTP nebo (nešifrované) HTTP.
Ethernet ani IP samo o sobe nic neposkytuje. Jisteze, jsou tu jiste "nadstavby", ovsem ty pri argumentaci "omezenymi zdroji" trpi stejne jako TLS, zvlast pokud se bavime o pouziti algoritmu do 21. stoleti a ne nejakych parodii na sifrovani typu RC4.
Pokud se nějaký protokol používá a FTP se, bohužel, používá stále docela dost, tak to asi mrtvé není. O tom prostě Vy nerozhodujete, smiřte se s tím.
To mate pravdu, ja o vyrazeni jeho podpory z Firefoxu (nebo i Chrome) nerozhodoval ;-) Byla kolem toho pred ctyrmi lety boure ve sklenici vody, ale proste se tak prihodilo.
Lenze ludia, ktori ftp pouzivaju, maju na neho svojho oblubeneho klienta. To, ze browser otvaral url s ftp:// v read-only rezime a vyrenderoval html so zoznamom suborov ako v devatdesiatkach bola len otrava. Praca s ftp klientom je predsa len pohodlnejsia.
V čem je "otrava", že něco prostě vypíše seznam souborů? Co je to za nesmysl? Otrava spíš je, když chci něco stáhnout z FTP a místo toho, abych prostě klikl na odkaz a stáhl to stejně, jako strahuju věci přes HTTP se mi někde startoval nějaký další klient a tomu jsem zvlášť říkal, že něco potřebuju odněkud někam stáhnout.
12. 9. 2025, 14:42 editováno autorem komentáře
Kdy se vám to naposledy stalo, že jste měl z webu odkaz na FTP? Já si to pamatuju snad jen z webů Mozilly a Debianu, ale to je tak patnáct let.
12. 9. 2025, 14:59 editováno autorem komentáře
Zrovna před pár týdny, cosi kolem čínského RISCV SBC (už nevím jestli to byl SiPeed nebo OPi RV, tak nějak střídavě na ně nadávám a nechávám je další čtvrtrok v šuplíku jestli to už nebude lepší) bylo jen ftp.
Já FTP nepoužívám, je mi to jedno. Spíš se snažím dopátrat toho, co vede někoho k tomu, že začne vyprávět něco o tom, že je to "otrava". Přitom takový výkřik naprosto postrádá smysl už z logiky věci a UX/UI.
Pretoze z ftp / sftp / atd zvycajne chcem stiahnut viac ako jeden subor. Casto cely adresar.
V normalnom klientovi to nie je problem, vybrat cely adresar a tahat (browser do neho vosiel a zobrazil jeho obsah), nie je problem vybrat viacero suborov a nechat ich tahat vsetky (v browseri bolo treba klikat po jednom a pokial mal server nejake limity, tak pockat kym sa dotiahne a potom klinut na dalsi, nejaka fronta neexistovala vobec). Nedalo sa uploadovat vobec. Ak bolo treba meno a heslo, tak password manager tam nefungoval.
Takze to je otrava. Browser otvoril ftp url a ked clovek chcel nejaky komfort, musel robit copy paste url. Teraz rovno otvori klienta co si zaregistroval url schemu a je to daleko komfortnejsie.
Aha. Takže vy víte, co kdo dělá "obyčejně"? Vy to chcete. Nebo na to máte nějaký sofistikovaný průzkum? Nemáte nic. Máte jen svou dojmologii.
Asi pred mesicem jsem pracoval s vestavenym zarizenim, ktere ve svem webovem rozhrani otvira ftp adresar po vyberu polozky "logs". Je treba si uvedomit, ze FTP bylo velmi rozsirene a spousta zarizeni z te doby je porad v produkcnim provozu.
Vsak vam nic nebrani pouzit specializovaneho klienta. Proc by se melo vsechno za kazdou cenu cpat do prohlizece?
Vsak vam nic nebrani pouzit specializovaneho klienta. Proc by se melo vsechno za kazdou cenu cpat do prohlizece?
Nejspis jste se ztratil ve vlaknech - ja jsem reagoval na prispevek, jehoz autor se ptal, kdy naposledy jsme narazili na ftp odkaz na webove strance. K tomu, jestli to ma ci nema byt ve Firefoxu jsem se vubec nevyjadroval, protoze FF ani nepouzivam.
Je to otrava, ale tak na jednu klavesovu skratku mam terminal, napisem curl a hotovo. Na desktope to nie je problem.
Nevím, v čem to měla být „otrava“. Na základní použití to stačilo tzn. výpis adresáře a hlavně stažení souboru, když odněkud vedl odkaz na ftp://example.com/.../soubor.tar.gz.
Mozilla bohužel šetří a odstraňuje na nesprávných místech – FTP, RSS… Do toho neustálé předělávání adresního řádku (sotva jsem si zvykl na výběr vyhledávače pomocí šipek, tak to zrušili) a dalších věcí. S Thunderbirdem to jde taky od desíti k pěti. Rád bych to používal dál, ale každá další verze něco rozbije nebo odstraní. U některého softwaru se člověk na nové verze těší, ale tady ne.
Na toto zakladni pouziti to mnohdy staci prepsat na http:// ... a bude to fungovat lepe a nebudete resit, ze v nejakem korporatu maji hloupeji nastaveny firewall.
RSS vyresite pluginem/rozsirenim. Pokud jej teda potrebujete - ono to proste kazdy taky nepouziva. A v tomhle ohledu mi prijde lepsi nemit software jako neohrabany moloch, co umi "vse" - i kdyz to realne vetsi cast lidi realne nepouzije. Cim mene toho je, tim mensi prostor i pro pripadne utoky.
Jde o to, že např. to RSS napomáhá decentralizaci internetu a snižuje závislost na velkých internetových korporacích typu Google nebo Facebook. Od organizace jako Mozilla bych čekal, že tohle bude podporovat a ne že to naopak pohřbí. Byť by ta podpora byla symbolická třeba v tom, že na liště na uživatele svítí ikonka a že si může přímo v prohlížeči zobrazit náhled toho RSS/Atom kanálu. Navíc už to měli implementované, takže nelze argumentovat tím, že na to neměli kapacity – pracnost navíc naopak znamenalo odstranění této funkce.
Jenže, když je Google jejich hlavním sponzorem, tak co taky čekat, že?
Jen ono nestaci jen podpora na strane prohlizece - ono to hlavne musi podporovat weby. A rozhodne neni pravidlem, ze by bylo RSS vsude a i tam kde je ta implementace obcas stoji... za starou backoru. A motivy te (ne)podpory muzou byt ruzne - ono provozovatel se snazi dostat uzivatele na svuj web, pripadne do sve vlastni aplikace (protoze dnes je cool & in mit vlastni aplikaci na kazde uprdnuti).
Konspiracni teorie o sponzorech bych s dovolenim vynechal. Mit neco implementovane je jedna vec. Ale ten kod musi take nekdo prubezne udrzovat - coz pracne byt muze a casto byva. A v tom byva ten zakopany pes. A to neni jen o Mozille - staci se podivat na linuxovy kernel, kde jej take "jiz naimplementovane" veci proste opousti, protoze se nenajde nikdo, kdo by byl vubec ochotny a schopny tu danou komponentu skutecne udrzovat.
O údržbě kódu něco vím, často se u zákazníků starám o kód starý i několik desetiletí…
Jenže Firefox (Chromium je na tom +/- stejně) má přes 20 milionů řádků kódu. Máš představu, kolik se ušetřilo odstraněním RSS nebo FTP? Ten problém je někde jinde, je rozprostřený skrze celý kód, je to dané dlouhou historií a stylem, jakým to je psané. Reálnější je tedy bohužel ta „konspirační“ teorie.
Jde o to, že např. to RSS napomáhá decentralizaci internetu...
RSS Mozilla podporuje v Thunderbirdu, kde se dají přidávat sledované kanály a funguje to podobně jako další emailová schránka, kde se jeden RSS kanál podobá složce s obsahem dle aktualit toho kanálu.
14. 9. 2025, 09:08 editováno autorem komentáře
A jen tak mimochodem, i dle Shodanu je za poslednich 24 mesicu videt propad o skoro 30%. Statistika nuda je, ma vsak cenne udaje.... :-)
Jestli je FTP mrtvé, tak co je pak náhrada? Podle mně žádná ekvivalentní náhrada v mnoha případech neexistuje.
Tak celkem bezne se pouziva SFTP, ktere narozdil od FTP funguje pres jedno TCP spojeni (a ne ta opicarna s PASV ve FTP ad vyse, se kterou - zvlaste korporatni - firewally problemy proste mivaji). Pokud je tedy rec o ciste souborove orientovanych ekvivalentech. Alternativy rozhodne existuji, ze se jen "nechce" a radsi se pouziva 54 let stare reseni nedokazuje jejich absenci.
SFTP má velký problém s výkonem. Ano, vím že existuje HPN patch, ale to nepovažuji za řešení, to je rovnák na ohýbák. Navíc s SFTP musíte mít přístup k shellu a udělat chroot pro uživatele také nebylo triviální.
Velky problem s vykonem? To take uplne nemusi byt pravda.
Tak nevím, těch korporátních firewallů mi prošlo rukama celkem dost, a počínaje starou Altavistou FW na starém DECu, a zrovna ten nenáviděný ftp (na standardním portu) problém nebejval s PASV nikdy...
Dneska je nutnost šifrovat, aby ti nikdo neodposlouchával hesla, nevkládal do dat svůj spyware a nešmíroval.
Na soukromé věci tedy SFTP. Na veřejné i soukromé WebDAV. Oba protokoly umí procházet adresáře, mají lepší specifikaci než FTP (tam byl formát výpisu adresáře spíš jen konvence), dají se připojit jako souborový systém, mají podporu v různých aplikacích typu LibreOffice, takže si dokument otevřeš i uložíš přímo, WebDAV umí i verzování, oba jsou jednoduše klient-server protokoly nad jedním TCP portem (ano, u FTP můžeš použít pasivní režim).
Přesto si nemyslím, že by se FTP muselo odstraňovat tam, kde už je dlouhé roky implementované. Hodně lidí má (asi spíš mentální) problém WebDAV nasadit, takže na serveru buď nechají běžet FTP nebo přejdou na obyčejné HTTP, což je v určitém směru zhoršení oproti FTP.
Viz vyse - "nechat kod" znamena ho prubezne udrzovat a resit jeho funkcnost ve vztahu k dalsim komponentam/castem. To je holt nevyhoda velkych softwarovych molochu, co v ramci jedne te splacane obludy delaji vsecko mozne.
S ohledem na mkv vs webm to není tak přelomová věc, skoro až nechápu, proč to trvalo tak dlouho. Matroška je tu s námi už enormně dlouho, já na ní přešel někdy v roce 2002. Ale ono to ani není tolik podstatné, důležitější jsou formáty stop a tam už to celé naráží na sw patenty, bohužel.
> Ale ono to ani není tolik podstatné
Mě vždycky strašně štve, že MP4 nejde přehrávat když ještě není hotové (tj. kóduju a chci se podívat jestli začátek vypadá rozumně), a i když je hotové, tak se ještě musí udělat harakiri (přesunout nějaký index na začátek, což znamená přepsat celý soubor, a pokud nedokončený soubor někam rsyncuju, tak ho to pak přenáší celý znova, protože to nezvládne najít ty změny), aby šlo přehrávat bez stažení celého / podpory seekování.
Nebo dělám něco blbě?
+faststart rezervuje místo na začátku souboru a po dokončení kódování tam zapíše potřebné hlavičky. Je to proto, že data do hlaviček jsou kompletní až po zpracování souboru.. Tzn. pro přehrávání nebo sync rozdělaného souboru to nepomůže.
MP4 by slo prehravat i s indexem na konci - od toho prece existuje v HTTP Range: header, ne? (tj. to, co dela wget -c ). Ze to neudela prohlizec.. je spis chyba implementace, nebo omezeni na strane serveru (zakaz tech ranges, nebo nesmyslny kontroly refereru a dvojiho stahovani).
(MP4 / QTFF / ISOBMFF jsem implementoval a neni tam nic divneho/tezkeho, nez zase jenom linost na strane jinych programatoru, udelat ten seek / subrequest)
Co se prehravatelnosti tvoreneho polotovaru tyka.. kodujte do TS - ten se prehrava jako stream a seekovani v nem probiha aktivnim hledanim hlavicek ramcu, a az se vam vysledek bude libit, tak ho jednoduse premuxujte do MP4/MOV (bez komprese, jen stream copy, na rotacnim disku klidne do tempu v /dev/shm)