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.
Netoužím ani po automatizaci z onoho řešení (něco jako najdi všechno na síti a začni to monitorovat, nebo tady šup agenta na server a monitoruj vše, co tam na něm najdeš). Monitoruji jen důležité věci a pokud chci automatizaci, tak jednotně přes Ansible.Tohle řešíme jednak tím že se automaticky berou metriky z clusterů (ať už EC2 v AWS, nebo k8s), ale taky tím že se instaluje DD agent do base image (AMI nebo docker). To automatické řešení se tu pomalu zavádí (APM tracing), to jsem zatím jednou viděl v rámci nějakého incidentu a připadalo mi to jako vidět v praxi fungovat nějaký sci-fi vynález. Řešil jsem tenkrát že něco vypadlo a protože na to bylo navázáno asi 20 dalších services, tak jsi viděl 20 alertů (z nagiosu byly nejlepší, tam nikdy nevím ani kde je vypnout), viděl že 20 věcí nefunguje, ale zjistit co z těch 20 věcí to způsobilo bylo docela peklo, dokud jsem se nepodíval do APM trace, kde mi to nakreslilo schéma, analýzu toho jak se ten výpadek zpropagoval v čase a nakonec to pomocí nějaké heuristiky ukázalo na jednu věc, že ta byla příčina. Tak jsem se tam lognul, a fakt jo. BTW, pokud tě sere ansible, tak doporučuji mrknout na pyinfra (psal jsem o tom před pár lety blog).
Tebou popsaný příklad s problémem mi přijde, jako když někdo spravuje nějaké prostředí, které nezná (nemyslím nijak zle, myslím to jako třeba neohlídání si předávky apod.).Tak když máš firmu kde je několik tisíc programátorů, tam ani není možné že bys mohl všechno znát. Myslím že kdybych sledoval co všechno dělají týmy tady v Praze, tak bych už nestíhal nic jiného.
Pravdou je, že nemám zkušenosti s tak velkým teamem, ale tak nějak jsem očekával, že všichni nedělají všechno, ale každý jen něco, každý je zodpovědný za nějakou část a tu má pod kontrolou / rozumí jí a řetězec funguje (vše vyjasněno v rámci dohled, admin, devík).To není úplně možné už jen protože všechno se neustále mění. Výhoda microservices.. Jinak jo, ale to se týče spíš vývoje, pak se dělají rotace na L1/L2, kde člověk na L1 řeší tak nějak všechno ten den, L2 je většinou někdo kdo rozumí tomu konkrétnímu projektu, ale to má tu nevýhodu že mezi těma věcma musíš prvně vůbec zjistit co je příčina, abys to na něj potom mohl hodit.
On k8s a všechno kolem toho k tomu tak nějak směřuje (že nikdo nebude vědět nic a každý problém se bude dlouho trasovat jak u idiotů).Tak tak :)
Tiskni
Sdílej: