Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Řadu instalačních úkonů nelze převést na jednoduché vytvoření souborů, které by šly zabalit do rpm, a je zapotřebí je provést až na cílovém systému. Patří mezi ně zejména:
/sbin/alternatives),ldconfigem,fonts.dir, fonts.scale a spol.,chkconfigem,scrollkeeperu,A k tomu slouží skriptíky (scriptlets) – skripty zabalené do rpm a spouštěné při instalaci či odstranění balíčku, případně jiných příležitostech. Ve spec souboru vypadají podobně jako skripty vykonávající jednotlivé fáze balení; jednoduchý poinstalační skriptík může vypadat např.
%post /sbin/ldconfig
Instalační skriptíky se spouštějí při instalaci či odstranění balíčku. K disposici máme tyto:
%pre%post%preun%postunTo tedy zní pěkně zmateně. Klíčem k pochopení je, že aktualizace probíhá tak, že se nejprve nainstaluje nová verze, a pak se teprve odinstaluje stará verze balíku (co se týká souborů, tak ty jsou v tu chvíli obvykle již přepsány novými, tudíž toho moc ke smazání nezbývá). Aktualizace tedy vypadá:
%pre.%post.%preun.%postun.V případě obyčejné instalace, resp. odstranění, proběhnou jen body 1-3, resp. 4-6. Aby
i skriptíky trochu tušily, co se děje, dostávají jako první argument, $1, kolikrát je balík právě nainstalovaný (přesněji kolikrát bude nainstalovaný po dokončení právě probíhajícího úkonu) – a nemělo by nás už překvapit, že je to občas více než jednou. Hodnoty $1 shrnuje následující tabulka:
| Akce | Skriptík | $1 | |
|---|---|---|---|
| Instalace | rpm -i |
%pre, %post | 1 |
| Aktualizace | rpm -U |
%pre, %post | 2 |
| Aktualizace | rpm -U |
%preun, %postun | 1 |
| Odstranění | rpm -e |
%preun, %postun | 0 |
Je-li kupříkladu zapotřebí provést nějaký úkon až po definitivním odstranění balíku, otestujeme hodnotu $1 na nulu:
%postun if [ "$1" = 0 ]; then … fi
Jednotlivé skriptíky je možno při instalaci zakázat volbami --nopre,
--nopost, --nopreun a --nopostun. Všechny čtyři zakáže volba --noscript.
Ověřovací skriptík se jmenuje %verifyscript a spouští se při
rpm --verify. Může zkontrolovat konzistenci balíku ve věcech, které rpm nekontroluje, a vypsat o tom zprávu na standardní výstup nebo chybový výstup.
Pokud je mi známo, nemůže způsobit stejné selhání ověření jako třeba chybějící soubor. Může sice skončit chybou, ale tu rpm považuje za fatální, jako když selže kterýkoli jiný skriptík. Navzdory této podstatné vadě se občas využívá.
Transakční skriptíky jsou novinka ve verzi 4.4. Podobají se instalačním, ale rpm je spouští úplně na začátku nebo na konci celé transakce – instalace/aktualizace/odstranění skupiny balíčků. Existují dva:
%pretrans%posttransSpouště (triggers) mohou při neopatrnosti způsobit pěknou spoušť, jelikož pravidla pro jejich spouštění jsou ještě zmatenější než u instalačních skriptíků. Od nich se vlastně liší jen v jedné zásadní věci: instalační skriptíky se provádějí při instalaci balíčku, který je obsahuje, kdežto spouště tiše číhají na instalaci či odstranění jiného balíčku, a teprve při ní se spustí.
Spouští jsou tři typy, které odpovídají instalačním skriptíkům. Jen ekvivalent
%pre chybí, neboť příliš nedává smysl číhat na chvíli těsně před tím, než se začne instalovat nějaké jiné rpm – libovolnou činnost může balíček stejně dobře vykonat rovnou při své vlastní instalaci.
%triggerin%triggerun%triggerpostunBalíček, na nějž se má číhat, dáváme jako argument daného skriptíku, a to za dvojpomlčku (ve stylu GNU argumentů programů). Balíček nemusí být jen jeden, můžeme jich uvést několik oddělených čárkami, a dokonce s verzemi, zcela stejně jako u závislostí. Spoušť se pak aktivuje při instalaci (odstranění) kteréhokoli z nich.
%triggerin -- lobster > 1.7, perl < 6.0
Instalačním skriptíkům rpm předává jeden argument, a to počet nainstalovaných instancí balíčku. Spouště musejí být složitější, a proto dostávají dva argumenty: první je stejný, druhý je počet instancí balíčku, jenž spoušť aktivoval.
Budeme teď muset trochu revidovat popis, co se vše děje při aktualizaci (existuje-li to):
%pretrans (úplně na začátku).%pre.%post.%triggerin aktivované instalací nového balíku.%triggerun aktivované odstraněním starého balíku.%preun.%postun.%triggerpostun aktivované odstraněním starého balíku.%posttrans (úplně na konci).Spouště jsou vcelku náchylné k zareznutí a balíčky se spouštěmi jsou de facto vždy vázány na jednu distribuci. Srozumitelný a smysluplný příklad z praxe je snad passivetex, jenž obsahuje jak formáty nezávislé na LaTeXu, tak LaTeXové. Po instalaci LaTeXu, tj. balíčku tetex-latex, proto znovu vygeneruje své formáty, čímž se doplní i ty specificky LaTeXové:
%triggerin -- tetex-latex
/usr/bin/env - PATH=$PATH:%{_bindir} fmtutil \
--cnffile %{_datadir}/texmf/tex/xmltex/xmltexfmtutil.cnf --all \
> /dev/null 2>&1
exit 0
„Čisté“ řešení by zde snad mohlo být rozdělení balíčku, ačkoli zrovna u těch TeXových by důsledné rozdělování vedlo k nepřehlednému chaosu stovek pidibalíčků s pár makry.
Jednotlivé spouště je možno při instalaci zakázat volbami --notriggerin,
--notriggerun a --notriggerpostun. Všechny tři zakáže volba
--notriggers.
Zatím to vypadalo, že skriptíky interpretuje shell, a kdybychom je chtěli psát v Haskellu, máme zkrátka smůlu. Ale nic není tak jednoduché, jak to poprvé napíši – v tomto případě naštěstí. Každý skriptík přijímá argument -p interpret definující program, který má skriptík interpretovat. Implicitní je shell. Interpret je nutné zadat s plnou cestou. Verze 4.4 navíc přidává hodnotu interpretu <lua>, určující, že má skript vykonat interpret Lua zabudovaný do rpm.
Nic nám tedy nebrání – tedy nic kromě obavy ze ztráty důstojnosti – napsat poinstalační skriptík takto:
%post -p /usr/bin/tcc
#include <unistd.h>
int main() {
execl("/sbin/ldconfig", "ldconfig", 0);
return 1;
}
Volba -p se často využívá, či spíš zneužívá, ještě k jinému účelu. Chceme-li totiž spustit jen ldconfig, je zbytečné spouštět shell, aby spustil ldconfig. Určíme tedy ldconfig jako „interpret“ prázdného skriptíku:
%post -p /sbin/ldconfig
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: