Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
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).
SSD tento čekací čas eliminuje a zrychlení desktopu je opravdu výrazné.Ja si to porad nejak nedovedu predstavit. To jako kdyz zmacku klavesu v editoru tak se na obrazovce pismenko obevi za 2 ms misto za 4, nebo kde presne bude to "opravdu vyrazne" zrychleni ? Co me napada je treba grep velkyho adresare, kde to s SSD bude poprve vyrazne rychlejsi. Ale kdyz s tim adresarem pracuju tak tech grepu budu delat vic a potom je lepsi kdyz ty data zustanou v pameti nez kdyz se budou pokazdy znovu tahat z SSD. A pripominam ze se tady bavime o "HDD + velka RAM" vs "SSD + mensi RAM", ne o "HDD + velka RAM" vs "SSD + stejne velka RAM".
Ja si to porad nejak nedovedu predstavit.Taky mi přijde, že to musí být hodně debilně napsaný desktop, aby jeho používání takto záviselo na rychlosti disku. Ještě tak chápu natažení molochů jako LibreOffice, ale tam to člověk tak nějak očekává.
Pokud se bavíme o počítači pro vývoj, zápis mnoha malých souborů při kompilaci bude celkem častý případ.Někdy je lepší, pokud to nástroje umí a velikost RAM to dovoluje, provádět kompilaci v ramdisku. Člověk tím i šetří to SSD :).
osc build
"), potřebuji pro buildroot asi 14 GB. Ale ani se samotným překladem a slinkováním bych se do 1 GB určitě nevešel.
Většina aplikací více či méně pracuje s diskem a i když jsou to drobnosti, tak „100× nic umořilo osla“.
Ať je to Gnome, XFCE, Unity, Widle (důvodně předpokládám, že i další), tak s SSD diskem je vše svižnější a někdy výrazně.
Mám desktop s rotačním diskem a NTB s SSD a v práci už je většina jen se systémovým SSD diskem, kdykoliv sednu k počítači s rotačním diskem (o to i 10+K), tak to poznám, že to nemá SSD.
Nevím jaký vývoj, ale pokud bychom se bavili o (složitě ;)) kompilovaných jazycích jako C/C++,
na více-jádrové mašině, kde lze spustit kompilaci ve více vláknech, tak SSD je citelně poznat.
Další, co se vývoje týče, pokud se používá nějaké IDE, vytvářející on-line indexaci, tak tam už je to poznat velmi citelně.
Pokud se otvírá v vim-u pár souborů, tak to taky pomůže, ale jen asi místo 'eee-hned' je to 'hned'.
Pokud je to postaveno: SSD + 8GiB vs. rotační + 32GiB, říkám SSD + 32GiB , ale vybral bych si určitě SSD + 8GiB.
Jen pro zajímavost, když otvírám na Core2Duo s rotačním diskem jedno svoje prostředí na jeden klik za konkrétním účelem (Eclipse, Bouml, Inscape, OO sešit + další doprovodné terminály a aplikace), tak
se rožne červený LED-ka (disk) a trvá to ≈2min, s tím, že v Eclipse 1-3min dobíhají procesy, pokud to samé udělám na NTB s i7 a SSD, tak
do 10 sec je vše ready a dobíhání v Eclipse „jen“ uvidím a je to (třeba 5sec).
A třeba doxygen nad nějakým projektem na rotačním disku vs. SSD - nepopsatelné :), ale je fakt že to se moc často nepotřebuje…
Každopádně s SSD už neblbnu s „RAM disky“…
Názorný příklad: vzal jsem aktuální gitový repozitář jádra, branch master, a dal "git checkout v3.0
". Výsledky podle toho, kde repozitář byl:
(Není to otázka cache, ten počítač má 32 GB paměti a ve všech případech jsem to prováděl dvakrát za sebou a měřil až ten druhý pokus.)
Podobné zkušenosti mám i s buildem jádra: build na tmpfs znamená zrychlení oproti SSD, ale zdaleka ne takové jako SSD oproti klasickému disku. Tam je ale samozřejmě potřeba brát v úvahu i problém počtu opakovaných zápisů.
Podobné zkušenosti mám i s buildem jádra: build na tmpfs znamená zrychlení oproti SSD, ale zdaleka ne takové jako SSD oproti klasickému disku.Díky, tahle zkušenost se hodí.
Tam je ale samozřejmě potřeba brát v úvahu i problém počtu opakovaných zápisů.Máš k tomu nějaké bližší info? Myšleno jak moc se toho má člověk obávat?
Ten odkázaný Xeon zrovna mám v serveru s klasickým Freezerem a donutit jej aby se zapotil a trochu zahřál stoji hodně velké úsilí (včetně ECC pamětí). A jsem si říkal, že bych ho chtěl i na desktopu.
S tímto Seasonic zdrojem, kde můžu říct, že neřve.
Výkřik na závěr: „Xeon jedině Xeon chová se mi to vždy v paralelním prostředí mnohem líp než i7 i bez technických »pindů«“ :)
Tiskni
Sdílej: