Byla vydána OpenIndiana 2026.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
Americký výrobce polovodičů onsemi (ON Semiconductor) zrušil plány na rozšíření výroby v rožnovském závodě v Česku za dvě miliardy dolarů (podle aktuálního kurzu zhruba 43,5 mld. Kč). Důvodem je vývoj na trhu.
O víkendu probíhá na FIT VUT v Brně konference OpenAlt 2026 o otevřeném softwaru a datech, IT bezpečnosti, DIY a IoT. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma. Přednášky lze sledovat i online na VHSky a YouTube.
Qualcomm uzavřel víceletou dohodu se SpaceX. Bude dodávat rádiové technologie, baseband jednotky a software pro plánovanou pozemní 5G síť Starlink Mobile. Výstavba má zahrnovat desítky tisíc základnových stanic v USA. Zahájení nasazování se očekává v roce 2027. Qualcomm dohodu označuje za svůj dosud největší 5G kontrakt.
Google rozšířil Cloud Vulnerability Reward Program. Nově nabízí odměnu až 250 tisíc dolarů za vysoce závažné architektonické bezpečnostní chyby označované jako Root-in-Cloud.
V březnu byla oznámena spolupráce GrapheneOS s Motorolou. Nejnovější vlajka Motorola Signature 27 je první Motorola s oficiální podporou GrapheneOS. GrapheneOS (Wikpedie) je varianta Androidu zaměřující se na bezpečnost a soukromí.
Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Na MojeFedora.cz byl vydán třídílný seriál na téma Docker ve Fedoře: Začínáme s Dockerem na Fedoře, Stavíme svůj první Docker kontejner a Docker obrazy nejen pro Fedoru.
Tiskni
Sdílej:
Zdá se mi to, nebo tohle potírá právě tu výhodu sdílených knihoven, jakou linux přináší?
Sračky vevnitř jsou jiný problém, který s dockerem nemá mnoho společného. Problém je, že docker neškáluje.
Nahoře se je dotaz, jak se aktualizují knihovny uvnitř kontejneru. Odpověď je, že se sestaví nový obraz z opravených knihoven. Problém je, že takový obraz může mít stovky megabajtů, které se musí při instalaci přenést na každý stroj. Docker sice umí přenášet rozdíly mezi obrazy, ale jen po linii dědičnosti obrazů. Jenže systémové knihovny jsou obvykle schovány v dalekém předku, takže to nemá smysl.
Jiný přístup je v existujícím obraze zaktualizovat jednu knihovnu a rozdistribuovat nový obraz jako poděděný rozdíl. Tohle škáluje při instalaci, ale ne při samotné aktualizaci. Pokud totiž takových obrazů pro různé produkty máte na starost stovky, tak přestává být možné udržet si přehled, který jste už aktualizoval, který ne a který aktualizaci nepotřebuje. Takže jste nakonec tam, kde jste byl před tím s klasickou distribucí s balíčky.
To že docker pužívají hostingy jako "vps", to že docker na produkci instalují programátoři, to že většina balíčků ve veřejném hub jsou sračky napsané zase jen programátory je realita, z které ale také nejsem nadšeny.Ta snaha navazet se do programatoru je komicka. Z dobreho programatora se znalosti systemu je jednoduzsi udelat administratora nez naopak, a tim se nezastavam lidi kteri nekam placnou ubastleny docker a pak se vykaslou na udrzbu.
Pokud programátor zná linux, žádný problém, potkal jsem ale desítky programátorů a opravdu znalost linuxu není častá ;)Totez plati od adminech. Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.
Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.:D
To, co se běžně prezentuje jako kontejnery, ano.
Docker umí údajně využít i unionfs a to už by mohlo být zajímavější - spousta knihoven by se dala "zabalíčkovat" do menšího množství vysokorúrovňových obrazů, nad kterými by se stavěly samotné aplikační kontejnery. V případě bezpečnostního problému by se prostě vytvořil nový image opravené knihovny.
Kromě nevýhody drobné ztráty místa na disku to má nespornou výhodu - vyšší vrstvy můžete "přesunout" na fixnutou verzi až budete chtít, ne s dalším restartem služby nebo stroje. Nad tímhle zajásá každý, kdo musí udržovat closed-source kritické firemní aplikace, které psala banda neandrtálců a které se podaří nastartovat až na 3. pokus a s tou správnou verzí libm. 
Kontejnery mají smysl hlavně u služeb, které mají více daemonů, stavových souborů či socketů někde ve /var - dají se schovat do jednoho kontejneru se snadným on/off vypínačem, který nejenže "čistě" zabije všechny související procesy, ale odmountuje všechny mountpointy, uvolní sdílené IPC prostředky, apod.
A co teprve použití takovýchto kontejnerů s btrfs snapshoty -- je libo bezstavové služby?
Nevýhoda? Někdo by musel udržovat vrstvené obrazy podobně jako distribuce udržují balíčky a to se nikomu nechce.
Je daleko jednodušší do kontejneru nacpat celou distribuci a v ní spustit jednu službu.