Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
Ohledně balíčkovacích systémů jsem tzv pole neorané. Přečetl jsem si tisíc flamů po internetu, desítky popisů v encyklopediích a různých wiki, ale odpověď na mou otázku jsem nedostal. Dnes jsem narazil na tento slade: RPM benefits
Jako uživatel suse a ubuntu znám rpm a deb pouze z uživatelského hlediska. Porovnám-li ubuntu/deb a suse/rpm, pak jedine prakticke závěry, ktere jsem schopen vyvodit jsou, ze v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.
Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm. Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva. Což je další výoda pro deb.
Jedina vyhoda, kterou jsem u rpm zaznamenal je delta-rpm, ovšem to je asi susí specialitka, mimo to update suse je i tak mnohem zdlouhavejší nez update ubuntu.
Zajímalo by mě tedy, v čem jsou takové výhody rpm, že jej využívá mnohem více distribucí než deb?
Asi jsem natvrdlý, neb mi to nějak nedochází, a nebo je to absencí praxe, kterou ovšem nevyčtu po manuálech.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czrpmrebuild, ale používá na to /usr/bin/build
2. Pokud dojde k problému při x86_64 s přeinstalováním půlky systému tak je to prostě na bugzillu.
3. To že v závislostech debianích balíčků by byl menčí bordel kvůli tomu, že by záviseli jen na balíčcích samotných je pěkná hloupost 
Výhoda debianu je v tom, že má policy takové jaké má a tedy, že v jeho repositářích může růst každý balíček a nedochází tam tak k situacím jako například v openSUSE, kdy polovina balíčků roste v Packmanovi, který neumí při změně závislosti libA přebuildit všechny aplikace které na libA závisí. Proto musí aktualizace hlídat balíkáři, kdyby byly ty balíčky součástí distribuce, tak by si to ohlídal autobuild a balíčky by tak byly konzistentní. A ani závislosti jen na balíčcích k ničemu nepomůžou... Mimochodem ono se to automatické registrování závislostí dá vypnout a pak to může být přesně jako v debianu... 
v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.Na druhou stranu možnost souborových závislostí zase zjednodušuje práci vývojáře. Výhoda není tak jednoznačná na jedné ani druhé straně.
Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Já jsem četl pravý opak. Sám dělám ale pouze RPM balíčky, takže nemůžu srovnávat.
Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.Ne, žádná taková potřeba neexistuje, to by byla pitomost.
Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.Ony ty nejpoužívanější 32bit balíky mají verzi pro architekturu AMD64. Rozdíl je IMHO v tom, že Debian udělá změnu AMD64->i586 pouze na výslovné přání uživatele. RPM distro tu změnu na výslovné přání neudělá. Výsledek je de-facto stejný, jen mi přijde, že RPM musím kvůli tomu více hlídat pokaždé, když něco instaluju.
ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.To je naopak velmi nedoporučované. Vše v RPM samozřejmě závisí na uživatelském nastavení, žádné takové "absolutní povinné cesty" neexistují.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Nevím, ve vytváření deb balíčků se nevyznám. Nicméně k vytvoření RPM vám stačí jeden .spec soubor (něco jako recept na sestavení) a jeden soubor se zdrojovými kódy (tarball). To mi připadá velmi přehledné.
Je třeba mít na paměti, že množina distribucí používajících RPM je značně heterogenní. DEB balíčky byly donedávna výsostnou doménou Debianu, to spoustu věcí zjednodušuje. K výhodám RPM: co třeba rollbacks ? To se může docela hodit.
22.9.2008 15:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
22.9.2008 21:46
belisarivs | skóre: 22
| blog: Psychobláboly
Mne na rpm chybi urovne zavislosti jako v Deb. Cili neco jako - depends, recommends, suggests.Škoda, že máme každý jiné suse :D Software Management/Dependencies
23.9.2008 10:03
belisarivs | skóre: 22
| blog: Psychobláboly
22.9.2008 14:22
22.9.2008 14:38
23.9.2008 08:23