No nicproti, ale jak to tak pozoruju, tak BTRFS je dobře rozjetý, s podporou v kernelu,... V podstatě nevidím důvod, proč ho odepsat, když se dá jenom doladit.
Snahu RH o vlastní řešení toho, co už teď dělá BTRFS, moc nechápu. Vždyť je to kupa práce a testování, aby se stali nekompatibilní se zbytkem světa. Aby se jim pak nestalo, že jim zákazník řekne: "Sorry, stoage infrastruktura nám jede na BTRFS, migrace na proprietální řešení je na dlouho a s velkým rizikem. Data jsou pro nás hodně cenný, takže když to neumíte, jdeme k SUSE nebo Canonicalu"
Některé nedořešené problémy má každý FS na světě, i ext4. Pokud jde o btrfs, nedořešené problémy se týkají hlavně raid 5/6, neboli stačí tuhle featuru nepoužívat. Facebook ho dneska používá, což mi připadá jako dost klíčové nasazení. Aby bylo jasno: nemám akcie u Red Hat ani nejsem nějak osobně zainteresovaný na btrfs, je mi celkem jedno, co kdo ho používá na co, ale ten věčný mýtus o tom, jak je btrfs nebezpečný atd atd je už opravdu ohraná deska.
na to ze je BTRFS mene rozsirene nez EXT4, tak mnohonasobne casteji ctu ze se nekomu podelal BTRFS kdy reakci od lidi co se BTRFS zastavaji a pouzivaji ho je to ze opravit to nepujde, at vykopiruje data ktere jdou/jsou, preformatuje a vrati je zpatky...wiki btrfsck (ackoliv 5let stara) rika ze se ma poustet az jako posledni opravna moznost, man page (aktualni) rika ze se parametr opravit ma "pouzivat opatrne!" a fungovat tak ze "staci nechtit pouzivat featuru opravu filesystemu" muze byt sice ohrana deska, ale ta nezkonci dokud nebude fsck pro btrfs robustni stabilni bezpecny nastroj...
"A Vi prý mate i mnohé uživatele editoru Vim."
Tohle jsem nikdy nepochopil. I ubuntu po instalaci ma vi, coz je vim ktery se tvari jako vi. Ma smysl na Fedore a Ubuntu pouzivat vi, misto plnohodnotneho vimu? Nema! Pouzival nekdo nekdy v poslednich 10 letech vi misto vimu? Leda nedobrovolne.
(Busybox apod. jsou jine kafe.)
Myslím, že jde o obrovskou setrvačnost. Spoustat adminů má klasické "vi" v krvi a spoléhají se na jeho přítomnost a fungování za všech okolností. V jakémkoliv nouzovém režimu, při rozpadlém terminálu, špatně mapovaných klávesách, ... Dodnes, když takovou situaci řeším, tak první mi pod ruce naskočí "vi". Podobné "problémy" způsobil přechod výchozího pageru z more na less.
Změna výchozího editoru by byla posun vpřed. Jediné, co se stane je to, že se způsobí trochu nepohodlí staromilcům.
No ale to je jedno. To se dá snadno vyřešit defaultní instalací VIMu a jedním symlinkem nebo aliasem navíc.
Jinak první příkaz, co po instalaci Fedory dávám do command line, je
sudo dnf install vim mc rsync
Bez toho to totiž nedává smysl.
Si naavíc nějak si nedokážu jako editor commitů v GITu představit nano... To by byla produktivita jak po zavedení Ribbonu do GUI.
29. 6. 2020, 09:25 editováno autorem komentáře
Myslím, že diskuse je o tom, co má být výchozí editor. A jestli si má uživatel vždy nastavit výchozí editor podle své volby - v tu(to) chvíli to musí udělat každý uživatel s každou novou instalací (případně novým uživatelským účtem). Je to mrňavá práce, ale konaná milionykrát.
Když to bude opačně, tak naopak při řešení průšvihu budete muset udělat opačnou akci - nastavit editor třeba na "vi". To je činnost, která se vůbec často nedělá, ale když už na to dojde, tak oceníte co nejméně překážek (maximálně jednoduchý, kompatibilní terminál, co nejjednodušší editor atp.)
Osobně bych výchozí editor taky změnil na něco modernějšího. Těch situací, kdy terminál skoro nefunguje, rapidně ubývá. K virtualizovaným serverům se dostanete přes konzoli, k fyzickým serverům přes IPMI. Lokální instalace opravujete přes live cd. Doba šla vpřed.
Výchozí má být rozhodně VIM - zpětná kompatibilita s původním VI a dá se snadno hodit alias, takže se VIM spustí i kddyž zadám do příkazové řádky VI. Ovládání VI je podmonožina VIMu, takže si nic nerozbiju a dostanu víc možností. Pro VI už na "velkým" systému (desktop, server) nějak není důvod - chyba může být stejně tak ve VI, jako ve VIMu, Nano,... a existuje lepší náhrada. Embedded věci s BusyBoxem jsou jiná třída.
"Když to bude opačně, tak naopak při řešení průšvihu budete muset udělat opačnou akci - nastavit editor třeba na "vi"."
Ale když bude rozbitý VI, tak to budu měnit taky. Textový editor je program, jako každý jiný. Sáhni do pytle s programama a vytáhneš kus s chybama.
Navíc textový editor nevidím z pohledu funkčnosti tak kriticky. Co musí spolehlivě běžet je kernel a shell, při přístupu po síti bez lokální konzoly ještě SSH. Bez toho jakýkoliv textový editor nespustím a s tím (a přístupem k repu nebo balíčku) si ho kdykoliv vyměním podle nálady nebo potřeby. A soubor zediituju v podstatě čímkoliv, klidně přes přesměrovaný echo nebo emacs, když na věc přijde.
@Petr M
O to tolik nejde. Jde o to, jak má být nastavena proměnná prostředí $EDITOR, jestli vi, vim, nano. Když spouštíte editor ručně, tak je skutečně jedno, jak se jmenuje - jde jen o to, aby byl k dispozici. Jenže někdy se výchozí editor spouští právě podle proměnné $EDITOR, např. při visudo
nebo při crontab -e
. Nyní je výchozí vi, ale to by se mohlo změnit.