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.
* 115 kbps není zas až tak málo a ani to není strop mnoha sériových portůNekde bych jeste mel mit ISA kartu, co udajne umi az 1.5Mbps na seriovem portu (UART 16850??). Nikdy jsem se nedostal k tomu, abych ji nainstaloval a pouzil. Snad se k tomu nekdy dostanu.
ponořit ještě do krabic u mě v práci?Ja uz mam nasysleno dost
SLIP protokol je opravdu primitivní protokol, kde se ethernetí paket obohatí o "escape" znaky END, ESC, ESCESC a ESCEND. SLIP Paket má pak tvar [END][PAKET........][END]. Pokud se v datech paketu najde znak END, tak je nahrazen dvojznakem [ESC][ESCEND] a pokud se v datech najde znak [ESC] tak je nahrazen dvojznakem [ESC][ESCESC]. Tím je zajištěno, že znak END je opravdu na lince vyjímečny a odděluje pakety od sebe. SLIP už pak něřeší opakování paketu, pokud např. dochází k chybám na lince. Určitě je z toho patrné, že CPU musí prozkoumat ethernetí paket bajt po bajtu a nahrazovat speciální znaky a na závěr ještě přidat 2 END znaky, což vypadá pro slabý procesor špatně.
PPP protokol, je už rafinovanější a dokáže navazovat spojení, provadět autentifikace, opakovat pakety při chybách a řídit kdo ví co viz RFC1661. Ale stejně jako v případě SLIP jsou PPP pakety kodovaná pomoci escape znaků jako SLIP. Takže s výkonem CPU budeme o něco hůře, ale zato bude komunikace více odolná vůči poruchám na lince.
Teď otázka, jak moc slabí je ten procesor? 8086XT na 8MHz se zapnutým turbem? Hehe ten určitě ne, ale asi minimálně Pentium na 100MHz, by určitě neměl problém dekodovat SLIP pakety na lince o rychlosti 115200 bps. Stejně by výkon CPU sežraly jiný ovladače a aplikace. A větší rychlosti se na integrovaných COM portech nedá stejně nastavit. Určitě se dá vyždímat i 1Mbit na většině USB sériových převodnících (ty lepší mají i 4Mbity). A i tak RS232 není stavěná na rychlost a při 1Mbitu může délka kabelu dělat problémy (RS422 a RS485 jsou na tom o poznání lepší)
Já osobně jediný využití UARTu jako síťového adaptéru jsem použil na desce s ARM9 na 200MHz. Při rychlosti 115200 bps a s protokolem CSLIP (komprimovaná verze SLIPu) jsem nezaznamenal, že by stím procesor vyloženě bojoval. To ten ARM ještě řešil DHCP + DNSMASQ, iptables a OpenVPN (to už procesor rozhodně poznal). Ono s CSLIPEM a pomocí pingů se linka jevila jako o rychlosi přes 400kbitů i když byla fyzická rychlost jenom 115.2kbitů. A ten ARM udával pseudo výkon kolem 100 BogoMIPSu. Takže s Pentiem Pro na 100MHz by asi byly nastejno. Ono pro embeded desky, kde je mrtě sériovek je ideální si vytvořit další síťové rozhraní, ale u PC jsou většinou i jiné možnosti, jak se dostat k datům.
Myslím, že SLIP je hodně blízko k tomu, že je tzv. "více na drátu". Potom už jedině se zbavit hlaviček paketů a posílat samotný data po UARTu, ale to se pak spojení redukuje na konkrétní port. Třeba za použití tcpsvd data presměrovat do UARTu a na druhé straně z UARTu do konrétní aplikace (aplikace by nebyla by na inetd, ale nějak narafičena na UARTu). Nebo napsat si vlastní utility. To už ten SLIP nebo PPP bude praktičtější.
UART jako síťové rozhraní je opravdu nouzovka, to koupit si siťovku na ISA, PCI nebo USB je určitě lepší a není ani moc drahý. Ale můžu říct, že jsem se setkal s ovladačem, který na ARM9, kde se normálně připojuje audio kodek řešilo síťové spojení. Pakety z ethernetu se serializovaly a na druhé straně opět deserializovaly. Takový pěkný bridge to byl. Samozřejmě místo audio kodeku byl chip, který sériové data moduloval do optiky nebo do kabelu čí bezdrátu. A ARM9 zvládl obousměrný přenos rychlostí 20Mbitů a to se v těch datech musel celkem dosti "hrabat". Sice linuxové jádro bralo 95% CPU a 5% zbylo pro userspace, ale i tak to stačilo.
Jinou praktickou výhodu v UARTu nevidím. Jedině ještě, že byste chtěl nějakým způsobem data po UARTu navázat na vlastnoručně zhotovenou síť (třeba bezdrát na nějakém svým rádiovém kmitočtu). Ale takových maniaků asi moc nebude.
Tiskni
Sdílej: