Dotaz: Chcem nejake distro s GNOME,

[lukve]

Hladam nejake distro ktore ma GNOME ako default

ano viem Fedora Workstation 33 je ako stvorená ale nemam rad instalator anakondu ci ako sa to teraz uz vola taktiez by som radsej nieco LTS a nehodlam pouzivat BTRFS isty cas som pouzival LVM ale to nema nic docienia s ZFS-BTRFS

Ubuntu voci nemu nemam vyhrady to je zatial number1 a ma aj najnovsie GNOME ak nenajdem distro s cistym vanilkovym gnome tak skoncim u Ubuntu a to mi nevadi kedze som istu dobu pouzival Lubuntu.

Debian sksual mozno by niekto povedal satre Gnome nevies co chces ale debian ma aspon stabilne balicky a APT je neocenitelny.

OS.GNOME.ORG najnovsie ale je to len pre testovacie ucely

Endless OS nie to sa na gnome uz nepodoba

PureOS 9 fajn debian ale nepodporuju v zaklade EFI boot

Mageia je to fajn distro maju aktualny kernel a Mageia 8 bude asi najlepsi release vobec ale nemam rad ich design

Tails - debian s gnome classic panelom ale nechcem nic dark

ostava mi skusit openSUSE Leap ale tu neviem co cakat ale vraj je to fajn distribucia tak skusim inac ostane Ubuntu

skusil som aj Manjaro GNOME minimal a to sa mi tiez pozdava ale vraj je to rolling release

 

skludom tuna pod diskusiu napiste postnite ak pouzivate distro s GNOME ake odporucite

 

 

 

co sa tyka HW co mam

moj PC J1900, ale mozem vymenit dosku s Pentiom nejaky Haswell co mi lezi v sufliku ale to staci 8G pamet a Intel HD grafika

---

---

Odpovědi

[Love_Dali]

Co takhle čistej Arch a na to Gnome?

[Pavel 'TIGER' Růžička]

No před chvilkou jsem si zkusil Artix s Gnome a také to velmi slušně jede. Ale z tazatelovi otázky mám spíš pocit, že potřebuje LFS. Protože nemá ujasněné, co vlastně chce.

[lukve]

Pre všetkých ktorý ako ja hladali distro s GNOME mozem odporucit MANJARO s GNOME verzie su az dve klasicka a minimal je to fakt dobra distribucia ako instalator Calamares ktory je fajn ak si date nove rozdelenie disku automaticky mate na vyber ako sa ma vytvorit swap, instalator hodnotim lepsi nez ten co ma ubuntu, system je rychly a moznost nastavenia rozlozenia gnome je tiez fajne featura.

neda mi ale prave testujem na druhom pc KDE NEON je to tiez fajn distro a tiez ma instalator Calamares vyzera ze som nasiel co som hladal.

odporucam Manjaro maju aj XFCE aj KDE ediciu a tiez nove KDE je uz v Neone User edicii

[PetebLazar]

Mám pocit, že POP!_OS od System76 založený na Ubuntu má GNOME jako default. https://pop.system76.com

[Pepan]

ale se zapnutým secure bootem nefunguje a ani mi nejde nainstalovat

[Petr]

To je to distro se zprznenym dedignem a ikonama, nebo si to pletu?

[lukve]

a default sifrovanim nemusim moc dost vytazuje disk

[Peter Golis]

Čo má prúdová šifra spoločného s I/O disku, ak sa smiem opýtať?

Pochopil by som keby to vyťažovalo CPU, ale CPU bez kryptoakcelerátora je v poslednej desaťročnici dosť málo. Teda ak sa človek netrápi na nejakom prastarom Atome.

[David Ježek]

Co ti vadí na designu Mageiy? Ptám se proto, že Mageiu s GNOME používám a nějak s designem Mageiy nepřicházím vůbec do styku.

[Honza]

ano viem Fedora Workstation 33 je ako stvorená ale nemam rad instalator anakondu ci ako sa to teraz uz vola taktiez by som radsej nieco LTS a nehodlam pouzivat BTRFS isty cas som pouzival LVM ale to nema nic docienia s ZFS-BTRFS

Instalator snad clovek pouzije jednou a pak ho uz nevidi a BTRFS nikdo nikomu nenuti a nic ti nebrani pouzivat ext4. Je fakt, ze to neni LTS, ale upgrady jsou nadherne seamless... :)

[pushkin]

Debian sksual mozno by niekto povedal satre Gnome nevies co chces ale debian ma aspon stabilne balicky a APT je neocenitelny.

Ja by som doporučil ten Debian. EFI? Má. LTS? Má. Gnome? Má.

[lkocman]

Ahoj, určitě zkus openSUSE Leap a možná bych se nebál ani Tumbleweedu. Záleží jak často máš rád změny.

Luboš

[lukve]

Lubos: no uz mam stiahnuty ISO Leap 15.2 idem skusit ale mam ASRock tak dufam ze UEFI boot to prekusne.

[vencour]

Kdybys nebyl měkkej, tak už máš půlku gentoo zkompilovanou.
A jaký by sis to udělal, takový bys to měl, gentoo je držák.

[jen tak]

Ano, drzi se dlouho na starych verzich nektere vubec nebyly do stable zarazene.

[Andrej]

Tvůj dotaz obsahuje hned několik populárních a rozšířených pověr, ať už přímo nebo jaksi v náznaku. Pojďme to vzít popořadě:

Hladam nejake distro ktore ma GNOME ako default

Svobodný desktop, zásada číslo 1: Grafické prostředí se nijak nepojí s distribucí. Do každé distribuce (s rozumným výběrem balíčků) si může uživatel nainstalovat jakákoliv grafická prostředí, třeba dvě nebo deset, podle vlastního uvážení.

Pokud má nějaká distribuce své „implicitní“ grafické prostředí, na kterém podivně a tvrdošíjně trvá (v instalátoru a podobně), je to spíš důvod držet se od takové distribuce dál než jakási výhoda (nebo kritérium pro výběr). Distribuce, kde funguje co nejvíc různého softwaru, desktopového i jiného, a kde neexistuje a priori závislost na jednom typu grafického prostředí, jsou obvykle z dlouhodobého hlediska příjemnější volba, snazší z pohledu správy a údržby atd.

…a nehodlam pouzivat BTRFS…

Takže hodláš ztrácet data. Výborně. S úsměvem se dívám na strop a vzpomínám si na výrok ze starého béčkového českého seriálu: Kdyby blbost nadnášela… A připomínám, že máme rok 2021, nikoliv 2011 (kdy by výrok typu nehodlám používat Btrfs mohl být ještě odůvodnitelný).

…ale vraj je to rolling release

Rolling release je nutnost, nezbytnost a ohromná výhoda vůči béčkovým distribucím bez rolling release.

(Proto nechápu, proč to zmiňuješ za „ale“, jako by to bylo špatně nebo co. (To je zhruba jako říct vybíral jsem auto, ale bohužel mělo vyšší výkon, nižší spotřebu a navíc klimatizaci.))

Release se má týkat jednotlivých balíčků, pokud možno (a až na nutné výjimky) bez vzájemných závislostí, ne celé distribuce. Release distribucí měl smysl v době, kdy se distribuce opravdu distribuovaly poštou na disketách a později na CD. V dobách internetu nemá absolutně žádný smysl a je to jenom komplikace.

Kdekoliv existuje release celé distribuce, musí uživatel volit mezi bolestivou a rozbíjející aktualizací celé distribuce nebo zastaralým systémem. Jenže většinou „dostane“ obojí. Rolling release žádný takový problém nemá. Několik mých strojů s Archem existuje a funguje už přes 10 let. Jsou pořád aktuální a bez jediné reinstalace.

[k3dAR]

kdyz ma nejake distro sve preferovane prostredi, tak je pravidlo/sance, ze se vice tomu prostredi venuje nad ramec pouheho sestaveni mainline zdrojaku, pro nekoho to je vyhoda, pro nekoho ne, ale je to tak a zalezi na kazdem jak to ma, ne na Tobe

rolling release je nutnost pouze pro toho, kdo:
1. chce vsechno "okamzite" nejnovejsi verze
2. nevadi mu ze pri aktualizaci musi/je_vhodne cist poznamky v aktualizaci kazdeho balicku, obcas resit nejaky problem, ci cekat par hodin az par dni az se aktualizujou i souvisejici balicku aby "se" "to" opravilo "samo"...

oproti tomu verzovane vydani je nutnost pro toho, kdo:
1. NEpotrebuje vsechno nejnovejsi verze, pripadne specificke programy ktere chce v last verzi so poresi 3rd repositarem
2. 2-5let NEchce kazdej den pri aktualizaci se modlit zda vsechno pak pojede, a nevadi mu kdyz to udela jednou za X let pri povysene verze distra, protoze to si muze naplanovat na obdobi kdy nebude vadit ze pocitac nebude pouzitelnej par hodin az par dni...

opet tedy je na kazdem aby zvazil co jemu vyhovuje a ne na Tobe co urcis ze je nutnost

u BTRFS to beru, tam sice kazdej take muze zvazit ze BTRFS nechce, ale chapu ze tve doporuceni nutnosti BTRFS ma opodstatneni, presto ale BTRFS zatim nepouzivam a o data sem prisel jen 2x, kdyz sem zkousel v minulosti BTRFS [tim nechci rict nic jineho nez vlastni zkusenost]

[Jirka Heřmánek]

bod 1 je nepravdivý! Stačí se podívat do AURu a spousta software je mnohem a mnohem starší. Naprosto nesrovnatelné s Ubuntu PPA! Proto přecházím z5 na Ubuntu.

[LarryL]

Stačí se podívat do AURu a spousta software je mnohem a mnohem starší.

Tak to by mě zajímalo jaké balíčky to jsou, protože balíček AURu si (před kompilací na localu) stahuje zdrojáky (většinou přímo z githubu tvůrce) a pokud jsi narazil na nějaký neudržovaný AUR balíček, tak stačilo v PKGBUILDu změnit cestu k nejaktuálnějším zdrojákům.

Jedině snad, že by to byl nějaký AUR balíček se spoustou závislostí a na úpravu PKGBUILDu jsi si netroufal.

[Jirka Heřmánek]

je toho opravdu dlouhý seznam. Např. Wine v ppa je verze 6.2 v AURu je 6.0. Cqrlog je ve verzi 2.5.2 v ppa a v AUR je prastará verze 2.4.0-1 atd atd

[LarryL]

Wine v ppa je verze 6.2 v AURu je 6.0

Ty se možná díváš na AURu na Stable, který skutečně je 6.0. Vyšší verze jsou "development release".

Tak jestli tvůrce (Wine) poskytuje vlastní PPA, tak je jasné, že maintainer na AURu, který musí ručně upravid PKGBUILD bude vždy o pár hodin nebo nějaký ten den později. Verze Wine 6.2 vyšla před 4 dny. Pokud se na AURu bavíme o tomhle Wine, tak tam by opravdu měla stačit maličkost:

V PKGBUILDu změníš jen pkgver=6.1 na pkgver=6.2 a pkgrel=3 na pkgrel=1. PKGBUILD se ve výchozím stavu nabízí k editaci před instalací balíčku, takže easy.

Cqrlog je ve verzi 2.5.2 v ppa a v AUR je prastará verze 2.4.0-1

Díváš se na tento cqrlog-bin 2.4.0-1, ale je i tento cqrlog-source 2.5.2-1

atd atd

Přihoď další, zatím jsme nic zásadně neaktuálního nenašli.

[LarryL]

... navíc Wine je ve verzi 6.2 v oficiálním repu, takže není důvod to tahat z AUR.

[Jirka Heřmánek]

Díky za odpověď. Sypu si popel na hlavu, používám Manjaro a možnost sestavení Cqrlogu v2.5.2 se tam objevila dnes! Včera tam tato možnost nebyla. Co se týká Wine 6.2 tak v oficiálním repu Manjara dosud není a úpravu PKGBUILDu v Manjaru neumím, protože to má pořešené asi jinak

[LarryL]

Wine 6.2 tak v oficiálním repu Manjara dosud není

Mně to taky nabízí jen 6.1-1, zřejmě ještě nejsou zaktualizované mirrory, protože jestli dobře vidím, tak je to v oficiální repu Multilib (nikoliv Multilib-Testing), každopádně když půjdeš na ten odkaz a vpravo vybereš "Download From Mirror", tak se ti sháhne právě verze 6.2, kterou si jen nainstaluješ.

a úpravu PKGBUILDu v Manjaru neumím, protože to má pořešené asi jinak

V Manjaru je to ještě jednodušší, protože je to přímo součástí GUI Pamac. Pokud máš v nastavení Pamac povolený AUR, tak těsně před aktualizací AUR balíčku máš nahoře tlačítko "Upravit sestavovací soubory" což je právě ten PKGBUILD, případně nějaké další soubory můžeš editovat (např. patch).

[LarryL]

zřejmě ještě nejsou zaktualizované mirrory

Zapomněl jsem, že Manjaro nemá stejné repa jako Arch , takže na Manjaru bude 6.2 asi během pár dnů (teď si neuvědomuji jakou mají prodlevu oproti Archu), ale kdybys Wine 6.2 nutně potřeboval už dnes, tak to z toho odkazu můžeš klidně stáhnout.

[Jirka Heřmánek]

Moc děkuji. Stáhl jsem balíček 58MB a podezřele rychle se nainstaloval cca 2s Winecfg ukazuje verzi 6.2 tak je vše ok. Ten PKGBUILD určitě vyzkouším. Jsem spokojený a uvidím kdy se bude aktualizovat KDE Plasma na 5.21

[LarryL]

Všiml jsem si, že na Manjaru se objevila verze Wine 6.2 před pár dny (28.2.). Na Archu byla již 12.2. Na Archu je od 27.2. už další verze a to Wine 6.3.

Takže snad to cca 2 týdenní zpoždění oproti Archu přináší Manjaru větší stabilitu v podobě vychytaných bugů (kdyby se nějaké na Archu objevily).

[Petr Fiedler]

Jak tak čtu tvoje komenty o RR, tak dospívám k názoru, že je to otřesná věc.

[k3dAR]

otresna urcite ne, RR resp. Arch/AUR je v podstate naprosto genialni, mas 1 par radkovej PKGBUILD, na zaklade ktereho se sestavi pri instalaci balicek automaticky (resp. pta se treba nad jakou knihovnou si to prejes sestavit pokud je vice moznosti), zdrojaky se tahaji primo od tvurce programu, mas to aktualni a vanilkove.... ALE neni to jak sem psal pro kazdeho, at uz tim ze to vyzaduje nejake znalosti, cas a trpelivost, tak tim ze se to proste meni nekdy moc rychle, komu to nevadi tak z Arch jen tezi, komu do vadi/nesedi tak nepouziva RR, ja bych treba nememl technicke problemy s Archem, ale nepotrebuju ho a naopak ocenim ze kdyz potrebuju pracovat nemusim nic se systemem/aktualizacema resit, takze Xubuntu ze

[Love_Dali]

Kolik těch AUR věcí potřebuješ? U mě to to výjimečně, protože většina je klasicky v repositářích a nebo se tam dřív nebo pozdějc dostane :)

[Petr Fiedler]

Jak se říká: "Když to znáš, tak je to brnkačka". Jenže když to neznáš/neumíš, tak je to pro tebe na používání otřesné. Kdysi jsem o RR uvažoval, ale když mě na fóru Mintu jedna uživatelka obeznámila s tím, co to obnáší, tak jsem to zavrhnul. Pro LarryLa, Andreje atp to může být super, protože umí, ale pro mě by to bylo utrpení a z 20 altuálních dotazů v poradně by bylo 17 mých.

[LarryL]

Proč myslíš? AUR je skvělý a co se týká těch aktualizací, které přichází cca každých 14 dnů, tak věnovat tomu v průměru 10 min není zas taková katastrofa. Jestli můj komentář vytvořil dojem, že je pořád něco pokažené, tak tak to není. Jenom si myslím, že údržba RR se v součtu časů delší než velká aktualizace na pár hodin u non-R.

Samotné aktualizace na Archu/Manjaru jsou rychlé. Během stahování i provádění aktualizací normálně pracuješ a když rebotuješ, tak systém hned nabootuje (neobjeví se žádná hláška "čekejte na provedení aktualizací").

[Petr Fiedler]

No, přišlo mi, že se o to musíš dost starat. A že musíš spoustu věcí sledovat a podle toho pak něco editovat. Oproti apt update && apt full-upgrade je to docela dost práce a hlavně, jak už jsem to napsal výše Radkovi, vyžaduje to vědomosti, které já nemám. Pokud je někdo má, je to pro něj hračka. Ale pro mě by to opravdu bylo otřesné, byť funkčně je to zřejmě super.

Velká aktualizace není otázkou hodin, ale tak 20 minut např. z Mint 19 na Mint 19.1, Mint 19.2, nebo Mint 19.3 a tak 40 minut, když upgraduješ z Mint 19.3 na Mint 20. Plus jak psal dole Radek, tak je ještě potřeba vrátit ručně PPA, což zabere tak 5 minut. Pokud by sis ale před upgradem chtěl udělat třeba LVM snapshot, nebo zálohu Clonezillou, tak o něco více.

Jinak osobně už si dlouho chci zkusit instalaci Archu a trochu si jej prohlédnout a vyzkoušet. Pořád na to ale není čas. Zrovna se zabývám Btrfs a pak mám v plánu ještě spoustu věcí. Ale snad se na to tento rok dostane.

[LarryL]

vyžaduje to vědomosti, které já nemám.

Pokud ve vedlejším vlákně řešíš Sicherboot, dokážeš zprovoznit VM, umíš přidat kernel parametr do GRUBu a umíš alespoň s pomocí google překladače si přeložit archwiki, tak si myslím, že bys Manjaro v pohodě zvládl. U čistého Archu by ses asi jen zdržel při instalaci, kde musíš spoustu věcí zadat a není to na pár kliků.

něco editovat

Zrovna před chvíli mi to při upgradu napsalo, že nějaké 4 konfiguráky libvirtu se nainstalovaly s příponou .pacnew a měl jsem možnost si porovnat starý a nový configurák a kdybych měl ve starém nějaké své úpravy, tak bych je přenesl do nového. Tohle je i u Debianu a možná se to píše i tobě na Mintu do nějakého logu a jen to ignoruješ.

[Petr Fiedler]

Já si chci zkusit tu instalaci Archu kvůli tomu, že se toho na ní dá dost pochopit a dost naučit. Podle ArchWiki bych to zvládnout měl.

Zrovna včera jsem si nainstaloval na sekundární disk Mint nad Btrfs, abych si zkusil quotas, subvolumes a jak se OS na Btrfs vlastně chová. Teď jsi mě docela nadchnul pro to ten disk přeformátovat (Btrfs) a dát na něj ten Arch. Uvidíme. Je toho fakt moc. Ještě jsem ani nezkusil ten passthrough té iGPU na nb, protože jsem zase řešil novou pc sestavu a ten Sicherboot a furt je prostě něco. Každopádně díky za povzbuzení.

[LarryL]

Já si chci zkusit tu instalaci Archu kvůli tomu, že se toho na ní dá dost pochopit a dost naučit.

+1. Přesně kvůli tomu bych Arch (Manjaro) a Archwiki doporučil začátečníkům Linuxu, kteří nechtějí jen klikat, ale chtějí nenásilnou formou pochopit jak Linux funguje.

[Petr Fiedler]

No to je z Radkové hlavy. Kdysi se tu někdo na něco ptal, už nevím na co a Radek mu poradil, jestli chce GNU/Linuxu porozumnět, ať si projde instalací Archu. Tenkrát mě to zaujalo a řekl jsem si, že si jí projdu taky. Akorát mi to sešlo z mysli a ještě jsem to nezrealizoval. Jak odešlu tento koment, rovnou jdu na stránku Archu. :)

[Pavel 'TIGER' Růžička]

Každý linuxák by si jednou měl vyzkoušet a zprovoznit LFS, pak pro něj budou ostatní distribuce procházkou růžovou zahradou.

[Love_Dali]

:) Kde jsou ty časy, kdy jsem stavěl Gentoo ze stage1 na P2, 233MHz a 96MB RAM :)

[LarryL]

LFS

Jestli to už není učení se násilnou formou.

[xhombre]

Ahoj, Arch můžu doporučit. Pár let jsem na něm jel. Nikdy větší problém a to jsem se k němu choval dost macešsky. Takže ke konci aktualizace i po pár měsících, ale to jsem měl spíš štěstí, že se mezi tím nezměnilo nic zásadního, jako třeba přechod na systemd.

AUR je skvělý, úpravy PKGBUILDů triviální.

Instalace tedy, v porovnání s jinými distry, nic moc. Ale podle tvých komentářů v poradně bych řekl, že to v pohodě dáš.

[Petr Fiedler]

Už se na tom pracuje. Díky za povzbuzení. :)

[LarryL]

Rolling release je nutnost,...

Nesouhlasím, a to říkám jako člověk, který využívá také Rolling release (Manjaro) mnoho let a taky se mi při aktualizaci nikdy nerozbilo (až na jednu vyjímku což jen vyřešilo dojetí aktualizace přes textovou konzoli (tty2)), ale...

Nevýhoda Rolling release je, že se příliš mění pod rukama. (Než jsem to stihl sepsat, tak už něco podobného napsal Kedar.) U dister co nejsou rolling dojde k zásadní změně jen při přechodu na vyšší verzi. Moje příklady ze života po aktualizacích rolling release:

• Po aktualizaci (cca měsíc) zpátky mi začalo problikávat xfce při probuzení monitoru ze spánku, stačí Ctrl-Alt-D a vše je OK, takže nepátrám po řešení (třeba se to po dalších aktualizacích opraví).

• Spice s Virgl mělo artefakty v obraze. Bylo nutné při spuštění Spice říct Mesa, aby místo výchozího iHD používala i965. (Tento problém měl i uživatel Ubuntu 20.04, virt-manager: 2.2.1, takže tohle možná nebyl jen problém rolling release.)

• Při pauznutí VM ve virt-manageru mi VM vytuhla. Kedarovi, který měl Xubuntu 18.04.3 to fungovalo správně.

• Manjaro v prosinci zahodilo starší verze Nvidia, ale jelikož potřebuji Bumblebee (ten byl jen u staré verze Nvidia-390) a nový ovladač byl jen s Prime, tak jsem tomu musel věnovat čas.

• Občas se při aktualizaci ztratí nastavení lokace počasí (addon na xfce panelu) a musel jsem to nastavit znovu.

Možná bych si vzpomněl na další. Nic z toho není nic fatálního, ale problém je v tom, že tomu musíš věnovat čas, který je podle mě delší než u distra bez rolling. Jelikož už nepotřebuji nejnovější balíčky jako dřív, tak chci od Rolling release odejít.

Rolling release má obrovskou výhodu pro tvůrce distra, protože nepotřebují armádu programátorů na backportování.

[PetebLazar]

Mají rolling release distra interně implementováno něco jako "bod obnovy", tj. schopnost vrátit se se stavem instalace/aktualizace OS (bez uživatelských souborů) zpět do uživatelem definovaného času?

[LarryL]

Lze obnovit všechny balíčky k danému datu, ale nikdy jsem to nepoužil. Stejně musíš případný problém vyřešit, abys mohl rolovat dál. Zastavit aktualizace a provést je jen jednou za delší dobu se prý moc nedoporučuje.

Nejlepší postup co se mi osvědčil je se před aktualizací podívat na fórum kde je vidět graf kolik lidí mělo problém a taky jsou tam celkem přehledně popsány problémy a jejich řešení (bývá jich tam třeba pět), takže ještě před spuštěním aktualizace člověk ví do čeho jde. Nic komplikovaného, třeba že v Gnome je něco nového a může vyskočit nějaká chybová hláška a že je potřeba změnit nějaký konfigurák. Když Gnome nepoužívám, tak to řešit nemusím.

[PetebLazar]

Dík za objasnění. Tak to asi R-R není nic pro mne. Já se nemohu dokopat ani k přechodu z Xubuntu 18.04 na 20.04. Možná s novým HW.

[lukve]

U mňa je to tiež podobne dlhú dobu som používal lubuntu potom som pochopil ze features nemusia byť na škodu a ze gnome, mate xfce majú aj ekosystém svojich apiek tak prečo nie rovno to najlepšie akým gnome je ale nesedia mi distra kebyže som sa uspokojil s malom a bol trosku minimalista sklidom mi postačí aj xubuntu.

[lukve]

Počítač je skôr u mňa na internetovanie. A raz za čas robím nejakú webku hodí sa aj prístup cez smb k nasku takže poteší pokrocily správca súborov. Preto gnome

[k3dAR]

tak Thunar v Xfce/Xubuntu samozrejme umi SMB take a napr:
- v okne mit ruzne adreare otevrene jako listy
- ma vlastni akce do contextoveho menu prave mysi podle druhu souboru nad kterym kliknes
- v 4.17 verzi je rozdeleni okna na 2 (leva/prava) casti
- podporu roz/za-baleni archivu
- hromadne prejmenovani souboru (vcetne moznosti mp3 prejmenovat dle tagu)
- editor ID3 pro Audio/Video
atd... coz mi pripada mnohem vice pokrocilejch moznosti nez omezne-nepokrocile moznosti Nautilusu v Gnome
(samozrejme ze Dolphin v KDE ma moznosti vice, ale o tom si nepsal...)

je pravda ze Xubuntu je pro minimalisty, protoze maximalisti chteji Gnome s maximalnima mezerama mezi/nad/vedle prvkama aby se toho na obrazovku veslo co nejmene jako nic proti Gnome, ac ho nepouzivam sem rad ze existuje a uzivatele kteri chteli desktop s UI/UX ala tablet maji po cem sahnout, ale Xubuntu mi toho nabizi mnohem vice nez Gnome a prehledneji/pohodlneji/rychleji

[Pavel 'TIGER' Růžička]

Nejpokročilejší správce souborů je příkazová řádka, pak nějaký cli manažer, což je v linuxu mc a nakonec jsou gui nástroje. Na linuxu je kouzelné to, že si ho můžeš sestavit podle svých představ. Můj desktop je založený na openboxu, lišta je z xfce, souborový manažer caja, webový prohlížeč Vivaldi atd, atd. Zkrátka používám jen to, co ptřebuji a ne to, co mi předhodí nějaké desktopové sestavení. Ale chápu, že každý to máme jinak.

[k3dAR]

mam to "podobne", sice ciste Xfce(kde mi ty predhozene casti vyhovujou), ale primarne pouzivam byobu + mc a Vivaldi

[lertimir]

Ono je to právě dvousečné. chápu tvoji nechut k přechodu z 18.04 na 20.04. Už asi cca 15 let používám openSUSE a posledních 5 let na Arch na stanici a noteboocích a openSUSE zůstalo na serverech a na stanicích manželky popř kamarádů a tak zkusím popsat můj pohled na rozdíly.

OpenSUSE

• + V průběhu života releasu nemusíš v zásadě nic řešit. Objem aktualizací není moc velký. V současnosti i s dosti velkou úrovní bezpečnosti (malou mírou rizika) si můžeš dovolit pustit automatické aktualizace.
• - Bezpečná aktualizace mezi releasy je činnost spíše na hodiny. Primárně distra (alespon opensuse velmi nedoporučuje) nepodporují online aktualizaci, pokud jsou připojeny jiné repozitáře než vlastní repozitář(e) distribuce. Navíc v komunitních distribucích je i ten další soft rozdělen podle releasů a mnohdy používaný soft nemusí být aktualizován pro nový release. V těch komunitních programech není jasné(a spíš myslím že není kvalitní) backportování chyb do starších verzí. V každém případě po aktualizaci je release jen s tím, co je v hlavních repozitářích a nové z komunity je třeba znovu nainstalovat a pohlídat si, aby zůstaly konfiguráky pro ty programy popř aby je správně změnil.

Arch

• + Software je aktuální. Není třeba řešit kompatibilitu a dostupnost konkrétních balíčků pro konkrétní release.
• - Větší objem downloadu a větší počet rebootů. Pro mé instalace Arch vytváří tak cca 600MB aktualizací týdně a mezi jednotlivými verzemi jádra vydávanými Linusem je tak 10-15 minor releasů (ted mám jádro 5.10.16-arch1-1). Přiznám se, že aktualizační informace na stránce Archu čtu občas a za těch 5 let s tím, že nějaká aktualizace probíhá v podstatě každodenně jsem se jen dvakrát dostal do problému. Jednou do situace, kdy po aktualizaci systém nenajel. Musel jsem se s jiného notebooku podívat na stránku archu, kde bylo upozornění na požadovanou ruční akci na konfiguracích a po bootu a opravě z live distra bylo vše ok. Podruhé byla také informace o ruční požadované změně v konfigurací sítě a také se stačilo notebookem připojit na síť a přečíst si informaci na stránce Archu
• Celkově je můj zcela subjektivní pohled: Arch proti opensuse tak -20 hodin (možní i více) čistého času na administraci aktualizací. Pokud je to systém, který máš denně pod prsty, vypínáš ho, rebootuješ, Arch je zcela bez problémů. Pokud je to systém, který má běžet (primárně jako server), nemám se o něj starat a připojím se k němu jednou za 14 dní tak verzované distro.

[k3dAR]

s Xubuntu povyseni z 18.04 na 20.04 na nekolika strojich(T430s,X230,STX+i3gen7):
+ povyseni je na cca 1h
+ bez PPA (coz neni muj pripad) se nemusi nic dale resit...
- zakaze PPA, po povyseni rucne pridat znovu (at uz add-apt-repository, nebo odkomentovani intalatorem zakomentovanejch radku)
- balicky z PPA se nemusi vzdy zaktualizovat z noveho PPA pokud maji "stejne" verze, takze "dpkg -l | grep -e bionic -e 18.04" a pripadne je rucne preinstalovat
(nabizenou moznost nezakazovat PPA (resp. 3rd repo) sem nezkousel, i takto za 1.5h bylo hotovo a aspon sem probral PPA :)

[Petr]

A snapper tam neni funkcni?

[LarryL]

Peteb se ptal na vrácení zpět bez změny uživatelských souborů, což jsem pochopil jako hromadný downgrade balíčků. Snapper ti IMHO vrátí zpět všechny soubory (co jsou v daném snapshotu).

[lertimir]

openSUSE právě toto má velmi kvalitně pořešené. btrfs snapshoty vrací zpět systém, ne logy, ne obsah serverů, ne uživatelská data. viz

[LarryL]

Asi by to šlo nastavit i na Archu, ale kdo nemá Btrfs nebo LVM, tak mu Snapper stejně nepomůže.

[lertimir]

No nastavit to jistě jde, ale openSUSE má i kvalitní integraci do grubu a v grubu se můžeš rozhodnout jestli chceš bootnout předchozí snapshot a u něj se rozhodnout jestli chceš ten boot jen aktuální, tedy jen boot a nebo rollback, kdy se se systémtrvale vrátí a můžeš od tohoto místa pokračovat. Provést takovou integraci samozřejmě také jde ale dá to mnohem více práce. V suse jsou to jen výběry v grub menu.

[LarryL]

má i kvalitní integraci do grubu a v grubu se můžeš rozhodnout jestli chceš bootnout předchozí snapshot a u něj se rozhodnout jestli chceš ten boot jen aktuální, tedy jen boot a nebo rollback

Co vím, tak to z openSUSE převzala i poslední Fedora. Taky používá Snapper + svůj DNF snapper Plugin. Když si otevřeš odkaz tak je tam velké varování ohledně snapshotů DB. Předpokládám, že možná nekonzistence dat u DB hrozí i u openSUSE.

PS: Možná ani na Archu by to nebyl takový problém zaintegrovat to do GRUBu, taky na to je plugin:

snap-pac-grub — Additionally updates GRUB entries for grub-btrfs after snap-pac made the snapshots. Also uses pacman hooks.

https://github.com/maximbaz/snap-pac-grub || snap-pac-grub(AUR)

[Leinad]

Nehrozí, protože openSUSE má subvolumes rozdělené tak, že datové jsou bez cow a aplikační s cow. Na Fedoře je vše s cow. Takže rollback to tam fakt může rozbít

[LarryL]

datové jsou bez cow

Přemýšlím jestli je to dobře nebo špatně. Pochopil bych vypnutí COW pro adresář s DB nebo VM, ale vypnutím COW pro celé datové subvolumes se IMHO připravím o jednu z velkých výhod Btrfs.

Ještě je tam napsáno:

Moreover, some system files must never be restored.

To by mě taky celkem zajímalo, které systémové soubory jsou tím myšleny. Předpokládám, že se to týká Fedory i openSUSE.

[lertimir]

na cow nezáleží. musí to být správně rozsekané do subvolumes a snapshoty jedou jen na root subvolume

[LarryL]

Ano, tak to bude. U výchozího nastavení Snapperu se píše:

Taking snapshots on partitions other than / is not enabled by default.

[LarryL]

Ještě jak se dívám na adresáře vyloučené ze snapshotů, tak volbu "no copy on write" mají nastaveny jen:

- /var/lib/libvirt/images

- /var/lib/mariadb, /var/lib/mysql, /var/lib/pgqsl

což mi připadá rozumné.

[Love_Dali]

osobně jsem časovej rollback použil na Archu jednou a to když mi vyhnil systemd. Nahodil Arch ISO, chrootnul, rollbacknul. Počkal dva dny a hotovo. Update šel. Osobně nevidím naprosto žádný důvod používat non-rolling distra. Ostatně nevidím jedinej důvod, proč se hrabat v debian/redhat/suse based krámech i tak :)

[LarryL]

Jedno se musí Archu nechat a to je nejlepší dokumentace Linuxu. Pak je chvilku nic a následuje dokumentace Genta, pak je hodně dlouho nic a pak jsou dokumentace všech ostatních dister. Ostatně dokumentace Archu byl hlavní důvod proč jsem začal používat Manjaro (nechtělo se mi zdržovat s instalací čistého Archu). To jestli je to [non]rolling release pro mě zas tak důležité nebylo.

[Vojta]

Nejdriv Genta pak dlouho nic pak Arh prevalcoval Genta a za chvili Genta prevalcuje Arh protoze tam kde byl Genta pred pred renovaci tam je ted Arh, to znamena hromada dokumentace mnohdy uz zastarala a cimdal vic neprehledna.

[GeorgeWH]

Hmm

... a to když mi vyhnil systemd... Počkal dva dny a hotovo.

Osobně nevidím naprosto žádný důvod používat non-rolling distra.

[Love_Dali]

furt lepší než si nechat rozmrdat system každej dist update a nebo každým přidáním PPA. Navíc, bavíme se o horizontu XY let, co jedu na Archu.

[k3dAR]

"dist update" neexistuje, asi si myslel "dist upgrade" coz je pouha aktualizace balicku s moznosti pridat/odebrat nove zavislosti/balicky... a to a ani pridani PPA nic nerozmrda, pokud nejses levej nebo blbej (aneb vzdy to chce premyslet a to samozrejme i s balickama z AUR) btw: trocha tolerance a slusnosti jeste nikoho nezabilo

[Petr Fiedler]

Jako mírně pokročilý ti můžu říct, že máš zkreslený pohled na dist-upgrade. Za těch pár let, co používám Mint jsem nic takového, o čem píšeš, nezaznamenal.

[xhombre]

Tohle by mohli v pohodě řešit snapshoty, např. použitím BTRFS apod.

[Andrej]

To přece není záležitost distra. Co s tím má distro společného? Už deset let je tohle samozřejmost. Klíčové slovo: Btrfs.

[LarryL]

Pokud mluvíš o snapshotu na BTRFS, tak si nemyslím, že snapshotovat je vždy lepší než obnovit rolling release k určitému datu. Snapshot ti "uloží" stav disku k určitému okamžiku, ale už nijak neuloží RAM. Obnovení ze snapshotu je stejné jako kdybys zapnul PC po výpadku proudu. Může se stát, že když nějaká aplikace zapisuje dvě nezávislé operace na disk, tak 1. operace se zapíše těsně před vytvářením snapshotu (a tudíž bude součástí snapshotu) a 2. operace se zapíše až po vytvoření snapshotu (a nebude součástí daného snapshotu). Když pak obnovíš do daného snapshotu, tak záleží jak se aplikace popere s tím, že nenajde uloženou 2. operaci.

[Andrej]

Tak zásadní a kompletní nepochopení toho, co znamenají snapshoty na úrovni filesystému, jsem ještě opravdu (ale opravdu (ale opravdu)) neviděl. Gratuluji.

Aplikace ať se popere s tím, co si vyžádala, jestli si mezi dvěma operacemi vyžádala sync atd. Filesystém se svými snapshoty bude konzistentní, podle své definice, kterou aplikace může / nemusí správně využít ve svůj prospěch.

[LarryL]

V pohodě, stačí když moje nepochopení vyvrátíš argumenty. Zatím jsi mi nic nevyvrátil. Nepsal jsem nic o tom, že obnovení snapshotu znamená nekonzistenci filesystému. Psal jsem o nekonzistenci pro určitou aplikaci. Konkrétním příkladem (aplikace) kde snapshotování může být problém je snapshotování databází. Varování z DNF snapper Pluginu používaného na Fedoře a OpenSuse k vytváření BTRFS snapshotů:

Warning

There is no mechanism to ensure data consistency during creating a snapshot. Files which are written at the same time as snapshot is created (eg. database files) can be corrupted or partially written in snapshot. Restoring such files will cause problems. Moreover, some system files must never be restored. Recommended is to only restore files that belong to the action you want to revert.

[jen tak]

Takže hodláš ztrácet data. Výborně.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f1ee3b8829006b3fda999f00f0059aa327e3f3d0

Ty zmeny se delaji diky tomu ze vsechno funguje.

[k3dAR]

jj, sem si rikal kdyz na rootu cetl zpravicku o 5.11, ze pokud btrfs bude rychlejsi o desitky procent, tak bud ted bylo pomale jak prase, nebo naopak ted bude prekonavat fyzikalni zakony

[lertimir]

Nerej. Mnohdy nejvýkonnější FS je FAT. S přidáváním vlastnosti se vždy musí něco zpomalit. Třeba jak bývalo XFS pomalé při operaci mazání množství malých souborů (mnohdy v benchi i 5-10 pomalejší než EXT3). A pak postupně při zachování vlastností lidi napadne, jak operace optimalizovat. A jestli jsi předtím třeba psal 100MB/s a ted budeš 120MB/s tak je to zrychlení o desítky procent (a není že to bylo pomalé jako prase)

[Andrej]

Ext4 má každé 3 roky (2009, 2012, 2015, 2018) obrovskou aféru se ztrátami dat taky proto, že všechno funguje?

Ne. Bude to tím, že software se prostě vyvíjí a každý software má své mouchy — Ext4 navržený pro 20 let staré disky obzvlášť.

Byť to některým nedůvtipným lidem ani po 10+ letech nedošlo, Btrfs je zatím nejspolehlivější a nejpokročilejší souborový systém, jaký Linux podporuje. (Ano, ZFS je taky dobrá volba, ale CDDL dědictví ho ještě nepustilo ze spárů.)

Ale žádná křeč, i těm pomalejším to nakonec docvankne. Chce to jenom čas. Fedora má konečně (s 10-letým zpožděním, ale přece!) Btrfs jako implicitní filesystém a spousta dalších distribucí bude následovat.

A chyby všeho druhu se budou samozřejmě opravovat — to je jedině dobře.

[pavele]

Počítám, že za 10-15 let se btrfs doladí a bude se běžně používat.

To, že je v současné době btrfs nejspolehlivější a nejpokročilejší souborový systém, jaký Linux podporuje, je smutné. Škoda, že má problém na databázích a virtuálních strojích.

Za stejnou dobu se budou běžně používat ECC RAM.

[LarryL]

Škoda, že má problém na databázích a virtuálních strojích.

To je jen problém COW, nikoliv problém BTRFS/ZFS. COW lze pro určité adresáře (s virtuálkou) vypnout. Nejen, že to lze, ale je to doporučováno, podobně jako je doporučována spousta jiných postupů při použití jiných FS.

[pavele]

To je právě škoda, protože přes COW by se perfektně zálohovaly virtuály i databáze. COW jsem považoval za jednu z najvětších přínosů tohoto fs. Takto musím volit jiné, podle mne zastaralé varianty záloh, přestože plně funkční.

[LarryL]

přes COW by se perfektně zálohovaly virtuály i databáze

Oj. Tak to si nemyslím. Řešili jsme to o pár komentů výše ("velké varování ohledně snapshotů DB"). O tom jak udělat konzistentní zálohu DB jsou na netu dlouhé návody a považuji do za vyšší dívčí.

[pavele]

Moje idea byla, že ukončím virtuál, udělám btrfs snapshot a jedu dál.

Můžu použít cp nebo staré rdiff-backup nebo lvm nebo idera hcp snapshot nebo virsh snapshot interní nebo externí, ale vše je to takové neohrabané.

Nejjednodušší a nejspolehlivější je obyčejné cp s hashem, ovšem trvá to. Btrfs by to krásně řešilo, kdyby to šlo.

Databáze se udělá SLAVE nebo MASTER-MASTER a ta se potom zálohuje, ovšem je to složitější.

Je fakt, že jsem za léta provozu virtuálu nebo hostitele nemusel použít zálohu systému - dat jo, občas uživatelé něco smázli.

[LarryL]

Moje idea byla, že ukončím virtuál, udělám btrfs snapshot a jedu dál. Můžu použít cp ...

No ale, ty to cp nebo cokoliv jiného co ti zálohuje VM stejně musíš udělat. Snapshot není záloha! Na Btrfs Wiki se píše:

Note that a snapshot is not a backup: Snapshots work by use of btrfs's copy-on-write behaviour. A snapshot and the original it was taken from initially share all of the same data blocks. If that data is damaged in some way (cosmic rays, bad disk sector, accident with dd to the disk), then the snapshot and the original will both be damaged. Snapshots are useful to have local online "copies" of the filesystem that can be referred back to, or to implement a form of deduplication, or to fix the state of a filesystem for making a full backup without anything changing underneath it. They do not in themselves make your data any safer.

[pavele]

To je opravdu dobrá poznámka, škoda, že tu není pěkné téma na zálohování a klonování současných linuxových OS.

[Peter Golis]

Ak sa jedná o jednoduché zálohovanie virtuálnej farmy, tak tu o niečom od Prozmoxu preletela pred štvrť rokom správička.

[LarryL]

Vypadá to, že Btrfs byl ve tých očích špatný jen proto, že jsi od něj měl přehnaná očekávání v podobě zázračného, rychlého a pohodlného způsobu zálohování. Asi se ocitneš v Andrejově seznamu FUDistů.

Pokud se bavíme o zálohování malého množství VM (typicky na desktopu), tak pokud děláš "cold" zálohu VM (vypnutá VM), což je tvůj případ, tak tam stačí zkopírovat virtuální disk (qcow2) a konfigurák VM (xml). U "hot" zálohy (běžící VM) už je to složitější (podobně jako u běžící DB). Potřebuješ pomocí snapshotu "zamrazit" virtuální disk k nějakému času a udělat jeho zálohu. Pak musíš ke stejnému času ještě zachytit stav RAM a taky uložit. Pokud má VM vyhrazenou GPU, tak musíš zálohovat i VRAM (v současné době neznám způsob jak by se VRAM zachytila a zálohovala). Pro zachycení takto komplexního stavu ti samozřejmě žádný filesystém nepomůže - to je zcela nad rámec toho co má filesystém dělat.

[LarryL]

...v tomto videu mluví o výhodě Btrfs send/receive pro zálohování VM.

K videu se vztahuje tento článek ve kterém je konkrétní návod pro send a receive (poslední odstavec "Efektivní zálohování mezi dvěma stroji").

[LarryL]

...zatím Btrfs nepoužívám (chystám se), ale někde jsem četl, že snapshot lze udělat i když má adresář (nebo subvolume) vypnutý COW.

[LarryL]

Taking snapshots of a BTRFS volume mounted with nodatacow?

[Petr Fiedler]

Přesně. Principiálně to tak dělám. Relativně často dělám snapshot VM a jednou za čas jej zálohuji včetně konfigurace a infa o snapshotech. Ta záloha mě za ten rok a něco, co virtualzuji už 2x zachránila.

[Andrej]

A Ext4 (nebo XFS) se doladí kdy, když je dnes naprosto nespolehlivý a nepoužitelný? To by mě fakt zajímalo. Jo, až bude mít Ext4 atomické checksumy metadat i dat, atomické snapshoty a redundanci (na jednom disku i přes víc disků), můžeme o tom dál diskutovat. Do té doby je lepší zvolit mnohem spolehlivější Btrfs.

ECC RAM se budou běžně používat tak nejpozději do 5 let, protože DDR5 budou mít (konečně!) ECC povinně jako součást specifikace.

[Andrej]

A na strojích bez ECC RAM je dvojnásob vhodné mít ZFS nebo Btrfs, aby se člověk o případném problému dozvěděl dřív, než sežere podstatnou část dat.

[jen tak]

Fedora má konečně (s 10-letým zpožděním, ale přece!) Btrfs jako implicitní filesystém a spousta dalších distribucí bude následovat.

Pred vydanim F33 kdy probihaly testovaci dny jsem ho sam rucne navolil v instalatoru F32 do mobilniho notebooku ktery moc nepouzivam, problemy s nim nemam. Vlastne ani nevim jestli je ve stejnem konfiguracnim stavu jako kdyz ho nasadili ve F33.

Reagoval jsem jen na to ze tam delali ted zmeny ohledne te neztraty dat. Takze asi uplne dospely a hodny doporuceni v takovem idealnim stavu minimalne nebyl.

[k3dAR]

Ext4 má každé 3 roky (2009, 2012, 2015, 2018) obrovskou aféru se ztrátami dat taky proto, že všechno funguje?

[...] Btrfs je zatím nejspolehlivější a nejpokročilejší souborový systém, jaký Linux podporuje[...]

psal sem ti to nahore:
BTRFS ma opodstatneni, presto ale BTRFS zatim nepouzivam a o data sem prisel jen 2x, kdyz sem zkousel v minulosti BTRFS [tim nechci rict nic jineho nez vlastni zkusenost]

[buran_vesnicky]

S BTRFS bych byl velice opatrný. Žiju na vesnici kde často vypadne proud asi díky zcela zdevastované lince 22kv. Asi před rokem jsem na starý SSD disk Samsung 250gb dal čisté Xubuntu a udělal image partition systému. Jednou s ext4 a podruhé s BTRFS. S ext4 jsem musel při úmyslném vypnutí PC opravit fs jenom při kopírování většího video souboru pomocí mc a při komprimaci. Asi 5 pokusů s ext4 a image jsem nevyužil. To samé s BTRFS dopadlo podstatně hůř. Z pěti pokusů jsem byl nucen 3x obnovit systém z image. Pro mě jednoduchý závěr nikdy více mi BTRFS na disk nesmí!

[jen tak]

S BTRFS bych byl velice opatrný. Žiju na vesnici kde často vypadne proud asi díky zcela zdevastované lince 22kv.

:D

O to nejde jestli prijdes o data timto, pokud delas zalohy. Jde ale o to jestli uz ta prvni zaloha je konzistentni v celem rozsahu a tu nekonzistenci nezavinil uz samotny FS. Tim nechci nic podsouvat nynejsimu stavu toho FS ale kdyz tam ctu ze ta kontrola dat neni presna, tak to moc duvery nevyvolava. Ale nic jsem nekde o pokazenych zalohach necetl, to je pravda.

[buran_vesnicky]

Tak na zalohy používat BTRFS mě ani nenapadlo. Jenom jsem si to pro sebe vyzkoušel Kdo má noťas tak to asi nemusí řešit

[jen tak]

To nevadi, hlavne ze umis cist

[Pavel 'TIGER' Růžička]

Nevím, jak je na tom BTRFS dnes, ale když jsem jej naposledy zkoušel, tak mi celkem vadilo, že nebylo moc nástrojů na jeho opravu, kdežto s ExtX umí pracovat kde co.

[LarryL]

Z pěti pokusů jsem byl nucen 3x obnovit systém z image

"buggy" hardware?

[Andrej]

Pro mě jednoduchý závěr nikdy více mi BTRFS na disk nesmí!

Jednoduchý (a hloupý a nesmyslný) závěr je skoro vždycky špatný. Ani tento případ není výjimka.

Kdo dává přednost Ext4, který nechává potichu mizet data, před Btrfs, který se při mizení dat aspoň ozve, ten většinou zkrátka nechápe, jak tenhle svět funguje, že je Země (skoro) kulatá a podobná základní fakta.

Pokud má nějaký systém nebo nějaké úložiště problém s poškozením dat, je potřeba vyřešit ten problém, nikoliv schovat ten problém za neschopný filesystém typu Ext4. Řešení může být složité, protože chyba může být v RAM (kde se těžko zjišťuje, pokud tam není ECC), v řadiči, v disku nebo SSD (zpravidla ve firmwaru) atd.

Nicméně nikdy, opravdu (ale opravdu) nikdy není řešením problém přehlížet a preferovat zastaralý souborový systém, který problém „úspěšně“ ignoruje.

[k3dAR]

povyseni sve demagogie s "nechape jak tenhle svet funguje" je proste PRILIZ i na alkoholka tveho kalibru
asi tezko si uvedomis ze TY zijes v bubline, kde ma kazdej 64jadrove CPU, 256GB RAM a 50TB SSD RAID10 pole... nejen z toho prameni i tvuj fanatismus... precti si jeste jednou co psal "Žiju na vesnici kde často vypadne proud", tedy je mu UKRADENE ze EXT4 teoreticky jednou za rok muze ztrait jeden bajt (obrazne), dulezite pro nej je prave ten jeho test PRAKTICKEHO problemu, ze mu casto vypadne proud...
samozrejme ze by mohl pouzivat BTRFS pri porizeni UPS s sw vypinanim pri vypadku proudu ci pri urcite kapacite UPS z ktereho by to jelo, ALE pokud nema ci nechce UPS, je pro nej EXT4 proste vhodnejsi nez BTRFS v jeho konkretnim pripade...

[ewew]

V tomto prípade vídim len možnosť sa pozrieť poriadne na štruktúru ext4 a btrfs a ich vlastnosti.

Už nám chýba len BTRFS kontrolér, ktorý by sa tváril ako jeden disk a vykoná val funkcie btrfs zo svojej strany.

[pavele]

Myslím si, že dotyčný z vesnice postupoval zcela empiricky a zvolil, co bylo podle jeho testů a zkušeností to nejlepší.

Osobně jsem takto testoval souborové filesystémy před cca 10 lety a dopadlo to stejně.

Zkoušel jsem rychlost spuštění a svižnost spouštění Firefoxu a odolnost fs při náhlém vypnutí PC - opakovaně, až mi odešel napájecí zdroj v PC.

[ewew]

Pull the plug !!!

[Petr Fiedler]

To by mě opravdu zajímalo, jak by to Btrfs ustál, kdyby to tak 5x udělal.

[Andrej]

Slaměný panák, pardon: Zatímco jak by to to Ext4 béčko neustálo, to tě kupodivu vůbec nezajímá. Klasika.

Btrfs by to jistě ustál s přehledem sobě vlastním, o tom nepochybuju. Nepříliš důvtipní uživatelé s daty zničenými kvůli Ext4 by se jen závistivě dívali.

[k3dAR]

ve zprave na kterou si reagoval pretim, pise ze EXT4 to ustalo, BTRFS nikoliv...

[Andrej]

Ext4 potichu posralo / ztratilo data, Btrfs nikoliv.

Bacha na věc, je třeba nazývat věci pravými jmény.

[k3dAR]

na ext4 kdyby mel predem (u)delane (rucne, skriptem) checkumy vlastni vsech souboru, muze si po vypadku a oprave FS overit zda jsou v poradku, u BTRFS ktere mu zkolabovalo (3x z 5) si uz nemuze overit/udelat nic samozrejme je mozne ze to co povazoval za zhavarovani by jednim z milionu nastroju/zpusobu na opravu BTRFS slo zachranit, stejne tak je mozne ze na EXT4 i s milionem vypadku o nic neprijde

[Andrej]

na ext4 kdyby mel predem (u)delane (rucne, skriptem) checkumy vlastni vsech souboru, muze si po vypadku a oprave FS overit zda jsou v poradku

Hovno, vole, porotože by netušil, jestli jsou ty checksumy atomické nebo ne. (Nápověda: Ne, nebyly by.)

Pokud někomu na odpadním hardware zkolaboval Btrfs, je to skvělé poučení a dobrý důvod, proč nepoužívat a nekupovat odpadní hardware.

Hernajs. Co je lepší: Vědět, že se mi něco posralo a že moje data jsou pryč, nebo to nevědět a dalších pár let si myset, že jsou data v pořádku?

Jdětě už všichni s tím Ext4 sajrajtem do prdele. Nefunguje to. Nikdy to nefungovalo. Hoňte si nad tím, jak chcete, ale nikdy to fungovat nebude. Je to z 20. století, jenže tohle je 21. století. Poserte se.