Portál AbcLinuxu, 5. května 2025 06:43
Zpráva, na kterou komunita kolem OpenSolarisu už několik měsíců čeká, konečně přišla. Rozhodně však nejde o dobrou zprávu. OpenSolaris končí, nahradí jej Solaris 11 Express. Bude sice i nadále (z větší části) open source, ale samotný vývoj bude probíhat „za zavřenými dveřmi“. Vývojáři mimo Oracle a OTN (Oracle Technology Network) už tedy nebudou moci pracovat s aktuálním zdrojovým kódem.
Tiskni
Sdílej:
zaroven oznacovany za nejvice precenovaneho managera na svete ...
Řekl bych, že úspěchy mnohých firem existují snaze jejich CEO navzdory...Kdepak, v tom je promyšlená strategie. Když je na vrcholku někdo schopný, tak všechnu práci oddře sám a zbytek hnije. Tak je třeba postavit nahoru vola nonplusultra - a pak už podle hesla, co firmu nezabije, to ji posílí. Univerzálně platné, např. i v politice.
Presne jak jsem cekal.
coz jee tandadni postup ... vezmete nejaky produkt a uzavrene casti prepisete tak aby neobsahovaly uzavreny kod
Komunitní projekt, který nahradil všechny uzavřené binárky za open source, už dávno úspěšně skončil, splnil všechny POSIXové testy a další náležitosti a nic by nebránilo jeho začlenění. Oracle ale tento kód nepřijal. Momentálně používám build 146, který je stále závislý na closed source kódu.
Nic takoveho pravda neni. Komunitni projekt, ktery se timto zabyval, aka Emancipation projekt, nebyl nikdy dokoncen. Takze ani SUN ani Oracle nemel co odmitat. Pokud vite o nejakem jinem, sem s tim. Prvni, kdo se realne predvedl snahou tohle resit, byl az Garrett D'Amore v ramci Illumosu.Komunitní projekt, který nahradil všechny uzavřené binárky za open source, už dávno úspěšně skončil, splnil všechny POSIXové testy a další náležitosti a nic by nebránilo jeho začlenění. Oracle ale tento kód nepřijal. Momentálně používám build 146, který je stále závislý na closed source kódu.
Takže se na mailing listu lže? Pokud vím, příslušný projekt (mimo jiné) nahradil všechny uzavřené binárky.
Děkuji za podrobné vysvětlení.
Je velká škoda, že podobné zdůvodnění na mailing listu nikde nezaznělo. Byla tam pouze stížnost, že Oracle údajně odmítá začlenit kód bez objektivních (technických) důvodů. Podle toho, co píšete, bylo objektivních technických důvodů k odmítnutí toho kódu hned několik. Mlčení ze strany Oracle bylo v tomto případě zcela zbytečné. Kritizovat open-source kód vzniklý mimo Oracle se snad ještě smí...
Celá ta konspirace kolem OpenSolarisu i čekání na Godota (bájnou verzi 2010.05) byla podle mého názoru zbytečná. O spoustě věcí přece muselo být rozhodnuto už poměrně dávno (březen?) a včasné oznámení takto důležitého rozhodnutí by komunitě mohlo pomoct se trochu rozhlédnout kolem a postavit se na vlastní nohy. V pátek 13. srpna už je to spíš výsměch a kudla do zad, navíc ještě oznámená jakousi neoficiální cestou.
Já se obávám, že moc daleko ne. Zpráva od Oracle „unikla“ nějaké dva týdny po založení tohoto projektu. Je to skutečně náhoda? Nebo zkrátka podřezaná větev?
Důvod mých pochybností je, myslím, zřejný: Oracle sice hodlá uvolňovat kód pod CDDL, ale jen s každým releasem. Zatím nespecifikovali, co přesně to znamená. Může to být major verze jednou za pět let, případně maintenance release jednou za rok... Těžko říct. V každém případě je od nynějška jakákoliv externí práce s kódem (externí == mimo Oracle a OTN) naprosto marná, protože bez přístupu k aktuální repository nemůže komunita ničím přispět. Ne bez rizika, že s následujícím releasem budou všechny změny naprosto k ničemu, tedy „nemergeovatelné“. (Fuj, to je odporné slovo.)
Představte si linuxovou distribuci, která by se omezovala pouze na dlouhodobě udržované verze kernelu (2.6.18, 2.6.27, ...) a mezi nimi by neměla žádné podstatné aktualizace. Kdo by takovou distribuci chtěl??? Obávám se, že k tomuto spěje Illumos, pokud se něco zásadního nezmění.
Kromě toho, každý pokročilý uživatel Linuxu asi tuší, že v kernelu se změní řádově tisíce až desetitisíce řádků kódu denně. To pochopitelně znamená, že uživatelé Linuxu (včetně mě, přiznám se) často považují kód starší než cca měsíc za poměrně zastaralý. Otázka tedy je: Jak přesvědčit někoho, kdo se vyzná v Linuxu, aby přispíval do Solarisu? „Podívej, tady máš nejnovější (rok starý) kód, zkus tam něco změnit a za další rok uvidíš, jestli už tu samou práci neudělal Oracle...“ Ne, tohle je fakt špatně.
Mimochodem, tímto prakticky zmizí veškerá komunita kolem OpenSolarisu, která byla v akademickém prostředí. Přednášející sice může mít OTN subscription, ale nemůže o aktuálním vývoji mluvit. To aby si dával pozor na každé slovo. (?!) No a studenti? Raději se budou zabývat jinými systémy, které taková omezení nemají. Důsledkem bude, že se neseznámí se Solarisem, nepoznají jeho kvality, neporozumí mu do hloubky. A později, až budou rozhodovat o IT řešeních, mu asi těžko dají přednost.
Představte si linuxovou distribuci, která by se omezovala pouze na dlouhodobě udržované verze kernelu (2.6.18, 2.6.27, ...) a mezi nimi by neměla žádné podstatné aktualizace. Kdo by takovou distribuci chtěl???
Jako kdo by chtel debian? :)
Přesně tak. To opravdu nechápu.
Andreji, jsem jen obyčejný uživatel obyčejného Archlinuxu jakožto obyčejný akademický člověk, jemuž je IT pouze jedním z jeho zájmů.
První otázkou je, proč je Oraclem financován vývoj btrfs jako GPL projektu, když nejde o nic jiného než GPL alternativu ZFS při CDDL charakteru dědictví po Sunu. Oracle v zásadě nepotřebuje z tohoto dědictví operační systém, ale pouze jeho užitečné součásti, které usnadní využití oraclovských produktů To ale koliduje se zájmem uživatelů, kteří v OSOL měli (a dosud mají) odladěnou platformu, u níž, když se na serverech neexperimentuje, vykazuje bezkonkurenční úrovně stability a výkonnosti.
Druhou otázkou je, proč se Illumos od počátku profiluje jako na Oracle potenciálně nezávislá a vlastního vývoje schopná komunita zahrnující i duše všech na OSOL postavených projektů (zejména Anil Gulecha).
Konečně bych poukázal na téměř absolutní absenci výuky GNU/Linux na aplikačních oborech manažerské orientace, což jasně říká, že o OSOL stejně jako o Linuxu takto "vzdělaní" manažeři nebudou vědět, pokud je někdo nepostaví před hotovou věc nebo je nepřesvědčí. IT obory to, co produkují, předurčuje spíše pro komerčně zajímavé zakázky bez ohledu na technologie nebo spíše pro obyčejnou zaměstnaneckou rutinu bez nápadu. Komunitu vývojářů nemůže zahubit ni jiného než ztráta motivace a kooperačního potenciálu uvnitř, nikoli vně komunity.
``I have made this letter longer than usual, because I lack the time to make it short.''---Blaise Pascalnapriklad mam jeden opravdu vypiplany projekt, ktery i presto, ze se do nej pridava nova funkcionalita ma porad priblizne konstantni pocet radku. dalsi vec je, ze se srovnavaji naprosto nesrovnatelne veci. sice jsem zdrojaky OOo hodne dlouho nevidel a stahovat se mi to nechce. ale dokazu si predstavit, ze tam bude velke mnozstvi kodu souvisejiciho s GUI... coz je kod, ktery relativne rychle roste pod rukama bez intenzivnejsi namahy. navic jestli tam praktikuji, to ze kazdy objekt ma par desitek setteru a getteru jako v jave, kod budu rust jeste rychleji. na druhou stranu kernel obsahuje vcelku slusne mnozstvi kodu, kde zalezi na nastaveni kazdeho bitu a ladit takove veci, je opravdu prijemny zazitek...
V praxi projekty kde při rostoucí funkčnosti klesá počet řádků jsou velmi vzácné.u dobre hlidaneho projektu nemusi dochazi k poklesu poctu radku... ale muze dochazet k tlaku at je kod co nejefektivnejsi do objemu... a tak nebude bobtnat tak rychle
Naopak vámi zmiňované GUI, to mě rozesmálo, to se od dob 2.O (2005?) prakticky nezměnilo.to jsem dal jenom jako priklad... s kterym mam konkretni zkusenost a proto muze treba OOo mit od zacatku vetsi mnozstvi kodu. ale je fakt, ze podpora ruznych formatu obzvlast, pokud jsou postavene na XML taky dokaze nafukovat velikost kodu.
Ohalování chyb jako artefakty na canvasu, které se vyskytnou jen když je nečekáte a zásadně nikdy když to máte v debuggeru, prakticky to nejde nijak unit-testovat.v nizkourovnovem programovani je zase podobna zabava treba s race-conditionama... a pokud v tom figuruje jeste nejaka HW komponenta je to jeste vetsi prdel.
Musíte podporovat hromadu cizích formátů, ke kterým není pořádná dokumentace a stále něčím dokážou překvapit, a jen to jakš takš doděláte, konkurence vydá další a jste zase na začátku, podporovat ho musíte neboť konkurence má většinu trhu a když podporovat nebudete, uživatelé utečou.v jadre zase musíte podporovat hromadu hardwaru (vlastne jadro neni nic jineho), ke kterým není pořádná dokumentace a stále něčím dokážou překvapit, a jen to jakš takš doděláte, firma vydá další kus zeleza a jste zase na začátku, podporovat ho musíte neboť konkurence má většinu trhu a když podporovat nebudete, uživatelé utečou.
Problém je v tom, že kód se bude uvolňovat jako open source až po uplynutí blíže nespecifikované doby od binárního release. Tudíž FreeBSD bude stále „pozadu“, pokud jde o ZFS. Kompatibilita bude fungovat jen jedním směrem (FreeBSD -> Solaris), nikoliv opačně.
To by i lepe sedelo k tomu, jak oracle funguje.
Ale BSD to taky nemusi resit, muze prohlasit ZFS za "bsdfs2 next generation" a vyrabet si vlastni verzi. Vzhledem k tomu, jak oracle zakazal provozovat solaris na jinem nez jejich hw nebo bez tucnych poplatku, tak kompatibilita nemusi nikoho zajimat.
Obávám se, že to je pouhý sen.
nevyvija "náš" linuxovsky BTRFS filesystem do ktoreho tolky skladaju nadeje prave ten "dobrak" ORACLE ?
jj, takze se muze stat ze v solarisu 11 bude vychozi brtfs a nebo nejaka smes tech dvou:)
OT: zajmavy je celkem HAMMER z DragonflyBSD
v roce 2004 kdyz jsme vlezli do EU jeden anglan nam dekoval ze sme tam vlezli ....
S vysvetlenim "Kam vlezli Cesi .. TO SE ROZPADLO"
S tou podobností bych to nepřeháněl.
POSIX nemá s kernelem žádnou souvislost. Stačí se podívat v UTS kernelu na rozhraní pro semafory nebo vlákna. Podobnost s POSIXem bych tam opravdu nehledal. POSIX souvisí pouze s uživatelským prostorem. Je implementovaný standardními knihovnami, které tvoří vrstvu mezi standardním a portovatelným API a syscally specifickými pro daný kernel. Struktura syscallů ani jejich implementace uvnitř kernelu není žádnou normou stanovená. Proto se může zásadně lišit.
Open source NT kernel vytváří projekt ReactOS. Nikdy jsem ten systém nezkoušel, takže nevím, zda je prakticky použitelný.
Zda je Linux „lepší“ projekt než Solaris, s tím nemůžu ani souhlasit, ani nesouhlasit, protože netuším, jak je definováno „lepší“.
Pokud jde o ten údajný balast v Solarisu, asi by to chtělo nějaké konkrétní příklady. Pokud jde o samotný kernel UTS, žádného balastu jsem si nevšiml. Pokud jde o orthodoxní přístup ke 32-bitové kompatibilitě a o podporu pro spouštění binárek ze SunOS 4.x (konec 80. let) na dnešním Solarisu, to není balast, ale prostě feature. Zpětná kompatibilita je prostě důležitá vlastnost toho systému. Kdyby ji zákazníci nežádali, asi by tam nebyla, že jo.
Já bych jednoznačně uvítal distribuci Solarisu, která by byla výhradně 64-bitová, bez dvojí verze knihoven, bez isaexec
a bez podpory pro 20 let staré closed-source programy. I přesto se ale zdráhám nazývat zpětnou kompatibilitu balastem. Všechno má svůj důvod.
Časem se od Larryho stejně uživatelé odvrátí, pokud bude pokračovat zvolenou cestou...
Už dvacet let se vypráví, jak se co nevidět (asi tak do roka) uživatelé odvrátí od nějakého Billa a Steva. Faktem je, že se nic takového nekoná.
Zony jsou ovsem v solarisu extremne zrave a support vse nad 10 zon odmita malem resitNa druhou stranu implementace zón v Solarisu je v produkční kvalitě, což se o OpenVZ úplně říct nedá. Support OpenVZ pod linuxem pokud vím žádná enterprise distribuce taky nemá.
Na zony ma linux jednoduchou odpoved: OpenVZ ... na jednom beznem x86 serveru jich bylo pusteno pokud vim pres 150.000 a porad v pohode ... pravda, prazdnych zonOpenVZ je dobrá technologie s malou režií, ovšem jak už jsem napsal, není to úplně rock-stable (ve srovnání se samotným jádrem).
A ZFS neni zase takovy zazrak, za ktery se vydavaZFS možná není takový zázrak, ale o ničem lepším nevím. Tvrdí se, že btrfs by mohl být dokonce lepší, ale k produkčnímu nasazení mu chybí ještě nekolik let. ZFS je velmi dobře otestovaný v reálném prostředí, a to se počítá.
ja osobne moc nemam rad spojovani veci dohromady, radeji samostatne celkyIdea samostatných celků je dobrá. Ovšem v tomto případě integrace těch komponent přináší skutečně zásadní výhody: při přepočítávání raidu se např. ví, které bloky jsou nevyužité; u LVM jsou snapshoty ve srovná se ZFS těžce nepoužitelné - LVM snapshot např. přináší degradaci výkonu, snapshoty ZFS jsou levné, lze jich vytvořit velké množství jako zálohy; snapshoty zabírají tolik místa kolik je potřeba, není třeba alokovat prostor předem jako u LVM. Kvalitní podpora NFSv4 ACL. A tak by se dalo pokračovat.)) ... takze Sw_RAID, LVM a FS
Mimochodem, tímto prakticky zmizí veškerá komunita kolem OpenSolarisu, která byla v akademickém prostředí.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.