Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Bylo vydáno Ubuntu 24.04.5 LTS, tj. páté opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na poznámkách k vydání.
Švýcarsko testuje přechod z Microsoft 365 na FOSS, konkrétně balík openDesk (Wikipedie) od německé státní společnosti ZenDiS (Wikipedie), s cílem posílit digitální suverenitu.
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.