Vége a Solaris fejlesztésének?

Solaris, OpenSolaris, Illumos

A leépítéseket a cégek általában igyekeznek titokban tartani, a velük kapcsolatos információkat általában igyekeznek visszatartani. A 2009 eleje óta működő Thelayoff.com online fórumon lehetősége van a dolgozóknak anonymous módon információkat megosztani a cégek tervezett leépítéseiről. Az oldal egyik bejegyzése szerint a Solaris fejlesztésének napjai meg vannak számlálva:

Solaris being canned, at least 50% of teams to be RIF'd in short term

All hands meetings being cancelled on orders from legal to prevent news from spreading.

Hardware teams being told to cease development.

There will be no Solaris 12, final release will be 11.4.

Orders coming straight from Larry.

No info on timing yet.

További részletek a fórumtopikban.

( mgabor v | 2016. 12. 02., p – 19:19 )

Rosberg visszavonul, megszűnik a solaris, mi lesz még ma? :)
Komolyra fordítva a szót én nagyon sajnálnám.

( lacika v | 2016. 12. 02., p – 20:17 )

Nagy kár lenne, szeretem nagyon, jól összerakott OS. Bár nem olyan rég, az év elején egészen más "belső" infókat kaptunk egy Oracle ZFS előadáson. Elég sok energiát, erőforrást belenyomtak a fejlesztésbe az akvizíció óta. Meg egy anoním bejegyzést nem veszek kézpénznek.

Csak közben felfutott az OpenZFS, ami implementálta a Solarisos ZFS minden tudását, és egyre jobban terjed.
Ez egy nagy előnye volt a Solaris-nak, de így, hogy az előny megszűnik, már lehet kevésbé éri meg fejleszteni, főleg mert az Oracle-nak saját Linux disztrója is van (igazából a radhat végzi a nagy munkát, de lehet ők is jobban rá akarnak kapcsolni a fejlesztésére), amiben valószínű könnyebben tud full OpenZFS támogatást szállítani mist más disztrók.

Ha megkérlek, kifejtenéd bővebben.
Tényleg érdekel mindkét téma. Egyre többet foglalkozom ZFS-el és épp most építek ki egy rá épülő tárolót, és nagyon érdekelne, milyen OS lenne a legmegfelelőbb alá, és mivel tud annyival többet az eredeti Solaris implementáció és egy OpenZFS-re épülő 5000-es feature set-el szállított ZFS.

Sajnos a Solarist illetően is tájékozatlan vagyok, mivel azon túl, hogy stabilabbnak és kiforrottabbnak tartom annál fogva, hogy egy Enterprise UNIX, konkrétan nem tudom a fő előnyeit.

Nálam jóval képzettebb szakemberek taglalják az internet több bugyrában is azt, miben térnek el az egyes platformok implementációi, én azt állíthatom csak bizton első kézből, hogy Linux alatt bizony vannak komoly problémák a snapshot-ok replikációja körül, de még illumoson is volt pár olyan esetem, hogy bedőlt egy komplett pool egy-egy - más jellegű - bug miatt. Solarison nemigen jártam így. Ha pedig a feature-öket nézzük, nagyon magas szintű integrációt élvez Solarison a ZFS a rendszer többi komponensével, ami nincs így másutt, továbbá az upstream ZFS tud például natívan titkosítani, aminek a hiánya OpenZFS-en számomra kellemetlen és nyűgös workaround-ok használatára kényszerít. Ami a Solarist illeti, az egész rendszer minden szintjét jellemzi a magas fokú ellenőrizhetőség - ennél okosabban nem tudom elmondani. Nézd meg továbbá a zones (aka. containers, ha rctl-t is használsz, és miért ne tennéd) feature-t - máig az egyik legkomolyabb fegyvertény a szememben mellette. (Ez utóbbit mondjuk illumoson is megkapod, ha néhol kevésbé gazdag feature-készlettel is.)
------------------------
{0} ok boto
boto ?

Kösz az infókat.
A gond azt hiszem itt a ráutaltságban van. Ahol én dolgozom ott a linux is megfelelően stabil, igaz néha a kontrol és monitorizálás terén érzek hiányosságokat, de ez nem elég ahhoz, hogy váltsunk, vagy akár csak megfontoljuk a váltást. A zones, az olvasottak alapján, kb megfelel az LXC/Docker megoldásoknak, de gondolom annál fogva, hogy még az OS is abban van "telepítve" messze jobb és stabilabb implementáció.

Most konkrétan engem a ZFS storage oldala érdekel, tehát, kevésbé kritikus, hogy az OS milyen részeivel integrálódik tökéletesen, másrészt nem fogunk beruházni Solaris-ba, tehát a maximum ami szóba jöhet, hogy ne linux legyen az OS.
Igazából 3 opcióm van, ahogy én látom:
Ubuntu
FreeBSD
OpenIndia
Ahogy látom mind 5000-es feature set-et használnak, tehát az OpenZFS implementációt (a titkosítás jelen pillanatban nekem nem szempont, a replika viszont nagyon is). Az nem világos számomra, hogy a két Unix jobban/stabilabban implementálja-e az OpenZFS-t mint a linux, és megéri-e ezért számomra ismeretlen OS-t használni.
A másik sarkalatos pont az NFS/ZFS integráció, ami talán a két Unix-ban jobb, de még erre sem találtam konkrét adatot.
Egy éve használunk egy hasonló storage szervert, amin "demózni" akartuk, hogy mennyire működőképes egy ilyen megoldás, és 300+ nap uptime-al egyelőre tökéletesen üzemel. Napi 1 snapshotot replikálunk egy másik gépre, és jelenleg 20-25 virtuális gép fut rajta, pedig csak egy demo gép, igaz kb ez is a vége, amit elbír (hp szerver, 4 sata hdd, 2 ssd cache).
Neked milyen helyzetben volt problémád a replikákkal, mert mi még sehol semmilyen problémába nem ütköztünk bele?

A Zones az 5.10-zel jelent meg 2005-ben - gondolj bele, mennyire lehet kiforrott, ha a derivatívok is mind használják, olyannyira, hogy a Joyent a SmartOS nevű, saját illumos distro-jában még tovább is fejlesztette (LX) és nagyon aktívan épít rá. Az OpenZFS a feature-öket a hagyományos upstream verziószámozás helyett ún. "feature flag"-ekkel jelöli, ezeket lehet kellően fejlett software-t futtatva sorra aktiválni a pool-okon. Az az 5000 gyakorlatilag éppen ezt hívatott jelölni - merthogy talán 28-nál forkolták 7 éve, és az upstream, ha nem tévedek, még mindig 3x-nél jár, így nincs az a sanity check, amin ki ne bukna, hogy itt valami másról van szó... A BSD-s implementációt gyakorlatilag mindenki stabilabbnak mondja azokat kivéve, akik "hazabeszélnek" a ZoL projekt részéről. Jómagam nem használtam, csak Solarison, illumoson (SmartOS) és Linuxon (Gentoo). Az NFS integráció annak idején Solaris 11.1-ig bezárólag biztosan - addig foglalkoztam vele - nagyon kényelmes volt: gyakorlatilag a dataset sharenfs property-jének értékadásával létrejött az export. (zvol-ok esetében iSCSI target alá lehetett LUN-okat adagolni ugyanígy, hihetetlen hasznos) Az én konkrét problémám több tíz gigabyte-os snapshotok replikációja során jelentkezett: az átvitel során gyakorlatilag az egész folyamat lefeküdt valahol félúton: az átvitel belassult, majd megállt és sosem indult ismét újra, viszont az azt megtestesítő process is beakadt, irreszponzívvá vált, majd véglegesen holt teherré avanzsált. Kisebb delták gond nélkül mentek. (Ez a jelenség talán szűk 3 hónapja lépett fel, akkor friss kódállapotok mellett.) OpenIndiana-t nem használtam, de az egy általános desktop célú illumos distro, talán az egykori OSOL mai örököse.
------------------------
{0} ok boto
boto ?

Én 1-3 TB-s kezdeti adatot replikáltam már 3 vagy 4 alkalommal, és pár GB-s (1-50) snapshotokat. Eddig még nem lépett fel hiba.
A gyors olvasgatások alapján nekem az OpenIndia tűnt a leg solarishűbb illumos alapú "disztrónak", de szerver célra javasolhatsz mást is, ami ingyenes/szabad.
Az OmniOS-t és a Napp-IT találtam, de nem tudom mennyire kiforrottak lehetnek.

Nem India, Indiana! Általános servernek OmniOS talán; én SmartOS-t használok. Nincs olyan illumos distro, ami nem "Solaris-hű", mindössze a célzott felhasználási területek térnek el. Az OI ma az, ami egykor az OpenSolaris volt, ahogy mondtam. A Nexenta storage-célú, a SmartOS egy hypervisor, a Napp-It pedig egy alkalmazás, nem distro. Gyakorlatilag egy front-end storage funkciókhoz.
------------------------
{0} ok boto
boto ?

és mivel tud annyival többet az eredeti Solaris implementáció

Az egyetlen, vendor által támogatott implementációról beszélünk, ugye. Nyilván for home use ez senkit nem érdekel...

Sajnos a Solarist illetően is tájékozatlan vagyok, mivel azon túl, hogy stabilabbnak és kiforrottabbnak tartom annál fogva, hogy egy Enterprise UNIX, konkrétan nem tudom a fő előnyeit.

Minden más UNIX vagy nem fut x86-on (ergó nem megy commodity hw-en), vagy nézheted, hogy ki fogja supportálni (ugye x86-on van még kb. a Linux, aminek nincs egy kézben az irányítása és a supportja, ennek minden következményével, a többi játékos pedig csak vendor-only saját vason megy).

( haspokember | 2016. 12. 03., szo – 12:39 )

Hatha a Java lesz a kovetkezo, bar tanult kollegam inkabb a MySQL-re fogad...

A Java világ (sajnos) sokat profitálna abból, ha az Oracle jelenlegi formájában eltűnne a képből. Meg lehet nézni, hogy milyen ütemben halad a JDK9 fejlesztése, és milyen gányolás folyik a Google-nél Android vonalon.

Pl. nem olyan rég tolták el a feature complete milestone-t _ismét_ a JDK9-nél egy olyan durva tervezési hiba miatt a module támogatásban, aminek már évekkel ezelőtt ki kellett volna derülnie. És itt nem (feltétlenül :) ) arról van szó, hogy dilettánsok csinálják, hanem a fejlesztési folyamatból következik.

De a Google meg a másik fele: Android 7-ben már "van" Java 8 támogatás (már ez is egy vicc)...de pl. az OpenJDK forrásokat úgy húzták be magukhoz, hogy még véletlenül se legyen egyszerű syncben tartani az upstreammel -- és elkezdték szétgányolni, hogy meglegyen a "bug for bug" kompatibilitás a korábbi Android runtime-mal.

Szóval kifejezetten hasznos lenne, ha a Java világban kicsit felkeveredne a sz*r és nem csak egymás beperlése lenne a fő műsorszám.

Ez új, a Google-féle Java 8 támogatás...

* Default and static interface methods
* Lambda expressions (also available on API level 23 and lower)
* Repeatable annotations
* Method References (also available on API level 23 and lower)
* Type Annotations (also available on API level 23 and lower)

Ebből a lambda, method reference, type annotation dolgot API level 23 alatt a JVM bájtkód -> dex fordításnál trükközik meg, hogy az Androidos VM-en is fusson? Ha igen, a repeatable annotations miért nem fért abba bele, vajon? Ennek utána kéne olvasnom, mindenesetre érdekesnek néz ki. (szerk, közben látom, kidobták a .class-ra fordítást is... a végén csak nem, tényleg leváltják a Java-t az Android tetejéről?)

S ez azt is jelenti, hogy az Android 7-tel már kaptam egy Swinget, meg egy JavaFX-et a telefonomra? Vagy azt ezért kigyakják belőle? S akkor miért lett az OpenJDK alapú Android runtime jobb, mint az Apache Harmony alapú?

A többire +1...
--
blogom

Igen, kb. úgy oldják meg ezeket mint a Retrolambda csinálta, csak ők a saját Jack toolchainükbe építették bele. (vendor lock-in FTW)

A .class-ra fordítás itt nem annyira fontos, mert a lényeg, hogy a Jack tud .class-ból is dolgozni, és ha megeszik Java 8 forrást / .class-t inputnak, akkor már mindegy, hogy közvetlenül .dex-re fordít. A Jack egyébként ProGuard funkciókat is integrál, meg tud daemonként is működni, szóval a build teljesítményt is javítja, ami nem feltétlenül rossz dolog. De ettől még vendor lock-in.

Swing-et nem fogsz kapni ettől, JavaFX-et is csak ha portolva van (és van Androidra port, eddig ha jól tudom retrolambdát használtak a Java 8 supporthoz).

OpenJDK-nak két oka van:
- jogi, az Oracle-Google per miatt
- technikai: a Harmony-t legalább 5 éve nem fejlesztik, Java 8 class library updatek sincsenek benne, semmi értelme tovább szenvedni vele. Az Android annyira elterjedt már, senkit nem fog zavarni, hogy van benne LGPL licencelt kód (ez az Android 1.0 idején sokkal nehezebben eladható lett volna).

Szerintem abbol profitalna a legtobbet a Java vilag, ha a Java, mint nyelv, atmenne @Deprecated-be (mellekszal: amikor a programban mar tobb az annotacio, mint a tenyleges kod, az talan jelez valamit...).

Kellene egy olyan ujragondolasa a Javanak (mint nyelvnek), mint a C-nek a Go. Futhatna az uj nyelv a regi JVM-en, es nyilvan szupportalhatna a regi libeket. De teljesen ujra kene kezdeni.

Sajnos nem latom azt a piaci szereplot, aki ezt meg tudna csinalni. Talan a Google, ha megunjak az androidos szenvedest, es valamelyik 20%-os projektjukbol kipottyan valami hasznalhato. Vegulis egesz jo eddig az arany: a Dart elbukott, a Go sikerult, Python fronton nem tudom, mi van (illetve ha a Python 3-at idevesszuk, akkor meg egy bukta).

A mysql-t soha nem fogja eldobni Larry. Ingyenes megoldás és ha használod akkor már bent vagy az Oracle-nél. Ez fegyvertény ebben a világban.
Meg még mindig vannak olyan vaskalapos csávók akiknek adatbázis=ora. (és ez egy olyan dolog amivel nem tudok és nem is akarok vitatkozni lol...)

--
GPLv3-as hozzászólás.

Ezt kifejtened? Amennyire emlekszem, a MySQL es az Oracle adatbazis semmilyen formaban nem atjarhato, kompatibilis, SQL szintaxis teljesen kulonbozik, az adminisztraciorol nem is beszelve.

Szoval attol, hogy MySQL guru vagy, egy Oracle DB-ben meg egy usert sem fogsz tudni letrehozni. Vagy rosszul tudom?

Az egyetlen dolog, amit el tudok kepzelni, hogy az Oracle ad a sajat enterprise megoldasaihoz mindenfele migracios eszkozt MySQL-rol. Meg persze fizetett supportot. De egyik sem latszik akkora biznisznek, hogy kulonosebb vizet zavarjon.