Solaris kernel fejlesztő a Linuxról

Sun Microsystems

Eric Schrock Solaris kernel fejlesztő írt a blogjában pár gondolatot a Linux kernelről, Linus fejlesztési filozófiájáról. Nekem kicsit lekicsinylőnek tűnik... A fejlesztő leírja, hogy ők (a Solaris kernel fejlesztők csoportja) a olyan dolgokban hisznek, mint a megbízhatóság, karbantarthatóság, erőforrás menedzsment, bináris kompatibilitás... Szerinte Linus időről-időre azt mutatja, hogy ezek a dolgok nem tartoznak főbb irányelvei közé.

``In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility. Linus has shown time and time again that these just aren't part of his core principles, and in the end he is in sole control of Linux's future. Projects such as crash dumps, kernel debuggers, and tracing frameworks have been repeatedly rejected by Linus, often because they are perceived as vendor added features. Not to mention the complete lack of commitment to binary compatibility (outside of the system call interface). Kernel developers make it nearly impossible to maintain a driver outside the Linux source tree (nVidia being the rare exception), whereas the same apps (and drivers) that you wrote for Solaris 2.5.1 will continue to run on Solaris 10. Large projects like Zones, DTrace, and Predictive Self Healing could never be integrated into Linux simply because they are too large and touch too many parts of the code. Kernel maintainers have rejected patches simply because of the amount of change (SMF, for example, modified over 1,000 files). That's not to say that Linux doesn't have many commendable principles, not the least of which is their commitment to open source. But there's just no way that we can shoehorn Solaris principles into the Linux kernel.''

A teljes blog itt.

( Ochronus | 2004. 09. 24., p – 08:25 )

Kemény szavak, túl sarkosak, de az utóbbi kb. egy, másfél év linux kernel-fejlesztését tekintve sajnos nem nélkülöznek minden alapot. Néhol nagyon csúnyán a minőség rovására ment a fejlesztés sebessége.

( necrolite | 2004. 09. 24., p – 08:40 )

Már elnézést, de ez egy f@sz! Keveri a szezont a fazonnal... Amiért Linus visszautasítja a crash dumpokat a tainted kernelektol az egyenesági következménye magának a kernel licenszének. (Akár jogi útra is terelhetné...) Ezt mindaz az ember elfogadja aki non-gpl drivert ír. Ha pedig vki nem tudja elfogadni ezt az az ő baja... Ez olyan mintha Linus az ő mellét verné miért is kér pénzt a SUN a termékeiért... EZ egy okozat... vegyük már észre az okokat...

A stabilitást és egyéb problemákat a fejlesztés eltérő stílusa is okozza ami NEM feltétlenül rossz...

A végső mérleg: Hány gépen (hány architektúrán képes futni?) fut Linux és hányon Solaris? Hányféle igényt, igénybevételt kell figyelembevennie a Linux fejlesztőinek és hányt a Solarisnak? Mintha csak az M$ célzott kritikáit hallanám... ami anniyra szűklátökörű hogy hajjaj...

( johans | 2004. 09. 24., p – 09:11 )

A bináris kompatibilitás a SUN részéről inkább marketing, mint technológiai valóság. Van egy ügyfelünk, egy nagyon-nagy magyar telkó cég, aki azért nem bír kidobni néhány ultra10-et, mert az applikáció nem fut 2.5.1 felett. Aki pedig dolgozott már sun-os tűzfal programokkal (pl. raptor, checkpoint) tudja, hogy nem csak a verzió, de még a patchlevel sem mindegy. (mondjuk itt a kernel szintű driverek miat ez megbocsájtható lenne, de Eric Schrock azt állítja, hogy még a driverek is kompatíbilisek)

Ami a dtrace-t illeti, valaki világosítson fel, mennyiben több ez mint az strace/ltrace. Nekem ez nem derült ki az erről szóló cikkből, de lehet, hogy a hiba bennem van.

A Solaris 10 zónázását inkább nem hoztam volna fel példaként: domain szeparációt lehet Linux alatt is csinálni (és már most lehet, sőt, több, mint egy éve lehet, és nem csak a "majd-mostnár-mindgyárt-megjelenik-de-beta-már-van-belőle" verzióban) Gondoljunk csak az UML-re, de nem ez az egyetlen megoldás.

A Predictive Self Healing - nos, ez biztosan jó dolog (lesz), és ha egy kicsit ironikus akarnék lenni, azt mondanám, hogy a SUN-nak sszüksége is van rá, mert a világtörténelemben eddig egyedül ő bírt olyan processzorszériát kihozni visszavonás nélkül, aminek az icache-ében a 0-kból néha 1-ek lettek...

( anr | 2004. 09. 24., p – 09:39 )

First they ignore you, then they laugh at you, then they fight you, then you win.

-Ghandi

Jol allunk;-))

Ha jól megfigyeled a cikket, Eric Schrock pont arról beszélt, hogy 2.5.1 óta változatlan a rendszer ABI. Ez pedig nagyjából a 2.0-ás linux kernellel egyidős. Nos, ami azelőtt volt, arról inkább ne beszéljünk :)

Az általad említett cég esete pedig nagyban emlékeztet arra a gazdasági osztályra, ahol azért nem dobják ki a 486-osokat, mert a könyvelő program, amit mindenki megszokott, csak DOS-ban fut.

Egyébként pedig nem sok értelme van a két kernel tudását összehasonlítani, mert más az alkalmazási területük.

Az SF15K-nkra biztosan nem raknék soha az életben Linux-ot (nem az erőssége a 64 procira ütemezés, és még csak nem is álmodik DR-ről, vagyis futás közben procit/alaplapot kikonfigurálni az OS alól), míg a PC-mre sem raknék Solarist (túl kevés driver a PC-s architektúrához).

A vanilla kernelből te ugyan nem fogsz UML-t kihozni, és semmilyen zónázáshoz hasonló dolgot sem.

Ami pedig az icache-t illeti, nem tudom, hogy került ide, mivel Linus Torvalds nem gyárt processzorokat.

( zwei | 2004. 09. 24., p – 10:58 )

A blog tényleg kicsit elfogult a Linuxxal szemben, de mit várhatunk egy Solaris kernel fejlesztőtől? Szerintem mindenki, aki egy adott oprendszerrel sokat dolgozik, akarva akaratlanul az az adott oprendszert (vagy éppen disztribuciót...) kicsit többre becsüli az összes többinél.

Az egész Solaris Open source/Solaris vs. Linux dolgok mögött valójában egy dolog van: megjelent egy új piac, amit meg kell szerezni.

Manapság egyre inkább előtérbe kerül a Linux, mint egy hatékony alternatíva a Microsoft-al szemben, mert mostanra megérett arra, hogy nagy vállalatok, jelentős intézmények is használják Az uj piacot a Microsoftot lecserélni akaró cégek jelentik. Éppen ezért egyre több nagy IT cég száll be valamilyen formába a Linuxos üzletbe. A Sun ezzel szemben úgy gondolja, hogy ezen az új piacon nem Linuxxal indul, hanem saját, már régebben létező x86-os Solarisával.

Ez a szándéka látszik az x86 Solaris fejlődési ciklusán. A megjelenése után nem sokkall gyakorlatilag leálltak programok x86-ra portolásával, majd kb 1-2 évvel ezelőtt újra felélesztették a projectet, és egyre több pénzt fektetnek bele. Ez gyakorlatilag akkor történt, amikor a Linuxot egyre több nagy vállalat kezdte komolyan venni.

A Sun elég jó esélyekkel indul, mert a Linux mögött jelenleg nincs dollármilliárdos tőke, és ráadásul több disztribucióból áll, amik kezdenek egyre jobban szétválni.

A Linuxnak viszont megvan az az előnye, hogy egy hatalmas "tábor" alakult ki körülötte.

A Sun az OpenSource Solaris programjával szeretné a Solaris népszerűségét növelni, vagy ha úgy tetszik szeretne kisebb cégekből, egyéni fejlesztőkből egy, a Linuxhoz hasonló "rajongótábort" kiépíteni.

Saját tőkéjével, nagyvállalatok számára jól csengő nevével, illetve kiépített széleskörű támogatottságával jó pozíciót tud kiharcolni az alternatív (nem vindóz) operációs rendszerek piacán.

"Aki pedig dolgozott már sun-os tűzfal programokkal"

A binaris kompatibilitas userlevel/application szintu. 32 bites SunOS 4 kornyeki binarisok futnak Solaris 9-en. Ha a publikalt API-kkal dolgozol, akkor mukodni fog felfele. Ha belemaszol a kernelbe es nem az ABI szintjebe, hanem lejjebb (mint azt az osszes tuzfal is teszi), akkor ez azert mar nehezebb dolog.

"Ami a dtrace-t illeti, valaki világosítson fel, mennyiben több ez mint az strace/ltrace"

Eg es fold. Bovebben: http://www.hup.hu/modules.php?name=News&file=article&sid=6886

"A Solaris 10 zónázását inkább nem hoztam volna fel példaként: domain szeparációt lehet Linux alatt is csinálni (és már most lehet, sőt, több, mint egy éve lehet, és nem csak a "majd-mostnár-mindgyárt-megjelenik-de-beta-már-van-belőle" verzióban) Gondoljunk csak az UML-re, de nem ez az egyetlen megoldás."

Megintcsak: eg es fold. A zonak kozelebb vannak az LPAR-okhoz es a mainframe-es vilaghoz, mint az UML-hez.

"világtörténelemben eddig egyedül ő bírt olyan processzorszériát kihozni visszavonás nélkül"

Vagy inkabb a vilagtortenelemben eloszor olyan tomegben akkora cache merettel rendelkezo processzort eladni, ahol az alfa reszecskek altal okozott problema gyakorlatilag is elobukkan. Kesobb meg is jelentek a tukrozott ecache-sel rendelkezo UltraSPARC II-k, a III-akban pedig mar ECC vedi ezt a memoriateruletet is.

"A stabilitást és egyéb problemákat a fejlesztés eltérő stílusa is okozza ami NEM feltétlenül rossz..."

Amig otthon a PC-n hasznalod, addig nem. Amikor evi 4-5 ezer dollarert megveszed Red Hat Enterprise Server-kent es hasznalod egy Oracle alatt, akkor azert ez is egy fontos szempont, nem?

Jut eszembe, tegnapelott kijott az Oracle 10g Solaris x86-ra...:)

Igen, ezt én is így hallottam. Talán ez a "felhasználói nyomás" is segített ráébreszteni őket, hogy van még hely új oprendszernek az x86 architektúrán. A Sun valóban fejleszt Linux alá, de amit a blogban olvashattunk azt magyarázza, hogy a Sun miért nem száll be magának a Linuxnak (a kernelnek, az operációs rendszernek) a fejlesztésébe.

Ugye a Microsoft is használ Linuxot, sőt, egy-két apróságot fejlesztett is rá...

- AZ SF15K-ban ugye nem 64 processzor van maximum, hanem 72/106 (attól függően hogy használsz-e maxcpu boardokat), tehát a 64 processzor nem tudom, honnan jött. A Silicon tudtommal ennél több processzorra is skálázza a linuxot single image-ként.

- Futás közben processzort/alaplapot bizonyos architektúrákon (elsősorban IA64-en) lehet kikonfigurálni linux alatt is, még ha ez egy jelenleg experimental is. PCI hotplug pedig elég régóta van a kernelben.

- A vanilla 2.6 kernelből csinálok neked teljes domain szeparációt. A ckrm patch után a domainekre vonatkozó erőforrás hazsnálatot is be tudom állítani. A zónázás annyival ad többet, hogy ezt nem neked kell összereszelni.

Az, hogy egy tűzfal programnak a kernel ABI szintjénél mélyebbre kell mennie, szerintem az ABI tervezési hiányossága, de ebbe most ne menjünk bele.

A solaris 10 zónázása pedig nem más, mint egy domain szeparáció + egy resource management egybegyúrva. Ez lehet közelebb szerinted a mainframe-ekhez, vagy az LPAR-hoz, vagy akár Mari nénihez is, akkor is csak ennyi. (Cáfolj meg tényekkel). Persze az LPAR is csak egy domain szeparáció + egy resource management, tehát ilyen szempontból igazad van. Abban viszont nincs, hogy linuxon ezt nem tudod megcsinálni. Csak nincs neki ilyen szép hangzatos marketing neve.

Ja skalazza, de az mar nem SMP, hanem NUMA architektura. Oriasi kulonbseg......

Jelenleg a kovetkezo kurrens SMP architekturak mennek 64 proci fole:

- Itanium 2 (HP Integrity Superdome)

- Alpha 21364 (HP AlphaServer)

- UltraSparc IV (Sun Fire mittomenmennyi)

Asszem az IBM p690 teteje 64 proci (nem mintha egeto szukseguk lenne tobbre :) ). Az SGI mar inkabb csak a NUMA termekeket nyomja. Talan a Cray csinalt regen extrem nagy SMP-ket.

Andrei

Anno Fisher Erik (aki foglalklozik Mo-on Sunnal, tudja hogy ki ő) kezdte úgy az előadását a Sun15K-ról, hogy

"A konkurenseink azt fogják mondani, hogy ez egy NUMA gép. Egy gépről akkor szokták azt mondani, hogy NUMA, ha a memóriából a processzor cache-be történő transzfer legjobb / legrosszabb esete között több, mint 2-szeres szorzó van. A 15k-nál ez 2,5 , tehát félig - meddig igazuk lesz"

Mivel Linux-szal hasonlitjuk ossze most a dolgokat, ahol aztan semmilyen ABI kompatibilitas nincs, nem ertem miert gond az, hogy egy 32 bites kernelre irt modul nem megy a 64 bites kernelen...

Zonak:

Egy eleg jo doksi, nem marketing es nem Sun-os irta:

http://www.blastwave.org/docs/Solaris-10-b51/DMC-0002/dmc-0002.html

Maximalis zonak szama 1 gepen: 8192 (a globalissal egyutt)

Van itt [blogs.sun.com] egy screenshot egy Ultra 10-esrol ami eppen 73 zonat futtat (bar azokban nem sok minden fut, de az utemezes/resource management komolyabb overheadjenek hianyat azert eleg jol demonstralja).

Amugy nagyjabol igazad van, a zonak lenyegeben errol a kettorol szolnak. Ha valaki felinstallal most egy Solaris Express-t vagy jovo ev elejen egy stabil Solaris 10-et, akkor ott van benne, hasznalhatja, tamogatott, mukodik. Melyik kereskedelmi Enterprise Linux valtozatban talalok User Mode Linux tamogatast, aminek a segitsegevel egy 8 processzoros szerverre konszolidalhatok 3-400 apache webszervert ugy, hogy teljes, OS szintu szeparaciom legyen extra szoftver (pl VMWare) nelkul?

A fo kulonbseg a Solaris es a Linux kozott ugyanaz, mint a BSD-k es a Linux kozott is. Pontosan megfogalmazott fejlesztesi iranyvonalak es elvek. Ad-hoc modszerek helyett elfogadott, evtizedes fejlesztesi gyakorlat. A blog pont errol szolt...

A domain szeparációhoz nem kell UML, az csak egy példa volt a megvalósítására. Teljes OS szintű szeparációt lehet például SeLinux-al csinálni. 2.6 vanilla kernellel, igen-igen kicsi overheaddel.

Kereskedelmi Enterprise Linux domain szeparációval pedig van, pl. az IBM-től a zSeries-re kiadott suse linux. (Ugyan itt a domain szeparációt szigorúan véve nem a linux kernel csinálja).

"A fo kulonbseg a Solaris es a Linux kozott ugyanaz, mint a BSD-k es a Linux kozott is. Pontosan megfogalmazott fejlesztesi iranyvonalak es elvek. Ad-hoc modszerek helyett elfogadott, evtizedes fejlesztesi gyakorlat. A blog pont errol szolt..."

Hányszor írták újra scratchből a cluster szoftverüket mondjuk az elmúlt 6 évben? Úgy emlékszem 4 alkalommal, de háromszor biztosan. Ez ugye összecseng a kijelentéseddel. De hasonlót el lehet mondani a disksuitről is (legalább kétszer írták újra).

Sun rendszerménök vagyok, pontosan tudom, mi szívás van a Sun operációs rendszereivel és egyéb termékeivel. Nézd már meg, hogy kiadás után mondjuk az elmúlt két évben hány patchsetet vont vissza a SUN. Ez mind-mind valószínüleg az elfogadott, évtizedes fejlesztési gyakorlat hatása, és nem az ad-hoc módszereké, meg a tesztelés nélkül kiadott hibajavításoké.

Nem azt mondom, hogy a SUN cuccai rosszak. Nem rosszabbak, mint akárki másé, ideértve a Linux vendorokat is. Minden gyártónak megvan a maga keresztje. De hogy marketing/üzleti megfontolásból olyan technológiákról állítja, hogy nem létezhetnek linuxon, amelyek, ha megkaparjuk a marketing-mázt, már régóta elérhetőek, egyszerűen nevetséges.

"Mivel Linux-szal hasonlitjuk ossze most a dolgokat, ahol aztan semmilyen ABI kompatibilitas nincs, nem ertem miert gond az, hogy egy 32 bites kernelre irt modul nem megy a 64 bites kernelen..."

Lásd a blog idézet első mondatát:

In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility.

Hogy jon ide a cluster szoftver? A kernelrol volt szo... Kulon termek, kulon fejlesztogarda, kulon kultura. Disk suite ujrairas? A DS egyre kozeledett az operation environment-hez (8-ban meg kulon install, 9-ben mar integralt resze, talan lassan eljutunk odaig, hogy mar az installnal is lehet tukrozni a diszkeket... bar a ZFS mintha ezt az egeszet felboritana a kozeljovoben).

Ha szigoruan ar/ertek aranyban nezed a dolgot, akkor szerinted ugyanazon a 2 procis Xeon szerveren mivel jar jobban valaki mondjuk egy Oracle adatbazist futtatva? Red Hat Enterprise Server-rel, SuSE Enterprise Linux-szal, Windows 2003-mal vagy Solaris 10 x86-tal?

"A kernelrol volt szo... Kulon termek, kulon fejlesztogarda, kulon kultura." Jah, értem. Tehát irányvonalak, évtizedes gyakrolat, meg minden - kizárólag a kernelnél. Bár a kiadott majd visszavont kernel drivereket ez sem magyarázza.

"Ha szigoruan ar/ertek aranyban nezed a dolgot, akkor szerinted ugyanazon a 2 procis Xeon szerveren mivel jar jobban valaki..."

Nem tudom, hogy konkrét eset nélkül hogyan forintosítsam azt a performancia különbséget, akár +, akár -, amit az Oracle produkál Solaris 10 x86 alatt Linuxhoz képest. Nem tudom, hogy forintosítsam, hogy jó linux rendszergazdát olcsóbban kapok, mint jó Sun-osat. Nem tudom, hogy miért nem soroltad fel az ingyenes disztribúciókat, például Debiant vagy Gentoot. És végül fogalmam sincs, hogy ennek mi köze van ahhoz, hogy a Sun kernel egy fejlesztője (szándékosan vagy tájékozatlanságból) valótlan állításokat tett a blogjában mind a Solarisról, mind a Linuxról.

"Bár a kiadott majd visszavont kernel drivereket ez sem magyarázza."

Konkretizaljunk, mert nem mindegy, hogy egy 3rd party altal gyartott OEM-elt kartya driver, vagy egy dtrace szintu dinamikus instrumentalasi technologia moduljat vonjak vissza...

"Nem tudom, hogy konkrét eset nélkül hogyan forintosítsam azt a performancia különbséget, akár +, akár -, amit az Oracle produkál Solaris 10 x86 alatt Linuxhoz képest."

Ok, csinaljunk konkret esetet. Allokalok egy V65x-et, toltunk le Oracle x86-ot, valakitol kerunk valami tesztalkalmazast es merunk. Utana osszeirjuk az arakat es osztunk szorzunk...

"Nem tudom, hogy forintosítsam, hogy jó linux rendszergazdát olcsóbban kapok, mint jó Sun-osat"

Amikor utoljara neztem, ugyanazok a cegek ugyanannyiert kepeztek linux rendszergazdakat, mint akik Solaris rendszergazdakat (a tobbi cegrol nem tudok). Autodidakta tanulas meg mindket rendszernel ugyanugy tortenik, es ugyanannyit er (es ez nem lekicsinyles).

"Nem tudom, hogy miért nem soroltad fel az ingyenes disztribúciókat, például Debiant vagy Gentoot. "

Mert enterprise oldalrol nem erdekesek. Oracle gentoo-n? SAP Debian-on? Siebel CRM?

"És végül fogalmam sincs, hogy ennek mi köze van ahhoz, hogy a Sun kernel egy fejlesztője (szándékosan vagy tájékozatlanságból) valótlan állításokat tett a blogjában mind a Solarisról, mind a Linuxról."

Meg mindig nem latom, hogy mi volt valotlan azokban az allitasokban. Megnezted mar, hogy mit tud a dtrace?

A SUN logójával árult, a suntól megvett kártya (például FC, utoljára azzal jártunk így) drivere sem számít már a kernel részének? Egyre érdekesebb...

A teszt érdekelne, annak van értelme.

A linuxos és a sunos rendszergazdák árában nem azért van különbség, mert más a képzés ára, hanem azért, mert lényegesen több linuxos rendszergazda van.

Az ingyenes disztribúciókból összerakott dolgokat (például oracle debianon) láttam már, nem is egyet banki- és telco környezetben. A dolog létezik. (És most nem a tűzfalnak használt debianokról és gentookról beszélek)

Ami álltás nem igaz:

- "whereas the same apps (and drivers) that you wrote for Solaris 2.5.1 will continue to run on Solaris 10." Ez még user space-re sem igaz, nemhogy driverre.

- "Large projects like Zones ... could never be integrated into Linux simply because they are too large and touch too many parts of the code A marketing részétől eltekintve ez már létezik linuxon, sőt, vagy másfél év előnye van a Linuxnak a Solarissal szemben.

- In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility. Linus has shown time and time again that these just aren't part of his core principles, and in the end he is in sole control of Linux's future Ez egyszerűen FUD. Egzakt bizonyíték se mellette, se ellene nincs. A Solarisban is legalább annyi ad-hoc fejlesztés és teszteletlen patch van, mint a Linuxban.

"A SUN logójával árult, a suntól megvett kártya (például FC, utoljára azzal jártunk így) drivere sem számít már a kernel részének?"

A kernel reszenek szamit, de ugye te sem gondolod komolyan, hogy egy FC kartya driver-et ugyanazok ugyanott fejlesztik, mint ahol egy utemezot/dtrace-hez hasonlo cuccot? Az, hogy egy szoftverben bug van, es a teszteles kozben nem derul ki, teljesen standard dolog minden cegnel es szoftvernel. A kerdes az, hogy mennyi ilyen bug van es milyen gyakran, valamint milyen sulyosak ezek a bugok. Programozoi hibakat altalanaban viszonylag konnyu kijavitani. Tervezesi hibakat altalaban qrva nehez...

"A linuxos és a sunos rendszergazdák árában nem azért van különbség, mert más a képzés ára, hanem azért, mert lényegesen több linuxos rendszergazda van. "

De ha ugyanannyiert ki tudok kepezni egy Solaris-os rendszergazdat, mint egy Linuxosat, akkor ugyanannyi az aruk, nem? Felveszem az elso beeso informatikai diplomaval rendelkezo intelligens arcot (sot, inkabb egyetemistat, mert az meg olcsobb) es elkuldom 1 honap tanfolyamra...


"Ez még user space-re sem igaz, nemhogy driverre."

http://wwws.sun.com/software/solaris/programs/abi/

http://wwws.sun.com/software/solaris/programs/abi/appcert.html

"Appcert, developed by the Solaris ABI Program, is an easy-to-use tool for developers that looks for potential future binary compatibility problems in an application.

Binary compatibility problems can cause an application to be recompiled or rewritten in order to run on later versions of Solaris. Appcert, a free tool from Sun Microsystems, checks your application's compatibility with the Solaris Operating System. Running the tool on your applcation`s binaries provides valuable information about potential binary breakage on later releases."

Ha egy fejlesztoceg a fentiek szerint fejleszt es csak dokumentalt interfeszt hasznal, akkor igaz. A fenti ingyenes tool pedig meg tudja mutatni, hogy egy alkalmazasban mit hol csesztek el a fejlesztok, amiert nem lehet attenni ujabb release-re.

"A marketing részétől eltekintve ez már létezik linuxon, sőt, vagy másfél év előnye van a Linuxnak a Solarissal szemben."

zonecfg -z zone1

create

set zonepath=/zone/1

set autoboot=true

add net

set address=192.168.35.210

set physical=hme1

end

commit

zoneadm -z zone1 install

zoneadm -z zone1 boot

zlogin -C -e@ zone1

Ha valamilyen linuxon default install utan ennyi konfiguracioval meg tudod csinalni ugyanezt, akkor beismerem, hogy a Linux elorebb van a Solarishoz kepest... A zone1 gepen root felhasznalokent futo process-nek semmilyen lehetosege nincsen visszajutni a globalis zonaba! Ha a resource management-et is hasznalod, akkor elo tudod irni, hogy a zone1 max 10% CPU-t kapjon a teljes rendszerbol. Megint megkerdezem: melyik Linux disztribucio default install-jat kovetoen van meg ugyanez a lehetoseged?

"A Solarisban is legalább annyi ad-hoc fejlesztés és teszteletlen patch van, mint a Linuxban."

Ad-hoc fejlesztes: zero. Vannak mindenfele commitee-k aminek a hozzajarulasa nelkul semmilyen kod nem kerulhet be a Solarisba. Ezek a comittee-k a legaprobb reszletekig atnezik a dolog technologiai oldalat, es ha valamit talalnak mar megtiltjak a dolog integralasat. Nem programozi hibakat keresnek, hanem elvit. Olyan dolog, ami a fenti filozofikus elgondolasoknak (robosztussag, skalazhatosag, stb) ellentmod 100%, hogy nem kerulhet be a kernelbe.

Teszteletlen patch: nem kellokeppen tesztelt binaris patch elofordulhat, de ez Quality Assurance es nem Software Engineering problema.

Igazad van. Pontosan annyira erdekel a Redhat, mint a SUN. Azaz semennyire. ;-))))

Minden olyan problemara, amire az altalam elerheto ugyfeleknek igenye van/lehet kepes vagyok opensource megoldast talani, es beuzemelni mindefele (rajtam kivulalo) ceg segitsege nelkul.

Megfigyeltetek mar, hogy szoftvercegek nem vasarolnak szoftvert (maximum felvasarolnak szoftverceget)?

Erdekes nem?

Nemtudom, nalunk vasaroltak szoftvert. Van Oracle Financials rendszer, regen volt MFG/Pro, van LiveLink-unk, csomo Oracle adatbazis belso rendszerek alatt, Siebel CRM... Netuddmeg mit szivtam, mire a korabban altalam irt lokalis kis mini CRM rendszerunk (ugyfelnyilvantartas) adatait bemigraltuk a globalis crm-be...

Te megis melyik szoftverceg belsejebe latsz be, akinek birtokaban van az ultimate megoldas?:) Microsoft talan kepes csak sajat szoftverekbol epitkezni, de mas nemhiszem...

At hiszem ez az utolsó válaszom, egy kicsit nehéz a sun.com-ról jövő emberrel vitatkozni ebben a témában.

- Nem gondolom, hogy egy driver hibája ugyan az, mint egy tervezés-beli hiba. De ettől sem, meg attól sem működik a rendszer, és az ügyfél anyáz.

- Az mindegy, hogy valamit mennyibe kerül kiképezni. Linuxos rendszergazdából sok van, kínálati piac, lenyomja az árat. Sunosból kevés, ha kiképzed és nem fizeted meg rendesen, elmegy máshova.

- mondtam, pont annyi ad-hoc fejlesztés van Solarisban, mint linuxban, zero :). Egy linux kernel patchet is két-három ember minimum átnéz és megért, mielőtt bekerül a kernelbe. Tannenbaut leszámítva pedig nem hiszem, hogy sokan találnak koncepcionális hibát a kernelben.

- Bármilyen SeLinuxot elindítani képes rendszer alatt 35 sor konfigurálással és egy kb. 40 soros scripttel ugyan azt eléred, amit a példában mutattál. És semmi esélye arra, hogy a process bármilyen módon visszajusson a globális zónába. (Ezt egyébként ne hangoztasd sokat, mert a *BSD-sek a jail óta körberöhögik, aki ezzel dicsekszik). Tudom hogy ennyi, mert egy projekthez meg kellett írnom. Sőt, nem csak azt adhatom meg, hogy melyik interface-t használhatja, hanem még azt is, hogy melyik portokra bindolhat. Igaz, ezért 8x annyit gépeltem, mint te (a script megírásával együtt), és a resource management még nem volt benne (a te példádban sem volt). Ez a lehetőség a 2.6.0 óta a vanilla kernelben benne van, de a SeLinux projekt 2001-ben vált publikussá.

"De ettől sem, meg attól sem működik a rendszer, és az ügyfél anyáz."

Jo, de te azt irtad, hogy Erick hulyeseget ir, mert a Sun driverek is hibasak, es vonnak vissza patch-eket (mintha ez hetente 10-szer megtortenne, es invalidalna azt az allaspontot, hogy a Solaris kernelfejlesztes iranyelvei a fentiek).

"Az mindegy, hogy valamit mennyibe kerül kiképezni. Linuxos rendszergazdából sok van, kínálati piac, lenyomja az árat. Sunosból kevés, ha kiképzed és nem fizeted meg rendesen, elmegy máshova"

Windows-osbol meg meg tobb van, meg olcsobb, akkor hasznaljon mindenki Windowst? Ugye nem...

"Ezt egyébként ne hangoztasd sokat, mert a *BSD-sek a jail óta körberöhögik, aki ezzel dicsekszik"

Tobb helyen is le lett irva, hogy a zonakat a BSD jail inspiralta. Nem latom mi ezzel a problema.

Reszletek innen [www.itjungle.com];

"The idea is that an application crashing in one zone should not be able to crash applications running in other zones. The fault protection that Sun is working on is keeping faults in the zones from creeping into the Solaris kernel space. A memory leak from a single C++ application running in one zone, for instance, should not be able to crash a whole system."

"There is one other neat feature of zones that will make them appealing. Solaris 10 will have single node failover, which is akin to an IBM subsystem that can restart its applications when they crash. Right out of the chute, Sun will not be able to support high availability failover clustering across two linked zones, but the Solaris team is working with the Sun Cluster and Solstice teams to make that happen"

Ez utobbi mondjuk szerintem max VMWare ESX-szel oldhato meg jelenleg x86-on, de hatha tevedek.

No, azert talalok meg erdekes linkeket:

http://toadstool.se/journal/2004/09/20/technology-battle

Solaris Zones (N1 Containers). OS Virtualization without the disk, management, or performance overhead you are used to! It’s like BSD jails with a really slick management interface, and without the wasted disk space and patch management hassles. I got to mess with it at work last week, and I’m overly excited about it. It’s probably the most revolutionary thing I’ve seen as a sysadmin this year. Everything I disliked about jails, vmware, VirtualPC, UML, vserver appears to have been solved.

Csak nem birom abbahagyni...

A Usenix-os Zone publikacio 2 oldalas anyaga:

http://www.usenix.org/events/vm04/wips/tucker.pdf

"As a result, zones can be administered in a

manner very similar to separate machines. In fact,

some types of administration are significantly easier;

for example, an administrator can apply a patch to

every zone on a system with a single command."

Benne referenciak korabbi publikaciokra:

References

[1] Alan Charlesworth et al. The Starfire SMP interconnect.

In Proceedings of the 1997 ACM/IEEE

Conference on Supercomputing, 1997.

[2] Paul Barham et al. Xen and the art of virtualization.

In Proceedings of the 19th Symposium

on Operating Systems Principles, 2003.

[3] P. H. Gum. System/370 Extended Architecture:

Facilities for virtual machines. IBM Journal of

Research and Development, 27(6), 1983.

[4] IBM Corp. Partitioning for the IBM eServer p-

Series 690 system.

[5] Poul-Henning Kamp and Robert Watson. Jails:

Confining the omnipotent root. In 2nd International

System Administration and Networking

Conference (SANE 2000), May 2000.

[6] http://www.linux-vserver.org.

[7] http://www.virtuozzo.com.

[8] Carl Waldspurger. Memory resource management

in VMware ESX server. In Proceedings of

the 5th Symposium on Operating Systems Design

and Implementation, 2002.