Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
Hlavním tématem celé konference bylo určení cílů pro další verze standardu LSB (aktuální verze je 3.1, připravuje se verze 3.2 a větší změny se chystají pro verzi 4.0) a stanovení konkrétních úkolů s tím souvisejících. Plány jsou poměrně rozsáhlé a o leckterých pasážích se strhla poměrně značná diskuse. Následuje stručný přehled toho, co bylo odsouhlaseno.
(Poznámka inspirovaná reakcemi na předchozí díl: Všechny údaje čerpám ze svých poznámek a paměti; ani jedno není dokonalé. Pokud něco z toho, co je tu psáno, vypadá jako úplná pitomost, pravděpodobně je to proto, že jsem něco nepochopil, překroutil nebo si to špatně pamatuji. Za všechny chyby se předem omlouvám.)Firmy vyvíjející software chtějí mít vlastní instalátor, nezávislý na balíčkovacím systému, fungující stejně jako ve Windows. Tedy malý program, který uživatel spustí, on všechno nainstaluje, během toho kreslí obrázky, animuje video, ptá se uživatele na různé věci, kontroluje licence a čert ví, co ještě. Leckdo (třeba já) to nepovažuje za moc dobrý nápad, ale oni to prostě chtějí. (Příčin, proč to chtějí, je pravděpodobně víc, od prostého lpění na starých postupech až po fakt, že každé distro má svůj balíčkovací systém a připravovat od každé verze programu dvacet různých typů balíčků by otrávilo i mrtvého.)
Na konferenci jsme se tedy zabývali tím, jak tento nápad umožnit tak, aby napáchal co nejméně škod. Bylo rozhodnuto, že sestavíme oficiální API, které bude nezávislé na balíčkovacím systému. Jak konkrétně to bude vypadat a jak silná vrstva různých pomocných funkcí k tomu bude potřeba, není dosud jasné; v nejhorším případě vznikne druhý balíčkovací systém, zcela nezávislý na tom systémovém.
Zájemcům doporučuji k přečtení tento a tento blogpost Iana Murdocka (jeden z hlavních organizátorů LSB), kde se dosti detailně zamýšlí nad touto problematikou. Také si můžete prohlédnout webové stránky pracovní skupiny LSB pro řešení problému balíčků a instalátorů.
Do standardu LSB v 4.0 by měla přibýt Java. K tomu je třeba stanovit, jaké chování interpreteru Javy se bude považovat za standard a jaké funkce budou garantovány. To není jednoduché, neboť v dnešní době existuje několik různých implementací Javy, které v důsledku různých extenzí, které si každý výrobce sám za sebe přidělal, už nejsou kompatibilní. Tvůrci aplikací psaných v Javě proto raději ke svému produktu rovnou přiloží i celé běhové prostředí Javy. Tento uzel bude třeba nějakým způsobem rozplést, buď standardizací holého základu (který ale bude těžké používat), nebo tím, že si vybereme určitá rozšíření (pak ale nevím, jak to budeme prosazovat).
Součástí další verze LSB standardu bude interpreter Pythonu. Zde je situace trochu jasnější než u Javy, protože různých interpreterů není tolik. Bylo rozhodnuto, že standardizovat se bude originální interpret psaný v jazyce C (CPython), další alespoň prozatím ne. Bude jen třeba rozhodnout, které z mnoha rozšíření Pythonu jsou natolik profláknutá, aby se dala vložit do standardu. Zatím není zcela jasné, zda bude standard zahrnovat i binární rozhraní Pythonu směrem k C a zda by se měl standardizovat i jazyk jako takový (jeho syntaxe) nebo jen stanovit, že interpret musí být schopen bezchybně provádět nějaké konkrétní skripty.
Na konferenci bylo odsouhlaseno, že knihovna D-Bus, sloužící pro komunikaci mezi aplikacemi, je natolik rozšířená, že bude přidána do standardu LSB 3.2 jako volitelný standard.
V rámci obvyklých aktualizací standardu budou do LSB 3.2 začleněny nové funkce, které se objevily v glibc. Přesný soupis najdete zde. Nejzajímavější je patrně rozhodnutí o přidání funkcí *at()
a funkcí týkajících se služby inotify, které jsou sice velmi nové, ale velmi žádané.
Tiskni Sdílej:
Bylo rozhodnuto, že sestavíme oficiální API, které bude nezávislé na balíčkovacím systému.Kam tohle API bude instalovat software? A co udělá, když soubor, který se má nainstalovat, již existuje?
Kam tohle API bude instalovat software?Přece do
/Program Files/Company Label/Version/
.
A co udělá, když soubor, který se má nainstalovat, již existuje?Přepíše. Nač vymýšlet něco nového, když tu máme osvědčené
/opt/third_party/Company Label/Version/
.
A co udělá, když soubor, který se má nainstalovat, již existuje?
To by se při takové organizaci nemělo nikdy stát, a pokud přece, API by mělo odmítnout ten soubor přepsat, případně umožnit uživateli volbu (pokud je to možné).
/opt
, jak stanovuje FHS.
No nevím, raději bych, aby se tyto third-party věci dávali do /opt
, jak stanovuje FHS.
Nebojte, jistě si budete moci vybrat distribuci, která to bude dělat právě podle vašeho gusta
dpkg
v takovém případě instalaci ukamžitě ukončí a NNF se tím pádem nenainstaluje.
A pokud ten soubor bude shodou okolností nějaká knihovna (.so) s nekompatibilní verzí, tak jste v háji, protože buď nebude fungovat NNF nebo zbytek systému. A už musíte buď dokopat výrobce ke změně umístění toho souboru (ale to vám dpkg
taky nedovolí nebo aspoň bude nadávat) nebo k jeho přejmenování.
Máte v plánu, jak vyřešit tohle?
To by se při takové organizaci nemělo nikdy stát, a pokud přece, API by mělo odmítnout ten soubor přepsat, případně umožnit uživateli volbu (pokud je to možné).A když to možné nebude?
rollback()
, která automaticky všecko vrátí. To je ten nejměkčí způsob, spoléhající na to, že autor instalátoru bude slušný a všechny změny bude opravdu dělat skrze to API a ne mimo. (Což se do jisté míry dá staticky ověřit, například ujištěním, že binárka instalátoru se linkuje jen proti našemu API a proti ničemu jinému.)
2. Celá instalace bude probíhat v nějakém druhu karantény (sandboxu), například pomocí chrootu nebo vrstveného filesystému (nemůžu si vzpomenout, jak se ten nástroj jmenuje, ale vy mi rozumíte, že? ), takže když instalátor neuspěje nebo se zhroutí, celý obsah karantény se zahodí a systém zůstane nezměněn.
Uvědomuji si, že "vrácení zpět" není jednoduchá úloha, ale řešit se to dá, například:Je to jednoduché.
2. Celá instalace bude probíhat v nějakém druhu karantény (sandboxu), například pomocí chrootu nebo vrstveného filesystému (nemůžu si vzpomenout, jak se ten nástroj jmenuje, ale vy mi rozumíte, že? ), takže když instalátor neuspěje nebo se zhroutí, celý obsah karantény se zahodí a systém zůstane nezměněn.A přesně takhle to dělá Gentoo. Dokonce není potřeba žádný chroot, prostě instalační skript se na začátku zeptá na prefix cesty, kam má instalovat, a na konci se přesunou soubory na to samé umístění bez prefixu.