Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
#define PORT 0x3f8
#define OFFSET_RIZENI_M 4
outb (0x00, PORT+OFFSET_RIZENI_M); //nuluj registr rizeni modemu
log1 (PORT+OFFSET_RIZENI_M); // inicializace sbernice a poskytnuti napajeni po dobu 1ms
usleep (1000);
log0 (PORT+OFFSET_RIZENI_M); //-|master reset
usleep (500); //_|
log1 (PORT+OFFSET_RIZENI_M); //-uvolnit sbernici
usleep (70);
statusCTS=inb (PORT+OFFSET_STAV_M);
if ((statusCTS & CTS_BIT)==0x00) //-je nula na sbernici
printf ("Ozval se\n");
Řešení dotazu:
void __usleep_test02 (int usecond) {
struct timeval ts,te; //ts-time start; te-time end
gettimeofday(&ts, NULL); //read start time in usec
do {
gettimeofday(&te, NULL); //read end time in usec
} while (te.tv_usec<ts.tv_usec+usecond); //when te(time end) < ts(time start) + usecond
}
casovani je naprosto presne a cip se ozval jak ma.
Ten cyklus ma spravny v pripade, ze nebude mit cekani delsi nez 1s (v pripade, ze mu to nekdo preplanuje a ono to pretece, tak uz na tom vlastne nezalezi a casem se mu to vzbudi stejne).Ne, zatuhne to. Dejme tomu: ts.tv_usec == 999999 a usecond == 3: bude se čekat až te.tv_usec >= 1000002, což nemůže nikdy nastat. Doporučuji alespoň následující, s tím, že nemůžete zadat usecond > 999999.
void __usleep_test02(int usecond) { struct timeval tv; time_t target_sec; suseconds_t target_usec; gettimeofday(&tv, NULL); target_sec = tv.tv_sec; target_usec = tv.tv_usec + usecond; if (target_usec >= 1000000) { target_sec++; target_usec -= 1000000; } while ((tv.tv_usec < target_usec) || (tv.tv_sec < target_sec)) { gettimeofday(&tv, NULL); } }
Ta pasaz s casovacem mne velmi zaujala a poprosil bych o rozvedeni. Mikrosekunda je z puhledu systemu cca 1000-2000 instrukci CPU a to neni az tak mnoho.No, základem všeho je si zajistit RT prioritu procesoru (SCHED_FIFO), jinak se můžete jít koulet - jádro do Vaší čekačky přepne jiný proces a místo 2 us čekáte třeba 20 ms. Pokud máte RT prioritu, tak se to nestane, na druhou stranu jelikož standardní jádro není hard-RT, tak stejně nemáte 100% jistotu, ale už máte aspoň něco, s čím se dá rámcově počítat. Samotné čekání pak můžete udělat metodou busy wait - tj. tak jak to je naznačeno výše, čekáním v úzké smyčce na ten správný okamžik. Zablokujete tím kompletně jedno jádro procesoru, proto je potřeba vážit kdy a jak se tento postup nasadí. V defaultním nastavení linuxu je proti kompletnímu zablokování pojistka:
$ cat /proc/sys/kernel/sched_rt_period_us 1000000 $ cat /proc/sys/kernel/sched_rt_runtime_us 950000... což znamená, že i přes RT prioritu bude váš proces donucen ke spánku pokud sežere více než 950000 us z 1000000 us okna (hodnoty v proc lze samozřejmě upravovat). To znamená že na jednoprocesorovém stroji budete mít šanci odladit tu chybně napsanou funkci na čekání :) Otázkou může být jak je jádro schopné říct kolik je přesně gettimeofday(). V linuxu jsou 2 časovače - clock source a event source. První lze jen číst a druhý lze i programovat na odeslání interruptu za nějakou dobu. Event source je obvykle podstatně méně přesný. Klasický časovač má 1000 Hz, HPETy mají v řádu MHz. Clock source má v optimálním případě přesnost 1 cyklu procesoru. Funkce gettimeofday() funguje tak, že se podívá na globální proměnnou kde je informace o čase posledního eventu a přičte k ní aktuální offset z clock source. Samozřejmě než se poté vyšaší přepnutí z kernel režimu do userspace atd. tak ještě nějaký čas uteče ale obvykle je to o dost méně než ta 1 us která nás zajímá. (Pro ultra přesné časování nesmíte volat funkce kernelu, ale vystačit si třeba s čtením TSC přímo v programu, což je zdroj dalšího opruzu...) Na druhou stranu pokud zavoláte nanosleep() tak si jádro dá určitou práci s tím, aby nastavilo event source jak nejlépe to jde (tam je toho dost, je potřeba váš časovač zařadit do RB stromu a kdovíco ještě) a pak si dá CPU voraz, takže skutečně tu mikrosekundu spíte. Bohužel kvůli různým overheadům a granularitě event sourcu budete mít trochu horší výsledky než u busy wait, na druhou stranu šetříte lesy :) Udělal jsem nějaké rychlé testy (viz přiložený program) a zdá se, že se výše popsané potvrzuje. Busy wait sežere 100% cpu a do 2ms okna se netrefí třeba 200x ze 100 000 pokusů. Na druhou stranu nanosleep nežere skoro nic, ale má overhead, se kterým musíte dopředu počítat a díky tomu trochu větší rozptyl.
kdezto aktivni cekani se netrefi v cca 6% pripadu... aspoň je vidět, že ani tahle metoda neni samospásná.
na jake verzi jadraPokud se pamatuju dobře, tak precizní časování se předělávalo někde kolem verze 2.6.17.
na takove kratke useky je aktivni cekani vhodnejsiStaré glibc uměly při volání nanosleep automaticky aktivně čekat do 2 mikrosekund pokud měl program RT prioritu, z novějších verzí to vyhodili.
Cist TSC bych radeji nedoporucoval, protoze se chova na ruznych architekturach jinakNení to věc architektury ale konkrétního modelu CPU. Já mám jeden celkem nový amd64 procesor a používá se dynamická změna rychlosti a TSC funguje dobře.
Tiskni
Sdílej: