abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 8
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 206 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy

    14. 4. 2014 | Luboš Doležel | Jaderné noviny | 3684×

    Aktuální verze jádra: 3.14-rc8. Různé problémy s cachí stránek: Velké disky na 32bitových systémech; Velké stránky v cache stránek; Větší bloky na systémech souborů.

    Obsah

    Aktuální verze jádra: 3.14-rc8

    link

    Aktuální vývojová verze jádra je 3.14-rc8 vydaná 24. března. Linus k ní řekl: Oproti mému běžnému plánu mám den zpoždění, doufal jsem, že to nakonec bude vypadat na verzi 3.14, ale nevyšlo to. Proto tu máme rc8 a vidím to na konečné 3.14 přiští víkend.

    Stabilní aktualizace: verze 3.13.7, 3.10.34 a 3.4.84 vyšly 23. března; verze 3.12.15 vyšla 26. března.

    Různé problémy s cachí stránek

    link

    Cache stránek je na Linuxu pověřena správou cachí bloků dat z persistentních úložných zařízení; jde o zásadní součást jak virtuálního systému souborů, tak subsystémů správy paměti. Cache stránek je klíčem k výkonu systému jako celku. Bohužel už v řadě směrů začíná vykazovat své stáří. První technická debata na Linuxovém sumitu pro úložiště, systémy souborů a správu paměti 2014 se zaměřila na řadu problémů s cachí stránek a ukázala přibližnou cestu k jejich řešení.

    Velké disky na 32bitových systémech

    link

    Jedním z hrozících problémů, který představil James Bottomley, je, že na 32bitových systémech nemůže cache stránek pracovat s disky většími než 16 TB. Cache stránek používá nativní velikost stránky (4 KB) k adresaci bloků na zařízení; s 32bitovými indexy bloků končí schopnost adresace na 16 TB. James kladl tyto otázky: je třeba tento problém na 32 bitech řešit a pokud ano, tak jak to udělat?

    Řada vývojářů to jednoznačně vnímala tak, že tento problém není nutné řešit. Vnímají 32bitové systémy jako systémy, co jsou už na odchodu; kdokoliv, kdo chce používat velká úložná zařízení, by si měl pořídit 64bitový systém. Ve skutečném světě to ale nemusí být tak snadné. 32bitová zařízení tu s námi ještě nějakou dobu budou, hlavně v říši embedded zařízení. Lidé si pořídí 16TB USB disky a budou očekávat, že poběží. Jiní umístí 32bitový procesor do laciného NAS a budou tam chtít dát velké disky. Navíc tu máme výrobce, kteří dávají 32bitové procesory přímo do disků, aby tak doplnili protokoly jako iSCSI.

    Dave Chinner poukázal na to, že jádro problému se skrývá v samotné cache stránek. Pokud dělá aplikace přímé I/O (čímž je obcházena cache stránek), pak žádné problémy nejsou. Pokazí se to až jakmile se uživatelský prostor pokusí o bufferované I/O na velkém disku. K tomu dojde při používání systémů souborů, ale i před tím: udev například používá bufferované I/O při mapování disků. A je tu ještě jeden drobný problém: i kdyby bylo možné 16TB systém souborů připojit a používat na 32bitovém systému, tak stále nebude dostatek adresního prostoru pro běh kontroly systému souborů. Tento problém se zdá na těchto systémech být neřešitelným. Jinými slovy, i když opravíme jádro, tak zbytek ekosystému bude zkrátka rozbitý.

    Tyto informace více méně vedly ke shodě. Nikdo se nebude snažit o podporu větších systémů souborů na 32bitových systémech. Ale přímé I/O bude na velkých discích fungovat a bude nadále podporováno. Takže situace, které závisí jen na přímém I/O – například v případě iSCSI – budou na 32bitových systémech fungovat. V ostatních případech bude nutné si pořídit 64bitové CPU.

    Velké stránky v cache stránek

    link

    Dave spolus s Christophem Lameterem pak přešli na další téma: ukládání větších bloků dat v cache stránek. Ukázalo se, že o to usilují z odlišných důvodů, což je vede k odlišným řešením. Může být možné vyřešit oba problémy, ale jedno z řešení bude pravděpodobně hotové dříve než to druhé.

    Christoph má obavy z režie operačního systému na všech úrovních; součástí jeho řešení je podpora větších fyzických disků v cache stránek. Větší fyzické stránky by snížily režii správy v jádře a objem práce spojený se sestavováním a úklidem [setup and teardown] při I/O operacích nad těmito stránkami. K velikostem v cachi stránek je možné přiřazovat atribut „řazení“, což umožní uložení odlišně velkých stránek, ale skrývá se tu obvyklý problém: udržení schopnosti doopravdy alokovat větší fyzické stránky poté, co systém už nějakou dobu běží.

    Podle Christopha je řešením udržovat si rezervu v podobě velkých stránek jen pro tento účel, ale to je „divné“ a obtížné správně vyladit. Jiným řešením je pak umožnit jádru přesouvat stránky, defragmentovat tedy za běhu. Většina nutné podpory už existuje; subsystém správy paměti má schopnost migrovat stránky a tato schopnost se používá v kódu pro kompakci stránek z účelem defragmentace paměti. Problém je v tom, že ne všechny stránky se dají přesouvat; jde o velkou překážku, jelikož na rozbití jedné velké fyzické stránky stačí jediná nepřesunutelná stránka.

    Existuje řada důvodů, proč nemusí být možné přesunout konkrétní stránku, ale jedním z nejzávažnějších příčin je alokace objektů v jádře. Kdyby objekty získané ze slab alokátoru byly přesunutelné, tak by problém zmizel. Christoph má patche, které tuto funkčnost přidají do některých intenzivně používaných cachí (kupříkladu do inode cache), ale ještě nebyly začleněny. Proti tomuto nápadu se objevil odpor; jádro je plné ukazatelů na objekty; žádný objekt nelze přesunout, leda by bylo možné všechny tyto ukazatele změnit bez zanesení race condition. Christoph trval na tom, že většinu obtíží lze zažehnat změnmi v několika důležitých datových strukturách.

    I tak to ale nemusí vše zafungovat tak, jak by se Christophovi líbilo. Mel Groman řekl, že i na současných systémech, kde probíhá snaha o oddělení přesunutelných a nepřesunutelných stránek, se ukazuje, že překvapivě hodně „přesunutelné“ paměti zkrátka neexistuje. Stránky tabulky stránek mohou představovat velkou část paměti a nejde je přesunout; patch, který to napravoval, přidával 5-6% režii, a proto nebyl začleněn. Jiné stránky jsou údajně přesunutelné, ale jsou zablokovány pro přímé I/O nebo jinak drženy na místě v paměti; i kdyby tomu bylo věnováno velké úsilí, tak by mohla být migrace stránek obtížná. Prozatím je pro většinu uživatelů hlavním symptomem to, že alokace transparentních velkých stránek selže; to není velký problém. Pokud bychom ale podle Mela došli do fáze, že opravdu závisíme na schopnosti přesouvat stránky, „tak se nám to šeredně vymstí“.

    Větší bloky na systémech souborů

    link

    Dave se zeptal na odlišnou, ale příbuznou otázku. Zajímala ho lepší podpora systémů souborů s bloky většími než je velikost stránky v systému. Podpora větších fyzicky souvislých stránek v cache stránek by v tomto ohledu mohla pomoci a tento přístup nabízí jisté výhody, hlavně díky tomu, že pro jeho podporu nejsou v kódu systémů souborů nutné téměř žádné změny. To samé se ale nedá říct o subsystému pro správu paměti, kde by to s rozsahem změn bylo závažnější. Než abychom na to hned skočili, bychom podle něj měli zvážit, zda musíme problém opravdu řešit takto.

    Jedním z popudů pro větší fyzické stránky byla omezení v zásobníku blokového I/O; maximální velikost jediného I/O požadavku byla po dlouhou dobu příliš nízká na to, abychom z vysokorychlostních úložišť získali maximální výkon. Zvýšení velikosti stránek by tento limit posunulo dále, což by umožnilo přenést více dat se stejným počtem stránek a problém by byl vyřešen. Ale omezení velikosti požadavků už bylo vyřešeno, takže není takový tlak na řešení problému s velikostí stránek. Skutečným problémem je tedy podle něj to, že cache stránek ví o velikosti bloků používaném na každém systému souborů. Končí to tak, že sleduje hodně údajů z úrovně systému souborů, čímž se duplikují údaje uložené na systémech souborů. Tato duplikace vede k problémům s koherencí a občasným ošklivým chybám; je to také zdroj toho omezení, že bloky systému souborů nemohou být větší než systémová velikost stránky.

    Nick Piggin se pokusil tento problém vyřešit už před lety svou prací na fsblock. Problém s tímto patchem je ten, že vyžaduje rozsáhlé změny ve všech systémech souborů. I ext2, který byl Nickem upraven na ukázku, potřeboval změn opravdu hodně. Proto Dave hledal jiné řešení. Ve zkratce by byl rád, kdyby cache stránek přestala udržovat mapování mezi stránkami a bloky systému souborů. Vše ostatní je už v systému souborů známo; odstranění tohoto sledování z cache stránek by mohlo umožnit odstranit omezení velikosti bloků.

    Tato práce by rovněž umožnila eliminovat používání hlaviček bufferů [buffer heads] pro sledování bloků. Vývojářům systémů souborů se s nimi těžko pracuje; navíc jen s malým užitkem přidávají hodně režie. Mapování stránek na bloky se mnohem lépe řeší na základě informací pro sledování extentů, které už v kódu systému souborů jsou. Cache stránek by se musela starat jen o to, jestli je daná stránka aktuální s ohledem na zapsaný permanentní stav; vše ostatní se může snáze a spolehlivěji řešit jinde.

    Christoph se ozval s tím, že chce, aby cache stránek vyšší úrovně snížila režii aplikací, hlavně okolo I/O požadavků; řešení na úrovni systémů souborů popisované Davem podle něj tento problém neřeší. Martin Peterson poukázal na to, že menší granularita I/O může být stejně vynucena hostitelskými adaptéry, ale Christoph řekl, že používá high-end hardware a tímto tedy netrpí. Dave za souhlasu ostatních prohlásil, že tu popisujeme dva odlišné problémy a že ve každém případě je nejprve potřeba vyřešit velké bloky systémů souborů.

    Vyskytly se také obavy z interakce mezi formátem binárek ELF, který má v sobě jisté předpoklady o zarovnání, a velkými bloky systému souborů. Vypadá to ale, že v této oblasti žádné problémy nejsou, hlavně jakmile se člověk zbaví 32bitových systémů.

    Na konci debaty se zdálo, že panuje shoda, že by Dave měl dále dělat na přesunu povědomí o systému souborů pryč z cache stránek. Podle něj jde o překvapivě malou změnu, ale stále o opravdu hodně práce. Změny budou volitelné; nikdo neočekává, že celá ta spousta starých systémů souborů na Linuxu bude aktualizována, a současně je nutné, aby dál fungovaly. Vyskytly se obavy o to, kolik práce by se dotklo obecného kódu pro systémy souborů; nikdo nechce vidět duplicitní implementace nakopírované do jednotlivých systémů souborů.

    Mezitím byl Christoph přizván k tomu, aby pracoval na podpoře větších fyzicky souvislých stránek v cache stránek. Bylo ale rozhodnuto, že se musí jednat o příznak pro alokátor; funkčnost systému nemůže záviset na úspěšnosti alokace. V obou případech bude prvním krokem zaslání kódu k revizi.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    14.4.2014 08:37 mmmm
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Možná už se to tu někdy řešilo, ale proč jsou tyto články publikovány s tak velkým zpožděním oproti originálům. Přesto díky.
    14.4.2014 09:31 anonym
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    A) preklad neco trva

    B) pristup k aktualnimu LWN je placeny, archiv davaji zdarma
    14.4.2014 15:21 registrovaný
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Jemonže překlad trval skoro dva týdny od uvolnění v archivu.

    Takže si, anonyme, tazateli vůbec nic nevysvětlil.
    14.4.2014 11:57 2X4B-523P | skóre: 38 | blog: Zelezo_vs_Debian
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    je to hlavně pro neanglicky mluvící a líné uživatele... admini, kteří pravidelně aktualizují si čtou změny přímo a zavčas...
    14.4.2014 15:36 registrovaný
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Ale stejně ty překlady trvají neskutečně dlouho.

    pavlix avatar 14.4.2014 15:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    A?
    14.4.2014 21:24 nnnn
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Hurá, náš malý Pavlix se dnes ve školce naučil písmeno A a otazník !
    14.4.2014 21:30 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Ak sa ti nepaci, mozes robit preklady rychlejsie.
    Saljack avatar 14.4.2014 13:02 Saljack | skóre: 28 | blog: Saljack | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Myslím, že žádný problém neexistuje. Proč by někdo chtěl používat 32bitový systém s tak velkým diskem?
    Sex, Drugs & Rock´n Roll.
    14.4.2014 21:29 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Pretoze ma zariadenie s 32-bitovym CPU a potrebuje skopirovat nejake data z 16TB disku, ktore sa mozno coskoro budu predavat s USB rozhranim?
    Jendа avatar 14.4.2014 22:04 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Protože je embedded 32b SoC šíleně levný a málo žere.
    14.4.2014 13:33 Milan Roubal | skóre: 25
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Kde presne lezi to omezeni? Mam system Synology DS413j, procesor Marvell Kirkwood mv6282 armv5te, coz je podle vseho 32bitovy system a uvazuji o update disku v tomto roce. Jsou tu 3 varianty:
    1. 4x 4TB disk - pri RAID5 a ext4 by nemel byt zadny problem
    2. 4x 5TB disk - pri RAID5 ma disk 15TB, tedy s ext4 to bude fungovat?
    3. 4x 6TB disk - pri RAID5 ma disk 18TB, tedy bude s tim problem? Pokud ano, bude fungovat 2x RAID5, jeden s velikosti 16 TB a druhy 2 TB?
    14.4.2014 14:00 MalyZelenyHnus | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Problem je v jakemkoliv blokovem zarizeni >16TiB. (Testovano shodou okolnosti na jadre 2.6.31, Marvell Feroceon 6282): 1) zadny problem 2) zadny problem (vsechna blokova zarizeni <16TiB) 3) jo, to je problem. Ext4 ma rozumne nastroje, ktere ti a) zabrani vytvoreni fs, ktery neni mozne adresovat 32 bity, b) pri pouziti 64bit rozsireni ext4 to na 32bitu sice naformatujes, ale nejde primountovat. MDRAID je jeste veselejsi - dovoli ti pole vytvorit i sestavit a tvari se korektne. Ale kdyz jsem tam zapisoval pomoci dd, po chvili se zapisovana data zacala proste ztracet (tj. write() tvrdil ze zapsal, na disky se skrz mdraid vrstvu nic nedostalo).

    Dve samostatna pole 16TiB a 2TiB fungovat budou, dokonce muzes udelat na discich dve partysny a do jednoho pole dat prvni partysny, do druheho zbyle. Tusim ze neco podobneho pouziva i QNAP.
    Didaktik M - brána do světa profesionálních počítačů
    14.4.2014 18:08 j
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Ja bych dokonce rek, ze lze i varianta dat to vse do jednoho raidu ... a rozdelit to na vic partysen. A dokonce by to pak mozna slo sfouknout tak, ze se to pro system bude jevit jako vic mensich disku, ale navenek jako jeden velkej.

    Ale takovou R5tku bych nechtel prepocitavat ani na HW raidu, natoz na SW.
    14.4.2014 18:55 MalyZelenyHnus | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Samozrejme, jeden velky raid + partysny na nem nepomuze, zase by tam bylo zarizeni >16TB.

    Ja jsem navrhoval nejdriv udelat partysny na discich a nad partysnama udelat vice RAIDovych poli. Oproti reseni "dva disky pro jedno pole, dva disky pro druhe" to nezmensi pocet zarizeni v poli, takze se muze pouzit i raid5/6/10, ktere pozaduji vic disku.

    Jeste jsem delal pokusy s aufs, ale pro ten stary (2.6.31) kernel to melo nejake bugy. Aufs (a existuje vic podobnych filesystemu) je filesystem, ktery nepracuje nad jednim blokovym zarizenim, ale nad nekolika a rozhazuje mezi nimi soubory podle ruznych nastaveni. Nevytvari teda velke blokove zarizeni, ale presto poskytuje sluzby jednoho souboroveho systemu. Takze komu staci jeden velky filesystem, muze vzit dve nebo vic disku (raidu) <16TB a vytvorit na nem jeden fs takhle. Zkusenosti s provozem ale nemam a moc bych tomu neveril.
    Didaktik M - brána do světa profesionálních počítačů
    14.4.2014 23:54 Kvakor
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Ještě je tu možnost použit distribuovaný souborový systém, i když poběží na jediném stroji. Celková velikost klidně může být >16TB, stačí jen aby jednotlivá zařízení byla menší. Nevýhodou by byl poněku nižší výkon, ale pokud se opravdu jedná o něco na způsob NAS, tak to pravděpodobně nebude zas tak velký problém (protože úzké hrdlo bude ve většině případů síť). Možná by dokonce stačilo použít jen "RAID" vlastnosti Btrfs (rozložení přes víc blokových zařízení), ale nejsem si jistý, jak přesně je to řešeno uvnitř.
    15.4.2014 13:17 Milan Roubal | skóre: 25
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Presne tak jsem to myslel, udelat nekolik poli pres 4 disky vzdy nad partition. Prepocitavani RAIDu se nebojim, s tim spatne zkusenosti nemam, spise se bojim e2fsck nad jednim velkym diskem, protoze ta masina na to nema dost pameti.
    15.4.2014 22:54 Kvakor
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    To jde obejít tak, že se buď celý souborový systém (nebo jednolivé oddíly) vyexportuje jako blokové zařízení (NBD nebo iSCSI) a zfscká se ze stroje, který má paměti dost. Jen to bude nejspíš trvat pekelně dlouho ...
    15.4.2014 11:38 Honz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    Cachí je krásné slovo...
    15.4.2014 14:41 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy
    se zaměřila na řasu problémů zní taky půvabně :)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.