Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.14.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Byla vydána nová stabilní verze 6.10 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Author: Miloš Jakubíček (AToL - PV208, FI.MUNI)
The general purpose of binary packages (no matter what format they use), or to be more precise, package management systems, is to provide a prebuilt software including related metainformation in a from that can be used to enable the users and administrators to easily maintain (i. e. install, upgrade, remove etc.) the systems and applications programs so that the system remains consistent and its resources are used in a efficient way.
To achieve this, several standard methods are in use such as centralized package repositories, dependencies detection mechanisms, automated updates etc.
There are various package formats which differ in their internal structure, features or available functional overlays for yet advanced management, but probably most widespread are RPM, deb and TGZ formats.
The RPM (the abbreviation stands for Redhat package management according to the original vendor) format is used e. g. in SUSE/openSUSE,Mandriva, CentOS and of course also RHEL and Fedora.
The deb(ian) format can be found especially on Debian-based distributions such as Debian or Ubuntu and TGZ is actually not a standardized package format as there are several (in most cases smaller) distributions (ArchLinux, Slackware, . . . ) which use tar&gzip to store their binary packages (in wide range of formats).
In this paper, I would like to concentrate on the comparison between deb and RPM format as these formats are most widespread nowadays and provide the richest features. There is also a conversion tool between RPM and deb called alien under development.
A standard way of packaging a program using RPM is to create a SPEC file containing all the metainformation about the package such as name, version, release (often abbreviated as N-V-R), runtime and buildtime dependencies, various installation scripts (called scriptlets) or triggers (event-driven scripts which can be executed when a specific action of another package occurs – like installation, update, uninstallation, . . . ) etc.
Further, an SRPM (source RPM) is created from the SPEC file and all source files which can be used to easily build the package or distribute the package sources. From this SRPM one or more final RPMs are created to be installed on the target systems. There is also useful program for automated checking well-formed SPEC files and RPMS called rpmlint.
The deb package structure consist of three main components: first it is the debian-binary file containing the format version number, second, there is a control.tar.gz package entailing all the metainformation about the package similar to the RPM SPEC file, however separated into many files (such as the control file with general metainformation or installation scripts which are each in a separate file too).
Finally as third, there is a data.tar.gz package where all the binaries and other applications programs files are stored. The counterpart of RPM’s rpmlint is lintian.
First of all, I should anticipate that there are several aspects which are hard to compare but important to consider. One of them is that each distribution usually defines a more or less precise set of packaging rules which influence the usability of their packaging systems in a big way. Moreover, users usually do not choose their distribution according to the package management system it uses and although it would be technically possible to use any of the package management systems on every distribution, there are hardly more users doing it.
From these (and yet more) reasons I’ll just point out some pros and cons of both RPM and deb package formats.
During my presentation and subsequent discussion, there were several valuable notices from my colleagues that I highly appreciate. Two of them I listed below:
Tiskni
Sdílej:
Copak DEB balík poskytuje pouze své jméno a nic jiného ?DEB to, pokud vím, řeší zavedením virtuálních balíčků a tagem Provides. Ono to vlastně dává docela dobrý smysl: Když mám objekt, který může být obecně nabízen více balíčky, měl by být deklarován samostatně spolu s komentářem, co je zač a k čemu slouží.
build
IMHO neumí pořešit zapsání konkrétního souboru v BuildRequires:
.
Důležité je, že rozhodnutí je na mě, možnosti balíčkovacího systému mě neomezují. To co píšeš zní rozumně, ale nevidím to jako výhodu DEBu, spíše jako z nouze ctnost.Já to také nevidím jako výhodu, ale přijde mi, že to ani není jakkoliv podstatná nevýhoda. Konec konců není od věci, když balíčkovací systém vynucuje jistou dávku štábní kultury :)
File provides mohou být užitečné i jinak - např. snadno umožňují dotazovat se na obsah nenainstalovaných balíků.Jistě, ale to se dá zařídit i nekonečně mnoha jinými způsoby. On si nezávisle na tom nejspíš každý balíčkovací systém udržuje povědomí o tom, který soubor kterému balíčku patří.
Jistě, ale to se dá zařídit i nekonečně mnoha jinými způsoby. On si nezávisle na tom nejspíš každý balíčkovací systém udržuje povědomí o tom, který soubor kterému balíčku patří.Ano, ale to platí pouze pro nainstalované balíčky. U balíčků dostupných v repozitáři je to trochu složitější. pkglist APT-RPM repozitáře obsahuje i seznamy souborů (= file provides), o APT-DEB to, pokud jsem dobře informován, neplatí.
Ano, ale to platí pouze pro nainstalované balíčky. U balíčků dostupných v repozitáři je to trochu složitější. pkglist APT-RPM repozitáře obsahuje i seznamy souborů (= file provides), o APT-DEB to, pokud jsem dobře informován, neplatí.A je vyhledávání v obsahu nenainstalovaných balíčků natolik důležité, aby bylo nutné kvůli němu (hrubým odhadem) zdvojnásobit velikost meta-dat balíčků, která si z repository každý musí stáhnout? Není přirozenější naučit repository nějaký vyhledávací interface?
Není přirozenější naučit repository nějaký vyhledávací interface?Je to určitě jedna z cest. Malou nevýhodu tohoto řešení vidím v tom, že skladba použitých repozitářů se na každém počítači může lišit a takhle by se dalo vyhledávat pouze z těch oficiálních.
Je to určitě jedna z cest. Malou nevýhodu tohoto řešení vidím v tom, že skladba použitých repozitářů se na každém počítači může lišit a takhle by se dalo vyhledávat pouze z těch oficiálních.Já měl na mysli definovat rozhraní, které může implementovat každý repozitář. U těch oficiálních to samozřejmě Debian už dávno má.
[root@pclinuxos /]# apt-get install psi
Reading Package Lists... Done
Building Dependency Tree... Done
Suggested packages:
psi-i18n
The following NEW packages will be installed:
psi
0 upgraded, 1 newly installed, 0 removed and 54 not upgraded.
Need to get 0B/3170kB of archives.
After unpacking 6967kB of additional disk space will be used.
Committing changes...
Preparing... ########################################### [100%]
1:psi ########################################### [100%]
Done.