Společnost OpenAI představila svůj nejnovější AI model GPT-4o (o jako omni, tj. vše). Nově také "vidí" a "slyší". Videoukázky na 𝕏 nebo YouTube.
Ondřej Filip publikoval reportáž z ceremonie podpisu kořenové zóny DNS. Zhlédnout lze také jeho nedávnou přednášku Jak se podepisuje kořenová zóna Internetu v rámci cyklu Fyzikální čtvrtky FEL ČVUT.
Společnost BenQ uvádí na trh novou řadu monitorů RD určenou pro programátory. První z nich je RD240Q.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »GHC (Glasgow Haskell Compiler, Wikipedie), tj. překladač funkcionálního programovacího jazyka Haskell (Wikipedie), byl vydán ve verzi 9.10.1. Přehled novinek v poznámkách k vydání.
Po 9 týdnech vývoje od vydání Linuxu 6.8 oznámil Linus Torvalds vydání Linuxu 6.9. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.
Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
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.