Byla vydána nová verze 4.8.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 142 (pdf) a HackSpace 79 (pdf).
Qtractor (Wikipedie) dospěl do verze 1.0.0. Jedná se o Audio/MIDI vícestopý sekvencer.
Byl vydán svobodný kancelářský balík OnlyOffice Docs 8.1. Vedle četných oprav přináší několik funkcí včetně podpory editace textu v PDF a vytváření formulářů v PDF.
Daniel Stenberg, autor nástroje curl, z databáze SteamDB zjistil, že aktuálně 22 734 her na Steamu používá curl.
Společnost Anthropic vydala Claude 3.5 Sonnet, tj. novou verzi své umělé inteligence Claude (Wikipedie). Videoukázky na YouTube. S Claude 3, stejně jak s GPT-3.5, Llama 3 a Mixtral, si lze pokecat bez přihlašování na DuckDuckGo AI Chat.
Byla vydána nová stabilní verze 6.8 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 126. Přehled novinek i s náhledy v příspěvku na blogu a na YouTube. Vypíchnuta jsou vylepšení v integrovaném poštovním klientu.
Příspěvek Aukce domén – měsíc po spuštění na blogu CZ.NIC shrnuje první měsíc provozu Aukce domén .CZ. Aukcemi prošlo celkem 18 174 domén, z toho na 742 z nich byl učiněn alespoň 1 příhoz. Nejdražší aukcí byla na doménu virtualnisidlo.cz s cenou 95 001 Kč, která však nebyla včas uhrazena. Nejdražší aukcí, která byla vydražena i zaplacena je praguecityline.cz s cenovkou 55 600 Kč.
Před 40 lety, 19. června 1984, Bob Scheifler představil první verzi okenního systému X (X Window System). Vycházela z okenního systému W (W Window System).
Desktopové prostředí MATE bylo vydáno ve verzi 1.28. V gitových repozitářích je sice už od února, ale oznámení vydání se na webu objevilo s několikaměsíčním zpožděním (únorové datum zveřejnění je nepravdivé). Jde o první velké vydání od roku 2021. Uživatelsky nejvýznamnější pokrok je v podpoře Waylandu.
Rodney Dawes začal pracovat na novém balíčkovacím systému Empulse. Není už těch balíčkovacích systémů nějak moc?
Tiskni
Sdílej:
Ř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>
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz