Jaderné noviny - 18. 7. 2007

2. 8. 2007 | Robert Krátký

Články - Jaderné noviny - 18. 7. 2007  

Aktuální verze jádra: 2.6.22.1. Citáty týdne: Linus Torvalds, Kay Sievers, Rafael Wysocki. Začleněno do 2.6.23. Autentizace a autorizace USB zařízení. Další pokus o software suspend.

Obsah

• Aktuální verze jádra: 2.6.22.1
• Citáty týdne: Linus Torvalds, Kay Sievers, Rafael Wysocki
• Začleněno do 2.6.23
• Autentizace a autorizace USB zařízení
• Další pokus o software suspend

Aktuální verze jádra: 2.6.22.1

Během posledního týdne nevyšly žádné nové verze. Začleňování do 2.6.23 stále probíhá a do hlavního repozitáře se valí další patche; vizte níže.

Citáty týdne: Linus Torvalds, Kay Sievers, Rafael Wysocki

Já si jen moc a _moc_ přeji, abychom měli dvě stabilní verze za sebou. Mám pocit, že 2.6.22 má dobrý potenciál a nerad bych měl hned potom další 2.6.21.

-- Linus Torvalds

Sysfs se nikdy nesnažil být ABI/API v běžném slova smyslu - některé části jsou jen trochu hezčí "kernel dump" :)

Musíte se tam řídit _velmi_ specifickými pravidly, abyste získali informace způsobem, který v další verzi jádra, nebo dokonce o vteřinu později, nepřinese neočekávané výsledky.

-- Kay Sievers

Podle mého názoru je každý hibernační systém, který nebere ohled na uvedené požadavky, odsouzen k neúspěchu. Navíc se některými z nich neřídí ani existující systémy, takže je všechny považuji za nedokončené. Z toho důvodu bych daleko více uvítal nápady, které by nám umožnily, více či méně evolučním způsobem, vylepšit stávající systémy, místo pokusů o jejich celkové nahrazení něčím úplně novým.

-- Rafael Wysocki

Začleněno do 2.6.23

Od minulého týdne bylo do repozitáře hlavního jádra zařazeno dalších 2600 sad změn. Začíná být jasnější, jak bude 2.6.23 vypadat; jádro bude obsahovat:

• Nové ovladače pro čipy Dallas DS1682, i2c řadiče PMC-Sierra MSP71xx, řadiče USB periférií Renesas M66592, USB řadiče Renesas R8A66597, řadiče mostů USB na RS232 OTi-6858, řadiče USB zařízení Samsung S3C24xx, DMA enginy Intel iop32x, iop33x a iop13xx DMA, compact flash rozhraní Xilinx SystemACE, duální UART zařízení BCM1250, multikanálové SPI řadiče OMAP24xx, real-time hodiny Atmel AVR32 AT32AP700x, ST M41T80, ST M48T59 a Dallas DS1216, framebuffey TI OMAP, řadiče displejů a LCD (vč etně podpory několika panelů), watchdog zařízení Atmel AT32AP700X, čtečky karet IBM z/VM a demodulátory Afatech AF9005.


• Po letech práce byla začleněna implementace Xen i386. Xen je konečně součástí hlavního jádra.


• Bylo začleněno systémové volání fallocate(), ale bez možnosti dealokace.


• Vývojový souborový systém ext4 získal množství nových funkcí, včetně podpory fallocate(), nanosekundových časových značek [timestamps] a podpory pro adresáře obsahující více než 65000 podadresářů.


• Nový ovladač "macvlan" umožňuje administrátorovi systému vytvořit virtuální rozhraní mapovaná na a z určitých MAC adres.


• Bylo přidáno několik virtuálních ovladačů pro logické domény Sun (na architektuře SPARC64). Také přibyla podpora LDOM CPU hotplug.


• Byl začleněn kód bsg - nový obecný ovladač SCSI zařízení založený na blokové vrstvě.


• Pryč šla podpora vícecestného kešovaného IPV4 směrování; kód nikdy pořádně nefungoval a nikdy se nedostal z experimentálního stavu.


• Přibyla základní experimentální podpora PPP přes L2TP sockety.


• Rozšíření pro model zařízení [device model extension] (označeno jako experimentální) může exportovat informace o správě desktopu [desktop management information (DMI)] u notebooku přes sysfs. To distributorům umožní natáhnout právě ty ovladače, které jsou pro daný notebook potřeba, místo techniky "natáhneme je všechny a necháme hardware, ať si vybere", která je teď často používána.


• Velmi experimentální funkce "USB persist" [zachovej] se pokouší udržet stav USB zařízení, když se přeruší napájení. Hlavní motivací pro tento patch je mít možnost uspat systém obsahující souborové systémy na úložném USB zařízení a mít pak tyto souborové systémy připojeny a připraveny k použití při probuzení.


• Regulátor procesoru speedstep-centrino [CPU governor] byl podle plánu nahrazen kódem acpi-cpufreq.


• Souborový systém XFS má teď koncept "stream of files" [proud souborů], který mu umožňuje ukládat související soubory (například sérii snímků videa) na disku souvisle.


• Souborový systém AFS podporuje zamykání.


• Ovladač pro práci se "surovými" bloky [raw block driver] byl vytažen ze stavu "zastaralý", protože to vypadá, že v dohledné době odstraněn nebude.


• Byl přidán příznak O_CLOEXEC.


• Máme nový příznak clone() - CLONE_NEWUSER - který pro proces vytváří nový uživatelský jmenný prostor; je určen pro použití s kontejnerovými systémy.


• Dlouho diskutované patche zabraňující fragmentaci paměti byly nakonec začleněny; související kód pro uvolňování stránek po kusech [lumpy reclaim] byl také začleněn.


• Kernel virtual machine (KVM) teď podporuje SMP hosty.

Změny viditelné vývojáři jádra:

• Většina startovacího kódu pro x86 byla přepsána do C. Změny by se neměly dotknout nikoho, kdo se v kódu nevrtá, ale těch pár by mělo mít velmi usnadněnou práci.


• Máme nové API rtnetlink pro správu softwarových síťových zařízení.


• Síťovací kód teď může pracovat se zařízeními, která mají více než jednu přenosovou frontu. Tato funkce byla potřeba kvůli korektní podpoře některých bezdrátových zařízení.


• Jádro kódu sysfs bylo dost předěláno, aby se zeslabilo spojení mezi sysfs a interními kobjekty. Nový kód by měl usnadnit práci autorům ovladačů, kteří už se nebudou muset starat o tolik problémů s životností objektů.


• Byla odstraněna nepoužívaná metoda enable_wake() z ovladače PCI.


• Ovladače, které chtějí z konfiguračního prostoru PCI získat ID revize, by teď měly prostě použít hodnotu z pole revision struktury pci_dev. Všechny ovladače zařazené v jádře už byly změněny, aby tento přístup používaly.


• SCSI vrstvě přibylo pár scatter/gather přístupových funkcí - scsi_dma_map() a scsi_dma_unmap() - je to součást přípravy na zřetězené scatter/gather seznamy a dvousměrné požadavky. Většina ovladačů v jádře byla aktualizována, aby tyto funkce používala.


• Kód idr má dvě nové pomocné funkce: idr_for_each() a idr_remove_all().


• Většina sestavovacího systému jádra byla převedena na objekty "menuconfig", což usnadňuje hromadné zapínání nebo vypínání celých skupin voleb.


• sys_ioctl() už není exportován do modulů.


• Pomocné funkce tabulky stránek (ptep_establish(), ptep_test_and_clear_dirty() a ptep_clear_flush_dirty()) byly odstraněny - nikdo je v jádře nepoužíval.


• Jaderná vlákna nejdou ve výchozím nastavení zmrazit; všechna jaderná vlákna, která je potřeba zmrazit kvůli provedení suspend-to-disk [uspání na disk], teď musí zavolat set_freezable().


• Výchozí je teď SLUB alokátor.


• Nová funkce is_owner_or_cap(inode) kontroluje přístupová práva podle aktuálních fsuid a kvalifikací.


• Nová funkce:

      char *kstrndup(const char *s, size_t max, gfp_t gfp);
  

  Duplikuje řetězec podobně jako strndup() v uživatelském prostoru.

Za zmínku stojí i pár věcí, které v 2.6.23 nebudou. První z nich je patch s kontejnery procesů - ještě není tak docela hotový. Některé další funkce (například skupinové plánování CFS) na kontejnery procesů čekají, takže je pravděpodobné, že bude kód připraven pro začlenění v 2.6.24.

Další velká věc, na kterou se nedostane, jsou clockevents, dynamický tik a časovače s vysokým rozlišením pro x86_64. Autoři už patch považují za připravený, ale po potížích, které způsobilo začlenění verze pro i386 v 2.6.21, mají někteří vývojáři pocit, že by se tentokrát mělo postupovat opatrněji. Výsledkem byla poněkud otrávená diskuze v konferencích a rozhodnutí patche lépe rozdělit, aby mohly být pečlivě prohlédnuty v rámci dalšího vývojového cyklu.

Autentizace a autorizace USB zařízení

Zařízení universal serial bus (USB) [univerzální sériová sběrnice] obyčejně nepodléhají nějakým bezpečnostním opatřením. Může-li uživatel USB zařízení strčit do počítače, předpokládá se, že je oprávněn to udělat. Existují však situace, ve kterých přidělává zapojování USB zařízení lidem vrásky; obvykle se jedná o strach z kopírování obchodních tajemství na nějaké USB zařízení, které lze z budovy snadno odnést. Většinou se takové hrozby řeší zákazem (nebo pokusem o zákaz) USB zařízení nebo prostě zapatláním USB portů lepidlem.

Bezdrátové USB situaci mění. Tento protokol umožňuje vzdálené připojení USB zařízení, takže není potřeba mít kabel, o který všichni zakopávají. Zatímco běžný uživatel notebooku by si pravděpodobně všiml, kdyby mu útočník zastrčil do USB portu kabel od svojí klávesnice, v případě využití bezdrátového USB by mohl útočník klávesnici připojit, aniž by se přiblížil. Je zřejmé, že je potřeba nějaká bezpečnostní vrstva. Specifikace bezdrátového USB tuto potřebu předvídala, takže nabízí celou řadu technik s množstvím zkratek pro zajištění 1) autentizace jak hostitele, tak zařízení a 2) dostatečného šifrování bezdrátové USB komunikace, aby nemohla být odposlouchávána.

Iñaky Perez-Gonzalez pracuje na podpoře bezdrátového USB pro Linux. Došel k závěru, že nehezké detaily autentizace bezdrátového USB patří do uživatelského prostoru; jádro nemůže (samo o sobě) udržovat přehled o tom, která zařízení se smějí k systému připojit. Je však na jádře, aby implementovalo autorizační stranu rovnice: neautorizované bezdrátové USB zařízení by nemělo mít možnost s hostitelským systémem jakkoliv komunikovat. Iñakyho odpověď na otázku autorizace je tato sada patchů pro subsystém USB.

Patche přidávají do struktury usb_device tři nové příznaky: wusb, authorized [autorizované] a authenticated [autentizované]. První značí, že se jedná o bezdrátové zařízení, a poslední (který ještě není používán) říká, že zařízení prošlo autentizací. Prostřední ukazuje, že se smí se zařízením mluvit. Dokud není zařízení autorizováno, nepřečte si jádro ani jeho konfiguraci (aby zjistilo, jaké styčné body poskytuje); v tu chvíli může dojít pouze k autentizaci. Kvůli tomu jsou různá místa v USB stacku změněna, aby kontrolovala příznak authorized, než povolí přístup.

Uživatelský prostor je do obrazu uveden pomocí obvyklého oznámení o připojení zařízení a vytvoření příslušného sysfs stromu. Sysfs adresáře jednotlivých USB zařízení mají nový atribut authorized, který odpovídá internímu příznaku; uživatelský prostor může povolit přístup k zařízení zapsáním nenulové hodnoty do atributu. Taková infrastruktura postačuje k tomu, aby si mohl nějaký uživatelský démon všimnout nového bezdrátového USB zařízení, projít databázi známých zařízení a případně uživateli předhodit dialogové okno - a rozhodnout se, jestli by mělo být zařízení povoleno se připojit nebo ne.

Iñaky posunul věci ještě o krok dál, když si uvědomil, že tento autorizační mechanismus nemusí být omezen jen na bezdrátová zařízení; ve skutečnosti může být využit k tomu, aby se nějakému správcovskému kódu umožnilo rozhodovat o kterémkoliv USB zařízení. Administrátor může nakonfigurovat sadu příznaků authorized_default; pokud se prostě nastaví výchozí hodnota na nulu, bude zamítnuto připojení všech nových zařízení, ať už bezdrátových nebo jiných.

Komplexnější implementace by mohla povolovat připojení jen některým druhům zařízení. Klávesnice a myši by mohly být přijatelné, ale cokoliv, co by mohlo ze systému brát data - třeba úložná zařízení nebo tiskárny - by bylo zakázáno. Nebo by mohla být úložná zařízení povolena, ale pouze za předpokladu, že by obsahovala nějaký řádně podepsaný certifikát, který by hostitelský systém ověřil. Existuje množství zajímavých možností. Výsledné zabezpečení nebude tak odolné jako ucpané porty nebo úplné odstranění podpory USB, ale mohlo by to být právě to, co je na některých místech potřeba.

Je to poměrně jednoduchá sada patchů, která přidává zajímavé možnosti. Zbývá ještě dodělat hodně té obtížné práce - autentizaci a šifrování - ale to je práce pro uživatelský prostor. Iñaky požádal o začlenění do 2.6.23; pro v podstatě netestovaný kód je však trošku pozdě. 2.6.24 se zdá pravděpodobnější.

Další pokus o software suspend

V roce 2006 probíhala živá debata o budoucnosti softwarového uspávání (na disk) - a pokračuje až do dnes. Andrew Morton do toho tenkrát skočil s návrhem na jiný přístup:

Pokud chcete můj vesele neinformovaný názor, tak já myslím, že bychom je měli všechny vyhodit a implementovat suspend3, který by byl založen na infrastruktuře kexec/kdump. Máme tu tolik duplicitní práce, až to už ani není vtipné. A když jsou takhle oddělené, tak to oba přístupy zeslabuje tam, kde jsou opravdové problémy: v oblasti ovladačů.

O 18 měsíců později to vypadá, že bychom přeci jen mohli mít "suspend3" - Ying Huang poslal patch kexec jump.

Yingův patch staví na existující funkci kdump. Účelem kdump je poskytnout bezpečné a užitečné crash dumpy [výpisy informací o pádu] v situacích, kdy je stav systému nejistý. Pokud systém zpanikaří, je fajn mít možnost uložit aktuální stav pro posmrtné debugování. Je však důležité, aby chybující jádro, kterému se v tu chvíli nedá věřit, nebylo používáno k provádění nebezpečných věcí - třeba zapisování crash dumpu na disk. Aby se tomu předešlo, vloží se do rezervované oblasti paměti malé "dump jádro", kde většinu času vyčkává, aniž by si ho někdo všímal nebo bylo potřeba. Dojde-li k panice, provede se volání kexec(), které převede kontrolu na dump jádro. Dokud zůstává dump jádro v rezervované oblasti paměti, bude schopno zapsat zbytek systémového stavu na disk (nebo jinam) poměrně bezpečně.

Minulý rok si Andrew všiml, že suspend-to-disk (které se pomalu přejmenovává na hibernaci) dělá v podstatě totéž: je zastavena činnost systému a aktuální stav je zapsán na disk. Pokud by dump jádro mohlo načíst stav zpět do paměti a vrátit kontrolu původnímu jádru, mohlo by hibernovat (a probudit) systém. Implementace v tomto duchu by měla výhodu ve sjednocení většiny kódu kdump a hibernace, což by umožnilo koncentraci vývojářského úsilí a obecné zjednodušení. Navíc by pak bylo možné odstranit současný kód, který není zrovna moc oblíben - navzdory mnohaletému pobytu v jádře.

Aktuální kód zatím tohle všechno neumí; je to jen první krok: umožňuje skok na původní jádro. Kód je poměrně jednoduchý; ačkoliv spoléhá na většinu existující infrastruktury, aby mohl řádně uspat a vypnout všechna zařízení při přípravě ke skoku oběma směry. Takže pokud ovladač zařízení nespolupracuje s hibernací, problém bude přetrvávat i v implementaci pomocí kexec. Ale spousta dalšího hibernačního kódu, včetně pomlouvaného zmrazovače procesů, by už nebyla potřeba a mohla by být odstraněna.

Než se však vezme kudla na stávající hibernační kód, je potřeba dořešit několik detailů. Vypínání zařízení při přechodu mezi těmi dvěma jádry není vlastně nutné ani žádoucí; musí být pouze v tichém "hibernačním" stavu. Kdump jádro musí být umístěno v rezervované oblasti paměti od počátku; snažit se ho natáhnout v okamžiku paniky už by bylo příliš pozdě. Jádro používané pro hibernaci však nemusí být v paměti celou dobu, takže je potřeba nějaký systém, který umožnil vyžádat natažení sekundárního jádra. Vlastní ukládání a obnovování obrazu systému ještě není implementováno - to se však dá snadno udělat v uživatelském prostoru, aniž by bylo potřeba podpory ze strany jádra. Dá však práci dostatečně zrychlit proces obnovy - uživatelům by se asi nelíbilo čekat, až nabootují dvě jádra, než budou moci používat svůj systém. A tak dále.

