Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 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.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
--layout=f2
) nebo na trech (--layout=f3
)
Treba tu, i kdyz benchmark primo nehovori ve prospech far, u mne to bylo vzdy rychlejsi nez Raid 1
Pokud mám k dispozici tři disky, ze kterých bych mohl sestavit raid1, je lepší sestavit raid1 se všemi třemi disky aktivními a nebo sestavit disk se dvěma aktivními a jedním spare diskem?Něco mi uniká ? Do teď jsem žil v představě, že RAID1 neboli mirror lze použít vždy jen pro dva disky... Případně pak s větším množstvím disků lze vytvořit raid 10. Nebo se dají např. dva spojit ( concat, raid0-stripe ) a teprve nad touto skupinou dělat zrcadlo na stejnou konfiguraci. tři disky netuším.... 1+1 mirror a třetí spare to ano. ale tři aktivní disky v raidu 1 ?
Maximum number of physical devices Non-RAID: 32 RAID 0: 16 per volume RAID 1: 2 per volume plus hot spare RAID 5: 16 per volume RAID 10: 16 per volume RAID 50: 16 per volumeMyslel bych si, že to nikdo nepoužije, přeci jen SW raid to musí protlačit přes PCI/PCI-E sběrnici, pro každý disk extra, takže čím víc disků tím pomalejší zápis ? ( teorie ) Takže u 3 disků je sice rychlejší čtení, ale zase o to pomalejší zápis bych si myslel.
Se třemi disky je lepší uvažovat o RAID 5.
RAID 5 je výhodný, protože má v porovnání s RAID 1 a RAID 10 vyšší výkon.
Toto tvrzení je naprosto stejný nesmysl, protože slovo výkon není patřičně definované. RAID 5 bude pomaleji číst a rychleji zapisovat ve srovnání s RAID 1. Tedy může být lepší i horší, podle toho, co z toho se považuje za výkon. Někdo může do definice výkonu zahrnout i efektivitu z pohledu kapacity.
Nesoulad mezi RAIDem a filesystémem na něm je evergreen mezi problémy. Právě proto je nejlepší mít RAID integrovaný přímo ve filesystému. Nemusí se pak synchronizovat prázdné místo a kromě pouhé parity je najednou k dispozici víc checksumů v několika „rozměrech“, tj. například když jeden z disků vrací neplatná data (a tváří se, jako by nic), dá se odlišit, který to byl, a tak dále a tak podobně. Zatím tohle umožňují jenom Btrfs a ZFS. (Možná taky HAMMER z DragonFly BSD, jenže ... no, kdo z vás to má?)
S velikostí bloku bych si hlavu moc nelámal, protože velikost bloku filesystému většinou bývá někde kolem velikosti stránky, zatímco RAID stripe má tak šestnáctinásobek, ne-li víc, v implicitní konfiguraci. Pokud například zápis šestnácti RAID bloků trvá stejnou dobu jako zápis jednoho (což je většinou pravda), není to až takový problém.
Malá velikost stripe podle mě nemá smysl, protože při malých souborech je všechno jedno a drtivě převáží čas nutný pro seekování. Tam je výkon srovnatelný s jedním diskem, snad jen RAID 1 bude lepší v tom smyslu, že může seekovat několik malých souborů paralelně (z každého disku jiný). Pokud jde naopak o přenos velkých souborů, tam se výhody RAIDu naplno projeví, ale v tom případě už nevadí, když bude stripe třeba 1 MB. Těch obvyklých 64 kB by mohl být docela rozumný kompromis.
Tiskni
Sdílej: