> Oracle-preise
> kannst du sehr schnell kalkulieren: 100$ x Prozessorenanzahl x
> Frequenz
> der Proz in MHz. Da soetwas nun aber beim besten Willen niemand
> mehr
> bereit ist, zu zahlen, gibt Oracle dann auf seine eigenen
> Listenpreise
> Rabatte, im Extremfall bis zu 80%! Das ist Stumpfsinn.
1999 war ich bei einer kleineren Firma. Wir haben einem Kunden eine
Oracle Datenbank verkauft. Von der Menge oder vom Prestige her nix
interessantes für Oracle. Haben den normalen Preis bezahlt. Ich
schätze, dass die Kiste (Windows-PC, eine CPU) vieleicht 300MHz gehabt
haben könnte. Nach der Rechnung oben hätte die Oracle Lizens 60.000 DM
gekostet. Ich weiß nicht mehr, was sie gekostet hat, aber auf alle
Fälle unter 10 TDM, also Preisnachlässe von über 80% nach obiger
Rechnung.
Anders gesagt: Ich glaube das oben nicht recht.
Entwicklerlizensen gibt es bei Oracle übrigens sehr preiswert. Wenn man
Spaß daran hat, kann man die sich auch direkt runtersaugen. Kostet dann
nur die Internetgebühren. So war das jedenfalls vor drei Jahren.

href=”http://x-foto.ch/blog/2008/06/06/des-informatikers-spielzeug-das-mediacenter/”>spielzeughe Hersteller denn?
> > Ich hab von solchen Maschinen noch nicht viel gehört.
> > Find ich auch eher unsinn, der Intel ein-neues-spielzeug/”>Xeon ist nicht gerade der
> > typische Serverprozessor.
> > Mit dem Itanium wirds vielleicht anders
>
> Welche hersteller? Zum Anfang war es Unisys (die maschinen wurden
> unter eigenen Labeln auch von Compaq und HP vertrieben). Dann
> kamen IBM, Siemens/Fujitsu, Compaq, HP, Dell…..
Meines Wissens vertickt Dell (sowie ein paar andere PC-Schrauber) heute
immer noch die Unisys-Kiste. Und Compaq hat sich AFAIK ebenfalls Know
How von Unisys geholt. Inwieweit das wirklich “nur” Know How war oder
ob das - ähnlich wie Siemens das gerne macht - nur eine Umlabel-Aktion
ist, kann ich nicht beurteilen.
> Es macht durchaus Sinn, solche maschinen zu bauene. I.A. haben
> die 8 prozessorboards und sind in sich - wie z.B. eine
> Starfire - Partitionierbar e.t.c.. Warum bitte soll das keinen
> Sinn machen? Und der Xeonj ist ein typischer Server-Proz., für
> Workstation eher falsch.
Jens, weil der Xeon etwas mehr Cache hat, ist es es noch lange kein
Prozessor den man in einem Atemzug mit einem 64 Bit Serverprozessor a
la Ultra Sparc, Alpha oder POWER3/4 nennen sollte. Und auch nicht mit
Kisten wie einer Starfire.
Ansonsten kann ich mir nur LoneRider5 (msg=58) anschliessen.
Happy holidays

spielzeug schrieb am 25. Dezember 2001 20:34
>
> > > Oops, Power Challenge/O2000 mit IRIX ? Dito von anderen
> > > Herstellern …..
>
> > Wir waren bei Intel-basierten Maschinen….. Und da gab es
> etliches
> > mit 8 Proz, aber eben nicht mit mehr.
>
> Das ist nicht wahr. Die MX-500I lief sehr sauber mit 16
> Prozessoren, uebrigens auch mit 32. Von Sequent und DG gab
> es auch SMP-Ports auf Intel.
>
> Das Problem war nicht die Zahl der Prozessoren. Das Problem
> war zum Teil die Backplane. Multibus-I hatte Bitbreitenprobleme,
> ausserdem war die maximale Taktfrequenz zu niedrig, bei Multibus-II
> war
> das Messaging zwischen den Boards nicht perfekt geloest. Meist
> kludgte
> man mit dem shared-memory der Interboard-Kommunikation rum, weil
> die
> solicited messages zu komplex waren, und die unsolicited messages
> zu
> wenig Bandbreite brachten (fuer tty-Treiber waren sie
> ok, hab selbst mal einen geschrieben). Spaetere Backplanes haben
> das Problem besser geloest.
> Das war keine Frage der Prozessorarchitektur, auch wenn Intel bei
> Serverdesignern unbeliebt war, da die Prozessoren den Muell der
> Historie seit Zilog mit sich rumschleppten und der CISC-Befehlssatz
> Grenzen aufwies, die weder der PA, noch der Rx000, der Power-, der
> Alpha oder der Sparc-Prozessor aufwiesen.
> Mit anderen Worten: kein technisch engagierter und informierter
> Programmierer mochte es, mit Intel umzugehen. Sofern es noetig
> war, ein richtiges Betriebssystem wie Unix auf Intel zu portieren,
> hat man das natuerlich trotzdem gemacht. Und das ging recht gut.
> Unverbluemt: NT war Scheisse und bleibt Scheisse. Man hat es mit
> tierischer Muehe auf Alpha portiert (32 Bit, obwohl die Alpha-
> Prozessoren generisch 64 Bit konnten), auf Mips R3000 wurde es
> mit Mordskosten von Siemens portiert (Microsoft brachte das nicht)
> und fuer die R4000 aufgegeben. Auch das war ein 32Bit-Port.
> Ein 64Bit-NT sehe ich noch nicht. Wahrscheinlich wird auch IA64-NT5
> ein Gefummel. Ein Linux auf allem von Z-Series und CMOS, also den
> IBM-Grossrechnerprozessoren, bis herunter zum Intel-Mist, ist
> dagegeb kein Problem. Ein Unix eh nicht.
> Und mach Dir nichts vor, Jens: die Zukunft der Betriebssystem-
> entwicklung, auf allen Prozessoren, heisst Unix. Egal ob Linux,
> BSD, Solaris oder was auch immer.
> Unix-Systemprogrammierer werden auf den zerbroeckelnden
> Grabstein von Bill Gates pissen.
> Frohe Weihnachten
>
> a^2
//—————————————
Aqua hat mir was vorweggenommen. Grabstein und so.
Er wird wohl recht haben, nachdem nix neues passiert,
werden für Win64 meiner Meinung nach nur noch Thunking-Mechanismen
herschen. Meine Meinung zu IA64-NT5.
Aber was nützt ein 64-Bitter, wenn die Registergröße nicht
ausgenützt wird ??
Er läuft auf 4tel Tempo wohl ??
Was ich bis jetzt gehört habe ist der P4 zum Teil
langsamer als sein Brüderchen P3.
Ein weiter Hinweis auf Thunking.
Nehme mal an das die neu SuSE für P4 das doppelte
an Leistung rausholt. Habe mich zwischendurch
mal informiert.
Grüße , nix für ungut, happy Xmas
HankPym.
//——————————————————

spielzeugt nicht wahr. Die MX-500I lief sehr sauber mit 16
> Prozessoren, uebrigens auch mit 32. Von Sequent und DG gab
> es auch SMP-Ports auf Intel.
OK, die Kisten kenne ich nicht. Aber es ist natürlich auch prinzipiell
so, dass es durchaus MSMP-Systeme auf Intel-Basis gab. Man schaue nur
in die top500, da rangiert eine Maschine mit Pentium-Pro-Proz. oben.
Nur ist da kein Seriengerät. > Das Problem war nicht die Zahl der Prozessoren. Das Problem
> war zum Teil die Backplane. Multibus-I hatte Bitbreitenprobleme,
> ausserdem war die maximale Taktfrequenz zu niedrig, bei Multibus-II
> war
> das Messaging zwischen den Boards nicht perfekt geloest. Meist
> kludgte
> man mit dem shared-memory der Interboard-Kommunikation rum, weil
> die
> solicited messages zu komplex waren, und die unsolicited messages
> zu
> wenig Bandbreite brachten (fuer tty-Treiber waren sie
> ok, hab selbst mal einen geschrieben). Spaetere Backplanes haben
> das Problem besser geloest.
Nice to know. So intensiv habe ich da noch nicht nachgelesen (zumal ich
das eher nicht benötige).
> Das war keine Frage der Prozessorarchitektur, auch wenn Intel bei
> Serverdesignern unbeliebt war, da die Prozessoren den Muell der
> Historie seit Zilog mit sich rumschleppten und der CISC-Befehlssatz
> Grenzen aufwies, die weder der PA, noch der Rx000, der Power-, der
> Alpha oder der Sparc-Prozessor aufwiesen.
Es ist hier wohl aber auch noch ein anderes Problem, das zum Tragen
kommt. Wenn ich - wie SUN - von dem Verkauf meiner Server lebe, dann
investiere ich auch wesentlich mehr in die Entwicklung notwendiger
Features. Das war bei Intel halt nicht so, da reicht die Masse. Und
Intel baut ja selber keine Kisten.
> Mit anderen Worten: kein technisch engagierter und informierter
> Programmierer mochte es, mit Intel umzugehen. Sofern es noetig
> war, ein richtiges Betriebssystem wie Unix auf Intel zu portieren,
> hat man das natuerlich trotzdem gemacht. Und das ging recht gut.
“richtiges BS” kommentiere ich mal jetzt nicht…. Aber auch der erste
Satz ist so nicht stimmig. Schau dir mal SCO an und wo die hergekommen
sind. Oder Novell.
> Unverbluemt: NT war Scheisse und bleibt Scheisse. Man hat es mit
> tierischer Muehe auf Alpha portiert (32 Bit, obwohl die Alpha-
> Prozessoren generisch 64 Bit konnten), auf Mips R3000 wurde es
> mit Mordskosten von Siemens portiert (Microsoft brachte das nicht)
> und fuer die R4000 aufgegeben. Auch das war ein 32Bit-Port.
NT ist eigentlich ein recht gutes System. Stbail, mit sauberem Aufbau
und relativ einfach (bei elementaren Aufgaben) zu managen. Es hat lange
Zeit nicht besonders gut Skaliert, die Zeiten sind aber vorbei. Was
also willst du? Ich muss doch nicht andere Plattformen unterstützen
(kenne kein MVP für Intel…). Und das Alpha nicht mehr unterstützt
wird, ist eher ein Problem von Digital gewesen, die sich selber nicht
mehr dazu committed haben. Du benötigst aber sehr spezielles Know How,
wenn du ein solches BS implementieren willst. Und das gehört dann auch
der Hersteller dazu.
> Ein 64Bit-NT sehe ich noch nicht. Wahrscheinlich wird auch IA64-NT5
> ein Gefummel. Ein Linux auf allem von Z-Series und CMOS, also den
> IBM-Grossrechnerprozessoren, bis herunter zum Intel-Mist, ist
> dagegeb kein Problem. Ein Unix eh nicht.
Ich habe Windows bereits auf IA64 gesehen…. Und es läuft schnell und
gut. Ist übrigens auch im Interesse von Intel, die gemeinsam mit MS
daran basteln. Die wollen nämlich ihre Prozessoren auch verkaufen…
> Und mach Dir nichts vor, Jens: die Zukunft der Betriebssystem-
> entwicklung, auf allen Prozessoren, heisst Unix. Egal ob Linux,
> BSD, Solaris oder was auch immer.
Die Zukunft fer BS ist heterogen. So, wie sie es bisher war. und da
wird sich auch nichts daran ändern. Warum soll ich nicht die Vorteile
eines OS/400 nutzen, genauso wie die von Windows oder die von Novell?
Ich glaube eher, du machst dir etwas vor. Die Aufgabem sind so
spezifisch, dass du mit nur einem System sehr schnell auf die nase
fliegst. Das beste beispiel ist der der Home-Anwender. Willst du den
ernsthaft vor ein Unix-System setzen? Er muss ja root-Rechte haben. Und
dann arbeitet er auch damit. Und bis zu einem rm * auf root ist es dann
nicht mehr weit…. Dazu kommt, dass der technische (nicht aus Sicht
der Arbeitsweise, da unterscheiden sich die heutigen Systeme sehr wenig
voneinander) Aufbau z.B. auch von Linux derart archaisch ist, dass man
das nicht unbedingt gut heissen kann. Aber letzten Endes ist es
Geschmacksache.
> Unix-Systemprogrammierer werden auf den zerbroeckelnden
> Grabstein von Bill Gates pissen.
…. von unten, aus der Hölle. Oder wie?
> Frohe Weihnachten
Gleichfalls.
>
> a^2
Jens

>
> > Hallo,
> > > Der Impuls war der, dass M$ so stur ist und nichts anderes als
> > > Intel kennt…
> > du hattest wohl noch nie die CD von NT 4.0 in Händen und Dir mal
> > die Verzeichnisse neben i386 angesehen.
> Hast du die Ports mal live gesehen? Alpha ging ja noch einigermaßen
> (auch wenn nicht so recht schlüssig war, was ein
> 32Bit-Betriebssystem
> auf einer 64Bit-Architektur soll), die anderen Ports (insbesonere
> PowerPC) waren einfach nur lächerlich. Und ja, ich habe NT auf ‘ner
> RS/6000 gesehen
>
> über den Satz bzgl. der Ahnungslosogkeit sage ich jetzt mal nix
//——————- HankPym
Port auf RS/6000 ???
Alpha ging wegen des Endian-Formats schneller.
Ahnungslos ???
Ja, sicher. Null Plan.
HankPym. *kopfschüttel* über Eure Ahnungslosigkeit.
Es folgt alphaops.h nur die ersten Zeilen. Visual C 4 prof.
mit Lizenz für MS C seit MS C 5.1 .
—————
/*
Copyright (c) 1992-1995 Digital Equipment Corporation
Module Name:
alphaops.h
Abstract:
Alpha AXP instruction and floating constant definitions.
Author:
Revision History:
–*/
#ifndef _ALPHAOPS_
#define _ALPHAOPS_
//
// Instruction types.
// The Alpha architecture does not number the instruction types,
// this numbering is for software decoding only.
//
#define ALPHA_UNKNOWN 0 // Reserved or illegal
#define ALPHA_MEMORY 1 // Memory (load/store)
#define ALPHA_FP_MEMORY 2 // Floating point Memory
#define ALPHA_MEMSPC 3 // Memory special
#define ALPHA_JUMP 4 // Jump (memory formation)
#define ALPHA_BRANCH 5 // Branch
#define ALPHA_FP_BRANCH 6 // Floating Point Branch
#define ALPHA_OPERATE 7 // Register-register operate
#define ALPHA_LITERAL 8 // Literal-register operate
#define ALPHA_FP_OPERATE 9 // Floating point operate
#define ALPHA_FP_CONVERT 10 // Floating point convert
#define ALPHA_CALLPAL 11 // Call to PAL
#define ALPHA_EV4_PR 12 // EV4 MTPR/MFPR PAL mode instructions
#define ALPHA_EV4_MEM 13 // EV4 special memory PAL mode access
#define ALPHA_EV4_REI 14 // EV4 PAL mode switch
//
// Instruction Opcodes.
//
#define CALLPAL_OP 0×00 // ALPHA_CALLPAL
#define _01_OP 0×01 // - reserved opcode
#define _02_OP 0×02 // - reserved opcode
#define _03_OP 0×03 // - reserved opcode
#define _04_OP 0×04 // - reserved opcode
#define _05_OP 0×05 // - reserved opcode
#define _06_OP 0×06 // - reserved opcode
#define _07_OP 0×07 // - reserved opcode
#define LDA_OP 0×08 // ALPHA_MEMORY
#define LDAH_OP 0×09 // ALPHA_MEMORY
#define _0A_OP 0×0A // - reserved opcode
#define LDQ_U_OP 0×0B // ALPHA_MEMORY
#define _0C_OP 0×0C // - reserved opcode
#define _0D_OP 0×0D // - reserved opcode
#define _0E_OP 0×0E // - reserved opcode
#define STQ_U_OP 0×0F // ALPHA_MEMORY
#define ARITH_OP 0×10 // ALPHA_OPERATE or ALPHA_LITERAL
#define BIT_OP 0×11 // ALPHA_OPERATE or ALPHA_LITERAL
#define BYTE_OP 0×12 // ALPHA_OPERATE or ALPHA_LITERAL
#define MUL_OP 0×13 // ALPHA_OPERATE or ALPHA_LITERAL
#define _14_OP 0×14 // - reserved opcode
#define VAXFP_OP 0×15 // ALPHA_FP_OPERATE
#define IEEEFP_OP 0×16 // ALPHA_FP_OPERATE
#define FPOP_OP 0×17 // ALPHA_FP_OPERATE
#define MEMSPC_OP 0×18 // ALPHA_MEMORY
#define PAL19_OP 0×19 // - reserved for PAL mode
//#define MFPR_OP 0×19 // ALPHA_MFPR
#define JMP_OP 0×1A // ALPHA_JUMP
#define PAL1B_OP 0×1B // - reserved for PAL mode
#define _1C_OP 0×1C // - reserved opcode
#define PAL1D_OP 0×1D // - reserved for PAL mode
//#define MTPR_OP 0×1D // ALPHA_MTPR
#define PAL1E_OP 0×1E // - reserved for PAL mode
#define PAL1F_OP 0×1F // - reserved for PAL mode
#define LDF_OP 0×20 // ALPHA_MEMORY
#define LDG_OP 0×21 // ALPHA_MEMORY
#define LDS_OP 0×22 // ALPHA_MEMORY
#define LDT_OP 0×23 // ALPHA_MEMORY
#define STF_OP 0×24 // ALPHA_MEMORY
#define STG_OP 0×25 // ALPHA_MEMORY
#define STS_OP 0×26 // ALPHA_MEMORY
#define STT_OP 0×27 // ALPHA_MEMORY
#define LDL_OP 0×28 // ALPHA_MEMORY
#define LDQ_OP 0×29 // ALPHA_MEMORY
#define LDL_L_OP 0×2A // ALPHA_MEMORY
#define LDQ_L_OP 0×2B // ALPHA_MEMORY
#define STL_OP 0×2C // ALPHA_MEMORY
#define STQ_OP 0×2D // ALPHA_MEMORY
#define STL_C_OP 0×2E // ALPHA_MEMORY
#define STQ_C_OP 0×2F // ALPHA_MEMORY
#define BR_OP 0×30 // ALPHA_BRANCH
#define FBEQ_OP 0×31 // ALPHA_BRANCH
#define FBLT_OP 0×32 // ALPHA_BRANCH
#define FBLE_OP 0×33 // ALPHA_BRANCH
#define BSR_OP 0×34 // ALPHA_BRANCH
#define FBNE_OP 0×35 // ALPHA_BRANCH
#define FBGE_OP 0×36 // ALPHA_BRANCH
#define FBGT_OP 0×37 // ALPHA_BRANCH
#define BLBC_OP 0×38 // ALPHA_BRANCH
#define BEQ_OP 0×39 // ALPHA_BRANCH
#define BLT_OP 0×3A // ALPHA_BRANCH
#define BLE_OP 0×3B // ALPHA_BRANCH
#define BLBS_OP 0×3C // ALPHA_BRANCH
#define BNE_OP 0×3D // ALPHA_BRANCH
#define BGE_OP 0×3E // ALPHA_BRANCH
#define BGT_OP 0×3F // ALPHA_BRANCH
#define LDA_OP_STR “lda”
#define LDAH_OP_STR “ldah”
#define LDQ_U_OP_STR “ldq_u”
#define STQ_U_OP_STR “stq_u”
#define LDF_OP_STR “ldf”
#define LDG_OP_STR “ldg”
#define LDS_OP_STR “lds”
#define LDT_OP_STR “ldt”
#define STF_OP_STR “stf”
#define STG_OP_STR “stg”
#define STS_OP_STR “sts”
#define STT_OP_STR “stt”
#define LDL_OP_STR “ldl”
#define LDQ_OP_STR “ldq”
#define LDL_L_OP_STR “ldl_l”
#define LDQ_L_OP_STR “ldq_l”
#define STL_OP_STR “stl”
#define STQ_OP_STR “stq”
#define STL_C_OP_STR “stl_c”
#define STQ_C_OP_STR “stq_c”
#define BR_OP_STR “br”
#define FBEQ_OP_STR “fbeq”
#define FBLT_OP_STR “fblt”
#define FBLE_OP_STR “fble”
#define BSR_OP_STR “bsr”
#define FBNE_OP_STR “fbne”
#define FBGE_OP_STR “fbge”
#define FBGT_OP_STR “fbgt”
#define BLBC_OP_STR “blbc”
#define BEQ_OP_STR “beq”
#define BLT_OP_STR “blt”
#define BLE_OP_STR “ble”
#define BLBS_OP_STR “blbs”
#define BNE_OP_STR “bne”
#define BGE_OP_STR “bge”
#define BGT_OP_STR “bgt”
//
// Type (1) Memory Instruction Format.
// Type (2) Memory Special Instruction Format.
//
// 3 2 2 2 2 1 1
// 1 6 5 1 0 6 5 0
// ———– ——— ——— ——————————-
// | opcode | Ra | Rb | Memory_disp |
// ———– ——— ——— ——————————-
//
// LDAx Ra.wq,disp.ab(Rb.ab) x = (,H)
// LDx Ra.wq,disp.ab(Rb.ab) x = (L,Q,F,G,S,T)
// LDQ_U Ra.wq,disp.ab(Rb.ab)
// LDx_L Ra.wq,disp.ab(Rb.ab) x = (L,Q)
// STx_C Ra.mq,disp.ab(Rb.ab) x = (L,Q)
// STx Ra.rq,disp.ab(Rb.ab) x = (L,Q,F,G,S,T)
// STQ_U Ra.rq,disp.ab(Rb.ab)
//
typedef struct _Alpha_Memory_Format {
LONG MemDisp : 16;
ULONG Rb : 5;
ULONG Ra : 5;
ULONG Opcode : 6;
} Alpha_Memory_Format;
//
// Special Memory instruction function codes (in Memdisp).
//
#define TRAPB_FUNC 0×0000
#define EXCB_FUNC 0×0400
#define MB_FUNC 0×4000
#define WMB_FUNC 0×4400
#define MB2_FUNC 0×4800
#define MB3_FUNC 0×4C00
#define FETCH_FUNC 0×8000
#define FETCH_M_FUNC 0xA000
#define RPCC_FUNC 0xC000
#define RC_FUNC 0xE000
#define RS_FUNC 0xF000
#define TRAPB_FUNC_STR “trapb”
#define EXCB_FUNC_STR “excb”
#define MB_FUNC_STR “mb”
#define MB1_FUNC_STR “wmb”
#define MB2_FUNC_STR “mb2″
#define MB3_FUNC_STR “mb3″
#define FETCH_FUNC_STR “fetch”
#define FETCH_M_FUNC_STR “fetch_m”
#define RPCC_FUNC_STR “rpcc”
#define RC_FUNC_STR “rc”
#define RS_FUNC_STR “rs”
//
// Type (3) Memory Format Jump Instructions.
//
// 3 2 2 2 2 1 1 1 1
// 1 6 5 1 0 6 5 4 3 0
// ———– ——— ——— — —————————
// | opcode | Ra | Rb |Fnc| Hint |
// ———– ——— ——— — —————————
//
// xxx Ra.wq,(Rb.ab),hint xxx = (JMP, JSR, RET, JSR_COROUTINE)
//
typedef struct _Alpha_Jump_Format {
LONG Hint : 14;
ULONG Function : 2;
ULONG Rb : 5;
ULONG Ra : 5;
ULONG Opcode : 6;
} Alpha_Jump_Format;

spielzeugrigens noch was zum Nachdenken angesichts der “ueber 90%”:
> Im Jahre 1988 stammten von weltweit ca. 34 Millionen Computern
> gut 29 Millionen von einer Firma, die Hardware und Betriebs-
> system lieferte. Diese Firma hiess Commodore Bueromaschinen.
……
……
> Dazu kamen weitere mehrere zehntausend Unix-Installationen auf
……
> unter zehntausend Mainframe-
> Rechner unter der Betriebssystemarchitektur OS-360/370 (ab wann
> hiess das eigentlich MVS) und unter 2000 Mainframerechner mit
> dem 360-kompatiblen Betriebssystem BS2000 von Siemens.
>
> (Zahlen sind alle aus dem Gedaechtnis, fuer Korrektur/Praezisierung
> danke ich im voraus)
präzisierung:
MVS wurde bereits Mitte der Siebziger eingeführt und erst ca. 1996 in
OS-390 umbenannt (=jetzt z-OS). OS-360 gab es von 1964 bis ca. 1973,
das war der Vorgänger..
http://os390-mvs.hypermart.net/mvshist.htm
gruß,
der engel frank

spielzeugkalierung über 256 Proz. und mehr bei fast linearem
> Lastverhalten
> hinzubekommen. Das bricht bei Oracle bei >100 bereits ein.
Wenn du diesen realitätsfremden Benchmark meinst *lach*.
Nicht alle Probleme in der Wirklichkeit lassen sich so gut verteilen…
Was die skalierung Angeht dürfte deshalb Oracle um einiges besser da
stehen, da es nicht nur auf 8088 und Nachfolger läuft…
kostet bei Oralce Unmengen an Geld.
>
> Und SQL2000 wird auch zunehmend in großen Umgebungen eingesetzt. So
> kenne ich Telko’s, die ihre DataWarehouse-Lösungen unter SQL2000
> laufen
> haben und dort Unmengen an Daten verwalten (–> telefongespräche
> dürfen
> in anonymisierter Form beliebig aufgehoben werden). Da gibt es
> durchaus
> Cubes mit 80-100 GB.
Ich glaube die übermäßige Dominanz von M$-Produkten in der Industrie
liegt weniger darin begründet dass sie bessere SW herstellen.
> Im Grunde geben sich beide nicht mehr viel. Nur im Gegensatz zu
> Ellison
> behautpet zumindest MS das auch nicht sondern sagt lediglich, dass
> man
> heute mit SQL Server mit den anderen mithalten kann.
Super Larry ?
Erinerts du dich.
> Und der SQL Server ist durchaus kein Billigprodukt. Eine
> Prozessorlizenzierung einer 32×1GHz-Maschine kostet immerhin satte
> 640.000$ (Oracle allerdings 3.2000.000$).
>
> Was Access in diesem ZH soll, ist mir nicht klar.
>
> > > Ach so, Patch ist schon bereit.
> >
> > Jau Da sieht man: Auch Konzerne koennen schnell reagieren, es
> > sei
> > denn, es steht Microsoft auf dem Firmenschild >
> Das geht bei MS genauso.
Ja genau, bei der Firma die das veröffentlichen von Sicherheitslücken
verhindern will…
> Jens

