Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
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 .