MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Prosím o radu ohledně tohoto nepříjemného problému: Mám tiskárnu <viz titulek> už víc než rok a vždy mi přes CUPS tiskla bezchybně. Přibližně od kernelu 2.6.16 a CUPS 1.2 prakticky nefunguje. (Verze neznám přesně, měsíc jsem netiskl (dobrovolně) a pak už taky ne (nedobrovolně).)
Při pokusu o tisk tiskárna bliká, stejně jako dřív. Stránka je však vytištěna až po 20 minutách nebo po hodině, pokud je vůbec vytištěna. (Většinou není.) Přitom CUPS se tváří, jako by se nic špatného nedělo. (Webové rozhraní i rozhraní KDE ukazuje tiskárnu ve stavu processing, accepting data atd.)
Když smažu tiskárnu v CUPS a znovu ji přidám přes webové rozhraní (nebo přes rozhraní v KDE), chvíli tiskne normálně. Ale jen do nejbližšího restartu. (Občas normální chování nevydrží ani do restartu.)
Zapnul jsem LogLevel debug. Bezvýsledně. Když udělám z logu grep err, vidím jen:
D [02/Oct/2006:21:10:09 +0200] PID 3400 (/usr/lib/cups/filter/pstops) exited with no errors. D [02/Oct/2006:21:10:10 +0200] PID 3401 (/usr/lib/cups/filter/foomatic-rip) exited with no errors. D [02/Oct/2006:21:10:10 +0200] PID 3402 (/usr/lib/cups/backend/usb) exited with no errors.
Jako by se fakt nic nedělo. Přitom se v logu minimálně tisíckrát dokola opakují shluky řádků tvaru:
D [02/Oct/2006:21:10:09 +0200] [Job 603] Received 40 bytes of back-channel data!
Takové řádky tam předtím nikdy nebyly. To vím jistě, protože už jsem LogLevel debug měl nastavený hodněkrát. (S CUPS jsou problémy soustavně a s každou novou verzí přijdou další.)
Dál se objevují ohromné shluky těchto řádek:
D [02/Oct/2006:21:05:15 +0200] [Job 602] Received 40 bytes of back-channel data! D [02/Oct/2006:21:05:16 +0200] [Job 602] Read 8192 bytes of print data... D [02/Oct/2006:21:05:16 +0200] [Job 602] Received 40 bytes of back-channel data! D [02/Oct/2006:21:05:17 +0200] [Job 602] Wrote 8192 bytes of print data... D [02/Oct/2006:21:05:17 +0200] [Job 602] Received 40 bytes of back-channel data! D [02/Oct/2006:21:05:18 +0200] [Job 602] Read 8192 bytes of print data...
Co to může být? Snaží se tiskárna něco sdělit ovladači? Je to chyba mé tiskárny (porucha, opotřebení) nebo chyba v kernelu a v ovladačích pro USB? (Poslední dobou se v nich dělalo několik změn...) Google o těchto hláškách nic smysluplného neříká. Prosím poraďte mi, můžete-li. Potřebuju v současné době tisknout denně a tento stav je pro mě naprosto neúnosný.
Další experimenty ukázaly následující:
Pořád se obbjevují povivné hlášky v logu. Toto je pro mě opravdu záhadou. Nemám ponětí, co bych s tím měl dělat. Kdyby aspoň byla šance zjistit, jestli je to tiskárnou nebo chybou v komunikaci přes USB...
Opravdu nikdo nevíte? Začínám z toho být už hodně zoufalý. Napsal jsem samozřejmě i do jiných diskusních fór, hlavně do fóra mé distribuce i do fóra na stránkách CUPS. Nikde žádná odezva.
Nechce se mi věřit, že by tento problém opravdu nikdy nikdo neřešil. Na stránkách CUPS samozřejmě tento bug je, ale mluví se tam o zcela jiných tiskárnách. Navíc se tam tvrdí, že byl problém vyřešen už v květnu, což zjevně není pravda.
Existuje nějaký jiný vhodný tiskový systém, který by mohl nahradit CUPS? Tento nefunkční kousek softwaru bych ze svého počítače rád co nejrychleji odstranil.
Jupí! Vyřešil jsem to. Pomohl mi vývojář od ESP. Tentokrát nebyla chyba mezi židlí a klávesnicí.
Ale musím uznat, že i ESP a jejich CUPS jsou v tom celkem nevinně.
Moje tiskárna se chová nestandardně a nedodržuje předepsaný protokol. Proto přidání nových vlastností, které měly prospět, uškodilo. Driver pro Windows si s tím poradí, ale jeho vývojáři mají k dispozici kompletní dokumentaci, což je podstatná výhoda.
Aby se to vyřešilo, musí se trochu rýpnout do zdrojáku pro USB backend. Ale pak to funguje jako po másle, dokonce i verze stažená přímo ze SVN.
Vše je podrobně shrnuto tady. Je tam 1) můj podrobný popis problému, 2) Rada od jednoho z vývojářů, 3) návod na konečné řešení problému.
Pevně doufám, že se tento příspěvek jednou bude někomu hodit, až se s tímhle problémem setká.
Tiskni
Sdílej: