Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
int loop()
{
qTimer.start(); // QElapsedTimer
while(shtDwn != 1)
{
GyroModule::gyroUpdate(gVal, aVal);
if(pthread_mutex_trylock(&srvBufMutex) == 0)
{
parseSrvMesg();
pthread_mutex_unlock(&srvBufMutex);
}
printf("Gyro y: %3.2f,", gVal.y);
setMotorsPid();
if(lopCnt % 1 == 0)
{
//for(int i = 0; i < loopTns/1000000; i++)
// cout << "#";
cout << ", loopt: " << loopTns+waitTime*1000+500; // ZDE VYPISUJI CAS SMYCKY
}
cout << endl;
/************* FREQUENCY STABILISATION ****************************/
loopTns = qTimer.nsecsElapsed();
waitTime = ((1/FREQ)*1000000000 - loopTns) / 1000 ;
if(waitTime > 1000)
{
usleep(waitTime-500); //
}
qTimer.restart();
/******************************************************************/
}
return 0;
}
No a problem je tento: pokud nastavím modul gyra, které je pripojeno k Raspberry Pi pres I2C na 66Hz, dám si frekvenci smyčky na 70Hz a všechno je ok. Když si ten modul nastavím na 100Hz a nastavím si frekvenci smyčky na 110Hz (zkoušel jsem klidně i víc), nastane problém, že Gyro hlásí FIFO OVERFLOW! což znamená, že k němu nepřistupuju rychleji než 100Hz (FIFO OVERFLOW je problém a nesmí se objevovat). Přičemž na obrazovku vypisuju různé údaje v každém kole smyčky. Pakliže vypisování na obrazovku zruším, tak FIFO OVERWLOF nenastane.
Tak možná si říkáte, že to je tím, že to vypisování na obrazovku to moc brzdí, jenomže jak mi vysvětlíte, že doba smyčky je přesná na +-0.1ms (viz řádek v kódu s výpisem) ať už s vypisováním, nebo bez něj? :-O
Pokiud nastavím frekvenci gyra na 200Hz, tak už mi nepomůže ani přestat vypisovat cokoliv na obrazovku, klidně si můžu dát frekvenci smyčky na 900Hz (a je jí fakt dosaženo a navíc stabilně) ale hlásí to pořád FIFO OVERFLOW.
Neví někdo co by to mohlo způsobovat?
Používám QT Creator.
Děkuji
Volba HZ nemá žádný vliv na frekvenci plánování. Nemá žádný vliv na odezvu systému. Nemá žádný vliv na nic. Většina pověr, které o ní kolují, pochází asi tak z dávných dob, kdy ještě nějaký vliv měla. Donedávna na ní třeba záviselo, jak moc často RCU spouští své drobné „reclamation“ úlohy na pozadí a další „housekeeping“. Ale ani to už dnes neplatí. Kernely jsou dnes většinou tickless; nicméně i v době, kdy nebyly, se uspávání, probouzení a plánování dělo s granularitou nesrovnatelně menší než 100 Hz, 1000 Hz nebo cokoliv podobného. Dojde-li k migraci vlákna na jiný procesor, kde se má vlákno zase spustit, stane se to okamžitě, ne až za chvíli. Paket ze sítě, požadavek od uživatele a obecně všechno, co vyvolá IRQ, se vyřeší okamžitě, bez ohledu na volbu HZ. Hardwarové časovače, které se používají někde v implementaci API jako je nanosleep()
, taktéž nemají absolutně žádnou souvislost s volbou HZ. IRQ (nebo jiný typ přerušení) od časovače i případné probuzení procesu, který spal, se ošetří okamžitě, tedy přesněji řečeno, hned, jakmile to bude možné. Nikdy se nikde nečeká setinu vteřiny nebo něco takového. Volba HZ je dnes spíš relikt z minulosti než cokoliv užitečného.
Neni problem cekat ve smycce kratsi dobu, ale jakmile pustis cpu musis pocitat ze se nedostanes k lizu driv nez zase za 1/CONFIG_HZ sekund.
Naprostý nesmysl.
A to jen kdyz na dalsi slice nevybere planovac zase jinou ulohu.
Naprostý nesmysl. Tohle už je fakt ve stylu Vesmírní Lidé.
Do techhle veci moc nevidim, ale zni mi to jako ze potrebujes RT kernel.
Tento výrok přichází se zpožděním několika dnů. Hodil by se na 1. dubna. Ale vážně, kdyby platilo cokoliv z toho, co tu tvrdíš, nikdo by dnes nepoužíval počítače a raději by dal přednost telegrafu.
…se ošetří okamžitě, tedy přesněji řečeno, hned, jakmile to bude možné.Jo, ale "okamžitě" a "jakmile to bude možné" není vždy totéž. Ano, me to taky prislo nejdriv streleny, proto jsem se taky ptal na nastaveni a casy. Ale jestli mu to zacina ujizdet kolem 100Hz tak to nebude nahoda.
To nemá absolutně žádný vliv na jakékoliv časování. Zaprvé, plánování, uspávání a probouzení se už minimálně patnáct let neděje s touto granularitou, ale s granularitou mnohem jemnější, kterou hardware umožňuje. Zadruhé, současné kernely jsou buď částečně nebo (stále častěji) úplně tickless, takže plánování i veškeré další úkony probíhající v systému se dějí zcela nezávisle na této volbě. Přísně vzato je volba HZ v konfiguraci kernelu spíš matoucí než užitečná. Nemá žádný smysl. Dokonce ani nemění přírůstek virtuálních tiků do /proc/stat, protože ten je vždycky 100 Hz na procesor, tedy u 16-procesoru přibude 1600 virtuálních tiků za vteřinu, u mého 8-procesur 800 virtuálních tiků za vteřinu, a tak dále a tak podobně, zcela bez ohledu na nastavení HZ.
Tiskni
Sdílej: