Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
Řešením této situace, kdy balíčky mezi všemi distribucemi a jejich verzemi jsou vzájemně nekompatibilní, by bylo vytvořit program, který by podle zadaných metainformací sestavil balíčky pro všechny možné distribuce a verze. Balíčky by pak už nedělali tvůrci distribucí, ale samotní autoři programů, čímž by odpadlo mnoho problémů. Je jasné, že třeba řešení typu debian, kdy distribuce bude obsahovat úplně všechno, je do budoucna neúnosné.
Je třeba vytvořit něco, co bude podporovat různorodost balíčkovycích systémů, protože snahy o sjednocení (každý bude používat rpm, xxxpm, ...) jsou nereálné. To dá ale dost práce, do které se nikomu nechce.
Nastíním, proč si myslím, že toto není řešení.
Například v Debianu existuje nástroj alien, který umí překonvertovat rpm, tgz, ... do .debu, který pak lze přímo nainstalovat. Jenže ten původní balíček je dělán pro jinou distribuci, kde je třeba adresářová struktura vyřešena jinak než v Debianu (zrovna Debian má dost přísné podmínky, co musí splňovat každý balíček - debian policy). Hodně je to vidět třeba u init scriptů, Slackware používá BSD like, ostatní sysvinit like. Potom je tu problém s jinými gid vyhrazenými u té které distribuce. O závislostech nemluvě.
Je toho samožřejmě mnohem víc, co způsobuje, že alien nemůže plnohodnotně konvertovat rpm nebo tgz balíček na deb. A cokoliv co není deb způsobuje v Debianu problémy, prostě to nebude nikdy čistě fungovat.
Proto si myslím, že je lepší, když tvůrce balíčku místo rpm/debu vytvoří jakýsi metabalíček s tím, že už bude počítat s rozdíly mezi distribucemi, a tento balíček následně použije na výrobu výsledných rpm, deb, tgz, cokoliv ..., které už jsou kvalitní, protože všechno už obstaral program, který přežvýkal metabalíček na rpm, deb, ...
Nejde tu jen o to fyzicky překonvertovat balíček do výsledného formátu, ale o to, aby balíček měl určitou kvalitu. Nikomu by se nelíbilo, kdyby si nainstaloval binární program někam do /etc nebo /usr/share.
Proto taky tezce doporucuju pouzivat konzistentne vetsinu veci z jedne distribuce -- ovsem upkg jakozto backend umoznuje v pripade chybejiciho balicku jeho trivialni instalaci.
Ale přístup "každá distribuce bude obsahovat vše" je do budoucnosti neudržitelný. Ve winech se instaluje každý program přes setup.exe, který si může dělat co chce, nemusí zajistit korektní odinstalaci, etc., ale každý si může nainstalovat program přímo od výrobce. Mně tu jde o to, aby byla ta samá možnost i v linuxu, ale aby se využívalo výhod balíčkovacích systémů. Výrobce by mohl snadno vydat sadu balíčků pro všechny více používané distribuce a k tomu by vydal zdrojový metabalíček, pomocí kterého by si uživatel minoritní distribuce mohl binární balíček už sestavit jednoduchým způsobem a nemusel by instalovat někam do /usr/local.
Metabalicek je uz technicky vzato tezko implementovatelna vec... uz jenom proto, ze kazda distribuce ma mirne jinou hierarchii atd., jak jsi popsal vyse.
Já si myslím, že udělat jde. Prostě tvůrce programu by vytvořil určitý soubor (obdoba spec filu nebo debian/control), který by obsahoval informace, jak balíček zkompilovat, co obsahuje, atd. a předhodil by to tomu nástroji. Ten by z toho sestavil source balíčky pro distribuce, pro které by bylo třeba. Pak by se třeba v chrootu nebo přímo na těch distribucích tyto balíčky prohnaly kompilátorem a binární balíčky jsou na světě.
Šlo by tím tvořit balíčky i pro různé architektury, což bude do budoucna důležité. x86_64 bude používat stále více lidí. Zdrojový balíček by už existoval a v chrootu s cross-compilerem by se jenom sestavil binární balíček pro x86_64.
Je tu i hodně zádrhelů. Kdyby chtěl vývojář tvořit balíčky pro mnoho dister, musel by mít hodně chroot prostředí a to by zabíralo místo. Ten samotný nástroj by bylo jistě těžké napsat, protože by musel ošetřovat vlastně všechno, co může balíček obsahovat - binárky, manuálové stránky, game binárky, konfigurační soubory, /var/games/..., dokumentace, info soubory, /usr/share/..., menu soubory, preinst a postinst (ty by se nemohly psát přímo), init scripty (ditto), knihovny, /bin, /sbin, atd.
Nešlo by to třeba používat na moc složité balíčky, které by třeba obsahovaly jaderné moduly (to by byl asi dost problém). Pak by se muselo ošetřit všechno možné, co se dá dělat v preinst a postinst scriptech pomocí generických volání, to samé pro init scripty. Dále třeba funkcionalita alternatives v Debianu, nevím jak jsou na to ostatní distra.
To, ze nektery balicky jsou smejdy nejvetsi, je smutna vec -- ale to riziko na sebe clovek bere kdykoliv, kdy bere balicek mimo distribuci (a i v ramci distribuce jsou obcas hodne zajimavy ulety)
Právě ten balíček, co by byl vytvořen tímto postupem, by měl zajištěnu určitou kvalitu třeba ohledně preinst a postinst scriptů a souborové hierarchie.
Zkusím to vysvětlit ještě jinak, o co mi konkrétně jde.
Tvorba balíčku = adaptace na konkrétní distribuci. Když je program rozumně vytvořený (tzn. používá autoconf, automake správně, rozumí cestám, které jsou mu předány pomocí ./configure parametrů), tak je ta adaptace celkem snadná. Pak vůbec nezáleží na tom, jestli distribuce dodržuje FHS nebo ne. Je akorát třeba stvořit preinst a postinst, vytvořit popisek balíčku, atd. To je pro každou distribuci vlastně stejné, takže by to šlo dělat genericky.
Tvůrce programu by se musel držet při tvorbě Makefilů nebo configure.ac/Makefile.am zdravého rozumu a nepoužívat různé špinavé triky. To by měl vlastně dělat i když nebude pak program balíčkovat on sám. Takovýto program je pak vcelku snadné zabalíčkovat, je to generický postup. A hlavně je pro většinu distribucí stejný. Jenom je v každé distribuci něco odlišného, třeba Slackware neřeší závislosti, Debian má priority a sekce balíčků (u rpm nevím, jak je toto vyřešené), a tak dál.
Prostě si myslím, že balíčkování je zbytečná činnost, která by se nemusela dělat, kdyby autor programu dodržoval jisté (přesně dané) konvence a balíčkovaní by potom mohlo proběhnout strojově.
V žádném případě se tu nesnažím vytvořit utopii, jen si myslím, že jistá činnost se zbytečně duplikuje při tvorbě balíčku jednoho programu pro různé distribuce.
Není už těch balíčkovacích systémů nějak moc?<fb> Je. Navíc když už tu 12 let spolehlivě funguje Slackware package management
</fb>
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz