Agent umělé inteligence vytvořil 'útočný' článek o Scottu Shambaughovi, dobrovolném správci knihovny matplotlib, poté, co vývojář odmítl agentem navrženou změnu kódu (pull request). 'Uražený' agent autonomně sepsal a publikoval na svém blogu článek, který přisuzuje Shambaughovi smyšlené motivace, egoismus a strach z AI coby konkurence.
Bylo vydáno Ubuntu 24.04.4 LTS, tj. čtvrté opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
V pátek 20. února 2026 se v pražské kanceláři SUSE v Karlíně uskuteční 6. Mobile Linux Hackday, komunitní setkání zaměřené na Linux na mobilních zařízeních, kernelový vývoj a uživatelský prostor. Akce proběhne od 10:00 do večera. Hackday je určen všem, kteří si chtějí prakticky vyzkoušet práci s linuxovým jádrem i uživatelským prostorem, od posílání patchů například pomocí nástroje b4, přes balíčkování a Flatpak až po drobné úpravy
… více »Evropská rada vydavatelů (EPC) předložila Evropské komisi stížnost na americkou internetovou společnost Google kvůli její službě AI Overviews (AI souhrny), která při vyhledávání na internetu zobrazuje shrnutí informací ze zpravodajských serverů vytvořená pomocí umělé inteligence (AI). Evropská komise již v prosinci oznámila, že v souvislosti s touto službou začala firmu Google vyšetřovat. Google obvinění ze strany vydavatelů
… více »Ubuntu 26.04 (Resolute Raccoon) už nebude v desktopové instalaci obsahovat GUI nástroj 'Software & Updates'. Důvodem jsou obavy z jeho složitosti pro běžné uživatele a z toho plynoucích bezpečnostních rizik. Nástroj lze doinstalovat ručně (sudo apt install software-properties-gtk).
Thomas Dohmke, bývalý CEO GitHubu, představil startup Entire - platformu pro spolupráci vývojářů a agentů umělé inteligence. Entire získalo rekordních 60 milionů dolarů na vývoj databáze a nástrojů, které mají zefektivnit spolupráci mezi lidmi a agenty umělé inteligence. Dohmke zdůrazňuje potřebu přepracovat tradiční vývojové postupy tak, aby odpovídaly realitě, kdy většinu kódu produkuje umělá inteligence.
Toyota Connected North America oznámila vývoj open-source herního enginu Fluorite, postaveného na frameworku Flutter. Pro renderování grafiky využívá 3D engine Filament od společnosti Google a dle svého tvrzení cílí na konzolovou kvalitu her. Fluorite je zřejmě navržen tak, aby fungoval i na méně výkonném hardware, což naznačuje možnost použití přímo v ICE systémech vozidel. Zdrojový kód zatím zveřejněný není.
Byl vytvořen nástroj a postup pro překonání věkového ověření platforem Discord, Kick, Twitch, Snapchat (a možná dalších), kód je open-source a dostupný na GitHubu. Všechny tyto sítě používají stejnou službu k-ID, která určuje věk uživatele scanem obličeje a na původní server posílá pouze šifrovaná metadata, ty ale sociální síť už nedokáže sama nijak validovat, 'útok' spočívá ve vygenerování a podstrčení legitimně vypadajících ověřovacích metadat.
Jihokorejská kryptoměnová burza Bithumb přiznala vážné selhání interních systémů, které ji vystavilo riziku sabotáže a nezabránilo chybné transakci v hodnotě přes 40 miliard dolarů (814 miliard Kč). Druhá největší kryptoměnová burza v Koreji minulý týden při propagační akci omylem rozeslala zákazníkům zhruba 620 000 bitcoinů místo 620 000 wonů (8700 Kč). Incident vyvolal pokles ceny bitcoinu o 17 procent. Většinu
… více »Google Chrome 145 byl prohlášen za stabilní. Nejnovější stabilní verze 145.0.7632.45 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Zpátky je podpora grafického formátu JPEG XL, viz Platform Status. Odstraněna byla před třemi lety. Nový dekodér JPEG XL jxl-rs je napsán v Rustu. Zobrazování JPEG XL lze vyzkoušet na testovací stránce. Povolit lze v nastavení chrome://flags (Enable JXL image format).
Během balení rpm se různé věci zapisují do různých adresářů nebo se
v nich hledají. RPM umožňuje flexibilní nastavení adresářové
struktury, pro začátek se však vyplatí seznámit se s tou standardní.
Nainstalujeme-li rpm-build, vytvoří se v /usr/src/RPM
(na RedHatu /usr/src/redhat, jinde případně i jinde)
následující podadresáře:
SPECS – sem se instalují spec soubory.SOURCES – sem se instalují zdrojové kódy a patche.BUILD – do tohoto adresáře se zdrojové kódy
rozbalují (každý do svého podadresáře) a probíhá v něm vlastní
překlad.RPMS – adresář, do nejž se po úspěšné
kompilaci nahrají vytvořené binární balíčky. Přesněji do podadresářů
odpovídajících jejich achitektuře (i386, …,
noarch).SRPMS – sem se případně nahraje vytvořený zdrojový balíček.Do /usr/src/RPM však může zapisovat jen root,
a jelikož k balení rpm není zapotřebí být rootem, nebudeme balit
jako rooti a namísto toho si stejnou adresářovou strukturu vytvoříme
někde v domovském adresáři, řekněme v ~/src/rpm.
RPM vysvětlíme, že ji má používat, přidáním řádku
%_topdir /home/yeti/src/rpm
do souboru ~/.rpmmacros. Kdo nemá uživatelské jméno yeti,
nahradí /home/yeti svým domovským adresářem. Do
/var/tmp, kam se při balení zapisují a dočasně instalují
soubory, sice zapisovat smíme, budeme však chránit životní prostředí
a změníme i adresář pro dočasné soubory:
%_tmppath /home/yeti/tmp
V souboru ~/.rpmmacros můžeme změnit řadu dalších
zajímavých věcí, prozatím se spokojíme s nastavením tvůrce balíku:
%packager Yeti <yeti@physics.muni.cz>
Kdo se nejmenuje Yeti, opět změní na svoje jméno, a především adresu.
Hodnota %_topdir také ovlivňuje, kam se nainstaluje obsah
zdrojového rpm. Nyní tedy můžeme spustit (nebude-li uvedeno jinak, bude se
náš balíček vždy nazývat lobster).
rpm -i lobster-1.10-1.src.rpm
jako obyčejní uživatelé a soubory se objeví
v ~/src/rpm/SOURCES
a ~/src/rpm/SPECS namísto
v /usr/src/SOURCES
a /usr/src/SPECS.
Myslíme-li to s balením vážně, budeme chtít oddělit systém, na
němž pracujeme, od cílového systému, pro nějž kompilujeme – byť
by se lišil jen nainstalovaným softwarem. V tom případě cílový
systém nainstalujeme do alternativního rootu a budeme při balení
a testování používat chroot. rpm a rpmbuild
sice mají argument --root, ten ale podle mne funguje jaksi
zvláštně. Chrootnout se do alternativního rootu přímo příkazem
chroot pracuje spolehlivě – jako obyčejní
uživatelé na to ovšem nemáme práva. Distribuce a významní nezávislí
baliči (např. Dag)
vyvinuli různé nástroje a systémy kompilace oproti čistým instalacím
a ověřování balíčků, které má smysl prostudovat, budete-li se
pouštět do nějakých větších akcí.
Než se pustíme do výroby vlastních balíčků, hodí se umět zkompilovat
ty, u nichž už nám někdo všechno přichystal. Argumenty
rpmbuildu se mírně liší podle toho, z čeho
kompilujeme.
Zdrojový balíček. Máme-li
lobster-1.10-1.src.rpm, binární rpm z něj vytvoříme
rpmbuild --rebuild lobster-1.10-1.src.rpm
Spec soubor a zdrojový kód. Ze zdrojových
kódů v SOURCES a spec souboru kdekoli (obvykle ho
ale budeme mít ve SPECS) zkompilujeme binární balíček
rpmbuild -bb lobster.spec
Ke spec souboru musíme vždy uvést cestu, nehledá se
v SPECS. S -ba namísto
-bb bychom získali binární i zdrojový balíček,
s -bs jen zdrojový balíček.
Tento způsob použijeme nejen při tvorbě vlastních balíčků, ale také když chceme překompilovat balíček například pro jinou distribuci, který vyžaduje úpravy. Zdrojové rpm nainstalujeme, upravíme, co je zapotřebí, a zkompilujeme rpm z „rozložené“ formy.
Tarová koule. Zabalil-li nám nějaký dobrodinec spec soubor do tarové koule se zdrojovým kódem, můžeme ji přímo přebalit do rpm:
rpmbuild -tb lobster-1.10.tar.bz2
Analogicky předchozí možnosti můžeme -tb nahradit
-ta či -ts a získat obě rpm či jen
zdrojové. Každá volba -bněco, co se má udělat se
samotným spec souborem (jsou i další než ty tři uvedené, časem na ně
dojde), má své dvojče -tněco pro spec soubor
obsažený v tarové kouli.

Obrázek shrnuje průběh kompilace a adresáře, jež se účastní výroby RPM balíku ze zdrojového rpm, případně z tarové koule. Adresáře jsou zobrazeny v záhlavích rámečků; rámečky samé ukazují jejich typický obsah. Černé šipky sledují postup kompilace; zelené znázorňují, jak spec soubor řídí jednotlivé její fáze (ty podrobně probereme v další kapitole).
rpmbuilduNelze přehlédnout, že se při kompilaci vypisují do terminálu spousty
věcí. Sám rpmbuild vypisuje na standardní výstup informace
o jednotlivých fázích kompilace a na konci, resp. těsně před
koncem, vypíše, co za balíčky vytvořil:
Wrote: /home/yeti/src/RPM/SRPMS/lobster-1.10-1.src.rpm Wrote: /home/yeti/src/RPM/RPMS/i586/lobster-1.10-1.i586.rpm
Na standardní chybový výstup se pak vypisují všechny spuštěné příkazy
stylem sh -x. Do toho se míchá, co vypisuje na
standardní, resp. chybový výstup ./configure,
make, make install, etc. –
zkrátka pěkný guláš. Zejména z něj nelze snadno vydobýt, jaké balíčky
se nám kde objevily (pokud vůbec), což by se ale často hodilo vědět (volba
--pipe pomůže jen marginálně). Můžeme si pomoci wrapperem
podobným následujícímu, jenž v případě úspěšné kompilace vypíše jen
jména balíčků, selže-li však něco, vypíše na chybový výstup celý log:
#!/bin/bash
outdir=${TMPDIR:-$HOME/tmp}
specfile=$(grep -o '\<[a-zA-Z][-_+a-zA-Z0-9]*\.spec\>' <<<"$@" \
|| { echo "No spec file" 1>&2; exit 1; } | tail -n 1)
log="$outdir/rpmbuild-$specfile-$$.log"
if rpmbuild "$@" &>"$log"; then
sed 's/^Wrote: //;t;d' "$log"
rm "$log"
else
cat "$log" 1>&2
echo Logfile: "$log"
fi
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: