Elhagyta az Oracle-t a Solaris fejlesztéséért felelős főigazgató

Oracle

A The Register egyik Solaris-szal kapcsolatos cikkében beszámol arról, hogy amellett, hogy az OGB "rituális öngyilkosságra" készül, az operációs rendszer fejlesztéséért felelős rangidős igazgató búcsút mondott az Oracle-nek nemrég.

Greg Lavender kisebb-nagyobb megszakításokkal 2000 óta volt a Sun Microsystems munkatársa különböző pozíciókat betöltve. A Sun-os pályafutása kezdetén a szoftvermérnökségért felelős igazgatói pozíciót töltötte be. Volt vendégprofesszor a vállalatnál, mikoris a Sun által szponzorált egyetemi, hálózatokkal és operációs rendszerekkel összefüggő R&D projekteket vezetett. 2008 márciusától 2010 februárjáig a Solaris operációs rendszer fejlesztéséért felelős főigazgatói széket birtokolta a Sun-nál. Az Oracle felvásárlás után 2010 februárjától június közepéig a Solaris Core operációs rendszer fejlesztéséért felelős részleg alelnöke volt.

A szakember LinkedIn profilja szerint már nem dolgozik az Oracle-nél. Jelenlegi munkaadója a lábát a szerverpiacra is belógató Cisco Systems.

A részletek itt.

( trey | 2010. 07. 15., cs – 12:03 )

Most nem tudom, hogy ezek a pókok maguktól tipliznek le, ellehetetleníti az Oracle a munkájukat, így kénytelenek letiplizni, vagy eltávolítják őket.

"No more Solaris. Now it's SoLarry's." <- Ahahahaha.

--
trey @ gépház

Előkészíti a Solaris eladását a Cisco-nak.
Nemsoká jönnek a zfs alapú Cisco NAS-ok, meg a Dtrace-elhető routerek.
:)

szerk: szerintem a Sun korábbi vállalatvezetési stílusa és az Oracle-é elég élesen különbözik, ami valószínűleg sok ex-sun alkalmazottnak most nagyon fájó pont. Szerintem fog még pár arc távozni a cégtől.

Kicsit off:

Arról nem csiripelnek a madarak, hogy esetleg egy nagyobb csapat mérnök kiválik a Sun-ból, és csinálnak egy új céget? Pl. az x86 szerveres részleg? Vagy nincs ilyen "kemény mag", akikre egy új HW céget lehetne alapozni?

(ugyan az "Eclipse" poént az IBM már elhasználta, de ettől még lehetne új ex-Sunos vállalat...)

Üdv,
Gergely

Annó, amikor a Java atyja - Gosling - lelépett, elterjedt egy olyan pletyka (amelyet senki nem cáfolt, tehát igaz :), hogy Gosling attól gőzölt be, amikor az előadását bekérte a jogi és a marketing osztály, hogy átnézzék, mielőtt előad, illetve ezek után az előadása elé két-három oldalas jogi nyilatkozatot csatoltak (amit mond, az nem üzleti ajánlat, nem az Oracle irányvonala, stb.)... ő nem volt ilyesmihez hozzászokva.

Sajnálom a Solaris-t, mivel építettem volna az OpenSolaris-ra, mint szerver platform, de nagyon elvitték desktop irányba (Toshiba egy ideig árult előtelepített OpenSolaris latopokat is), eközben a szerver erősségeket nem igazán fejlesztgették... aztán próbálkoztak csomagkezelő-fejlesztő-szakember importálásával, ahelyett, hogy a FreeBSD csomagkezelését és ports adatbázisát vették volna át és készítettek volna kompatibilitási patch fájlokat, a FreeBSD csapat ugyanis a Linux -> Unix portolás nagyobb részét elvégezték, így az OpenSolaris-hoz elég lett volna minimális FreeBSD -> OpenSolaris patch. Szerény véleményem szerint ezt már a Sun elszabta...

Annak örülök, hogy a Sun a Java világot idejében nyílt forrásra helyezte, és így az Oracle nem tud igazán ebbe belenyúlni, maximum lesz egy Oracle Java 7i.0.1.11.0 és lesz egy OpenJDK7, a világ nagy része pedig ez utóbbit fogja használni... a Java köré nagyon sok innovatív és fejlődőképes közösség épült, és ők vannak többen, a Java gyakorlatilag önjáró lett, csak az Apache és a Red Hat képes lenne önállóan fenntartani a fejlődését, és még ott több tucatnyi kisebb-nagyobb közösség és cég, amelyik elkötelezett az OpenJDK mellett.

Az Oracle termékeit elnézve nem lesz túl jó a felhozatal, valahogy minden termékük működik valamennyire, de ez a működés nehézkes és sok esetben érthetetlen vagy kezelhetetlen, a hibákat nehezen lehet kideríteni vagy kijavítani, vastag support nélkül szinte öngyilkosság... és ez az Oracle működésmódja: beteszi a lábát, majd megpróbál eladni mindent, amit csak tud, aztán csak tartja a markát a semmiért, de mindig éppen csak annyit kér, hogy éppen ne érje meg más technológiára átállni.
--
http://wiki.javaforum.hu/display/FREEBSD

"Sajnálom a Solaris-t, mivel építettem volna az OpenSolaris-ra, mint szerver platform, de nagyon elvitték desktop irányba"

a Sunnak már korábban is voltak forradalmi desktop ötletei, Sun Starfire például.
az internetes idők által felpörgetett serverpiac előtt unix workstationökből volt jelentős bevétele a Sunnak.
mindenesetre sajnálom én is a SUNt. szerencsére amit csak lehetett nyílt forrásúvá tett a termékeiből, még a Sparc Niagara processzorokat is. így a korábbi gyakorlattól eltérően a SUN nem fog nyom nélkül eltűnni.

"Java gyakorlatilag önjáró lett, csak az Apache és a Red Hat képes lenne önállóan fenntartani a fejlődését, és még ott több tucatnyi kisebb-nagyobb közösség és cég, amelyik elkötelezett az OpenJDK mellett".
a jó Googlenek már sikerült forkolnia is, csak sajnos inkompatibilis módon.

a jó Googlenek már sikerült forkolnia is, csak sajnos inkompatibilis módon.

Két külön dologról beszélsz. A Java létezik, mint nyelv, létezik mint API és létezik, mint VM, a Google ebből a VM-et cserélte ki, mivel a JavaSE alkalmatlan mobil eszközökre, a JavaME pedig szépen lassan elavult, akár a WinMo. Az Android Java nyelven programozható, de nem JVM-en fut a program. :)
--
http://wiki.javaforum.hu/display/FREEBSD

az éppen a legfontosabb része, ezen múlik a kompatibilitás. forráskód és api szinten nagyon sok program kompatibilis egyébként is.
úgy egy évtizede volt nem is kicsi felzúdulás SUNos körökből a Microsoft elbaltázott java pluginje miatt. most pedig a SUNnak volt épp elég baja, nem maradt ideje/ereje arra, hogy a Dalvik miatt lenyomjon egy csörtét a Googleel.
miért lenne alkalmatlan a JavaSE mobil eszközre?
egyedül a swingel van probléma, annak kódja ugyanis tele van lebegőpontos műveletekkel, fpu pedig általában nincs a mobil processzorokban. ez a probléma sokkal egyszerűbben is orvosolható lett volna, nem kellett volna fenekestül felforgatni mindent. register archra cserélni a Dalvik VMet a JavaVM stack machine helyett, istenem! az az érzésem, a Google csakazértis fordítva csinált mindent, amit csak lehetett.

úgy egy évtizede volt nem is kicsi felzúdulás SUNos körökből a Microsoft elbaltázott java pluginje miatt

Felzúdulás azért volt a Sun részéről, mert egyrészről az MS nem volt hajlandó annyit fizetni nekik, amennyit ők elvártak volna, másrészről meg az akkori MS-mentalitáshoz hűen nem lett teljesen szabványos a Java implementációjuk. Ennek ellenére nagyságrendekkel gyorsabb volt, mint a Sun JVM. Aki használta mindkettőt (akár csak GUI cuccokkal, mint a Cisco PIX/PDM), az tudja miről beszélek...

Nyilván senki sem tiltotta akkor a ms-nak sem, hogy a specifikációk szerint egy teljesen más rendszert csináljanak belőle, de ők akkor azt mondták, hogy az is "Java runtime", holott állatira nem volt az. Ezért perelte ki tőlük a sun a név használatát, de ha jó szemed van, akkor J# formájában még láthatod ez az állatot is.
A gugli most fogta a speckót kifordította, valószínűleg okkal optimalizálta is, de eszébe sem jut "Java runtime"-nak titulálni, max azt mondja -- ami igaz is -- hogy az alapok ugyanazok.

az éppen a legfontosabb része, ezen múlik a kompatibilitás.

