Matthias Clasen z Red Hatu oznámil v diskusním listu vývojářů Fedora Linuxu, že tým Red Hat Display Systems se zaměří na Wayland a podporu HDR na Linuxu a přestane spravovat RPM balíčky pro LibreOffice. V další major verzi RHELu už LibreOffice nebude. Pokud se nenajde správce balíčků pro Fedora Linux, zůstane pouze LibreOffice ve Flatpaku.
Na Steamu lze získat zdarma počítačovou hru Tell Me Why (ProtonDB). Na Epic Games Storu počítačovou hru Midnight Ghost Hunt (ProtonDB).
Společnost Meta představila (YouTube) brýle pro virtuální realitu Meta Quest 3. V prodeji budou na podzim a stát budou od 499,99 dolarů.
Byla vydána nová verze 2.41.0 distribuovaného systému správy verzí Git. Přispělo 95 vývojářů, z toho 29 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Organizace Apache Software Foundation (ASF) vydala verzi 18 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Byla vydána verze 1.70.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. Jako reakce na rostoucí obavy z vlivu korporací na vývoj Rustu a předložený návrh restriktivních zásad používání ochranných známek Rustu, byl nedávno představen komunitní fork Rustu se 100 % méně byrokracie: Crab (CrabLang).
Oliver Smith z Canonicalu shrnuje základní vlastnosti „neměnné“ distribuce Ubuntu Core také ve srovnání s protějšky Chrome OS, Fedora Silverblue a MicroOS. Canonical připravuje desktopovou variantu Ubuntu Core vedle dosavadní serverové/embedded.
Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Fossil (Wikipedie) byl vydán ve verzi 2.22. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
David Malcolm se ve svém příspěvku na blogu vývojářů Red Hatu rozepsal o vylepšeních statické analýzy (volba -fanalyzer) v GCC 13.
--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: