Společnost Anthropic vydala Claude 3.5 Sonnet, tj. novou verzi své umělé inteligence Claude (Wikipedie). Videoukázky na YouTube. S Claude 3, stejně jak s GPT-3.5, Llama 3 a Mixtral, si lze pokecat bez přihlašování na DuckDuckGo AI Chat.
Byla vydána nová stabilní verze 6.8 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 126. Přehled novinek i s náhledy v příspěvku na blogu a na YouTube. Vypíchnuta jsou vylepšení v integrovaném poštovním klientu.
Příspěvek Aukce domén – měsíc po spuštění na blogu CZ.NIC shrnuje první měsíc provozu Aukce domén .CZ. Aukcemi prošlo celkem 18 174 domén, z toho na 742 z nich byl učiněn alespoň 1 příhoz. Nejdražší aukcí byla na doménu virtualnisidlo.cz s cenou 95 001 Kč, která však nebyla včas uhrazena. Nejdražší aukcí, která byla vydražena i zaplacena je praguecityline.cz s cenovkou 55 600 Kč.
Před 40 lety, 19. června 1984, Bob Scheifler představil první verzi okenního systému X (X Window System). Vycházela z okenního systému W (W Window System).
Desktopové prostředí MATE bylo vydáno ve verzi 1.28. V gitových repozitářích je sice už od února, ale oznámení vydání se na webu objevilo s několikaměsíčním zpožděním (únorové datum zveřejnění je nepravdivé). Jde o první velké vydání od roku 2021. Uživatelsky nejvýznamnější pokrok je v podpoře Waylandu.
Laboratoře CZ.NIC vydaly novou verzi 4.24.0 aplikace Datovka, tj. svobodné multiplatformní desktopové aplikace pro přístup k datovým schránkám a k trvalému uchovávání datových zpráv v lokální databázi. Přidány byly nové parametry do rozhraní příkazové řádky „export-msg“, „export-msgs“, „import-msg“ a „import-msgs“, které dovolují číst/zapisovat zprávy z/do databází. Veliký panel nástrojů byl nahrazen více nastavitelnými
… více »Mapnik (Wikipedie), tj. open source toolkit pro vykreslování map a vývoj mapových aplikací, byl vydán ve verzi 4.0.0. Přehled změn na GitHubu.
Mozilla koupila firmu Anonym, tj. průkopníka v "digitální reklamě chránící soukromí".
Knihovna htmx (Wikipedie, GitHub), tj. knihovna rozšiřující HTML o nové atributy a umožňující vývoj dynamických webových aplikací, byla vydána ve verzi 2.0 (𝕏).
Společnosti DeepComputing a Framework Computer společně představily RISC-V základní desku pro modulární Framework Laptop 13.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Jednou z hlavních (a opravdu pořádně velkých) bolestí je neexistence jednotného rozhraní pro příjem událostí a jejich snadné a bezpečné zpracování. S tím, jak se technologie kevent
blíží k rozumně použitelné implementaci, samozřejmě roste naděje na změnu. Současně ovšem vyvstávají i otázky.
Zpracovávat v Linuxu rozumně události? Dosud nemožné. Máme například program (řekněme server), který má otevřeno x síťových spojení, současně potřebuje hlídat timeouty, sledovat změny určitých souborů a dělat případně některé další věci. Takový server se implementuje dost špatně - buď ho musíme rozštěpit na řadu procesů či vláken (a babrat se s komunikací a synchronizací mezi nimi), nebo používat všelijaká krkolomná řešení, navíc nepříliš efektivní.
To v takových Windows je na tom člověk o poznání lépe. Může nechat čekat program v jediném volání WaitForMultipleObjects()
, a když to vyskočí ven, obsloužit událost, ke které došlo. Lhostejno, o jaký druh události se jednalo. Podobně jednoduchou práci mají i vývojáři na *BSD nebo na Mac OS X. Jen Linux zatím pokulhává.
Jednoduché je to v případech, kdy máme k dispozici souborové deskriptory. Ty použijeme ve volání select()
, poll()
nebo epoll()
a hned se dozvíme, co se stalo. Problém je ovšem v tom, že tyto deskriptory máme jen pro omezený okruh událostí. Pro mnohé události (asynchronní I/O, časovače, skončení podřízeného procesu atd.) musíme spoléhat na signály - a ty s výše uvedeným nejdou příliš dohromady. Jediným skutečně bezpečným způsobem zpracování signálů je volání sigwait()
, které pak musíme použít místo zmíněných funkcí. Tím se ovšem nevyřeší problém se "spojováním" nezpracovaných klasických signálů.
Je jasné, že cesta ven vede jen přes zavedení skutečně univerzálního rozhraní pro události. Bylo by principiálně možné říct si "všechno bude deskriptor", ale pak vyvstane problém škálovatelnosti. Při velkém množství deskriptorů by to bylo pomalé. Než vymýšlet složitá řešení ve stylu inotify
(na jednom souborovém deskriptoru může být větší počet "hooků" identifikovaných vlastními deskriptory), je lépe to udělat opravdu pořádně a dát do nového rozhraní opravdu všechno, co by mohl někdo potřebovat.
A tím se dostávám k jádru pudla. Dosavadní plány kevent
u totiž počítají s tím, že se budou sledovat skoro všechny zajímavé události (AIO, časovače, signály, klasické deskriptorové události), ale bohužel ne úplně všechny. Protože si myslím, že by bylo správné využít této chvíle a dotáhnout to do opravdu kvalitní podoby, rád bych viděl v kevent
u i další události. Jmenovitě:
Možná teď někdo bude mít pocit, že jsem se praštil o futro a chci z Linuxu udělat Windows. Třeba to tak je, ale každopádně by přidání monitoringu těchto událostí bylo velice přínosné. Mám v plánu poslat to jako námět do LKML, ale nejdřív to tu chci předhodit k veřejné kritice. Byl bych rád, kdyby ten, kdo má proti takovém nápadu nějaké výhrady, je tu předložil - aby se zamezilo případnému zaplevelování LKML (a zbytečné zátěži vývojářů jádra) nesmyslnými nápady.
Tiskni
Sdílej:
Jednoduché je to v případech, kdy máme k dispozici souborové deskriptory. Ty použijeme ve volání select(), poll() nebo epoll() a hned se dozvíme, co se stalo. Problém je ovšem v tom, že tyto deskriptory máme jen pro omezený okruh událostí. Pro mnohé události (asynchronní I/O, časovače, skončení podřízeného procesu atd.) musíme spoléhat na signály - a ty s výše uvedeným nejdou příliš dohromady.Ad asynchronní I/O a deskriptory - píšeš, že jediným skutečně bezpečným způsobem zpracování signálů je volání
sigwait()
. Co je špatně na způsobu, kdy se při zpracování signálu SIGIO pomocí select()
otestují deskriptory a příslušně se zareaguje? (Za předpokladu, že deskriptorů není příliš mnoho)
sigwait()
(a samozřejmě také sigwaitinfo()
a sigtimedwait()
) má tu výhodu, že se zpracuje vždy právě jeden signál (a ostatní zůstávají blokované) a nepoužívá se - není potřeba - asynchronní handler. Při jiném řešení už nastávají komplikace s rozlišováním, které všechny signály vlastně přišly. Tak jako tak tam ale zůstane problém s výkonností, protože select/poll operace je obecně O(n).
int main() { struct sigaction sigakce; void io_sigio (int i); void casovano (int i); ... sigakce.sa_handler = io_sigio; sigfillset (&sigakce.sa_mask); sigakce.sa_flags = 0; sigaction (SIGIO, &sigakce, NULL); sigakce.sa_handler = casovano; sigaction (SIGALRM, &sigakce, NULL); for (;;) {pause();} }Program má jenom reagovat na události - příchod dat ze sítě a periférií a na časovač, takže čeká v nekonečné smyčce. Jestli jsem to dobře pochopil, tak při použití
sigwait()
by program v nekonečné smyčce volal tuto funkci a rozhodoval, jaký signál přišel a jak se zachovat.
Při jiném řešení už nastávají komplikace s rozlišováním, které všechny signály vlastně přišly.To znamená, že když nepoužívám sigwait() a přijde víc signálů najednou, že se některé zahodí a nezpracují? Já měl zato, že se nejprve zavolá obsluha jednoho a pak druhého.
Tak jako tak tam ale zůstane problém s výkonností, protože select/poll operace je obecně O(n).Jasně, proto jsem psal, že předpokládám, že deskriptorů je málo (tento případ rozhodně není to, co je popsáno v blogu - tj. server s mnoha síťovými spojeními, otevřenými soubory apod.)
volatile
(= rychlost dolů). A tak dále.
Jestli jsem to dobře pochopil, tak při použití sigwait() by program v nekonečné smyčce volal tuto funkci a rozhodoval, jaký signál přišel a jak se zachovat.
sigwait()
vrací (resp. zapisuje přes pointer) číslo signálu, který přišel. Funkce sigwaitinfo()
a sigtimedwait()
dělají totéž, ale navíc ještě poskytují další informace (např. identifikátor časovače, PID ukončeného potomka, PID procesu, který zavolal kill()
apod.).
Všechny tyto funkce fungují tak, že se zavolají s blokovanými signály, tyto se uvnitř odblokují, a když přijde první signál (nebo už nějaký čeká), zase se všechny signály zablokují a vyskočí to ven z funkce. To vše atomicky. Pak lze bezpečně a synchronně dělat cokoliv. Takže se to používá tak, že se v nekonečné smyčce volá sigwait()
a vždy se podle čísla signálu zjistí, jaká událost nastala.
To znamená, že když nepoužívám sigwait() a přijde víc signálů najednou, že se některé zahodí a nezpracují? Já měl zato, že se nejprve zavolá obsluha jednoho a pak druhého.Signál se "zahodí" jen v jediném případě - že se jedná o obyčejný (klasický POSIXový, ne-realtime) signál a již nějaký čeká na zpracování. Ovšem když přijde více signálů "najednou" (tedy těsně po sobě), začne se zpracovávat jeden, a pokud ty další nejsou blokované, může kdykoliv začít obsluha jiného (s jiným číslem). Takže to doběhne třeba do půlky handleru a v tu chvíli začne obsluha jiného signálu. Blokace v handleru to úplně neřeší, protože se nemusí stihnout (i když toto není většinou tragédie). Horší ale je, že jsou to pro každý handler 2 syscally navíc, což sežere dost času. Tohle je výhoda
sigwait()
, že takové problémy se nemusejí vůbec řešit.