ing-games-get-ready-for-the-real-war/”>spielzeugs sein, dass Ihr etwas wesentliches aus den Augen verliert?
Nein.
> Eure Implementierungen betreffen vermutlich keine 2-3% des
> IT-Marktes.
Du zaehlst falsch. Nach Zahl der Installationen, wenn man
keinen Unterschied zwischen Client und Server macht, duerften
es 8-12% des Computermarktes sein.
Ob es sehr sinnvoll ist, Mainframes, Supercomputer, Server aller
Art und PC-Clients nach Kopfzahl auszuzaehlen, mag man bezweifeln.
Aber nun gut. Die 88-92%, die Microsoft da hat, sind schon relativ
beeindruckend, wenn man auf so etwas schaut. Zaehlen wir die PDAs
noch dazu, sinkt der MS-Wintel-Anteil schon in den Bereich von
unter 80%, nimmt man Microcontroller und Steuerungen hinzu, was
nicht illegitimer ist, als einen MVS-Mainframe und einen PC als
zwei Computer zusammenzuzaehlen, schrumpft der Wintel-Anteil weit
unter 30%, mit Spielkonsolen und Kneipenautomaten zusammen auf
vielleicht 20 Prozent. Gehen wir nach Umsaetzen aller Hardware-
und Softwarebuden, schrumpft der Microsoft-Anteil sogar unter
diesen Wert. Und alle Baeckereien der nicht so gewaltig grossen
BRD zusammen machen eh mehr Umsatz als der Weltkonzern Microsoft.
> Grosskonzerne mögen solche Server-Parks ja noch aufstellen und vor
> allem finanzieren, das Gross der Firmen benötigen diese Rechenkraft
> einfach nicht.
Naja, das “Gross” der Menschen braucht eh keine Computer. Was
moechtest Du uns also mitteilen?
> Somit bauscht Ihr hier ein Thema auf, welches für 90% der Anwender
> und Anwendungen nicht relevant ist.
Genau genommen bauschen alle Computernutzer ein Thema auf, das fuer
die grosse Mehrzahl der Menschen nicht relevant ist. Sollten wir
nicht lieber ueber Lebensmittel oder Sex diskutieren? Das betrifft
alle Menschen.
> Um Euer anerkennendes KnowHow zu unterstreichen und es hier
> ständig untermauern zu wollen, dass man’s doch besser weiss,
> bringt meiner Ansicht nach wenig.
Naja, moechtest Du uns sagen, es waere besser, ueber Themen zu
diskutieren, von denen man keine Ahnung hat? Oder dass man nicht
mehr wissen darf als die 92-95% User von PC-Clients, deren Marke
mit grossem M anfaengt? Darf ich denn noch andere Blaetter als die
Bild-Zeitung lesen, ohne Rechtschreibfehler schreiben und einen
Wortschatz ueber 300 Worten haben? Oder ist das schon zu elitaer?
> Aber wenn’s Euch gut tut…
Naja, Diskussionen zwischen Leuten, die sich in einem Themengebiet
auskennen, fuehrt zum Austausch von Informationen. Ich habe hier
im Forum sowohl Fakten als auch Sichtweisen kennengelernt, die ich
vorher nicht kannte. Das tut gut.
> Wer was auf welchen Servern in Euren Dimensionen aufsetzt, wird
> wohl immer Geschmacksache sein und eine Entscheidung Eures
> IT-Teams.
Das ist eher eine Entscheidung von Geschaeftsleitungen als von
IT-Teams. Geschmacksache ist es eher selten. Es geht eher um
technische und oekonomische Fragen. Aber sicher gibt es dabei
auch Fehlentscheidungen. Darueber diskutieren wir unter anderem.
> Da spielt das BS, denke ich mal, eine untergeordnete Rolle.
> Jemand muss das Ganze ja auch noch bezahlen.
Das Betriebssystem spielt da sehr wohl eine Rolle, gerade weil
das Ganze bezahlt werden muss. Da spielt es schon eine Rolle,
ob der Server bis zum naechsten Upgrade vergessen werden kann
oder staendiger Handreichung bedarf. Und Downtimes sind auch
sehr teuer, Sicherheitsalarme noch viel teurer.
Uebrigens noch was zum Nachdenken angesichts der “ueber 90%”:
Im Jahre 1988 stammten von weltweit ca. 34 Millionen Computern
gut 29 Millionen von einer Firma, die Hardware und Betriebs-
system lieferte. Diese Firma hiess Commodore Bueromaschinen.
Etwa 26 Millionen waren Rechner vom Typ C-64, einige Millionen
VC-20, C-16 und Pet und etwas ueber eine Million Buerorechner
der Typreihen 3000 und 8000. Dazu kamen noch einige Millionen
Heim- und kleine Buerocomputer von Firmen, deren Namen heute
nicht mehr viele kennen (ich nenne mal Schneider und Atari *g*,
das waren aber beileibe nicht die einzigen).
Etwa 1,8 Millionen Maschinen waren PC der Typen IBM PC und Clones
(8088- und 8086-Prozessoren, ueber eine Million) sowie PC AT 286
und 386 (etwa eine Viertelmillion, davon ein Zehntel AT-386)
sowie PC von Apple (ueber 200.000). Von diesen PC waren ueber
eine Million mit MS-DOS ausgeruestet, mehrere hunderttausend
mit CP-M und etwa hunderttausend mit dem Unix-Abkoemmling Xenix,
den Microsoft gerade an SCO verkauft hatte.
Dazu kamen weitere mehrere zehntausend Unix-Installationen auf
Hardware aller Art, einige zehntausend Serversysteme VAX und PDP
mit VMS der Firma Digital Equipment, etwa genausoviele Midrange-
Computer der Baureihen /34, /36 und /38 der Firma IBM (die
Vorgaenger der spaeteren AS-400) dazu unter zehntausend Mainframe-
Rechner unter der Betriebssystemarchitektur OS-360/370 (ab wann
hiess das eigentlich MVS) und unter 2000 Mainframerechner mit
dem 360-kompatiblen Betriebssystem BS2000 von Siemens.
(Zahlen sind alle aus dem Gedaechtnis, fuer Korrektur/Praezisierung
danke ich im voraus)
Fazit: Schon damals gab es PC. Aber es gab darunter eine viel
vielfaeltigere und buntere Welt der Client- und Homecomputer.
Man haette 1988 schon ziemlich tief in die Kristallkugel schauen
muessen, um zu sehen, dass die damaligen ueber 90% der Computer
knapp 15 Jahre spaeter verschwunden sein wuerden.
Ich sage nicht, dass in knapp 15 Jahren Microsoft weg ist (ich
denke auch nicht, dass das der Fall sein wird). Aber 1988 haette
auch keiner gesagt, dass Commodore verschwindet, und wenn, dann
eher zu Gunsten von IBM.
Sicher ist nur eins: Unix gab es schon damals, und es sieht nicht
so aus, als wenn es das in 15 Jahren nicht immer noch geben wird.
Dafuer braucht es keine Kristallkugel.
a^2

spielzeugein, kommt schon hin. vorrausgesetzt, es wird das
> > powerunits-lizenzmodell verwendet. oracle ist schweineteuer
> > (nicht nur die lizenzen, sondern auch die jährlichen kosten!),
> > aber dafür kann das RDBMS auch ne menge, insbesondere bei der
> > verwaltung grosser datenmengen.
>
> Das Powerunit-Lizenzmodell ist aber Pflicht, wenn ich die Kiste für
> unbestimmte Useranzahl verwednen will, sprich: WEB-Apps. Dann
> greift
wie ich vor kurzem gehört habe, hat es bei der lizensierung seitens
oracle änderungen gegeben. speziell bei dem powerunit-modell (zeit
wurde es ja).
> auch bei MS diese Variante mit den 640.000 $ (sonst kostet das auf
> nur
> 25%).
ich hab mit sql6 und sybase ase gearbeitet. waren beide nicht schlecht
(sind sich durch die gemeinsamen wurzeln recht ähnlich). sybase würde
ich heute immer noch einsetzen. wenn sql2000 auf anderen plattformen
laufen würde, vielleicht auch das. aber so bin ich auf ms-intel schiene
festgelegt und das gefällt mir überhaupt nicht.
sollte es ein windows ohne den ganzen gui-schnickschnack (dann kann es
aber nicht mehr windows heissen geben, waers einen blick wert.
ein server muss bei mir nur mit der für den zweck notwendigen
funktionalität ausgestattet sein. also kein X, keine entwicklingstools
wie compiler, libs etc. nur das notwendige eben. ich kriege jedesmal
nen dicken hals, wenn externe bspw. solaris auf ner sparc aufsetzen und
mich begrüsst die cde, obwohl die kiste für die dmz bestimmt ist.
> Oralce kann aber heute eigentlich nicht mehr, als andere RDBMS wie
> DB/2
da habe ich meine zweifel. vor nicht allzu lang habe ich mal eine
übersicht gesehen (müsste ich noch irgendwie rumliegen haben), wo
informix, oracle, sybase und db2 miteinander verglichen worden sind.
und da hatte oracle den interessantesten funktionsumfang (aus meiner
sicht).
sybase kommt gegen oracle nicht an (nicht das ich sybase schlecht
finde, im gegenteil). immer mit hinblick auf grosse datenbanken
(>100GB). da wollen wir nicht von echten VLDBs reden.
> (auch wenn mir das Ding wohl immer suspekt beliben wird…),
> Informix
> (halte ich für besser als Oracle), Sybase oder eben auch SQL2000.
> Im
also informix, db2 (kommt ja nun beides von ibm) sind interessant
und sicher ein test wert. sybase spielt für mich in dieser klasse nicht
mit.
ist eher für kleinere OLTP-db interessant (ist da auch recht fix).
sql2000 fällt wegen der festgelegten plattform für mich aus.
> gegenteil - die anderen haben z.T. Features ‘drin, für die du bei
> Oracle extrem dazulöhnen darfst. Das beginnt bei Entwicklungstools
die tools sind zugegebenermassen ein unrühmliches kapitel für sich.
hier weiche ich eh auf 3rdparty aus
> und
> endet bei OLAP. Keine der großen DB kommt heute noch ohne
> SAN-Anbindung, verteilte DB’s und parallele Queries daher. Und alle
> -
> ausser oracle - halten sich weitgehend an ISO-SQL (wobei es
> durchaus
> Erweiterungen gibt wie z.B. bei Informix oder SQL Server). Oracle
> hat
> z.B. bis heute noch keinen standardisierten Innerjoin
> implementiert.
> Und die Möglichkeiten von parallelen Queries über Plattformgenzen
> hinweg (Sybase) oder Skaliebarkeit der DB über X maschinen (SQL
> Server)
> machen bis heute bei Oracle riesen Probleme, wenn sie denn
> überhaupt
> vorhanden sind.
hmm, versteh ich nicht. was ist mit ops im loadbalancing modus?
skaliert bei mir wunderbar (db auf fc-storage). und da hat es mit 9i
nochmals verbesserungen/vereinfachungen gegeben.
> Oracle ist vor allem deshalb heute (noch) so stark am markt
> vertreten,
> weil es so vor 6, 7 jahren nichts anderes vernünftiges gab. Und
> wenn du
> in einer Firma jetzt erst einmal Oracle-Know How aufgebaut hast,
> dann
> wirst du schwerlich wechseln wollen. daneben gibt es in größeren
das ist sicherlich wahr. knowhow aufzubauen braucht zeit und geld.
> Unternehmen ohnehin einen Zoo, auch bei DBMS. Einen absolut
> überzeugenden grund, Oracle und nur Oracle zu verwednen, gibt es
aber das hat doch nie jemand behauptet, oder? wer oracle als
web-backend db einsetzt, macht IMHO irgendwas verkehrt. für solche
zwecke (kleine OLTP-db) reicht sybase oder meinethalben sogar postgres.
oracle, informix, db2 (naja vielleicht auch sql2000 machen nur ab
datamart-klasse aufwärts sinn.
-j