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.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Vývojové jádro 3.17-rc7 vyšlo dne 28. září (oznámení) místo finální verze 3.17, které měl Linus v plánu. Linus k tomu řekl:
Není to proto, že by se stalo něco obzvlášť děsivého, ale upřímně řečeno, všechno jsem jen neuklidnilo tak, jak jsem doufal. I když by mi s ohledem na cestovní plány vyhovovalo, kdybych zvládl kratší cyklus vydání než obvykle, „pohodlí“ mezi kritéria vydání nepatří. Co se dá dělat.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace a žádná neprochází v době vzniku tohoto textu procesem kontroly.
V podstatě [je checkpatch] v pořádku jako nástroj, který upozorňuje na podmnožinu kódu, která by mohla stát za pozornost; dává ale nesprávně pozitivní i nesprávně negativní výsledky. Pokud jich však není moc, je užitečný. Za předpokladu, že nenahrazuje váš vkus. Tedy „Hele, upozorňuje na tyhle řádky; mrkneme na to, něco z toho by mohlo stát za pozornost.“, a ne „Nejsvětější orákulum promluvilo; udělej, co ti přikazuje.“
– Al Viro (odkaz)
Ve zdrojovém kódu jádra je v podstatě 1 milion „selhání“ při checkpatchi, opravdu je chceme všechny vyčistit, plýtvat přenosovou kapacitou recenzentů a správců a tvářit se, že těchto 1 milion čištění je stejně důležitých jako „ostatní“ práce, která probíhá na jádru?
– Ingo Molnar (odkaz)
Sice mi to vzalo trochu času, naučil jsem se ale jednu cennou techniku ladění:
#undef EINVAL #define EINVAL __LINE__
– Hugh Dickins (odkaz)
Tunelovací protokoly jsou v uspořádání moderních sítí stále důležitější. Díky provázání vzdálených sítí umožňují vytváření virtuálních privátních sítí, přístup k portům skrytým obvykle za firewallem a další. Tunelování může probíhat na více vrstvách úrovních; tunely SSH jsou implementovány prostřednictvím protokolu TCP, zatímco protokoly jako GRE nebo IPIP pracují přímo na úrovni protokolu IP. Zajímavé však je stále častější zájem o tunelování v rámci protokolu UDP. Oprava „foo over UDP“ (FOU) od Toma Herberta, která byla zahrnuta do dalšího stromu verze jádra 3.18, implementuje tunelování na úrovni UDP obecným způsobem.
Proč UDP? V podstatě všechna existující síťová rozhraní zahrnují hardwarovou podporu UDP, která zajišťuje podrobnosti jako kontrolní součty. UDP dodává jen tolik informací (konkrétně čísla portů), aby bylo směrování zapouzdřených paketů snadné. UDP může rovněž pracovat s protokoly jako RSS (Receive Side Scaling) nebo ECMP (Equal-cost multipath routing protocol) ke zlepšení výkonu ve vysoce propojené konfiguraci. Tunelování UDP nabízí tolik výhod, že si někteří vývojáři myslí, že se v následujících letech bude používat úplně všude.
Zapouzdření a tunelování paketů pomocí protokolu UDP je celkem snadno pochopitelný koncept. Předpokládejme, že je tunelovému rozhraní předložen jednoduchý paket TCP:
Tento paket má obvyklou hlavičku IP a TCP, následovanou daty, která chce uživatel odeslat. Proces zapouzdření udělá něco takového:
V tuto chvíli vypadá paket jako paket UDP, ve kterém je náhodou ukrytý paket TCP. Systém ho teď může přenést do cíle jako obyčejný paket UDP; na straně příjemce budou přidané hlavičky odstraněny a původní paket se vloží do zásobníku sítě.
Konfigurace tunelu FOU bude obvykle dvoustupňový proces. Odesílající a přijímací strany jsou oddělené. Toto řešení mimo jiné umožňuje asymetrickou konfiguraci, pokud by ji někdo potřeboval. Konfigurace na straně příjmu spočívá jen v nastavení portu UDP tak, aby se stal příjemcem zapouzdřených paketů. Nový dílčí příkaz „fou“ má následující tvar:
ip fou add port 5555 ipproto 4
Tento příkaz odstaví port 5555 s tím, že přicházející pakety budou mít protokol 4, tedy zapouzdření protokolu IP. Paketům přijatým na daném portu je odstraněno zapouzdření; potom jsou předány zpět do síťového zásobníku k doručení do skutečného cíle.
Situace je trochu složitější na vysílající straně, vzhledem k tomu, že musí být nastavena cílová adresa a přenos musí spolupracovat s existujícími protokoly zapouzdření. Typický příkaz může vypadat takto:
ip link add name tun1 type ipip \ remote 192.168.1.1 local 192.168.1.2 ttl 225 \ encap fou encap-sport auto encap-dport 5555
Tento příkaz vytvoří nové virtuální rozhraní (tun1) nakonfigurované pro zapouzdření IPIP. Zdrojový port pro pakety je ponechán na rozhodnutí síťového zásobníku, ale cílový port bude 5555. Uživatel samozřejmě musí zapouzdření protokolu přimět, aby toto rozhraní použilo. Nyní byla podpora této funkčnosti přidána do protokolů IPIP, SIT (tunelovacího protokolu propojujícího sítě IPv4 a IPv6) a GRE (používá se pro virtuální privátní sítě).
Některé údaje zveřejněné v sadě oprav ukazují na významné zvýšení výkonu protokolů SIT a IPIP; výkon s protokolem GRE je zhruba srovnatelný s případy nevyužívajícími FOU. Tato funkce tedy má jasný potenciál urychlit tunelování díky využití výhod stávajících optimalizací kolem odesílání a příjmu pomocí protokolu UDP. Pěkné na tom je, že nevyžaduje žádnou speciální hardwarovou podporu; stávající hardware dokáže UDP zpracovat dobře. Jedná se tedy o jednoduché řešení, které bude fungovat ve stávajících systémech – a mělo by být k dispozici ve finální verzi jádra 3.18.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
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):
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.