Torvalds arról, hogy merre tart [majd] a Linux 2008-ban

Címkék

Az InformationsWeek egy levélinterjúban faggatta Linus Torvalds-t arról, hogy a nem is olyan távoli jövő esztendőben milyen irányba tart majd a Linux kernel fejlesztése. A riportból kiderül, hogy Linux kernel megalkotóját izgatják a "solid state" meghajtók, várakozása szerint fejlődés tapasztalható majd a grafikus eszközök és a vezetéknélküli hálózatok területein és elmondása szerint az operációs rendszere erős a virtualizáció területén is annak ellenére, hogy ez a terület nem érdekli. Az interjú elolvasható itt.

Hozzászólások

Vajon mikor lesz belőle kaliforniai kormányzó?

Isten ments. Lehet, hogy remek programozó, de az emberi interfésze egy tragédia. Az egyik utolsó lenne, akit szívesen látnék egy magyar kormányban.
Stop. Nehogy valaki elkezdjen itt politizálni és hasonlítgatni mostani vagy korábbi szakminiszterekkel. Csak annyit mondok, hogy ő nem. És nem, nincsen alternatív javaslatom sem.

Nem érdekli a virtualizáció????
Hát ember az ilyen?

desktop részről nagyvonalakban:
- fail safe (mindig vissza tudok állni egy adott, előre meghatározott pillanatára a rendszernek)
- nem kell multiboot, pause-olom az egyiket (vagy nem), és indítom a másikat
- frankón lehet tesztelni/próbálgatni

szerver részről nem fejtem ki, gondolom az egyértelmű...

- Kissebb terheltségű rendszereket össze lehet vonni egy gépre -> kevesebb gép -> kevesebb költség
- Különböző szolgáltatásokat el lehet szigetelni egymástól -> biztonság
- Könnyű egy-egy gépet költöztetni (fogod az image-t, átkopizod, elindítod ot) -> egyszerűbb menedzselhetőség
- stb.

benne van....
már az athlon 64 széria óta
bár valami miatt az amd honlapján nem írják, csak az opteronoknál, ellenben ha utánolvasol (mondjuk phoronix), akkor látni fogod, hogy az amd már rég beletette minden asztali procijába... (vagyis inkább nem tiltotta le)
saját tapasztalat:
birsbane magos 4800+ x2
asus m2a-vm lap (bios 1501)(amd690G chipset)
van amd-V
olcsó megoldás, sok rammal kifejezetten alkalmas virtuális gépes tesztekre
az alaplapok biosának támogatni kell a virtualizációt
aza asusnál az alap bios ezt nem tudta, de egy frissítés után már megy.
ugyanilyen chipes gigabytal pl. állítólag nem megy

xenes tesztet még nem csináltam, de a virtualbox működik amd-v vel
vagy nem erre gondoltál?

ezen én is sokat szaroztam, és nem értettem, hogy most mi van. igazság szerint a gyár lapját olvasgatva többször vágtam wtf fejet, mint nem.
hát no, a dokumentációik kissé...pontatlanok.
már nem csodálom, hogy olyan lassan megy a gpu specifikációk tisztázása.....
egyébként az I/O szintű virtualizációik doksiai is kint vannak a weblapon ha érdekel, legalábbis én valahonnan már letöltöttem, ami .amd.com-ra végződött...

akkor én is most felteszek egy kérdést. előtte azért hardver spec.: intel c2d e6550 gigabyte ds3-p35, 2g ddr2. nos a virtualbox aszongya, hogy ha bekapcsolom az intel vt-t, akkor lassabb virtualizációra számíthatok, és tapasztalataim szerint valóban, pedig vt-s a cpu-m. valaki elmesélne, hogy valójában mi történik a háttérben?

"Többször van kvázi ugyan az a file memóriábn."

Erre van megoldás pl. a VMWare ESX-ben (persze fizesd meg).

"I/O büntetőket magkapod. (Ebből elég sok féle van)
Több scheudler fut egymáson."

Másrészt oké, hogy _önmagában_ lassabb, de TFH. hogy van 10 nem nagyon leterhelt rendszered (amihez kellene 10 gép), amely kihozható (hasamra csaptam) 2 gép beszerzési és 1 gép üzemeltetési költségéből egyetlen egy gépen. Szerintem ilyenkor kb. mindenki tesz majd magasról a CPU és I/O időidre, ha átlagosan kb. ugyanaz a teljesítményt lehet kihozni, kevesebb adminisztrációval és költséggel.

Pl. egy adott alkalmazás fejlesztési és tesztkörnyezete, ami alapból baromira nem terhelés, mégis az éles alkalmazás komplett környezetét le kell másolni.
Vagy olyan programok, amiből csak egy pédány telepíthető egy oprendszerre (Pl. mindenféle message-queue szerverek - IBM MQ Series), stb.

A virtualizáció nagy előnye a kevesebb vas mellett inkább a rugalmasság: a komplett éles futó oprendszerről gyorsan készíthető másolat mentési vagy teszt célra.
Ugyanígy a vas elhalálozásakor sokkal gyorsabban állítható helyre bármilyen másik - ekár eltérő konfigurációjú -vason az alkalmazásod, mert az oprendszer az alatta levő fizikai vas paramétereitől függetlenül mindíg ugyanazon a virtualizált hardware környezeten fut.

Az utóbbi időben elég sok olyan projektben vettem részt, ahol vettek pár blade szervert, és külső FC diszkalrendszerrel megtámogatva nagyüzemben tolták át a korábban külön szerveren futó windowsos cuccokat Vmware ESX alá... (És az ügyfél igencsak elégedett volt a virtualizációval.)

Az olyan programokbol általaban egy is elég. :)
De testelni tényleg jó.

Ha kevesebb vas kell így akkor rossz a sok vasas tervezés.

Könnyebb auditálást (kisebb bonyolultság - kevesebb idő), és ha megfelőle imaga set-ed van, akkor gyorsabb üzembe helyezést jelenthet.

De kevesebb vasról(szum számitási telj., memory bandwith .. etc) álló éles környezetről nehéz lesz meggyőzni.

"Ha kevesebb vas kell így akkor rossz a sok vasas tervezés."

Nem. Olyan nagy teljesítményű egy-egy ma kapható szerver, hogy nagyon gyakran nem lehet elég kicsit venni egy adott alkalmazásnak. Márpedig főleg windows környezetben nagyon sok olyan vállalati szoftver van, amit nem lehet más alkalmazással egy oprendszeren futtatni...

Egyébként nem akarlak meggyőzni, csak a való életben pont azt látom, hogy egyre több blade szervert vesznek a nagy cégek, és tolják be ESX alá folyamatosan az addig külön vasakon futkosó Windows szervwereiket. Nyilván valami miatt megéri nekik...

Megint csak a driverek tekinteteben lesz fejlodes, holott ezeket nem is szigoruan veve a kernel fejlesztoknek kellene csinalniuk... En inkabb uj protokolokat varnek a kernelben, mint pl. egy memoria teruleteket megoszto, altalanos celu torrentszeru protokol... Akkor lehetne konnyen igen innovativ protokolokat epiteni ennek a tetejere. Eh, ezek csak vagyak maradnak.

Több gép között ?
Pontosaban ?

openmp, http://kerneltrap.org/node/2500 ilyesmi kéne ?

"On July 15, 2007, Bar announced that the openMOSIX project will reach its end of life on March 1, 2008, due to the decreasing need for SSI clustering as low-cost multi-core processors increase in availability."

Láttátok a képet? Szent Linus Torvalds.