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í
×
22.11. 22:30 | Zajímavý projekt
Steve Chamberlin představil (YouTube) svůj malý počítač s Linuxem, jenž pojmenoval 68 Katy. Jádrem počítače postaveného na nepájivém poli (breadboard) je procesor Motorola 68008. [Slashdot]
Ladislav Hagara | Komentářů: 4
21.11. 08:57 | Zajímavý článek
Na titulnej stránke slashdotu dnes nájdete aj správičku o Vojtěchovi Pavlíkovi. Patrí mu uznanie za vedúcu rolu v SUSE Labs a projekty, ako sú kGraft (patchovanie jadra za behu) a bootovanie počítačov zamknutých pomocou secure boot. Pôvodný článok o Vojtěchovi Pavlíkovi nájdete na IT Wire. Gratulujeme.
rastos | Komentářů: 20
20.11. 10:54 | Komunita
Počínaje prosincem bude v některých zemích provedena změna na pozici výchozího vyhledávače ve Firefoxu. V USA bude nově výchozím vyhledávačem Yahoo a v rámci nové pětileté dohody bude podporovat technologii Do Not Track. V Rusku se stane výchozím vyhledávačem Yandex. V Číně bude jako výchozí pokračovat Baidu. Ostatní vyhledávače jako Google či Bing budou v nabídce i nadále. Mozilla mění strategii. Místo jedné globální smlouvy na výchozí … více »
Ladislav Hagara | Komentářů: 23
19.11. 19:34 | Zajímavý projekt
Společnost Jolla spustila na Indiegogo kampaň na podporu svého tabletu. Cílová částka 380 tisíc dolarů byla vybrána za něco málo přes 2 hodiny. V době zveřejnění zprávičky bylo vybráno přes 700 tisíc dolarů. Jolla Tablet s operačním systémem Sailfish OS 2.0, displejem o velikosti 7,85 palce a rozlišení 2048x1536, lze aktuálně koupit za 204 dolarů. Předpokládaná cena po kampani je 249 dolarů.
Ladislav Hagara | Komentářů: 44
19.11. 12:33 | Zajímavý článek
Debian zveřejnil výsledky hlasování o způsobu integrace init systémů v Debianu. V hlasování zvítězila možnost označovaná jako "General Resolution is not required".… více »
Ondřej Surý | Komentářů: 145
19.11. 10:22 | Zajímavý článek
WhatsApp, proprietární aplikace rychlých zpráv pro chytré telefony, která má více než 70 milionů aktivních uživatelů (z celkového počtu 700 milionů registrovaných), zavedla silné šifrování end-to-end. Vyvinul a nasadil je pro ni Moxie Marlinspike, známý bezpečnostní expert a aktivista, který stojí za TextSecure a WhisperPush (implementací TextSecure protokolu v CyanogenModu). Jedná se o implementaci Axolotl Ratchet (vylepšené OTR).
xm | Komentářů: 20
19.11. 04:04 | Zajímavý projekt
Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, IdenTrust a University of Michigan představují projekt Let’s Encrypt. Jedná se o projekt otevřené certifikační autority, jež bude od léta 2015 nabízet certifikáty pro servery rychle, bezpečně, transparentně a zadarmo. Pro správu certifikátů a automatické nastavování serverů je vyvíjen klientský software. Videoukázka na YouTube. Technické detaily na stránkách projektu. Popis použitého protokolu ACME (Automated Certificate Management Environment) na GitHubu. [Slashdot]
Ladislav Hagara | Komentářů: 47
19.11. 01:01 | Zajímavý článek
Bylo uvolněno první číslo časopisu Linux Voice z letošního dubna. K dispozici je jak jedno velké PDF o 116 stranách (61 MB), tak PDF nebo HTML verze jednotlivých článků. K některým z článků je k dispozici také jejich audio verze (OGG, MP3). Linux Voice je anglicky psaný "papírový" časopis. Po úspěšné kampani na Indiegogo bylo vydáno již 9 čísel. Jedno číslo vyjde na cca 330,- Kč, roční předplatné na cca 3000,- Kč. Polovina zisku časopisu se vrací komunitě. Jednotlivá čísla časopisu jsou po 9 měsících od vydání uvolněna pod licencí CC-BY-SA.
Ladislav Hagara | Komentářů: 0
18.11. 17:19 | Pozvánky
Spolek OpenAlt zve na 110. sraz příznivců open source, který proběhne v pátek 21. listopadu od 18:00 v Brně U Bílého beránka (Štefánikova 85/16) a v Praze v restauraci Lokalblok (Náměstí 14. října 10, Praha 5).
Ladislav Hagara | Komentářů: 0
17.11. 18:19 | Nasazení Linuxu
Byl aktualizován seznam 500 nejrychlejších superpočítačů na světě TOP500. Pořadí na prvních devíti místech se od června nezměnilo. Nejrychlejším superpočítačem na světě je již počtvrté čínský Tianhe-2 (MilkyWay-2). Počet superpočítačů v TOP500 bežících na Linuxu zůstal 485. Další přehledy a statistiky na stránkách projektu.
Ladislav Hagara | Komentářů: 4
Disketu jsem naposledy použil během
 (46%)
 (3%)
 (11%)
 (38%)
 (2%)
Celkem 1112 hlasů
 Komentářů: 39, poslední včera 15:25
Rozcestník
Reklama
Autoškola testy online Levný benzín

Jaderné noviny - 26. 4. 2006

9. 5. 2006 | Robert Krátký | Jaderné noviny | 4873×

Aktuální verze jádra: 2.6.16.11. Co nového se splice(). OpenVZ a checkpointing za běhu. Začíná diskuze o AppArmor. vmsplice() versus COW. Komu patří stack?

Aktuální verze jádra: 2.6.16.11

Aktuální verze stabilního jádra je 2.6.16.11. Byla vydána 24. dubna. Jedinou změnou je oprava bezpečnostní chyby v souborvém systému CIFS. 2.6.16.10 byla také vydána 24. dubna, ale obsahovala větší množství důležitých oprav.

Aktuální předverze je 2.6.17-rc2; během minulého týdne nevyšly žádné nové -rc. V hlavním git repozitáři se však shromažďují patche; jde povětšinou o opravy, i když je mezi nimi i Trusted Platform Module (TPM) 1.2, podpora více velikostí stránek pro architekturu PA-RISC a systémové volání vmsplice() (viz níže).

V minulém týdnu nebyly vydány žádné -mm.

Co nového se splice()

Jens Axboe rozeslal mail, ve kterém popisuje stav splice(). Poznamenává, že rozhraní splice() a tee() by měla být - jak ze strany uživatelské, tak ze strany jádra - v současné době stabilní a neočekávají se žádné další změny. Systémové volání sendfile() bylo přepracováno tak, aby využívalo mechanismus splice(), ačkoliv tento proces nebude dokončen před začátkem vývojového cyklu verze 2.6.18.

Přestože je splice() možná stabilní, stále se toho děje dost. Konkrétně jde o další systémové volání, které přidal Jens:

    long vmsplice(int fd, void *buffer, size_t len, unsigned int flags);

Zatímco běžné volání splice() propojí rouru na soubor, toto volání je navrženo tak, aby předávalo paměť z uživatelského prostoru přímo do roury. Takže paměťový rozsah len bajtů začínajících na buffer bude natlačen do roury fd. Parametr flags se zatím nepoužívá.

Pomocí vmsplice() může aplikace generující data v paměťovém bufferu zmiňovaná data odeslat na místo určení bez jakéhokoliv kopírování. Při vhodně nastavené velikosti bufferu může aplikace snadno provádět dvojité bufferování [double-buffering]; polovina bufferu provádí I/O prostřednictvím vmsplice(), zatímco druhá polovina je naplňována. Je-li buffer dostatečně velký, stačí aplikaci volat vmsplice() vždy, když je zaplněna polovina bufferu - ostatní bude fungovat bez potřeby několika vláken nebo komplikovaných synchronizačních mechanismů.

Je však důležité správně nastavit velikost bufferu. Je-li buffer alespoň dvakrát tak velký jako maximální počet stránek, které může jádro do roury natáhnout, může být úspěšné provedení vmsplice() na polovině bufferu vyhodnoceno aplikací tak, že ta druhá polovina bufferu už neprovádí I/O. A protože polovina bufferu zcela zaplní dostupný prostor jaderné roury, nemůže být druhá polovina vložena dříve, než budou všechna ostatní data z roury zpracována - alespoň v jednoduchých situacích. Takže když vmsplice() uspěje, může aplikace bezpečně doplnit druhou polovinu novými daty. Podaří-li se však aplikaci zmást, mohlo by se stát, že by začala přepisovat data, která ještě jádro nezpracovalo.

Jensův patch přidává pár fcntl() operací, které by v této otázce měly pomoci. Operace F_GETPSZ vrátí maximální počet stránek, které mohou být vloženy do bufferu roury, což je zároveň maximální počet stránek, na kterých může operace vmsplice() provádět I/O. Další je F_SETPSZ pro změnu maximální velikosti - i když tato operace zatím vrací jen EINVAL. Linus má však obavy, že tyto informace nestačí k tomu, abychom věděli, že s danou stránkou už není prováděn I/O. V situacích, kdy jsou v jádře další buffery - třeba jen další roura v řadě - by mohlo mít jádro pořád odkazy na stránku, i když už by byla z původní roury zpracována. A síťování přidává další problémy: je-li stránka "vmsplicována" na TCP socket, nebude znovu použitelná, dokud vzdálený počítač nepotvrdí přijetí dat, která obsahovala. Toto potvrzení přijde dlouho poté, co byla stránka zpracována z bufferu roury.

Z toho všeho vyplývá, že na rozhraní vmsplice() je ještě potřeba trochu zapracovat. Pravděpodobně bude nutné přidat další systémové volání, které aplikaci umožní zjistit, jestli už jádro s danou stránkou skončilo. Současná implementace vmsplice()také neumí napojit příchozí rouru na uživatelskou paměť. Fungování i opačným směrem je dosti komplikovaná záležitost a v brzké budoucnosti se ho asi nedočkáme.

OpenVZ a checkpointing za běhu

Projekt OpenVZ je GPL částí proprietárního produktu Virtuozzo firmy SWSoft. Pomocí OpenVZ může linuxový systém implementovat vícero "virtuálních prostředí", z nichž každé se procesům v něm spuštěným jeví jako samostatný systém. Virtuální prostředí mohou mít své IP adresy a lze je podrobit různým omezením zdrojů. Jinými slovy, jde o implementaci kontejnerového konceptu, jednu z mnoha pro Linux. V poslední době začaly jednotlivé projekty zabývající se virtualizací a kontejnery projevovat větší zájem o začlenění alespoň části svého kódu do hlavního jádra, přičemž OpenVZ není výjimkou. Vývojáři OpenVZ jsou tedy v konferencích o vývoji jádra více vidět.

Projekt OpenVZ nedávno oznámil novou verzi, která přidává jednu zásadní funkci: checkpointing [záznam aktuálního stavu] a migrace virtuálních prostředí za běhu. Stav prostředí (kontejner plný linuxových procesů) může být uložen do souboru a díky tomu později opět nastartován. Ale je také možné vytvořit checkpoint běžícího virtuálního prostředí a přesunout jej bez přerušení provozu na jiný systém. Tato funkce, která chce zjevně konkurovat migračním možnostem Xenu, umožňuje za běhu vyrovnávat zátěž systémů.

OpenVZ patch není při svých 2,2MB pro slabé povahy; cena za tyto funkce je na první pohled zřejmá. Většina obsahu patche už tu byla probrána dříve; obsahuje například patche pro virtualizaci PID - každá součást jádra musí vědět, jestli pracuje se "skutečným" nebo "virtuálním" ID procesu. Bylo potřeba změnit i další rozhraní, aby podporovala virtualizační funkce OpenVZ; např. hodně ovladačů zařízení a souborových systémů vyžadovalo úpravy.

Jak by se dalo očekávat, kód checkpointování je z těch delších a komplikovanějších. Proces checkpointování začne pozastavením cílových procesů způsobem ne nepodobným tomu, co dělá kód software suspend. Pak přijde dlouhá řada rutin, které seřadí a vypíší každou datovou strukturu a kousek paměti spojený s virtuálním prostředím. Jsou uloženy ty zřejmé věci: paměť procesů, otevřené soubory atd. Ale kód musí uložit i kompletní stav každého TCP socketu (včetně seznamu struktur sk_buff, které čekají na zpracování), informace o sledování spojení, stav zpracování signálů, informace o SYSV IPC, popisovače souborů získané přes Unix-domain sockety, asynchronní I/O operace, mapování paměti, jmenné prostory souborových systémů, data v tmpfs souborech, nastavení tty, zámky souborů, popisovače souborů epoll() a další.

Pro každý uložený objekt je nutné vytvořit soubor s jadernou datovou strukturou. Všechny ukládací rutiny pak seřadí jednu nebo více datových struktur do správného formátu pro zápis do checkpoint souboru. Vypadá to, že všechno funguje, ale také to vypadá velmi křehce - téměř jakákoliv změna jaderných datových struktur pravděpodobně způsobí, že checkpointovací a obnovovací kód přestane být funkční. I kdyby byl tento kód začleněn do hlavního jádra, bylo by obtížné jej vývojářům vysvětlovat (a přimět je, aby se o něj zajímali). Udržování ve funkčním stavu je náročné, ať už je kód v jádře nebo ne.

Nemělo by to však být interpretováno tak, že funkce OpenVZ za tu námahu nestojí. Virtuální prostředí, checkpointování a migrace za běhu jsou mocné a užitečné funkce. Ale virtualizace všeho v jádře povede k větší komplexnosti a vyšším nárokům na správu. Bude zajímavé sledovat rozhodování o tom, kde bude stanovena hranice určující, které funkce začlenit, a které už ne.

Začíná diskuze o AppArmor

Novell v lednu oznámil vydání bezpečnostního modulu AppArmor. Pak vše ztichlo; především se nesnažili o začlenění AppArmor do hlavního jádra. Minulý týden však přinesl oživení v reakci na diskuzi o možném odstranění LSM API. Předložení kódu AppArmor mělo požadovaný krátkodobý efekt: diskuze se posunula od odstraňování rozhraní LSM k vlastnostem AppArmor. Vývojáři AppArmor však z toho posunu možná právě teď nebudou zrovna nadšeni.

AppArmor byl podle očekávání dosti kritizován. Za největší neduh je považována skutečnost, že AppArmor používá pro svou bezpečnostní politiku cesty k souborům. Při použití AppArmor může systémový administrátor sestavit seznam souborů, ke kterým má daná aplikace přístup; co není na seznamu, je nepřístupné. Konfigurovatelné jsou i další věci - například možnosti - ale kolem toho žádné neshody nejsou.

Hlavní věc je, že název souboru není soubor samotný. Takže i když /etc/shadow značí soubor se stínovými hesly, ten název není soubor se stínovými hesly. Dokáže-li útočník vytvořit pro tento soubor jiný název (třeba pomocí odkazů nebo jmenných prostorů), mohl by ten jiný název být cestou, po které se útočník k souboru s hesly dostane. Takže přestože AppArmor nepovoluje dané aplikaci přístup k /etc/shadow, může mít ta samá aplikace přístup k jiným názvům souborů, které by mohly ukazovat na stejný soubor.

AppArmor se tedy liší od přístupu SELinuxu, který objektům přiřazuje značky a dodržování pravidel pro přístup zajišťuje na základě těchto značek. V případě SELinuxu má soubor se stínovými hesly stejnou značku (a tím pádem stejná omezení přístupu) bez ohledu na název, přes který je k němu přistupováno. SELinux se tedy vyhýbá selhání (obejití pravidel pomocí jiného názvu souboru), které je u AppArmor možné. Každý administrátor SELinuxu však ví, že udržování značek v aktuálním stavu je samo o sobě dost náročné.

Další problém s přístupem, který využívá AppArmor, je to, že LSM API není pro bezpečnostní politiku založenou na názvech souborů příliš vhodné. Kvůli tomu musí AppArmor často překonávat (potenciálně náročné) překážky, aby zjistil odpovídající názvy souborů. Tento nesoulad mezi AppArmor a LSM není obecně považován za důvod, proč ponechat AppArmor mimo jádro, ale vedl k návrhům, že by vývojáři AppArmor měli buď rozšířit LSM tak, aby podporovalo politiky založené na názvech souborů, nebo by prostě měli poslat své patche a LSM úplně vynechat. Přežije-li AppArmor ostatní námitky, bude určitě potřeba se této otázce věnovat.

V tuto chvíli není zdaleka jasné, jak bude dosaženo rozhodnutí o tom, jestli bude AppArmor začleněn. Nezůstalo bez povšimnutí, že nejtvrdší kritika se ozývá z tábora SELinuxu; vývojář SELinuxu Stephen Smalley tuto kritiku obhajoval takto:

Nebojíme se alternativ. Starosti nám dělá nesprávný technický přístup. Argumenty stavěné proti kontrole přístupu založené na názvech souborů jsou o správnosti technického přístupu, ne o tom, jestli by měly existovat alternativy k SELinuxu.

Příznivci AppArmor tvrdí, že přístup je správný. Na rozdíl od SELinuxu se AppArmor nesnaží být jediným bezpečnostním řešením pro všechny situace. Místo toho prostě odřízne aplikace, které by mohly být útočníkem napadeny. AppArmor se stará o omezení toho, co může nefunkční aplikace dělat; nesnaží se o regulaci interakce všech aplikací a každého objektu v systému. Tento přístup je podle jejich tvrzení dostatečný na to, aby výrazně zvýšil bezpečnost systému, ale přitom zachoval administrační rozhraní přístupné obyčejným smrtelníkům. Co se přístupu týče, tak kontrolní mechanismus založený na názvech souborů je prý dostatečně dobrý. Pravděpodobně bude chvíli trvat, než bude jasné, jestli s tímto tvrzením vývojářská komunita souhlasí.

(Viz také tuto podrobnou kritiku kontroly přístupu založené na názvech souborů od Joshua Brindleho).


Následující obsah je © KernelTrap

vmsplice() versus COW

21. dub, originál

V rámci vysvětlování nových systémových volání splice() a tee() se Linus Torvalds zmínil o možných budoucích rozšířeních, včetně vmsplice(), které implementoval Jens Axboe. To vedlo ke srovnání se ZERO_COPY_SOCKET na FreeBSD, které používá COW (Copy On Write - kopírovat při zápisu).

Linus vysvětlil, že ačkoliv při určitých výkonnostních testech to může ukazovat dobré výsledky, je s tím ve skutečnosti spojená extra režie: Problém je, že cenou za označení věcí jako COW není jen počáteční zneplatnění tabulky: je tu také cena za chybu, když nakonec začnete na stránku zapisovat, i když už se v tu chvíli rozhodnete, že stránka není sdílená a chyba stránku pouze označí jako zapisovatelnou. A pokračoval: COW přístup může vygenerovat pěkná čísla při výkonnostních testech, protože tahle věc se testuje tak, že na uživatelskou stránku se vůbec nezapisuje. Takže skončíte s pěknou nekonečnou smyčkou, která musí zneplatnění TLB provést jen napoprvé, a pak už nemusí dělat nic. A nebral si servítky, když zakončil:

Tvrdím, že lidi kolem Mach (a zjevně i FreeBSD) jsou nekompetentní idioti. Zahrávání si s VM je špatné. Kopírování paměti je taky špatné, ale upřímně lze říci, že kopírování paměti má často méně mínusů než hrátky s VM. A větší keše to budou jen potvrzovat.

A přestože s ním pak Piet Delaney pokračoval v diskuzi o výhodách a nevýhodách obou přístupů, reagoval později Linus sám na svůj mail:

> Tvrdím, že lidi kolem Mach (a zjevně i FreeBSD) jsou nekompetentní idioti.

A taky tvrdím, že lidi, kteří chodí na Slashdot, většinou páchnou a jedí vlastní nudle z nosu.

A dále tvrdím, že každý, kdo si ještě nevšiml, že jsem umíněný parchant, a že "neslušný" je moje druhé jméno, má pěkně dlouhé vedení.

A nakonec je jasné, že nejenže jsem tu ten nejchytřejší, ale také nejlíp vypadám, a mému nevadnoucímu šarmu se vyrovná jen moje elegantní skromnost.

Takže tak. To jen pro ujasnění.

      Linus "klaňte se přede mnou, verbeži" Torvalds

Komu patří stack?

26. dub, originál

V krátké diskuzi mluvil Linus Torvalds o nedávno přidaném hacku, který má gcc zabránit v přepisování stacku parametrů u funkcí s asmlinkage na platformě x86. Tato oprava využívá prevent_tail_call() k předejití gcc optimalizace koncových volání [tail call]. Linus však poznamenal: Problém nejsou koncová volání, to je jen detail, díky kterému se to projevuje (umím si představit i jiné situace, které by to mohly působit). Koncová volání se říká tomu, že poslední řádek funkce vrací volání jiné funkce. Kompilátory to často optimalizují.

Linus uznal, že současný hack je ošklivý, a naznačil, že správný způsob opravení by spočíval v tom, kdyby tým gcc přidal atribut, který by kódu umožňoval říci gcc, že mu stack parametrů nepatří: Raději bych, kdyby se gcc rovnou od asmlinkage dozvěděl, že mu stack nepatří. Ale žádný takový atribut neexistuje, takže se zase musíme spokojit s makrem prevent_tail_call() (stejný problém jsme měli dříve s sys_waitpid() a sys_wait4()). Potom navrhl čistší hack, který by ten problém řešil obecnějším způsobem - ne pouze pro případ optimalizace koncových volání.

       

Hodnocení: 96 %

        š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ář

9.5.2006 00:56 k3 | skóre: 15 | blog:  
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
hezke :)

AppArmor byl podle čekávání -> AppArmor byl podle očekávání
9.5.2006 07:24 Leoš Literák | skóre: 74 | blog: LL | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
opraveno
Zakladatel tohoto portálu. Twitter, LinkedIn, blog
9.5.2006 01:03 Dan Ohnesorg | skóre: 29 | blog: Danuv patentovy blog | Rudná u Prahy
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Videl jsem OpenVZ na prednasce na LinuxTagu a bylo to fakt tuze zajimave. Meli spustenou virtualni masinu, na ni Xvnc a v nem bezel screensaver, takove ty bublajici barevne bubliny. Reklo se tomu migruj a behem cca 5 vterin to naskocilo na jinem nodu (kazdy nod na jednom notebooku). Screensaver bublal od mista kde bublat prestal a tcp spojeni VNC na ten Xvnc server zustalo bez problemu zachovano. Vrele doporucuji k vyzkouseni.
I'm an Igor, thur. We don't athk quethtionth. Really? Why not? I don't know, thur. I didn't athk. TP -- Making Money
Mikos avatar 9.5.2006 01:52 Mikos | skóre: 34 | blog: Jaderný blog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Paravirtualizace ala Xen je IMHO mnohem lepší řešení než všechny tyhle VServery, OpenVZ, Virtuozza, atp. A pokud se nepletu, měla by být i výrazně výkonnější ;-)
CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
9.5.2006 09:16 miso | skóre: 36 | blog: iSCSI_initiator_howto | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Ano, niekde na strankach Novell-u je video, kde migruje Xen domena, na ktorej bezi stream video server (V podstate podobny pripad ako ten screensaver, ale myslim, ze Xen je na tom vykonnostne ovela lepsie)
Project Satan infects Calculon with Werecar virus
9.5.2006 11:43 Honza Houštěk | skóre: 18
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Xen poskytuje lepsi izolaci jednotlivych virtualnich systemu a hlavne umoznuje provozovat ruzne systemy. Co se tyka vykonu, rezie behu nad hypervisorem muze byt dost minimalni, co ovsem uz tak minimalni neni je spotreba pameti jednotlivymi virtualnimi stroji. Navic je nutno pamet natvrdo jednotlivym virtualnim strojum pridelit v okamziku jejich startu, takze nepripada v uvahu, aby se o tyto prostredky jednotlive virtualni systemy nejakym zpusobem delily dle potreby. Velke komplikace ma Xen s primym pristupem k hardware nebo s pouzitim vlastnosti jako DMA, coz je u OpenVZ trivialni.

Kdo tvrdi, ze virtualizace na urovni OS nema misto na pod Sluncem a lekem na vsechno je Xen, je ignorant.
Mikos avatar 9.5.2006 13:42 Mikos | skóre: 34 | blog: Jaderný blog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Já netvrdím že virtualizace na úrovni OS nemá místo pod Sluncem, já jen tvrdím, že Xen je celkově výrazně lepší řešení :-)
CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
9.5.2006 14:41 Kyosuke | skóre: 28 | blog: nalady_v_modre
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Jo, skoro tak dobrý, jako hardware s podporou virtualizace, třeba jako mají mainframy. :-)
9.5.2006 09:06 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
LT zase neudrzel svou nevymachanou hubu a nekdo mu decentne soukrome naznacil, ze to opet prepiskl? Uz ani ty jeho opravy nejsou vtipne... :-/
16.5.2006 12:14 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
,,zahrávání si s VM je špatné'' - huh, 2.6.17-rc4-git3 běží s vypnutým MMU? To jsem musel nějak přehlédnout. Inu každý den se dovídáme spoustu nového ;-)
Táto, ty de byl? V práci, já debil.
9.5.2006 17:16 Jiří (BoodOk) Kadeřávek | skóre: 19 | blog: BoodOk | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Nektere moralni kvality idealne vyhovuji pozadavkum na vyvoj jadra a mene pozadavkum na diplomacii :-)
Věda má v sobě určitou zpupnost, že čím dokonalejší techniku vyvineme, čím více se dozvíme, tím lepší budou naše životy.
16.5.2006 12:22 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
Já mám raději když se věci říkají naplno. Ovšem v tomto případě Linus podle mne nemá úplně pravdu.
Táto, ty de byl? V práci, já debil.
18.5.2006 00:45 Jiří (BoodOk) Kadeřávek | skóre: 19 | blog: BoodOk | Brno
Rozbalit Rozbalit vše Re: Jaderné noviny - 26. 4. 2006
To neni naplno. To je s prehankou, to je vulgarni hyperbola.
Věda má v sobě určitou zpupnost, že čím dokonalejší techniku vyvineme, čím více se dozvíme, tím lepší budou naše životy.

Založit nové vláknoNahoru

ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.