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.
Před časem jsme se doslechli o projektu FatELF, který po vzoru univerzálních binárek pro OS X umožňoval mít několik binárek pro různé architektury v jedné. Ryan C. Gordon, autor, byl však znechucen a odrazen přístupem lidí od jádra a glibc, kteří jeho patche odmítli a nemají ani zájem na jejich zařazení. FatELF je tedy pravděpodobně mrtvé. Více na Phoronixu.
Tiskni
Sdílej:
A kto sa má postarať o to, aby to fungovalo? Kto napr. bude testovať knižnice, či fungujú na potrebných platformách, kto sa postará o úpravu perl, python... a ďalších vecí, ktoré majú architektúru zakomponovanú aj do adresárovej štruktúry... (a podobných problémov je viac)?
Ak niečo také potrebuje niekto, kto také niečo chce využívať pri svojich binárnych súboroch, nič mu nebráni sa o všetky problémy postarať a potom bude väčšia šanca, že sa sa potrebné zmeny dostanú aj do jadra. Navyše potrebná funkcionalita sa dá dosiahnuť aj inými spôsobmi už dnes.
Kompatibilita binárok nie je problém Linuxu, skôr je to problém (pravdepodobne väčšiny) knižníc. Ak mi nevadí, že mám kopec starých verzií knižníc (ako to funguje napr. vo Windows, kde mám 13 verzií d3dx9_*.dll), tak mi budú fungovať aj dosť staré binárky.
Nedávno tu bol odkaz na odpovede Nvidia vývojára na rôzne otázky, a kompatibilita s knižnicami nebol až tak veľký problém.
Následně si ale pak bude linuxová komunita stěžovat na důsledky této ideologie, jako například, proč je tak těžké najít dobrý CAD, či účetní program do Linuxu, a proč je na Windows daleko větší výběr. Proč není verze Photoshopu, či Corelu pro Linux, atd. Už jenom vytvoření a distribuce binárky (poté co máte hotový a odladěný zdrojový kód) pro Linux je mnohem dražší a s mnohem více úskalími, než pro Windows.A nestěžuji si čirou náhodou jistá skupina do které spadá i p. Ponkrác? Či není to spíš vysněný svět p. Ponkráce? Vždyť už přeci jeden systém na kterém jede ten Photoshop a existují pro něj CADy, atd. už máme, tak nač ten druhý? A nebo snad někdo někomu brání ho využívat? Jo a ještě jedna poznámka: Neexistuje žádné Windows/Linux na té úrovni jak ho tady neustále prezentuje p. Ponkrác. Když tak, tak už GNU nebo prostě otevřený software, který nemá nejmenší problém běžet na jakékoliv platformně – třeba i Windows. Takový systém, který tu prezentuje p. Ponkrác existuje jen jeden: Microsoft Windows.
Já jsem si chtěl stěžovat, ale vykašlal jsem se na to. Nemá to cenu.
Problémy GNU/Linuxu, které mně (a dalším) hází klacky pod nohy, jsou:
/opt/, ale rozesraný v /usr/, ve /var/ a bůhví kde ještě. Když má uživatel nainstalováno více programů — což na desktopu zpravidla má — jsem téměř v koncích něco dohledat. Adresáře typu /usr/share/ obsahují prostě příliš mnoho položek a manuální práce s nimi je téměř nemožná.Osobně jsem se zařídil takto:
/usr/share/, ať si to tam klidně založí.
Primárně se však instaluje do /opt/./opt/. 
Svůj software zásadně distribuuji se zdrojovými kódy. A to tak, že se všemi! Pan Ponkrác nahoře krásně popsal, že snahou komunity je šířit vše cestou zdrojových kódů. Binární kompatibilita je opravdu — slušně řečeno — diskutabilní.
Tak mi tedy vysvětli, proč si přes warezprotokol (torrent) můžu stáhnout tisíce verzí binárních obrazů — kolikrát není ani jiné cesty a musím hledat jiný mirror, který milostivě distribuuje to co potřebuji i přes FTP — ale žádný distribuce-verze-src.iso neexistuje? Proč musím skriptovat FTP klienty a stahovat tisíce souborů? Asi mám být vděčný, že nemusím používat cvs export či svn export, že?
Tím chci říct, že všichni se chvástají, jak je všechno free a open, ale tak blbě dostupné, že mám beztak smůlu. A to se netýká jen distribucí. To se týká i knihoven od Apache Foundation. Každou chvíli narážím na knihovny, které mají závislost na uzavřeném systému. Jak to kompilují? Je to vůbec legální? Přece si kvůli (tuším) commons-logging nebudu kupovat licenci na IBM WebSphere!
A abych to uzavřel. Nějaký FatELF je opravdu zbytečný, když je to celý v tak děsnym bordelu, který je nekompatibilní sám se sebou. Někdo tu plácnul, že Applí Universal Binaries zmizí. Prý pro nové verze programů. Já si to nemyslím. Třeba Adobe bude určitě ještě nějaký ten pátek podporovat PowerMacy (G5) a OS X 10.4.
Co se komerčního využití a FatELF týče, nikdo nebude strkat do jedný binárky úplně všechny architektury. Myslím si, že by beztak vyhrálo x86, x86_64 a možná ARM. A mluvit v případě mizivého procenta aplikací, kterých by se to týkalo, o zaplnění diskového prostoru či ucpání internetu je opravdu mimo.
Ale jsem rád, že jsem si touto diskuzí ověřil, že o nativní komerční (uzavřené) aplikace pro GNU/Linux opravdu není zájem. 

To se týká i knihoven od Apache Foundation. Každou chvíli narážím na knihovny, které mají závislost na uzavřeném systému. ... Přece si kvůli (tuším) commons-logging nebudu kupovat licenci na IBM WebSphere!Jaký je problém s http://www.apache.org/dist/? Zrovna Apache se vyznačuje tím, že svoje zdrojové kódy poskytuje v poměrně rozumné formě. Daleko větší problémy jsem zaznamenal u Suních projektů na dev.java.net, které jsou často neaktualizované a plné podivných licenčních ujednání. Nemluvě o projektech typu openproj, kde není možné se ani dopátrat, kde všechny zdrojáky vlastně rostou.
o nějaké neoficiální hacky, které se sami vyřadili ze hry tím, že nejsou svobodné nikdo neřeší a řešit moc ani nebudeJeden hack stále né a né zaniknout — Wine.
x86_64? Když je to tak svobodný a svatý, pak jsou v té nepodpoře Software602 nevinně a je to tedy selhání komunity. No neříkej že ne!
uname -m nebo ve firefoxu do Nápověda->O aplikaci Mozilla Firefox. A pokud jde o binární bloby, že by se ušetřilo místo za data, tak to se řeší oddělením noarch části s daty.
Šlo by jen o alternativu pro speciální případy, kdy by se to hodilo.Prosil bych příklad.
) k tomu napsal velice podrobnou analyzu: ELF should rather be on a diet
), tak by se to stejně moc neuchytilo.