A kompatibilitás API és nyelv szinten múlik, nem a VM-en. A Google nem változtatott a nyelven, se az API-n, mindössze épített rá egy saját GUI-t és Thread modellt. De minden, ami meg van írva Java nyelven, az újrafordítva működhet Android platformon.

miért lenne alkalmatlan a JavaSE mobil eszközre?

Nem mobil eszközökre találták ki, nagyon sok esetben túl bő, más esetekben túl szűk. Ha úgy gondolod, hogy csak az FPU miatt van DalvikVM, akkor gondolkodj még egy kicsit, van ott még több tucatnyi alapvető különbség a memória modelltől kezdve a felület életciklusán át egészen a szálkezelésig... :)
--
http://wiki.javaforum.hu/display/FREEBSD

"De minden, ami meg van írva Java nyelven, az újrafordítva működhet Android platformon"
ez itt a probléma, újrafordítva! feltéve, hogy megvan a forráskód. a java fő előnye pedig épp az, hogy nincs szükség forráskódra/újrafordításra, minden támogatott sw és hw platformon működni fog az adott program.
itt pont ez vész el.
ráadásul az "újrafordítás" sem teljesen automatikus, néha módosítani kell a kódot is. így pedig, forrásszinten még a C programok is "kompatibilisek". jó eséllyel működhetnek más platformokon is.

"Nem mobil eszközökre találták ki, nagyon sok esetben túl bő, más esetekben túl szűk"
a Linux kernelt pedig speciel nem mobiltelefonos használatra találtál ki. és?
egyébként már évekkel ezelőtt használtam javat zaurus PDAn. abban 206Mhzes ARM cpu volt, 64Mb ram társaságában. ahhoz képes a mai smartmobilok erőgépek. így a filozófiai megfontolások helyett konkrét tapasztalataim vannak. a "túl bő, más esetekben túl szűk" "érvek" csak a kérdéskör filozófiai síkra terelésére jók:)

Ha egy mérnökcsapat nekiáll fejleszteni egy terméket, akkor nem a "forkoljuk le a Java-t" felkiáltással áll neki. Szépen összegyűjtik a követelményeket, megoldási lehetőségeket, aztán döntést hoznak.

A követelmények között szerepelt egy könnyen elsajátítható, széles körben ismert nyelv. Itt nyilván felírtak több lehetőséget, és a Java _nyelv_ mellett döntöttek.

A futtatókörnyezet megtervezésénél pedig a JVM nem volt megfelelő, ezért készült el a Dalvik.

Az Android fejlesztésénél új platformot építettek, de nyilván, ahol lehetett, nem találták fel a kereket ismét (pl. Linux kernel használata).

Ahol viszont szükséges, ott a hagyományokat teljes nyugalommal fel is rúgják. Emiatt lehet ilyen jól dolgozni az Android platformmal (itt most nem csak az SDK szintre gondolok, hanem amikor portolod, vagy mélyebben bele kell nyúlnod új feature-ök miatt).

Egyébként abban a ritka helyzetben vagy, hogy az android-platform listán közvetlenül is megkérdezheted a rendszer kitalálóit, hogy miért így döntöttek. Akkor nem kellene elméleteket gyártanod.

Üdv,
Gergely

Ui: A Java forkolásában a Google duplán bűnös, hiszen ott a GWT is...lehet, hogy valahol a Googleplex mélyén éppen sátáni kacajt hallatnak, hogy milyen hatékonyan zilálják szét az "egységes" Java platformot.

itt nem a mérnökcsapat ült össze a Googlenél, hanem a jogi osztály és pár közgazdász. a mérlegelési lehetőség a teljesen új platform, illetve valamelyik jól bevált között terjedt. végül ez a Dalvik fork lett az eredmény. kevésbé perelhető, mint egy java kompatibilis változat, de természetesen jóval olcsóbb mint egy új saját platform fejlesztése. ráadásul már ismerik is.
a jogi fenyegetettség ezzel ugyan nem szűnt meg, a Java ugyan szabad szoftver, de e gplv2 licence nem terjed ki a szabadalmakra, így ott még továbbra is lehet fogást találni a Dalvikon. de a másik oldalról adódó előnyök megérték nyilván a kockázatot.
ugyan mi oka volt a VM register machinera változtatásának stack machineról?
csak nagyobb lesz tőle a kód! nem éppen ideális egy smartmobile számára.
JITra is eléggé sokat kellett válni, egészen mostanáig.
a Dalvik körül nincsenek műszaki megfontolások, ez csak jogi manőverek és trükközés eredménye.

Te a Google-nél dolgozol? Ott voltál? Esetleg tudsz konkrét, megbízható forrásból származó linket arra amit írsz (és nem a különböző blogok okoskodásait)?

"ugyan mi oka volt a VM register machinera változtatásának stack machineról?
csak nagyobb lesz tőle a kód! nem éppen ideális egy smartmobile számára."

Dalvik VM Internals előadás, Google I/O 2008

22. slide.

Idézet:

common system libraries
(U) 21445320 — 100% (U) uncompressed jar file
(J) 10662048 — 50% (J) compressed jar file
(D) 10311972 — 48% (D) uncompressed dex file
web browser app
(U) 470312 — 100%
(J) 232065 — 49%
(D) 209248 — 44%
alarm clock app
(U) 119200 — 100%
(J) 61658 — 52%
(D) 53020 — 44%

Ezt az uncompressed Dex file-t egyébként a rendszer MMAP-pel tölti be a futó alkalmazás címterébe. Hasznos lenne, ha az állításaidat alá tudnád tényekkel is támasztani.

Üdv,
Gergely

ez első kérdésedre te is tudod nincs válasz, pláne egy nyilvános oldalon. a Dalvik VM Internals előadás ezen része pedig a szokásos IT marketing, a szokásos csúsztatásokkal és mellébeszélésekkel. bár diszkréten nem említik, hogy az összehasonlítás melyik java kiadást érinti. nyilván nem JavaMe, és mégcsak véletlenül sem JavaFX.
ez szerinted érv register machine vs stack machine ügyben?
ugyanez megoldható a kompatibilitás megtartása mellett is.

nem volt illendő, amit a google csinált ez ügyben.

itt nem a mérnökcsapat ült össze a Googlenél, hanem a jogi osztály és pár közgazdász.

Ez részben igaz. A Sun, illetve most már az Oracle a JVM-et ingyen adja desktop és szerver környezetbe, a Java-ból érkező bevételeinek nagyon-nagyon-nagyon-nagy részét a beágyazott rendszereken futó Java után fizetendő licenc díjak adták, nagy részben a JavaME, kis részben a JavaCard.

a mérlegelési lehetőség a teljesen új platform, illetve valamelyik jól bevált között terjedt. végül ez a Dalvik fork lett az eredmény.

Sokkal kisebb a DalvikVM footprint, mint a JavaSE JVM footprint. Ez nem elhanyagolható, amikor nem egy, hanem 10-20-30 VM fut egymás mellett.

egyébként már évekkel ezelőtt használtam javat zaurus PDAn.

Használtál rajta időnként egy-egy Java programot, vagy _minden_ UI és a service-ek jó része Java nyelven írt program volt?
--
http://wiki.javaforum.hu/display/FREEBSD

félreértés ne essék, nem azt írtam, hogy egy teljes Java SEt kellett volna az Androidhoz használni. csak azt, hogy a feladatot egy Java kompatibilis Dalvikkal is meg lehetett volna oldani. nemcsak api és nyelv szinten, hanem vm szinten is.
használható Dalvik runtime environment létezik már Ubuntura, vagy bármilyen más disztribre? a Canonical ígérgeti már egy ideje.

egyébként amint írtam a Sharp Zaurus jól elboldogult a java appokkal, pedig egy 5500asban csak 16odnyi ram, és 8ad órajelű jóval korábbi arm cpu állt rendelkezésre, mint a Google etalon Nexus Oneban.

természetesen ettől még a Google egy normális mentalitású IT cég marad. a motiváció is érthető, egy sikeres nyílt és linux alapú mobilplatform létrehozása mellett, az Android tervezése idejében kezdődött a versenyfutás a Flash/AdobeAIR, Silverlight, JavaFX között. egyrészt a Dalvik, másrészt a webMel megerősített html5 mellett nincs sok esélye a Silverlightnak a piaci dominancia megszerzésére. és igen, ennek nagy része a Googlenek köszönhető.

a JavaME valóban licencdíjas, és az okok is itt kereshetőek az inkompatibilitásra. egy JavaMEt jobb képességeivel leváltó, de Java kompatibilis Dalvik jogilag támadhatóbb lett volna, és talán per is lett volna belőle. bár a SUN akkoriban elég sok bajjal küszködött és már vevőt keresett. ezt a helyzetet valóban ügyesen használta ki a Google.

en a zfsert se sirtam jo volt az ufs 20 evig adatvesztes nelkul akkor talan meg 20 evig jo lesz

de amugy az egesz solarisbol a dtrace az ami tetszett meg talan az smf, de amiket az opensolarisban lehet szopni az leirhatatlan

en orulok ha a hasznalhato reszek atkerulnek a freebsdbe es csoki. slowaris jo volt veled meg a sparc is kiraly volt!

Konkrétan melyik részére gondolsz? Már a dtrace-en (van helyettesítő), a zfs-en (van/lesz helyettesítő) kívül. Az infrastrukturális dolgoknak szinte nulla az esélye, a többinek sem sokkal több, és nem is nagyon látok ilyet.
Nem fognak átemelni egy komplett hálózati réteget...

suckIT szopás minden nap! A ZFS lassan utoléri az UFS-t...

konkrétan nagyjából ezekre:) dtrace ugyan helyettesíthető, de a jelenlegi alternatívát nézve, khhm értelmesebb lenne portolni a dtracet magát. Solaris Containers/zones átemelése is hasznos lenne, bár igaz ez is helyettesíthető. és igen a zfs. per pillanat a btrfs már jobbnak tűnik, de még mindig csak experimental. a zfs már jó ideje jelen van. már csak a névért is megéri megtartani. így a meglevő zfst használó ügyfélbázisnak lehet mondani, hogy upgradelhetnek Oracle Unbreakable Linuxra továbbfejlesztett zfs2 technológiával:) természetesen jó pénzért, hiszen az Oracleről beszélünk:D plusz megmarad így a zfs1 kompatibilitás is, ami nem hátrány.

a Solaris kukázása azért még nem a jövő hónapban esedékes az Oracleéktől. addig valószínűleg leboxolják. márcsak azért is, mert nem lehetetlen, hogy a Brtfs is sért NetApp szabadalmat. a boxmeccs csak nem tart majd egy évtizedig, bár az SCO szappanoperát elnézve újabb végtelen történetre is van esély:)

Ezek nagy részben hit, és ego kérdések is. A linuxos tábor már csak dacból sem fog belemenni abba, hogy valaki a dtrace-t, vagy a zfs-t tolja, főleg, hogy mindkettő akkor igazán jó csak, ha egy kicsit belenyúlnak a kódba, nem pedig csak hozzácsapják.
A containers pedig már abszolút az az eset, mint a network stack. Nincs mit (kód) átemelni szerintem, hiszen annyira különbözik a két kernel.

suckIT szopás minden nap! A ZFS lassan utoléri az UFS-t...

"A containers pedig már abszolút az az eset, mint a network stack. Nincs mit (kód) átemelni szerintem, hiszen annyira különbözik a két kernel."

Ez így ebben a formában nem igaz. A Solaris zónák leginkább a privilégiumokhoz és chroot-hoz állnak közel, nem pedig virtuális gépeket kell elképzelni kernelen belül. Az biztos, hogy nem egyszerű az implementálása, mert az egész kernel működését át kell látnia a fejlesztőnek, de akár Linuxra, akár *BSD-re portolható lenne.

Ismerem a zónákat, pont ezért gondolom, hogy ha valaki ilyen funkcionalitást szeretne, valószínűleg inkább elméleti inspirációt venne az opensolarisból, mintsem kódot. Nem zárom ki, hogy lenne felhasználható rész, de a munka jelentős része nem annak a megírása lenne, hanem a hálózati, processz, erőforrásmenedzsment és hasonló dolgok megvalósítása, amely tekintetében a két rendszernek nincs közös kódbázisa.

suckIT szopás minden nap! A ZFS lassan utoléri az UFS-t...

lehet hogy a almaidban, vagyaidban ez igy van de perpillanat se a zfs se a dtrace nincs linuxon ellenben mindketto van freebsdn

szal maradjunk a talajon, nem kell rogton pszichoaktiv drogokohoz nyulni

az mar kulon poen h a systemtap nevu szuttyadek amit a dtrace inspiralt(aztan persze letagadtak) mekkora egy retek a dtracehez kepest :)

olyan érdekes ez a rekurzív álomvilág amiben élsz. mármár magyar nemzeti sajátosság:) úgy "álomvilágozol" le egy neked nem tetsző véleményt, hogy közben pont te élsz egy alternatív univerzumban:)

hint, Oracle Unbreakable Linux.

szerinted mit fog tenni az Oracle a Solarisban levő, átemelésre érdemes technológiákkal akkor, amikor hivatalosan is kukázza a Solarist? kettőt találhatsz:)

Úgy beszélsz az Oracle-ről, mintha az övé lenne a Linux kernel, holott a saját disztribúciója is csak egy Red Hat fork. Attól, hogy azt a semmit, amit a Solarisból (a ZFS, dtrace-en kívül, de ezek fogadtatását már kb. ismerjük a linuxos fejlesztők körében) kódszinten átemelhetne át szeretné emelni, még nem biztos, hogy át tudja emelni. :)

suckIT szopás minden nap! A ZFS lassan utoléri az UFS-t...

azért még nem ment el az utolsó Solarisfejlesztő az Oracletől. na meg Indiában is nagyon olcsó a munkaerő, ráadásul sokan vannak:)
már most van natív zfs port linuxra. és a lehetőség is teljesen evidens volt.
csak valahogy néha az az érzésem, hogy sokan kódolás helyett licenceket olvasnak, és minél többet olvassák annál kevésbé értik őket:D

:) ez igy van, csak sajna abbol all a vilag, hogy penz, meg a jog, szoval ha akarja az ember, ha nem, kell foglalkozni a licencekkel, meg aztan olyan hulyesegekrol ne is beszeljunk, mint a software patent-ek, foleg a "trivialis" dolgok ... Ez csak egyvertar a harchoz, de sajna kell, mert ha nincs, hiaba hulyeseg meg nem kene egy idealis vilagban: kulonben nem tudod megvedeni magad ...

És az ugye rémlik, hogy ez a port csak zvol-ok supportjáig megy el.
+ kérdéses hogy melyik zpool verzióig.
Azért még ott is történtek komoly fejlesztések a legutoljára publikusan kiadott 2009.06-os osol és a 134-es build között.
Arról meg már nekem sincs fogalmam, hogy b134 után mi történt.

Mondjuk a dtrace tenyleg jo. Pont azert "sirok" a Solaris miatt, mert van/volt par agymenese, de az utobbi idoben mintha pont kezdett volna megoldodni egy csomo problema, ami miatt sokan "fapadosnak" neveztek (pedig akkor is csak erteni kellett hozza, de azert mas kerdes, hogy egy csomo - legalabbis nekem tetszo - dolog jott be, zfs, dtrace, smf, ilyesmik), azert a Solaris-on latszik hogy egy kiforrottabb OS sok tekintetben mint a Linux, bar teny, hogy erre a kovetkeztetesre nem lehet eljutni ugy, "hogy en mar egyszer be-ssh-ztam egy Solaris-ra, de szar, a Linux sokkal jobb" alapon. Ja es felreertes ne essek: alapvetoen tobb Linux-os szervert uzemeltetek mint Solaris-t, es talan jobban is ertek az elobbiekhez, megis latom, hogy kar a Solaris-ert, a fentiek miatt (is).

+1

ZFS miatt elkezdtem beletanulni, mert van egy X4540-ünk storage szervernek, nem akartam Debillel meggyalázni.
Ahogyan már nyilatkoztak róla, eleinte eléggé az idős, még papucsban közlekedő rendszergazdák játékszerének tűnik, de egy pont után nagyon kezdett megtetszeni.

Főleg, hogy érdekelnének ilyen featureök is, mint FCoE, amiben pl. a Comstar csapat/projekt elég erősen aktívnak tűnik.
Bár kipróbálni még egyikkel sem sikerült, de a doksik alapján itt használhatónak tűnik, még linuxon még nyoma nincs annak, hogy kiforrott lenne, de egyáltalán ami csak iSCSI téren linuxban van is (nézzük bármelyik implementációt) egy gányrakásnak tűnik a comstarhoz képest.
Doksik alapján szintén szimpatikus fejlesztés nekem az xvm, xvm-ha, crossbow, stb.
Ha meg egyszer felrakod, bár nem próbálkoztam túl erősen vele, de eddig agyonverhetetlennek tűnik.
Akár 2009.06-osról, akár b134-ről beszélünk. Installert, meg mindent korrektül gatyába ráztak a 134-ben.

Bár vannak érdekes diverziók is:
Jobb szeretem az online doksikat, pl. elég használhatóak a hub.opensolaris.org -on levő doksioldalak, csak azok általában a fejlesztői változatról szólnak :-) Ha meg nem azt használod, akkor man. Viszont azokat korrektül karban tartják, és az aktuális manlap az aktuális verzióról szól.

...alapvetoen tobb Linux-os szervert uzemeltetek mint Solaris-t, es talan jobban is ertek az elobbiekhez, megis...

Hadd fejezzem be a mondatot az én verziómban is: "...a hányinger kerülget, amikor pl. RHEL-clustert kell konfigurálnom." :))) Vagy pl. az FC LUN-okat csak barkácsmegoldással lehet vele fölfedeztetni (újak), elfelejtetni (kizónázottak). Meg hasonló "finomságok".

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( lgb | 2010. 07. 15., cs – 13:54 )

Valahogy az az erzesem, hogy az Oracle nem merte fel, hogy a Sun "vezetoi stilusahoz" szokott dolgozok (most fokepp a "fontosabb arcokra" gondolok) community stb, nem fogja csipni, hogy az Oracle igencsak maskepp akarja csinalni. Bar lehet, ezt ok beleszamitottak a kepbe, es nem is nagyon banjak, ha ezek szepen elhuznak a cegtol? Mert erosen az a gyanum, hogy a Solaris amugy is csak teher nekik, hosszabb tavon nem akarnak foglalkozni vele.

Gondolom az nagyobb presztisveszteseg lenne, vagy hasonlo, lehet ilyen kis alattomos modon inkabb megvarjak, amig maguktol elmennek a fejlesztok, elpartol a community stb, es akkor szep csendben "kihal" a dolog, ok meg fapofaval kozlik, hogy ok pedig nem akartak megszuntetni, de most mar nem tehetnek mast. Amugy persze, naivsag lenne azt gondolni, hogy az Oracle nem a penzre hajt (nyilvan minden ceg azt teszi), de ha hosszu tavu terveiben tenyleg nincs benne a Solaris, akkor talan tenyleg megmondhatnak mar most. Eleve - ki tudja - lehet lenne ceg, aki megvenne a dolgokat, es az azzal foglalkozo emberkek es szivesebben mennenek oda. Ja, hat az meg ugye viszont konkurencia is lehetne az Oracle-nak akkor, szoval hmmm ...

Ez igy van, de a nyilt forras sem csodaszer, nezzuk csak milyen zavar tamad a Linux kernel fejleszteseben ha Linus bejelenti, hogy 2 het szabi, es nem fogad semmit addig :) Szoval kulcs ember/ceg/akarmi mindig van, kulonben kaosz az eredmeny, legyen az nyilt forraskod vagy nem. Meg mondjuk ettol fuggetlenul en attol tartok, hogy a Linux es az OpenSolaris ilyen osszehasonlitasa azert is santit, mert "kisse" kisebb az OpenSolaris kozosseg ... Plusz arrol ne is beszeljunk, hogy jelenleg meg (legalabbis ahogy en latom munkam soran is pl) a Solaris meg mindig tobbet hasznalt, mint az OpenSolaris, ez utobbi "meg fiatal", a Linux kernel esetben Linus, vagy barki mas (legyen ember vagy ceg) eltunese valoszinu csak ideiglenesen okozna zavart, nem vagyok azonban biztos abban, hogy az OpenSolaris "tulelne" azt a csapast, ha eltunik a "vedoernyo" a feje folul. Lathato (lasd egyik elozo HUP hirt) hogy maris ongyilkossagra keszulnek kvazi, ha nem akar nyilatkozni az Oracle, hogy most mi is legyen ... A Linux kernel eseteben a legnagyobb hozzajarulo ceg a fejleszteshez (ki az amugy? RedHat? csak tipp, nem tudom) eltunese nem feltetlen lenne tul nagy sokk talan, megha ereztetne is hatasat egy darabig.

a Solaris "túlélését" csak az OpenSolaris biztosíthatja, ha az Oracle hivatalosan kihúzza a falból a dugót. a Solaris régimódi proprietary rendszer. ha a tulajdonosa befejezi a fejlesztését, akkor ott vége a dalnak. kiket érdekelhet? imho sokakat. elsősorban kontinentális gondolkozású feltörekvő nagyobb országokra gondolok, mint Oroszország, Kína, vagy akár India, ahol egyébként is igen sok Solaris fejlesztő van.
egy ideje divat lett, a "mindenből legyen egy saját nemzeti változatunk mentalitás. az okok a nemzetbiztonsági megfontolásoktól a kontinentális erős nemzetállami ideáig sokféle lehet. minek kellett Oroszországnak az AMD leselejtezett drezdai gyártósora? minek kellett Kínának HD DVD a bukása után? miért jó nekik, hogy CBHD néven újrafestve most van egy nemzeti kéklézeres formátumuk?
és persze hagyományos nagy IT cégeknek is érdekes lehet, bár ők valószínűleg valamilyen formában megvennék a Solarist is az Oracletől.
ilyen lehet a Cisco, akinek egyre inkább szüksége lesz valamilyen normális unixra. ez most úgy néz ki a linux lesz, de egy saját osben is láthatnak fantáziát, ha már egyszer a serverpiacon is akarnak terjeszkedni.
imho az Apple számára is érdekes lehet a Solaris. ha az íróasztalok, nappalik és zsebek után a servertermekben is meg akarna jelenni az IT divatdiktátor Jobs, alumínium/üveg design serverekkel:) az OSX serverként igen gyengén muzsikál. egyszerűbb megoldás lehet diszkont áron venni egy nagy múltú unixot, mint helyrepofozni az OSX server képességeit.
IBM vagy HP. a két megmaradt nagy unixvonalat fejlesztő cég. mert bár lehet, hogy van saját AIXja az IBMnek, és a HPnak is van HPUX plusz elvben még létező Tru64 unixa is, de ezeket nem birtokolják 100%ban. a régi nem túl szerencsés unix üzleti gyakorlatnak megfelelően tele vannak lincencelt kódokkal. a Sun ezzel szemben egyedüliként a területen, már a kezdetektől fogva gondosan ügyelt arra, hogy tisztán tartsa a rendszerét, távol a unix licencmocsártól. az sem véletlen, hogy a Sun volt az egyetlen amely megtehette, hogy szabadon letölthetővé tegye a Solarisát még valamikor a 90es években. ezt például az IBM még akkor sem tehetné meg az AIXal, ha szándékában állna. nem költöztetheti mobiltelefonba, nem licencelheti játékkonzolba, stb. egy 100%ban birtokolt és ezért a mostaniaknál sokkal szabadabban felhasználható unix még a linux felé erősen konvergáló unix jövőben is hasznos lehet, egy régi unix hagyományokat ápoló cégnél.

az Opensso is csak túlélte az Oracle köldökzsinór elvágását. a Solaris világ természetesen sokkal komplexebb, de az érdeklődők/érdekeltek száma is nagyobb. ha egyetlen nagy cég/ország sem fog érdeklődni a Solaris után, még mindig ott vannak a közösségi fejlesztők. a DragonflyBSD maroknyi csapata is életben tudja tartani azt a rendszert. ennyien imho lesznek az OpenSolaris körül is, ha más nem is, hardcore solarisosok.
az biztos, hogy a unix jövője a Linux főszerepéről szól, de lesz ott hely több mellékszereplőnek is.

sajnos ez nem az a fajta nyilt fejlesztes h minden tibike aki irt mar hello worldot kuldhet be patchet, es mint tudjuk a FOSS fejlesztok ~70% ebbe a kategoriaba esik sajnos, igy nem hiszem hogy komoly fejleszto ezzel fogja elcseszni az idejet amikor van ezer mas project ami telleg jo ellentetben az opensolarissal ami nem sok mindent tudott felmutatni eddig

( aludanyi | 2010. 07. 15., cs – 19:54 )

Én személyesen nem a Sun termékeit sajnálom, hanem azt a környezetet, amelyben a kutatás és fejlesztés gőzerővel működött. Az Oracle ezt nem képes (és nem is akarja) fenntartani. A számítástechnika az igazi nagy vesztese a Sun-Oracle “egyesülésnek”. A Sun soha nem volt termék orientált cég, mindég képességi cég volt (capability), és a vezérötlet a cégnél az volt, hogy fantasztikus képességű embereknek viszonylag nagy szabadságot adtak és ez komoly számítástechnikai eredményeket hozott.

Sajnos a cég vezetősége túl naiv volt és nem tudott ezen az alapokon üzleti sikert produkálni. Az Oracle nem ismeri a szabadságot és nem a képesség a fontos náluk, hanem az alkalmazkodás és az összhang. Ezért az igazán kreatív emberek ott képtelenek fennmaradni és előbb vagy utóbb felmondanak, vagy ha szél ellen mennek, akkor felmondanak nekik. Az Oracle egy porszívó, amely mások munkáját tudja kamatoztatni, de ők maguk nem az innováció híveik. A Sun ennek az ellentéte volt.

( lberes (nem ellenőrzött) | 2010. 07. 15., cs – 21:35 )

Siman elkepzelheto, hogy az Oracle dobja a Solarist, mint a huzat, es kizarolag az appliance-ekre fog koncentralni (ld. Exadata - Linux).

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

( current88 | 2010. 07. 18., v – 23:10 )

Nekem rossz a memóriám, vagy tényleg kicsit gyászos a légkör az Oracle-nál. Ha jól emléxem ez nem az első elpártoló. Javítsatok ki ha tévedek, de hogy fejlődik egy cég ha a fejlesztőket elküldik?