Byl vydán Linux Mint 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Čínská společnost Tencent uvolnila svůj AI model HunyuanWorld-Voyager pro generování videí 3D světů z jednoho obrázku a určené trajektorie kamery. Licence ale nedovoluje jeho používání na území Evropské unie, Spojeného království a Jižní Koreje.
Blender Studio se spojilo s kapelou OK Go a výsledkem je videoklip k písni Impulse Purchase. Stejně jako samotný 3D software Blender je i ve videoklipu použitý animovaný chlápek open source. Kdokoli si jej může stáhnout a upravovat.
Zig Software Foundation stojící za programovacím jazykem Zig publikovala finanční zprávu za rok 2024. Současně s prosbou o finanční příspěvek.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za srpen (YouTube). Vypíchnuta je podpora Tabulek Google, implementace Gamepad API a Cookie Store API nebo také podpora WebGL na Linuxu.
openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »Studentská dílna Macgyver zve na další Virtuální Bastlírnu - pravidelné online setkání všech, kdo mají blízko k bastlení, elektronice, IT, vědě a technice. Letní prázdniny jsou za námi a je čas probrat novinky, které se přes srpen nahromadily. Tentokrát jich je více než 50! Těšit se můžete mimo jiné na:
Hardware – Bus Pirate na ESP32, reverse engineering Raspberry Pi, pseudo-ZX-80 na RISC-V, PicoCalc, organizéry na nářadí z pěny nebo … více »20. črv - 24. črv
Greg KH poslal patch, který kompletně odstraní DevFS z jádra 2.6. Andrew Morton odpověděl: Moc bojím. Možná bychom to měli nechat chvíli v -mm, ať získáme představu o tom, jak moc nás budou uživatelé nenávidět a kolik jich bude. Greg reagoval: Nějaké stížnosti možná budou. Ale pochybuji, že by pocházely od někoho, kdo používá -mm, protože tihle lidi vědí, jak se věci v jádře mají. Už proběhlo mnoho varování o tom, že se chystá odstranění, a čekal jsem _rok_. Žádná distribuce už nepoužívá pouze DevFS (Gentoo skoro, ale nabízí uživatelům i udev a statický /dev). Andrew na to řekl: A co když to začleníme a během následujících čtyř týdnů nás ta smršť přinutí říct "jejda, to jsme (ještě) neměli dělat"? Arjan van de Ven navrhl na pár týdnů zrušit konfigurační volbu a zjistit, kdo si všimne. Andrew i Greg souhlasili, že to bude dobrý test.
Několik lidí se přimlouvalo za ponechání DevFS kvůli množství práce vyžadované pro přechod na udev nebo jiné řešení. Ale další, mezi nimi i ti, kdo byli dříve proti odstranění, se vyjádřili pro. I pro ně byl přechod dost složitý, ale jak řekl Bill Gatliff Říkám to trochu neochotně, ale vidím, že udev je lepší dlouhodobé řešení. Jakmile bude DevFS pryč, bude pro mě snazší si odůvodnit práci, kterou budu mít s plným přechodem na udev.
Mike Bell se rozohněně dožadoval ponechání DevFS:
Jak je jednou DevFS venku, je pryč nadobro. Není dost dobře možné takovou věc spravovat mimo hlavní jádro. Měli byste vědět, že interní jaderná infrastruktura udev byla vyvíjena téměř výhradně v rámci hlavního jádra. A jak dlouho trvalo, než s tím začalo spolupracovat tolik ovladačů.
Bude docela těžké se DevFS věnovat, když nebudou patche začleňovány, protože jistí lidé už se rozhodli, že DevFS není ten správný způsob. Jako příklad může sloužit rychlá a nekomentovaná smrt patchů umožňujících DevFS nad tmpfs.
Nebo si uvědomte, jak dlouho trvalo, než se udev dostalo do povědomí lidí, jak dlouho už tu bylo. Lidi začali na udev přecházet jen díky léčbě šokem v podobě označení DevFS jako OBSOLETE (zastaralé) už v době, kdy ještě udev nebylo vůbec připraveno DevFS nahradit, takže nebylo ani trochu zastaralé.
Greg Mikeovi připomenul, že DevFS už mělo hlavu na špalku více než rok, a uživatelé se na jeho odchod měli připravovat. Řekl, že pokud lidi neplánovali dopředu, je to z větší části jejich chyba, když teď skončili s plnýma rukama práce.
Mike se bránil a flamewar byl na spadnutí, ale Greg řekl: Věnoval jsem ten čas, který bych strávil odpovídáním v této diskuzi (a dalším lidem, kteří z nějakého důvodu neradi píší do konference, a otravují mě místo toho soukromými emaily typu "nemažte devfs"), a napsal jsem náhradu na 300 řádků, včetně všech potřebných háčků v jádře. Pokud tohle nestačí, odpověz prosím ve vlákně s ndevfs patchem. A bylo ticho.
21. črv - 27. črv
Alan Cox napsal:
Staré ISA/VESA systémy někdy dávají čtvrtý IDE řadič na adresu 0x1e8, 0x168, 0x1e0 nebo 0x160. Linux proto tyhle adresy na x86 systémech prověřuje. Některé PCI systémy však bohužel tyto adresy využívají k jiným účelům, což uživatelům způsobuje zamrzání při bootu na minutu i více, někdy i pád.
Následující patch (už je nějakou dobu ve Fedoře) nechává tyto obstarožní a obskurní ISA porty prověřovat jen na před-PCI strojích. Zdá se, že to takhle všem vyhovuje. A pokud má někdo tak podivný stroj, že by to nefungovalo, parametr ide= by měl pomoci. Nepřekvapuje mě, že se neobjevil nikdo, koho by se to týkalo.
Maciej W. Rozycki poznamenal: U MIPS strojů s PCI sběrnicí ověřujeme ISA IDE porty pouze pokud existuje PCI-ISA nebo PCI-EISA most. To by mohlo být řešení i pro x86 a další platformy, které používají PCI. Alan odpověděl:
Primární/sekundární ISA porty se na PC systémech objevují proto, že zařízení třídy PCI IDE jsou v režimu kompatibility, ne v nativním režimu (takže je možné spouštět staré operační systémy). Také existuje pár starších podivných případů.
Kód PCI vrstvy je dost chytrý na to, aby rozpoznal, kdy PCI i ISA test nalezne stejné zařízení. A umí to dát celé dohromady tak, aby byl tento aspekt v pořádku.
Ověřování třetích a vyšších portů není na PCI strojích bezpečné bez ohledu na přítomnost ISA mostů, takže bych neřekl, že to potřebujeme nějak dále komplikovat - nebo jsem něco nepochopil?
Maciej odpověděl:
Kód se mi líbí, ale přemýšlel jsem o tom, jestli by nebyl možný obecnější přístup.
24. črv - 24. črv
Russell King napsal:
Při kompilaci aktuálního git stromu pro ARM vidím:
CC arch/arm/mm/consistent.o arch/arm/mm/consistent.c: In function `dma_free_coherent': arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function) arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once arch/arm/mm/consistent.c:357: error: for each function it appears in.) make[2]: *** [arch/arm/mm/consistent.o] Error 1
Jak zjistím, co se jinde v jádře změnilo a způsobilo tenhle problém?
S BK šlo u daného souboru požádat o historii revizí pravděpodobných kandidátů a pak vyhledat sadu patchů a prohlédnout související změny.
S gitem...? Nemáme historie revizí pro jednotlivé soubory, takže...
Linus Torvalds odpověděl:
Ohó! Reálný příklad toho, jaké skvělé věci git umí.
No, každopádně je první krok naprosto stejný jako u BK, až na to, že syntaxe je dost odlišná, a git to dělá lépe:
git-whatchanged -p arch/arm/mm/consistent.c
Jenže v tomto případě se v daném souboru nic nezměnilo během celé historie gitu, takže dostaneš prázdnou odpověď. Pojďme do fáze dva, ale nejprve odbočka:
Pokračoval komentářem k Russelově zmínce o historii jednotlivých souborů:
Neukládáme změny jako historie revizí souborů, ale ukládáme je tak, že chceš-li zjistit, co se stalo, je to efektivní i u jednotlivých souborů. Zatímco "anotování" řádek po řádku efektivní není, "co se změnilo" efektivní je.
A git to ve skutečnosti zvládá lépe než BK (nebo jakýkoliv jiný software ukládající historie revizí souborů), protože "git-whatchanged" funguje na adresářích stejně jako na samostatných souborech. A pracuje čistě s cestami, takže můžeš provést "git-whatchanged" na souboru, který byl odstraněn, abys viděl, proč byl odstraněn. U většiny ostatních systémů je těžké zjišťovat, co se stalo něčemu, co už tam není.
Zpět. Problém zjevně nevznikl kvůli změnám v tom souboru, takže historie revizí souboru nepomůže. Ale ničeho se neboj, ještě nejsme v háji. Vzhledem k tomu, že víš, že nešlo o změnu v souboru, a protože víš, co se měnilo v ARM kódu, pojmeš podezření, že na vině bude nějaký obecný linuxový hlavičkový soubor.
Takže fáze 2 je:
git-whatchanged -p include/linux
(což zobrazí všechny změny v include/linux, ale jako patche - proto to "-p"). Spustí se stránkovaný výpis výsledků, takže na to půjdeme jednoduše a provedeme "/mem_map", abychom vyhledali změny zmiňující mem_map. Třeba budeme mít štěstí.
Ani tohle moc nepomůže; ale objeví se podezřívavý prstík ukazující na nedávno začleněné věci kolem sparse-mem od Andy Whitcrofta.
A už máš změnu, na kterou je možné se podívat, konkrétně "sparsemem memory model", commit ID d41dee369bff3b9dcb6328d4d822926c28cc2594.
Když se na to dívám, tak se mi zdá, že to je prostě změna konfigurační volby. A bude to asi ta volba SPARSEMEM, která způsobila chybějící podporu DISCONTIGMEM. Ale už máš někoho, na koho můžeš svalit vinu a žádat ho o pomoc: Andy Whitcroft a Dave Hansen, které jsem dal do CC.
Fázi tři bych začal s:
git-whatchanged -p mm/Kconfig arch/arm/Kconfig
ale v tuhle chvíli už máš asi dostatečnou představu, takže už ti je to jedno.
24. črv - 26. črv
Michal Piotrowski napsal:
Představuji náš jednoduchý skript, který pomáhá s vytvářením hlášení o
chybách:
http://stud.wsi.edu.pl/~piotrowskim/files/ort/beta/ort-b1.tar.bz2
<http://stud.wsi.edu.pl/~piotrowskim/files/ort/ort-a5.tar.bz2>
Proč to děláme?
Protože hodně lidí nemá čas na přípravu dobrých (se všemi důležitými
informacemi) hlášení o chybách.
Jak to funguje?
Vytvoří soubor s informacemi o vašem systému (software, hardware, použité
moduly atd.), připojí k němu soubor s oopsem a později vše odešle
zvolenému správci nebo do konference.
Jak můžete pomoci?
Pokud se vyznáte ve skriptování v BASHi, můžete skript zkontrolovat,
přidat užitečné funkce a optimalizovat. Nebo prostě pošlete nápad.
Odezva byla všeobecně kladná a různí lidé nabídli návrhy na vylepšení.
V originálu Kernel Traffic 318 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
30.8.2005 14:00