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.
Původní železo:
Deska: Gigabyte M61PME-S2P
CPU: AMD Athlon(tm) Processor LE-1640
RAM: 2GiB, @800 MHz
Disk: 2x 5400ot/min
Device Model: EcoGreen F2 HD502HI
Serial Number: S1VZJ1BS310211
User Capacity: 500,107,862,016 bytes
SMART hlásí teplotu: 23 (Lifetime Min/Max 18/26)
Tiché neparkující dísky s malým odběrem (<5.5 W)
(Jeden reklamovaný ined po koupi, druhý asi po roku, na základě SMART,
od té doba oba zdravé 3+ roků)
Uspořádání disků: RAID1 (mdadm), LVM
XEN: Domain-0 + 3x virtual, všechny něco sem-tam dělají
včetně Domain-0 (DNS + nezatížený fileserver Samba+NFS4)
Kde: dd if=/dev/urandom of=smaz bs=1048576 count=500sha512sum smazNové železo je (to o čem chci psát):
Deska: Intel S1200BTLR
Zdroj: SSR-450RM, SEASONIC G450 450W 80PLUS GOLD
CPU: Xeon E3-1230V2 BOX 3,30 GHz (chladič: Freezer 7 Pro Rev.2)
RAM: 32GiB, (4× DIMM DDR3 8GB 1333 ECC TRANSCEND CL9 STANDARD)
Disk: 2x WD10EZRX GREEN ... 1TB
2× WD20EFRX RED RAID EDITON ... 2TB
2× ST2000VX000 SEAGATE BARRACUDA ... 2TB
Kde: dd if=/dev/urandom of=smaz bs=1048576 count=500
trvá: 47 sec
a: sha512sum smaz
trvá: 1.6 sec
Celkového odběru (prozatím zjištěného) 55-98 W
Doplněno 2013-03-31: Celkový odběr po uspání 4 disků 39.7 W (hdparm -S 240 /dev/sd[d-f])
A bude tam toho o kus víc než před tím + data budou šifrována a místo OpenSuSe tam bude CentOS a místo XEN-u KVM-ko atd.
Je to v „levné-upravé-lehce-odhlučněné“ bedně (je to trochu slyšet, a výrazně méňe než šum radiátoru)
Už si zde povšimněte, že spotřeba celkové sestavy v idle je nižší, výkon nesrovnatelně vyšší 1 jádro vs. 4 a HT, paměti „trochu“ přibylo a úložný prostor je „o kapánek“ větší.
Základní odběry:
Ve vypnutém stavu <3.5W (PC vypnuto, BMC aktivní) Po zapnutí a nastartování systému: 57 W (po „nechání na pokoji“ 55 W) zatížení jednoho jádra (sha512sum) <=73 W zatížení 4 jader (sha512sum 4×) <=95 W zatížení 4HT jader (sha512sum 8+×) <=98 W (připojený LCD monitor, nezapočítaný do odběru, X-ka běží)Kdo neví, tak BMC (Baseboard Management Controller) je takový „mini-os“, který je aktivní i pokud je vypnutý zdroj, ale pod napětím a přes ethernet se můžete přihlásit a ovládat či sledovat (zapnout/vypnout).
Základní stav(y) z BMC:
Processor Fan 784 RPM Sys Fan 1 686 RPM zadní 120mm Sys Fan 2 686 RPM přední spodní 140mm Sys Fan 3 686 RPM horní přední 120mm BMC Board TEMP 36 °C (pro info limit je 105°C) Board Inlet TEMP 26 °C (pro info limit je 105°C) P1 Therm Margin -74 °CZ nastavením ventilátorů jsem si nehrál ani asi nebudu, zvolil jsem to čemu intel říká „Medium ramp“. Vzhledem k tomu, že při pokusech prozatím jsem zvedl teplotu CPU na max -51 °C, takže jsem zatím ani ventilátory nedostal do dalšího limitu a točí se furt stejně, jak je uvedeno výše.
Pokud Vás mate záporná teplota CPU (byl jsem na to stejně), tak je to teplota „kolik ještě zbývá“ k výrobní maximální hodnotě daného modelu a snad i konkrétního kusu (na první pohled to zní to divně, ale je to vlastně přesně to, co nás zajímá) info třeba tady či rovnou tady (pdf-ko).
Spotřeba disků:
Disk: Idle: Zápis: Celkem při zápisu:
WD10EZRX GREEN 3.7 W + 5.0 W = 8.7 W
WD20EFRX RED 4.0 W + 3.7 W = 8.7 W
ST2000VX000 SEAGATE 5.9 W + 4.0 W = 9.9 W
Celkem po 2 ks: 27.2 W 54.6 W
Je to jen jednoduché měření způsobem: zapojím jen systémový disk, nastartuji OS, chvíli počkám, zapíšu odběr a pak jednotlivé disky připojuji provedu to samé, nakonec dvě hodnoty odečtu.dd z /dev/zero přímo na disk a opět rozdíl hodnot před a při zápisu udává hodnotu. Takže měření nijak zvlášť přesná. Pro měření používám watt-metr Energy Check 3000.
Základní výkonové údaje (z testu):
Read MB/s Write MB/s
Disk: Min: Max: Avg: Min: Max: Avg: Acess:
WD10EZRX GREEN 70 218 118 36 119 66 17.2 ms
WD20EFRX RED 66 168 115 57 146 104 19.9 ms
ST2000VX000 SEAGATE 97 232 178 66 147 118 14.2 ms
V přílohách jsou obrázky výsledků testů.
Ceny s DPH
WD10EZRX GREEN 1509 Kč/Ks 1.62 Kč/GiB WD20EFRX RED 2633 Kč/Ks 1.41 Kč/GiB ST2000VX000 SEAGATE 2400 Kč/Ks 1.29 Kč/GiBCo k tomu říct: „WD je horší než Seagate a proto Seagate končí s klasickými disky a čtení je ekologické, proto GREEN je na tom lépe než RED, přičemž zápis zvládá ± stejně (ano, jsou to jiné kapacity…“
Na první závěr, parkování u GREEN disků:
Věděl jsem, že budu muset něco udělat, ale nečekal jsem, že nebude stačit hdparm.
Po chvíli hraní (několika více hodin provozu) jsem tam měl hodnotu u
193 Load/Unload Cycle Count skoro 900.
hdparm -B hlásí APM level = not suported (mimochodem u všech uvedených disků)
I když ve výpise hdparm -I najdeme * Power managment feature set
Pomocí utility od WD a FreeDOS-u jsem uspěl idle3 bylo nastaveno na „vypnuto“ - tedy konec parkování (maximum šlo nastavit 300 sec), existuje i idle3-tools projekt, ale nezkoušel jsem.
Drobná poznámka: pro uplatnění nové hodnoty musí být disk opravdu na chvilku vypnutý, takže bych „jen“ restart nedoporučoval.
Před přestavením se systém dostával s celkovou spotřebu až k 52 W, po přestavení 55-57 W, jak je uvedeno výše.
Na druhý závěr, ventilátory:
Nejraději používám Artic cooling ventilátory nakupované v TS-Bohemii, ale protože jsem to chtěl osadit jednou 140-kou, která v TS-ce nebyla, tak jsem si koupil červený ventilátor, ale už jsem zas na nějakou dobu vyléčený, dělá oproti a ARCTIC F14 PWM randál, s bednou dodaná 120-ka označená jako tichá, oproti ARCTIC F12 PWM je na to podobně, navíc při vyšších otáčkách plašila myši ultrazvukem, takže nakonec jsem všechny ventilátory zas osadil od Arctic-u a s PWM.
Bohužel Alza má na tyto komponenty docela fuj ceny (o 10 % vyšší než se sluší a až o 20 % vyšší než TS-ka…).
Tiskni
Sdílej:
Hraní s malým serverem I.
Xeon E3 3,30 GHz RAM: 32GiB 2x 1TB 4× 2TB…
dd if=/dev/urandom of=smaz bs=1048576 count=500
conv=fsync
conv=fsync - tady je to asi jedno, protože spíš je to rychlost dávaní, než zapisování (a moc jsem na tím nepřemýšlel). Ale uvědomil jsem si, že v některý připravených věcech (na ty testy) mám oflag=sync a teď vlastně nevím jaký je v tom rozdíl.
.
conv=fsync provede fsync nakonec, ale oflag=sync asi po každém bs.
, ten výkon bude využitý jen opravdu ojediněle, ale předchozí uvedené železo je semo-tamo nedostatečné a má radikálně nedostatečnou diskovou kapacitu (a musel by tam jít nový řadič) a nedostatečnou paměť (kde toho už moc udělat nelze), a za chvílí se tam možná začnou šklebit kondíky… $ time dd if=/dev/urandom of=smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 39.0765 s, 13.4 MB/s real 0m39.078s user 0m0.003s sys 0m38.990s2 roky stary desktop s Core i3-2100; 2x3.1GHz; bez TurboBoost. Disk asi 3-4 roky stary WD Green 1TB, 5400rpm. sha512sum uz hadze tak nejak ocakavane vysledky:
$ time sha512sum smaz 33c85bac1e5eb6...271eddcc smaz real 0m2.188s user 0m2.140s sys 0m0.043s
Nieco ti tam asi hnije, alebo ten RAID zerie viac, nez by som cakal:To mu hnije spíš urandom, tohle se přece vejde do cache.
~ # time dd if=/dev/urandom of=nesmaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 57,4556 s, 9,1 MB/s real 0m57.488s user 0m0.000s sys 0m57.324s ~ # time sha512sum nesmaz 33c85bac1e5eb6...271eddcc nesmaz real 0m2.975s user 0m2.888s sys 0m0.080s ~ # time dd if=/dev/urandom of=/dev/null bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 56,4191 s, 9,3 MB/s real 0m56.422s user 0m0.000s sys 0m56.376sCore i3, notebook, šifrovaný disk.
time dd if=/dev/urandom of=smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 57.7799 s, 9.1 MB/s real 0m57.782s user 0m0.000s sys 0m53.927sNa NE-šifrovanou partition:
time dd if=/dev/urandom of=/tests/imega/smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 54.0388 s, 9.7 MB/s real 0m54.041s user 0m0.000s sys 0m53.419sOpakovaně se to mění až v 10 %. (A při detailním sledování v průběhu, vidím, že někdy se zatížení CPU sníží a někdy i přeskočí z jádra na jádro…)
time dd if=/dev/urandom of=/dev/null bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 55.1809 s, 9.5 MB/s real 0m55.183s user 0m0.000s sys 0m55.083sA jak vidno z diskem to nemá mnoho společného.