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.
KernelTrap píše o nápadu implementovat ZFS do jádra (pouze ke čtení), a to na bázi GPLv2 kódu, který uvolnil Sun pro GRUB. Není však zájem toto rozvinout na plnohodnotnou podporu, protože Sun nepovolil použití patentovaných technologií, a to ani přes několik žádostí. Alan Cox se na to dívá tak, že Sun je otevřený podle toho, jak se jim to zrovna (ne)hodí.
Tiskni
Sdílej:
23.7.2008 15:25
andree | skóre: 39
| blog: andreeeeelog
to aby sme si podavali vsetci windows, lebo ntfs je vyborny fs :o)))
nemyslim, ze dovod na vyuzivanie ZFS je preto, ze `je v mode` ..
co sa tyka qouota-y, tak napr.:
zfs set quota=1G pool/home
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
23.7.2008 17:11
24.7.2008 10:07
Snap% v lvs ukáže 100% ukazuje 100% pořád, i když ho zvětším. Takže, samozřejmě, jednou přeplněný snapshot je vhodný už snad jen pro lvremove, protože obsahuje asi poškozená, nebo nekompletní data.
Pořád si ale myslím, že snapshoty v ZFS nejsou záloha. Myslím, že pokud se poškodí souborový systém, můžu mít poškozen i snapshot.
Snapshoty v LVM mohou jako záloha zřejmě fungovat lépe, protože je nějaké poškození nezajímá, je to zkrátka jiná úroveň. Katastrofa ovšem nastane, pokud Snap% dojde až do oněch 100%, žehož se snad dá vyvarovat tak, jak jsi řekl.
A ještě BTW: ani ten snapshot z LVM bych nepovažoval za zálohu. Umožní to, stejně jako ZFS zálohovat online.
Spokojenost s používáním ZFS Vám přeju, ale ty jeho výhody zatím nějak nevidím Což je taky důvod, proč jsem to doopravdy nikdy nezkoušela, jen jsem o tom ledacos přečetla... a minimálně všechny benchmarky, co jsem potkala, vypadaly dost nepřesvědčivě. A to zcela pomíjím neobyčejně perverzní spojení souborového systému a LVM...
Ale vážně: Z jakého důvodu Vám stálo za to přejít na ZFS? Já zatím neslyšela nic než "přešel jsem na ZFS, protože je skvělé" což nezní zrovna přesvědčivě.
.)
Nevím, co přesně jste o ZFS četla a přiznám se, že jsem doufal, že budete v této věci trochu konkrétnější. Co se týče benchmarků, také jsem jich několik viděl a výsledky byly různé podle konkrétního scénáře použití. Je nesporný fakt, že v určitých případech má ZFS horší výkon než tradiční systémy, ale v jiných případech je ten výkon naopak větší. Jsem dalek tomu, abych tvrdil, že je ZFS vždy vhodná volba. Faktorů, které zde hrají roli, je celá řada, a hodně také záleží na konkrétním nastavení. Dlouho jsem se například domníval, že se ZFS vůbec nehodí pro databáze. Ale byl jsem pak překvapen, jakých solidních výsledků se dá dosáhnout se správným nastavením velikosti bloku (zfs set recordsize=<blocksize> <filesystem>) a umístěním WAL (Write-Ahead Log) na samostaný disk s tradičním systémem typu ext3 nebo UFS. Obecně mám pocit, že výhody ZFS v oblasti výkonu se projeví zejména na exponovaných systémech s velkými diskovými poli.
Co se týče perverzního spojení souborového systému a LVM, již jsem se k tomu vyjadřoval výše. Především bych rád připomněl, že i v ZFS je volume manager (zpool) důsledně oddělen od vlastního souborového systému (zfs). Pouze pro komunikaci mezi sebou nepoužívají tradiční rozhraní ve formě blokového zařízení, ale sofistikovanější abstrakci, která se podobá spíše principu alokování operační paměti. Tato změna přístupu umožňuje mnohem efektivněji plánovat I/O operace, vytvářet velmi efektivní (časově i prostorově) snapshoty a klony souborového systému, výrazně zrychluje obnovení degradovaného pole po výměně vadného disku, umožňuje realizovat RAID-5 bez write hole, umožňuje velmi efektivně sdílet volný prostor mezi více souborovými systémy, hlídat konzistenci dat a v případě jejich poškození rozhodnout, která kopie je správná a tuto použít, apod.
Co se týče přechodu na ZFS, tam byly u každého systému důvody různé. Mnohdy nešlo jenom o ZFS, ale i o jiné důvody pro přechod na Solaris, kdy ZFS byl pouze příjemným doplňkem, který by sám o sobě pro přechod nebyl dostatečným argumentem. Pokud se omezím pouze na případy, kdy se přecházelo kvůli ZFS, hrála roli zejména snadná správa, která se mi jeví jako jednodušší, pohodlnější a blbuvzdornější než v případě linuxového RAID/LVM/FS. Klíčovou vlastností je hlídání konzistence dat pomocí kontrolních součtů na úrovni systému. Už se mi bohužel několikrát stalo, že se data na discích a diskových polích poškodila, aniž by systém hlásil jakoukoliv chybu. K tomuhle by u ZFS nemělo dojít. Dalším důvodem bylo rychlé zotavení degenerovaného RAID pole po výměně vadného disku. U našeho datového skladu (datawarehouse) hrálo roli i snadné přidávání dalších disků do pole bez nutnosti rekonfigurace souborového systému a sdílení volného místa mezi jednotlivými systémy. U serveru s méně kritickými aplikacemi běžícími nad MySQl a Postgresql jsme potřebovali možnost snadného zálohování bez nutnosti pozastavit běh služby, což velmi elegantně řeší snapshoty (mám konzistentní kopii dat, kterou pak mohu v klidu zabalit a odložit na pásku nebo jiné zálohovací zařízeni, zatímco služba vesele běží dál).
Na počítači u mne doma jsme na Solaris a ZFS přešel proto, že jsem si chtěl udělat malé diskové políčko a chtěl jsem si ZFS vyzkoušet (ano, to je možné označit jako módní důvod ). Hodně mne láká přechod na Solaris a ZFS i na mém notebooku, kde by se mi hodně líbilo zálohování a synchronizace dat pomocí snapshotů a příkazů zfs send/receive, které umožňují velmi efektivní inkrementální synchronizaci souborových systémů. Ale bohužel v práci používám programy a nástroje, které v Solarisu nejsou oficiálně podporovány (např. Lotus Notes, VMWare, apod.) a i kdyby se mi je povedlo zprovoznit, nemohu si dovolit je používat bez záruky spolehlivého provozu. Takže na notebooku zatím zůstávám u svého oblíbeného OpenSuse .