Přímý přenos (YouTube) z konference LinuxDays 2026, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
Byla vydána nová verze 0.17.0 programovacího jazyka Zig (Codeberg, Wikipedie). Přispělo 206 vývojářů. Přehled novinek v poznámkách k vydání.
Open-source projekt OpenDLSS-NR je 'bitově přesná reimplementace' neuronové rendrovací sítě DLSS 5 od společnosti NVIDIA, jenže pro grafické API Vulkan (DLSS slouží k vylepšování klasickým způsobem vyrendrovaných snímků pomocí lokálních modelů umělé inteligence, a to v reálném čase). Projekt není nijak spojen se společností NVIDIA, je pouze pro OS Windows a natrénované váhy modelu si uživatelé musí obstarat sami. Zdrojový kód je k dispozici na GitHubu, pod licencí MIT s výjimkou pro komponenty třetích stran.
Společnost Cloudflare představila Clef a Clef-Flash, open-source rozhodovací modely určené pro rychlou a konzistentní klasifikaci vstupů. Na rozdíl od klasických LLM vracejí tyto modely deterministické striktně typované strukturované odpovědi s exaktními pravděpodobnostmi, tedy odpovědi ve stylu přelomového modelu Jev.
… více »Byla vydána beta verze Ubuntu 26.10 s kódovým názvem Stonking Stingray. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.10 mělo vyjít 15. října 2026.
Byla vydána verze 1.99.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Od 13. do 15. října proběhne v Praze OpenSSL Conference 2026. Na YouTube lze zhlédnout videozáznamy přednášek z loňského roku.
Eben Upton oznámil další zdražení jednodeskových počítačů Raspberry Pi. Tentokrát 2 GB varianty o 12,50 dolarů. Nově 2 GB Raspberry Pi 4 stojí 67,50 dolarů a 2 GB Raspberry Pi 5 stojí 77,50 dolarů.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 26.09. Vedle Flatpaku také s podporou Snapu.
Edison Design Group po více než 30 letech zveřejnil zdrojový kód svého EDG C/C++ front-endu. Ten proslul širokou podporou standardů C++ a kompatibilitou s dialekty kompilátorů od Microsoftu, GNU, Clangu, Sunu a dokonce i s prehistorickým cfrontem. EDG byl použit například v kompilátoru Intel C++ Classic, kompilátoru NVCC od firmy NVIDIA pro platformu CUDA nebo v našeptávači kódu IntelliSense v produktech společnosti Microsoft. Projekt nyní spravuje organizace The C++ Alliance a kód je dostupný pod licencí Apache 2.0, doplněnou o výjimky projektu LLVM.
listen sluzba1 bind 192.168.56.20:443 ssl crt /etc/haproxy/certs/ssl.crt verify required ca-file /etc/haproxy/certs/intermediate-ca.crt mode http balance roundrobin maxconn 100000 server s2 192.168.1.26:8080 check listen sluzba2 bind 192.168.56.22:443 ssl crt /etc/haproxy/certs/ssl.crt ca-file /etc/haproxy/certs/intermediate-ca.crt mode http balance roundrobin maxconn 100000 server s2 192.168.1.66:8080 check # pri niektorych bind mam este obmedzenie sifier, zakaz sslv3 # niekde mode tcpMoja otazka spociva v tom, ze "verify required" v sluzba2 sice nie je, ale "ca-file" tam je nastaveny. Je v tomto pripade ten "ca-file" nastaveny zbytocne? Lebo takyto config mam a nechapem preco to tam je, ked "verify required" tam nie je. Nie je tam nejake implicitne pravidlo alebo cosi, ked je nastavene iba "ca-file", ze to checkuje certifikat clienta (hoci len optionally)? Ci tym, ze tam chyba "verify required" (pripadne "verify optional") tak nie je realizovana ABSOLUTNE ziadna kontrola certifikatu klienta, resp. HAproxy vobec neriesi ci klient ma cert alebo nie? A este otazka, v dokumentacii su navody ako nastavit rozne pripady, ked napr. sa niekto pripaja s certom a niekto bez, ked ma niekto expirovany certifikat atd, vzdy tam davaju "verify optional"...cize ak to chapem spravne, tak pri "verify required" MUSIS mat certifikat a certifikat musi byt spravny, cize overeny CA a nesmie byt expirovany. Budem vdacny za akykolvek feedback. Dakujem.
bind 10.0.0.3:443 ssl crt /etc/ssl/certs/mysite.pem, volitelny re-pack SSL pro backend:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
backend ...
server ... ssl ca-file /etc/ssl/certs/ca.pem
, overovani SSL klenta:
bind 10.0.0.3:443 ... verify required ca-file /etc/ssl/certs/ca.pemTakze souhlasim s nazorem, ze to druhe 'ca-file' je tam zbytecne. Odpoved na otazku: Chapes to spravne. https://www.haproxy.com/blog/haproxy-ssl-termination/ https://www.haproxy.com/blog/ssl-client-certificate-management-at-application-level/
Tiskni
Sdílej:
