Google, potažmo YouTube umožní návrat tvůrcům, kteří byli zablokováni kvůli údajnému šíření dezinformací souvisejících s COVID-19 a volbami. Tvůrci teď mohou požádat o navrácení přístupu. Společnost Alphabet v této souvislosti uvedla, že zákazy byly uděleny kvůli tlaku tehdejší Bidenovy administrativy.
Vývojári z distribúcie Artix, ktorá je postavená na Arch Linuxe, alebo skôr jeho forkom, už skôr prešli na Open-RC init systém, stále však niektoré projekty ako GNOME boli závislé na systemd. Teraz pretiekol pohár trpezlivosti a počnúc GNOME 49, kvôli ktorému komponenta gnome-session je úplne závislá na systemd-init, padlo rozhodnutie na odstránenie GNOME z repozitárov Artixu. Táto zmena sa podľa všetkého týka viac než 90 distribúcií, ktoré tiež nepoužívajú systemd. Viac v príspevku na DistroWatch.
Magazín IEEE Spectrum opět po roce publikoval svůj žebříček programovacích jazyků. Vedou Python, Java, C++, SQL a C#.
Repozitáře pro spolupráci v rámci projektu Fedora se přesunou z Pagure na nově vzniklý Fedora Forge. Ten stejně jako třeba Codeberg běží na softwaru Forgejo, které bylo už před časem vybráno jako náhrada za Pagure. Pagure pochází z dílny Fedory, ale mimo ni se příliš neuchytil. Jeho vývoj a údržba byly náročné a Fedora se rozhodla jít cestou úspěšnějšího projektu, který má větší základnu přispěvatelů.
Byla vydána (𝕏) nová verze 2025.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
V IT4Innovations národním superpočítačovém centru byl dnes slavnostně spuštěn první český kvantový počítač VLQ disponující 24 fyzickými qubity s unikátní hvězdicovou topologií. Systém dodala společnost IQM Quantum Computers a jeho celková pořizovací cena činila přibližně 125 milionů korun.
Výrobce čipů Nvidia chce investovat až 100 miliard dolarů (přes dva biliony Kč) do společnosti zaměřené na umělou inteligenci OpenAI. Firmy o tom informují v tiskové zprávě. Oznámené partnerství přichází v době, kdy se mezi technologickými giganty a start-upy zostřuje konkurence o zajištění přístupu k energii a čipům potřebným pro rozvoj umělé inteligence (AI).
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 157 (pdf).
Společnost Cloudflare oznámila, že sponzoruje nezávislý webový prohlížeč Ladybird a linuxovou distribuci pro vývojáře Omarchy (Arch Linux s dlaždicovým správcem oken Hyprland).
Společnost XTX Markets zabývající se algoritmickým obchodováním pro své potřeby vyvinula a dnes představila a otevřela souborový systém TernFS. Zdrojové kódy jsou k dispozici na GitHubu. Vývoj TernFS začal počátkem roku 2022. Od léta 2023 jej XTX Markets používá v produkčním prostředí.
Zdravim vsechny citatele, rad bych slysel vas nazor na nasledujici problem. Jiste vsichni znate rozdil, vyhody a nevyhody aktivního a pasivního rezimu FTP.
Mejme nasledujici situaci:
Aktivni rezim:
Pasivni rezim:
Moji otazkou je: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"
Muze mit souvislost s:
Jsem si zcela jisty, ze jen stale neco prehlizim nebo si dostatecne neuvedomuji. Zatim ale nemuzu prijit na pro me prijatelne vysvetleni. Dekuji vsem za reakce.
Tiskni
Sdílej:
archaické FTPMimochodem, ďábelská kombinace je FTPS (FTP over SSL, resp. FTP + TLS) s NATem u klienta a firewallem na serveru. Connection tracking (verze pro FTP) samozřejmě nebude fungovat, takže kdo by to chtěl používat (namísto čistší náhrady protokolem SFTP), může zažít docela zábavné chvilky.
iptables
parametr -d
za -s
(když ony ty dvě klávesy jsou tak blízko u sebe...), takže jsem nějakou dobu ještě zjišťoval, proč se FTP klient za NATem někdy připojí a někdy ne.V pasivním režimu datové spojení navazuje klient. Ten spojení z portu 20 nenastaví už jen proto, že klient obvykle není root
Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"
Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?
Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.
Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"Důvod může být v podstatě stejný - aby server nemusel běžet jako root, tak začne naslouchat na portu 21 a pak se zbaví svých práv. Tím pádem když chce někomu poskytnout data pasivně, nemůže už použít privilegovaný port.
Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.Nemusí, když ho nenastavíš, OS si nějaký vybere sám.
Jak odpověděl níže mich, aby šlo rozeznat od sebe různá datová spojení. To už by asi bylo fakt trapný, aby klient musel po kontrolním spojení říci, ze kterého svého portu se připojil, aby to datové mohl FTP server dohledat.V pasivním režimu datové spojení navazuje klient. Ten spojení z portu 20 nenastaví už jen proto, že klient obvykle není root
Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"
Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?
Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.
Povinná hlavička protokolu TCP to je, nicméně obvykle se o to postará operační systém (přidělí náhodný volný), programátor se o to vůbec nemusí zajímat. Co je důležité je nastavit především cílový port.
Mimochodem, pár FTP serverů jsem zkusil, na port 20 kašlaly. Asi to je jen featura pro lepší firewallování serverů...
FTP je dnes dobré akorát tak pro PHP webhostingy a jejich PHP klienty, kteří si neumí nastavit SCP nebo SFTP.
Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port?V aktivním režimu by se to mohlo hodit jako omezující pravidlo do firewallu...
Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?
Třeba IKE. Smysl to má ale jen tehdy, když se jedná o proces, který z principu poběží jen v jedné instanci a nepotřebuje navazovat víc "spojení" na stejný cíl.
Jiste vsischni znate rozrdil, vyhody a nevyhody aktivního a pasivního rezimu FTP.
Jediná výhoda, která mě napadá, je, že musím při použití FTP klienta ještě lozit do nastavení, abych řešil přesně tenhle aktivní a pasivní mód.
> O WebDavu raději mlčím
Proc? Pokud mate nejake postrehy, me by to urcite zajimalo...
Můžete pomocí něj například zkopírovat soubor mezi dvěma FTP servery, aniž přitom teče přes váš počítač.
Heh. A zkoušeli jste už někdo překopírovat pár větších souborů mezi dvěma FTP servery v nějakých velkých housingových centrech?
> pokračuje nedefinovaným listingem adresářů, potom tu máme několi potrhlých formátů souborů, nápad konvertovat CRLF
...
> Doufám že umře, patří do propadliště dějin. Máme HTTP
Ackoliv s vyhradama proti FTP vicemene souhlasim, tak nechapu preferovani HTTP - HTTP nema vubec zadny definovany listing adresaru (FTP aspon definuje moznost vylistovat ciste jmena souboru) a ruzne konverze (napr. kodovani) jsou u HTTP serveru take mnohem rozsirenejsi a obtizneji vypnutelne (ze strany klienta). SFTP je velice pekny protokol, nicmene pro verejnou distribuci souboru me stale prijde FTP jako nejvhodnejsi z bezne rozsirenych sitovych protokolu.
…uživatel klikne na odkaz na webu a stahuje…Na které planetě ? Tady na zeměkouli je to tak, že klikne co chce stáhnout, pak odklikne potvrzení licenčních podmínek, pak klikne na výběr místa odkud se stahuje, pak klikne na přeskočení reklamy, pak klikne na "nefunguje to" odkaz protože nechce čumět dalších deset sekund na další reklamu, pak musí odklikat všechny popupy,které v průběhu procesu vznikly. A to jen když má štestí a nenachází se na místě s povinnou registrací pro zasílání vyžádaného obchodního lančmítu, pak je kliků daleko víc.
Na které planetě ? Tady na zeměkouli je to tak, že klikne co chce stáhnout, pak odklikne potvrzení licenčních podmínek, pak klikne na výběr místa odkud se stahuje, pak klikne na přeskočení reklamy, pak klikne na "nefunguje to" odkaz protože nechce čumět dalších deset sekund na další reklamu, pak musí odklikat všechny popupy,které v průběhu procesu vznikly.Ano, takhle to chodí na webech firem typu Adobe, a také na hrůzách typu SourceForge (ano, SF je hrůza - pokud mám možnost stahovat odjinud, rád tak činím, se SF jsou jen problémy). Při stahování z webu tvůrce obvykle stačí kliknout na odkaz. Jdu příkladem (např. tady nebo tady)
I na SF to jde zjednodušit. Tedy aspoň o tu zbytečnou stránku těch podělanejch mirrorů. Stačí cílový soubor otevřít do nového tabu (funguje v Safari a snad i ve Firefoxu), počkat na download okýnko a zavřít prázdný tab.
No, já abych řekl pravdu, tak SF rád nemám. Nejen kvůli reklamám, ale hlavně je strašně pomalý a nepřehledný. Když hledám nějakou knihovnu, jedno z pravidel výběru je, že nejlépe kdekoli jen né na SF.
U FTP je tech pozadavku sice vice, ale vzhledem k poctu paketu na preneseni celeho souboru je to obvykle prakticky jedno. Navic jsem mel na mysli spis cely FTP archiv, kde je tech souboru vic (treba ftp.kernel.org) - napriklad adresar s ruznyma verzema souboru. Tam HTTP neumoznuje napriklad strojove parsovatelne prochazeni adresaru.
> kdežto u FTP je potřebných kroků více a jsou tam různá úskalí.
No u HTTP je tech uskali mnohem vic - server to muze posilat se spatnym MIME typem a klient se pak bude chovat divne, server se muze usmyslet ze se jedna o textovy soubor a je treba ho prelozit z ISO-8859-2 na CP1250 :–), ci ze k tomu bude posilat divnou informaci o platnosti pro cache. Samozrejme, pokud je clovek adminem toho HTTP serveru, tak si to ohlida aby to bylo v poradku, ale pokud ne, tak s tim muze byt problem.
Za asi jedinou podstatnou vyhodu (pro ucely verejne distribuce souboru) HTTP proti FTP povazuji podporu pro virtualni domeny.
Spíš je třeba brát ohled na dobu kdy vznikal(fňuk). Tehdy se o takovém Internetu jako je dnes nikomu ani nezdálo(a o takovém NATovém bazmeku jako je dnes se asi ani nikomu zdát nechtělo). Je docela zázrak, že přežil až do dnešních dob. Znám už jen jeden a ještě starší protokol, kterému se povedlo něco podobného. Docela zajímavé, že ani ne za měsíc bude mít první RFCéčko čtyřicáté výročí a Telnet to čeká jen o pár měsíců později.(A furt tu s námi je)
Telnet to čeká jen o pár měsíců později.(A furt tu s námi je)I někde jinde, než v embeded zařízeních?
Co myslíš, že leze přes kanál Connection protocolu poté co je zabezpečeno spojení Binary Transport Protocolem, Key Exchange Protocolem a popř. Authentication Protocolem u SSH? A ani tak nejde o samotný telnet tak jak ho známe v dnešní době, ale o jeho podmnožinu NVT.(Samotná norma také nepopisuje telnet, ale takové jakési čudo) K tomu si dovolím citaci:
Právě protokol NVT je použit v omezené míře pro prezentaci dat v mnoha dalších protokolech jako jsou FTP, POP3, SMTP, NNTP i HTTP apod. MIME v podstatě je rozšířením této filosofie.
Bůh ví ve všem čem je to ještě dneska zadrátováno.
Myslim si, ze i zbaveni se roota ma smysl, ale b) je IMHO ten hlavni duvod. Jak jinak by server s jistotou vedel, jaka data ma do daneho socketu posilat? Tomas
jak byste věděl komu máte co poslat (případně kde očekávat jaká data)?Ideálně podle IP adresy.
Co to? Není náhodou jednoznačné spojení dáno zdrojovou adresou, zdrojovým portem, cílovou adresou, cílovým portem a protokolem?
Mohlo by se to řešit třeba tak, že spolu s výzvou PASV by klient odesílal i ip a port toho, kdo bude se serverem komunikovat, což ale není tak jednoduché.
A přesně o tomto jsem mluvil. Bohužel jsem si až teď uvědomil, že přes kaskádu NATů by to asi opravdu nebylo tak jednoduché a v podstatě by to byl aktivní mód naopak, takže žádné řešení.
Proč se nezeptat přímo u zdroje?:
Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to negotiate a non-default port. The second is to use another transfer mode.
A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. Thus using these modes one can leave the data connection open for multiple file transfers.