Tipuji, Google ho nepotřeboval a v otevřeném světě vytvoření nového protokolu zabere i 20 let (viz třeba ntp vs nts, první diskuze byly ještě v době sntp, první draft 2015, RFC8915 před pár měsíci).
Hromada poslední změn, které se udály na webových technologiích je inicializovaná velkými firmami v čele s Googlem.
FTP pro uživatele není důležitý a zastaral. Je to škoda, scp, rsync nebo sftp za mě není náhradata právě kvůli omezení rychlosti a velkému overhaedu.
Naprimo nikde. Tomu se rika praxe ktere se ve skole nenaucis, na zive nedoctes a u microsoftu ti reknou ze je to OK.
A pouziti mezi Prahou a Brnem coz je "u souseda pres chodbu" nepokladam jako use case "pres internet".
Minimalne bych zacal od SMB3 ktere je mnohem mene ukecane a jednodussi na primou komunikaci.SMB3.1.1 uz ma i slusnejsi zabezpeceni.
Meli jsme nejaky ipsec koncentrator ktery umel inteligentne prevadet ukecane SMB zpravy na mene ukecane ale nakonec to vyresila hruba sila - manazer rekl ze je to kravina vsechno se prevedlo na webdav.
Ale i tak je tam hodne stavovych zprav tam a zpatky k tomu si pripocitej delay ladeni mss/mtu, fragmentace a dalsi opicarny.
Je treba hodne potunit klient a server.
Jinymi slovy. Pokud napriklad z vule dabelskeho prumysloveho nemeckeho koncernu nemusis jeste tohle tlacit pres privatni MPLS, tak to nechces.
21. 1. 2021, 16:08 editováno autorem komentáře
Nikoli, myslím přesně to, co jsem napsal. Reaguji totiž na text komentáře uživatele kamui.
Nedávno jsem zjistil, že busybox obsahuje jednoduchý webový server, takže jím jde jednoduše (i když bez seznamu souborů, ten by se musel vyrobit např. skriptem) nasdílet adresář. Např.
busybox httpd -p 8080 -h ~/soubory
,
v prohlížeči pak
http://můj_server.de:8080/soubor1.zip
...
Mimochodem, když už to tady protřepáváme...:
Hledal jsem takové jednoduché sdíledlo souborů, které by umožňovalo autentizaci (virtuálních uživatelů) a adresáře pro jednotlivé autentizované uživatele s případným jejich nahráváním souborů. Našel jsem pouze Miniserve, což má omezení na jednoho uživatele (i když nějakým zalamovaným spuštěním více instancí by bylo asi možno dosáhnout kýženého výsledku). Znáte něco takového?
Uživatele proprietárního Chromu na Linuxu by mohlo ještě zajímat, že Chrome 88 má podporu hardwarové akcelerace videa pomocí VA-API. Pokud nemáte NVIDII, tak můžete zkusit v chrome://flags povolit #ignore-gpu-blocklist a #enable-accelerated-video-decode.
Podporované kodeky poté lze zjistit na chrome://gpu v sekci "Video Acceleration Information" (pokud je prázdná, tak akcelerace nefunguje). Pokud je video akcelerováno, pak by se mělo v chrome://media-internals u políčka "kVideoDecoderName" ukázat "MojoVideoDecoder".
Otestováno na AMD Renoir a funguje to skvěle - při přehrávání 4K 60fps HDR YouTube videa kódovaného pomocí VP9 šlo využití procesoru z ~85% na ~35%. Snad by to někomu mohlo pomoci. :-)
Vygooglil som https://github.com/brave/brave-browser/issues/13284 kde som sa doklikal k riešeniu - vypnúť #enable-vulkan
.
Je to divné, taky mi to funguje. Test třeba ftp://speedtest.tele2.net
Se nam tad rozmaha takovy nesvar - korporatni fasizmus.. nehodici se zrusime bez nahrady.
Lze tam tedy nastavit alespon otevirani odkazu s ftp:// protokolem pres jinou (GUI) aplikaci?
Je hromada webu, ktere vyuzivaj FTP - at uz na manualy k deskam, nebo na biosy, a vzdy je fajn, kdyz si clovek muze stahnout cely adresar, nebo odzalohovat klidne i vse co tam existuje.
Ale s Googlem to jde pekne dolu vodou - jsem chtel minuly tyden nastavit synchronizaci skrze aplikaci na Drive, a po zadani hesla to napsalo v te jejich aplikaci ze "zabezpeceni je slabe" - jako wtf. Po chvilce zkoumani jsem prisel na to ze ta desktop aplikace je jakasi webstranka sbalena v appce, na webu nasel ze ostatni maj taky problemy a pak jsem to vzdal. Muzete byt sebelepsi ajtak, kdyz je dodavatel appky/sluzby jak to rict jednoduse - no s "diagnozou ind".
podle mě tam chybělo 2FA, poté lze vygenerovat extra token pro přístup nějakých aplikací. Tohle chování mě také štve, přestává být snadné s údaji na těhle službách manipulovat.
Ftp je za mě také důležitý protokol, umožňuje listování (bez nutnosti, aby tam běžel webový server a generoval html), umožňuje stažení celé složky (u http pouze rekurzivně stahovat odkazy, uhf). Spousta zdrojů kolem linuxu je na ftp, trochu se bojím, že to kvůli tomu budou migrovat a přes http je to vždy o trochu horší.
IE to zobrazí v Exploreru jako normální složky i pro WebDAV - http(s). Potřeboval jsem skriptem přejmenovat tisíce složek (v jedné verzi MS Dynamics CRM se změnil formát jmen složek v SharePoint), tak jsem otevřel root složku CRM v SP přes WebDAV (ikona v toolbaru web app Dynamics CRM), Shift+pravý klik, otevřít Příkazový řádek a Windows dokonce přimountoval WebDAV složku jako písmenko disku.
21. 1. 2021, 00:08 editováno autorem komentáře
To neslo (pouzivam porad FF), ale slo to prohlizet/prochazet - takze jste mel na par kliku prehled co se na danem serveru nachazi (hlavne pri kliku na "..", nebo upravou url) a jak tam maj organizovana data.
Pokud to bylo neco zajimaveho/sloziteho/velkeho na potrebu resume, tak uz clovek pustil plnotucneho FTP klienta.
Jediný problém je v tom, že Google má významnou pozici na trhu a podobnými rozhodnutími ho může jemně, ale soustavně ovlivňovat trh pro sebe. Proto je dobré o dopadech mluvit, sledovat, hlídat a tvořit protiváhu.
Odstranění FTP z prohlížeče nevidím tragicky. Dnes se už široce nevyužívá, pro doručení souborů uživateli slouží lépe HTTP. Jsou situace, ve kterých je FTP stále nepřekonané (nikdo se nevěnuje tomu, aby ho překonal). Tím jsou hromadné downloady a uploady, změna oprávnění a taky kopírování dat mezi servery, aniž by tekly přes klienta. Jenže to jsou okrajové operace, které stejně prohlížeč neuměl - tedy nebudou ani chybět.
Jsou kroky, které Google dělá, a nevoní už na dálku. Zrovna toto mi přijde jako racionální uvážení nákladů a přínosů udržování podpory. Nenapadá mě, jakou vlastní výhodu by Google získal tím, že zlikviduje "FTP trh".