Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. 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.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Rozdělení disků klidně můžeme odvodit ze stávajícího, ale s ohledem na RAID, je možná vhodnější zvolit jen jednu velkou partition (pokud tomu nebrání něco jiného, například požadavek na připojení některých oddílů jen pro čtení). Důvod pro jedinou partition s RAIDem na každém disku je ve výkonu. Ovladač RAIDu se totiž snaží optimalizovat čtení z pole a čte buď z prvního disku který nic neprovádí nebo z disku od kterého naposledy požadoval přístup do nejbližší oblasti. Protože poslední oblast přístupu je uložena v informacích o každém RAID poli, nebude se tento algoritmus při více polích na jednom disku chovat moc efektivně.
Na druhou stranu, pokud budou mít oba oddíly stejnou úroveň RAIDu, bude k něčemu dobré oddělovat systém od dat?Napadá mě možnost, že se do budoucna počítá s oddělením dat na samostatné disky.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
mv
Doporučuji nic nerozdělovat a použít Btrfs RAID 1. Po ztrátě jednoho disku se nic nerozpadne, od toho je přece RAID 1, aby se to nestalo. GRUB pak bez problémů nabootuje z kteréhokoliv disku. Dělení na partitions je nápad z minulého desetiletí. Vhodnější je vytvořit si subvolumes, které lze snadno atomicky zálohovat pomocí snapshotů a které mezi sebou nemají žádné předem dané hranice.
Softwarový RAID je téměř vždy lepší řešení než jakýkoliv fake raid na desce, jak z hlediska výkonu, tak z hlediska diagnostiky, přenositelnosti na jiné systémy a tak dále. Hardwarový RAID, který stojí za řeč, zpravidla rovnou na desce nebývá.
Pokud chcete za každou cenu mít oddíly a zrcadlit je pomocí klasického softwarového RAIDu (tedy buď pomocí LVM mirroru nebo pomocí ještě klasičtějšího mdadm RAIDu), neexistuje žádný rozdíl ve výkonnosti mezi zrcadlením celého disku a zrcadlením jednotlivých oddílů. Jediné, na co je třeba někdy dát pozor, je správné zarovnání těch oddílů. (Na to by ale měly implicitně dohlédnout všechny možné tooly, kterými se oddíly vytváří.) Zrcadlení po jednotlivých oddílech může být taky jedinou možností v případě, že se GRUBu zrcadlení celého disku nelíbí. (Což se klidně může stát, pokud takovou situaci člověk správně neošetří a nenechá na začátku disku potřebné místo pro GRUB. Ani pak ale nemusí být vyhráno, jako ostatně u všech netypických konfigurací... S klasickými oddíly si GRUB zaručeně poradí.)
Nicméně jak už jsem psal, řešení, na kterém bude fungovat ihned a bez složitého nastavování GRUB i RAID 1, tkví ve vytvoření jednoho velkého oddílu na každém disku (aby zabíral celý disk) a spojení těch dvou disků/oddílů do Btrfs RAID 1.
Ano, bez nejmenších problémů. Samozřejmě to musí být GRUB 2, nikoliv nějaká fosilní verze. 
Je tam ještě jedna výhoda: Když je /boot partition na Btrfs RAID1, dá se pak nabootovat z kteréhokoliv (jednoho) ze zúčastněných disků. To taky GRUB umí. Ne že by to s mdadm nešlo taky, ale nakonfigurovat takto Btrfs je jednodušší, zkrátka je tam o vrstvu méně.
30.8.2013 15:50
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data.
File systems ---> <*> Btrfs filesystem support [*] Btrfs with integrity check tool compiled in (DANGEROUS)Fandím tomuto FS, ale na vážny server by som ho naozaj nedával.
Řeči typu „na server bych to nedal“ jsou fakt úsměvné. Nechápu, proč by se měl server od desktopů nějak zásadně lišit. V mém případě se servery a desktopy nikdy příliš nelišily. Spousta záležitostí kolem správy a údržby se tím výrazně usnadní.
A taky mě fascinuje ta naivita, s jakou někteří používají ext4, který má za poslední roky soustavně víc problémů než Btrfs, a dušují se, že Btrfs fakt ještě ne. 
Btrfs se hodí právě tam, kde se nezálohuje až tak často. Zkrátka proto, že má checksumming, že umí sám od sebe zajistit replikaci dat i metadat jak v rámci jednoho diskového oddílu, tak i pomocí RAID konfigurací a tak dále a tak podobně. Když se v klasickém RAIDu 1 v jedné ze dvou replik objeví špatná data, která z replik je správná? Btrfs to ví (při použití jeho vestavěného RAIDu), zatímco ext4 o tom nemá ani ponětí a s klidem naservíruje poškozená data. To je samozřejmě jen zlomek ze všech výhod, které Btrfs nabízí.
Nechápu, proč by se měl server od desktopů nějak zásadně lišit.Protože když se mi vysere fs na desktopu, budu naštvaný já. Když na serveru, budou kvůli výpadku naštvaní zákazníci (zde předpokládám, že mám zálohy, takže budou naštvaní jenom kvůli výpadku.)
A taky mě fascinuje ta naivita, s jakou někteří používají ext4, který má za poslední roky soustavně víc problémů než Btrfs.Za poslední roky používání ext4 jsem nenarazil na jediný problém. Po zkušenostech s opakovaně se samorozbíjejícím reiserfs o velikosti několik TB (lepší smazat, než se několik dní snažit to obnovit), mi to stačí.
Nechápu, co má společného rozbíjející se ReiserFS a nedůvěra k Btrfs. Je tam snad nějaká souvislost?
Já se zase rád směju dobrovolníkům, kteří testují filesystémy bez kontrolních součtů na svých datech. Někteří lidé mají velmi volnou definici „svých dat“.
Samozrejme hovorim o verzii 3.6
Ten popisek je už několik let naprosto neaktuální. Nebýt různých komplikací (například fanatiků trvajících na offline fsck toolu), byl by už Btrfs dávno implicitním filesystémem ve Fedoře. Už cca od verze 16 se o tom uvažuje. Každopádně například zrovna Fedora podporuje Btrfs velmi solidně, jen je třeba v Anacondě nezvolit implicitní rozložení, kde se úplně zbytečně vytváří ext4 /boot oddíl, a místo toho rovnou zformátovat 100% celý disk jako Btrfs (tj. vytvořit na něm 1 oddíl a na něm pak Btrfs — přímý formát disku bez oddílů by neumožnil správnou funkci GRUBu).
Pokud jde o offline fsck, ZFS taky nikdy nic podobného nikdy neměl a prostě funguje. Idea těchto filesystémů je, že částečný fsck se dá provést kdykoliv za chodu (scrub) a cokoliv, co by normálně opravoval fsck, se dá udělat částečně při mountu a částečně pak později na pozadí.
Slovo DANGEROUS je zde téměř vytržené z kontextu. Samozřejmě, že integrity tool tam být nemusí a normálně je tahle volba vypnutá. To je tool určený momentálně spíš pro vývojáře Btrfs. Není důvod takovou věc mít zapnutou.
Btrfs používám od roku 2010 k naprosté spokojenosti a označení DANGEROUS by si zasloužil spíš ext4, kvůli kterému už spousta serverů přišla o data. I ext3 má už dost másla na hlavě, protože se při každé větší změně ve VFS aspoň tu a tam něco rozsype. Přesto před ext4 kupodivu nikdo nevaruje. Bugy se odstraní a život jde dál. Btrfs měl za stejné období mnohem méně veřejně propíraných bugů a nepamatuji si, že by měl nějakou kauzu se ztrátou dat srovnatelnou s průsery ext4. Nikdy jsem u něj nezažil nic, co by nespravil btrfs_zero_log (a to bylo asi tak to nejzávažnější, co se s ním kdy stalo).
Zatímco ext4 ne. Osobně jsem ale zažil snad jedině problém s Reiserem 4 a volným místem, cca v roce 2008, když jsem ten filesystém ještě používal.
Ale řekl bych, že všechny bugy tohoto typu jsou už minulost.
Například v ext4 taky nejsou vychytané všechny bugy a kritické problémy spojené se ztrátou dat se u ext4 tu a tam stále objevují, narozdíl od Btrfs. Přesto ho lidé na serverech mají. Taky se ext4 od Btrfs liší například tím, že nemá checksumming, takže bude klidně vracet neplatná a poškozená data, aniž by se to uživatel dozvěděl. Navíc na většině filesystémů není k dispozici automatická replikace dat a metadat, nefunguje tam cp --reflink a copy-on-write obecně, není tam vestavěný a efektivní RAID, který dovede při poškození integrity dat odhalit, který z disků vrací špatná data, není tam automatická online defragmentace... Tohle všechno Btrfs má.
Momentálně na čtyřech, ale nedělají nic jiného než hosting virtuálních strojů. Takže tam samozřejmě cp --reflink rulezzz na celé čáře. Srovnání výkonnosti s jiným filesystémem na stejném hardware (tj. jestli je opravdu Btrfs lepší třeba pro databáze než filesystémy bez CoW) jsem nikdy příliš neřešil. Killer features Btrfs (kontrolní součty dat, cp --reflink, snapshoty, vestavěný RAID) byly natolik zásadní, že otázka, zda je Btrfs výkonnější, nikdy nebyla na prvním místě.
Žádnou statistiku o nasazení Btrfs nemám. Z pár diskusí s některými administrátory mám ryze osobní a ničím nepodložený dojem, že 90% lidí volí implicitní volby instalátoru, aniž by o filesystémech vůbec přemýšleli a aniž by se snažili něco bližšího o nich zjistit. Ze zbývajících 10% asi tak 9% podlehlo populárnímu FUDu kolem Btrfs. (Stačí si přečíst tuto diskusi.)
Těsně před vydáním 3.0 jsem to už měl na noteboocích a na nějakém desktopu, na těch serverech to bylo asi tak od 3.1 nebo 3.2, jestli si pamatuju.
To se přece nedá takhle střelit od boku. Záleží to na způsobu využití serverů (protože ḿódní výraz „produkční“ nikdy nikdo pořádně nedefinoval), na konkrétní dohodě s klienty nebo obecně s uživateli a tak dále. Na serverech se dá provozovat všechno možné od distribuovaných záležitostí s multi-version concurrency a postupnou aktualizací nějakého cloudu až po nějaké kritické centralizované řešení schované málem v bankovním trezoru. Pro každý případ se hodí trochu jiné systémové prostředí a jiný plán upgradování.
protože módní výraz „produkční“ nikdy nikdo pořádně nedefinovalDobrá definice je "server, za jehož běh mi někdo platí, a když to bude padat, tak mi platit přestane"
Server musí být schopen nabootovat každý měsíc, každý den, každou hodinu — jinak není spolehlivě použitelný. Jistě může mít uptime třeba rok, ale pak je to časovaná bomba, která se projeví, když to člověk nejméně čeká. (On někdo dřív nebo později tu údržbu UPS naplánuje. Tak to prostě je.) Dlouhý uptime se na jedné straně považuje za jakési prověření kvality systému, zda si dovede dlouhodobě udržet jakousi homeostázu, ale ze všech ostatních hledisek je to nesmysl. Je to taková podivná frajeřina, která připomíná čekání na další exploity a na to, který nový exploit se někomu proti serveru podaří použít.
Výkon jsem nikdy neporovnával s ext4 nebo jiným filesystémem, přiznám se. Prostě se mi líbila možnost kdykoliv udělat atomický backup celého běžícího systému, případně mávnutím kouzelného proutku zreplikovat storage od virtuálního stroje téměř okamžitě a bez overheadu, který by stál za řeč, takže jsem si řekl, že pokud to nebude performance katastrofa (což nebyla), mohlo by to být OK. Jsou tam kontrolní součty dat, takže už proto se dá tak trochu očekávat, že výkon bude třeba v některých ohledech horší než u jednodušších filesystémů.
Btrfs neslibuje lepší výkon než (všechny) ostatní filesystémy. Má checksumming dat, což přináší snížení výkonu ve spoustě případů. To mi ale nepřipadá tak podstatné ve srovnání s výhodami, které Btrfs nabízí. Chci-li za každou cenu rychlejší přístup k datům, můžu si dnes sehnat rychlejší SSD, větší počet těch SSD nebo něco takového.
Filesystém, který ve výkonnosti natrhl prdel všem ostatním, byl bezesporu Reiser 4. No, vlastně ještě je... Používal jsem ho dlouho, ale pak začaly podivné bugy, kvůli kterým jsem jednou přišel o data. Navíc neustál zaplnění oddílu ani další trochu méně obvyklé situace. Pro mě osobně znamenal důležitou zkušenost, že nejlepší výkon zkrátka není všechno.
Tiskni
Sdílej:
1.9.2013 09:49