Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Do konference přišlo celkem 853 emailů, nejvíce jich poslali "Martin J. Bligh", John Bradford, Greg KH.
Během diskuse David S. Miller poznamenal, že celý model fbdevu
je hrozný, že dělá závěry, jak se přistupuje k registrům a paměti
videokarty a mnoho populárních karet vůbec nepasuje do tohoto
modelu. James Simmons souhlasil, že design rozhraní /dev/fbX
není nejlepší, bohužel na něm uvízli. Jeho změna by totiž narušila
uživatelské nástroje.
David odpověděl, že to chápe a nenavrhuje rozbít současnou formu
fbdevu, neboť na něm závisí příliš mnoho nástrojů. Chtěl jen
upozonit, že mnoho X serverů jako třeba ovladač ATI jej vůbec
nepoužívají a místo něj mmapují zařízení a programují jej přímo.
Fbdev je pěkný v těch případech, kdy karta přesně padne na jeho
model, protože po naprogramování podpory v kernelu máte ihned k
dispozici podporu X Window Systému 
.
Antonino Daplas napsal Jamesi Simmonsovi, že když se rozhraní pro fbdev stabilizovalo a dostalo do stromu jádra, posílá mu ovladač grafických čipů Intel 810/815 k náhlednutí a snad i začlenění do jeho větve a doufejme že i sloučení s Linusovým stromem. Patch je vůči jádru 2.5.51, ale nebude fungovat z dvou důvodů:
Po vyřešení prvního problému bude ovladač fungovat jako modul. A po přidání #2 bude možné ovladač zkompilovat staticky. Dave Jones již má #2 ve svém stromu a pracuje na #1 (doma má hacklou verzi).
Ovladač je kompatibilní s fbdev verze 2.5 a podporuje všechny očekávané vlastnosti (modularita, ukládání stavů, plná podpora hardwaru atd.). Ovladač bude fungovat s nativním i810 ovladačem XFree86 bez nutnosti úprav a to celkem stabilně. Najdete jej na adrese http://i810fb.sourceforge.net/linux-2.5.51-i810fb.diff.gz. James odpověděl stručně: Aplikováno.
Miles Bader zaslal patch a Linus Torvalds jej požádal:
Mohl bys zasílat patche standardním způsobem? Tedy
diff -ruN linux-old-dir linux-new-dir
takže mohou být čistě aplikovány pomocí patch -p1 a hlavičky
diffu vypadají nějak takto:
--- xxxx/arch/v850/vmlinux.lds.S +++ yyyy/arch/v850/vmlinux.lds.S
protože všechny moje nástroje očekávají patche v tomto tvaru. Tentokráte jsem to aplikoval ručně, ale je to otravné a protože jsem (většinou) líný, končí to tím, že zahazuji patche, které nejdou čistě aplikovat.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz