Jaderné noviny - 6. 6. 2007

28. 6. 2007 | Robert Krátký | Jaderné noviny | 4201×

Aktuální verze jádra: 2.6.22-rc4. Citáty týdne: Dave Jones, Andrew Morton. Zábava s popisovači souborů. kmalloc(0) - ošemetná záležitost. Dodržování regulací při bezdrátovém síťování.

Obsah

• Aktuální verze jádra: 2.6.22-rc4
• Citáty týdne: Dave Jones, Andrew Morton
• Zábava s popisovači souborů
• kmalloc(0) - ošemetná záležitost
• Dodržování regulací při bezdrátovém síťování

Aktuální verze jádra: 2.6.22-rc4

Aktuální předverze je (k 6. 6. 2007) 2.6.22-rc4, vydaná 4. června. Přidává několik stovek oprav zaměřených na další stabilizaci 2.6.22. Vizte podrobnosti v dlouhém changelogu.

Od vydání -rc4 se do hlavního jádra žádné další patche nedostaly.

Aktuální verze -mm stromu je 2.6.22-rc4-mm1. Mezi nedávné změny patří operace pro vypnutí veškerých I/O přístupů (pro virtualizované hosty), dlouhý patch opravující zásek při selhání stránky, další práce na uspávání/hibernaci, patch O_CLOEXEC (vizte níže), kód pro podporu Xen na architektuře x86-64, podpora v ext4 pro nové systémové volání fallocate() a sada kontejnerových patchů.

Starší jádra: 2.6.16.52 bylo vydáno 31. května a obsahuje hrstku oprav.

Citáty týdne: Dave Jones, Andrew Morton

Jsem přesvědčen, že probíhá nějaká soutěž o vytvoření nejhoršího grafického poštovního klienta pro Linux. Nejsem si jistý, jaká je první cena, ani kdo vyhrává, ale všichni soutěžící jsou strašní.

-- Dave Jones

Lotus Notes nemá vážnou konkurenci.

Andyho skript pro kontrolu patchů rozpozná (tedy měl by) zalamování slov, roztahování tabů a snad i vyplňování volným místem. Až to uvedeme do chodu, měli by všichni, kdo pošlou vadné patche, dostat za pár minut od robota odpověď, která jim řekne, co udělali špatně - a tak se věci z velké části napraví samy.

Už se na to táááák těším. <Posílá zmínku komisi pro Nobelovu cenu>

-- Andrew Morton

Zábava s popisovači souborů

Článek o sysletech stručně zmínil problém s používáním popisovačů souborů k nízkoúrovňové komunikaci s jádrem. Pro popisovače souborů je vyhrazen jediný jmenný prostor a na alokaci těchto popisovačů se vztahují přísná pravidla. Dokud má aplikace daný prostor plně pod kontrolou, funguje všechno dobře a je možné se spolehnout na pravidlo o "nejnižším dostupném popisovači". Jakmile však začnou popisovače pro své vlastní účely používat i skryté úrovně (především knihovna C), zvyšuje se pravděpodobnost konfliktů a zmatků na úrovni aplikací. Aplikace, která chybně odhadne, kde bude popisovač souboru alokován, nebo bez okolků "vyčistí" otevřené popisovače knihoven, selže. Je to evidentně dost reálný problém - do té míry, že se glibc snaží seč může, aby interní popisovače souborů nepoužívala vůbec pro nic.

Je to také problém pro vývojáře jádra. Nechce se jim vytvářet nové služby založené na popisovačích souborů (například události signalizující dokončení u asynchronního I/O založeného na sysletech), pokud je glibc nebude používat. Hledají se tedy alternativy, z nichž většina spočívá ve vytvoření samostatného prostoru pro "systémové" popisovače souboru. Jeden způsob navrhl Linus:

Což by *mohlo* být něco tak jednoduchého jako určení, že "bit 30 v popisovači souborů označuje samostatný fd prostor", plus nějaké příznaky, aby open a spol. vracely tyto samostatné fd. Pro "select()" by pak byly k ničemu (samozřejmě za předpokladu plochého adresního prostoru), ale všemu ostatnímu by přišly vhod.

Davide Libenzi ten nápad rozvinul a poslal patch pro vytvoření nesekvenční oblasti pro popisovače souborů. Aktuální jádro popisovače sleduje v lineárním poli - technika, která funguje správně, dokud platí pravidlo o "nejnižším dostupném popisovači". Jakmile však začneme v číslech popisovačů nastavovat bity vyššího řádu, přestane být lineární pole praktické. Takže Davidův patch vytváří samostatnou datovou strukturu ve formě spojového seznamu, která se používá pro ten nesekvenční rozsah popisovačů souborů. Druhá část sady patchů opravuje systémové volání dup2(), aby používalo nový rozsah popisovačů. Běžné chování dup2() se nezměnilo, ale pokud je cílový popisovač souboru předán jako FD_UNSEQ_ALLOC, bude z nesekvenční oblasti alokován náhodný popisovač souboru. Specifický popisovač z této oblasti lze vyžádat předáním čísla vyššího než FD_UNSEQ_BASE.

Takový přístup má výhodu v tom, že nevyžaduje žádná nová systémová volání nebo změnu výchozího uživatelského binárního rozhraní. Ale podle Ulricha Dreppera není takový atribut žádná výhoda. Protože využívání této možnosti stejně vyžaduje změny v aplikacích, tak už by Ulrich raději viděl nové systémové volání. Navrhuje:

    int nonseqfd(int fd, int flags);

Toto systémové volání by duplikovalo otevřený popisovač souboru fd do nesekvenčního prostoru, volitelně by bylo možné při té příležitosti fd zavřít. Parametr flags by umožňoval kontrolu nad dalšími atributy nového popisovače. Obzvláště důležité je, jestli se popisovač objeví v adresáři /proc/pid/fd. Optimálním způsobem zavírání všech otevřených popisovačů souborů je totiž prosté přečtení tohoto adresáře, což ukáže, které popisovače jsou otevřené. Budou-li speciální popisovače drženy mimo tento adresář (například by mohly být přesunuty do paralelního adresáře private-fd), zabrání to aplikacím, aby, byť v dobrém úmyslu, uzavřely popisovače knihovny.

Bylo také navrženo, že by systémové volání open() mohlo mít příznak, který by způsobil zvolení nesekvenčního popisovače už od začátku, takže by nebylo nutné mít samostatné volání nonseqfd(). Existuje však dost systémových volání, která vytvářejí popisovače souborů, ale nemají parametr pro příznaky, takže by nebyla schopna vracet nesekvenční popisovače; klasickým příkladem je socket(). Bude tedy potřeba mít systémové volání, které dokáže popisovač nakopírovat do nového prostoru.

Ulrich navrhl, aby byly všechny popisovače souborů v nesekvenčním prostoru alokovány náhodně. Nerad by se dočkal situace, kdy si budou vývojáři aplikací myslet, že se mohou spolehnout na jakékoliv specifické chování při využívání tohoto prostoru. Objevily se také návrhy, že by nesekvenční prostor mohl být užitečný pro vysoce výkonné aplikace, které drží velká množství otevřených popisovačů souborů - například webové servery. Takové aplikace většinou nepotřebují záruku "nejnižšího dostupného popisovače" a s radostí by se obešly bez režie, kterou implementace této záruky přináší. Nevypadá to však, že by byla aktuální Davidova implementace psána s ohledem na tisíce nesekvenčních popisovačů.

Ulrich také pracoval na vyřešení souběhu [race condition], který se projevoval u určitých druhů aplikací. Pokud proces provede exec(), je možné požadovat automatické uzavření popisovače; k tomu se používá systémové volání fcntl(). Potíž je v tom, že mezi vytvořením popisovače (třeba pomocí volání open()) a následným voláním fcntl() uplyne nějaký čas. Pokud se jiné vlákno rozdělí a spustí nový program v době mezi těmito dvěma voláními, nebude mít jeho kopie nového popisovače nastaven příznak zavřít-při-exec, a ten tedy zůstane otevřen.

Obecné řešení problému chvíli potrvá, ale oprava případu s open je poměrně jednoduchá. Ulrich pro tento účel navrhuje nový příznak O_CLOEXEC. Nezdá se, že by byl někdo proti, takže se nový příznak možná objeví v 2.6.23.

kmalloc(0) - ošemetná záležitost

Uživatelé jader 2.6.22-rc si pravděpodobně všimli občasných varování a tracebacků souvisejících s alokacemi nulové délky. V jádře je totiž kód, který po kmalloc() požaduje alokace objektů s nulovou velikostí. Nikdo pořádně nevěděl, jak často se to stává, dokud nebylo začleněno varování (jako součást sady patchů se SLUB alokátorem); když se teď ty případy ukazují, tak to vypadá, že rozhodování o tom, co s tím, bude těžší, než by si kdo myslel.

Jednou možností je vracet NULL. Na první pohled by to dávalo smysl; volající požadoval, aby nebyla alokována žádná paměť, a kmalloc() mu vyhověl. Problém je s tím, že ukazatel NULL už má spoustu významů. Říká, že alokace selhala (což se nestalo - vždycky zbývá dost paměti na to, aby se dalo alokovat dalších nula bajtů), a často se používá pro označení faktu, že nějaká konkrétní struktura nebo subsystém nebyly inicializovány. Kromě toho to vypadá, že se občas vyskytne situace, při které by alokace nulové délky nemusela být nutně chybná; vezměme si například alokaci struktury, která byla v důsledku jaderných konfiguračních voleb optimalizována až na nula členů. Takové případy by šlo obcházet, ale není jisté, že by přidávání dalších kliček a výhybek stálo za tu námahu, když je možné nulové alokace řešit v rámci kmalloc().

Další možností je vracet nejmenší objekt, jaký kmalloc() zvládne - v současné době osm bajtů. Tak to ostatně kmalloc() potichu dělalo roky. Takové řešení sice patrně funguje, ale má tu nevýhodu, že vrací paměť, do které lze zapisovat. Ačkoliv jsou nulové alokace zjevně korektní, těžko hledat někoho, kdo by si myslel, že dává smysl ukládat do nulových kousků paměti. Ve většině případů by se tam nevešla ani vysoce zkomprimovaná data. Lidé, kteří se zabývají odhalováním chyb, by byli raději, kdyby jádro při každém pokusu o zápis do paměti alokované pomocí kmalloc(0) hlasitě protestovalo.

Což nás přivádí ke třetí možnosti: patch od Christoph Lametera, který nutí kmalloc(0) vracet speciální hodnotu ZERO_SIZE_PTR. Jde o ne-NULL hodnotu, která se tváří jako normální ukazatel, ale způsobuje chybu při každém dereferencování [použití odkazované hodnoty]. Při kfree() s touto speciální hodnotou bude samozřejmě provedena správná akce.

Vypadá to, že poslední možnost míří tím správným směrem, protože umožňuje alokace s nulovou délkou, aniž by se snažila maskovat nějaké pozdější nesprávné chování. Překvapivě se však objevila stížnost i v tomto případě: každé volání kmalloc(0) pak vrací stejnou hodnotu. Člověk by myslel, že to nebude problém; následné nulové alokace budou od sebe vzdáleny nula bajtů, přesně jak to říká C standard. Jenže někteří vývojáři mají obavy, aby to nezmátlo kód, který porovnává ukazatele, aby zjistil, jestli jsou dva objekty totožné. Navíc je zjevně v uživatelském prostoru běžné, že se nulové alokace používají jako způsob generování unikátních hodnot cookies. Pokud by všechny nulové alokace vracely stejný ukazatel, přijdou tyto cookies o svou unikátnost.

Nevypadá to však, že by si kvůli tomuto problému někdo dělal vrásky; Linus píše:

Když už jsou líní si vytvořit "generátor náhodných ID", tak by se aspoň ksakru mohli naučit používat "kmalloc(1)" místo "kmalloc(0)", aby dostali svoje unikátní cookie. Chtít po alokátoru, aby dělal idiotské věci jen proto, že si nějaký idiot myslí, že alokátor paměti je alokátor cookies, to je prostě ujetý.

Dokáži pochopit, že u věcí, jako jsou uživatelské knihovny, je potřeba brát ohledy na bláznivé lidi - ale u interních jaderných knihoven to tedy určitě nutné není.

Přičtěte si k tomuto komentáři skutečnost, že v rámci jádra ještě nikdo takové využití kmalloc() nevymyslel, a argumentaci s "unikátním cookie" dojde dech. Patch s ZERO_SIZE_PTR a bez varování se tedy v nějaké podobě pravděpodobně dostane do jádra, ale asi ne dříve než v 2.6.23.

Dodržování regulací při bezdrátovém síťování

Výrobci hardwaru pro bezdrátové síťování si během let vymysleli velkou a nápaditou hromadu důvodů, proč odmítají dávat k dispozici svobodné ovladače a hardwarové informace o svých produktech. Jedním z těchto důvodů je i dodržování regulací; kdyby mohly nedůvěryhodné třetí strany upravovat ovladače pro bezdrátová zařízení, mohly by také (nevědomky nebo úmyslně) zařízení naprogramovat tak, aby fungovalo mimo rámec frekvencí a úrovní výkonu povolených v dané oblasti. Někteří výrobci zjevně věří, že by mohli být viněni z toho, co lidé s jejich hardwarem dělají - zvláště v těch částech světa, kde jsou regulace pro využití spektra poměrně přísně prosazovány. Ačkoliv jsou v této souvislosti často zmiňovány Spojené státy, lidé z oboru se více obávají Japonska. Každopádně tyto regulace existují na celém světě (různé regulace) - a od linuxového systému s radiovými vysílači se očekává, že je bude dodržovat.

Proto Larry Finger nedávno představil novou verzi svého návrhu na mechanismus, který by Linuxu umožnil provozovat bezdrátové adaptéry v souladu s právními požadavky. Schéma je založeno na vytvoření databáze popisující regulační režimy v různých částech světa. Při startu systému by uživatelský démon (nějak) zjistil, kde se systém nachází, získal by z databáze příslušné parametry a nakrmil jimi subsystém mac80211, který by instruoval ovladače, jak zařízení naprogramovat. Pokud by nebyly požadované informace získány z uživatelského prostoru, využilo by jádro minimální konfiguraci, o které by se vědělo, že je povolena všude - za předpokladu, že taková existuje.

Objevilo se několik zajímavých reakcí, počínaje připomínkou, že vrstva mac80211 není vhodným místem pro regulační modul. Existují bezdrátové adaptéry pln kompatibilitou s MAC, které mac80211 nevyužívají, i když se jich otázka regulace týká také. Kromě toho mohou linuxové systémy obsahovat i jiné vysílače, například Bluetooth atd. Pokud bude do jádra přidán takovýto způsob pojistky pro dodržování regulací (a odstraněn z různých ovladačů, ve kterých už je), bylo by lepší ho přidat jen jednou tak, aby fungoval ve všech situacích. Ukázalo se, že podobné cíle měl modul "frequency broker" [vyjednavač frekvence], ale jeho vývoj se moc daleko nedostal.

Pro některé uživatele je příliš horlivé vynucování regulací starostí navíc. Mezi uživateli Linuxu jsou i lidé, kteří mají licence umožňující širší využití spektra. Je pochopitelné, že by rádi využívali svůj hardware (je-li takového využití schopen) způsobem, který by jim umožňoval vytěžit z volnějších limitů maximum. Pokud by jádro nakonec obsahovalo regulační mechanismus, který by nešlo přenastavit, bránilo by to některým uživatelům v něčem, na co mají právní nárok. Aspoň do chvíle, než by se ponořili do kódu a regulační mechanismus vypnuli.

Samozřejmě, pokud mohou regulační mechanismus obejít ti, kteří smějí, pak to mohou udělat i ostatní. Což vede k otázce, jestli je vůbec možné, aby byl regulační režim implementovaný ve svobodném softwaru vůbec kdy z hlediska úřadů dostatečný. Luis Rodriguez poukázal na dubnové rozhodnutí (PDF) Federální komise pro komunikaci [U.S. Federal Communications Commission], které napovídá, že by s tím mohly být problémy:

Komise se nezabývala možností, že by výrobci pro implementaci bezpečnostních opatření používali open source software. Připouštíme však, že hardwarová a softwarová bezpečnostní opatření, která spolupracují s open source softwarem, nemusejí být vázána open source smlouvou. V souladu se záměry Cognitive Radio Report and Order [Zpráva a nařízení týkající se poznávacího radia] a žádosti firmy Cisco tímto stanovujeme, že by výrobci neměli záměrně zveřejňovat charakteristické prvky používané pro implementaci bezpečnostních opatření v softwarem definovaném rádiu, pokud by to zvýšilo riziko proražení nebo jiného obcházení, které by umožnilo provoz rádia způsobem porušujícím pravidla Komise. Systém, který je zcela závislý na open source prvcích, bude jen velmi těžko prokazovat, že je dostatečně bezpečný na to, aby mohl být autorizován jako softwarem definované rádio..

(Zvýraznění doplněno.)

Nebude-li pro regulační úřady svobodný svobodný regulační mechanismus nikdy dost dobrý, stojí za to si položit otázku, jestli má vůbec cenu, aby vývojáři linuxového jádra na implementaci takového modulu vynakládali úsilí. Dalo by se argumentovat tím, že prvozování vysílačů v souladu s jejich licencováním je správná věc, bez ohledu na to, jestli to státní orgány považují za dost bezpečné. Jenže hlavním cílem je snaha uchlácholit státní orgány, takže jediným možným způsobem bude asi provést to, co už udělal Intel - přesunout regulační kód zpět do firmwaru zařízení, tj. zcela mimo hostitelský operační systém. Tento přístup přináší další výhodu v tom, že odstraňuje jednu z výmluv, proč nevydávat svobodné ovladače.

       

Komentáře

[Andy]

s/samy/sami

[Andy]

beru zpet.. to je ostuda, uz nebudu pit

[trekker.dk]

Proto Larry Finger nedávno představil novou verzi svého návrhu na mechanismus, který by Linuxu umožnil provozovat bezdrátové adaptéry v souladu s právními požadavky

Předpokládám, že si výrobci HW najdou jinou výmluvu, oblíbené jsou třeba smlouvy s třetími stranami.

[Michal Kubeček]

Jde o ne-NULL hodnotu, která se tváří jako normální ukazatel, ale způsobuje chybu při každém pokusu o zrušení odkazu na ni [dereferencing].

Nejsem si jistý, jaký je oficiální český výraz pro deferencing, asi bych napsal použití (nebo klidně dereferencování, ať si obrozenci prskají), ale zrušení to nebude zcela určitě.

[Robert Krátký]

Je-li referencing odkazování, tak jsem myslel, že dereferencing bude "ododkazování" (tj. opak). Ale teď jsem ještě ve slovníku našel, že dereferencing může být nepřímý odkaz. V tom případě (a vzhledem k tomu, že navrhuješ překlad "použití") si však nejsem jistý skutečným významem té věty.

[Michal Kubeček]

Referencing má význam spíš "odkazovat se na něco". Dereferencovat pointer znamená prostě použít hodnotu, na kterou se odkazuje. V daném kontextu to znamená, že

  char* p = kmalloc(...);
  char c = *p;

způsobí chybu.

[petr_p]

Já jen přidám, že mnohé dnešní jazyky mají automatickou dereferenci (např. druhé x v céčkovém příkazu x=x+1;), takže možná proto mají lidé problém pochopit ukazatele :)

[Kyosuke]

To není dereference, poněvadž to x není reference. Hmm, někteří lidé zase mají problém pochopit bindingy.

[petr_p]

Ale je. Jen to pred vami prekladac ume skryva. Drive bylo bezne, a i dnes existuji jazyky, kdy se muselo psat cosi jako x=!x+1. Jiste sam citete, ze leve x je misto v pameti, kdezto prave x je hodnota.

Nejsem expert na jazyky, ale me tento jev ucili pod pojmem implicitni dereference. Mozna ze mluvime o teze veci.

[Kyosuke]

Podívejte se někdy na nějaký lispovský kompilátor. Pak uvidíte, že od jména proměnné k hodnotě podle situace mohou vést nula až dva pointery. Má pak ještě smysl hovořit o nějakých dereferencích? Jisté je jen to, že některé přístupy k datům na úrovni strojového kódu jsou nepřímé. Ale na úrovni jazyka, tam je jen binding. A binding je a scope jsou všechno, co programátora po většinu času zajímá.

[Kyosuke]

A ještě k tomu Cčku: To druhé x je buď fetch z paměťové adresy SP-<konstantní_offset>, nebo v lepším případě je v danou dobu už v registru. Ve druhém případě nemá ani adresu v paměti. Tehdy není vůbec třeba dereferencovat, a to ani implicitně. Pokud použiju &x, pak ho v té paměti kompilátor zřejmě ponechá, ale to už jsem měřením ovlivnil mnohdy mlhavou realitu.

Mimochodem, máte příklad takových jazyků? Rád bych konkrétní názvy, abych si mohl něco dohledat.

[petr_p]

Jistě že v praxi překladače optimalizují, takže proměnná třeba přežije v registru a na zásobník se vůbec nedostane. Nicméně já se bavím o jazyku jako takovém (ne o překladači) a co jazyk programátorovi nabízí.

Implicitní dereference je jeden z druhů koerce. Čerpám z přednášek p. Škarvady, který vše přednáší z hlavy, takže jediné na co mohu odkázat, jsou zápisky jednoho studenta tamtéž odkazované (strana 77 a 99). Ten vykřičník mám vypůjčen z jazyka ML.

Mimochodem Google na implicit dereferencing vrací hned na prvním místě článek nadepsaný C has a lot of implicit dereferencing. To the right of each…

[Kyosuke]

Tak zrovna tahle stránka je poněkud "divná". i = deref(i) + 1 - to přeci nedává smysl, ne? Buď je levé i adresa, když je třeba ho dereferencovat, nebo pravé i dereferencovat vůbec nejde, ne? Taky nemůžu napsat p_i = *p_i + 1 (nebo můžu, ale bude to nesmysl). Buď to, nebo je chápání operátoru přiřazení autorem poněkud divné. Nebo mě jen možná mate vysoce abstraktní sémantika places v Lispu, kde se fakt jen šoupe s obsahem přihrádek.

[petr_p]

Rovnítko znamená uložení na adresu. Kdežto plus značí sečtení dvou hodnot. Proto je nutné pravou proměnnou derefercovat – načíst hodnotu uloženou v paměti na adrese i a do levé proměnné zapsat – zapsat na adresu i.

Přirovnání s explicitní dereferncí v C je neštastné, protože tam dochází na pravé straně k dvojí dereferenci. Nejprve se vezme hodnota na adrese p_i (1.) a pak se z této hodnoty udělá adresa a znovu se dereferencuje hvězdičkou (2.).

Zkuste si vzít příkazy i = i; a i = 1;. Přiřazovátko je typu (proměnná)=(hodnota). V prvém případě musím vyhodnocovat adresu i, v druhém nemusím. Tento krok navíc, který uživatel nemusí zapisovat, se nazývá implicitní dereference. Pokud by tomu tak nebylo, byl by příkaz 1 = 1 v pořádku, což jistě není. C je tímto prolezlé, tudíž práce s ukazateli a explicitní dereference (a reference) se v učebnicích vysvětluje, kdežto implicitní derefernce se bere za samozřejmost.

Do stejné kapitoly patří implicitní type casting. Např. int i; long int j; i + j; V tomto případě programátor nemusí nic řešit. V C by snad i prošlo, kdyby jeden z nich byl float. Avšak v jazycích, které umožňují parametrický polymorfimus (např. C++), by již podobné výstřelky mohly vyjít pěkně draho.

Implicitní derefencování striktně rozlišuje mezi hodnotou a proměnnou. Proměnnou považuje za ukazatel do paměti, kde hodnotu ukazatele, adresu, nelze programátorsky změnit (něco jako const * int, jenže tady dochází k dvojí dereferenci).

Pokud mluvíte o Lispu, tak je třeba mít na paměti, že se jedná o funkcionální jazyk. A takové jazyky a zvláště ty, které se snaží o referenční transparentnost, si mohou dovolit mnoho zjednušení a předpokladů, co se týče vyhodnocování výrazů.

[rADOn]

dereferencing neni zrušení odkazu ve smyslu mazani ale prevod ukazatele na odkazovanou hodnotu.

[test]

"Někteří výrobce zjevně věří, že by mohli " vyrobce -> vyrobci.

Jsem pro "dereferencovani", popisovačů souborů => file descriptoru, nízkoúrovňové komunikaci => low-level komunikaci, jmenný prostor => namespace, nové systémové volání => novy system call, příznaky => flagy, atd. atd.

Neni mozne, aby v odbornych clancich o IT nebyly veci nazyvany pravymi pojmy.

------------ ...a obrozenci at se vrati na pole kopat brambory

[Jary]

Já bych to asi neřešil. Obrozenci ať si trhnou a zastánci cizích výrazů taky. Hlavně ať se to dobře čte - je na autorovi ať se rozhodne. Třeba podle toho komu je článek určen.

[Libor Chocholaty]

+1

[Robert Krátký]

"Někteří výrobce zjevně věří, že by mohli " vyrobce -> vyrobci.

Díky, opraveno.

Jsem pro "dereferencovani", popisovačů souborů => file descriptoru, nízkoúrovňové komunikaci => low-level komunikaci, jmenný prostor => namespace, nové systémové volání => novy system call, příznaky => flagy, atd. atd.

Dereferencování už je probíráno výše - bohužel jsem tam nepochopil pravý význam. Za ostatními výrazy si však stojím a nebudu je psát anglicky, když pro ně existují výstižné a jednoznačné překlady. V případech, kde by to nemuselo být zcela zřejmé, uvádím původní výraz do závorky (nebo naopak - ponechávám původní výraz a do závorky uvádím popisný český překlad).

[test]

V podstate mi nejde ani tak o to, zda je vyraz cesky ci anglicky, ale ukazete mi nekde v C/C++ ceske pojmy? Pripadam si zhruba tak, jako by nekdo prekladal printf() na vytisknif(), struct na struktura, exit() na konec(), atd. Vzdyt kazdy kompilator i kazdy rozsirenejsi programovaci jazyk neuziva zadnou jinou terminologii, nez originalni.

Prekladem originalnich IT terminu se clanek prinejmensim zbytecne komplikuje, je zde snad nejaky C/C++ programator, ktery nevi co je to filesystem, file descriptor, system call, flag, low-level, alokace, dealokace, rekurze, interrupt, partition, race condition, kernel, ... ?

Neberte to prosim jako jednostranou kritiku, spise by to mel byt namet k zamysleni, zda mame vubec zapotrebi zbytecne komplikovat a prznit tak krasne terminy, jako je namespace.

[happy barney]

článok je imho určený aj pre ne(C/C++ programátorov). Príklad "dereferencing" naznačuje, že nie každý musí chápať význam slova. Osobne sa mi zdá, že výstižný český preklad má (v týchto končinách) väčšiu informačnú hodnotu ako anglický originál. Okrem toho, existujú "Odkazy a zdroje"

btw, "jmenný prostor" ma tiež niečo do seba

[Michal Vyskočil]

namespace

Afaik je jmenný prostor v češtině terminus technikus

[petr_p]

Plete si jména a významy.

[Robert Krátký]

jako by nekdo prekladal printf() na vytisknif(), struct na struktura, exit() na konec()

Což však nedělám

Pro ostatní zmiňované pojmy (kromě alokace - ten také nepřekládám) platí to, co jsem psal výše: nebudu je psát anglicky, když pro ně existují výstižné a jednoznačné překlady. V případech, kde by to nemuselo být zcela zřejmé, uvádím původní výraz do závorky (nebo naopak - ponechávám původní výraz a do závorky uvádím popisný český překlad).

Důvodem je to, že článek není určen pouze programátorům - zatímco programátor by neměl mít problém s pochopením např. slova "nízkoúrovňová", laik a/nebo neangličtinář by pravděpodobně výrazu "low-level" neporozuměl.

[egg]

Souhlasím, ale obávám se, že dereference je stejný případ jako alokace. (Na rozdíl od namespace.) Ekvivalent, který by byl více česky a používal se, neexistuje. Jako termín se používá dereference a s vymýšlením vlastních překladů je třeba být opatrný, jak se právě ukázalo. Znamená to nahrazení odkazu hodnotou, na kterou ukazuje. Nenapadá mě, jak to popsat jedním nebo dvěma slovy bez újmy na srozumitelnosti a přesnosti.

[thingie]

Možná, jmenné prostory asi jo, popisovače bych tvrdě ztrashoval a nahradil filedeskriptory, páč jsou ošklivé. Nízkoúrovňová komunikace by naopak mohla zůstat, ten system call vypadá dost křečovitě, nepřeložený. Flagy bych asi taky nepřekládal.

[Josef Kufner]

Flag == příznak.