Jaderné noviny – 15. 4. 2009 (diskuse)

[🇵🇸]

Další alternativou k data=ordered by mohl být režim data=guarded navržený Chrisem Masonem.

^_^

[Filip Jirsák]

že zaznamen8v83 zpoždění

Autor nebo překladatel měl problém s přepínáním klávesnice

A hned v další větě:

Z toho je zjjvný závěr,

Další odstavec:

Tento režim odstraňuje potřebu zapisování datových bloků byly na disk před metadaty

„Byly“ je tam zřejmě navíc.

[trekker.dk]

Autor nebo překladatel měl problém s přepínáním klávesnice

Korektor.

Z toho je zjjvný závěr,

Tentokrát autor i korektor, já napsal zejvný

„Byly“ je tam zřejmě navíc.

Robert asi tentokrát chvátal...

[Robert Krátký]

Omlouvám se...

[Filip Jirsák]

Stanou se i horší věci. Kdo se ke korekturám textu dostane častěji, určitě už při korektuře vyrobil chybu, která v původním textu nebyla...

[Robert Krátký]

Přiznávám, že s JN trochu zápasím. Ten text je dost hutný, takže mám co dělat, abych po celou dobu udržel maximální koncentraci. A když pak objevím nějakou chybku nebo nepřesnost v překladu, tak do toho při opravě pro jistotu rovnou vrazím ještě vlastní překlep . Klobouk dolu před Jirkou - já už ani nevím, jak jsem to dělal, když jsem to ještě překládal sám...

[trekker.dk]

He, abych pravdu řekl, tak já tu koncentraci taky většinou neudržím (což je potom nejvíc vidět na slovosledu)

[🇵🇸]

Kontrola pravopisu? ^_^

[Filip Jirsák]

V té hromadě cizích slov, jmen, novotvarů a HTML značek? Automatická kontrola pravopisu (přesněji kontrola překlepů) funguje jedině v případě, kdy dává málo planých poplachů -- tj. většina slov označených za chybná jsou opravdu chyby. Když 90 % podtržených slov jsou správná slova, která jen nejsou ve slovníku příslušného programu, přestane červeným vlnovkám člověk stejně věnovat pozornost...

[🇵🇸]

Mně se osvědčila kontrola pravopisu i u odborných textů: měl jsem to v OpenOffice.org se zapnutou automatickou kontrolou pravopisu a skákal jsem očima mezi podtrženými slovy.

[Robert Krátký]

Také to tak dělám, ale jak je vidět, tak se nechám snadno ošálit... V záplavě podtržených slov (akorát pro finální kontrolu nepoužívám OOo, nýbrž Konqueror) se leccos ztratí.

[Nicky726]

To mám radši kontrolu pravopisu "spouštěnou tlačítkem" v okamžiku, kdy to má smysl.

[🇵🇸]

Takovou tu, která nabízí v dialogu opravy? Fuj!

[Nicky726]

Nevím jak OOo -- to jsem k tvorbě něčeho nepoužil už hodně dlouho -- ale v KWrite je to Nástroje -> Kontrola pravopisu. Jinak opravy nabízí, a pokud se na to díváme demokraticky, tak se většinou i trefí. Zas to není problém přepsat na něco, co tam zrovna není.

[🇵🇸]

Narážím na to, že se snaží opravit i slova, která jsou správně, ale nejsou ve slovníku... člověk to pak odklikává a může něco přehlédnout.

[Nicky726]

Problém se slovníkem je vždycky. Přehlédnutí hrozí vždy, ať už bude člověk odklikávat dialog nebo hledat vlnovky. Mně přijde při delším textu lepší odklikávat dialog, protože prochází jeden výskyt za druhým. U textového pole v komentáři se mi zas víc líbí vlnovky, protože dávají okamžitou reflexi při samotném psaní.

[Filip Jirsák]

Přeskočit očima správně napsané podtržené slovo je mnohem rychlejší, než vybírat nějaké tlačítko (Přeskočit? Ignorovat? Přidat do slovníku? Tento výskyt nebo všechny?) a klikat na něj.

[🇵🇸]

Spíš je problém, když je těch korektních neznámých slov hodně a člověk valí Ignorovat, Ignorovat, Ignorovat,... Pak se snadno něco přehlédne.

[petr_p]

Od čeho existují uživatelské slovníky?

[🇵🇸]

Pokrýt tolik slov?

[petr_p]

Proč ne? Pořád lepší, než při každé aktualizaci překladu je prohlížet znova. V opačném případě mi to přijde jako sebetrýznění a hrozí, že se dostaví překlepová slepota.

[Filip Jirsák]

Když se to slovo, které není ve slovníku, vyskytne ve vašem textu jednou za 2 roky, je zbytečné jej přidávat do uživatelského slovníku. Navíc tím přidáváním ještě roste náročnost korektury textu – u neznámých slov už se nerozhodujete jenom o tom, zda je to slovo správně či špatně (a máte jej opravit nebo „chybu“ ignorovat), ale pokud je správně, musíte se ještě rozhodovat, zda jej máte nebo nemáte zařadit do slovníku. Zařadit do slovníku každé správné slovo také není řešení, protože čím víc slov ve slovníku máte, tím nižší je účinnost spellcheckeru při odhalování překlepů – zvyšuje se pravděpodobnost, že chybně napsané slovo se trefí do nějakého málo používaného slova, které je ve slovníku.

[petr_p]

Uživatelský slovník nemusí být jenom jeden. Můžete mít slovník pro každou aplikaci nebo obor nebo stupeň odbornosti zvlášť.

Chápu, že není dobré kdejaký jednoúčelový patvar přidat do slovníku. Ale pokud vám standardní slovník vyhodí 50 neznámých slov, z čehož jsou skutečné překlepy jen 3, tak je škoda nevyužít nástrojů, které máme. Až budete kontrolovat příští verzi, tak už vás těch 47 novotvarů obtěžovat nebude.

[petr_p]

Já na gettextové překlady používám něco takového:

msgexec -i $< sed 'a\' | \
        aspell --lang=cs --encoding=utf-8 list | \
        aspell --lang=en --encoding=utf-8 list | \
        sort -u >badtranslationlist

Myšlenka je vytáhnout z kódu obsahový text (ve vašem případě to budou textové uzly a hodnoty atributů alt a title; lze použít parametr aspellu --mode=html), který zkontrolujeme proti českému slovníku a zbytek proti anglickému. Výsledek setřepeme do seřazeného seznamu.

Takový seznam si pak pozorně přečteme a chybná slova v původním textu opravíme. Ustálené novotvary můžeme připadat do vlastního slovníku a ten pak použít při další kontrole. Tento postup opakujeme, dokud soubor badtranslationlist obsahuje slova, která se nám nelíbí.

[Standa Kříž]

Když se tak hromadně opravuje, tak bych přidal zajímavé slovo "zaznamen8v83".

Jinak super seriál, díky za překlady. Dnešní citát o samohláskách mě opravdu dostal.

 

[Standa Kříž]

Tak opravu beru zpět (už tu je), poděkování ne :)

[Michal Kubeček]

Zajímavé je, že u ext3 jsem na ten problém s fsync() nikdy nenarazil, zato s ním (nebo něčím, co se projevuje velmi podobně) už nějakou dobu válčím u XFS. Dokonce jsem už rezignoval a na velké filesystémy (stovky GB), na kterých hodlám mít image disků virtuálních strojů pro VMware, raději používám JFS.

[Robert Krátký]

Chápu-li to správně, tak "ten problém s fsync()" se začne projevovat až teď, tj. po začlenění příslušných patchů, které nastaví výchozí chování jako u ext4.

[petr_p]

Řekl bych, že ten problém se projevuje už nyní. Jakmile máte velkou diskovou cache, plnou nezapsaných dat a pak zavoláte fsync, tak data synchronizovaného souboru se umístí na konec fronty, ale de facto se vynutí vypláchnutí celé cache. A to je záležitost, která s dnešními obludně velkými paměťmi (a tedy i cachí) trvá znatelně dlouho.

Když jsem měl v počítači 32 MB RAM, tak disková cache zabírala několik megabajtů, disk byl schopen sekvenčního zápisu kolem 11 MB/s, takže (f)sync trval teoreticky nejdéle sekundu (u rozkouskovaného zápisu to mohlo být tak 5 sekund). To vzhledem k tehdejší rychlosti procesorů a častému swapování jste ani nepostřehl.

Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.

Kdybych měl moderní stroj, tak mi disk dá 100 MB/s, ale pokud jej taky adekvátně zatížím (nějaké to desktopové prostředí, Firefox, Eclipse, Evolution, …), tak disková cache bude zabírat třeba gigabajt a vylití bude trvat alespoň 10 sekund.

[petr_p]

Abych se opravil, tak záleží, jestli v cachi máte data na čtení nebo na zápis. Takže je pravda, že běžný uživatel tam toho k zápisu moc mít nebude. Pokud ale stříháte video nebo sbíráte telefonní odposlechy, tak to bude situace docela jiná.

[Michal Kubeček]

Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.

Kdyby šlo o tři sekundy, tak to neřeším. Problém, o kterém jsem se zmiňoval u XFS, se projevuje tak, že při 100 MB nezapsaných dat trvá provedení příkazu sync 30-60 sekund. Podobně třeba po vypnutí VMware virtuálního stroje následovala při troše smůly desítky sekund trvající prodleva, během které jeho UI nereagovalo a stejně tak všechno ostatní, co se snažilo přistupovat k disku (předpokládám, že VMware volá po vypnutí virtuálního stroje fsync() na image virtuálního disku). Mountováním s nobarrier se to zlepšilo, ale jen zhruba na polovinu, řešením byl teprve přechod na JFS.

[petr_p]

To, co popisuji já, je problém blokové vrstvy. Vy jste měl spíš problém se souborovým systémem. Já XFS vůbec neznám, takže těžko můžu radit.

Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?

Kdyby to byla jen bloková cache (jak si myslím), tak co je v ní, už dávno prošlo (V)FS, takže její vylití by mělo být omezeno jen výkonností plánovače blokového I/O. Takže pokud ta cache neobsahuje hromadu drobných synchronních požadavků, které by mohly ucpat sběrnici z řadiče do disku režií ATA protokolu a donutit disk k neefektivnímu seekování, tak by měl jet disk na plno a cache by se měla vyprázdnit za pár sekund.

Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.

[Michal Kubeček]

Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?

Tohle číslo je z tohoto pohledu celkem nezajímavé, protože to je veškerá disková cache, z níž většinu obvykle většinu tvoří data, která jsou načtena do cache, ale na disku jsou aktuální, takže je není potřeba zapisovat. Pro to, o čem se bavíme, je směrodatnější spíše hodnota Dirty v /proc/meminfo.

Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.

Tomu bych se samozřejmě nedivil, ale tohle není ten případ. Ty problémy jsem měl na počítači, kde disk i CD-RW mechanika byly na SATA řadiči (navíc na PCI-E sběrnici) a většinou se CD-RW mechanika vůbec nepoužívala. A nešlo jen o jeden počítač, u některých šlo dokonce o SCSI disk. Společným znakem byl 64-bitový procesor (tím ovšem nechci naznačovat, že na 32-bitových se to dít nemůže) a mám pocit, že s vícejádrovými procesory to bylo trochu výraznější (ale to nemám podloženo měřením).

[geebranz]

Virtual assistance

storageshedsportland.com