IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
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.