Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Hodnotit těžko, když Linuxu chybí protikus.Vista má zkrátka velký plus za krok správným směrem při řešení jednoho z nejnepříjemnějších úzkých hrdel současných systémů.V Linuxu se vyskytuje nanejvýš (v některých distribucích) to, že se přednačtou soubory ze staticky definovaného seznamu. Čili i když používám KDE, nachroustají se tam kvanta dat pro GNOME apod., která vůbec nebudu potřebovat. Už jsem se o zmiňoval ("Chytrý přednačítač") o tom, jak hodně je potřeba to vyřešit. Do jisté míry se to také řešilo tady, ale reálné výsledky nevidím.
Vůbec se nedivim, že se do toho nikomu nechce, když to s příchodem "masově použitelnejch" SSD disků již brzy prakticky nebude potřeba.
Pokud si myslis, ze v dobe SSD disku nebude cache zapotrebi tak se asi pletes
Rozhodně si nemyslim, že bude zbytečná cache. Ale prefetch™ tak jak je dneska znám z Vist, tzn. odhad, dle nějakého "magického" algoritmu co by asi tak uživatel mohl chtít spustit.
V linuxu jsou mnohem horší "Achilovy paty", co se týče desktopu, například katastrofálně pomalé (co se "reakční doby" týče) gtk, které by potřebovaly vylepšit, prefetch je až to poslední co hoří*. Ono totiž existují tři scénáře využití aplikace:
* než si tady zase nějakej "linuxák" začne otvírat hubu, jak jemu na jeho "hyper ultra mega" stroji běží v linuxu i Firefox krásně rychle, poznamenám, že spravuju firemní linux síť s ~30PC, reálným HW, a naprostými BFU uživateli, takže mám velmi dobrou představu o tom, co na linuxovém desktopu nejvíc hoří (tzn. na co uživatelé nejvíce nadávají a argumentují při tom: "Ale ve Windows...").
A pak uz jen takova drobnost v podobe ceny ~250Kc/GB.Takže budou asi malé. Pak se teda bude muset řešit úloha, které soubory dát na rychlý disk a který na velký disk (a kdy...). Co mi to připomíná?
Zajímavým nástrojem v této kategorii je "Sledování výkonu". Umožňuje vynést do grafu libovolný počet z mnoha možných sledovaných číselných hodnot (čítačů), sledovat maximum, minimum a průměr dané hodnoty. Množství sledovaných hodnot je vskutku impozantní, od sledování zatížení procesoru přes počet zavedených tříd v .NET runtime, procentuální úspěšnost diskové vyrovnávací paměti až po počet odeslaných Echo zpráv přes ICMPv6.Mám pocit, že něco podobného v menším provedení bylo již ve Windows 95 nebo 98. V XP jsem to neviděl, zdá se, že to zase vzkřísili.
Superfetch je jiste fain ale rekl bych ze pripojeni tmpfs do /tmp a spravnej IO planovac resi plusminus to samy. ano, nekesujou se tak hezky binarky ale to AFAIK ani ve vistach uz moc ne pacz si tam kazda app muze drzet vlastni instance dllek.To není pravda. Kvalitní I/O plánovač je samozřejmost, o tom není třeba diskutovat. Ale problém neřeší. Neřeší ho ani použití tmpfs, protože mnoho programů vůbec s dočasnými soubory nepracuje. Největší brzdou je načítání mnoha malých souborů, zejména pokud jsou rozcourané po disku. Tam by chytré přednačítání mohlo výrazně pomoci - zejména tam, kde je po startu velká část paměti nevyužitá a mohla by se bez problémů využít právě k přednačtení souborů, které budou v nejbližších chvílích použity.
Největší brzdou je načítání mnoha malých souborů, zejména pokud jsou rozcourané po disku. Tam by chytré přednačítání mohlo výrazně pomoci - zejména tam, kde je po startu velká část paměti nevyužitá a mohla by se bez problémů využít právě k přednačtení souborů, které budou v nejbližších chvílích použity.To by slo realizovat i bez sahani do jadra, stacilo by jen sledovat syscally open, read a mmap (myslim, ze tyhle tri staci, nebo ne?), pripadne pres preload knihovny zahakovat jim odopvidajici funkce z libc. Pak je treba jen udaje ulozit, vyhodnotit a podle nich pri staru nekde v initscriptech spustit demona, co bude mit nizkou I/O prioritu (pres ionice -c 3) a seznam souboru, co proste jen otevre a precte, pripadne seznam rozsahu odkud-pokud ma soubor precist.
To by slo realizovat i bez sahani do jadra, stacilo by jen sledovat syscally open, read a mmap (myslim, ze tyhle tri staci, nebo ne?), pripadne pres preload knihovny zahakovat jim odopvidajici funkce z libc.To nestačí. Např. při použitím mmap() by to sledovalo jen samotné namapování, ale už ne skutečné využití (tj. kam to doopravdy sahá). Nehledě na řadu dalších volání. Pokud bych chtěl sledovat jen přístup k souborům, stačilo by využít inotify - bez nutnosti kamkoliv hrabat. I když nevím, jaké by to mělo výkonnostní dopady, protože by to znamenalo vytvořit na každém adresáři v systému jeden watch. Někdy to zkusím změřit.
Pak je treba jen udaje ulozit, vyhodnotit a podle nich pri staru nekde v initscriptech spustit demona, co bude mit nizkou I/O prioritu (pres ionice -c 3) a seznam souboru, co proste jen otevre a precte, pripadne seznam rozsahu odkud-pokud ma soubor precist.Takového démona už někde mám, ale je (stručně řečeno) k prdu. Aby to mělo smysl, musí takový démon fungovat dynamicky, tedy na základě dat, které má k dispozici, volit v reálném čase soubory k přednačítání (např. vědět, že když si spustím nějaké IDE, tak za chvíli budu potřebovat gcc). A to není vůbec triviální a jde o jádro celého pudla.
Kvalitní I/O plánovač je samozřejmost, o tom není třeba diskutovat.Proto jsem psal spravny a ne kvalitni, jeden planovac tezko bude optimalni pro vsechny typy zateze. Takze co jsem tim mel na mysli nebyl jeden nejlepsi™ planovac ale moznost vybrat si.
Největší brzdou je načítání mnoha malých souborů...Stejny pripad - zalezi na vyberu, tentokrat filesystemu. Tahle moznost me ani nenapadla, uz jsem moc dlouho mimo widli eko(no)system abych vyber filesystemu povazoval za neco mimoradnyho. Vzato kolem a kolem, cim vic to tady ctu tim vic mam pocit ze superfetch bude pro widle velky zlepseni ale ze je to jen skryvani priznaku a ne reseni zdroje problemu.
Stejny pripad - zalezi na vyberu, tentokrat filesystemu.
No to ani ne. Pokud hlavička disku bude poskakovat po plotně - protože pořadí načítání jednotlivých souborů je jiné, jako jejich uspořádání na disku - tak každý FS pohoří. Najít uspořádání dat na disku tak, aby vyhovovalo všem situacím je v podstatě nemožné. V podstatě by to šlo částečně řešit změnou API tak, že OS dostane od aplikace seznam souborů, které daná app bude potřebovat - namísto součastného otevířání po jednom - a OS už ví, jak jsou ty soubory na disku a v tomto pořadí je může načíst.
Pokud hlavička disku bude poskakovat po plotně - protože pořadí načítání jednotlivých souborů je jiné, jako jejich uspořádání na disku - tak každý FS pohoří.... a prave proto maji filesystemy pro pevne disky veci jako interni cache, readahead buffery a antifragmentacni algoritmy. Mozna se to bude zdat neuveritelne, ale vyvojari filesystemu nejsou az TAK pitomi.
podľa mňa sa snažíte vyhnúť sa dôsledku, a nie príčine.
ad druhý odstavec ... oddeliť aplikačné data od aplikácií
Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.
btw, optimalizovať by sa malo vždy
Lenivosť programátorov naprogramovať svoje aplikácie lenivé.Snad naopak, ne? Ale jinak souhlasím.
Príklad: save dialog ... hoci nezobrazí obsah adresára, aj tak načíta jeho obsah (gtk 2.8.13)Tohle už jsme tu řešili. Typický případ špatného řešení.
Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.Není pravda. Latenci v desítkách ms mít SSD nebude. Navíc u něj nezáleží na umístění dat, takže není potřeba řešit optimalizaci vzhledem k pozici.
optimalizovať by sa malo vždyPokud se to vyplatí. Většinou nemá smysl prodloužit čas vývoje na dvojnásobek, pokud se tím získá 5% nárůst výkonu.
Snad naopak, ne? Ale jinak souhlasím.lenivé v zmysle nerobiť veci v aktuálnom čase zbytočné. Chovanie aplikácií štýlom "toto možno budem potrebovať, tak mi to priprav (thread na pozadí?), ja si neskôr na to možno počkám", a nie "toto možno budem potrebovať, tak si to teda teraz pripravím".
Myšleno zřejmě bylo psát aplikace tak, aby nedělaly hned, co mohou udělat později Tedy ne lenivé z pohledu výkonu, ale z pohledu množství vykonané práce. Prostě něco jako kapitola 3.5 v SICPLenivosť programátorov naprogramovať svoje aplikácie lenivé.Snad naopak, ne? Ale jinak souhlasím.
Myšleno zřejmě bylo psát aplikace tak, aby nedělaly hned, co mohou udělat pozdějiTohle by bylo asi na delší diskuzi, není až tak jednoznačné, co je správně. Buď můžete
Ono hlavně taky ten procesor nebude stačit. Datové struktury, které Gtk používá v TreeView jsou poněkud neefektivní. Jediné co to umí jsou seznamy a stromečky, které se obtížně a pomalu procházejí a celé to trvá nechutně dlouho. Je úplně jedno jak rychlý disk bude. Než Gtk vyrobí seznam, než ho patřičný widget zobrazí, než se to seřadí, než se tam umístí kurzor,... blé... Krásným příkladem ja gmpc vs. xmms a vyhledávání v seznamu skladeb (v xmms klávesa 'j'). Při stejném množství položek v seznamu to xmms stíhá v reálném čase (rychleji než píšu na klávesnici) a gmpc asi minutu chroustá. Do zdrojáků jsem koukal a gmpc nic zvrhlého ani náročného nedělá. Položek je cca 14 297.Pamäte budú vždy pomalé a pomalšie. Ani SSD vám nepomôže.Není pravda. Latenci v desítkách ms mít SSD nebude. Navíc u něj nezáleží na umístění dat, takže není potřeba řešit optimalizaci vzhledem k pozici.
ale vyvojari filesystemu nejsou az TAK pitomi.
Ulevilo se ti alespoň? Pokud vezmu za příklad těch 100 Lukových souborů, tak všech možných pořadí jejich čtení je:
93326215443944152681699238856266700490715968264381621468592963895217\ 59999322991560894146397615651828625369792082722375825118521091686400\ 0000000000000000000000
Pro tohle nelze žádný FS optimalizovat. Kdyby ten FS dostal od aplikaci informace o souborech, které bude potřebovat, mohl by si je nachystat do cache a číst je v pořadí v jakém jsou uloženy na disku. Ve chvíly, kdyby je program skutečně potřeboval, již by byly v RAM.
Navíc porovnáním ukazuje, co by stálo zato "okopírovat" v Linuxu.S tím okopírováním v Linuxu je to ošemetné. Mnoho věcí (zrovna třeba SuperFetch a mnoho dalších) je kryto řadou patentů. Tady nás to nemusí trápit, ale např. v USA ano a proto i když třeba implementace vznikne, v mnoha distribucích nebude.
Chce prokazat, ze skutecne plati, ze kazda hul ma dva konce?Spíš že každá p.... má dvě půlky
spustil jsem si strace na běžící procesSákryš, mě ani nenapadlo, že by to mohlo jít i takhle. Člověk se pořád učí Díky
Tiskni Sdílej: