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. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Wayfire, kompozitní správce oken běžící nad Waylandem a využívající wlroots, byl vydán ve verzi 0.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.
Před necelými čtyřmi měsíci byl Steven Deobald jmenován novým výkonným ředitelem GNOME Foundation. Včera skončil, protože "nebyl pro tuto roli v tento čas ten pravý".
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Tento zápisek se snaží ukázat jednoduché řešení nastavení konfigurace PC s Debianem (Wheezy) a s vícero síťovými kartami (integrovanými na desce). Přitom jde o to aby: 1) byla vždy IPv4 konektiva (ať už PC bude zapojeno kteroukoliv ze síťových karet) - IPv6 nechceme; 2) PC musí vždy dostat stejnou lokální IPv4 adresu, ať už je zapojeno přes kterýkoliv port (resp. ať už se eth* rozhraní nadetekují v jakémkoliv pořadí) - přičemž tu adresu dostane přes DHCP; 3) nastavení musí být natvrdo v systému a dostupné všem uživatelům (a nikoliv pomocí NetworkManageru či tak podobně); 3) PC by případně mělo fungovalo jako switch a to se zapnutým STP; 4) nahození rozhraní a získání adresy z DHCP nesmí při bootu zdržovat.
Řešení vypadá asi nějak takto (/etc/network/interfaces
na daném PC):
# --- Loopback auto lo iface lo inet loopback # --- Set up interfaces iface eth1 inet manual ethernet-wol g iface eth0 inet manual ethernet-wol g # --- Ethernet Bridge auto br0 iface br0 inet dhcp bridge_ports eth0 eth1 bridge_waitport 1 bridge_maxwait 1 # !! Not using "bridge_stp on" in order to reduce boot time. Using "post_up" instead !! post-up /sbin/brctl stp br0 yes
Vysvětlení: 1) nejdřív zajistíme, aby na eth[0-1]
nešahal nikdo jiný (např. již zmíněný NetworManager [pun intended]). To se zajistí pomocí dvou sekcí iface eth? inet manual
. Jako bonus pro každé rozhraní nastavíme možnost buzení přes Wake-On-Lan.
2) obě rozhraní (eth0
+ eth1
) dáme do bridge - br0
. To nám pak bude sloužit jako virtualní ethernetové rozhraní, které si získá svoji adresu přes DHCP a přes které se připojíme do sítě.
3) aby nastavení rozhraní netrvalo věčnost, nastavíme waitport (doba, po kterou se čeká na nahození jednotlivých rozhraní, než jsou přidány do bridge) jakož i maxwait (maximální doba, po kterou se čeká, než bude bridge v použitelném stavu) na jednu sekundu. Zvláště MAXWAIT je potvora, anžto je běžně nastavena na 32 sekund, po které se čeká, až bude bridge ve "stabilním stavu".
4) ovšem těchto 32 sekund vypadá jako dlouhá doba, nicméně je potřeba v případě, kdy je bridge v režimu STP (což chceme, protože máme různorodou síť a různé způsoby propojení a je potřeba, aby nám tam nevznikaly smyčky a pododně). Což je ale trochu problém, protože pokud nejprve nahodíme bridge a zapneme STP, pak je docela nutností nejprve dlouho čekat na ustálení STP. Pokud tak neučiníme, tak DHCP nefunguje a trvá nějakou chvíli, než to celé začne fungovat.
Moje řešení je v tuto chvíli takové, že nejdřív nahodím rozhraní, ale nezapnu STP - a doufám, že se síť za tu chviličku nezblázní - nechám PC, ať si získá adresu z DHCP - a teprve potom nahodím STP pomocí
post-up
.
Dodatek: To aby PC dostalo vždy stejnou řeším přes ISC-dhcpd asi nějak takto:
host pc1-eth0 { option host-name pc1; hardware ethernet xx:yy:zz:qq:1c:23; fixed-address 192.168.123.123; } host pc1-eth1 { option host-name pc1; hardware ethernet xx:yy:zz:qq:0f:12; fixed-address 192.168.123.123; }
Tiskni
Sdílej:
Pravdou je, že jsem to nikdy na linuxu nepotřeboval, jen na switchích a routerech.Jo, když odpadají licenční problémy, tak tohle bude nejspíš důvod, proč v kernelu RSTP není. Bylo by tam hezké, ale nikdo to vlastně nepoužívá, tudíž se nikomu nechce s tím patlat. Používat bridge jako fyzický switch sice jde, ale řekl bych, že drtivá většina použití bude spojení wifi a ethernetu na nějaké domácí routovací krabičce. Na větší nasazení to má málo portů (protože se do počítače nevejde tolik síťovek) a narozdíl od normálního switche se všechno řeší softwarově. S nástupem virtualizace (a virtuálních síťovek jako portů v tom bridge) by se tohle mohlo trochu posunout, ale neřekl bych, že o moc - připojením jednoho virtuálu do stejného bridge přes několik síťovek žádné výhody nemá (resp. žádné mě nenapadají) a jen si to koleduje o průšvih.
spousta mgmt síťových prvků postavených na linuxuNevím, které prvky jsou tím myšleny, ale pokud jde o switche a podobné*, tak i kdyby v nich byl Linux, určitě nebudou pro přepínání paketů používat kernelový bridge. A nemá smysl dávat do jádra implementaci RSTP pro něco, co se nakonec nepoužije. Tipl bych si, že spíš budou mít userspace proces, který od hardwaru dostane info o tom, že přišel RSTP rámec, a případně něco pošle do sítě. *) moc mi toho pod rukama neprošlo, ale jediný výrobce, který se zatím "přiznal", že mu jako OS běží nějaký open source, je Juniper se svým JunOS - který navíc vychází z BSD, ne z Linuxu.