Byla vydána nová verze 0.17.0 programovacího jazyka Zig (Codeberg, Wikipedie). Přispělo 206 vývojářů. Přehled novinek v poznámkách k vydání.
Open-source projekt OpenDLSS-NR je 'bitově přesná reimplementace' neuronové rendrovací sítě DLSS 5 od společnosti NVIDIA, jenže pro grafické API Vulkan (DLSS slouží k vylepšování klasickým způsobem vyrendrovaných snímků pomocí lokálních modelů umělé inteligence, a to v reálném čase). Projekt není nijak spojen se společností NVIDIA, je pouze pro OS Windows a natrénované váhy modelu si uživatelé musí obstarat sami. Zdrojový kód je k dispozici na GitHubu, pod licencí MIT s výjimkou pro komponenty třetích stran.
Společnost Cloudflare představila Clef a Clef-Flash, open-source rozhodovací modely určené pro rychlou a konzistentní klasifikaci vstupů. Na rozdíl od klasických LLM vracejí tyto modely deterministické striktně typované strukturované odpovědi s exaktními pravděpodobnostmi, tedy odpovědi ve stylu přelomového modelu Jev.
… více »Byla vydána beta verze Ubuntu 26.10 s kódovým názvem Stonking Stingray. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.10 mělo vyjít 15. října 2026.
Byla vydána verze 1.99.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Od 13. do 15. října proběhne v Praze OpenSSL Conference 2026. Na YouTube lze zhlédnout videozáznamy přednášek z loňského roku.
Eben Upton oznámil další zdražení jednodeskových počítačů Raspberry Pi. Tentokrát 2 GB varianty o 12,50 dolarů. Nově 2 GB Raspberry Pi 4 stojí 67,50 dolarů a 2 GB Raspberry Pi 5 stojí 77,50 dolarů.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 26.09. Vedle Flatpaku také s podporou Snapu.
Edison Design Group po více než 30 letech zveřejnil zdrojový kód svého EDG C/C++ front-endu. Ten proslul širokou podporou standardů C++ a kompatibilitou s dialekty kompilátorů od Microsoftu, GNU, Clangu, Sunu a dokonce i s prehistorickým cfrontem. EDG byl použit například v kompilátoru Intel C++ Classic, kompilátoru NVCC od firmy NVIDIA pro platformu CUDA nebo v našeptávači kódu IntelliSense v produktech společnosti Microsoft. Projekt nyní spravuje organizace The C++ Alliance a kód je dostupný pod licencí Apache 2.0, doplněnou o výjimky projektu LLVM.
Pocket Tank je malé kapesní virtuální akvárium postavené na vývojové desce ESP32-S3-Touch-AMOLED-1.8. Na dvoujádrovém mikrokontroléru ESP32-S3 s 8 MB PSRAM a 16 MB flash paměti běží jak simulace akvária, tak i malý jazykový model určující chování rybiček. Lokální model o velikosti 7,56 MB se 14 miliony parametrů vznikl destilací modelu Gemma 4 26B, tedy učitele s 26 miliardami parametrů. Kromě firmwaru pro skutečný modul s AMOLED
… více »V firmě máme dvě lokality, v každé z nich je pár privátních sítí, které nejdou navzájem routovat přes internet. Ale protože potřebujeme spojení mezi lokalitami neomezeně, používáme IPsec tunel, a sice OpenSwan. Běží to přímo na linuxových hraničních routerech. V konfiguraci IPsecu je napsáno, že co jde do privátní sítě na druhé straně, ať to zabalí a pošle tunelem. Na jednu síť jsme zapomněli, v konfiguraci IPsecu není, a přesto má konektivitu. Akorát že traceroute ukazuje o dva hopy víc než by měl a jako mezistanice samé hvězdičky.
Přesněji je to takto: požadavek na spojení přijde do hraničního routeru z nějaké VLANy. Projde pravidly iptables, kde není přesměrován ani zahozen, nýbrž akceptován. Teď by měl odejít defaltní routou do internetu a tam se ztratit, protože cílová adresa je 10.x.x.x . Avšak neodejde, jak jsem zjistil tcpdumpem na externím rozhraní routeru. Spojení s privátní adresou v druhé lokalitě se uskuteční jako by se nechumelilo. Nemám pro to jiné vysvětlení, než že se jádro stydí poslat paket směřující do privátního rozsahu do defaltní routy. Místo toho se paket pořád jenom v jádře nějak mrcasí, což ho stojí dvě TTL jednotky, a potom ho dostane IPsec démon a normálně pošle. Celé se to tedy zachová, jako kdyby paket navazující spojení přišel z jiné VLANy než ze které ve skutečnosti přišel. Funguje TCP a ping, nic jiného jsem nezkoušel. Sakra to jsou ty systému vážně tak inteligentní?
Tiskni
Sdílej:
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz route, ale to, co ukazuje 'ip route show' nebo ještě lépe 'ip route show table all' a 'ip rule show'.
Jinak konfigurace FreeS/WAN byla vždycky trochu mystická a po přechodu na ipsec-tools (setkey a racoon) jsem zjistil, že je všechno najednou mnohem průhlednější, když se nemlží vlastními matoucími pojmy a používají se ty standardní. Celkově v používání OpenSWAN na dnešních jádrech nevidím moc smysl.
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz routeTakže mě někdo mystifikuje?
man route route - show / manipulate the IP routing table
route --help Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
route je v Linuxu obsolete od jádra 2.2 (vyšlo v lednu 1999). Takže vám sice v dobré víře ukáže, co si myslí, že je směrovací tabulka, ale ani zdaleka nemůžete spoléhat na to, že vám ukáže všechno, co potřebujete vědět.
1. Já to třeba v ifconfig(8) mám (a ne, nenapsal jsem si to tam sám). Jinak třeba tady a na spoustě dalších míst. Stačí nezavírat oči.
2. To už jsem udělal mnohokrát, ale pokud si úmyslně zadefinujete "běžné" situace jako ty, kdy ifconfig a route jakž takž stačí, pak to samozřejmě už z principu nepůjde. Pro zajímavost si zkuste porovnat i na zcela "běžném" systému výstup 'route -n' a 'ip route show table all'. Myslíte si, že to, co ukazuje druhý příkaz navíc, je nějaká fikce? Nebo si snad myslíte, že tyto položky nemají vliv na směrování paketů?
ifconfig a route naprosto postačuje. Navíc má o mnoho příjemnější syntaxi.
ifc<TAB>eth0 IP/maska upvs
ip addr add IP/maska dev eth0
18.8.2011 14:59
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ifconfig eth0:n IP/maska
ifconfig eth0:n IP/maska
ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:13:d3:d2:bb:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.26.1/32 scope global eth0
inet 192.168.2.175/24 brd 192.168.2.255 scope global eth0
inet 192.168.0.175/24 brd 192.168.0.255 scope global eth0
inet 172.16.34.175/16 brd 172.16.255.255 scope global eth0
inet6 fe80::213:d3ff:fed2:bbef/64 scope link
valid_lft forever preferred_lft forever
A co mi ukaze ifconfig?
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:13:d3:d2:bb:ef
inet addr:192.168.26.1 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::213:d3ff:fed2:bbef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:254104359 errors:0 dropped:5146 overruns:0 frame:0
TX packets:130721632 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3197090190 (2.9 GiB) TX bytes:3644918187 (3.3 GiB)
Interrupt:17
No a kde je ten zbytek adres? Navic, primarni by mela byt 172.16.34.175 (DHCP) - kde je? To se pak nediv, ze ti pak chodi nejaky packety neznamo odkud a neznamo kam, kdyz vidis jenom pulku nastaveni (resp. mozna jenom 10%).
To je alias, ne dve adresy.
On to právě není alias, jen se to tak tváří. IP aliasing jako takový fungoval naposledy v řadě 2.0 (IIRC pouze v řädě 2.0). Problém (jeden z problémů) je právě v tom, že se ifconfig dodnes tváří, jako by tam skutečně existovalo virtuální rozhraní, což dávno není pravda. Navíc další adresy vidí a zobrazuje jen v případě, že mají přiřazený label (což demonstruje váš příklad).
Jestli jsem to dobře pochopil, výrazem příjemnější rozumíte kratší. V tom případě se můžete vykašlat na srozumitelnost a psát 'ip a a addr/prefixlen dev eth0' (IIRC spíš musíte, protože ip IIRC zápis s maskou ani nepodporuje).
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje. Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.
Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.Neni to primarne proto, ze u IPv4 se vseobecne pocitalo s tim, ze rozhrani ma jen jednu adresu (a vic adres je tedy rozsireni nekterych implementaci), tak u IPv6 se standardne pocita s vice adresama? Treba u toho IPv4 mnoho navazujicich standardu ma s vice adresama problem (treba OSPFv2).
1. U IPv6 je skutečně pro plnou funkcionalitu nutné mít možnost přiřadit rozhraní více adres. Ale co se IPv4 týká, nejsem si vědom toho, že by standard nějak přikazoval nebo aspoň doporučoval mít jen jednu.
2. Skutečně je to problém OSPF jako takového? Není to spíš problém konkrétních implementací?
U OSPFv2 standard predpoklada 'jedna linka - jeden prefix'.Tedy s vyjimkou ptp (a ptmp) linek, ktere prefix mit nemusi.
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje.Mě jedna adresa na rozhraní zatím skoro vždy stačila (OK, IPv6 je výjimka).
'ip route show table all'No, to je trochu zavadejici, nebot to vypise i obsah tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku. Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní. Zvláštní jsou na ní jen dvě věci: za prvé je defaultní tabulkou pro přidávání položek typu local a broadcast (a možná i některých dalších), ale stejně tak je main (254) defaultní pro typ unicast a některé další. Za druhé: automaticky vytvářené pravidlo s prioritou 0 zajišťuje, že se tato tabulka prohledává pro všechny pakety jako první. Jinak ale tato tabulka funguje stejně jako všechny ostatní.
Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
Ne úplně, první příkaz vám IIRC neukáže třeba MTU, metriku nebo preferovanou zdrojovou adresu. Ale především vám ani jeden neukáže dostatek informací na to, abyste mohl určit, jak se bude konkrétní paket směrovat.
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní.Hlavni rozdil bych videl v tom, ze tabulka 'local' je asi dost linuxove specifikum - pokud si predstavim jakysi genericky koncept IPv4 routovani a pak jeho jednotlive implementace, pak tabulka 'local' (resp. ty polozky typu 'local' a 'broadcast') resi to, co v ostatnich implementacich (ci v tom generickem modelu) je reseno mimo routovaci tabulku jinymi strukturami. Ze v Linuxove implementaci to chytre sloucili do stejnych struktur je sice pekne, ale tezko to potom porovnavat.
17.8.2011 22:55
xxx | skóre: 42
| blog: Na Kafíčko
Imho je tam skutecne neposle. 10.0.0.0/8 neni globalne smerovatelna, takze na takovem rozhrani nema co delat. NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani. (Coz by znamenalo, ze se o jeho smeru vubec nerozhoduje routovaci tabulka. Ale nejsem si zcela jist, je to uz delsi dobu co sem to studoval.)
NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani.
To určitě ne, jak by se pak poznalo, které rozhraní to má být (a kdo má být další hop)? Překlad zdrojové adresy (tj. i maškaráda) se provádí až na konci, kdy už je o směrování rozhodnuto. Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním, ale paket je pak směrován podle standardních pravidel a tabulek. Trochu složitější je to jen při přepisu cílové adresy (případně značky) u lokálně generovaných paketů, ale i tam v zásadě platí, že bez ohledu na NAT o směrování rozhodují standardní mechanismy.
Na druhou stranu, pokud se používá IPsec (a zvláště v tunelovacím modu), je potřeba dávat pozor ještě na to, kdy se na paket aplikuje SP, která také může zamíchat kartami.
17.8.2011 23:26
xxx | skóre: 42
| blog: Na Kafíčko
Mate pravdu, staci zadat do Googlu iptables a mrknout se co to naslo za obrazky.
Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním
Tady samozřejmě mělo být cílové, omlouvám se za nepozornost.
Bohužel není možné, abych zveřejnil topologii firemní sítě. Jak vidím, všeobecný názor je, že jádro neví nic o veřejných a privátních rozsazích. My teď opravíme konfiguraci, aby všechny routy byly definované. Tím ty záhady přestanou být vidět a budeme moci na ně zapomenout.
Prošlo to tam na úrovni Ethernetu VLANou, která vede radiospojem mimo routování a málokdo ze správy sítě o tom věděl. Na jedné straně je mi líto, že máme v síti nepořádek. Na druhé straně jsem rád, že jádro linuxu se nestydí a ten plyšovej talisman zatím ještě není tak úplně nezbytný.