Výzkumníci ze společnosti ESET objevili 11 zapomenutých UEFI shim zavaděčů, které byly podepsány společností Microsoft, a které umožňují útočníkům obejít ochranu UEFI Secure Boot na většině zařízení. Microsoft je zneplatnil (přidal jejich hash do databáze dbx) v rámci aktualizace Patch Tuesday dne 9. června 2026. Uživatelé Linuxu mohou databází aktualizovat pomocí LVFS. Ověřit zneplatnění zavaděčů lze pomocí skriptu uefi-dbx-audit. Jedná se o CVE-2026-8863 a CVE-2026-10797.
pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
Na Seznam nepovolených internetových her (Wikipedie) se k 13. 7. 2026 dostala predikční platforma Polymarket.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 167 (pdf) a Hello World 30 (pdf).
Byla vydána nová verze 3.22.0 grafického vývojového prostředí a platformy Gambas (Wikipedie) založené na interpretru programovacího jazyka Basic s rozšířením o objektově orientované programování. Přehled novinek v poznámkách k vydání. Zdrojové kódy jsou k dispozici na GitLabu.
FreeBSD odstranilo poslední GPL kód ze základního systému. Konkrétně dpv, libdpv, libfigpar a dialog. Instalátor před čtyřmi lety přešel z dialogu na bsddialog.
Inu uz i Linus jde s dobou a casti kernelu se zacnou delat v rustu.
Memset s bufferem? To je potencialni dira a memleak.
Mohl byste tuhle myšlenku nějak objasnit? Samozřejmě by čistší bylo
memset(buffer, 0, sizeof(buffer));
nebo raději rovnou
char buff[BUFF_LEN] = {};
nebo
char buff[BUFF_LEN] = "";
ale jak z inicializace lokální proměnné uděláte memleak, to bych si docela rád poslechl.
Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
mít takhle velkou proměnnou na stacku.napr. u funkce, ktera pise do logu a jako parametr dostane vetsi text se s ti neco udelat musi. Co pouzivate potom. Static, malloc, extern ? Ja pouzivam static uvnitr funkce a priznam se, ze jsem vlastne nikdy nezkousel, kde se to uklada
, ja jsem si myslel, ze tyhle permanentni veci by mely skoncit v datovem segmentu, ale jisty si vlastne nejsem. Vi to nekdo na 100%? Co pouzit kdy?
malloc() apod. V jádře je vzhledem k velikosti stacku tlak na šetření hodně velký, ale ani v userspace není dobré si představovat, že je stack nekonečný. Resource limit na velikost stacku (ulimit -s) sice bývá něco jako 8 MB, ale to je pro všechny thready dohromady, takže u multithreadových programů běžně používám stack o velikosti 64 KB nebo dokonce 16 KB - a pak už si rozmyslíte, jestli tak velkou část zaplácnout nějakým bufferem.
my dodavame programy do firmy, ktera se nachazi v obci Rust a kolega kdysi delal nekolik excelovych zpracovani pro mestsky urad v obci Perl. Je zajimave, ze pro radu programu existuje obec, ktera se zrovna tak jmenuje+ ještě Kotlin a Java. Lua, Saint-Python, Cobol, Fortran, Scala, C++, Ruby, …
move s Vámi soublasím – to by měl řešit spíš kompilátor. Na druhou stranu, proti let mut/mut nic nemám (pořád hezčí než const v C++) – alespoň si v tom musím udělat jasno předem. (Kotlin má val (jako let) a var (jako let mut) a tam mě to spíš obtěžuje, zčásti protože si tato klíčová slova jsou tak podobná, že se snadno spletou.)
Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
Mě teda spíš vadí to, že má takhle velkej buffer, když do něj čte maximálně 4 byty... Víc commandů za sebou to neumí, zbytek načteného bufferu stejně zahazuje. Kdyby tam měl odpovídající - 4 bytovej buffer - tak si ho dovedu na stacku klidně představit i v kernelu
. Celkově bych to nazval jako "céčko od ne-céčkaře" (vyloženě z toho čiší neznalost základních principů, jako co je v C string a jak je reprezentovaný, co je stream a jak funguje standardní vstup, ...). Nějak takhle asi vypadaj moje programy v pythonu
.
Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU). Pokud uz je stack naalokovany, je to nejefektivnejsi metoda, jak ziskat docasnou pamet - jen se navysi stack pointer (proto ma alloca obcas svuj smysl, treba kod llvm je toho plny).Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU).
A taková proměnná vám zabere čtvrtinu té stránky, to je docela dost, aby se nad tím vývojář aspoň řádně zamyslel. Nemluvě o tom, že v civilizovaném programu těch 1000 nebude natvrdo zadrátovaná konstanta, čímž se problém posouvá na novou úroveň. (Viz např. čistka VLA v jádře pár let zpátky.)
proto ma alloca obcas svuj smysl, treba kod llvm je toho plny
Snad jsou aspoň trochu prozíravější než autor resolveru v glibc, který také miluje alloca(), ale bohužel má malou představivost ohledně toho, jak velká může být odpověď nebo kolik IPv6 adres může host používat, takže ten zásobník tu a tam přeteče…
Nebo se jedna o nejaky nedefaultni runtime?
Co s tim jako?Reakce na tohle: https://www.abclinuxu.cz/poradna/linux/show/473630
jaktože to jakoby má jenom 23 zobrazení ale už 12 hlasů :D
ok tudlectu výmluvu žeru ;D ;D
while(1)
if(loop()==1)
break;
Stačí naspat:
while(loop() != 1)nebo
== 0, ale to může mít jiný význam v závislosti na tom, jaké hodnoty vracíš.
while(!loop());
… radeji vidim true/false a EXIT_* nez return 0/1, while(1), atd.Souhlasím. Mám také raději „ukecanější” kód ze kterého je jasné co se kdy děje, než rébusy, u kterých lze návratovou hodnotu snadno zaměnit. Číselné hodnoty využívám jako návratovou hodnotu jen tam, kde potřebuji odchytnout konkrétní místo.
Tiskni
Sdílej: