Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Řešení dotazu:
Zatím mám takovou představu, že napíšu aplikaci v C++ která bude obsluhovat akcelerometr, tu spustím hned při bootování a já si z ní budu nějakým způsobem v mě klientské aplikaci (napadlo mě udělat to přes Socket) odebírat data.Cili spousta srani pro nic za nic. Pokud se to cely nema zasekavat na blokujicim cteni, budes muset napsat select/poll handler a postavit nad tim protokol na posilani zprav. To uz mas jednodussi psat si navzajem do sdileny pameti, tam se musis starat akorat o atomicitu. Ale jestli se opravdu chces s takovou silenosti matlat, tak existujou hotovy protokoly (dbus, corba, ice…)
Ale nejvíc by se mi líbilo využít mechanismy Linuxu (které moc neznám) a napsat to jako modul (říkám to správně?).Jestli myslis modul do kernelu kterej by rozumel primo protokolu toho cipu, to by bylo nejlepsi. Ale jestli se musis na takovou vec ptat tak je to, bez urazky, zcela mimo tvoji ligu. Jinak je nejbeznejsi praxe ze co se nevejde do kernelu se zabali do pekny userspace knihovny s nejakym peknym API v C nebo prinejhorsim C++ a to pak jde nalinkovat vicemene z jakyhokoliv slusne vychovanyho jazyka. Coz je v jave to vyse zminene JNI.
mkfifo (1)
, do ni pak muze jeden proces psat a jinej cist a tim spolu kecat. Ale komunikace pres fifo ma takovou vlastnost ze kdyz neni co cist tak se cteci proces zablokuje. To je sice sikovny pacz tim pusti procesor delat neco uzitecnyho (treba zrovna ten zapisujici proces) ale pro rizeni letajicho hardwaru (a obecne rt ulohy) asi neni uplne dobry kdyz se ti proces na predem neznamou dobu zastavi. Proto se to pouziva spis pro zpracovani dat ve stylu fronty a ne na rizeni veci. (Neblokujici cteni pro jednoduchost vynechavam, to ma zase jiny problemy. Zvracenosti jako nechavat si posilat "vyprostovaci" signal casovace jsou svyho druhu reseni, ale je to takovej narovnavak-na-ohejbak.) Na komunikaci s hotovou knihovnou se hodi spis RPC a to se dela asynchrone pres socket jak jsem psal vyse.
Vsechno tohle zahrnuje prinejmesim nejakou de/serializaci coz je podstatne komplikovanejsi (a ma z hlediska RT ulohy nezanedbatelny overhead) nez volat tu knihovnu primo. I kdyz to pozenes pres hotovy protokol (ted je zrovna v kurzu dbus) tak s tim bude dost prace navic. Jestli je nejaky problem napsat si wrapper (nemuzu posoudit, nikdy jsem JNI v ruce nemel) tak asi Java neni "slusne vychovany jazyk".
select
nebo epoll
, což by ale RT úlohy měly používat tak jako tak.
Nicméně, co jsem vůbec nepochopil je, co se tu vlastně řeší. V nadpisu je komunikace běžících aplikací, ale pak se řeší I2C a mezitím JNI. To je fakt děsivý mišmaš. Pokud člověk chce jen komunikaci mezi aplikacemi, tak prostředky systému jdou najít pod klíčovými slovy pipe a socket. High-level programovací jazyky a knihovny poskytují prostředky většinou na socketech postavené, tudíž jaksi není co řešit.Je to tu celé nějak zmatené. Ale vzhledem k tomu, že tazatel evidentně nemá moc chuť do C/C++, ale přitom má Céčkovou knihovnu, která umí všechno, co potřebuje, tak mi přijde jako nejschůdnější udělat okolo té knihovny malý wrapper pomocí JNI a pak už jen používat Javu.
Zkoušel jsem JNI ale poněvač jsem nezjistil, jak uchovat proměnné, které se vyvořily při inicializaci modulu, tak jsem to předělal nakonec na Socket a funguje mi to, ačkoliv mám trochu obavy z narůstajícího zpoždění, už teď to není ideál.Pokud nejdou použít globální proměnné, tak bych se ještě podíval na použití
NewGlobalRef
pro vytvoření globální reference.
Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
Hodne hodne moc. Nekolik radu. Vystreleni novyho procesu znamena kontext switch a uz jen to je draha operace. Ne jenom ze musis nakopirovat kodovej segment, musi planovac udelat svoje kolecko a takovy ty kernelovy veci. Docela velkej zarez je ze se vicemene invalidujou zahraty cache linky, by woko bych si tipnul ze to bude asi nejvetsi brzda. Plus takovy ty detaily jako nakopirovani enviromentu, commandlajny a nejaka ta knihovni omacka. Zavolani funkce primo z nalinkovany knihovny je otazka lookupu v tabuli symbolu a dereference pointeru. Nula nula nic. Proto se taky knihovny pouzivaji. Ve tvem pripade tam bude jeste rezie JNI pacz musis preklopit javovsky datovy typy na ceckovy, coz bude drazsi nez to samotny volani ale ve srovnani s saskarnou kolem execu je to porad zanedbatelny. BTW tohle je ale akademicka otazka - dokonce i na raspi nebude rozdil okem viditelny. Pokud je to RT uloha, tak to daleko spis zabije nedeterminimismus. Pri execu musi kernel nabrat nakou pamet pro proces a kernelovy pameti pro novej task, coz muze zabrat jakykoliv cas mezi nulou a nekonecnem. Nula je samozrejne "normalni" stav, ale kdyz je masina pod tlakem (napriklad proto ze nejaky proces vyzral veskerou volnou pamet a kernel zacne hledat co kde muze vysypat do swapu tak si muzes pekne pockat.Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
Ale jestli to nakonec budete dělat v C++, dejte Qt ještě šanci. Qt není jen GUI, je to i spousta dalších užitečných věcí. Na server to zrovna není, ale pořád to bude jednodušší, než obsluhovat sockety v C++ jinak.Je spousta knihoven s event loopem popřípadě zapojitelných do prakticky libovolného event loopu a čtení a zápis do socketu zvládnou všechny tak nějak podobně.
Ten program je zablokovaný úplně stejně jako při prostém blokujícím čtení z jednoho filedescriptoru, jen to systémové volání čeká na více filedescriptorech najednou a pak řekne, který to byl.Čekání na události z více zdrojů je hlavním smyslem event loopů postavených nad nějakým systémovým voláním, které toto umožňuje.
Select není nějaké periodické čekání. Je to zablokování s timeoutem, aby program mohl čas od času pohnout animací nebo něco zatahat za nohu.A na linuxu je i ten timeout zbytečný, vzhledem k dostupnosti timerfd lze časovač jednoduše považovat za další zdroj událostí, a též ho tak technicky realizovat. Podle mě to Petr napsal správně.
Tiskni Sdílej: