Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Google Chrome 152 byl prohlášen za stabilní. Nejnovější stabilní verze 152.0.7977.64 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 327 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Před 35 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
Apple představil čipy M6 a M5 Ultra, Mac mini s M6 nebo M5 Pro a Mac Studio s M5 Max nebo M5 Ultra. Fedora Asahi Remix zatím podporuje jenom M1 a M2.
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: