PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
1) Jakym zpusobem se dělá přijímací část, která by měla být schopna přijmout zprávy, které budou mít promennou délku.Ja to riešim tak, že každá správa má na začiatku 32-bitový int, ktorý hovorí o dĺžke zvyšku správy. Tebe vlastne stačí 1 bajt lebo máš krátke správy.
Pokud zadam velikost bufferu napriklad 10 byte. A ted poslu zpravu, ktera ma treba 8 byte. Vrati se tato funkce s osmi byte v bufferu, nebo zustane cekat na zbyle 2?man recv(): The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested. Z toho vyplýva, že ak je dostupných 8 bajtov, tak sa sa prečíta 8 bajtov a recv() vráti 8 bajtov. Na zvyšné 2 sa nečaká.
2) Dal jsem se chtel zeptat na hlidani toho ukoncovaciho znaku zpravy - nacitat po jednom byte se mi zda jako hloupost.Dúfam, že dnešné OS sú už natoľko chytré, že si jadro udržuje v pamäti nejaký buffer prijatých bajtov a recv() len vráti to čo v tom buffer-i nájde, takže ani čítanie po jednom znaku by nemuselo byť pomalé. Môžeš to ale riešiť aj tak, že si budeš sčítavať koľko bajtov recv() prečítalo a volať recv() opakovane až kým celkový počet prečítaných znakov nedosiahne počet, ktorý si chcel pôvodne prečítať.
3) Kdyz poslu pres sendv jednu zpravu delce o 3 byte a nasledne druhou zpravu o delce 3 byte a na druhe strane bude funkce recv () cekat s bufferem o velikosti 10 - vrati se mi prvne prvni zprava a potom druha, nebo tyto dve zpravy mi recv vrati za sebou v jednom volani?Vráti sa to v jednom volaní. Pre také množstvá dát ako prenášaš je vhodné použiť socket option TCP_NODELAY - inak vysielač dáta skutočne pošle až po naplnení nejakej veľkosti odosielacieho bufferu alebo vypršaní nejakého timeout-u.
4) Vubec netusim, jakou zvolit velikost bufferu? Budou odesilány zprávy o průměrné velikosti 10 byte, max 40 byte.Zvoľ 40 bajtov a zariaď sa podľa toho čo recv() vráti.
5) Je potreba do kazde zpravy nejak vkladat jeji velikost? Nebo to lze udelat i bez ni?Myslím, že bude jednoduchšie ak tam tá veľkosť (a prípadne nejaký identifikátor typu správy) bude. Ale neexistuje jediná správna cesta.
Dúfam, že dnešné OS sú už natoľko chytré, že si jadro udržuje v pamäti nejaký buffer prijatých bajtov a recv() len vráti to čo v tom buffer-i nájde, takže ani čítanie po jednom znaku by nemuselo byť pomaléI v takovém případě se ale bude muset přepínat mezi kontextem jádra a aplikace pro každý bajt místo pro celý buffer, takže to pomalejší bude. Ono je to v tomto případě asi jedno, ale načítat ta data po jednom bajtu je prostě ošklivé
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
sendv() i recv() pak vždy představují jen jakési okno do tohoto proudu, nejsou to jednotlivé zprávy. Tzn. rozdělení na zprávy si musíte udělat sám, třeba tak, že si délku zprávy napíšete na její začátek. V případě UDP komunikace (založené na zprávách) byste měl použít recvfrom(), pak budete dostávat celé zprávy po jedné.
Ad 1) Vrátí 8 bajtů (nebo klidně méně) v bufferu.To "méně" záleží na nastavení SO_RCVLOWAT (minimální počet bajtů které se vrací - default je 1) a na použití blokujících / neblokujících socketů. Pokud je neblokující a nemáte data, může vrátit -1 a EAGAIN.
Ad 2) Od toho je tam ten buffer, načtete větší množství dat a pak budete hledat v bufferu.Tak. Čtení znak po znaku je obvykle známkou chatrného designu aplikace.
Ad 3) Může se to vrátit jako libovolný počet zpráv – celé jako jedna „zpráva“, rozdělené do dvou zpráva jako 3+3 bajty ale klidně taky jako 2+4, 6 volání po jednom bajtu…Tohle opravdu záleží na tom, jestli používáte datagramový socket (SOCK_DGRAM) nebo proudový (SOCK_STREAM). Datagramy se vrací v jednom kuse. Pokud máte moc malý buffer na celý datagram, je zbytek datagramu zahozen. Proudový socket se tváří jako jeden proud (překvapivě) dat, takže bude příchozí pakety slepovat, nebo naopak si můžete vyžádat jen 10 bajtů a pak dalších 10 a nic se nezahodí. Jestli dostanete 3+3 nebo 6 obvykle záleží na tom jak rychle stihnete ty první 3 vybrat.
Ad 4) Pokud je to takhle malý objem dat, zvolil bych buffer o maximální možné délce zprávy.Normálně se buffer zarovnává na násobky 4096 bajtů, i když to může vypadat jako plýtvání.
Ad 5) Předpokládám, že se celou dobu bavíme o TCP/IP komunikaci. Ta není založena na zprávách, ale na proudu bajtů – sendv() i recv() pak vždy představují jen jakési okno do tohoto proudu, nejsou to jednotlivé zprávy. Tzn. rozdělení na zprávy si musíte udělat sám, třeba tak, že si délku zprávy napíšete na její začátek. V případě UDP komunikace (založené na zprávách) byste měl použít recvfrom(), pak budete dostávat celé zprávy po jedné.Souhlas, až na to, že to chování záleží na typu soketu a ne na protokolu. (Viz také můj popis výše.) Pokud používáte proudový socket, záleží na Vás, jak si vyřešíte rozdělení zpráv. Můžete na začátek zprávy dát délku nebo naopak můžete zprávu ukončit nějakou sekvencí jednoho a více bajtů. Oboje má svoje plus a mínus.
Abych doupresnil - jedna se o TCP komunikaci.V tom případě nevidím důvod se zahazovat s recv a send, použijte normální read a write.
Pokud by prisel jeden bajt, tak ho vrati okamzite?Ano.
Nebo se bude cekat na nejake vetsi mnozstvi, pripadne timeout? To se pripadne nastavuje jak?Viz setsockopt SO_RCVLOWAT (tohle podle manuálu ale nefunguje na linuxu), případně u recv lze také použít flag MSG_WAITALL. Timeout přes setsockopt SO_RCVTIMEO. Pro komplikovanější operace lze použít select().
sendvPokud vím tak sendv neexistuje, maximálně tak writev.
A na prijimaci strane volat recv tolikrat, dokud nenarazim na ukoncovaci znak zpravy. Buffer tedy zarovnam na 4096 bajtů. Kazdy vraceny buffer projdu a zjistim, zda obsahuje ukoncovaci znak. A proste budu muset pocitat s tim, ze by prisel i zacatek nasledujici zpravy.V jazyce C je nejlépe na to udělat cyklický fifo buffer. Např. http://www.vias.org/cppcourse/chap20_05.html nebo http://www.answers.com/topic/circular-buffer-1. Jinak doporučuju míň teoretizovat a spíše program otestovat na různé kombinace možností.
Kazdy vraceny buffer projdu a zjistim, zda obsahuje ukoncovaci znak.Jenom pro jistotu: vždy dostanete hodnotu, která určuje, kolik bajtů bylo do bufferu skutečně zapsáno. Buffer tedy nemůžete procházet celý, ale jenom tolik bajtů z něj, kolik tam bylo zapsáno.
3.5.2010 02:56
Josef Kufner | skóre: 70
5) Je potreba do kazde zpravy nejak vkladat jeji velikost? Nebo to lze udelat i bez ni?Pokud použiješ textový protokol a každou zprávu na samostatný řádek, tak se bez délky obejdeš. Nebo docela dobrá je taky lispová syntaxe – vemeš závorku a čteš dokud nenajdeš druhou do páru (přitom plníš seznam). Rozhodně doporučuju udělat hezký i za cenu, že se bude přenášet o pár bajtů víc. Hezky udělaný jsou POP3 a XMPP, protože POP3 je jednoduchý řádkový a XMPP má univerzální a rozšiřitelný formát (ale pro jednoduché věci radši ten lisp než XML). Hlavně ale počítej s tím, že TCP negarantuje doručení zpráv! Takže si musíš ověřovat, která zpráva byla doručena jako poslední pro případ nekorektně uzavřeného spojení. TCP garantuje pouze pořadí dat, ale doručení jen při správně uzavřeném spojení. Kvůli tomuhle se na Jabberu ztrácejí zprávy, když ti vypadne kabel a server si toho nevšimne...
Tiskni
Sdílej:
