Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Amazon koupil společnost Bee zaměřenou na nositelnou osobní AI aktuálně nabízející náramek Pioneer (YouTube) s mikrofony zaznamenávající vše kolem [𝕏, LinkedIn].
Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.
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