Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
+---------+ eth0 +----------+ eth1 (maskarada)
|INTERNET |----------------------| |-------------------
+---------+ 128.169.28.1 | | 192.168.1.0/24
verejna IP | |
| FIREWALL |
| | eth2 +-----+
| |-------------------| DMZ | Verejne adresy 128.169.28.3-X
+----------+ 128.169.28.2 +-----+
dalsi verejna IP
vubec si totiz nedokazu predstavit jak by to dopadlo kdyz by se na sitove karty eth0 a eth2 povesil stejny rozsah a jestli by to vubec fungovalo a jak by si s tim poradila routovaci tabulka. Muzete mi prosim popsat pripadne vyhody a nevyhody nebo nastinit jak to jinak zrealizovat ??? Cetl jsem tady uz DNAT/SNAT ale zda se mi to jako neohrabana moznost. Do te DMZ totiz potrebuji pristup z INTERNETU. dekuji za kazdou reakci
Stejné IP rozsahy (resp. podsítě) na eth0 a eth2 skutečně mít nemůžete, to by nefungovalo. Máte-li možnost, nechte si pro DMZ přidělit další rozsah IP adres, ten nastavíte na eth2 a provoz mezi Internetem a DMZ budete na firewallu normálně routovat (a samozřejmě nějak filtrovat, že).
Pokud nemáte možnost získat další blok adres, tak strojům na DMZ přidělíte privátní adresy (jiné, než na eth1). Na firewallu si na eth0 dopřidáte kromě oné 128.169.28.1 i další veřejné adresy (...2, atd.) a pomocí SNAT/DNAT zajistíte, že třeba provoz na 128.169.28.2 přišedší na firewall bude 1:1 (tj. se zachováním čísel portů) předán stroji s IP 192.168.2.1 v DMZ. Je to trochu drbačka, zejména ve světle té maškarády na eth1 (protože se vám otevírá celá řada příležitostí k omylu při nastavování komunikace mezi eth1 a eth2), ale rozhodně to tak nastavit jde a počítače v DMZ budou (téééměř) plnohodnotně přístupné z Internetu.
To není tak úplně pravda, fungovat to může. Jen je potřeba to ošetřit.
Jo, přesně tak.
2. Týkalo by se to nejen providera, ale také ostatních, kdo jsou s firewallem na stejném segmentu (typicky další zákazníci).
Přidělené veřejné adresy
128.169.28.2-X
+----------+ wirelles +---------------+ LAN1 +-----+
| INTERNET |-------------------| |-------------------------| DMZ |
+----------+ | | +-----+
| OVISLINK 1120 |
| | eth0 eth1
| | 128.169.28.1 +--------+ 192.168.1.1 +-----+
| |-------------------| ROUTER |------------------| LAN |
+---------------+ LAN2 | + | +-----+
|FIREWALL|
+--------+
pokud se totiz domnivam spravne tak OVISLINK by mel fungovat jako bridg a tim padem by mel ty verejne IP od poskytovatele bez vetsich problemu propustit
+---------+ eth0 +----------+ eth1 (maskarada)
|INTERNET |----------------------| |-------------------
+---------+ neni IP | | 192.168.1.0/24
| |
| FIREWALL |
eth0:1 | | eth2 +-----+
128.169.28.2 | |-------------------| DMZ | Verejne adresy 128.169.28.2-X
+----------+ neni IP +-----+
mezi rozhranim eth0 a eth2 je vytvoren bridge pomoci utility brctl a neni na nej prirazena IP adresa tim padem se to bude chovat jako OVISLINK. Ten alias eth0:1 je tam pouze kvuli tomu aby byl na router pristup i z venku. Jedina nevyhoda je u komunikace mezi LANem za eth1 a DMZ pac se na nej bude aplikovat firewall 2x respektive 4x. ale tohle jde uz vyresit.
Tiskni
Sdílej: