Vlákno názorů ke zprávičce Ext4 bude výchozím souborovým systémem ve Fedoře 11 od Kakihara - Tak tohle nepochopim. Ma implicitni nasazeni ext4 JEDINOU vyhodu...
-
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).
