Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
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).