Branch Privilege Injection (CVE-2024-45332, Paper) je nejnovější bezpečnostní problém procesorů Intel. Intel jej řeší ve včerejším opravném vydání 20250512 mikrokódů pro své procesory. Neprivilegovaný uživatel si například může přečíst /etc/shadow (YouTube).
Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
pisi maly program v c-cku a potreboval bych vedet, jak dlouhy je double, nebo lepe jaka je jeho presna bitova struktura (kolik bitu je exponent atp.). Jak to na danem systemu zjistim? Jedna se o architekturu i386, gcc-4.1 (distro debian testing).
Dekuj za radu :)
Zdravi Michal
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
sizeof(). Na velikost mantisy a exponentu se zkuste podívat třeba do seriálu, který nedávno vyšel na Rootu, je to asi tak druhý nebo třetí díl.
dekuji za odpoved, upresnim svuj problem: ja dostanu z pristroje 8byte, z toho prvnich 11 jsou "exponent bits" a zbylych 52 jsou "fraction bits" podle EEE754. Kdyz ted nactu techle 8byte do promene typu double (sizeof(double)=8, alespon na mem systemu), tak dostavam hodnotu o 4 rady mensi, napriklad misto 0.2 dostanu 0.00002. Hledam pricinu problemu. Napadlo me, jestli je opravdu ulozeny double podle EEE754 i na mem systemu. Proto dotaz, jak to zkontroluji?
jeste presneji, pristroj vraci hodnotu ve tvaru :
(ascii)0(ascii)#(binary)110100....
cili prvni dva byte jsou ascii 0 a ascii #, pak nasleduje 64 bitu.
nactu tedy vsechno (celkem 10 byte) do pole typu char a pak provedu
pointer_na_double=pole + 2;
No a chova se to jak jsem uvedl vyse... :)
Jeste jednou dekuji za pomoc
Zkuste se podívat na hodnoty maker FLT_RADIX (mělo by být 2), DBL_MANT_DIG, DBL_MIN_ËXP a DBL_MAX_EXP (je potřeba includovat <float.h>), z nich by to mělo být vidět. U mne je to (na x86 i x86_64) 2, 53, 1024, -1021. Takže by to mělo být 53 bitů mantisy, 1 bit znaménko a 10 bitů exponentu.
V každém případě bych ale doporučoval nespoléhat na kompatibilitu binárního zápisu a napsat si na to konverzní funkci. Ušetříte si tím těžkou hlavu, kdybyste to někdy chtěl portovat na jinou platformu (třeba big endian).
moc dekuji, to je ono :) Na mem systemu jsou hodnoty totozne tj. 2, 53, 1024 a -1024.
Ano, kompatibilita mym resenim trpi. Mohl bych vsechna data nacist jako ascii a pak je zkonvertovat pomoci atof(), coz je z hlediska kompatibility bezproblemove. Nicmene rad bych se tomuto reseni vyhnul kvuli rychlosti. I za cenu ztraty kompatibility.
Tiskni
Sdílej:
