Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?
Dovedu si představit zjednoduššení klientské části, ale není to pak jen snadná náplast pro "složitost" použití IPIP rozhraní? Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?
Chápu význam samotné UDP enkapsulace a použití nad libovolným tunnelem, jen nechápu nutnost "ip fou".
Díky.
Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?
Můžete trochu rozvést, co konkrétně tím myslíte?
Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?
V čem konkrétně vidíte problém?
Můžete trochu rozvést, co konkrétně tím myslíte?
(níže se odkazuji na původní mail)
Konkrétně nechápu rozdělení na "RX" a "TX" části, kdy se každá konfiguruje jinak. Např. klasický IPIP tunel se konfiguruje jako:
strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1 strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2
A to je vše. Jednoduchá enkapsulace přidáním jedné IP hlavičky.
Pokud jsem dobře pochopil, rychlostní benefity odkazovaného patchsetu spočívají v tom, že routery/switche/síťovky počítají s tím, že nad IP je buď TCP nebo UDP, ale ne už další IP - fungovat budou, ale nebudou asi moci použít hardwarové optimalizace. Řešením je tedy zabalit provoz do ještě jedné UDP hlavičky - to bych si představoval jako (cca):
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1 \
encap udp encap-sport 1111 encap-dport 2222
strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2
encap udp encap-sport 2222 encap-dport 1111
Má otázka tedy je - proč se to neudělalo takto jednodušše? Proč se přidávalo celé nové API pro iproute2 s vlastní sadou příkazů?
V čem konkrétně vidíte problém?
Když si čtu původní článek znovu, nedochází mi, proč by "ip fou" měl vůbec existovat. Chápu myšlenku odstranění enkapsulace a vražení zpět do síťového stacku, ale nechápu použití. Proč tu enkapsulaci nedovede rozbalit kód tunelu? Původní email se zmiňuje, že to rozbalení dělá XFRM, tak proč nebylo použito rozhraní ip-xfrm?
Nevím, přijde mi to jako příliš nepodstatný a primitivní "hack" na to, aby měl vlastní API. Nebo se mi naopak líbí ten jednoduchý nápad a nechápu, proč je implementace limitována na IPIP - např. na několika místech používám gretap a zvýšení výkonu enkapsulací do UDP bych uvítal.
Díky.
Sice mi to vzalo trochu času, naučil jsem se ale jednu cennou techniku ladění:#undef EINVAL #define EINVAL __LINE__
To by nesměly být v jádře soubory, které mají víc než 4095 (MAX_ERRNO) řádků.
Oboje. :-)
Purista by asi používal paket pro označení celého IP paketu s UDP protokolem a datagram pro samotnou UDP hlavičku a payload, ale ono je to většinou jedno. Buď je to jasné z kontextu nebo je stejně lepší explicitně napsat, co má člověk na mysli.
Tiskni
Sdílej:
