Názory k článku
Ext4 bude výchozím souborovým systémem ve Fedoře 11
-
Kakihara (neregistrovaný)Tak tohle nepochopim.
Ma implicitni nasazeni ext4 JEDINOU vyhodu oproti ext3 krom toho, ze pak bude ext4 solidne otestovane? To ext4, ktere by vsichni stejne nejradeji co nejdrive zahodili ve prospech btrfs. Jo, vim...az se za rok takhle implicitne nastavi btrfs, budu se ptat, proc btrfs, kdyz vsichni touzebne cekaji na btrfs2, ktere bude umet jeste daleko vetsi disky, ktere ovsem jedinej uzivatel fedory/ubuntu nema...
)-: -
Palec (neregistrovaný)Možná je UTF-8 o trochu složitější k parsování, ale je to vážně takový rozdíl? :-) Potom si také představ, že bys měl něco založeného na ISO 8859-2 lokalizovat do jazyků jako je čínština, japonština, arabština a další... Kdybys chtěl využívat jenom jednobytové znakové sady, nikam by ses pořádně nedostal, protože by ses zbláznil z jejich přepínání. Takhle jenom uděláš tabulku stringů pro každý jazyk a zbytek neřešíš.
Co se pomlčky týče, stojí ISO 8859-2 za prd. Kdo trochu rozumí typografii, ví, že je zásadní rozdíl mezi pomlčkou a spojovníkem, který tento milý standard AFAIK ignoruje. Kdo víc rozumí typografii, rozlišuje i půlčtverčíkovou pomlčku, čtverčíkovou pomlčku a případně minus.
http://www.root.cz/clanky/strucny-uvod-do-typografie/ -
xx (neregistrovaný)> Možná je UTF-8 o trochu složitější k parsování, ale je to vážně takový rozdíl?
Bohuzel, kdyz provadite nahrazovani/vyhledavani v radove MB textu, tak uz je to poznat. :(
> Potom si také představ, že bys měl něco založeného na ISO 8859-2 lokalizovat do jazyků jako je čínština, japonština, arabština a další...
Jenze mnoho veci neni potreba lokalizovat, a presto jsou v UTF-8 -- treba internetove stranky.
> Co se pomlčky týče, stojí ISO 8859-2 za prd.
Z hlediska typografie asi ano, ale pak se to muze vyresit jako v TeXu -- tam aspon poznate,
jakou pomlcku/mezeru tam mate, zato kdyz je tam vice druhu pomlcek a mezer, tak je docela
tezke (aspon na obrazovce) rozpoznat ruzne pomlcky/mezery.
Mj, kdyz se bavime o typografii, jak treba Unicode rozlisuje polohy diakritickych
znamenek nad pismeny -- napr. u ceskeho c s hackem neni hacek nad stredem pismene,
ale nad tezistem -- podobne to bude asi i u jinych jazyku, co kdyz se 2 jazyky
v tomto lisi -- jsou v Unicode 2 ruzne znaky -- jeden co ma diakritiku uprostred
a jeden, co ji ma treba vychylenou na stranu?
A nakonec jsou symboly, jenz Unicode nezna, takze mate stejne smulu. -
„Bohuzel, kdyz provadite nahrazovani/vyhledavani v radove MB textu, tak uz je to poznat. :(“
Ano, trvá to asi o pikosekundu déle, pokud máte to vyhledávání a nahrazování dobře naprogramované.
„Jenze mnoho veci neni potreba lokalizovat, a presto jsou v UTF-8 - treba internetove stranky.“
Já osobně jsem už několik let neudělal jiné texty, než UTF-8. Nesmírně to zjednodušuje život. Nehledě na to, že ani tento můj komentář nejde převést do ISO-8859-2, protože Vám tam budou chybět i ty základní české znaky, které můj komentář obsahuje. Typografie zkrátka není s ISO-8859-2 ani trochu kamarád.
„Z hlediska typografie asi ano, ale pak se to muze vyresit jako v TeXu -- tam aspon poznate, jakou pomlcku/mezeru tam mate, zato kdyz je tam vice druhu pomlcek a mezer, tak je docela tezke (aspon na obrazovce) rozpoznat ruzne pomlcky/mezery.“
Zkušené oko to pozná a když to bude jenom chvíli používat, praští Vás ty rozdíly do očí. Okamžitě poznáte, že namísto pomlčky je někde spojovník, a další.
Já se nedivím, když Vy jste nedospěl ještě ani k tomu, že v češtině existují čárky a háčky (k čemuž řada lidí dospěla třeba před deseti lety), že Vám v zásadě stačí i sedmibitové ASCII. Ale já už se s ISO sadami patlat nehodlám, nevidím v tom nic, než nevýhody.
„A nakonec jsou symboly, jenz Unicode nezna, takze mate stejne smulu.“
Akorát jich zná sakra víc, než ISO sady. A vzhledem k tomu, že 99,99999% běžně potřebných znaků v Unicode najdete, pak ten zbytek už je zanedbatelný problém. -
xx (neregistrovaný)> Ano, trvá to asi o pikosekundu déle, pokud máte to vyhledávání a nahrazování dobře naprogramované.
Bohuzel to trva dele, uz jen proto, ze znaky s diakritikou maji vice bajtu. Navic vetsina
programu/knihoven to nema dobre naprogramovane (mam na mysli konkretne kodovani UTF-8).
> Typografie zkrátka není s ISO-8859-2 ani trochu kamarád.
Stejne jako s Unicode. Napr. tam chybi ruzne velike mezery. Jak Unicode resi napr. mezery
za vetou v ruznych jazycich? Obavam se, ze nijak. Co treba zaporne mezery?
Unicode totiz nema s typografii nic spolecneho.
> Zkušené oko to pozná a když to bude jenom chvíli používat, praští Vás ty rozdíly do očí. Okamžitě poznáte, že namísto pomlčky je někde spojovník, a další.
Jenze kdyz v TeXu napisu $-$ tak je to matematicke minus, to same, kdyz napisu --- tak je to ctvercikova pomlcka, takze zkusene oko nema co poznavat, nebot je vse v poradku.
Unicode nijak neprispiva k dobre typografii, je to jen pokus sjednotit znakove sady,
ale s typografii to nema nic spolecneho.
> Akorát jich zná sakra víc, než ISO sady. A vzhledem k tomu, že 99,99999% běžně potřebných znaků v Unicode najdete, pak ten zbytek už je zanedbatelný problém.
Kdyz takovy symbol chcete, tak je to neprijemny problem a Unicode vam nevychazi nijak vstric. -
„Bohuzel to trva dele, uz jen proto, ze znaky s diakritikou maji vice bajtu. Navic vetsina
programu/knihoven to nema dobre naprogramovane (mam na mysli konkretne kodovani UTF-8).“
Stále můžete porovnávat bajt po bajtu, protože pokud máte Unicode ve stejném tvaru (ohledně dekompozice), můžete se vykašlat na to, že je to UTF-8 a hledat bajtíky.
„Unicode totiz nema s typografii nic spolecneho.“
Unicode neřeší celou typografii, ale rozhodně má k typografii daleko blíž, než ISO kódování. A Unicode řeší řadu typografických věcí – podle mě daleko elegantněji, než speciální značky v TeXu.
„Jenze kdyz v TeXu napisu $-$ tak je to matematicke minus, to same, kdyz napisu --- tak je to ctvercikova pomlcka, takze zkusene oko nema co poznavat, nebot je vse v poradku.“
Problém je, že TeX je jenom TeX. Až v něm budete sázet typograficky a graficky složitou sazbu, tak TeX zahodíte, protože je to fakticky za jeho možnostmi.
A já jsem spíš zastánce toho, když $-$ bude znamenat tři znaky, a vše bude mít svůj vlastní znak. Stejně tak, jako jste nacvičen na TeX a nepoznáte to normálně, tak typografové a sazeči jsou navyklí na znaky a s peseudošifrováním v TeXu Vás pošlou do háje. Takže názor proti názoru, kdo to rozsoudí?
„Unicode nijak neprispiva k dobre typografii, je to jen pokus sjednotit znakove sady,
ale s typografii to nema nic spolecneho.“
Ani 2× opakovaná lež se nestane pravdou.
„Kdyz takovy symbol chcete, tak je to neprijemny problem a Unicode vam nevychazi nijak vstric.“
Co kdybyste se s Unicode nejdříve alespoň povšechně seznámil? Co Vy na to? -
Proč by nešlo? Existuje (pokud srovnáte dokompozice) naprosto jednoznačné mapování mezi znaky a sekvencí bajtů v UTF-8, kterou najdete i tehdy, pokud nepojedete od začátku řetězce – stále je to jednoznačné. Je tedy možné klidně regulárními výrazy, které umí jenom 8-mi bitové prohledávání prohledávat naprosto bez problémů i UTF-8 řetězce.
UTF-8 je speciálně stvořené k tomu, a byl na to kladen důraz, když se vymýšlelo, aby skoro všechny operace šly provést i funkcemi a prostředky, které umí pracovat jen nad 8-mi bitovými znaky.
Takže si to v mozku opravte, jde to a jde to i v regulárním výrazu. Proto každý, kdo tvrdí, že prohledávání, či nahrazování v UTF-8 řetězcích je nutně pomalejší, než v 8-mi bitových znakových sadách na sebe mezi řádky prozrazuje, že se v problematice neorientuje. -
xx (neregistrovaný)> Je tedy možné klidně regulárními výrazy, které umí jenom 8-mi bitové prohledávání prohledávat naprosto bez problémů i UTF-8 řetězce.
S obycejnymi regularnimi vyrazy je problem nebot v UTF-8 jsou napriklad diakriticke znaky
na vice bajtu takze tohle [č] nebude fungovat tak jako v kodovani, kde na kazdy znak je
jeden bajt.
> UTF-8 je speciálně stvořené k tomu, a byl na to kladen důraz, když se vymýšlelo, aby skoro v:šechny operace šly provést i funkcemi a prostředky, které umí pracovat jen nad 8-mi bitovými znaky.
To bohuzel ne (ac by se mi to libilo), protoze ty same znaky muzete v Unicode tj. i v UTF-8
slozit ruznymi zpusoby, takze pouhe srovnavani bajtu je k nicemu. Pokud chcete srovnavat
bajty, musite oba retezce normalizovat, coz zdrzuje.
Abyste se take poucil prikladam odkaz http://www.unicode.org/unicode/reports/tr15/ -
„S obycejnymi regularnimi vyrazy je problem nebot v UTF-8 jsou napriklad diakriticke znaky
na vice bajtu takze tohle [č] nebude fungovat tak jako v kodovani, kde na kazdy znak je
jeden bajt.“
Takže i v regulárním výrazu budou znaky s diakritikou na více bajtů – a bude to fungovat.
„To bohuzel ne (ac by se mi to libilo), protoze ty same znaky muzete v Unicode tj. i v UTF-8 slozit ruznymi zpusoby, takze pouhe srovnavani bajtu je k nicemu. Pokud chcete srovnavat bajty, musite oba retezce normalizovat, coz zdrzuje.“
No však o tom jsem se psal, že je třeba mít Unicode ve stejném tvaru co se týká dekompozice. Navíc jsem ještě neviděl text, který by nebyl už normalizovaný. Ani nechápu, proč by třeba editor měl vytvářet nenormailzovaný text. -
xx (neregistrovaný)> Takže i v regulárním výrazu budou znaky s diakritikou na více bajtů – a bude to fungovat.
To ano, ale pak uz to nebudou regularni vyrazu 8-bitove, jak jste psal.
> No však o tom jsem se psal, že je třeba mít Unicode ve stejném tvaru co se týká dekompozice. Navíc jsem ještě neviděl text, který by nebyl už normalizovaný. Ani nechápu, proč by třeba editor měl vytvářet nenormailzovaný text.
Prvni problem je, ze tech normalnich forem je vic, takze pri prohledavani ruznych textu (treba na disku) je na to potreba brat zretel. Druhy problem je, ze se na to, ze text bude normalizovany, neda 100% spolehnout, takze to osetrit stejne musite. -
„To ano, ale pak uz to nebudou regularni vyrazu 8-bitove, jak jste psal.“
Regulární výraz bude v UTF-8, prohledávaný text bude v UTF-8, a knihovna regulárních výrazů si bude myslet, že prohledává normální text složený z 8-mi bitových znaků, přičemž vše bude fungovat. Kde je problém?
„Prvni problem je, ze tech normalnich forem je vic, takze pri prohledavani ruznych textu (treba na disku) je na to potreba brat zretel. Druhy problem je, ze se na to, ze text bude normalizovany, neda 100% spolehnout, takze to osetrit stejne musite.“
Problém je hlavně v tom, že i když je nromálních forem více, je to pro některé znaky jen několik variant přesně a jednoznačně určených sekvencí bajtů. I kdybyste nenormalizoval, stále uděláte bleskově rychlé prohledávání a nahrazování nad UTF-8.
Zkrátka, abych to uzavřel a už se k tomu nevracel, práce s UTF-8 je v zásadě velmi prímová a fajn. Nejsou nad tím žádné složité algoritmy, ani nic, co by výrazně zpomalovalo jakékoli operace nad řetězci, či texty. Já osobně jsem se rozhodl, jak už jsem psal výše, že 8-mi bitové znakové sady pro mě neexistují, píšu-li jakýkoli text kamkoli, a stále jsem přesvědčený, že to bylo nejlepší rozhodnutí.
Pokud se někdo chce trápit s již zastaralou ISO-8859-*, jejichž podpora je IMHO nutná už jen z historických důvodů, ale z žádných jiných, nechť se trápí. -
xx (neregistrovaný)> Regulární výraz bude v UTF-8, prohledávaný text bude v UTF-8, a knihovna regulárních výrazů si bude myslet, že prohledává normální text složený z 8-mi bitových znaků, přičemž vše bude fungovat. Kde je problém?
Napriklad: napisu-li regularni vyraz [ř] v UTF-8, tak pro 8-bitovou knihovnu regularnich vyrazu to vypada jako ze jsou ve skupine znaky dva: [C5 99]
Tudiz pokud budu prohledavat text s pismenem "š", pak 8-bitova knihovna regularnich vyrazu vidi znaky "C5 A1", tedy regularni vyraz [ř] uspeje na znaku s kodem C5, ktery je ve skutecnosti soucasti pismena š. -
Mám na Vás dotaz: Opravdu si myslíte, že je problém regulárnímu výrazu napsat, aby hledal sekvenci dvou bajtů? Vždyť automaticky je v zásadě regulární výraz hledač sekvencí bajtů!
Jinak já se omlouvám, ale dál nemohu odpovídat, rád bych, píšete suprově a kokrétně k věci, ale valí se tu na mě halda povinností. -
xx (neregistrovaný)> Mám na Vás dotaz: Opravdu si myslíte, že je problém regulárnímu výrazu napsat, aby hledal sekvenci dvou bajtů? Vždyť automaticky je v zásadě regulární výraz hledač sekvencí bajtů!
To mate pravdu, regularni vyraz [šř] staci prepsat jako (š|ř) a vetsina knihoven (8-bitovych) si s tim pak uz poradi. -
Ded Kenedy (neregistrovaný)
Regulární výraz bude v UTF-8, prohledávaný text bude v UTF-8, a knihovna regulárních výrazů si bude myslet, že prohledává normální text složený z 8-mi bitových znaků, přičemž vše bude fungovat. Kde je problém?
placate nesmysly, pokud budu mit regualarni vyraz, ktery oznaci radky, ktera maji prave jedno pismeno tj. ^.$ tak mi to nenajde radky obsahujici jedno pismeno s diaktritikou -
Kakihara (neregistrovaný)Taky to tehdy bylo docela bolestivy a ja nadlouho vykysnul u RH7.3
Ale jako jo, jen v tomhle pripade nechapu, proc radeji opravdu nepockaji na zminovanej btrfs, kolem ktereho je docela solidni hype a obecne se predpoklada(aspon mi to tak prijde), ze bude na linuxu(alespon na desktopu) standardem...
Neni ext4 predem mrtvej? -
Tom (neregistrovaný)To je jednoduche. RedHat pocita s vyuzitim ext4 u RHEL pocinaje tusim 5.4 - tam btrfs rozhodne neda. Takze se ozkousi na Fedore, a uprimne receno, ja tenhle pristup schvaluji. UTF-8, gcc 3, acl, xorg 1.5 - to vsechno uzivatele Fedory otestovali a ostatni pak zaradili jako otestovane. Podpora btrfs je zatim experimentalni (skoro se divim, ze to v tomhle stavu do jadra pustili - srovnejte si treba postup vuci Reiser4).
-
Izak (neregistrovaný)Fedora neni urcena na server, kazdopadne je to linux a je na server mnohem vhodnejsi, nez treba windows.
Co na fedore, co se tyce serveru nefunguje ?
I kdyz taky pouzivam CentOS na servery, jediny problem jsou ale moderni tech, jako XEN etc, to si to pak stejne cele musim predelat a upgradovat a nejsem si jisty, co je pak lepsi, zda nasadit CentOS s predelanym kde cim, nebo rovnou fedoru, kde vypnu vse pro desktop ;-)) -
Izak (neregistrovaný)Takze vazeni, kde kdo pouziva XFS, ktery se nakonec ukazal jako nebezpecny FS, v seznamu jej dokonce po X letech pouzivani odstrihli uplne, nekde s nim zase maji dobre zkusenosti, nekteri nasi zakaznici jej taktez pouzivaji, mam ho i na notebooku, ale pripravuji se prechod zpet na ext3 nebo ext4, kdyz pi po vybiti baterek a padu vsechny nove soubory mrsil, nastesti jsem si toho hned vsiml a provedl opravu FS, proc se ale kurna ten FS namountoval, kdyz byl corrupt a nic nehlasil !
Ext4 uz pouzivam doma, jeho vyhody jsou jasne, umi velke soubory, velke part. a je rychli.
btrfs ... nas, co umime linux a mame SW RAID (doma pouzivam 1-OS, 5-Data, 0-docasne soubr) a nad RAID5 mam jeste LVM. Co mi nabidne btrfs vice ? ... krom toho ze jeste neni vhodne ho pouzivat, nema danou strukturu, takze nova verze uz nemusi umet precist starou a nikdo mi nenapise prevodnik.
Mam spise pocit, ze se nekdo vzhledl v ZFS, v zivote ho nepouzival a hlavene nevidel, co to zacne delat, kdyz vypadavaji disky na OpenSolarisu, uvedomte si, ze Solris ma LVM na urovni daleko za LVM1 pod linuxem, SW_RAID je u nich taky dost slozity a tezkopadny, tak vsichni pouzivali VeritasFS a Veritas Volume Man. ... cehoz se chtel SUN zbavit. Mimochodem LVM2 umi to same co Veritas Volume manager, ma i variantu Cluster LVM, staci spustit cluster a vytvorit VLM2 jako clusterovou, vyuziva to i GFS.
Vubec si nejsem jisty, zda btrfs potrebujem, kazdopadne nikomu nebudu branit ho vyvijet, nebo pouzivat, kazdopane jeste uplyne par let, nez bude pouzitelny. -
alblaho (neregistrovaný)Já nevím, co tu všichni držkují. Fedora tu je od toho, aby obsahovala nové věci. Uživatelé to očekávájí. Přesto se obvykle Fedora dá používat a to je úspěch :-).
A krom toho je ext4 natolik feudální design, že bych tomu i věřil :-)
Kdo něco takového nechce, ať používá Debian. -
S tímhle musím naprosto souhlasit. Fedoru používám asi 2 roky a i když vím, že nově vadaná verze bude obsahovat plno chyb, které mi jistým způsobem okoření život, tak si ji stejně nainstaluju. Ano, očekávám, že budou jistý problémy, který byly doposud povětšinou drobného rázu, ale mě to nevadí. Prostě si můžu dovolit mít ntbk do jisté míry nefunkční, tak proč ne.
To že je Fedora testovacím produktem RH je obecně známá věc a ani páni z RH se tomuto označení nebrání. Nikdo vás nenutí Fedoru používat, tak proč na ní nadávat.
ČLÁNKY DO MAILU