Az Oracle megvásárolja a Sun Microsystems-t

 ( trey | 2009. április 20., hétfő - 13:48 )

Az Oracle Corp. (NASDAQ: ORCL) és a Sun Microsystems, Inc. (NASDAQ: JAVA) ma bejelentette, hogy az Oracle ~ 7,4 milliárd amerikai dollárért (részvényenként 9,50 dollár) megvásárolja a Sun-t. A részletek itt olvashatók.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez meglepett...

Talán ez jobb, mint ha az IBM vette volna meg. Itt talán kevesebb az egymást átfedő szakterület.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

Mysql vs oracle sql??? szerinted melyik megy a devnullba?

A'rpi

muszaj mennie valameknek?

--
>ami belassu, az hirtelen nem benchmark

egy nyílt forrású projektet csak egyvalami tud a /dev/nullba küldeni, az érdektelenség. ebben az esetben erről szó nincs. így ha az Oracle fiókba tenné a Mysqlt, születne egy fork és minden menne tovább, csak új néven. természetesen az Oracle nem ostoba, a Mysql pedig jó pénzt hoz. lásd kormányszóvivő.hu:)

sztem is...
es epp ezert kellet neki a mysql.. lefedi az egesz piacot (oracle+mysql)
mondjuk azt eltudom kepzelni hogy megszunteti a supportot mysql hez

--
>ami belassu, az hirtelen nem benchmark

Te totál megőrültél? Ha valahogy pénzt lehet realizálni a mutyisql-ből, az a támogatás/konzultáció:)

igen.. de oracle bol tobbet ...

--
>ami belassu, az hirtelen nem benchmark

ez igaz, viszont a ma oly divatos cms alapú webszerverek alá a Mysql a legjobb megoldás, és egyben a leggyorsabb. az Oracle erre nemcsak feleslegesen drága, de lassú is lenne. és ahogy a fenti kormanyszovivo.hu példája is mutatja, nagyon is van erre fizetőképes kereslet.

meglatjuk mi lesz..
remelem nem lesz nagy valtozas a software reszlegben

--
>ami belassu, az hirtelen nem benchmark

"ma oly divatos cms alapú webszerverek alá a Mysql a legjobb megoldás, és egyben a leggyorsabb. az Oracle erre nemcsak feleslegesen drága, de lassú is lenne"

Ezt a sok baromságot magadtól találtad ki, vagy segített valaki más is?

Javítsd ki nyugodtan, ha máshogy tudod.

választ ne várj. ahhoz ismernie kellene az aláhúzott szavak jelentését is:D
bizonyára a tanárnénije is alá szokta húzni a szavakat a dolgozatában:)

>> ismernie kellene az aláhúzott szavak jelentését is:D

sajnos rögtön az elején elakadunk, mert nem mindannyian vágjuk az olyan szakzsargont, mint a 'cms alapú webszerverek'

Amit irsz, azt magadtol irod, vagy helyetted utik a billentyuket?
Mondd mar meg, hol ertelmes megoldas akar a XE akar egy rendes Oracle mondjuk akar egy hup.hu szintu oldal ala is? Boven nincs annyi lekerdezes, hogy megerne, szamitasi feladat gyakorlatilag nulla, ellenben az Oracle XE nagyon hamar hatarokba utkozne, a nagy Oracle meg baromi draga, ha support is kellene hozza, plusz az eroforrasigenye messze meghalad egy rendes MySQL-et. Szoval szerintem a MySQL az egyik legjobb megoldas (a masik a PostGres) a mai CMS alapu weboldalak gyors es hatekony kiszolgalasara. De tenyleg erdekelnek reszletesebb tesztek/tapasztalatok eles helyzetben mukodo Oracle hatteru CMS rendszerek mukodteteserol, melyek megcafoljak a fenti ervelest. Ha csak annyit mondasz, hogy hulyeseg, akkor valami hasonlot fogok en is irni.

--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mysql ilyen kisebb protalokhoz elmegy Facebook.

20 esetbeol 19-nel mysql is helytalna ott ahol most Oraclet hasznalnak, de ez most mindegy.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én "láttam" már Oracle XE-t, és néhány dolgon ütköztem meg:
* nem tudott több adatbázist, vagyis csak a sémákkal lehetett játszani
* a 4GBájtnyi maximális adatbázis méretből 700MBájtot elzabált saját célra
* feleslegesen sok memóriát használt
* kis kéréseket lassan szolgált ki
* egy kapcsolat felépítése rendkívül költséges művelet volt

Irreális egy ilyen adatbázis motort tenni egy olyan rendszer alá, amelynek még egy MySQL is nagy, egy SQLite vagy egy HSQL tökéletesen elég... hiszen pont ezért léteznek ezek az SQL motorok, mert egyszerűen baromság lenne Oracle XE-t tenni arra a helyre.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

flat txt miert nem jo?
--
.

Vannak esetek, amikor az is megoldás, de akkor már inkább JAXB... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

CSV azt barmi megragja :)
Barmi masban is kiegyezhetunk :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mindent a helyére tesznek az alsó szegmensben.
Lesz Oracle DB XE, 1 CPU, 1 G RAM, 1 TB diszk.
Lesz MySQL XE, itt a jelenlegi skálázhatósági maximumot veszik alapul, azaz 2 CPU, 4G RAM, 1 TB diszk.
Esetleg kiadnak még egy Postgres-adaptációt, hogy teljes legyen az adatbázis-portfólió.

loal :)

Bocsánat, a korrektség megkívánja, hogy a 2 CPU mellé odaírjam, hogy azok legfeljebb négymagosak lehetnek. :)

mi ez a kesoi komment? :)

Be kellett még kerülni az oracle identity managerbe, hogy ki tudjon jönni a proxyn. ;)

haha :) szerencsere me'g nem. :)
az IM amugysem kell ahoz, hogy natolva legyel :)

nade, ezeket Te kimerted, vagy csak ugy mondod? en anno neztem, es a magok szama*2 -ig jol skalazodott, de ez meg azelott volt, hogy az innodb mutexeket finomitottak volna. elvileg az 5.1 mar tud linearisan skalazodni sokaig.. :)

de kene szerezni egy X4450et vagy egy T5140et, es kimerni. ha valaki ad, szivesen megcsinalom :)

:(
--
.

hmm, ez érdekes fordulat
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

viszlát mySql?
viszont ők érdekeltek a Java-ban

jajj, ne, BME-n szerveztek Oracle-ös előadásokat, és kb a fele abbol áll, hogy elmesélik, milyen cégeket vettek meg. Most majd ezt is elmondják. dejólessszzz

Nem kötelező ott lenni.

milyen igaz:)
sőt, mivel kényelmetlenek az egyetemi székek, inkább egyetemre sem járok mostantól

A MySQL sosem volt riválisa az Oracle DB-nek. Az előző japán bevásárló kisautó, az utóbbi utánfutós teherkocsi. Én inkább azt várom, hogy a MySQL fejlesztése megint felpörögjön, utóbbi időben nagyon le van maradva.

--
The Net is indeed vast and infinite...
http://gablog.eu

Én arra számítok, hogy a MySQL-t nem venné át az Oracle.

Miert, mit csinalna vele? Nem hagyhatnak meg 8.923 db torzsreszvenyt a piacion, hogy az a MySQL.

Hangsulyoznam, hogy a MySQL soha nem volt rivalisa az Oraclenek DBMS-nek. Ezzel pont hogy egy szep belepo kategorias termekre tettek szert.

--
The Net is indeed vast and infinite...
http://gablog.eu

Mert hasonlót nem gyárthatnának saját kútfőből, ha akarnának...

Ave, Saabi.

Azért a mysql elég nagy bázissal rendelkezik bizonyos területeken, pl kis/közepes forgalmú website-ok, stb.

********************
http://holo-media.hu

És a kis/közép forgalmú websitek hány %-a vesz supportot MySQL-hez?

----------------
Lvl86 Troll

zero

#edit: mondjuk kerekítettem.


No rainbow, no sugar

És a néhai MySQL AB. miből élt a felvásárlásáig?

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

Ja, azért vették meg az InnoDB-t is.

Miért nem riválisa az egyik adatbázis kezelő a másiknak? (az ok, hogy nem egy súlycsoport de attól még ugyanaz a sportág...)

Pontosan, egyaltalan abszolut nullaban rivalisa az egyik a masiknak. Igy pont jol kiegeszitik egymast: lesz egy belepo kategorias DBMS, amivel belep az ugyfel az Oracle univerzumba, es ha kinovik a MySQL-t, mar lehet is eladni az Oracle licenceket.

--
The Net is indeed vast and infinite...
http://gablog.eu

Azert, amiert a Gellert szallo es a Burj al Arab sem rivalisa egymasnak, es ahogy a Gundelnek sem rivalisa a sarki kifozde. Mas a celkozonseg.

Ha nem tudsz Dubaiban megszallni, akkor nem fogsz ezert Budapestre atjonni. Ha nincs hely a Gundelben, nem teheted at a sarki kifozdebe a targyalast, ugyanakkor ha csak az utobbira van penzed, az elobbibe nem fogsz beterni.

Ha a MySQL megfelel az igenyeidhez, akkor nem fogsz Oracle DBMS-t licencelni, ugyanakkor van olyan eset, amihez a MySQL keves. Ha komoly rendelkezesreallasra van szukseged, akkor a feladathoz valoszinuleg apropenz az Oracle support. Ugyanakkor sok esetben az Oracle teljesen felesleges (az XE is). Nem tudom, hogy a MySQL miert elterjedtebb, mint az Oracle XE, de elterjedtebb, es ezert erdemes tamogatni mar a neve miatt is. Ha nagyon nem kell nekik (vagy a trosztellenes csapat belekot), legfeljebb eladjak valakinek ezt a reszet.

Lattam mar olyan esetet, amikor egy serveren rajta volt Oracle es MySQL is. Utobbit valami webes cucc hasznalta, es nem erte volna meg atalakitani a kodot ugy, hogy az Oracle-t hasznalja.

--
"ne támogasd az erdők kiírtását mozijeggyel, töltsd le a netről!" - killllll, asva.info

Idézet:
Lattam mar olyan esetet, amikor egy serveren rajta volt Oracle es MySQL is.

Ez nálam elég rendszeres, mivel WordPress alapon szoktam megcsinálni a gépeken az üzemeltetési naplót. Egyrészt nincs kedvem, időm és tudásom átírni a WordPresst, másrészt az üzemeltetési naplónak semmi keresnivalója a valódi munkát elvégző Oracle adatbázis(ok)ban.

Ave, Saabi.

miért fejlesztenék tovább? A BME-s előadást is azzal kezdték, hogy a magyar vezér vagy ki elmesélte, hogy az opensource szar:) a kedves nézőknek kellett megindokolniuk, hogy miért.

az Oracle redwoodi irodaházainak portásai is fontosabb személynek számítanak, mint a magyar rezidensük:)

Ezzel pont hogy egy szep belepo kategorias termekre tettek szert.
hahahahaha

ezt a belepo kategorias terméket, olyan belepo kategorias cégecskék használják infrastruktúrájuk egyik alapvető részeként, mint a Google, vagy a Facebook:)

Miert ne lenne rivalisa? Attol fugg hol, persze. Nalunk jartak fejlesztok, akik boldogan bologattak, amikor arrol volt szo, hogy egy kulso adatbazishoz kene kapcsolodnia, csak akkor fagyott le a mosoly az arcukrol, amikor mondtuk, hogy MySQL, a kerdes ez volt: de miert nem Oracle? A vicces a dologban az, hogy a feladat bozasztoan primitiv, gyakorlatilag mezei select-ek, semmi sub query, migymas, mondhatni egyszerubb nem is lehetne, de ok meg itt is kardoskodtak, hogy ide Oracle kell, aztan szep szamokat hoztak ki, hogy mennyi lenne, majdnem seggreultunk tole. Na ez a tipikus hely, ahol pl miert ne lehetne rivalisa. Nyilvan vannak sokkal komplexebb, es "erzkenyebb" teruletek is az adatbaziskezelesnel, ott lehet mas az abra azert ...

Szerintem a konkurencia dolgot _értelmes_ körülmények között értették.

(Egy kezdő sokat tanul a hup-os hsz-ekből az adatbázisokról.. like me)

Ugyan miért ne? Benne van a csaomagban, majd pont az adatbázis kezelőt nem kéri az Oracle. Az InnodDB már úgyis az övék volt ( http://www.oracle.com/innodb/index.html ) , most már szőröstül-bőröstül az övék. Kiváncsi vagyok mi lesz ebből.

> Benne van a csomagban, majd pont az adatbázis kezelőt nem kéri az Oracle.

Én a helyükben nem tartanám meg. Inkább visszaadnám Widenius-nak, hogy ezzel javítsam az Oracle megítélését. A visszaadás marketing értéke nagyobb lehet, mint a megtartás gazdasági értéke.

ki előtti megítélését? :DDD

Hát én nem vagyok egy nagy üzletember, de inkább legyen konkurrenciám házon belül mint kívül... Visszaadás marketing értéke nagyobb mint a gazdasági értéke? Ne viccelj már. Pár hozzászólással feljebb van egy nagyon gyakorlatias meglátás: a mysql kiváló csalétek lesz az oracle komolyabb termékeihez. Ez kapitalizmus és nem grál lovagok kerekasztala.

> a mysql kiváló csalétek lesz az oracle komolyabb termékeihez.

Szerintem a jó csalétek a komolyabb termékeket modellezi (ugyanaz a szintaxis és a szemantika, mint a komolyabb termékeknél). Aki kinövi a modellt, egyszerűen át tud térni valami komolyabbra. A MySQL meg szerintem nem modellezi az Oracle komolyabb termékeit, ezért nem lehet jó csaléteknek.

> Visszaadás marketing értéke nagyobb mint a gazdasági értéke?

Megér-e neked* egyszeri 50 Ft-ot kiadni, hogy "zilahu jó csávó" hírek jelenjenek meg a sajtóban, vagy inkább szeretnél havi 5 Ft-os kiadás mellett egy év eltelte után havi 2 Ft plusz bevételre szert tenni?

*a számokon biztos lehet javítani, az arányok számítanak. Oracle bevételei helyett vegyünk átlagos havi jövedelmet; az 50Ft az a pénz, amibe az ajándék MySQL megvásárlása kerül a havi jövedelemhez arányosítva, a havi 5 FT a MySQL karbantartásába, fejlesztésébe kerülő összeg, stb. A lényeg az hogy az ismerős nagyságrendbe eső számok megkönnyítsék a helyzet átélését.

a mysql kiváló csalétek lesz az oracle komolyabb termékeihez
Az Oracle-nek van saját "csalétke": Oracle XE-nek hívják, ingyenes, és kiváló belépő termék.

Én sem vagyok gazdasági szakember, de nem látom miért lenne kiváló csalétek az Oracle-nek a MySQL.
Ettől persze megtarthatja, és fejlesztheti is, de nem mind "kistestvér".

a.

állítólag az Oracle régebben meg akarta venni a MySQLt de az nem hagyta magát
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Nem állítólag.

Kösz, ezt nem tudtam,

amúgy csak próbáltam utalni, hogy a MySQL nem biztos, hogy "belépő" az Oracle világába.
Az egykori próbálkozása az Oracle-nek sem biztos hogy azért volt, hogy találjanak egy kistestvért, inkább portfólió bővítés - már ha lehet ezt itt értelmezni... :)

Aha, csak a Oracle XE rendszerigenye magasan a MySQL-e folott van. Igenis van olyan feladat, amire a Oracle XE agyu es hangya kategoria.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Link?
Én ezt találtam:
http://www.oracle.com/technology/software/products/database/xe/files/install.102/b25143/toc.htm#BABDHJHB
ill. MySQL esetében csak clusterre volt HW req:
http://www.mysql.com/products/database/cluster/faq.html#7

De ha tudsz valamit, oszd meg pls :)
Nekem egy gépen fut mindkettő, semmi extra igénye nem volt egyiknek sem, illetve az Oracle XE-nek legalább 1G swap kellett, addig nem volt hajlandó felmenni. Ha nagyon kekeckedünk, ezt lehet rendszerigénynek nevezni, deee... Érted... :)

a.

Ahajapersze... Orékülbérenceknek ...

Nem emlékszem pontosan a google mennyiért is licenszelt oracle termékeket? Bár nekik nincs nagyméretű adatbázisuk, úgyhogy tényleg nem ugyanaz a kategória.

És akkor azért, mert a Google használja valamire, azért már mindenhova jó és azt kell rakni?

----------------
Lvl86 Troll

Nem érzem pontosan, hogy érzed-e az iróniát abban amire válaszoltál? A Google nem oracle-t használ. Nyilván nem véletlenül...

A válasz: ha a google mysqlt használ, akkor az mindenképpen jó, és érdemes sok helyre rakni sztem...

Szerintem az Oracle alkalmazasszervernek hamarabb vege lesz, mint a MySQL-nek, az InnoDB eddig is ott volt naluk.

Valóban, mert a WLS lett a stratégiai termék. De 9 évig az IAS is támogatott marad.

Max leforkolják, azért ahhoz túl sokan használják, h be lehessen szüntetni a fejlesztését.

viszlát mySql?

Mindannyian zokogni fogunk. :))

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Végre egy jó hír...
Mondjuk már az első körös "eladó a Sun" hírveréskor is ez tűnt volna a leglogikusabbnak.

http://www.sun.com/third-party/global/oracle/index.jsp

--
>ami belassu, az hirtelen nem benchmark

Mert a finance.yahho.com-os cikk, amit eredetileg trey linkelt, nem szóról szóra ugyanez a szöveg volt, ugye? :)

"ami belassu, az hirtelen nem benchmark"

XD

Lehet lesz Unbreakable Solaris! :)
Esetleg 11g x86 Solarisra...

Ugyanezek jutottak eszembe...

Most akko' az Oracle-nek lesz 3 oprendszere? (Van saját Linux, + Solaris, + OSolaris) :)

a.

Ha eszük van a (Open)Solaris-t kiadják GPL-be, ami kell azt beletolják a Linux-ba, a közösség meg majd fejleszti nekik az egészet. A fél Solaris fejlesztőgárdát meg elzavarják, ráállítják a Linux-ra, vagy más egyéb területre. Mivel eddig nekik a Linux megfelelt - sőt az volt az elsődleges platformjuk - bajuk nem hiszem, hogy van vele. Válság idején ez a legjobb forgatókönyv anyagilag.

--
trey @ gépház

Nem látom, hogy mi köze van a mondandómnak ahhoz, hogy ki a tulajdonosa a PostgreSQL-nek.

Szerk: látom nem arra utaltál. Ezt megteheti a Solaris nélkül is.

--
trey @ gépház

Larry azt mondta, hogy eddig is Solarison adták el a legtöbb Oracle DB-t. Persze a Linux is fókusz marad továbbra is, de a Solaris is fontos nekik...
Lsd. webcast replay - http://www.oracle.com/corporate/investor_relations/index.html

Illetve az a cél, hogy integrált portfóliót kínáljon a diszktől egészen az alkalmazásig.

www.sunblog.hu

Legyen így.

--
trey @ gépház

Nyilvánvaló, hogy ezekre a kérdésekre az idő ad majd választ és nem felvásárlás előtti ígéretek. Pár éven belül kiderül, hogy mi lesz.

--
trey @ gépház

Meglatjuk. Az Oracle-nel sem dilettansok ulnek. Tudjak ok, hogy mit akarnak. Ha kidob a piacra egy hw-sw kombot, abban a solarisnak helye lesz, szerintem. Hiszen az otleteiket egy sajat fejleesztesu os-nel kielheti. :-)

Megmutatják C. Mansonnak a ZFS kódját, aki ezután "Aiee, killing interrupt handle" felkiáltással felakasztja magát az OpenBSD kernelének hangman játékával.

És lesz két levelező-, LDAP stb. szervere?
Ügyfélként én most jövő évig (addigra csak kiderül) semmi komolyba nem vágnám a fejszémet, sem az Oracle-től, sem a Suntól a kérdéses területeken...

Ezen csak egy gyors, és határozott döntéssel segíthetnek, de persze először a "nagypolitikának" kell kitermelnie a leendő vezéreket, amelyek révén aztán majd eldől, hogy mi esik áldozatul.

Nem mindkettő a Netscape szoftvereken alapul? Netscape -> iPlanet -> SunONE ( -> Sun Java System ). Az Oracle-ben nem vagyok biztos, azért kérdezem.

A Suné igen. Az Oracle-é nem (amennyire tudom, de aztán ki tudja, lopnak ezek mindent öcsém :).

Az oracle levelező szervere elég nagy hulladék.
(Mondjuk nem személyes tapasztalat, hanem egy olyan valakitől hallotam, aki egy időben "gyári" supportot adott hozzá.)

Néhány Sun szoftver is az. :)

Nem mondtam, hogy nem. :)

Néha az ember a pokolba kívánná az összeset, és felteszi a kérdést magának, hogy vajon megnézi-e egyáltalán valaki a kódot, mielőtt kidobják az ablakon?

Több QA van némely nyílt forrású projektnél...

Vajh, mit csinálnak majd a vasakkal?
Eladják a Lenovónak? :)

Kíváncsi vagyok, portolják-e ZFS-t Linuxra?

Ez azert is erdekes, mert AFAIK a btrfs is eleg Oracle-kozeli fejlesztes.

A cél az, hogy teljes portfóliót felölelő IT megoldást kínáljanak. Azaz hw is marad - sőt jobban integrálva lesz a különböző sw termékekkel.

Ez egyfelol - a java meg a szerverpiac szempontjabol - tok jo deal az IBM-eshez kepest.

Az adatbazis-piac szempontjabol viszont hatarozottan rosszabb deal: a mysql es a postgresql (mindketto Sun tulajdon) aranyaiban valoszinuleg tobbet vett el az oracle piacabol, mint a db2 piacabol.

Nyilvan lehet azzal jonni, hogy a mysql egy jatekadatbazis oracle-hoz kepest, en nem gondolom ezt, bazinagy rendszerek futnak felette, en azt gondolom, az oracle-nek erdeke elhitetni azt, hogy a szoftveruk egy komoly eszkoz, nota bene, van olyan 100% SQL-kompatibilis lekerdezesem (teli subquery-kkel es group by clause-okkal persze), ami mind mysql-en mind postgresql csont nelkul fut, az oracle-on elszall, ilyen es ehhez hasonlo okok miatt en valahogy mindig a masik kettot preferalom, es egy hype-nak tartom azt, hogy az oracle inkabb alkalmas azoknak a celoknak az ellatasara, amire az esetek donto tobbsegeben aztan vegul alkalmazzak (vallalati szoftver mogott db-nek lenni).

A Postgresql mióta SUN tulajdon? Le vagyok maradva...,Link?

Szerintem csak supportot adnak rá....

Ugy tudom, hogy a postgresql mogott nem all(t) olyan formaban ceg, mint anno a mysql mogott a MySQL AB, igy nem is tudott Sun tulajdon lenni. Annyi igaz a sztoribol, hogy a Sun kinalt supportot igeny szerint Postgreshez illetve a Solaris + Postgres kombohoz.

postgresql mióta a suné?
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Az Oracle törekedett mostanában arra, hogy ne csak egy adatbázis szervert adjon az üzletben el, amit majd ráraknak egy valamilyen vason futó valamilyen oprendszerre, amiből neki nincs bevétele.
Most szert tesz mind a gépparkra, mind pedig az OS-re (OS-ekre), ami ahhoz szükséges, hogy komplett megoldásokat toljon be a szerverszobába. Ezzel egyrészt többet fog keresni, másrészt az ügyfeleknek is sokkal jobban megéri egy gyártótól beszerezni ezt a jövőbeni terméket. Ráadásul mennyire szép már az, hogy betolják a Datacentert és már csak klikkolni kell a webes felületen, hogy összelődd a virtuális oprendszereken a RAC-ot, az adatokat pedig a már ott levő storage termékeken osztod szét. A management ott fogja helyben kiverni a f@szát.

"másrészt az ügyfeleknek is sokkal jobban megéri egy gyártótól beszerezni ezt a jövőbeni terméket."

Hogy is van az egy gyártótól való függés rossz?

----------------
Lvl86 Troll

A gyakorlat inkabb az, hogy egy gyarto jobb (mar ha nem brutalnagy cegrol beszelunk, mint google v. ibm), mert egyszeru a support - nincs egymasramutogatas, minden ossze van reszelve (vagy ha nincs, akkor support, ugye). Arban meg eleg jo deal-eket lehet kifogni, kozepes nagysagu cegeknek meg van buyer-e, aki elintezi az akcios arakat.

Most szert tesz mind a gépparkra, mind pedig az OS-re (OS-ekre), ami ahhoz szükséges, hogy komplett megoldásokat toljon be a szerverszobába. Ezzel egyrészt többet fog keresni, másrészt az ügyfeleknek is sokkal jobban megéri egy gyártótól beszerezni ezt a jövőbeni terméket. Ráadásul mennyire szép már az, hogy betolják a Datacentert és már csak klikkolni kell a webes felületen, hogy összelődd a virtuális oprendszereken a RAC-ot, az adatokat pedig a már ott levő storage termékeken osztod szét. A management ott fogja helyben kiverni a f@szát.

Úgy van. És rajta kívül az IBM az egyetlen a piacon, ami ezt meg tudja még csinálni, nézzük csak:

MS: nincs hardver
Intel: csak hardver van, egy ideje reszelgetnek a Linuxon
HP: nincs adatbáziskezelő
Dell: csak hardver van, az is az Inteltől függ erősen
Cisco: csak hardver van
Redhat: csak oprendszer van

--
"How do you work in a team situation when all the other team members are fools and idiots?"

yeah baby

mondjuk telleg ideje lenne a mysqlt kiirtani a foldrol mert bosszantobb mint a magyarok nyilai rozsa-folres sandor vezetesevel

--
.

válts projektet / munkahelyet

Idézet:
Redhat: csak oprendszer van

RedHat-nek van alkalmazás szervere, valamint jobbára ők faragják az OpenJDK bitjeit. :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Cisco meg most vasarolt hardver+gyarost.
Mozog a piac, valamerre...

Sokban fogadnék arra, hogy a klasszikus forgatókönyv lesz itt is: Oraclenek kell a JAVA és a sallangok; a HW gyártás leválasztásra kerűl és megy a levesbe... A MySQL itt sem fontos tényező, az is megy a levesbe. Aki "normális" az már most is Oracle XE-t használ :)

"Aki "normális" az már most is Oracle XE-t használ :)"

Programozóknál látok ilyen hozzáállást rendszeresen. Azok szoktak olyan apróságok felett elsiklani, hogy 1 processzor használat, 1GB-os memórialimit, 4 GB user data limit. Megírják a sz.rukat, aztán megy a sírás-rívás, amikor az ügyfélnél kiderül, hogy lassú, meg hogy egy év alatt betelt kiflivel az adatbázis.

Ilyenkor a programozó megvonja a vállát, az ügyfél vegyen x millióért licencet. Az ügyfél nem akar, ő egy megoldást vett (marhán nem kért Oracle-t, de a programozó azt erőltette, mert az milyen jó, igazából szükség sem volt rá), marhán nem akar még milliókat költeni.

A programozó f.szsága miatt szív a rendszert összeállító mérnök (neki kell megoldani a lehetetlent, "megállt a rendszer"), elégedetlen az ügyfél.

Naponta megtörténő dolgok ezek.

A "normális" Oracle XE-t használ. Gondolom a "normális" ebben az esetben azt jelenti, hogy nem volt nagyobb projektje a helyi videotéka 17 ügyfeles adatbázisánál.

(Ez nem csak az Oracle XE-re vonatkozik, hanem a többi "beetető" adatbázisra is, úgy mint MS SQL Server Express-re, vagy az IBM DB2 Express-C-re. Ha már ilyen, akkor inkább az IBM cucca, ami 2 processzor (4 mag), 2 GB RAM és végtelen adatterületet kínál)

--
trey @ gépház

Fölhozható ellenpéldának a másik véglet is: a zseniális programozó MySQL-t rak a program/sitemotor alá, ami kiválóan működik az otthoni "csúcs PC"-jén. Aztán deployolja ügyfélnek, elkezdik keményebben használni, és mindenki csodálkozik, hogy a remek queryktől lassul a gép, a MyISAM nem bírja a sok párhuzamos írást, az InnoDB fölzabálja a disket stb.

Mindkettő emberi hülyeség miatt van, egyik sem az adott adatbáziskezelő hibája: nem arra használják, amire való. Emiatt fölösleges az Oracle-t szidni.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Úgy tűnik nem értetted meg mit írtam. Nem az Oracle-t szidtam, hanem egyes emberek nem előrelátó hozzáállását tettem szóvá. Valamit félreolvastál.

Lehet egyébként jó az Oracle XE, meg van annak a helye, de azért a "Aki "normális" az már most is Oracle XE-t használ :)" állítás elég vastag.

--
trey @ gépház

errol az innodb felzabalja a diszket meselj mar, mert marhara erdekel. nalunk itt van nemistudom hany millio rekordos db (nem videoteka ;)), naponta dol bele a sok cucc, es semmi baja. ja, es innodbvel.

tehat vegulis ti is oracle termeket hasznaltok.

ez azert jo mert nem fog sok bajt okozni majd az uj tulajjal.
--
.

Hat igen, egyfelol nem az a jo MySQL, amit a disztrod ad, hanem amit magad optimalizalsz, az adott celnak megfeleloen. Nem kell nagy szemekkel bamulni, egy agyonterhelt MySQL-t igenis optimalizalni kell, ki kell belole dobni ami nem kell, ra kell tenni teljesitmenynovelo patcheket, processzoroptimalizacio es tarsai. Erdekes modon mindenki elfelejti, hogy a disztrokhoz adott csomagok altalanos celra vannak felkeszitve, nem pedig specialisra (ez alol kivetelek a specialis celra osszerakott disztrok). Meghat, a nem tudas nem mentesit.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az Oracle XE nem "termelésre" való, hanem nézegetésre, kipróbálásra, esetleg fejlesztésre. Itt (az első bekezdésben) leírtam, hogyan gondolom egy adatbázisalkalmazás skálázását Postgres és Oracle között.

Az a baj, hogy az Oracle XE még fejlesztésre sem feltétlenül jó. Van egy kis regressziós tesztem, amivel megnézem, hogy az Oracle és a Postgres interfész egyformán működik-e. Egyszercsak mit látok: Az XE egy helyen eltér (létező értékek helyett nullokat ad egy oszlopra). Egy napig áskálódtam, minden visszatérési értéket megnéztem, stb, de semmi. Felraktam az XE helyett a 11g-t: A dolog "megjavult".

Nem állítom, hogy a programom hibátlan, de azt igen, hogy van egy olyan értelmesnek látszó programom, aminek az Oracle XE és Oracle 11g más választ ad. Egyébként OCI-ból használom az Oraclet.

--
CCC3

Nade XE az 10g kódbázis.

Az, hogy két verzió, 10 és 11 eltér, előfordul. Sőt. Számos olyan hiba volt, amiket később peccsekkel javítottak (szóval nem kell még major verzió eltérésnek se lenni, hogy egy adott utasítás más eredményt adjon).

G

Akkor remélem rágyúrnak JDeveloperre.
SÜN!
------------------
lúzer Ubuntu júzer

én a netbeanst féltem
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

én azért még most is félem :)

Ezzel a sunos-nek es a sparc-nak valszeg reszeltek. Epeszu menedzser nem tart fent egy total mas architekturat iszonyat penzekert, inkabb az x86-os vonalat + linuxot fogjak tolni.

Ami szerintem jobb is a unix vilagnak. De legfokepp: egy gyengelkedo hardcore unix-os ceg most hatalmas tokeinjekciot kap. Mindenkeppen jo.

fyi sunos már közel 20 éve nincs, van helyette solaris
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Ennek mintha az uname kicsit ellentmondana...

http://en.wikipedia.org/wiki/Sunos

uname mas dolognak is "elletmond"

--
>ami belassu, az hirtelen nem benchmark

"Latest stable release 4.1.4 / 1994"

"86-os vonalat + linuxot fogjak tolni."

Ugyanezt tippelem én is. Gazdaságilag tök értelmetlen lenne más irány. A Sun elbukott abban, hogy életteli fejlesztői közösséget építsen az OpenSolaris köré. A Solaris-ból komolyabb pénzt nem tudott csinálni. A mostani SPARC rendszerek nem egy Oracle bajnokok (fixme), az Oracle Linux felett pedig elfut a Sun x86 vasain is. Fenntartani egy fejlesztőgárdát azért, hogy megmentsenek egy olyan dolgot, amibe egy másik cég belebukott, nem egy ésszerű lépés. Bár láttunk már karón varjút, így bármi megtörténhet.

--
trey @ gépház

Nemtom, terán feletti Oracle-okat még nem láttam linuxon. Biztos van, de sok helyen Sun-on és AIX-on fut - nem is rosszul.

A kérdés az, hogy mennyi és hogy ezért megéri-e fenntartani X darab fejlesztőt, vagy ez egy olyan niche piac, amiért nem éri meg, illetve jobban megéri olyan platfomon megcsinálni a hiányzó dolgokat, aminek nagyobb jövője van. Ez a pénzről szól.

--
trey @ gépház

Jah. Pontosan.
Szerintem jobban megéri egy olyan oprendszerre fejleszteni, ami teljesen a cég tulajdonában van.

Aki Oracle-t akar, az eddig is az alapján választott oprendszert a cucca alá, amit a fejlesztő cége, vagy az Oracle javasolt.
Ha az Oracle holnaptól azt mondja, hogy Solaris a preferált, akkor Solaris fog az adatbázis alá kerülni a legtöbb helyen.

Így az adatbázis licensz és support mellett még a Solaris support is bevételt generál ugyanattól az ügyféltől.

Akkor biz még elég keveset láttál a világból.
És a jelenlegi TCO-ja ugyanazon teljesítménynek "Oracle adatbázis x86 Linux-on" vs "Oracle adatbázis Sun Sparc Solaris-on" kb 1:8-hoz.

Jah, lehet, kezdő vagyok.
Csak az miért van, hogy pl. még egy banknál sem láttam mission critical környezetben linuxon Oracle-t futni, solaris-on meg jópár tucatot.

Azért megnézem, hogy linux alá mikor lesz olyan vas, ami olcsóbb mint egy M5000-es, vagy egy M8000-es és ugyanolyan teljesítményt hoz mint azok.

Mert ugye van ahol k. mindegy, hogy mennyi a linux tco-ja, ha az esti job nem fut le a kötelező időablakon belül.

Ne Magyarországban gondolkodj. Itt mindíg le van maradva az élet, ha meg Oracleről van szó akkor meg közelebb van az egyhelyben toporgáshoz mint a fejlődéshez.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

Jónak mondod. Ezek szerint nálunk sem jártál még, ha nem láttál ilyet...

Egy alap M5000-es 8 GB RAM, 2 db 2,15-ös kétmagos, négyszálas SparcVI-tal ~45k USD listaáron.
Ennyiért kapni HP "pc" vasat, 8 db 2,7-es négymagos Opteronnal, 128 GB memóriával.

Találós kérdés: melyik a jobb adatbázis-vas vajon?
Elhiszem, hogy az új SparcVI atomkirály, de ennyire azért nem.

A Sparc egy régen halott ló, amit a Sun rugdos már egy ideje, mert még mindig nem vették észre, hogy meghalt. Persze ettől még lehet, hogy az Oracle majd úgy dönt, hogy megpróbálja feltámasztani, de őszintén szólva így válság közepette eléggé meg lennék lepve.

Hát, amit írtál az az M5k minimum kiépítése.
Azért ebbe is bele lehet rakni 256Gb memóriát, meg 8 db. 4 utas USVII-et. És ez csak a középkategória...

"Elhiszem, hogy az új SparcVI atomkirály, de ennyire azért nem."
Ott az új SparcVII. Az igen. :)

Egy max kiépítésű M5k azért nem kicsit erősebb szinte bármelyik x64 arch-nál.
A processzoron és memórián kívül az olyan dolgok is számítanak, mint pl. memória és IO sávszélesség.

Ismétlem, ha egy bizonyos teljesítménynél több kell, akkor oda vegyél IBM-et, vagy Sun-t.
Vagy esetleg HP-t, de ne i386 dzsunkát, hanem mondjuk Integrity-t. (Vajon ők miért árulnak high-end vasakat?)

Ember, épp erről beszélek, hogy a minimum... Az említett HP vasban meg már benne van a 32 utasításszál, amit az M5k-ba +100k USD-ért kapsz meg, nem beszélve a memóriáról.

Egy max kiépítésű M5k, az azt jelenti, hogy kb 250k USD beruházás, és a jelenleg piacra lépett új intel x86 szerver lapkák úgy verik péppé az USVII-et, ahogy kell.

Én személy szerint Oracle adatbázis alá nem nagyon hiszek abban, hogy nagyobb monolitikus vas helyes választás. Ilyen méretű feladatoknál már tényleg inkább több vason elosztott terheléssel, és RAC használatával olyan pluszokhoz jut az ember, amit egy monolitikus architektúrában nehéz megbízhatóan megvalósítani. Persze, ilyenkor ugyanazt a pénzt az olcsóbb vas helyett a drága szoftverbe kell ölni, de ez már csak így van. Ettől még az architektúra maga előnyösebb lesz...

Én láttam. Nem banknál, mert bankokban nem nagyon dolgoztam, de telkónál, szállítmányozásnál volt.

Viszont sok helyen, ahol nem csak egy akármi adatbáziskezelő kell egy akármi alkalmazás mellé, hanem mondjuk egy konkrét alkalmazás van, ami alkalmazásszerver, adatbázisszerver, stb. több darabból áll, ott egyszerűen a vendor nem szórakozik azzal, hogy 6 féle OS-t szállítson.
Jön minden egyféle gépen, egyféle OS-sel.

Ahol én dolgoztam, ott ez általában HP volt vagy Sun. Mondjuk az elmúlt 8 évben.

Egy HP blade keret tele BL680c-vel és Oracle RAC-kal?
Vagy az M8000-es árából mondjuk tíz ilyen?

Esetleg ha valamiért egyben kell, összedrótozol 96 x86 magot az IBM legójával?

Ja, bocs, most látom, hogy ugyanolyan teljesítményről volt szó. Sztornó, akkor valami kisebb. ;)

Hehe. RAC licenszéből és egyéves support díjából a minimálisnál kicsit kicsit nagyobb M5k kiépítést vehetsz.

Szerintem ár/teljesítményben (és teljesítményben) még így is jobban jön ki, de persze kérdés, hogy mire.

Mindenesetre nem úgy tűnik, hogy a nagypapakorú adminok/architektek "scale up" elképzelése terjedne. A fiatalok fejében már más van, csak hát a sziklaszilárdnak gondolt -amúgy persze tudjuk, hogy nem- banki, és egyéb helyeken még nem ők osztják a pénzt.

Van olyan terület, ahol az abszolut kapacitás számít, és nem az ár/érték arány.

Én csak a kihívásodra válaszoltam. :)

Ahol meg az abszolút kapacitás számít, nem ilyen csumpi rendszereket használnak, hiszen azok túl drágák és lassúak is, hanem építenek egy clustert. Nem?
Vagy te azon igen ritka feladatokra gondolsz, amely annyira teljesítményigényes, hogy egy ilyen közepes teljesítményű cucc is elég a futtatásához, viszont a feladatot csakis kizárólag egy kernelen belül lehet megoldani?

Nosza, van már InfiniBand, RDMA, meg hasonlók, olyan sebességekkel, amelyek nemrég még a CPU-k etetéséhez is sok lett volna, akár ezt is megteheted...

Akár standard, low cost PC-kből is.

+1

De. Nem is tudom, hogy miért nem használnak mindenütt parallel clustereket. :)
Talán azért, mert 10x (100x?) annyiba kerülne megírni az adott alkalmazást, hogy elosztott rendszeren tudjon normálisan futni, mint alátolni egy kicsit nagyobb vasat?

Léteznek olyan feladatok, amiket nem tudsz annyira párhuzamosítani, hogy elosztott rendszeren használható legyen.

Egy elosztott rendszer hibatűrése is igen kényes kérdés.
Vannak olyan feladatok, ahol a párhuzamosan futó jobok közül bármelyik elszáll, az megakaszthatja, vagy akár tönkre is teheti a teljes feladat futását.
Márpedig minnél több node-ot használsz, és minél bonyolultabb az adatelosztó és szinkronizáló rendszered, annál valószínűbb, hogy valamelyik node meghibásodik.

A kis garázsokból indult startupok (google, facebook, meg mittudoménmi) mind ezt az irányt választották az M9000-es (vagy E2xk) helyett. A tudás már ott van a fiataloknál, csak idő kérdése, míg ezek az elvek beszivárognak az annyira hihetetlenül ködös misztikusságba burkolózó banki rendszerekbe is. :)

Kíváncsi vagyok mikor jutunk el oda, hogy mondjuk IB interconnecttel valaki megírja a Linux kernelt ilyen elosztott rendszerre. Mert a mondandóm lényege pont az, hogy ma már egy HP blade chassis 64 CPU-val, tele memóriával (az annyi mint 256 db 3 GHz-es mag és 1 TiB memória 10U-ban) egy korrekt IB switchcsel kb. olyan belső sávszélességekkel rendelkezne, mint egy általad emlegetett "nagy" gép.
Csak két szekrény helyett 10U-ban, tized (vagy még kevesebb) áron...

De kíváncsian várom, hogy szerinted mi az, ami egy M9000-est ehhez képest mássá tesz.

Idézet:
Csak az miért van, hogy pl. még egy banknál sem láttam mission critical környezetben linuxon Oracle-t futni, solaris-on meg jópár tucatot.

Ez kizarolag a sales-esek dicserete. Ar/teljesitmeny aranyban egy nagysagrenddel rosszabb, megbizhatosagrol meg csak annyit, hogy minden hardvergyaros kinal mar x86_64 alapu szervert, es alairom, semmivel sem rosszabbak, mint egy sun.

BTW, megbizhatosag, mint olyan, amugy is felesleges a clusterek vilagaban. Ha van 16-64 vasad, akkor bizony valamelyik EL FOG ROMLANI. Pont. Tokmindegy, milyen hardver. Innentol meg tokmindegy, hogy milyen gyakran, a lenyeg, hogy szepen le legyen kezelve a hiba.

Hát, ha van egy HA clustered, aminek az alkalmazás rétege kb fél óra-óra mire elindul, akkor nem mindegy, hogy milyen gyakran döglik meg.
Vannak olyan cégek, akik máig használnak fault tolerant rendszert, mert egy perc állásidő is 60 másodperccel több a megengedhetőnél.

Igen, egyre több mindenkinek elég az x86 teljesítménye, de mindig is voltak olyan felhasználók, akiknek a rendelkezésre álló legnagyobb teljesítmény kell.
Hiába jobb az ár/érték aránya az x86-nak, ha van olyan alkalmazási terület ahol az elérhető legnagyobb teljesítmény kell, akkor 10x rosszabb ár/érték arányt is ki fognak fizetni.

Nem véletlenül árul még mindig mainfram-et is az IBM.

A dinoszaurusz is elég sokáig húzta, de az evolúció csak betett neki.
Miért pont a mainframe-ek lennének a kivételek? Legjobb esetben is kihalnak a most megszülető új zsenik "hatalomátvételekor".

nem véletlenül árul". Hát persze hogy nem. Addig árulja, míg nyeresége, vagy egyéb formában megtérülő bevétele van belőle. Vagy van más oka is?
A mainframe-en (a mainframe megbízható) futó program nem tud olyanolyan megbízhatóan futni 16 pécén? A 16 pécé lassabb, mint a mainframe (a mainframe gyors)?
A 16 pécé több helyet/áramot eszik, mint a mainframe (a mainframe takarékosabb)?

Szerinted racionális döntés a mainframe?

Izé, én nemrégiben olyat olvastam, hogy az IBM profitjai folyamatosan nőnek a mainframe-eladásokból és a kapcsolódó supportból. Most akkor mi van, mindenki megőrült? :)

Vagy lehetséges, hogy nem csak Google-jellegű workloadok léteznek? ;)

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Link? Egyébként ennek sem feltétlenül az az oka, hogy a mainframe-piac bővül. Millió dolog okozhatja.

Nyilván nem csak google-workloadok vannak, én de én nem is ezt mondom, hanem azt, hogy nehezen tudok elképzelni olyan workloadot, amit egy taliga pécével ne lehetne olcsóbban, gyorsabban, hatékonyabban megoldani.

A nagy különbség persze az, hogy aki mainframe-et, meg ilyen minicomputereket vesz, mint az M9000 (amelyet ugye szintén mainframe(-like) rendszernek pozicionálnak) az gyakorlatban gondolkozik (van ez a gyatrán megtervezett xyz alkalmazásom, min tudnám a legjobban futtatni), nem pedig elméletben (ha a nulláról kellene xyz-jellegű alkalmazást terveznem, hogyan építeném fel).

Én azt gondolom (de persze nem hiszem vakon, hogy nekem van igazam, mert nem vagyok hülye), hogy előbb-utóbb eljutunk odáig, hogy ezeket a böszme gépeket leváltják a valamilyen gyors interconnecten ülő elosztott vackok. Jelen állás szerint nagy valószínűséggel olyan pécék, amelyek tizenvalahány évvel ezelőtt még szuperszámítógépnek minősültek volna.

ahahahah

es a meg kb. 30 evig uzemelo gepekkel mi lesz? annyi idore vettek meg :)

szal kar lenne azert minden mas temetni mert itt a leenugz kermel meg az x86 es olcso, akar meg virtualizacioval is ami epp hogy csak h elidnult ezen a platformon

egyszeruen azzal nem tudsz pc kategoriaban versenyezni h gyarkolatilag 100% a rendelkezesre allas es nincs kieses 10 evig, rakhatsz barmilyen HA megoldast 10000 nodeal(mondjuk kivancsi lennek hogyan migralnal egy folyamatiranyito rendszert ilyen clusterre aminek a leallasa eseten megall a gyartosor vagy leall a repuloter)

--
.

Pontosan mi az a különleges tulajdonsága egy ilyen rendszernek szerinted, amely miatt nem tud egy elosztott környezetben futni?

kerdezd meg a frankfurti repteret

--
.

Értem, szóval neked fogalmad sincs róla.

nem sajnos nincs :(
--
.

Kár, pedig reménykedtem benne, hogy megtudok valami újat.

tehat roviden:

-mukodo mainframe alapu megoldast hasznal egy adott ceg egy adott feladatra es ezt az ervenyben levo szerzodesek alapjan meg vagy 30 evig igy lesz

-szted ez "nem nagyon jo gyerekek", es sokkal jobb volna n darab szutyok_86 gepre cserelni leenugzzal mert ugy olcsobb is lenne meg amugyis

es en biznyiotsam be h az altalad javasolt teoretikusan mukodo megoldas telleg mukodni fog

sztem inkabb legyen az h citalj ide mindenfele bizonyitekot h olyan helyeken mint pl. atomeromu, repter, etc. ahol emberletek mulhatnak az informatikai rendszer mukodesen sikerrel csereltek mainframeket linux/x_86-ra.

en ertem h rengeteg esetben -pl. google.com jellegu workload- olcsobb es jobb(hatekonyabb) megoldast kinal ez utobbi de nehogymar mindenhova ezt akarjuk eladni csak azert mert a managernek felall a pingvintol

nem en fogom neked bizonygatni h igenis a nagygepek eletkepesek hanem a valo elet.

http://www.giit.info/mainframe.htm

--
.

Most ooolyan vaaaagy! Egy URL-lel megcáfolod minden postját. :)))

--
"How do you work in a team situation when all the other team members are fools and idiots?"

life sucks, take it like a man
--
.

A mondanivalóm lényege, hogy jobbnak tartok egy elosztott, hibatűrő rendszert, az erre a környezetre felkészített alkalmazásokkal, mint egy(két, három) darab vasat, amelynél a működés biztonsága leginkább ezeknek a (jól) működésétől függ.
Az, hogy milyen komponensekből is áll egy ilyen rendszer lényegében hullamindegy. Állhat PC-kből, vagy akár olyan gépekből is, amelyek jobban teljesítik az adott hely elvárásait.

Ha ebből csak annyit sikerült megérteni, hogy szutyokpécé, meg Linux, akkor így jártam, szíved joga, hogy inkompetens baromnak tarts.

Esetleg majd visszatérhetünk erre 10-20-30 év múlva, és megnézhetjük akkor -már ha lesznek még mainframe(-jellegű) gépek, vagy egyáltalán a maihoz valamelyest is hasonlító megoldások-, hogy mi lett, közeledett-e a "mass market technológia" ehhez a külön kasztot (ez persze már ma sem igaz) alkotó, magasztos világhoz, amitől annyira el vagy ájulva.

nem tartalak inkompetens baromnak csak olyan embernek aki szeret ellentmondani :)

nem ugyanaz

mondom gyakorlar vs. elmelet :)

--
.

+ 1024

Lehet nezegetni a kepeket, es morfondirozgatni, hogy olcso PC "pakk" mikor is lesz erre kepes, es biztos hogy annyival olcsobb lesz? Stabil is? Vagy allandoan lehet imadkozni bizonyos testreszekre osszetett kezekkel minden gyakori es termeszetesen forradalmi technologiai attorest tartalmazo update elott, kozben, utan?




Ez tényleg olyan cucc, amire az életemet bíznám, hiszen annyi sávszélesség, meg olyan fasza RAS-feature-ök vannak benne. Meg hát ha mégis leolvadna valamelyik CPU, a nem licencköteles (már ahol) 5 GHz-es nyitott sávon hazaszólhat apucinak, hogy: "kína szindróma", lehet küldeni a betonkeverőt, ezután pedig kalibrálni kell a szekunder kvázipixist, aztán kontaminálni kell a negatív visszacsatolással katalizált hiszterézishurkokat, majd intabulálni az operációs rendszert.

De miről is jutott ez a cucc eszedbe? :)
A mainframe-ről? A skálázhatóságról? Az olcsóságról? A megbízhatóságról?

A maga nemében persze kiváló darab, a Power6 is biztos nagy sávszélességeken képes kommunikálni (bár ha nagyon akarnánk csak találnánk olyan CPU-t, amely ennél is többet kínál), de szerintem nem sikerült megértened a mondandómat.
Megpróbálom összefoglalni: szerintem a jövő az, hogy a standard fostömlő pécék szép lassan átveszik az ilyen közepes teljesítményű single image gépek helyét is.
Ehhez mindössze arra van szükség, hogy valakinek igénye és pénze legyen arra, hogy a fenti milliárd forintos cucc megvétele helyett szoftverfejlesztésre költse a pénzét, és összerakassa valami okos indiaival linuxos pécékből (hatásában) ugyanezt.
A fentihez hasonló technológia lassan itt van (millió portos QDR Infiniband switchek, a fenti P6-nál gyorsabb CPU-k, amelyek immár olyan gyorsan képesek a DOS-t futtatni, hogy annak visszafelé számlál az órája, széles adatutak, rengeteg memória(sávszélesség)), már csak valakinek meg kell csinálnia.

Ezek már biztosan ma is működnek HPC környezetben, ha van értelme (és igény rá) összedrótozni egy kvázi single image, de elosztott (esetleg megfelelően hibatűrő) rendszert ilyenre, valamikor csak meg fog jelenni (szoftver, vagy hardver oldalon, a lényeg, hogy standard komponensekből).

ui: és igen, szerintem annyival olcsóbb lesz. A fenti gépet az IBM magának fejleszti, emiatt drága. A gagyi pécék infinibandes (vagy tökmindegy, a lényeg, hogy nyitott, mindenki számára hozzáférhető tömegtermék) összekötéséből származó cuccban pedig megoszlanak a költségek, több piaci szereplő egymással versenyezve fejleszt építőkockákat, amelyek képesek egymással csereszabatosan együttműködni.

1 milliárdból mégis hány pécét lehet venni szerinted? :)

(a fenti árat tippeltem, ha van "listaárad", mondd)

"olyan gyorsan képesek a DOS-t futtatni, hogy annak visszafelé számlál az órája"
LOL... megcsinaltad a reggelemet...
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Khmm... ize... telleg nem beleszolaskepp, de legkozelebb lecci csak linkeljed a kepeket... sokkal jobb lesz mindenkinek... koszi.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

pont felére kicsinyítve idefért volna minden (felbontás/olvashatóság/hely/téma/kötözködők) tekintetben :)

Azert egy 10k node-s clusternel nagyon kicsi az esely, hogy leall a komplett cluster, nyilvan a cluster-management is clusterezve van, de legalabbis HA-val figyeltetve. Egy ilyen tipusu clusternel amugy meg az szokott lenni az iranyelv, hogy a fele passziv node, es foldrajzilag elkulonulo helyeken taroljak oket, igy a legnagyobb a fault tolerance. Annak, hogy ket foldrajzilag elegge tavol eso site egyszerre szurja tokon magat, megintcsak kicsi az eselye.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

jah max az connection fekszik le koztuk de nem para ott az szepen fut csak innen nem latszik
--
.

Ami persze nem gond az egy gépteremben elhelyezett mainframe-nél, hiszen önmagán belül csak nem szakad el a drót.
És milyen jó, hiszen a mainframe-technológia a fenti problémát is megoldja, ha esetleg mégis két helyre tennél egyet-egyet. Szub-Éta Detekt-O-Méterekkel kommunikálnak, triplán redundáns transceivereken keresztül!

És SHA-680564733841876926926749214863536422912-cel checksumozzák az adatokat (ezt még a ZFS sem lenne képes eltárolni)!

Szerintem ilyen helyre azert normalis ember site-onkent tobb fuggetlen linket is tervez, arrol nem beszelve, hogy ekkora clusternel jocsan benez egy geologiailag differencialt site-rendszer is. Tudod, ha valamit nem ismersz elegge, nem kell fikazni olyan nagy hevvel.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

aha

mennyi az atterheles egy ilyen ip halon, 2-3 masodperc? 5 perc?

gondolom a leszallas kozben levo repulogepnek majd elmagyarazod h figyi ez ugyanaz mint amikor kihullik egy processzor vagy barmi a mainframebol es nem tortenik semmi mert minden redundans ugyhogy lecci ne crashelj bele a betonba mert elment a nulla jeled es nem tod milyen messze van a fold

--
.

> foldrajzilag elkulonulo helyeken taroljak oket

Akkor bejön a képbe a szétesés tűrés, aminek a megvalósítása a CAP tétel szerint lerontja vagy a magas rendelkezésre állást, vagy az erős adatkonzisztenciát.

Tartom amit eggyel feljebb irtam, egy ilyen helyre 2-3 fuggetlen link tervezese automatikus atallassal alap. Persze kerdes, hogy maga a cluster mennyi ideig turi a fuggo allapotot (vagyis amikor epp le van szakadva valamelyik nodegroup aktiv linkje, de meg nem allt at a group a backup linkre). Ez nyilvan teszteles kerdese is, de nem megoldhatatlan feladat.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"A 16 pécé lassabb, mint a mainframe (a mainframe gyors)?

Egyértelmű igen.. főleg, ha Mainframe-re is optimizálták a kódot ( tekintve, hogy a mainframe-eknek vannak olyan belső utasításaik amivel elég durva sebességnövelést lehet elérni, viszont x86 hírből se hallott még olyanról..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem szamit. Egy 10-20 eves mainframe nem ellenfele egy mai x86 clusternek semmilyen szinten (ar, teljesitmeny). Elismerem, ha olyan ratyi szoftver fut rajta, amit valami regimodi gyepesagyu tervezett, es abszolut nem hibaturore lett kialakitva, akkor kell a mainframe megbizhatosaga.

De a mainframe-nel sokkal olcsobb/egyszerubb sima off-the-shelf HA megoldasokbol osszerakni egy hibaturo clustert. Nem is szolva, hogy utobbi esetben foldrajzilag is eloszthatod a node-okat, ami egy mainframe-nel nehezkes/draga.

Ki beszélt itt 10-20 éves Mainframe gépekről?? Én azt mondtam, hogy ha megnézed, hogy egy MAI mainframe mennyibe kerül, és annak az áráért nézel össze hasonló teljesítményre szánt PCket, akkor hiába lesz jóvalta több PC-d, és jóvalta több Mhz-d is, attól még a Mainframe teljesítménye simán oda fogja vágni a teljes PC-vel kiépített clustered teljesítményét. És lehet hogy a kódnak még nem is kell Rexx-ben íródnia :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nekem az openoffice hirtelen nem akarja megnyitni a discounted_ibm_mainframe_pricelist.xls-t. Mondanál árakat a sajátodból?

A register szerint egy z10 BC induló ára 100e USD körül van, míg egy EC-é 1 milliónál indul, de könnyen felszaladhat 30-40 millióig (majdnem tízmilliárd forint!).
Azon most hirtelen elgondolkoztam, hogy van-e értelme ilyen gépeknél listaárról beszélni, hiszen nincs lista, ezeket nem onnan szokás megvenni.

Hát nem tudom.

Találtam nagy nehezen egy power estimator táblázatot, ahol a legkisebb konfig (4 CP, 16 GiB RAM, lényegében a táblázat csak ezekben változik) 5498 wattot eszik. Ezt sem tűnik túl nagy kihívásnak megverni, ennyiből kijön a 16 darab PC, egyenként 16 GiB RAM-mal, és 2xnégymagos, minimum 3 GHz-es CPU-val.

Összteljesítményben szerintem nem lehet kérdés, a kérdés az, hogy az alkalmazásod képes-e kihasználni a teljesítményt.
De ugyanez a mainframe-nél is kérdés, több (ráadásul speciális) processzorra skálázódni még ma is kihívás.

"Mondanál árakat a sajátodból?"
Nem vagyok én sales-es, hogy ilyen információkkal rendelkezzek :) Mindenesetre a listaárazásnak tényleg nem sok értelme van.. Főleg, hogy a nagyobb mainframe gépeket nem is igazán eladni szokták, hanem bérelni.

Mindenesetre ha valaki tényleg venni akarna egy mainframe-et, akkor aláírom, hogy azonos árból jópár PC-t vethetnél teletömve ram-al, meg számítási kapacitással. Ám még így is tartom a véleményem, hogy a Mainframe-et nem véletlenül használják a mai napig, hisz alapvetően erre lett kitalálva => nagy erőforrásigényes alkalmazások/rendszerek kiszolgálására.

"Összteljesítményben szerintem nem lehet kérdés, a kérdés az, hogy az alkalmazásod képes-e kihasználni a teljesítményt."

Ezt bármelyik másik alkalmazásról is elmondhatod. Hiába teszel über-brutál vasat egy app alá, ha az rosszul van megírva, vagy akár rossza paraméterekkel van fordítva ( és így optimizálva is )

"több (ráadásul speciális) processzorra skálázódni még ma is kihívás."

Még mázli, hogy ezt a mainframe alapból tudja :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"Még mázli, hogy ezt a mainframe alapból tudja :)"
vs
"Ezt bármelyik másik alkalmazásról is elmondhatod. Hiába teszel über-brutál vasat egy app alá, ha az rosszul van megírva, vagy akár rossza paraméterekkel van fordítva ( és így optimizálva is )"

Tehát a mainframe alapból képes bármilyen szarul megírt alkalmazás teljesítményét az egekbe tornászni?
Vagy nem?
Vagy mit is akarsz mondani?

Mitől képes (hardveresen) jobban skálázódni egy mainframe, mint egy infiniband fabricben összedrótozott PC-k serege?
Legalább egy architektúra ábrát linkelj pls. :)

"Tehát a mainframe alapból képes bármilyen szarul megírt alkalmazás teljesítményét az egekbe tornászni?"

Félreértesz.. Azt mondtam, hogy ha egy kód xarul van megírva, vagy forgatva egy adott platformra, akkor persze, hogy nem fog olyan sebességgel futni, ahol ez adott ( ergo ha a 2 rendszert ( jelen esetben PC-cluster Vs Mainframe ) összehasonlítod, akkor persze, hogy nem fogsz normális eredményt kapni, csak az optimizált esetében.

Amúgy a skálázhatóságot arra értettem, hogy a gépben elhelyezett erőforrásokat dinamikusan tudod hozzáadni/elvenni a host-tól. Alapvetően a mainframe-eken nem csak 1 rendszer szokott futni, hanem jóvolta több, amik közül mind1iknek megvan a saját profilja, melyben definiálva van, hogy az összes erőforrásból mennyit kaphat meg a host.. Na ezt viszont dinamikusan tudod változtatni ( kb mint az LVM-nél az LV méretét ), persze csak míg fizikailag a HW adott.. Amennyiben az se lenne elég akkor is adott viszont, hogy bepakolnak a gépbe még HW-t, majd aztán azt allokálják a host-hoz, vagy összekötnek 2 mainframe gépet, és onnantól ismét csak ki lehet osztani az erőforrásokat.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Hol tart már a tudomány. :)

Ez azért már elég rég lecsorgott a unixos gépekbe is.

Stimt.. De a kérdés az volt, hogy a mainframe skálázhatósága felérhet e egy linuxos géppark skálázhatóságáig.. válaszom igen.. Ehhez jött még, hogy amúgy még van 1-2 olan plusz is a mainframe-ben ami linuxban még 1 jó ideig szerintem nem lesz ( microcode, megbízhatóság 1 (!) gépen belül, erősebb számítási kapacitás, jobb virtualizációs támogatás )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Egyrészt a Linux és a PC csak példája volt a minél olcsóbb, de még igen jó teljesítményt (mind megbízhatóság, mind sebesség) adó rendszernek.
De nem ez a lényeg, hanem az elosztottság, a modularitás, a standard komponensek és interconnectek, és persze az, hogy az alkalmazás maga is erre van tervezve.

Ezzel az elmélettel csupán annyi bajom van, hogy elmélet, míg mainframe-nél meg valóság.. Ráadásúl ha tényleg csak azon vagy fennakadva, hogy mennyibe fáj ez neked/a cégednek, és ezen akarsz ezzel a megoldásal spórólni akkor meg szintén le vagy tévedve, mert senki nem mondta, hogy azt a nyamvadt Mainframe-et meg kell venned.. Nyugodtan köthetsz szerződést a support céggel, hogy neked nem kell a vas, csak a teljesítmény, és akkor kapsz egy olyan gépet, amit te kértél, annyi memmel, procival ( avagy számítási kapacitással ) amennyit az adott pénztárca elbír, és lényegében mindenből annyit amit szeretnél. És akkor az olyan nagy gondok, mint HW problémák nyomban ki is esnek a körből, mert az üzemeltető majd törődik házon belül a HW problémákkal.. És itt meg már tényleg olyan szerződést küzdesz ki magadnak amilyet szeretnél, és innentől már hosszútávon szerintem tutira jobban megtérül a pénz, mint a te általad felvázolt verzió ( és még mindig stabilabb, mint az agyonclusterezett,jóval gyengébb szerverek, tekintve, hogy ez már jó ideje kiforrott )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Most. Én azt gondolom, hogy valamikor ez átkerül múltidőbe.

Én meg azt mondom, hogy lehet, hogy lesz belőle valami, de azt a teljesítményt, hibatűrést, és biztonsági szintet akkor se tudják elérni majd az ilyen osztott rendszerek, mint egy mainframe.. Lehet hogy majd a KKV-knek jól jön ( szívjanak vele ők, ha akarnak :)) hogy 'occóért lehet egy arányaiban hasonló rendszerük, de ettől még a világmegváltás szerintem elmarad :)) Akinek meg ez nem jön be, az meg marad a már amúgy is bevált mainframe-nél ( ezek valszeg meg amúgy is nagy cégek lesznek )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A cégek profitmaximalizálásra törekednek. Azt meg azzal lehet elérni, ha nagy tömegben gyártott dolgokat tudnak eladni. Ha közelítik a mainframe-eket a tömegtermékekhez, olcsóbban adhatják őket, vagy nagyobb nyereséget realizálhatnak rajtuk.
Gondolom ilyen irányt sem látsz.

Félreértesz.. Azt mondtam, hogy a közelítés ( ami ugye sose egyenlő a viszonyítási alap szintjével ) sok nagyobb cégnek nem lesz elég, mert még mindig hiányozni fog egy olyan dolog amit az nem tud, és valszeg jó ideig nem is fog tudni.. Most is összerakhatsz egy linuxos gépeket tömörítő számítási clustert de a teljesítménye fele akkora nem lesz, mint egy azonos összegből kihozott mainframe-nek ( És épp ezért nem látom benne a realitást) . És pont a nagy fokú elosztottság miatt nem fognak tudni majd az ilyen nagyon elosztott rendszerek versenyképesek maradni sok mainframe-el szemben, mert akinek tényleg kell az amit tudnia kéne, az rá lessz kényszerülve, hogy megvegye a mainframe-et.
Azoknak a cégeknek, akiknek ez nem szempont, azok meg majd eljátszanak ezekkel, de őket nem sorolom a komoly kategóriába (ezekre mondtam a KKV-t )
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Persze ez szamitasi feladat fuggo is...

Hat igen, a cel valaszt eszkozt, es nem forditva.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Bra, nem szabad elfelejteni azt az orokervenyu mondast, hogy mindig a cel valaszt eszkozt, es nem pedig forditva. Nem ertek a mainframe-khez, de tuti van olyan feladat, amit azon celszerubb megoldani, espedig nem azert, mert a megvalositas arra lett megirva.
Olyan ubermegoldas, ami mindenhova, mindenkinek jo, egyszeruen nem letezik, mert elteroek az igenyek.
Arrol nem beszelve, hogy egy clusternek van am management overhead-je is, es esetleg nagyobb, mint egy mainframe-nek. Lehet, hogy valahol ez is szempont.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Lehet, de erre mondom, hogy a PC-k gyors összedrótozásával (szerintem) ez is megoldható, ráadásul egy jóval skálázhatóbb rendszert kapsz.

És jelen pillanatban semmi akadályát nem látom (de cáfolj meg) annak, hogy egy node-ként működhessen sok kernel, közöttük egy gyors interconnect technológiával.

Ez az igazi plug-n-play, rádugsz a switchre egy mozdulattal 32 új gépet, a rendszer észreveszi, és már be is csattant 384 új processzor (mag) a rendszerbe. :)

Tényleg, hírből sem hallottam még olyanról, hogy ezeket valaki értelmesen összehasonlította volna.

És való igaz, az, hogy a mainframe-ekben speciális (vagy éppen kutya "közönséges", csak más mikrokódot futtató) processzorokat használnak bizonyos feladatokra teljes mértékben megoldhatatlan PC-n.
Hiszen ki hallott már olyanról, hogy egy Xeonba, vagy Opteronba más mikrokódot is lehessen tölteni, vagy hogy a hypertransportra Opteron helyett más, célprocesszor kerüljön, vagy hogy otthagyva ezt a témát speciális feldolgozóegységek végezzenek speciális feladatokat (TOE, SSL offload, GPU-k használata stb).

x86-nál arról se lehet nagyon hallani, hogy dedikált CPU-ja van 1 külön tasknak ( és itt nem OS oldali taskra gondolok, hanem mondjuk HW szintű terheléselosztásra ). Az, hogy ezekhez külön microcode van.. és? BIOS is lényegében egy microcode.. azt is néha frissíteni kell. .Annyi a különbség, hogy ezt a legtöbb HW-re átültették, hogy a jövőben akár még többet is ki tudjanak belőle hozni..

"vagy hogy otthagyva ezt a témát speciális feldolgozóegységek végezzenek speciális feladatokat"
Ez mainframe-nél is megvan, csak ott a gépen belül.. Sok HW-k számára szükséges funkcióhoz dedikált HW van, ami csak azért felelős, hogy azt ellássa.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

hat, gondolom ironiaval irtad, de azert huzzuk ala, hogy az. :) csak hogy masnak is leessen.

mi ugy 2-3 eve csinaltuk azt, hogy FPGA -t raktunk az opteron melle, modellezni.

de a power6 tud decimalis lebegopontos szamokkal szamolni hardverbol (ezt olvastam) mig a xeon nem :) amugy ajanlom mindenki figyelmebe a spec.org-ot, ott az latszik, hogy 5 GHz-s power6 teljesitmenyben valamennyire tul is szarnyalja a 3 GHz-es xeon-t, legalabbis floating-pointban (mondjuk a fogyasztast nem irjak). Az 1.4 GHz-es ultrasparc T2-t viszont mindketto elveri mint buzi a faszat.
Csak hat arban gondolom a xeon sokkal kedvezobb (javitsatok ki ha tevednek).

u.i.: egyebkent engem is meglepett, hogy ennyire versenykepesek az intel konkurenciai, eddig ennek ellenkezojerol voltam meggyozodve, pedig neztem maskor is a spec.org-ot (csak ugy latszik nem jol).

- Use the Source Luke ! -

Akkor ha erre van szükséged, power blade-eket használsz. Akár közösen a pécékkel. Pont a spec.org-on láthasz erre példát, mintha a listavezető is így épülne fel.

negativ

intel blade es power blade

pece eleg messze all egy bladetol az en ertelmezesemben

--
.

Nem értem ezzel mit akartál mondani. Azt, hogy egy x86-os blade az nem PC?
Nekem PC=x86 (IA32 és AMD64).

PC=egyfajta pejoratív jelző ezekre. :)

ezeknek raadasul nem ibm pc kompatibilis biosuk van? (nem lattam soha ilyet)

- Use the Source Luke ! -

Miknek, az x86-os blade-eknek?

Nyilván lehet(ne) olyan, amiben pld EFI van, sőt olyan is, amiben Open Firmware. Vagy Simons' BASIC. Mégsem jellemző egyelőre. :)

Ezek hulla közönséges 8086 klónok attól, hogy egy kis dobozban vannak, 24 core van bennük, és 128 GiB memória...
http://picasaweb.google.com/nagy.attila/20090209Bl680c#5328349597668597170

igen az ibm bladecenter (vagy minek hivjak) gepekre vonatkozott a kerdes.
nyilvan igy van ahogy mondod, de ha efi lenne rajta lehetne vitatkozni, hogy ez nem pc hanem mac :), viszont a pc bios-szal ezen se lehet vitatkozni.

amugy kosz a kepet, mondom meg nem lattam ilyet

- Use the Source Luke ! -

jo akkor mitol pc a pc

szerinted?

az biostol?

--
.

Az x86 ISA-tól.

Idézet:
Hát, ha van egy HA clustered, aminek az alkalmazás rétege kb fél óra-óra mire elindul, akkor nem mindegy, hogy milyen gyakran döglik meg.

Mondom jol lekezeli a hibat. Vannak erre megoldasok x86+linux-on is, ne rogton holmi drbd-re vagy linux-ha -ra gondolj (ami BTW az egyik legborzasztobb megoldas: nem a meglevo szoftver kore kell HA-t hekkelni, hanem kapasbol olyan architekturat kell tervezni, ami hibaturo).

Tipikusan varnish+memcached+vmi okos mysql backendnek szokott mukodni. A lenyeg, hogy 1 node kiesese eseten a tobbi node barmifele extra konfig nelkul atveszi a feladatait.

ja te ilyen kis idealista vilagban elsz, mi, ahol mindenki majszikvelt meg memcachedet hasznal, igaz? aranyos (:

(en is szeretnek igy lenni, de hat mindig rossz helyen vagyok)

...varnish+memcached+vmi okos mysql backendnek...

Itt jelezném halkan, hogy lehet, hogy erre a fajta workloadra ez valóban alkalmas, de másra nem biztos.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

kar hogy nem lattak meg ettol eltero jellegu applikaciot
--
.

"BTW, megbizhatosag, mint olyan, amugy is felesleges a clusterek vilagaban. Ha van 16-64 vasad, akkor bizony valamelyik EL FOG ROMLANI. Pont."

Ez nem mindig ilyen egyszeru, a valo vilagban a hibak ravaszak, es direkt ki akarnak szurni az emberrel. :)
Nem mindegyik hibabol lesz kernel panic, van amelyik csak szep csendben data corruption-t okoz kb. havonta egyszer.

Egy munkatarsam meselte, hogy egyszer regen valami banki szoftvert fejlesztettek PC-re. Ott alkalmaztak azt az eljarast, hogy minden tranzakciot, es az egyes szamlaegyenlegeket is kulon taroltak, zaraskor pedig replay-eltek a tranzakciokat, es megneztek, hogy a ket vegeredmeny egyezik-e. Atlagban havonta 1-2 esetben talaltak igy elterest.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Biztos nem ZFS-t használtak. :)

Ez konnyen elkepzelheto, de ilyen jellegu gond nem csak a diszkkel (meg a RAM-al) lehet.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Akkor felteszem atlagban havi 1-2 bug javitasra is kerult?

Nem egeszen sikerult felfognod a mondandom lenyeget.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Imho normálisabb Oracle installok most is vagy Solaris-on, vagy AIX-on futnak...

Vagy nem.

Még az is lehet, hogy az Oracle kukázza a Linuxot és rágyúr az x86-Solarisra, elvégre most már házon belül van, és a Nehalem egy baromi ütős architektúra lett. Azért sok enterspájz fícsörben nincs még ott a Linux, mint a Solaris (próbáljunk normálisan clusterezni pl., haha).

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Minek clusterezni az oprendszert ha a middleware-ben már évek óta jól működik?
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

Mert azok, akik nagy cégeknél dolgoznak ezt tanulták meg, és mást el sem tudnak képzelni. :)

Kettőnk közül te dolgozol a nagyobb cégnél. :))

--
"How do you work in a team situation when all the other team members are fools and idiots?"

Hmm.... és asszem náluk is használnak Sun clustereket, és Tandemeket is. :)

Posvány, pénztemető. A cluster és a tandem (a locksteppinggel) is az önmagukban hibatűrő működésre képtelen alkalmazások kisegítésére való.

Maguk a megoldások (vagy hívjuk workaroundnak, mert ezek végülis csúnya hackek) végülis brilliáns elmék munkái, amelyekre persze az égvilágon semmi szükség nem lett volna, ha a lusta alkalmazás-programozók más csecsen nevelkednek, és nem mentik meg a seggüket a másik részlegen dolgozó kollegák.

Te lattal mar _tenyleg_ hibaturo szoftvert? Olyat, amelyik mezei PC-ken kepes megvalositani egy TMR rendszert, fel van keszitve a kulonbozo random data corruption hibakra a proci regisztereiben, cache-en, memoriaban, diszken, es kepes a hw-es megoldasokkal osszemerheto ideju failoverre?

En meg nem.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Nem láttam, de mivel nem is ezen a területen dolgozom (és szakértője sem vagyok a témának), ez érthető is. De ebből ugye azért nem az következik, hogy nincs is, sőt elvileg sem valósítható meg? :)

Az általad említett hibák egy mainframe-nél is előfordulhatnak, hogy ezek mégse okozzanak problémát, megpróbálhatják rábízni magukat a hardverre (emelt RAS-képességek, amelyek (egy része biztosan, nem vagyok tájékozott az utolsó bitig) megvannak nem mainframe rendszerekben is (Itanium pld)), vagy ha az sem nyerő, alkalmazhatnak TMR rendszert.
Az viszont (javíts ki, ha tévedek) ugyanolyan, mint a ZFS esete a hagyományos megoldásokkal: a hagyományos megoldásoknál stackelve vannak a logikai rétegek (bitek diszkek közötti másolgatása, fájlrendszer stb), míg a ZFS ezt ötvözi, és végül egy jobb megoldás születik.
Azaz az, hogy egy mai TMR rendszer a processzorokat működteti lockstepben adott esetben három különböző helyén a világnak, egyesével léptetve mindegyiket, valójában nem értve, hogy mi is történik biztosan gyorsabb, mint ha ezt szoftverből (pld. kernelben) akarnád megoldani, viszont biztos, hogy lassabb, mintha az alkalmazásba kódolod bele ezt a logikát, és annak a műveleti egységeit végzet ugyanilyen módon, megszavaztatva az eredményeket, és elvetve, adott esetben teljesen kizárva, vagy másikkal helyettesítve azt a kisebbséget, amely hibázik.

Az en fejembe valahogy nem fer bele, hogy a a felhasznaloi programnak kellene biztositania a hibaturest - ez kicsit olyasmi, mint ha a raid-et ki akarnank dobni, es mostantol minden programnak 2 peldanyban kellene irnia a file-jait a kulonbozo diszkekre.
Az mar jobban hangzik, hogy ezt a feladatot egy, az alkalmazas alatti sw-reteg (pl. VM) csinalja, de nekem inkabb ez tunik hacknek: sw-bol kuzdunk olyasmivel, amit hw-ben sokkal egyszerubben, gyorsabban, es elegansabban meg lehet oldani.

"ebből ugye azért nem az következik, hogy nincs is, sőt elvileg sem valósítható meg? :)"

Azert legalabbis furcsa, nem? :)

"viszont biztos, hogy lassabb, mintha az alkalmazásba kódolod bele ezt a logikát"

Miert lenne lassabb? Egy komparator aramkor meglehetosen egyszeru dolog, a vegrehajtason gyakorlatilag semmit sem lassit, es ha instruction retry jon, akkor minimalis az a munkamennyiseg, amit ki kell dobni.
Nem igazan latom, hogy a sw-es megoldas mit tudhat, amivel ezen gyorsitani lehetne.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A szoftveres megoldás úgy vélem azon gyorsíthat, hogy teljes mértékben érti is a feladatot. (erre hoztam a ZFS-es példát)
A komparátor áramkor hiába nem lassít semmit, ha az eredményeket egy három különböző kontinensen lévő (extrém példa, de a mainframe erről szól, nem? :) kupac próbálja rendben tartani.
A fény sajnos igen lassú.

Komparátor áramkör kontinensek között "nem játszik" szvsz. :)

"A szoftveres megoldás úgy vélem azon gyorsíthat, hogy teljes mértékben érti is a feladatot."

Ezt ertem, azt nem, hogy ezen informacio birtokaban pontosan hogyan.

"erre hoztam a ZFS-es példát"

Ami nem egeszen jo, mert a ZFS nem felhasznaloi program, hanem az alatta levo retegek kozul nehanynak az osszevonasa.

"A komparátor áramkor hiába nem lassít semmit, ha az eredményeket egy három különböző kontinensen lévő (...) kupac próbálja rendben tartani."

Ennek igy semmi ertelme, miert akarnak szetdobni 3 kulonbozo kontinensre?
Az integritas akkor is biztosithato, ha az a 3 processzor egymastol 10 centire van, a DR-hez meg nem kell a lockstep.

" (extrém példa, de a mainframe erről szól, nem? :)"

Nem, errol pont a masik oldal, az elosztott rendszer szol.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Én azt tippelném, hogy egy hibatűrő alkalmazást írni valószínűleg nem egyszerű, és feltételezem, hogy annyival több pénzbe és időbe kerül, hogy ezért oldják meg inkább hardtverből.

Van, ahol meg ez nem megy, pl. úgy tudom, az űrtechnikában nagyon csúnyán hibatűrő programokat készítenek. Legalábbis a főiskolán azt mondta valami tanár, hogy az ada nyelvet pl. azért használják erre, mert azzal milyen jó hibatűrő rendszereket tudnak készíteni...

G

Szerintem meg ennek is eljön az ideje. A szoftvert elég egyszer kifejleszteni, megírni, a hardvernél ez kicsit bonyolultabb...

Igaz, de ez fordítva is így van:

készíthetsz egy hibatűrő gépet, amire bármi szoftvert lehet tenni,

vagy készíthetsz egy nem hibatűrő gépet, hibatűrő szoftverrel.

Te azt mondod, a szoftvert egyszer kell megírni, a hw bonyibb.

Szerintem a hardver tényleg bonyolultabb, de azt tényleg egyszer kell elkészíteni. A szoftvert meg szerintem nem. Egyfelől nem egy darab szoftver fut a gépen, másfelől a szoftvert szokták fejleszteni általában. Bővítik, javítgatják.
Persze nem lehetetlen megcsinálni jól, de fenntartom: biztosítani kellene, hogy az összes szoftver hibatűrőre legyen tervezve (és megvalósítva), és toldozás-foldozás közben se kefélje el valaki, aki csak egy bug javításán dolgozik, nem látja át az egész rendszer, és a főnöke üti a fejét, hogy legyen kész estére.

Nem mondom, hogy lehetetlen. Sőt, én inkább a te nézetedet osztom: a clusteres PC-kből összerakott nagy izomgépek most is léteznek. Azt nem gondolom, hogy minden feladatra jó egy ilyen (hisz nem is minden feladat párhuzamosítható)

De úgy gondolom, hogy egész egyszerűen a szoftver fejlesztés nem annyira megbízható folyamat, mint a hw fejlesztés. Persze ez akár változhat is a jövőben, tudom. Igen. :-)

G

Sajnos hardverben is nagyon sokszor előfordulak hibák. Akár egy számítógépes processzort is korrekten letesztelni bonyolult feladat.
Hardver esetén is nagyon sokszor jelenik meg új revízió, ami tulajdonképpen az előző javítása.

Ha azt vesszük, a technika fejlődését továbbvinni a megalkotott hardverbe (pl. nem 8086-os processzorokból rakunk össze szuperszámítógépet) szintén plusz feladatot jelent. Lehet, hogy (jó- kevésbé jó) szoftvert hardverrel ellentétben szinte bárki megalkot, utóbbi esetén pedig mindez sokkal több pénzt emész fel és ritkábban történik (ill. talán pont az előbbiek miatt jobban kigondolt, megtervezett megoldásokat kapunk).
ill. egy esetleges hibával sorozatgyártásba került alkatrész/rendszer miatt főhet az "ember" feje...

- Ha arról van szó, egyfajta teszt fázis folyamán felmerülő, működést lényegesen befolyásoló hibákat még azelőtt javítják, hogy sorozatgyártásba kerülne a hardver, szoftver esetén pedig a kevésbé üzembiztos kódot is kiadják stabilként, mert közvetlen anyagi költségként nem jelentkezik és megintcsak nem a legegyszerűbb mindenre kiterjedően tesztelni.

Szerintem csupán ez okozza a lényegi különbséget.

Pontosan milyen middleware-re gondolsz? Amúgy meg mi van, ha az adott föladatnál azt nem lehet használni? :)

--
"How do you work in a team situation when all the other team members are fools and idiots?"

A csudába. Vehetem elő a Gimp-et újra :DD

--
trey @ gépház

trollinglista-update?

Hüm? Nem. Majd később kiderül.

--
trey @ gépház

Én arra tippeltem, amikor olvastam, hogy készül új logo a hupra bizonyos témák mellé...

Mondjuk a piros háttérben a fehér oválisnak mosolygó arca is lesz, meg szép napsugarai... :-)

Langyos :D

--
trey @ gépház

Nagyon kíváncsi leszek, mi lesz a dolog vége. A Sun jónéhány olyan dolgot adott, amiért kár volna, ha süllyesztőbe menne, ugyanakkor pedig jónéhány bukott dolog is van. Hogy melyik vonal marad? Majd az idő eldönti.

Az a része nem lepett meg, hogy az IBM nem veszi meg :) (erre tippeltem korábban is: http://hup.hu/cikkek/20090318/wsj_targyalasokat_folytat_az_ibm_a_sun_megvasarlasarol#comment-737676)

Az Oracle elsőre meglepő, de végigolvasva a kommenteket és jól meggondolva nem is hülyék :)

Abszolut nem, vegre normalis vezere lesz a merge utan a sun-nak is. Sokra vihetik meg.

Jelenleg az Oracle leginkább a Linux-ot nyomja OS-nek. (lásd: Linuxra jött ki először a 11g, és a majd minden patch is arra jön ki először). Vajon ez után átállnak a Solarisra? Ha már házon belül van...
Illetve mi lesz a Oracle unbreakable Linux-al?

Majd az idő eldönti, de nagyon kíváncsi leszek rá

---
Ubuntu 8.04 LTS

Innen:

The Sun Solaris operating system is the leading platform for the Oracle database. With the acquisition of Sun, Oracle can optimize the Oracle database for some of the unique, high-end features of Solaris. Oracle is as committed as ever to Linux and other open platforms and will continue to support and enhance our strong industry partnerships.

...

Will the ownership of Solaris change Oracle’s position on Linux?
No. This transaction enhances our commitment to open standards and choice. Oracle is as committed as ever to Linux and other platforms and will continue to support and enhance our strong industry partnerships.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

"Fujj MySQL; remélem, dobják a MySQL -t, stb."
Érdekes dolgokat szűrtök le, illetve reméltek, ahhoz képest, hogy a weboldalak közül rengeteg (kb min. 2/3 része) használja egészséggel.
Be is kellene tiltani, nem?

kötöjelkötöjel
Pedig ez nem az!

ja ez a fos hup is mysql-en megy :(

--
>ami belassu, az hirtelen nem benchmark

Fikazok jo resze MaS RDMS -t arul, vagy hasznal a cegenel ennyi.
Hozzaszolasokban foglalt velemenyek aranya nem tukrozi a latogatok velemeny aranyat. Welcome to hup.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hozzaszolasokban foglalt velemenyek aranya nem tukrozi a latogatok velemeny aranyat.
++


"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series

ahaha nem is tudtam h adatbazis expert is lettel

mondjuk ahol eleg a select * from gayporno where user like '*linuxusers*'; oda telleg felesleges is volna barmi mast rakni mint mysql. ez lehet h a web3.0as drupal egine hasznalok 90% at kielegiti de azert ne ebbol vonjuk mar le messzemeno kovetkezteteseket arrol h mennyire jo az adatabaziskezelo, mondjuk en inkabb OpenExcel-nek szoktam hivni mert olyan kepesegekkel rendelkezik a majkremsql.

--
.

Marmint ugy erted, hogy '%linuxusers%'? Ez a csillag milyen szintaxis? MSSQL?

--
"ne támogasd az erdők kiírtását mozijeggyel, töltsd le a netről!" - killllll, asva.info

Tuti nem, ott is %.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A frankfurti reptéren használt mainframe-ben így kell, nem értem mit pörögtök ezen.

ahahaha :D:D

find :)

nem kell minden kis aprosagra raporogni

--
.

neked is mondom, hogy jott ki uj verzio a 3.23-as ota. :)

Tyrael

Hiába, már sokan mondták neki. De nem hiszi el.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

10 milliárd légy és a lósz*r esete. :)))

--
"How do you work in a team situation when all the other team members are fools and idiots?"

http://www.oracle.com/sun/sun-faq.pdf

--
>ami belassu, az hirtelen nem benchmark

basszus, most akarok solaris-ból vizsgázni... kicsit elgondolkodtat, hogy megéri-e pénzt+energiát fektetni

IJ. Ezert kell megfontolni, hogy mire pocsekolja az ember az idejet. Az a kezdettol nyilvanvalo volt szamomra, hogy egy versenykeptelen ceg versenykeptelen termekere felesleges.

Ahogy a FAQ-ból kiderül, a Solaris lesz az Oracle elsődleges platformja. Így elég értelmetlennek tűnik amit mondasz.

Ezt írja? A verzióbuzi Solaris x86-ot használó (mondjuk el nem tudom képzelni ki az az őrült, aki Solaris x86-ra Oracle-t tesz) lúzerek biztos tűkön ülve várják már a 11g-t. :)

De lehet, hogy pár 10g patchre is úgy vágynak már, mint más egy falat kenyérre (nem tudom, nem követem, csak hallok innen-onnan hasonlókat)...

Segítek: csak a 4. bekezdésig kellett volna eljutni.

"Ahogy a FAQ-ból kiderül, a Solaris lesz az Oracle elsődleges platformja."
"The Sun Solaris operating system is the leading platform for the Oracle database"

De ha jól látom nem csak én gondolom úgy, hogy ez ebben az állapotában sehol sem jelenti azt, hogy ezután a Linux helyett a Solaris előtérbe kerül.

Ha más is úgy gondolja akkor rendben van...

Szerinted ez egyértelmű kinyilatkoztatása annak, hogy ezentúl a Linux helyett a Solaris lesz az elsődleges platform (akármit is jelentsen ez)?

Szerintem még ők sem tudják mi legyen, hiszen még meg sem történt az ügylet...

Szerintem igen.

Az ők sem tudják mi legyen dolog meg azért elég viccesen hangzik. Szerinted így döntötték el, hogy megveszik a céget?

hat te tenyleg bolond vagy, kerlek (:

he's just a usual linux funboy. ignore him.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Are you absolutely sure in the lack of his English knowledge or why don't you write Hungarian sentences? :)
:D

mert épp úgy tartotta kedvem :P
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

értem... :)

Funboy! ^_^

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Persze. Solarist rengeteg helyen használnak még most is, bankok, telekomok stb., és fognak is még. Ha Linux mellett Solarishoz is értesz, akkor csak megnöveled az esélyeidet, hogy kifogj valami jó állást.

--
"How do you work in a team situation when all the other team members are fools and idiots?"

a helyzet az, hogy a FAQ szerint: "The Sun Solaris operating system is the leading platform for the Oracle database"
IMHO a jövőre nézve nincs utalás

Cisco szerver,Oracle processzor ... hova jut a világ ...

én már a pet palackos sörnél elkezdtem gyanakodni...


No rainbow, no sugar

igen, meg internetes csajozás ...

uj ertelmet nyert a szamomra most a pet shop bojz (:

Fura, hogy mindenki a mysql-en rugozik. Mi lesz az openoffice-szal? Arra mi szuksege lesz az Oracle-nek?

Miért ne lehetne rá szüksége?
Profilbővítés? Sokkal tisztább ügy, mint a mutyisql.

Inkább arra lennék kíváncsi, ezek után hogy fogja magát "a világ első számú független szoftverszállítójának" nevezni az Oracle.

Lehet, hogy a kitűzött cél most már a világ első számú IT megoldásszállítója? :-)

www.sunblog.hu

Az ügyfelek csak nyernek ezzel. Nekünk is milyen jó lett volna pár évvel ezelőtt ez az összeborulás, amikor összehányta magát a Solaris-Oracle kombó, és mindkét cég a másikat hozta ki hibásnak.
:)

*yawn*

--
>ami belassu, az hirtelen nem benchmark

én arra leszek kíváncsi, hogy fog egymás mellett mutatni az oracle meg az ms reklám a telepítőben :)

Mint a Win + Sol reklam kombo.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

erről lemaradtam

a jre telepítője már szép piros :D (a jdk-é valamiért még nem)