Jinými slovy, kexec hibernaci nečekejte nijak brzy. Počáteční reakce na tento přístup byly příznivé; zdá se, že se hodně lidem líbí představa nového začátku v této oblasti. Něco z tohoto odhodlání možná vyprchá časem, až se ukáže, že i s novým přístupem je hibernace složitý a poněkud obskurní problém. Jen čas ukáže, jestli z tohoto kódu vzejde lepší implementace.

---

Co s novinkami z kerneltrap.org?

Vzhledem k tomu, že Jeremy na kerneltrap.org zjevně chytil nějaký druhý dech a rozjel vydávání článků v míře dosud (nebo alespoň za poslední dva roky) nevídané, tak už jich je pro přidávání do Jaderných novin moc. Mnohé z nich jsou sice o věcech, které už byly v LWN (a tedy i v JN) popisovány podrobněji, ale i tak zůstává v průměru skoro jeden článek na den, což už by jednotlivé díly JN neúnosně natáhlo. (Shodou okolností jsem si to uvědomil jen pár dní po té, co jsem v diskuzi prohlásil, že všechny články z kerneltrap.org do JN dávám...)

Proto vkládám do tohoto článku anketu, ve které vás nechám rozhodnout, jak s tím přívalem novinek v Jaderných novinách zacházet.

Anketa

Související články

Jaderné noviny - 11. 7. 2007
Jaderné noviny - 4. 7. 2007
Jaderné noviny - OLS: tři přednášky o správě napájení
Jaderné noviny - 27. 6. 2007

Odkazy a zdroje

Kernel coverage at LWN.net: July 18, 2007

Další články z této rubriky

Jaderné noviny – přehled za březen 2024
Jaderné noviny – přehled za únor 2024
Jaderné noviny – přehled za leden 2024
Jaderné noviny – přehled za prosinec 2023
Jaderné noviny – přehled za listopad 2023

Diskuse k tomuto článku

[b42]

process freezer bude spise neco jako zmrazovac procesu nez konkretni proces s nazvem freezer

[Jan Včelák]

Jádro kódu sysfs bylo dost předěláno, aby se zeslabilo spojení mezi sysfs a interními kobjekty. Nový kód by měl usnadnit práci autorům ovladačů, kteří už se nebudou muset starat o tolik problémů s životností objektů.

Původně jsem si myslel, že k jako kernel a proto kobjekty, ale asi to bude překlep, protože v druhé větě to nění.

[michich]

To nebude překlep. Adresáře v sysfs odpovídají objektům typu struct kobject.

[Käyttäjä 11133]

Kernel virtual machine (KVM) ted podporuje SMP hosty.

[e.lisak]

demolátory Afatech AF9005

nemelo by byt spise demodulátory ?

[melkors]

Taky me to trosku zarazilo - takovy demolator by spis mel demolovat

[Robert Krátký]

Díky, opraveno (i ostatní chybky zmíněné v komentářích).

[trekker.dk]

které by nám umožnily, více či méně evolučním způsobem, vylepšit stávající systémy

Nejsou tam ty čárky navíc? Nevím, jak to vypadalo v anglickém originálu, ale v češtině se mi to nezdá jako vložená věta.

[Robert Krátký]

Vložená věta to určitě není, ale podle mě jde o volný přívlastek, takže by čárkami oddělen být měl.

[David Jaša]

Není to spíš příslovečné určení? (Jak umožnily vylepšit? Více či méně evolučním způsobem.)

[Robert Krátký]

Jasně... plácám.

[Filip Jirsák]

Podle mne to není věta, ale větný člen (příslovečné určení), v tomto případě volný, takže se píše s čárkami. Sice jsem o volném příslovečném určení nikdy neslyšel, ale myslím, že pravidlo "dává-li věta 'stejný' smysl i bez větného členu, jde o větný člen volný psaný s čárkami" tu funguje taky.

[Filip Jirsák]

Tak podle mluvnice existuje volný a těsný akorát přívlastek. Ptal jsem se i jedné bývalé jazykové redaktorky, napsala by to bez čárek. Mně osobně připadá, že čárky tu větu zpřehlední, ale nenašel jsem žádnou mluvnickou kategorii, která by použití čárek ospravedlnila. Ale v tomto případě je to snad srozumitelné s čárkami i bez

[Hynek (Pichi) Vychodil]

a co vsuvka?

[Ondrej 'SanTiago' Zajicek]

Zrejme jde o omyl uz v originalnim textu, ale speedstep-centrino AFAIK se neodstranuje a neni nahrazen acpi-cpufreq. Pouze se z speedstep-centrino odstranuje kus implementace, ktery pouziva ACPI (protoze v kombinaci s ACPI je mozne pouzit acpi-cpufreq). speedstep-centrino je mozne pouzivat i bez ACPI a tato cast funkcionality zustava.

Viz feature-removal-schedule.txt :

What:   ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
When:   December 2006
Why:    Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
        functionally very much similar. They talk to ACPI in same way. Only
        difference between them is the way they do frequency transitions.
        One uses MSRs and the other one uses IO ports. Functionaliy of
        speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
        That means one common driver will support all Intel Enhanced Speedstep
        capable CPUs. That means less confusion over name of
        speedstep-centrino driver (with that driver supposed to be used on
        non-centrino platforms). That means less duplication of code and
        less maintenance effort and no possibility of these two drivers
        going out of sync.
        Current users of speedstep_centrino with ACPI hooks are requested to
        switch over to acpi-cpufreq driver. speedstep-centrino will continue
        to work using older non-ACPI static table based scheme even after this
        date.

Who:    Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

[disorder]

tak to bol asi bug, ked sa mi s upgrade kernelu speedstep_centrino odmietol loadnut?

[Ondrej 'SanTiago' Zajicek]

Nevim, bud to byl bug, anebo na tvem systemu speedstep-centrino vyzadoval tu ACPI cestu, ktera z nej byla odstranena.

[disorder]

nenasiel hardware :) vie to este niekto potvrdit pre core 2 duo?

[Robert Krátký]

Jak tak zkoumám materiály na kerneltrap.org a lwn.net, tak si začínám uvědomovat, že jsem anketu v článku navrhl dost blbě. Možnost, která teď vyhrává, totiž není zrovna moc reálná. Jeremy toho na kerneltrap v tuto chvíli vydává tolik, že i kdybych vynechával občasné duplicity z LWN, stejně by toho bylo příliš moc; na kerneltrap je teď tolik článků, že by to úplně stačilo na celé JN. Což by nebylo nic špatného, ale bylo by mi líto úplně zahodit LWN - články odtud jsou IMHO přinejmenším stejně zajímavé - často spíš více.

Vidím to tak, že bude nutné materiál z kerneltrap dost prosívat. Mohl bych upravit poměr LWN - kerneltrap více ve prospěch kerneltrap, ale i tak bude potřeba vybírat.

[andree]

no a o tom som hovoril v blogu minule ze je to ho dost... kludne by som to prekladal aj raz za par dni, to zase take hrozne nie je - ale neviem ako by ludia neslovenskej narodnosti zvladali citanie prekladov.. hadam ze poniektori by uz skor prekusli anglicku originalnu verziu

[Robert Krátký]

no a o tom som hovoril v blogu minule ze je to ho dost...

Ono to začalo dost nečekaně. Já kerneltrap sleduji se stejným odstupem, s jakým vycházejí JN - když se podíváš trošku zpátky, tak je vidět, že Jeremy vydával sotva dva články týdně. Proto jsem (tehdy) psal, že není problém je dávat do JN všechny.

neviem ako by ludia neslovenskej narodnosti zvladali citanie prekladov

S tím bych si hlavu nedělal. Články ve slovenštině na abclinuxu normálně vycházejí.

Pokud máš opravdu zájem s překladem pomoci, kontaktuj mě prosím emailem a dohodneme se na podrobnostech.

[andree]

ale to potom pridem o skore co uz, shit happens... :o)

[Käyttäjä 11133]

O jaké skore? Pokud budeš překlady vydávat jako články tak právě naopak příjdeš mimo jiné i ke skóre

[andree]

ale nie ak ich bude vydavat Robert pod hlavickou JN... ;o)

[Robert Krátký]

Tak budeme uvedeni jako "autoři" (v tomto případě překladatelé) oba, neboj

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.