A két patch természetesen nem egyforma. De mi a különbség? A cikk szerint a VMware egy teljesen nyílt, VMI (Virtual Machine Interface) névre hallgató általános csatolófelületet szeretne elfogadtatni, amelyik alapja lehetne több hypervisor-alapú virtualizációs megoldásnak, köztük akár Xen-nek is. Ezzel szemben a Xen fejlesztők egy olyan megoldást javasolnak, ami 100%-osan Xen specifikus lenne, a VMware-nek (és az esetlegesen később érkezőkneknek) teljesen használhatatlan lenne.
A cikk azt a kérdést feszegeti, hogy nem irónikus-e az, hogy noha a Xen a nyílt forrású, mégis a zárt forrású VMware ajánlata az, amely jobban megfelel a nyílt forrás szellemiségének?
A cikk itt.
- A hozzászóláshoz be kell jelentkezni
- 2990 megtekintés
Hozzászólások
A fentiek alapján a VMWare megoldása hangzik jobbnak, az, hogy minden alkalmazásnak ilyen-olyan patch-e kerül a kernelbe csak káoszt és zagyvaságot okoz. Persze lehet, hogy csak nekem hangzik egyértelműnek, de ha már felmerül az igénye hogy bizonyos típusú alkalmazásoknak kernel támogatásra van szüksége, akkor olyan megoldás kell, ami a funkciót támogatja, nem pedig az adott alkalmazást. És ha megvalósult az igényelt funkció, akkor ahhoz alkalmazkodjon minden azt használó alkalmazás. Szerintem.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Szerintem nem. Semmi akadalya, hogy mindketto belekeruljon, ha mindketto hasznalhato, es meguti azt a szintet. Nem kell versenyezniuk, hogy a jobb kerulhet bele.
Az jo dolog persze, hogy legyen egy "alltalanos" celra hasznalhato..., de nem arrol van szo. hogy ez akkor jobb mint a masik, hanem hogy ennel mas a cel.
- A hozzászóláshoz be kell jelentkezni
"Semmi akadalya, hogy mindketto belekeruljon" - szerintem ez nem helytallo. Lasd lentebb.
- A hozzászóláshoz be kell jelentkezni
_szerintem_ is belekerülhet akár mindkettő, de a vmware ajánlata a jobb. ha a xenes megoldás lesz hosszútávon, azzal igazából csak a xen jár jól. ha a vmware-t rakják bele, akkor akár mindenki is jól járhat, de a forrás minősége és karbantartottsága függ majd egy cég kénye-kedvétől (lásd reiserfs).
össze kéne ültetni őket, és csináltatni velük egy közös felületet, aztán akkor csudajó világunk lenne. persze ez csak álom :)
- A hozzászóláshoz be kell jelentkezni
Felremlik nekem most egy ACL/policy framework, ami a jelenlegi kernel resze, es csak az SELinux-al mukodik, a GrSecurity, es a tobbi szamara hasznalhatatlan.
- A hozzászóláshoz be kell jelentkezni
"A cikk azt a kérdést feszegeti, hogy nem irónikus-e..." - De. Imho az. Kivancsi vagyok, mikor adjak fel a 100% Xen specifikussagot kernel szinten, es fordulnak egy altalanosan, masok altal is hasznalhato kernel interfesz fele. Egy ideje hasznalok Xen-t production rendszereken, es nyomon kovetem -users, -dev listat (kevesbe), tisztan kiveheto az ottani posztokbol, hogy mennyire fontos nekik, hogy bekeruljenek a mainline-ba (ertheto modon - gyurnak is ra rendesen).
Viszont gondolom azzal is tisztaban vannak (amit a cikk is emlit), hogy a donteshozok sosem preferaltak olyan megoldast, ami csak 1 implementaciot tamogat, mindig a generikussag fele hajlottak. Fel van adva a lecke...
"They're not going to accept either set of patches until VMware and Xen hash out their differences and come to a compromise"
- A hozzászóláshoz be kell jelentkezni
Egyebkent valoszinu, hogy a Xen altal szorgalmazott patch bar 100% Xen specifikus valoszinuleg jobban megy vele a Xen, mint az altalanos interfesszel. (Es mas virtualis gepeket figyelembe veve, a sebesseg nem elhanyagolhato szempont.)
- A hozzászóláshoz be kell jelentkezni
vendor-lock-in a sebességért cserébe? nem ezért utálják a microsoftot? :)
- A hozzászóláshoz be kell jelentkezni
Ez miert lenne vendor-lock-in? Nyilt forrasu, barmikor megertheted hogyan mukodik, barmikor valaszthatsz masik konkurens megoldast (mindenfele hatrany nelkul, leszamitva az atallasi kiserleteidet), amikor csak akarsz. Ne legyunk naivak, az nem a fejleszto problemaja, hogy esetleg nem megfelelo vadaszpuskat valasztasz a nyulhoz vagy a verebhez :). A kiserleteket azelott kell lefolytatni, hogy eldontened neked melyik platform kell. Ennel szabadabb fejleszto valtast nem lehet elkepzelni.
- A hozzászóláshoz be kell jelentkezni
Ez egy meglehetősen régóta húzódó vita és a látszat ellenére nem két szereplős a játék.
Nem is olyan régen még az is kérdés volt, hogy az UML mellé minek még más virtualizációs megoldást a mainline kernel részév tenni. A OpenVZ körüli csapat szintén régóta próbálja benyomni a sajátját változatát a kernelbe (még ha az más technológia is). Ez a piac most borzasztóan túlfűtött és kicsit mindenki kapkod is. Egyébként ha alapos vizsgálatnak vetjük alá a VMWare javaslatát akkor kiderül, hogy közel sem annyira általános, mint első ránézésre tűnik.
Mindenesetre egy tény előbb utóbb zöld ágra fognak jutni. Egyébként van kommunikáció a két csapat között elsősorban a nagyokon keresztül (IBM, MS, Novell, RH stb.)
- A hozzászóláshoz be kell jelentkezni
Az eredeti cikkben linkelt olvasmanyt vegigfutva megtudhatjuk, hogy pl. az Oracle is egyre turelmetlenebb, es igyekszik partatlan szereplokent nyomas gyakorolni a felekre, hogy jo lenne, ha a seggukhoz kapnanak, es kidolgoznanak egy konszenzus alapu megoldast.
- A hozzászóláshoz be kell jelentkezni
En nekem ez jutott eszembe: OpenBSD es Linux WiFI hozzaallasa es egyebek .
Sajnos nem vagyok olyan szinten, hogy ezt le tudjam ellenorizni, de ha igaz akkor erdemes elgondolkodni rajta.
- A hozzászóláshoz be kell jelentkezni