V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
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