Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
Pluto.jl, reaktivní notebook pro programovací jazyk Julia, dospěl do verze 1.0.
Byla vydána nová verze 12.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
RAID 1 nasazujeme, abychom nepřišli o data, pokud nám selže disk. Existují ale mnohem zákeřnější hrozby, než selhání disku.
Nedávno jsem se kvůli jednomu incidentu začal obávat, že se můj disk se spoustou nezazálohovaných dat připravuje na cestu do věčných lovišť. Nakoupil jsem tedy dva stejně velké disky, připojil je přes PCI SATA řadič s čipsetem SiI 3114, rozdělil je a vytvořil na nich sw raid 1. Data jsem na toto pole úspěšně zálohoval.
K očekávanému kolapsu původního disku nedošlo, obavy o jeho ztrátu se rozplynuly, a tak jsem začal přemýšlet, co s tím vším místem navíc. Prozatím jsem se rozhodl na něm ponechat zálohy všeho, co jsem umístil do raidu. Velmi moudrá volba.
Za pár týdnů jsem zjistil, že md5 součty souborů nějak nesouhlasí s původními zálohami. Větší soubory na raidu měly odlišné součty. Poruchu některého z disků jsem rychle vyloučil, operace v rámci každého z disků byly prováděny v přádku. Problém nastával pouze při operacích nad raidem. Šestiportový (4 int., 2 ext.) PCI SATA řadič to prostě nějak nezvládal, ačkoliv jsem obsadil pouze dva porty.
Problém jsem vyřešil přehozením jednoho z disků na jiný řadič, ale data na raidu již byla plná drobných chyb. Při opakovaném čtení stejného souboru jsem dostával různé výsledky (podle toho, ze kterého disku se ten či onen fragment souboru četl). Naštěstí jsem reálně přišel jen o naprosté minimum dat, neboť jsem měl zálohy skoro všeho na původním disku. Moje přehnaná opatrnost se vyplatila.
Když zvážím, co všechno se mohlo stát, kdybych si toho nevšiml, běhá mi mráz po zádech. Když selže disk nebo souborový systém, tak si toho člověk velmi rychle všimne, ale drobných chyb při čtení a zápisu ne, alespoň ne hned. A až si toho konečně všimne, chvíli trvá, než objeví pravou příčinu. Já jsem podezříval jednu paměťovou kartu, že přestává fungovat a vrací mi porušené fotky, zatímco celou dobu byl příčinou raid, na který jsem je ukládal.
Bral jsem v úvahu lecos - kolaps jednoho z disků nebo souborového systému, omylem puštěné "rm -rf /" (chattr +i je neocenitelným pomocníkem), ale něco takového tedy ne. Až do této chvíle. Od teď budu md5sum používat mnohem častěji...
Tiskni
Sdílej:
data budu zrcadlit cronem prostřednictvím rsync jednou denně.takže v podstatě zase online zálohování... To není šťastná volba
Takže doporučuju alespoň důležité věci (/etc/, /home/, /srv/) projet tarem, bzipem, gnupg, zkopírovat na jiný stroj pod názvem mantisha.m4r3k.org-17:23-20070914.tar.bz2.gpg (to je jen příklad, tak to pojmenovávám já
) No a jednou za čas buďto povymazávat staré, nebo povypalovat. (Já vypaluju.)
RAID 1 nasazujeme, abychom nepřišli o data, pokud nám selže disk. Existují ale mnohem zákeřnější hrozby než selhání disku.
Například uživatelé… :-)
Ten můj Kouwell má 3512, tak doufám že to je ok. Náhodou si něco o něm neslyšel? Jen jestli ho mám střelit a koupit Adaptec se kterým jsem na serveru moc spokojený :) MD5 součty zatím sedí, ale nemám tu žádný 100GB soubor abych to vyzkoušel pořádně :(
Taky je možná otázka, jestli pisatel použlil soft raid v linuxu nebo softraid na tom řadiči.
dd if=/dev/urandom of=testfile bs=1M count=1500
Pozor na diskovou cache, tj. testovací soubor se prověřovat čtením z disku, ne z paměti, kam se samozřejmě při práci natáhne, pokud není dost veliký. Já vytvářel testovací soubory o velikosti 1,5G.