Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
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.