Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první stabilní verzi 7.2.5.
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.