Ubuntu 25.10 má nově balíčky sestavené také pro úroveň mikroarchitektury x86-64-v3 (amd64v3).
Byla vydána verze 1.91.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.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
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í
 - 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:
                 
                 
                 
                 
                 
                 
            
    
 4.1.2016 12:18
Max             | skóre: 72
             | blog: Max_Devaine
        4.1.2016 12:18
Max             | skóre: 72
             | blog: Max_Devaine
            
         4.1.2016 18:52
Max             | skóre: 72
             | blog: Max_Devaine
        4.1.2016 18:52
Max             | skóre: 72
             | blog: Max_Devaine
            
         4.1.2016 21:47
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty
        4.1.2016 21:47
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty
            
         5.1.2016 07:13
Max             | skóre: 72
             | blog: Max_Devaine
        5.1.2016 07:13
Max             | skóre: 72
             | blog: Max_Devaine
            
         5.1.2016 14:33
Max             | skóre: 72
             | blog: Max_Devaine
        5.1.2016 14:33
Max             | skóre: 72
             | blog: Max_Devaine
            
        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.
 5.1.2016 15:45
Max             | skóre: 72
             | blog: Max_Devaine
        5.1.2016 15:45
Max             | skóre: 72
             | blog: Max_Devaine
            
        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.
 4.1.2016 19:39
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty
        4.1.2016 19:39
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty
            
         8.1.2016 22:24
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty
        8.1.2016 22:24
Petr Tomášek             | skóre: 39
             | blog: Vejšplechty