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.
Vyšlo jádro 3.15, a to 8. června. Mezi hlavní změny v této verzi patří výrazná vylepšení ve správě paměti, systémové volání renameat2(), POSIXové zámky specifické pro soubor, nový cíl mapovače zařízení nazvaný dm-era nebo rychlejší probouzení z uspání.
Začleňovací okno 3.16 zatím zůstává otevřené; přehled toho, co bylo začleněno, najdete níže. Linus poznamenal, že i když překryv začleňovacího okna 3.16 se stabilizací 3.15 zafungoval dobře, neznamená to, že je nakloněn tomu dělat to takto pokaždé. Navíc si nemyslím, že by to byl takový užasný zážitek, abych chtěl dělat podobný překryv pokaždé, pokud by pro to nebyl dobrý důvod. Bylo to fajn být během posledního týdne nebo rc produktivní (obvykle je to docela nuda), ale myslím si, že by to jen odvádělo pozornost v době, kdy si lidé mají dělat obavy o stabilitu rc.
Stabilní aktualizace: verze 3.14.6, 3.10.42 a 3.4.92 vyšly 7. června, následně pak 11. června vyšly verze 3.14.7, 3.10.43 a 3.4.93.
Neděláme tu vědecký výzkumný projekt. Pracujeme tu na opravdu velkém projektu v oblasti softwarového *inženýrství*.
Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?
-- Dave Chinner
Proto tedy budeš (nebo možná bude muset Intel obecně) opravdu explicitně popisovat, jak věci fungují a neskrývat to někde v ovladači a čarovat tam. To samé ostatně platí i pro jiné výrobce.
Pokud vy (výrobci [...]) nebudete hrát podle pravidel (a nebudete explicitně a viditelně popisovat, jak váš hardware funguje), pak zkrátka nebudete mít energeticky efektivní plánovač tečka.
Není tu žádný roh, za kterým byste se mohli skrývat, ani žádné magické závoje. Prostě to buď popíšete _veřejně_, nebo budete mít smůlu.
Toto je druhý díl seriálu, který popisuje začleňovací okno 3.16. Pokud vás zajímá, co se odehrálo během několika prvních dnů, pak se podívejte na článek z minulého týdne. Od té doby se Linus vrátil do větve master, respektive se tak stalo poté, co začlenil nějakých 6800 commitů ze své větve next. Nyní bylo do 3.16 začleněno 8179 patchů, což je 2831 od článku z minulého týdne.
Následuje přehled významných změn viditelných uživatelům.
Vývojáři si mohou všimnout těchto změn:
V tento moment bychom už měli být u konce začleňovacího okna, i když se během následujících dnů ještě může objevit několik zajímavých patchů. Těšte se na závěr v příštím vydání JN.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?Jenom to ne :D.
Nebylo by tedy lepší používat procesy ze softwarového inženýrství namísto akademického peer review jako vzor pro náš proces revidování kódu?
Jasně příjde nějaký korporátnický manažér a svoboda bude fpiči... :-/
Občas neškodí podívat se na kontext, než začnete bít na poplach. Konkrétně šlo o tohle:
IMO, every reviewer has their own developement environment and they should be at least testing that the change they are reviewing doesn't cause problems in that environment, just like they do for their own code before they post it for review.Let me ask you this. In the scientific community, when someone posts a research project and asks their peers to review their work. Are all those reviewers required to test out that paper? Or are they to review it, check the math, look for cases that are missed, see common errors, and other checks? I'm sure some reviewers may do various tests, but others will just check the logic. I'm having a very hard time seeing where Reviewed-by means tested-by. I see those as two completely different tags.We are not conducting a scientific research experiment here. We are conduting a very large software engineering project here.
So perhaps we should be using robust software engineering processes rather than academic peer review as the model for our code review process?
Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.
Nepopírám, že ta myšlenka je kontroverzní a že za otestování na zjevné regrese by měl být v první řadě zodpovědný autor patche, ale ať to čtu, jak to čtu, nějak v tom ne a ne vidět to omezování svobody ze strany korporátnického manažera.
Však to přijde, až přijdou ty tzv. „robust software engineering processes“...
Mě to přijde jako docela samozřejmost, otestovat si program který píšu (v tom se asi se mnou nebude přít nikdo, kromě nadřízených/prodejců :D ) a nebo po někom kód kontroluju. (tady je to závislé případ od případu)
Chápu, že patch pro nějaký hack pro síťování s ARM procesorem, si každý doma na své x86 neozkouší.
Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.
Na druhou stranu bych čekal, že když už děláte "Reviewed-by:", tak vlastníte železo, na kterém to zkoušíte.
Reviewed-by nemá s testováním nic společného. Znamená to, že sis kód přečetl a připadá Ti v pořádku. Samozřejmě se předpokládá dostatečná znalost kontextu.
Naproti tomu Tested-by znamená, že nemusíš rozumět kódu, ale že si to ozkoušel a funguje to.