Společnost OpenAI představila GPT-5 (YouTube).
Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.
Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
Byla vydána verze 1.89.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Americká technologická společnost Apple uskuteční v USA další investice ve výši sta miliard dolarů (2,1 bilionu korun). Oznámil to ve středu šéf firmy Tim Cook při setkání v Bílém domě s americkým prezidentem Donaldem Trumpem. Trump zároveň oznámil záměr zavést stoprocentní clo na polovodiče z dovozu.
Zálohovací server Proxmox Backup Server byl vydán v nové stabilní verzi 4.0. Založen je na Debianu 13 Trixie.
Byla vydána nová verze 1.54.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Jan Václav.
Knižní edice správce české národní domény přináší novou knihu zkušeného programátora Pavla Tišnovského s názvem Programovací jazyk Go. Publikace nabízí srozumitelný a prakticky zaměřený pohled na programování v tomto moderním jazyce. Nejedná se však o klasickou učebnici, ale spíše o průvodce pro vývojáře, kteří s Go začínají, nebo pro ty, kdo hledají odpovědi na konkrétní otázky či inspiraci k dalšímu objevování. Tištěná i digitální verze knihy je již nyní k dispozici u většiny knihkupců.
OpenAI zpřístupnila (en) nové nenáročné otevřené jazykové modely gpt-oss (gpt-oss-120b a gpt-oss-20b). Přístupné jsou pod licencí Apache 2.0.
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ějiLenivosť 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čí
Tiskni
Sdílej: