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í.
Netwide Assembler (NASM) byl vydán v nové major verzi 3.00. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
Linuxová distribuce Frugalware (Wikipedie) ke konci roku 2025 oficiálně končí.
Byla vydána nová verze 3.0.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP bude brzy k dispozici také na Flathubu.
Americký výrobce čipů AMD uzavřel s americkou společností OpenAI smlouvu na několikaleté dodávky vyspělých mikročipů pro umělou inteligenci (AI). Součástí dohody je i předkupní právo OpenAI na přibližně desetiprocentní podíl v AMD.
Možná jste taky někdy zápasili s tiskem formulářů nebo šablon, které pořád ne a ne vyjít ve správné velikosti. Článek Tisk v přesném měřítku (PDF, PPD, CUPS) popisuje příběh hledání jedné takové chyby v GNU/Linuxu.
Tiskni
Sdílej:
lp
. Tím se snadno odliší chyby aplikací od chyb print serveru / tiskárny.
Už dávno jsem si vyrobil jednoduchou postscriptovou testovací stránku pro kalibraci tiskáren.
Vyrobil jsem podobnou stránku (je v příloze blogu), ale ne tak pěknou, díky.
To je nečekaně častý problém.
To mne na tom právě trápí asi víc než to, že jsem zrovna nemohl vytisknout dokument v měřítku. Proto jsem vlastně kolem toho psal ten článek, byť to řešení samotného problému je celkem triviální. Tohle se opakuje často a na různých místech, nejde jen o tisk, je to obecný problém s kvalitou – něco se rozbije a nikdo1 si toho nevšimne, opraví se to až po letech a pak klidně rok nebo déle trvá, než se ta oprava dostane do distribucí, které používají běžní uživatelé.
[1] resp. oni si toho všimnou ti uživatelé, kteří pak dotyčný software třeba přestanou používat, ale nikde to nenahlásí jako chybu, takže z pohledu vývojářů žádný problém neexistuje
pokud byste hledali ve své distribuci PPD soubory pro nenainstalované tiskárny, tak je pravděpodobně nenajdete. Místo nich tam máte /usr/lib/cups/driver/openprinting-ppds, což je skript v Pythonu, který v sobě má textovou proměnnou s velmi dlouhým řetězcem (celý ten skript má přes 5 MB) ve formátu Base64, uvnitř kterého jsou zkomprimované všechny PPD soubory. Tohle raději nebudu komentovat. PPD soubory si můžeme vypsat pomocí openprinting list a jeden konkrétní získat pomocí openprinting-ppds cat URI (kde URI začíná openprinting-ppds: a jde o první sloupec z výpisu). Získání jednoho PPD souboru na mém ne úplně pomalém počítači s SSD diskem trvá dva a půl vteřiny. Tím se vysvětluje, proč přidávání nové tiskány přes CUPS není zrovna dvakrát rychlé.masakr
Ano, týká se to Debianu a Ubuntu. Docela by mne zajímalo, co je k tomu vedlo.
Ono těch 5 000+ souborů může někoho vyplašit, ale pro souborový ani balíčkovací systém by neměl být reálný problém a výkon by měl být lepší než v Pythonu prohledávat komprimovanou proměnnou zabalenou v Base64.
Ono je to rozbité i přímo v té tiskárně:
dávám PDF soubory na USB flashku a nesu je k tiskárně – ta má USB port a nabízí tzv. přímý tisk. Ovládání přes ten malý displej a pár tlačítek je docela použitelné. Tiskárna tiskne… a další makulatura je na světě. Výsledek je o nějaký ten milimetr lepší, ale stále je to celé špatně. Až tak „přímý“ tisk to tedy nebude.
a to je proprietární firmware, se kterým uživatel nic nenadělá. Oproti tomu v GNU/Linuxu je všechno softwarové a protože je to svobodný software, tak to lze opravit. (ano, trvalo to hodně dlouho)
Na druhou stranu, když jsou programy skládané tímhle způsobem a volají se jako podproces, tak se to dá snáze ohackovat, aniž bych musel jít do zdrojáků a něco kompilovat. Můžu si udělat např. skript s názvem lpr
, přidat si ho do $PATH
a pomocí něj to odladit – jednak se můžu dívat, co jde dovnitř (parametry příkazu, proměnné prostředí, STDIN…), co jde ven (STDOUT, STDERR…), vedlejší efekty monitorovat přes strace
… a když se mi něco nelíbí, tak v tom svém skriptu upravím ty parametry a s nimi pak zavolám ten skutečný lpr
.
Pokud by to bylo řešené např. přes D-Bus, můžu komunikaci sledovat přes dbus-monitor
, ale už nevím, jak do toho vstoupit a přepisovat hodnoty (asi bych musel tu původní službu přesunout a na její místo nasadit nějakou svoji proxy, kterou bych si napsal). Podobné je to s komunikací přes TCP/IP nebo UDP/IP – monitorovat to jde snadno přes Wireshark. Ale vstoupit do té komunikace a upravovat ji, to je trochu víc práce než u těch podprocesů.
Jakou technologií je ten subsystém řešený v KDE 3? Ono by to vlastně šlo řešit přes podprocesy i v případě, že tam bude nějaká abstraktní vrstva, která to bude přesměrovávat dál (CUPS, external program, LPD, LPR/LPRng, RLPR).