Discussion:
S: AIX für alte PS/2 Systeme
(zu alt für eine Antwort)
Marc-Tell Volkmann
2010-10-30 22:15:50 UTC
Permalink
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Falls jemand soetwas verstauben läßt und einfach nicht weiss, wohin
damit, kann er sich ja bei mir melden.
Markus H. Maussner
2010-10-31 19:06:15 UTC
Permalink
Post by Marc-Tell Volkmann
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Falls jemand soetwas verstauben läßt und einfach nicht weiss, wohin
damit, kann er sich ja bei mir melden.
moin moin

k.a. ob das hilft, aber auf dem unixforum wurde das thema auch vor
kurzem mal angeschnitten... (iirc)

grüße

markus
Michael Kraemer
2010-10-31 20:46:09 UTC
Permalink
Post by Markus H. Maussner
Post by Marc-Tell Volkmann
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Falls jemand soetwas verstauben läßt und einfach nicht weiss, wohin
damit, kann er sich ja bei mir melden.
moin moin
k.a. ob das hilft, aber auf dem unixforum wurde das thema auch vor
kurzem mal angeschnitten... (iirc)
grüße
markus
originale wird wohl keiner rausrücken,
die images gibt's aber im web ...
Christian J. Bauer
2010-11-02 07:09:39 UTC
Permalink
Post by Marc-Tell Volkmann
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Die letzte Version 1.3 (IMHO: PTF024) läuft sogar noch auf einem
Pentium II, solange der eine passende ISA SCSI Karte hat.

Allerdings habe ich noch keine Ethernet damit zum Laufen bekommen :-(

Christian
Michael Kraemer
2010-11-02 08:21:50 UTC
Permalink
Post by Christian J. Bauer
Post by Marc-Tell Volkmann
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Die letzte Version 1.3 (IMHO: PTF024) läuft sogar noch auf einem
Pentium II, solange der eine passende ISA SCSI Karte hat.
Allerdings habe ich noch keine Ethernet damit zum Laufen bekommen :-(
Christian
mW kommt AIX 1.x nur mit einer bestimmten Ethernet-Karte klar,
einer Ungermann (sp ?), für die man im Austausch idR eine
Niere hergeben muss. Aber es gibt ja noch Totenring :-)
So Sachen werden übrigens auch in
comp.sys.ibm.ps2.hardware
diskutiert. Da werden Sie geholfen ...
Christian J. Bauer
2010-11-02 13:58:39 UTC
Permalink
Post by Michael Kraemer
mW kommt AIX 1.x nur mit einer bestimmten Ethernet-Karte klar,
einer Ungermann (sp ?), für die man im Austausch idR eine
Niere hergeben muss. Aber es gibt ja noch Totenring :-)
So Sachen werden übrigens auch in
comp.sys.ibm.ps2.hardware
diskutiert. Da werden Sie geholfen ...
Tja, für PS/2 Kisten eine passende Kiste ist noch realistisch. Von
den Ungermann Bass Karten geht nur eine (ich hatte mal genau die
falsche). Eine WD Karte ist da eigentlich die erste Wahl. Eine Ethenet
Karte von IBM sollte es auch noch geben. Der 3COM support ist seit
PFT024 "broken".

ABER: ich hab leider noch keine gefunden die auf einer ISA Maschine
geht :-(

Christian
Michael Baeuerle
2010-11-02 14:12:12 UTC
Permalink
Post by Christian J. Bauer
Tja, für PS/2 Kisten eine passende Kiste ist noch realistisch. Von
den Ungermann Bass Karten geht nur eine (ich hatte mal genau die
falsche). Eine WD Karte ist da eigentlich die erste Wahl. Eine Ethenet
Karte von IBM sollte es auch noch geben. Der 3COM support ist seit
PFT024 "broken".
ABER: ich hab leider noch keine gefunden die auf einer ISA Maschine
geht :-(
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)


Micha
Michael Kraemer
2010-11-02 15:44:32 UTC
Permalink
Post by Michael Baeuerle
Post by Christian J. Bauer
Tja, für PS/2 Kisten eine passende Kiste ist noch realistisch. Von
den Ungermann Bass Karten geht nur eine (ich hatte mal genau die
falsche). Eine WD Karte ist da eigentlich die erste Wahl. Eine Ethenet
Karte von IBM sollte es auch noch geben. Der 3COM support ist seit
PFT024 "broken".
ABER: ich hab leider noch keine gefunden die auf einer ISA Maschine
geht :-(
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)
Fuer AIX wie wir es kennen und lieben, also Version>=3
ist das jetzt nicht soo schlimm.
Bei Version 1.x kommt man evtl mit Tokenring weiter.
Bleibt die Frage nach Version 2.x.
Muss doch nachher mal schauen was da beim RT PC hinten rauskommt.
Michael Baeuerle
2010-11-02 16:39:50 UTC
Permalink
Post by Michael Kraemer
Post by Michael Baeuerle
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)
Fuer AIX wie wir es kennen und lieben, also Version>=3
ist das jetzt nicht soo schlimm.
Bei Version 1.x kommt man evtl mit Tokenring weiter.
Irgendwas mit Tropic-Chip wird doch bestimmt funktionieren, gab es ja
als MCA und ISA. Ist mit 16MBit/s dann sogar schneller als damaliges
Ethernet.


Micha
Michael Kraemer
2010-11-03 07:36:27 UTC
Permalink
Post by Michael Baeuerle
Post by Michael Kraemer
Post by Michael Baeuerle
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)
Fuer AIX wie wir es kennen und lieben, also Version>=3
ist das jetzt nicht soo schlimm.
Bei Version 1.x kommt man evtl mit Tokenring weiter.
Irgendwas mit Tropic-Chip wird doch bestimmt funktionieren, gab es ja
als MCA und ISA. Ist mit 16MBit/s dann sogar schneller als damaliges
Ethernet.
Stimmt. Ich mochte den TR damals auch viel lieber als Eternit.
Nicht nur dass er (nachgemessen) deutlich schneller war,
er kollodierte sich bei hoher Last auch nicht zu Tode.
Hilfreich war hierbei natürlich, dass man auf dem TR in der IBM-Welt
(S/390 und RS6K) quasi unter sich war,
während der VAX- und PC-Pöbel sich auf dem Ethernet prügelte :-)
Vorteilhaft schien mir auch, dass der Ring nicht unterbrochen
wurde, wenn man einfach mal einen Rechner abstöpselte,
eine ziemlich nervige Eigenschaft beim alten BNC-Ethernet.
Aber zu früh gefreut: der 16/4-TR fiel komplett auf die Nase
wenn man eine Station mit der falschen Geschwindigkeit
einstöpselte. Der default bei unserem Ring war 16Mbit,
der Startup-default einer RS/6000 4Mbit, den Rest kann
sich jeder ausmalen ...
Michael Baeuerle
2010-11-03 08:51:57 UTC
Permalink
Post by Michael Kraemer
Post by Michael Baeuerle
Irgendwas mit Tropic-Chip wird doch bestimmt funktionieren, gab es ja
als MCA und ISA. Ist mit 16MBit/s dann sogar schneller als damaliges
Ethernet.
Stimmt. Ich mochte den TR damals auch viel lieber als Eternit.
Nicht nur dass er (nachgemessen) deutlich schneller war,
er kollodierte sich bei hoher Last auch nicht zu Tode.
Ja, fuer "shared medium" Netzwerke war das wirklich ein schoenes
Protokoll.
Post by Michael Kraemer
Hilfreich war hierbei natürlich, dass man auf dem TR in der IBM-Welt
(S/390 und RS6K) quasi unter sich war,
während der VAX- und PC-Pöbel sich auf dem Ethernet prügelte :-)
Vorteilhaft schien mir auch, dass der Ring nicht unterbrochen
wurde, wenn man einfach mal einen Rechner abstöpselte,
eine ziemlich nervige Eigenschaft beim alten BNC-Ethernet.
Und die TR-Lobekabel werden vor dem Insert getestet, d.h. der Ring wird
auch nicht unterbrochen wenn sie kaputt sind.
Post by Michael Kraemer
Aber zu früh gefreut: der 16/4-TR fiel komplett auf die Nase
wenn man eine Station mit der falschen Geschwindigkeit
einstöpselte. Der default bei unserem Ring war 16Mbit,
der Startup-default einer RS/6000 4Mbit, den Rest kann
sich jeder ausmalen ...
Tja, kein Licht ohne Schatten. Wobei manche 16/4-Karten durchaus
Autodetect unterstuetzen, das ist also kein prinzipielles TR-Problem.
Mit einer so konfigurierten Karte muss man dann nur sicherstellen, dass
auf dem Ring bereits ein AM vorhanden ist, ansonsten schlaegt der Insert
fehl. Karten mit Olympic-Chip unterstuetzen das, die mit Tropic-Chip
hatten ja meistens noch Jumper oder Switches, mit denen geht das wohl
eher nicht.


Micha
Clemens Schueller
2010-11-03 15:37:10 UTC
Permalink
Post by Michael Kraemer
Stimmt. Ich mochte den TR damals auch viel lieber als Eternit.
Nicht nur dass er (nachgemessen) deutlich schneller war,
er kollodierte sich bei hoher Last auch nicht zu Tode.
IMHO ist das ein haushoher Vorteil von TR gegenüber Ethernet. Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.


GreetinX, Clemens Schueller
Gerrit Heitsch
2010-11-03 17:13:32 UTC
Permalink
Post by Clemens Schueller
Post by Michael Kraemer
Stimmt. Ich mochte den TR damals auch viel lieber als Eternit.
Nicht nur dass er (nachgemessen) deutlich schneller war,
er kollodierte sich bei hoher Last auch nicht zu Tode.
IMHO ist das ein haushoher Vorteil von TR gegenüber Ethernet. Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Aus dem gleichen Grund warum VHS gegen Video2000 und Beta gewonnen hat.
Ethernet war 'gut genug' und billiger. Nebenbei auch noch einfacher zu
handhaben, selbst bei Yellow Cable, mit BNC und RG58 dann sowieso.

Gerrit
Hartmut Scholz
2010-11-04 15:07:36 UTC
Permalink
Post by Michael Kraemer
Stimmt. Ich mochte den TR damals auch viel lieber als Eternit.
[...]
Da hier in so hohen Tönen von TokenRing gesprochen wird: Bei mir lungern
seit langem mehrere TR-Karten rum, für die ich keine Verwendung habe. Hat
jemand Interesse?
Im Einzelnen: 2x PCI mit 85C9533, davon einmal mit WOL
3x mit Madge ..., alle mit WOL
1x Einschubkarte wohl für Drucker ("MLP-88-V1.1")
Und noch eine: "IBM 16/4 Token-Ring Low Profile PCI Management Adapter"
Zustand unbekannt, sehen aber ordentlich aus und wurden bei mir schonend
gelagert. Gegen Portoerstattung gehen sie weg. Oder ist das eher ein Fall
fürs Recycling?

MfG
HartmutS
Michael Baeuerle
2010-11-04 19:59:49 UTC
Permalink
Post by Hartmut Scholz
Da hier in so hohen Tönen von TokenRing gesprochen wird: Bei mir lungern
seit langem mehrere TR-Karten rum, für die ich keine Verwendung habe. Hat
jemand Interesse?
[...]
Gegen Portoerstattung gehen sie weg. Oder ist das eher ein Fall
fürs Recycling?
Ich prophezeihe mal eher letzteres. Weil das heute keiner mehr braucht
und in den Firmen kistenweise entsorgt wurde kann hier vmtl. die
Mehrheit der Leute mit 16/4-Karten um sich werfen ...

Wenn du dagegen auch MSAUs, Bridges oder sogar Switches haben solltest,
da werden sich bestimmt Interessenten finden. Selten ist auch 100MBit/s
TR-Equipment, da sind auch die Karten wertvoll. Ich habe hier mal nach
zwei 100MBit/s Olympics gefragt - und keine bekommen.


Micha
--
http://micha.freeshell.org/
Hartmut Scholz
2010-11-05 10:34:43 UTC
Permalink
Post by Michael Baeuerle
Post by Hartmut Scholz
Da hier in so hohen Tönen von TokenRing gesprochen wird: Bei mir lungern
seit langem mehrere TR-Karten rum, für die ich keine Verwendung habe. Hat
jemand Interesse?
[...]
Gegen Portoerstattung gehen sie weg. Oder ist das eher ein Fall
fürs Recycling?
Ich prophezeihe mal eher letzteres. Weil das heute keiner mehr braucht
und in den Firmen kistenweise entsorgt wurde kann hier vmtl. die
Mehrheit der Leute mit 16/4-Karten um sich werfen ...
So was habe ich mir schon gedacht. Ich muß eh aufräumen. Dann gehen sie halt
den Weg aller Dinge...
Nur die LowProfile Karte werde ich behalten. Ich habe nämlich kein
entsprechendes Blechlein, mit dem ich den Schlitz im Gehäuse schließen
könnte.
Post by Michael Baeuerle
Wenn du dagegen auch MSAUs, Bridges oder sogar Switches haben solltest,
da werden sich bestimmt Interessenten finden. Selten ist auch 100MBit/s
TR-Equipment, da sind auch die Karten wertvoll. Ich habe hier mal nach
zwei 100MBit/s Olympics gefragt - und keine bekommen.
Weiteres Gerät aus diesem Kontext habe ich nicht. Aber ich halte die Augen
offen. Die Karten stammen aus ausgemusterten Firmenrechnern, die statt auf
dem Schrott erst mal bei mir gelandet sind. Die Karten sehen tlw. aus wie
neu. Es ist eine Schande.

MfG
HartmutS
Michael Kraemer
2010-11-07 10:07:19 UTC
Permalink
Post by Hartmut Scholz
Post by Michael Baeuerle
Post by Hartmut Scholz
Da hier in so hohen Tönen von TokenRing gesprochen wird: Bei mir lungern
seit langem mehrere TR-Karten rum, für die ich keine Verwendung habe. Hat
jemand Interesse?
[...]
Gegen Portoerstattung gehen sie weg. Oder ist das eher ein Fall
fürs Recycling?
Ich prophezeihe mal eher letzteres. Weil das heute keiner mehr braucht
und in den Firmen kistenweise entsorgt wurde kann hier vmtl. die
Mehrheit der Leute mit 16/4-Karten um sich werfen ...
So was habe ich mir schon gedacht. Ich muß eh aufräumen. Dann gehen sie halt
den Weg aller Dinge...
Nur die LowProfile Karte werde ich behalten. Ich habe nämlich kein
entsprechendes Blechlein, mit dem ich den Schlitz im Gehäuse schließen
könnte.
Post by Michael Baeuerle
Wenn du dagegen auch MSAUs, Bridges oder sogar Switches haben solltest,
da werden sich bestimmt Interessenten finden. Selten ist auch 100MBit/s
TR-Equipment, da sind auch die Karten wertvoll. Ich habe hier mal nach
zwei 100MBit/s Olympics gefragt - und keine bekommen.
Weiteres Gerät aus diesem Kontext habe ich nicht. Aber ich halte die Augen
offen. Die Karten stammen aus ausgemusterten Firmenrechnern, die statt auf
dem Schrott erst mal bei mir gelandet sind. Die Karten sehen tlw. aus wie
neu. Es ist eine Schande.
hmm,
wenn man sich die Armut an
funkenden Ethernet-Karten für PS/2 System so anschaut:
Man könnte doch für diese ein separates TR-Netz bauen,
incl einer Art Gateway ins "normale" Ethernet, oder?
Auf Arbeit war das damals die unvermeidliche Cisco-Büchse.
Aber evtl könnte diese Funktion auch eine "multi-homed"
RS/6000 übernehmen?
Nur mal so ins Unreine gedacht.
Goetz Hoffart
2010-11-07 10:16:43 UTC
Permalink
Post by Michael Kraemer
Man könnte doch für diese ein separates TR-Netz bauen,
incl einer Art Gateway ins "normale" Ethernet, oder?
Klar. Läuft ja bei verschiedenen Leuten hier genauso.
Post by Michael Kraemer
Auf Arbeit war das damals die unvermeidliche Cisco-Büchse.
Die gibt's für ein Apple & 1 Ei.

Manche 25xx tun, oder bspw. 3620, 3640 oder 3660.
Post by Michael Kraemer
Aber evtl könnte diese Funktion auch eine "multi-homed"
RS/6000 übernehmen?
Klar - solange dein OS routen kann. Wobei der Cisco den Vorteil hat,
dass auch non-IP geroutet werden kann.

Grüße
Götz
--
http://www.knubbelmac.de/
Philipp Thomas
2010-11-05 02:18:52 UTC
Permalink
On Wed, 03 Nov 2010 16:37:10 +0100, Clemens Schueller
Post by Clemens Schueller
IMHO ist das ein haushoher Vorteil von TR gegenüber Ethernet. Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Nicht ganz :) Es hat auch noch 100VG AnyLAN gegeben
http://en.wikipedia.org/wiki/100BaseVG aber abweichend von der im
Wikipediaartikel genannten Vorzüge meine ich mich zu entsinnen, dass
zumindest in einigen damaligen englischen Fachzeitschriften (für eine
von denen bekam ich überraschenderweise ein Freiabo) der
Verwaltungsaufwand bei hoher Geschwindigkeit dann doch beträchtlich
bremste.

Aber wenige verfügbare Modelle und sehr hohe Preise haben dann recht
rasch dafür gesorgt, das 100VG Karten vom Markt genommen wurden.

Und spätestens mit dem Aufkommen von erschwinglichen Switches war es
dann mit dem Geschwindigkeitsvorteil vorbei.

Aber sicherlich war auch der VHS-Effekt am Werke, sprich massenhafte
Verfügbarkeit mit daher niedrigereren Preisen.

Philipp
Michael Kraemer
2010-11-05 07:28:02 UTC
Permalink
Post by Philipp Thomas
Aber sicherlich war auch der VHS-Effekt am Werke, sprich massenhafte
Verfügbarkeit mit daher niedrigereren Preisen.
Waren's bei VHS nicht auch schlicht die längeren Bänder?
Christian Corti
2010-11-05 09:48:07 UTC
Permalink
Post by Michael Kraemer
Waren's bei VHS nicht auch schlicht die längeren Bänder?
Nö, bei Video2000 konnte man zudem die Kassette wenden, also z.B.
2x 240min. aufzeichnen. Bei LP waren's dann 960min.!
Stereo gab's auch bei Video2000, und vom streifenfreien Standbild und
Bildvor-/-rücklauf (ohne aufwendige Elektronik) haben die anderen
Systeme auch nichts gehört. Problem war halt die geringe
Durchsetzungskraft von Philips/Grundig, das außerhalb Deutschlands zu
verbreiten.

Christian
Wolfgang Wegner
2010-11-05 10:38:25 UTC
Permalink
Waren's bei VHS nicht auch schlicht die l?ngeren B?nder?
N?, bei Video2000 konnte man zudem die Kassette wenden, also z.B.
2x 240min. aufzeichnen. Bei LP waren's dann 960min.!
Stereo gab's auch bei Video2000, und vom streifenfreien Standbild und
Bildvor-/-r?cklauf (ohne aufwendige Elektronik) haben die anderen
Vorsicht - DTF erfordert deutlich hoeheren Aufwand in der Mechanik
(Piezo-Aktuator in der Kopftrommel, (Schleif-)Kontakte zur Uebertragung
der Aktuator-Signale), und auch die Aktuatorsignale wollen erstmal
erzeugt werden.
Natuerlich ist es besser, aber mit "wenig Aufwand" hat es erstmal
nichts zu tun...

Gruss,
Wolfgang
Philipp Thomas
2010-11-05 22:46:58 UTC
Permalink
On Fri, 5 Nov 2010 10:48:07 +0100, Christian Corti
Problem war halt die geringe Durchsetzungskraft von Philips/Grundig,
das außerhalb Deutschlands zu verbreiten.
Ja, vermutlich zum Teil das NIH Syndrom und evtl. ein
lizenzrechtliches Problem (ich weiß es nicht). Zumindest Betamax ist
AFAIR ja auch daran gescheitert, dass Sony keine Lizenzen vergeben
wollten.

Philipp
Roger Schwentker
2010-11-06 10:09:32 UTC
Permalink
Post by Christian Corti
Problem war halt die geringe
Durchsetzungskraft von Philips/Grundig, das außerhalb Deutschlands zu
verbreiten.
Es gibt eine Theorie, dass VHS sich durchgesetzt hat, weil es dafür die
meisten Pornos gab. Sex sells.

Gruß
Roger Schwentker
***@regioconnect.net
--
Ham wers geschafft: Sind wir solange mit dem Flieger in den Süden geflogen,
bis es warm genug wurde, daß wir hier bleiben können. [Hagen Rether, Liebe 2]
Michael Kraemer
2010-11-07 09:59:03 UTC
Permalink
Post by Roger Schwentker
Es gibt eine Theorie, dass VHS sich durchgesetzt hat, weil es dafür die
meisten Pornos gab. Sex sells.
Das würde doch eher für die höher auflösende Konkurrenz sprechen:
man möchte doch *alles* sehen und das möglichst lange ... :-)
Michael Kraemer
2010-11-07 09:56:25 UTC
Permalink
Post by Philipp Thomas
Nicht ganz :) Es hat auch noch 100VG AnyLAN gegeben
http://en.wikipedia.org/wiki/100BaseVG
"was originally proposed by Hewlett-Packard, ratified by the ISO in 1995
and was practically extinct by 1998"

In diesem Fall hat wohl das Zertifizieren länger gedauert
als das de facto Aussterben.
Wimre hat HP das bei uns mal im Zusammenhang mit den ersten Series 700
Rechnern angeboten. Ich glaube man hat schon damals, 1992/93, den
Kopf über diesen Sonderweg geschüttelt.
Aber HP war damals halt noch richtig "invent" :-)
Ralf Kiefer
2010-11-06 20:18:20 UTC
Permalink
Post by Clemens Schueller
Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Das hättest Du wg. ARCNET genauso fragen können. Die Kombination aus
billigen Kabeln (Vorteil damals vom Cheapernet/10Base2) und Token Bus
(TokenRing). ARCNET konnte daher problemlos in Echtzeitsystemen [1]
verwendet werden.

Gruß, Ralf

[1] definitionsgemäß: deterministisch.
Clemens Schueller
2010-11-07 13:47:44 UTC
Permalink
Post by Ralf Kiefer
Post by Clemens Schueller
Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Das hättest Du wg. ARCNET genauso fragen können. Die Kombination aus
billigen Kabeln (Vorteil damals vom Cheapernet/10Base2) und Token Bus
(TokenRing). ARCNET konnte daher problemlos in Echtzeitsystemen [1]
verwendet werden.
[1] definitionsgemäß: deterministisch.
Dann werfe ich mal TR over 802.11n in den Raum.


SCNR
Michael Baeuerle
2010-11-07 11:39:13 UTC
Permalink
Post by Ralf Kiefer
Post by Clemens Schueller
Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Das hättest Du wg. ARCNET genauso fragen können. Die Kombination aus
billigen Kabeln (Vorteil damals vom Cheapernet/10Base2) und Token Bus
(TokenRing). ARCNET konnte daher problemlos in Echtzeitsystemen [1]
verwendet werden.
Dafuer war es doch AFAIK urspruenglich gedacht. Und man konnte sich
sogar aussuchen ob man es als Stern oder Bus verkabeln wollte. Beides
ging sowohl mit Koax- als auch TP-Kabeln.

Die "richtig alten" Ethernet Karten waren ja auch noch ziemlich
kompliziert, teils 3/4-lange Bretter mit unzaehligen Chips drauf ...
wirklich billig wurden die wohl erst spaeter. ARCNET Karten bestanden
schon damals quasi nur noch aus einem Chip, muessten also eigentlich
sogar billiger gewesen sein (aber halt auch langsamer). Vielleicht war
es halt doch nicht der Preis, sondern die Politik die Ethernet zum
Durchbruch verhalf. Da war immerhin Intel mit im Boot, und die haben ja
seither schon oefter demonstriert wie das geht.


Micha
--
http://micha.freeshell.org/
Clemens Schueller
2010-11-09 21:16:21 UTC
Permalink
Post by Michael Baeuerle
Post by Ralf Kiefer
Post by Clemens Schueller
Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Das hättest Du wg. ARCNET genauso fragen können. Die Kombination aus
billigen Kabeln (Vorteil damals vom Cheapernet/10Base2) und Token Bus
(TokenRing). ARCNET konnte daher problemlos in Echtzeitsystemen [1]
verwendet werden.
Dafuer war es doch AFAIK urspruenglich gedacht. Und man konnte sich
sogar aussuchen ob man es als Stern oder Bus verkabeln wollte. Beides
ging sowohl mit Koax- als auch TP-Kabeln.
Die "richtig alten" Ethernet Karten waren ja auch noch ziemlich
kompliziert, teils 3/4-lange Bretter mit unzaehligen Chips drauf ...
wirklich billig wurden die wohl erst spaeter. ARCNET Karten bestanden
schon damals quasi nur noch aus einem Chip, muessten also eigentlich
sogar billiger gewesen sein (aber halt auch langsamer). Vielleicht war
es halt doch nicht der Preis, sondern die Politik die Ethernet zum
Durchbruch verhalf. Da war immerhin Intel mit im Boot, und die haben ja
seither schon oefter demonstriert wie das geht.
Irnkwo hab ich noch eine alte 3com (ISA) rumliegen. Die hat Koax, TP
und AUI.

Mangels passendem Rechner kann ich sie leider nicht testen.


GreetinX, Clemens Schueller
Ralf Kiefer
2010-11-09 22:12:17 UTC
Permalink
Post by Michael Baeuerle
Die "richtig alten" Ethernet Karten waren ja auch noch ziemlich
kompliziert, teils 3/4-lange Bretter mit unzaehligen Chips drauf ...
Nein, die ersten Karten (von 3Com und teils mit Apple-Etikett) waren in
voller Länge anfangs bestückt mit 8kB SRAM, 8kB EPROM, dem 40pol.
Controller und über einem Dutzend TTLs. Ok, die Hälfte davon war
NuBus-Interface. Später waren die Karten, speziell die für den LC-Slot,
ebenso auf 4 Chips reduziert, dann aber ohne AUI. Und Cheapernet
brauchte immer noch den DC-DC-Wandler.
Post by Michael Baeuerle
ARCNET Karten bestanden
schon damals quasi nur noch aus einem Chip, muessten also eigentlich
sogar billiger gewesen sein (aber halt auch langsamer).
Da war doch auch noch ein Hybrid im Spiel. Glaub ich.

Ein ausgelastetes ARCNET war mit seinen 2,5Mb/s schneller als ein
ausgelastetes 10Base2 oder 10Base5, da die dann wg. der Kollisionen
zusammenbrachen, wo ARCNET einfach nur die volle Bandbreite nutzen
konnte, und dabei immer noch deterministisch blieb.
Post by Michael Baeuerle
Vielleicht war
es halt doch nicht der Preis, sondern die Politik die Ethernet zum
Durchbruch verhalf.
Ethernet hatte aufgrund seines Alters Ende der 1980er Jahre, der
Blütezeit vom ARCNET, bereits eine zu große Verbreitung gefunden. Viele
Hochschulen waren bereits von wasserschlauchdicken gelben Kabeln
durchzogen.
Post by Michael Baeuerle
Da war immerhin Intel mit im Boot, und die haben ja
seither schon oefter demonstriert wie das geht.
Intel hatte damals keine große Bedeutung. Die haben zu jener Zeit nur
ein paar unbrauchbare, zudem "segmentierte" Prozessoren gebaut.

Gruß, Ralf
Michael Baeuerle
2010-11-10 10:11:12 UTC
Permalink
Post by Ralf Kiefer
Post by Michael Baeuerle
Die "richtig alten" Ethernet Karten waren ja auch noch ziemlich
kompliziert, teils 3/4-lange Bretter mit unzaehligen Chips drauf ...
Nein, die ersten Karten (von 3Com und teils mit Apple-Etikett) waren in
voller Länge anfangs bestückt mit 8kB SRAM, 8kB EPROM, dem 40pol.
Controller und über einem Dutzend TTLs. Ok, die Hälfte davon war
NuBus-Interface.
Ich kenne da nur PC-Karten, Mac hatte ich nie einen.

Richtig gross waren die alten TokenRing Karten, da habe ich z.B. eine
Proteon P1390 mit voller Laenge.
Post by Ralf Kiefer
Später waren die Karten, speziell die für den LC-Slot,
ebenso auf 4 Chips reduziert, dann aber ohne AUI. Und Cheapernet
brauchte immer noch den DC-DC-Wandler.
Am Anfang hatten sie ja nur AUI.
Post by Ralf Kiefer
Post by Michael Baeuerle
ARCNET Karten bestanden
schon damals quasi nur noch aus einem Chip, muessten also eigentlich
sogar billiger gewesen sein (aber halt auch langsamer).
Da war doch auch noch ein Hybrid im Spiel. Glaub ich.
Richtig, das ist aber "nur" ein Tranceiver. Vergleichbar dem 10base5 MAU
bei Ethernet, nur eben onboard.
Post by Ralf Kiefer
Post by Michael Baeuerle
[...]
Da war immerhin Intel mit im Boot, und die haben ja
seither schon oefter demonstriert wie das geht.
Intel hatte damals keine große Bedeutung. Die haben zu jener Zeit nur
ein paar unbrauchbare, zudem "segmentierte" Prozessoren gebaut.
Auch wieder richtig. Ohne IBM waere da wohl eher nichts draus geworden.


Micha
Marc Haber
2011-01-07 17:06:46 UTC
Permalink
Post by Michael Baeuerle
Dafuer war es doch AFAIK urspruenglich gedacht. Und man konnte sich
sogar aussuchen ob man es als Stern oder Bus verkabeln wollte. Beides
ging sowohl mit Koax- als auch TP-Kabeln.
Diese Entscheidung musste man allerdings beim hardwarekauf bereits
treffen.
Post by Michael Baeuerle
Die "richtig alten" Ethernet Karten waren ja auch noch ziemlich
kompliziert, teils 3/4-lange Bretter mit unzaehligen Chips drauf ...
wirklich billig wurden die wohl erst spaeter. ARCNET Karten bestanden
schon damals quasi nur noch aus einem Chip, muessten also eigentlich
sogar billiger gewesen sein (aber halt auch langsamer).
ARCNET war billiger; deswegen war das erste Netz, das ich je gebaut
habe, auch ein ARCNET.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Hans-Juergen Lukaschik
2011-01-27 09:05:36 UTC
Permalink
Hallo Marc,
Post by Marc Haber
ARCNET war billiger; deswegen war das erste Netz, das ich je gebaut
habe, auch ein ARCNET.
So habe ich auch mal angefangen. Danach kam dann NE 2000.

MfG Hans-JÃŒrgen
--
http://www.fischereiverein-rietberg.net * http://kuerzer.de/brde
http://kuerzer.de/gullibrde * http://kuerzer.de/gade
http://kuerzer.de/cyber * http://kuerzer.de/nrde
Dennis Grevenstein
2010-11-09 20:57:06 UTC
Permalink
Post by Clemens Schueller
IMHO ist das ein haushoher Vorteil von TR gegenüber Ethernet. Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Um auch mal was zu dem Thema zu schreiben, mache ich es einfach
an dieser Stelle.
Ich denke Ethernet war frueh verfuegbar (entwickelt in den 70er,
breiter verfuegbar ab Anfang der 80er) und die grossen Hersteller
wie Intel oder DEC waren mit dabei. Ethernet gab es fuer praktisch
jede Maschine und ab Mitte der 80er war es bei den meisten
professionellen Kisten immer mit dabei. Im Unix-Bereich war etwas
anderes als Ethernet schon untypisch. IBM oder Apollo fallen mir
ein... Wobei IBM ja erst 1989 mit der RS/6000 richtig die Unix-Fuesse
auf den Boden bekommen hat.
Im PC-Bereich faellt mir sowas wie Novell Netware ein und auch da
denke ich fast nur an Ethernet.
Ich vermute bei Ethernet schlicht Erfolg durch market share,
wobei Verbreitung sogar noch ein konkretes Kaufargument fuer
eine Netzwerktechnik ist.

gruss,
Dennis
--
Don't suffer from insanity...
Enjoy every minute of it.
Clemens Schueller
2010-11-09 21:22:59 UTC
Permalink
Post by Dennis Grevenstein
Post by Clemens Schueller
IMHO ist das ein haushoher Vorteil von TR gegenüber Ethernet. Da frag
ich mich doch glatt, warum sicht TR nicht gegenüber Ethernet durchsetzen
konnte.
Um auch mal was zu dem Thema zu schreiben, mache ich es einfach
an dieser Stelle.
Ich denke Ethernet war frueh verfuegbar (entwickelt in den 70er,
Hmm - wann hat denn IBM Token Ring rausgebracht?
Post by Dennis Grevenstein
breiter verfuegbar ab Anfang der 80er) und die grossen Hersteller
wie Intel oder DEC waren mit dabei. Ethernet gab es fuer praktisch
AFAIK hat DEC sein eigenes Süppchen gekocht - oder täusche ich mich da?
Post by Dennis Grevenstein
jede Maschine und ab Mitte der 80er war es bei den meisten
professionellen Kisten immer mit dabei. Im Unix-Bereich war etwas
anderes als Ethernet schon untypisch. IBM oder Apollo fallen mir
ein... Wobei IBM ja erst 1989 mit der RS/6000 richtig die Unix-Fuesse
auf den Boden bekommen hat.
Im PC-Bereich faellt mir sowas wie Novell Netware ein und auch da
denke ich fast nur an Ethernet.
Novell Netware - gibts das überhaupt noch? Mir war nur eine Installation
bekannt. Und zwar in der Ex-Firma (ein Möbelhaus). Die haben die Küchen
für die Kunden auf einer OS/2 Kiste geplant und die Daten auf einem
Novell Server gespeichert. (LAN war übrigens über BNC realisiert).

Aber die Warenwirtschaft selbst ist sogar heute noch total retro:

Ein DEC Server mit OpenVMS und in den Filialen standen "dumme" VT 510er
Terminals. Wurden mittlerweile durch Thin Clients ersetzt, aber die WWS
ist immer noch dieselbe.

Die haben dann irnkeinen anderen Möbeltandler aufgekauft, der ein Top
WWS hatte - was war: Auch die haben den totalen Rückschritt auf die WWS
unter VMS machen müssen.
Post by Dennis Grevenstein
Ich vermute bei Ethernet schlicht Erfolg durch market share,
wobei Verbreitung sogar noch ein konkretes Kaufargument fuer
eine Netzwerktechnik ist.
Ist heute beim dämlichen EiPhone nix anders.



GreetinX, Clemens Schueller
Dennis Grevenstein
2010-11-09 21:34:41 UTC
Permalink
Post by Clemens Schueller
Hmm - wann hat denn IBM Token Ring rausgebracht?
Mitte der 80er?
Post by Clemens Schueller
Post by Dennis Grevenstein
breiter verfuegbar ab Anfang der 80er) und die grossen Hersteller
wie Intel oder DEC waren mit dabei. Ethernet gab es fuer praktisch
AFAIK hat DEC sein eigenes Süppchen gekocht - oder täusche ich mich da?
DEC hatte fuer kleine und normale Kisten schon Ethernet. Grosse
Kisten konnte man mit "CI" = "cluster interconnect" verbinden.
DEC hatte allerdings ein eigenes Protokoll namens DECnet. TCP/IP
kostete damals extra :-)
Post by Clemens Schueller
Novell Netware - gibts das überhaupt noch? Mir war nur eine Installation
bekannt. Und zwar in der Ex-Firma (ein Möbelhaus). Die haben die Küchen
für die Kunden auf einer OS/2 Kiste geplant und die Daten auf einem
Novell Server gespeichert. (LAN war übrigens über BNC realisiert).
Gibts wohl schon noch, aber ich denke da auch an die 80er
und an eine Zeit als es noch kein Windows NT gab.
Post by Clemens Schueller
Ein DEC Server mit OpenVMS und in den Filialen standen "dumme" VT 510er
Terminals. Wurden mittlerweile durch Thin Clients ersetzt, aber die WWS
ist immer noch dieselbe.
In vielen Moebelhaeusern ist das offenbar so. Hat IKEA nicht
eine Zeit lang ausrangierte VT Terminals als Dekoration benutzt?
Post by Clemens Schueller
Post by Dennis Grevenstein
Ich vermute bei Ethernet schlicht Erfolg durch market share,
wobei Verbreitung sogar noch ein konkretes Kaufargument fuer
eine Netzwerktechnik ist.
Ist heute beim dämlichen EiPhone nix anders.
Ich meinte das eigentlich anders. Ein Ding zu kaufen, weil der Rest
der Welt das auch gekauft hat und sich vermutlich nicht geirrt hat,
ist eine Sache. Bei Netzwerken kann es aber gerade interessant sein
etwas zu kaufen, was der Rest der Welt auch hat, eben weil ich dann
mein eigenes Netzwerk-Ding besser mit dem Rest der Welt verbinden
kann.

gruss,
Dennis
--
Don't suffer from insanity...
Enjoy every minute of it.
Clemens Schueller
2010-11-09 21:56:11 UTC
Permalink
Post by Dennis Grevenstein
Post by Clemens Schueller
Hmm - wann hat denn IBM Token Ring rausgebracht?
Mitte der 80er?
Also hat IBM auch ein eigenes Süppchen gekocht, ist aber in einem
Nischenmarkt gelandet? Ich kenn TR nur auf Banken - meine Hausbank hatte
bis vor kurzem noch TR und hing auf einer AS/400 drauf. Jetzt hams was
webbasiertes in Java. Aber die AS/400 dürfte es noch geben, weils
außerdem noch Lotus verwenden.
Post by Dennis Grevenstein
Post by Clemens Schueller
Post by Dennis Grevenstein
breiter verfuegbar ab Anfang der 80er) und die grossen Hersteller
wie Intel oder DEC waren mit dabei. Ethernet gab es fuer praktisch
AFAIK hat DEC sein eigenes Süppchen gekocht - oder täusche ich mich da?
DEC hatte fuer kleine und normale Kisten schon Ethernet. Grosse
Kisten konnte man mit "CI" = "cluster interconnect" verbinden.
DEC hatte allerdings ein eigenes Protokoll namens DECnet. TCP/IP
kostete damals extra :-)
Gabs da nicht noch was - nannte sich AFAIK Pathworks (oder so ähnlich)?
Post by Dennis Grevenstein
Post by Clemens Schueller
Novell Netware - gibts das überhaupt noch? Mir war nur eine Installation
bekannt. Und zwar in der Ex-Firma (ein Möbelhaus). Die haben die Küchen
für die Kunden auf einer OS/2 Kiste geplant und die Daten auf einem
Novell Server gespeichert. (LAN war übrigens über BNC realisiert).
Gibts wohl schon noch, aber ich denke da auch an die 80er
und an eine Zeit als es noch kein Windows NT gab.
Ach ja, im Büro hams dann Office PCs mit NT4 bekommen (Win2000 gabs zur
der Zeit aber schon). Aufs WWS sinds dann mit SmarTerm Essentials drauf.
Post by Dennis Grevenstein
Post by Clemens Schueller
Ein DEC Server mit OpenVMS und in den Filialen standen "dumme" VT 510er
Terminals. Wurden mittlerweile durch Thin Clients ersetzt, aber die WWS
ist immer noch dieselbe.
In vielen Moebelhaeusern ist das offenbar so. Hat IKEA nicht
eine Zeit lang ausrangierte VT Terminals als Dekoration benutzt?
Keine Ahnung, wie es in DE ist - aber hier in Graz ist mir das nicht
aufgefallen.
Post by Dennis Grevenstein
Post by Clemens Schueller
Post by Dennis Grevenstein
Ich vermute bei Ethernet schlicht Erfolg durch market share,
wobei Verbreitung sogar noch ein konkretes Kaufargument fuer
eine Netzwerktechnik ist.
Ist heute beim dämlichen EiPhone nix anders.
Ich meinte das eigentlich anders. Ein Ding zu kaufen, weil der Rest
der Welt das auch gekauft hat und sich vermutlich nicht geirrt hat,
ist eine Sache. Bei Netzwerken kann es aber gerade interessant sein
etwas zu kaufen, was der Rest der Welt auch hat, eben weil ich dann
mein eigenes Netzwerk-Ding besser mit dem Rest der Welt verbinden
kann.
Irnkwo im Net gabs mal eine schöne Grafik mit den Netzprotokollen. Hast
Du zufällig den Link zur Hand?



GreetinX, Clemens Schueller
Dennis Grevenstein
2010-11-09 22:09:35 UTC
Permalink
Post by Clemens Schueller
Also hat IBM auch ein eigenes Süppchen gekocht, ist aber in einem
Nischenmarkt gelandet? Ich kenn TR nur auf Banken - meine Hausbank hatte
bis vor kurzem noch TR und hing auf einer AS/400 drauf. Jetzt hams was
webbasiertes in Java. Aber die AS/400 dürfte es noch geben, weils
außerdem noch Lotus verwenden.
Die Welt der IBM war schon recht gross. Nennt man das einen Nischenmarkt?
keine Ahnung.
Post by Clemens Schueller
Gabs da nicht noch was - nannte sich AFAIK Pathworks (oder so ähnlich)?
Pathworks war eine Software, genutzt um PCs an groessere VMS oder
Unix Maschinen zu verbinden und so z.B. eine VAX zum fileserver fuer
PCs zu machen. Das hat damals wohl auch gut funktioniert.
Post by Clemens Schueller
Post by Dennis Grevenstein
Ich meinte das eigentlich anders. Ein Ding zu kaufen, weil der Rest
der Welt das auch gekauft hat und sich vermutlich nicht geirrt hat,
ist eine Sache. Bei Netzwerken kann es aber gerade interessant sein
etwas zu kaufen, was der Rest der Welt auch hat, eben weil ich dann
mein eigenes Netzwerk-Ding besser mit dem Rest der Welt verbinden
kann.
Irnkwo im Net gabs mal eine schöne Grafik mit den Netzprotokollen. Hast
Du zufällig den Link zur Hand?
Meinst Du jetzt sowas wie ein OSI Schichtenmodell?

gruss,
Dennis
--
Don't suffer from insanity...
Enjoy every minute of it.
Michael Kraemer
2010-11-09 22:38:45 UTC
Permalink
Post by Dennis Grevenstein
In vielen Moebelhaeusern ist das offenbar so. Hat IKEA nicht
eine Zeit lang ausrangierte VT Terminals als Dekoration benutzt?
Nicht nur IKEA. Vor ein paar Jahren war ich mal in einem
dieser IKEA-clones (Sommerlad? egal).
Brauchbare Möbel hatten sie zwar keine,
da ich aber grade auf der Suche nach einem VTxxx bzw
einer LK-tastatur war, fragte ich eine der dienstbaren
Geister ob ich die "Deko" mitnehmen könnte wenn sie
nicht mehr gebraucht würde. Etwas indigniert gab
sie mir zu verstehen, dass das nicht ginge weil
es Teil der Haus-IT sei ... :-)
Ignatios Souvatzis
2010-11-27 12:44:11 UTC
Permalink
Post by Michael Kraemer
Vorteilhaft schien mir auch, dass der Ring nicht unterbrochen
wurde, wenn man einfach mal einen Rechner abstöpselte,
eine ziemlich nervige Eigenschaft beim alten BNC-Ethernet.
Dann hast du etwas falsch gemacht.

-is
--
seal your e-mail: http://www.gnupg.org/
Michael Kraemer
2010-11-27 13:40:51 UTC
Permalink
Post by Ignatios Souvatzis
Post by Michael Kraemer
Vorteilhaft schien mir auch, dass der Ring nicht unterbrochen
wurde, wenn man einfach mal einen Rechner abstöpselte,
eine ziemlich nervige Eigenschaft beim alten BNC-Ethernet.
Dann hast du etwas falsch gemacht.
Und was bitte kann man da "richtig" machen?
Unterbrochen ist nun mal unterbrochen.
Goetz Hoffart
2010-11-27 15:24:24 UTC
Permalink
Post by Michael Kraemer
Und was bitte kann man da "richtig" machen?
Unterbrochen ist nun mal unterbrochen.
Wenn man ein T-Stück am Rechner hat, dann wird doch nichts unterbrochen,
wenn man das Längsstück vom Rechner wegnimmt?

Grüße
Götz
--
http://www.knubbelmac.de/
Michael Kraemer
2010-11-27 16:59:55 UTC
Permalink
Post by Goetz Hoffart
Post by Michael Kraemer
Und was bitte kann man da "richtig" machen?
Unterbrochen ist nun mal unterbrochen.
Wenn man ein T-Stück am Rechner hat, dann wird doch nichts unterbrochen,
wenn man das Längsstück vom Rechner wegnimmt?
und was ist wenn man noch *kein* T-Stück am Rechner hat,
zB weil er neu ist? Die Ethernet-Verkabelung auf Arbeit
sah (bzw sieht zT immer noch) so aus, dass ein oder mehrere
BNC-Stränge gut verpackt durch dutzende von Büros liefen.
Pro Zimmer ein paar Buchsen, durch kurze (ca 15cm) Kabelschlaufen
verbunden. Diese musste man auftrennen wenn ein Rechner dran
kam, bzw wieder restaurieren wenn er mal verschoben wurde
(kam damals öfter vor).
Goetz Hoffart
2010-11-27 18:55:52 UTC
Permalink
Post by Michael Kraemer
und was ist wenn man noch *kein* T-Stück am Rechner hat,
Dann verkabelt man außerhalb der Specs. Denn Kabel direkt auf die
BNC-Buchse aufstecken heißt, den Bus ohne Terminierungswiderstand
abzuschließen - und das soll so nicht sein.
Post by Michael Kraemer
zB weil er neu ist?
Verstehe ich nicht. T-Stücke hat man doch rumliegen oder kauft die, so
wie man auch Kabel kauft.

Grüße
Götz
--
http://www.knubbelmac.de/
Dennis Grevenstein
2010-11-28 02:03:30 UTC
Permalink
Post by Goetz Hoffart
Verstehe ich nicht. T-Stücke hat man doch rumliegen oder kauft die, so
wie man auch Kabel kauft.
Er meint wohl das Einfuegen oder Entfernen eines Rechners am
Ethernet. Dazu muss man irgendwo in der Mitte was auftrennen
und dann wieder ordnungsgemaess mit einem T-Stueck verbinden.
Wenn Du jetzt software hast, die sehr empfindlich auf Fehler
im Netz reagiert (vieleicht sowas wie einen VAXcluster), dann
spielen Praktikanten, die an PCs schrauben, nicht nur mit
Kabeln, sondern auch mit der geistigen Gesundheit der Admins.
Und dann gibt es noch die Leute, die einfach ueber Kabel fallen.
Das gute alte yellow cable hatte wenigstens noch den Vorteil,
dass es gross und gelb war und man es nicht in der Mitte
durchhauen konnte.

gruss,
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
Goetz Hoffart
2010-11-28 09:32:33 UTC
Permalink
Post by Dennis Grevenstein
Er meint wohl das Einfuegen oder Entfernen eines Rechners am
Ethernet. Dazu muss man irgendwo in der Mitte was auftrennen
und dann wieder ordnungsgemaess mit einem T-Stueck verbinden.
Hm. Ich hatte damals an den Stellen, wo ein Rechner angeschlossen werden
könnte, ein T-Stück eingebaut, auch wenn nix drankam. Ärger gab es mit
der Vorgehensweise keinen mir bekannten.

Grüße
Götz
--
http://www.knubbelmac.de/
Ulrich F. Heidenreich
2010-11-28 10:59:50 UTC
Permalink
Post by Goetz Hoffart
Post by Dennis Grevenstein
Er meint wohl das Einfuegen oder Entfernen eines Rechners am
Ethernet. Dazu muss man irgendwo in der Mitte was auftrennen
und dann wieder ordnungsgemaess mit einem T-Stueck verbinden.
Hm. Ich hatte damals an den Stellen, wo ein Rechner angeschlossen werden
könnte, ein T-Stück eingebaut, auch wenn nix drankam. Ärger gab es mit
der Vorgehensweise keinen mir bekannten.
Glücksache. Eigentlich gehört an solche Stellen eine EAD-Dose.

CU!
Ulrich
--
In 0 Monat und 29 Tagen ist Weihnachten
DN0FL L7KDC 25FP5 CKU1F OFDP7 KSGC5 50JC9 Y3SWV GYEUE
Stellt euch vor, es ist Sonntag und keiner geht hin!
Goetz Hoffart
2010-11-28 12:38:17 UTC
Permalink
Post by Ulrich F. Heidenreich
Post by Goetz Hoffart
Hm. Ich hatte damals an den Stellen, wo ein Rechner angeschlossen werden
könnte, ein T-Stück eingebaut, auch wenn nix drankam. Ärger gab es mit
der Vorgehensweise keinen mir bekannten.
Glücksache. Eigentlich gehört an solche Stellen eine EAD-Dose.
Vielleicht auch eine Frage der Größe des Netzes. BNC hatte ich nie mit
mehr als einem Dutzend Rechnern im Betrieb.

Grüße
Götz
--
http://www.knubbelmac.de/
Ulrich F. Heidenreich
2010-11-28 13:32:57 UTC
Permalink
Post by Goetz Hoffart
Post by Ulrich F. Heidenreich
Post by Goetz Hoffart
Hm. Ich hatte damals an den Stellen, wo ein Rechner angeschlossen werden
könnte, ein T-Stück eingebaut, auch wenn nix drankam. Ärger gab es mit
der Vorgehensweise keinen mir bekannten.
Glücksache. Eigentlich gehört an solche Stellen eine EAD-Dose.
Vielleicht auch eine Frage der Größe des Netzes. BNC hatte ich nie mit
mehr als einem Dutzend Rechnern im Betrieb.
Trotzdem würde ich kein T-Stück "offen" lassen, wenn kein Rechner
dranhängt. Thin-Ethernet kann sich gleichermassen mimosenhaft als auch
gutmütig wie SCSI benehmen, wenn irgendwo Elektronen aus der Leitung
fallen können.

Einen netten "Spaß" hatte ich damals auch mal mit hochohmigen
Abschlusswiderstanden. Die hatte $Kunde irgendwo billig gekauft.
Und dann sein oszillierendes Netzwerk reklamiert. Wer geht schon
sofort mit einem Ohmmeter an die Terminatoren, um festzustellen
daß die einige hundert statt 52 Ohm haben ... #-)

CU!
Ulrich
--
In 0 Monat und 29 Tagen ist Weihnachten
6CK67 ODM6P WDLIY YUXZ8 M00AI L8A01 X9LDS FU14E 05R49
Stellt euch vor, es ist Sonntag und keiner geht hin!
Jochen Pawletta
2010-11-28 17:05:41 UTC
Permalink
Hallo
Post by Ulrich F. Heidenreich
Einen netten "Spaß" hatte ich damals auch mal mit hochohmigen
Abschlusswiderstanden. Die hatte $Kunde irgendwo billig gekauft.
Und dann sein oszillierendes Netzwerk reklamiert. Wer geht schon
sofort mit einem Ohmmeter an die Terminatoren, um festzustellen
daß die einige hundert statt 52 Ohm haben ... #-)
Das war bei der Verkabelung für mich immer einer der ersten Schritte.
An einem der T-Stücke den Widerstand messen, muß ca. 25 Ohm sein.
Wenn nicht ... Terminatoren durchmessen.


mfg Jochen
--
ZX81 - C64 - Amiga - x86-Linux - iMac (OS X)
Klemens Krause
2010-11-29 08:46:44 UTC
Permalink
Post by Goetz Hoffart
Hm. Ich hatte damals an den Stellen, wo ein Rechner angeschlossen werden
könnte, ein T-Stück eingebaut, auch wenn nix drankam. Ärger gab es mit
der Vorgehensweise keinen mir bekannten.
Doch, ich kenne durchaus Aerger, der dadurch entstanden ist:
Wenn sich solch ein herrenloses T-Stueck in einer ebenfalls nicht benutzten
Steckdose an die Schutzleiterkontaktbuegel rangemacht hatte, oder mit einem
nicht lackierten Teil der Heizung kontaktierte.
Diese Fehler waren besonders nett, weil sie sporadisch kamen und gingen, je
nachdem wie der Benutzer oder die Putzmenschen in dem Kabelsalat unten hinter
dem Schreibtisch herumruehrten.

Klemens
Michael Kraemer
2010-11-28 10:07:57 UTC
Permalink
Post by Dennis Grevenstein
Post by Goetz Hoffart
Verstehe ich nicht. T-Stücke hat man doch rumliegen oder kauft die, so
wie man auch Kabel kauft.
Er meint wohl das Einfuegen oder Entfernen eines Rechners am
Ethernet. Dazu muss man irgendwo in der Mitte was auftrennen
und dann wieder ordnungsgemaess mit einem T-Stueck verbinden.
genauso ist es. Und je mehr Rechner man auf diese
Weise unterbringen will/muss, desto anfälliger wird das ganze.
Irgendwann haben die Netzleute dann drei parallele
Stränge verlegt, das hat das ganze dann etwas entkoppelt.
Aber spätestens wenn zB am "grünen" Strang mal nix ging
probierte man den "blauen" oder "gelben" aus und schon
ging die Stöpselei wieder los.
Post by Dennis Grevenstein
Wenn Du jetzt software hast, die sehr empfindlich auf Fehler
im Netz reagiert (vieleicht sowas wie einen VAXcluster),
Exakt. Die VMS-Hohepriester waren diejenigen, die permanent
als Netz-Hilfssheriffs unterwegs waren, sie wussten wohl
warum. Im Ggs zu dem, was man immer so liest, habe ich
VMScluster als höchst fragile Gebilde erfahren, vmtl
aus ebendiesem Grund. PCs, X-terms, Unix waren da bei weitem
nicht so anfällig.
Post by Dennis Grevenstein
dann
spielen Praktikanten, die an PCs schrauben, nicht nur mit
Kabeln, sondern auch mit der geistigen Gesundheit der Admins.
genau. Das pralle Leben eben.
Post by Dennis Grevenstein
Und dann gibt es noch die Leute, die einfach ueber Kabel fallen.
Das gute alte yellow cable hatte wenigstens noch den Vorteil,
dass es gross und gelb war und man es nicht in der Mitte
durchhauen konnte.
Dennis Grevenstein
2010-11-28 16:33:29 UTC
Permalink
Post by Michael Kraemer
genauso ist es. Und je mehr Rechner man auf diese
Weise unterbringen will/muss, desto anfälliger wird das ganze.
Irgendwann haben die Netzleute dann drei parallele
Stränge verlegt, das hat das ganze dann etwas entkoppelt.
Ich habe BNC Ethernet immer auch als "cheapernet" empfunden.
Billig und brauchbar, solange man alles im Griff hat.
Aber schon der Horror, wenn irgendein Witzbold den Abschluss-
widerstand losdreht und die bits aus der Leitung fallen.
TP Verkabelung war zwar teurer, weil man einen hub oder
switch brauchte, zusaetzlich zu den Kabeln, aber sehr viel
einfacher zu handhaben.
Post by Michael Kraemer
Exakt. Die VMS-Hohepriester waren diejenigen, die permanent
als Netz-Hilfssheriffs unterwegs waren, sie wussten wohl
warum. Im Ggs zu dem, was man immer so liest, habe ich
VMScluster als höchst fragile Gebilde erfahren, vmtl
aus ebendiesem Grund. PCs, X-terms, Unix waren da bei weitem
nicht so anfällig.
VMS ist halt ein Betriebssystem, das sich sehr auf die
hardware verlaesst und VMScluster verlassen sich absolut
auf eine sichere Verbindung zwischen den einzelnen Knoten.
Wenn eine Maschine vom Netz getrennt wird, dann bringt
sie nur noch "quorum lost, blocking activity". Wenn ein
Cluster sogar noch in Teile zerfaellt, dann ist alles
aus. Wenn sich solche zerteilten cluster wieder sehen,
dann stuerzt alles ab. DEC hat ewigen Mengen Dokumentation
rausgebracht, wo erklaert wird, wie man VMScluster aufbauen
und konfigurieren muss, um Probleme zu vermeiden. Meistens
hat das keiner richtig gelesen und es wurde einfach die
default Konfiguration zusammengestoepselt. Das funktioniert
in den meisten Faellen ja auch ganz gut.

gruss,
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
Michael Kraemer
2010-11-28 20:49:50 UTC
Permalink
Post by Dennis Grevenstein
Ich habe BNC Ethernet immer auch als "cheapernet" empfunden.
Billig und brauchbar, solange man alles im Griff hat.
Aber schon der Horror, wenn irgendein Witzbold den Abschluss-
widerstand losdreht und die bits aus der Leitung fallen.
TP Verkabelung war zwar teurer, weil man einen hub oder
switch brauchte, zusaetzlich zu den Kabeln, aber sehr viel
einfacher zu handhaben.
TP kam dann später, natürlich, aber so um 1990+x war
BNC Ethernet eben Standard, und der hält sich zäh.
Erst vor ein paar Monaten haben wir eine der letzten
BNC Strecken auf TP umgestellt, und das auch nur, weil
eine ebenso alte DECbridge in Rente sollte.
Post by Dennis Grevenstein
Post by Michael Kraemer
Exakt. Die VMS-Hohepriester waren diejenigen, die permanent
als Netz-Hilfssheriffs unterwegs waren, sie wussten wohl
warum. Im Ggs zu dem, was man immer so liest, habe ich
VMScluster als höchst fragile Gebilde erfahren, vmtl
aus ebendiesem Grund. PCs, X-terms, Unix waren da bei weitem
nicht so anfällig.
VMS ist halt ein Betriebssystem, das sich sehr auf die
hardware verlaesst und VMScluster verlassen sich absolut
auf eine sichere Verbindung zwischen den einzelnen Knoten.
Wenn eine Maschine vom Netz getrennt wird, dann bringt
sie nur noch "quorum lost, blocking activity". Wenn ein
Cluster sogar noch in Teile zerfaellt, dann ist alles
aus. Wenn sich solche zerteilten cluster wieder sehen,
dann stuerzt alles ab. DEC hat ewigen Mengen Dokumentation
rausgebracht, wo erklaert wird, wie man VMScluster aufbauen
und konfigurieren muss, um Probleme zu vermeiden. Meistens
hat das keiner richtig gelesen und es wurde einfach die
default Konfiguration zusammengestoepselt. Das funktioniert
in den meisten Faellen ja auch ganz gut.
Nun ich weiss nicht wie intensiv unsere VMS Gurus damals
das gelesen haben, aber so wie die damals drauf waren, hätten
die eher eine unbezahlte Nachtschicht eingelegt oder sich
die Zunge abgebissen, als auch nur die Möglichkeit zuzugeben
dass ihr heiliger Cluster evtl schlechter verfügbar wäre
als zB die Unix oder PC-Welt.
Von daher glaube ich schon, dass sie in der gegebenen Situation
das richtige getan haben.
Dennis Grevenstein
2010-11-28 23:03:38 UTC
Permalink
Post by Michael Kraemer
Nun ich weiss nicht wie intensiv unsere VMS Gurus damals
das gelesen haben, aber so wie die damals drauf waren, hätten
die eher eine unbezahlte Nachtschicht eingelegt oder sich
die Zunge abgebissen, als auch nur die Möglichkeit zuzugeben
dass ihr heiliger Cluster evtl schlechter verfügbar wäre
als zB die Unix oder PC-Welt.
VMS ist auch schoen stabil und zuverlaessig, aber nicht
so fehlertolerant im taeglichen Betrieb. Wenn man eine Unix
Maschine vom Netz trennt, dann gibt es vieleicht einen timeout
beim NFS, aber der Rest der Maschine laeuft weiter. Ein
verclustertes VMS bleibt dann einfach stehen. Das kann
richtig und wichtig sein, um sicherzustellen, dass benoetigte
Resourcen aus dem Netz vorhanden sind und es nicht zu
Datenverlust kommt. In vielen Faellen ist eine solche
Philosophie aber einfach nervig. VMS bietet tolle Moeglich-
keiten fuer gute Zuverlaessigkeit. Moeglich ist z.B. ein
rolling upgrade eines ganzen clusters, also das kontrolliert
einzelne Maschine runtergefahren, upgegraded und dann wieder
neu in den cluster gebootet werden, ohne das die Funktionalitaet,
die der ganze cluster bietet, verloren geht. Notwendig ist
dafuer natuerlich, dass die entsprechenden Resourcen vorher
schon redundant vorhanden sind und dass die Maschinen des
Clusters untereinander zuverlaessig verbunden sind.
DEC hat solche Konfigurationen aber nicht unbedingt mit
Ethernet gebaut, sondern mit CI oder DSSI. Schon cluster
ueber DSSI kann sehr cool sein, wenn zwei Maschinen
transparent und gleichzeitig auf ein und dieselbe physikalische
Platte zugreifen koennen.

gruss,
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
Michael Kraemer
2010-11-29 08:59:07 UTC
Permalink
Post by Dennis Grevenstein
VMS ist auch schoen stabil und zuverlaessig, aber nicht
so fehlertolerant im taeglichen Betrieb. Wenn man eine Unix
Maschine vom Netz trennt, dann gibt es vieleicht einen timeout
beim NFS, aber der Rest der Maschine laeuft weiter.
Meist hängt die Kiste einfach, und läuft weiter wenn
das Netz bzw der Service wieder da ist.
Das nervt zwar auch, ist aber lange nicht so
nervig wie ein Totalabsturz.
Post by Dennis Grevenstein
Ein
verclustertes VMS bleibt dann einfach stehen.
Wenn es das nur gemacht hätte.
Leider ist es öfter, als einem lieb war, komplett
abgestürzt. Ich bin auch nicht sicher, ob das
nur an "trivialen" Stöpseleien lag,
immerhin durfte man das Ethernet ja 20 oder 30s
"offen" lassen. Vielleicht kam das Clustern
auch einfach nicht mit maroden Paketen klar.
Post by Dennis Grevenstein
Das kann
richtig und wichtig sein, um sicherzustellen, dass benoetigte
Resourcen aus dem Netz vorhanden sind und es nicht zu
Datenverlust kommt. In vielen Faellen ist eine solche
Philosophie aber einfach nervig. VMS bietet tolle Moeglich-
keiten fuer gute Zuverlaessigkeit. Moeglich ist z.B. ein
rolling upgrade eines ganzen clusters, also das kontrolliert
einzelne Maschine runtergefahren, upgegraded und dann wieder
neu in den cluster gebootet werden, ohne das die Funktionalitaet,
die der ganze cluster bietet, verloren geht. Notwendig ist
dafuer natuerlich, dass die entsprechenden Resourcen vorher
schon redundant vorhanden sind und dass die Maschinen des
Clusters untereinander zuverlaessig verbunden sind.
DEC hat solche Konfigurationen aber nicht unbedingt mit
Ethernet gebaut, sondern mit CI oder DSSI. Schon cluster
ueber DSSI kann sehr cool sein, wenn zwei Maschinen
transparent und gleichzeitig auf ein und dieselbe physikalische
Platte zugreifen koennen.
In einem Reservat mag das ja funktionieren,
der klassische VMS cluster im technischen/akademischen Umfeld
sah aber oft so aus, dass ein oder zwei zentrale Server mit ein paar
dutzend im ganzen Gebäude verstreuten VS3100 (VS4000) verbunden waren.
Für flächendeckende Redundanz gab's kein Geld,
mal abgesehen davon, dass ich mir
das bei Workstations auch schwer vorstellen kann.
Im Prinzip unterschied sich diese Konfiguration nicht von
der Unix-üblichen (NFS-server plus workstations/xterms).
Ausser dass das Unix Geraffel stabiler war und man
es nicht "Cluster" nennen durfte, sonst wurden die VMSlinge
ungehalten :-) Den Unterschied habe ich bis heute
nicht verstanden.
Dennis Grevenstein
2010-11-29 15:46:13 UTC
Permalink
Post by Michael Kraemer
In einem Reservat mag das ja funktionieren,
der klassische VMS cluster im technischen/akademischen Umfeld
sah aber oft so aus, dass ein oder zwei zentrale Server mit ein paar
dutzend im ganzen Gebäude verstreuten VS3100 (VS4000) verbunden waren.
Für flächendeckende Redundanz gab's kein Geld,
Das ist oft so. Leider ist die Software mehr dafuer gemacht
gewesen, dass die Leute das Geld fuer anstaendige Hardware
ausgeben.
Post by Michael Kraemer
mal abgesehen davon, dass ich mir
das bei Workstations auch schwer vorstellen kann.
Im Prinzip unterschied sich diese Konfiguration nicht von
der Unix-üblichen (NFS-server plus workstations/xterms).
Ausser dass das Unix Geraffel stabiler war und man
es nicht "Cluster" nennen durfte, sonst wurden die VMSlinge
ungehalten :-) Den Unterschied habe ich bis heute
nicht verstanden.
VMScluster geht teilweise einfacher und die Kisten bekommen
untereinander z.B. failover besser hin. Wenn man Redundanzen
hat, dann lassen die sich gut ausnutzen. Aber die klassische
akademische Umgebung ist halt nicht entsprechend ausgestattet.

gruss,
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
Michael Baeuerle
2010-11-29 09:07:21 UTC
Permalink
Post by Dennis Grevenstein
DEC hat solche Konfigurationen aber nicht unbedingt mit
Ethernet gebaut, sondern mit CI oder DSSI. Schon cluster
ueber DSSI kann sehr cool sein, wenn zwei Maschinen
transparent und gleichzeitig auf ein und dieselbe physikalische
Platte zugreifen koennen.
War DSSI eine SCSI Kopie? Es soll zumindest irgendwie kompatibel mit
SCSI-Hardware gewesen sein, weisst du was genaueres drueber?


Micha
Dennis Grevenstein
2010-11-29 15:34:16 UTC
Permalink
Post by Michael Baeuerle
War DSSI eine SCSI Kopie? Es soll zumindest irgendwie kompatibel mit
SCSI-Hardware gewesen sein, weisst du was genaueres drueber?
Ich glaube es war aehnlich zu SCSI. Aber kompatibel zu SCSI war
es auf keinen Fall. Es gab aber extra DSSI-SCSI Bruecken, die
z.B. SCSI Platten als devices auf dem DSSI Bus verfuegbar gemacht
haben. Das war aber mehr als ein simpler Umwandler. DSSI Platten
haben ja IIRC auch Eigenintelligenz und koennen z.B. die Zeit
angeben, die die Festplatte insgesamt gelaufen ist und so Scherze.
Fuer die Zeit Ende der 80er/ Anfang 90er schon extrem cool.

http://www.mcmanis.com/chuck/computers/vaxen/dssi-plug.html

gruss,
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
Michael Baeuerle
2010-11-29 16:50:33 UTC
Permalink
Post by Dennis Grevenstein
Post by Michael Baeuerle
War DSSI eine SCSI Kopie? Es soll zumindest irgendwie kompatibel mit
SCSI-Hardware gewesen sein, weisst du was genaueres drueber?
Ich glaube es war aehnlich zu SCSI. Aber kompatibel zu SCSI war
es auf keinen Fall. Es gab aber extra DSSI-SCSI Bruecken, die
z.B. SCSI Platten als devices auf dem DSSI Bus verfuegbar gemacht
haben. Das war aber mehr als ein simpler Umwandler. DSSI Platten
haben ja IIRC auch Eigenintelligenz
Die brauchen SCSI Platten auch.
Post by Dennis Grevenstein
und koennen z.B. die Zeit
angeben, die die Festplatte insgesamt gelaufen ist und so Scherze.
Fuer die Zeit Ende der 80er/ Anfang 90er schon extrem cool.
http://www.mcmanis.com/chuck/computers/vaxen/dssi-plug.html
Ende der 80er kam auch SCSI1 raus, deswegen frage ich. DSSI ist
jedenfalls auch ein parallel terminierter Bus. Im Netz konnte ich aber
kein Pinout finden, das wuerde die Frage ja zumindest naeherungsweise
auch beantworten.


Micha
Ulrich F. Heidenreich
2010-11-28 11:03:01 UTC
Permalink
Post by Michael Kraemer
Post by Goetz Hoffart
Post by Michael Kraemer
Und was bitte kann man da "richtig" machen?
Unterbrochen ist nun mal unterbrochen.
Wenn man ein T-Stück am Rechner hat, dann wird doch nichts unterbrochen,
wenn man das Längsstück vom Rechner wegnimmt?
und was ist wenn man noch *kein* T-Stück am Rechner hat,
Dann stopft man auch kein Kabel rein. Zumindestens
keines, welches /nicht/ EAD-Kabel heißt.

CU!
Ulrich
--
In 0 Monat und 29 Tagen ist Weihnachten
U9HEC JWEKL OABLK IPOH6 KQECS EWCUC D2NU4 N2CLJ WZPBG
Stellt euch vor, es ist Sonntag und keiner geht hin!
Michael Kraemer
2010-11-28 11:33:22 UTC
Permalink
Post by Ulrich F. Heidenreich
Dann stopft man auch kein Kabel rein. Zumindestens
keines, welches /nicht/ EAD-Kabel heißt.
Dennis hat es erfasst, die andern scheinen
(absichtlich ?) begriffstutzig zu sein,
da kann man wohl nix machen.
Goetz Hoffart
2010-11-28 12:40:12 UTC
Permalink
Post by Michael Kraemer
Dennis hat es erfasst, die andern scheinen
(absichtlich ?) begriffstutzig zu sein,
da kann man wohl nix machen.
Das in der Klammer hättest du dir, trotz Fragezeichen, IMO sparen
können. Eigentlich sind wir ja dafür hier, wenn man mal was nicht
versteht. Da Absicht (wozu diese?) zu unterstellen ist unnötig.

Grüße
Götz
--
http://www.knubbelmac.de/
Michael Baeuerle
2010-11-04 13:32:12 UTC
Permalink
Post by Michael Baeuerle
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)
Tja zumindiset die 250 sind immer mit Ethernet (AUI) onboard gekommen.
TR war da optional. Und die c10 hat weder TR noch eth per default.
Meine 42T hat auch "nur" Ethernet onboard, aber ich habe
"selbstverstaendlich" eine TR-Karte drinstecken :-)

Netzwerk geht auch voellig problemlos, nur das AIX (4.3.3) bringt mich
zur Verzweiflung. Ich habe jetzt schon diverse GCCs probiert (2er und
3er), aber irgendwie kommen die mit dem IBM Linker nicht wirklich klar.
Viele Sachen gehen, andere (speziell C++ Programme) lassen sich komplett
compilieren aber am Ende nicht linken.

Langsam geht mir wirklich die Geduld aus (und ich bin nicht jemand der
schnell aufgibt). So einen GCC compilieren kann auf der lahmen CPU schon
mal mehrere Tage dauern und wird noch massiv ausgebremst weil die
originale /bin/sh so dermassen lahm ist - einmal habe ich sie durch eine
bash ersetzt weil ich dachte ich erlebe es nicht mehr bis das configure
Script durchlaeuft, der Unterschied war echt unglaublich. Und wenn man
GCC von 2.x auf 3.x updatet darf man C++ maessig wegen dem ABI auch
gleich nochmal _alles_ neu compilieren. Am Ende ging es jedenfalls mit
beiden nicht, also nochmal bei Null angefangen und mit pkgsrc probiert
(bootstrap mit 2.95 und dann wie offiziell empfohlen den dort
vorgesehenen 3er GCC bauen lassen). Out-of-the-box tut da AIX-typisch
gar nichts, nichtmal der Bootstrap, aber irgendwie kriegt man es dann
schon an den Start. Am Ende bin ich bestimmt >>50 Stunden drangesessen,
die Maschine ist viele Naechte durchgelaufen und es ging wieder nur bis
99% und ist dann erneut am Linker gescheitert ... */&$$%"=??//=()/!!!elf

AIX 4 mit OSS betreiben zu wollen ist echt was fuer
Hardcore-Masochisten. Wenn auf der 42T was anderes laufen wuerde waere
mir mittlerweile der Stilbruch _sowas_ von egal, das koennt ihr euch gar
nicht vorstellen ;-) Hat jemand Mitleid mit mir und vielleicht ein AIX
5.x das auf der 42T laeufen wuerde und sich nicht ganz so hinterhaeltig
anstellt? Alternativ einen IBM C++ Compiler der hoffentlich mit dem IBM
Linker vernuenftig umgehen kann.


Micha
Jochen Pawletta
2010-11-04 13:58:10 UTC
Permalink
Hallo
Post by Michael Baeuerle
AIX 4 mit OSS betreiben zu wollen ist echt was fuer
Hardcore-Masochisten. Wenn auf der 42T was anderes laufen wuerde waere
mir mittlerweile der Stilbruch _sowas_ von egal, das koennt ihr euch gar
nicht vorstellen ;-) Hat jemand Mitleid mit mir und vielleicht ein AIX
5.x das auf der 42T laeufen wuerde und sich nicht ganz so hinterhaeltig
anstellt? Alternativ einen IBM C++ Compiler der hoffentlich mit dem IBM
Linker vernuenftig umgehen kann.
AIX 5L (5.1) läuft auf jeder mir bekannten RS/6000 (pSeries).
Das "L" im Namen steht für "Linux", und soll die OSS-Unterstützung
hervorheben ...


mfg Jochen
--
ZX81 - C64 - Amiga - x86-Linux - iMac (OS X)
Michael Kraemer
2010-11-04 14:38:15 UTC
Permalink
Post by Michael Baeuerle
Post by Michael Baeuerle
Wie kann man auch an einer AIX-Maschine Ethernet verwenden, das ist ja
sowas von Stilbruch ;-)
Tja zumindiset die 250 sind immer mit Ethernet (AUI) onboard gekommen.
TR war da optional. Und die c10 hat weder TR noch eth per default.
Meine 42T hat auch "nur" Ethernet onboard, aber ich habe
"selbstverstaendlich" eine TR-Karte drinstecken :-)
die 25x und 42T sind halt schon 2. Generation,
da hat IBM es wohl schon aufgegeben, mit TR gegen Ethernet anzustinken.
Post by Michael Baeuerle
Netzwerk geht auch voellig problemlos, nur das AIX (4.3.3) bringt mich
zur Verzweiflung. Ich habe jetzt schon diverse GCCs probiert (2er und
3er), aber irgendwie kommen die mit dem IBM Linker nicht wirklich klar.
Viele Sachen gehen, andere (speziell C++ Programme) lassen sich komplett
compilieren aber am Ende nicht linken.
Was geht denn genau nicht? Vielleicht fehlen irgendwelche libs?
Post by Michael Baeuerle
Langsam geht mir wirklich die Geduld aus (und ich bin nicht jemand der
schnell aufgibt). So einen GCC compilieren kann auf der lahmen CPU schon
mal mehrere Tage dauern und wird noch massiv ausgebremst weil die
originale /bin/sh so dermassen lahm ist
original waere ksh ...
Post by Michael Baeuerle
- einmal habe ich sie durch eine
bash ersetzt weil ich dachte ich erlebe es nicht mehr bis das configure
Script durchlaeuft, der Unterschied war echt unglaublich.
liegt wohl eher an der Missgeburt namens "configure" ...
Post by Michael Baeuerle
Und wenn man
GCC von 2.x auf 3.x updatet darf man C++ maessig wegen dem ABI auch
gleich nochmal _alles_ neu compilieren.
liegt am C++ bzw gcc selbst.
Post by Michael Baeuerle
Am Ende ging es jedenfalls mit
beiden nicht, also nochmal bei Null angefangen und mit pkgsrc probiert
(bootstrap mit 2.95 und dann wie offiziell empfohlen den dort
vorgesehenen 3er GCC bauen lassen).
Ich weiss nicht warum Du es Dir so schwer machst.
Es gibt vorkompilierte gcc-Versionen (auch fuer AIX 4.3.3),
zB auf
http://computer-refuge.org/classiccmp/aixpdslib/pub/
Die aixpdslib Leute haben damals ihren ganzen Kram mit gcc gebaut.
Post by Michael Baeuerle
Out-of-the-box tut da AIX-typisch
gar nichts,
das ist nicht aix-typisch, sondern OSS-typisch.
Sind halt grossenteils Stuemper.
Post by Michael Baeuerle
nichtmal der Bootstrap, aber irgendwie kriegt man es dann
schon an den Start. Am Ende bin ich bestimmt >>50 Stunden drangesessen,
kenn' ich. Liegt am configure.
Hast Du mal mitgezaehlt wie oft es das Vorhandensein von "strings.h" testet?
Post by Michael Baeuerle
die Maschine ist viele Naechte durchgelaufen und es ging wieder nur bis
99% und ist dann erneut am Linker gescheitert ... */&$$%"=??//=()/!!!elf
Vielleicht compilierst Du erstmal ein "hello world" oder was einfaches
und stellst fest, was dem Linker wirklich fehlt?
Post by Michael Baeuerle
AIX 4 mit OSS betreiben zu wollen ist echt was fuer
Hardcore-Masochisten.
Sorry, das ist Quatsch.
Als 4.3.3 noch "neu" war, ist sehr wohl OSS drauf gelaufen.
Es gibt bekanntlich von IBM die Toolbox mit OSS speziell fuer 4.3.3,
deren Horizont endet aber ca 2003, als 4.3.3 langsam aus dem Support fiel.
*Neue* OSS auf/fuer 4.3.3 zu bauen, ist genauso leicht/schwer wie
auf HP-UX, Tru64 etc, das liegt aber hauptsaechlich am
kranken "configure" Mechanismus.
Post by Michael Baeuerle
Wenn auf der 42T was anderes laufen wuerde waere
mir mittlerweile der Stilbruch _sowas_ von egal, das koennt ihr euch gar
nicht vorstellen ;-) Hat jemand Mitleid mit mir und vielleicht ein AIX
5.x das auf der 42T laeufen wuerde und sich nicht ganz so hinterhaeltig
anstellt? Alternativ einen IBM C++ Compiler der hoffentlich mit dem IBM
Linker vernuenftig umgehen kann.
Ein 5.1 (mehr geht eh nicht) waere fuer Deine Zwecke nur etwas langsamer,
aber nicht unbedingt besser, weil es eben nicht am BS sondern an der
unfaehigen OSS liegt. Du findest aber evtl mehr vorkompilierte Soft als fuer
4.x.
Ditto die Compiler (fuer 4.3.3 ware VAC/C++ 6 grade noch richtig),
natuerlich koennen die mit dem Linker (ebenso wie gcc normalerweise),
aber den Krampf mit dem configure haettest Du trotzdem.
Marco Lorig
2010-11-04 15:39:50 UTC
Permalink
Post by Michael Kraemer
Post by Michael Baeuerle
Meine 42T hat auch "nur" Ethernet onboard, aber ich habe
"selbstverstaendlich" eine TR-Karte drinstecken :-)
die 25x und 42T sind halt schon 2. Generation,
da hat IBM es wohl schon aufgegeben, mit TR gegen Ethernet anzustinken.
Hm, mir würde da jetzt spontan gar keine RS/6000 mit integriertem TR
einfallen. Selbst die 320/32H hat das nicht.
Die meisten hatten allerdings eine TR Karte im MCA Slot stecken.

Gibt es eine RS76k mit onboard TR?

Grüße Marco
Michael Kraemer
2010-11-04 15:49:59 UTC
Permalink
Post by Marco Lorig
Post by Michael Kraemer
Post by Michael Baeuerle
Meine 42T hat auch "nur" Ethernet onboard, aber ich habe
"selbstverstaendlich" eine TR-Karte drinstecken :-)
die 25x und 42T sind halt schon 2. Generation,
da hat IBM es wohl schon aufgegeben, mit TR gegen Ethernet anzustinken.
Hm, mir würde da jetzt spontan gar keine RS/6000 mit integriertem TR
einfallen. Selbst die 320/32H hat das nicht.
nein, die war noch "neutral", d.h. man konnte/musste
sich eine (oder beide) der NIC-typen dazubestellen.

Ich meinte eigentlich die mehr oder weniger subtile Botschaft,
die damit verbunden ist: wenn Ethernet
standardmaessig mitgeliefert wird, haben sie es als
"Gewinner" anerkannt und TR gibt's nur noch fuer Freaks
gegen Aufpreis.
Michael Baeuerle
2010-11-04 17:32:07 UTC
Permalink
Post by Michael Kraemer
Post by Michael Baeuerle
Netzwerk geht auch voellig problemlos, nur das AIX (4.3.3) bringt mich
zur Verzweiflung. Ich habe jetzt schon diverse GCCs probiert (2er und
3er), aber irgendwie kommen die mit dem IBM Linker nicht wirklich klar.
Viele Sachen gehen, andere (speziell C++ Programme) lassen sich komplett
compilieren aber am Ende nicht linken.
Was geht denn genau nicht? Vielleicht fehlen irgendwelche libs?
Waere moeglich, aber ich habe nicht rausgefunden was ihm fehlt. Bei
Interesse kann ich heute Abend den Fehler ja nochmal triggern.

Was zum Beispiel auch nicht geht ist einfach einen aktuellen GCC zu
compilieren. Der binaere 2.95 kann weder einen 3.4 noch einen 4.x
Compiler bauen. Einen 3.3er habe ich zu Stande bekommen, aber auch da
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
Post by Michael Kraemer
Post by Michael Baeuerle
Langsam geht mir wirklich die Geduld aus (und ich bin nicht jemand der
schnell aufgibt). So einen GCC compilieren kann auf der lahmen CPU schon
mal mehrere Tage dauern und wird noch massiv ausgebremst weil die
originale /bin/sh so dermassen lahm ist
original waere ksh ...
Ja, eine ksh muesste das sein.
Post by Michael Kraemer
Post by Michael Baeuerle
- einmal habe ich sie durch eine
bash ersetzt weil ich dachte ich erlebe es nicht mehr bis das configure
Script durchlaeuft, der Unterschied war echt unglaublich.
liegt wohl eher an der Missgeburt namens "configure" ...
Nein, die ksh ist bei manchen Sachen wirklich elend langsam. Ist mir bei
einem von meinen Skripten auf einer x86-Maschine auch schon aufgefallen
als ich es mit allen Shells durchgetestet habe (dort pdksh vs bash).
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Am Ende ging es jedenfalls mit
beiden nicht, also nochmal bei Null angefangen und mit pkgsrc probiert
(bootstrap mit 2.95 und dann wie offiziell empfohlen den dort
vorgesehenen 3er GCC bauen lassen).
Ich weiss nicht warum Du es Dir so schwer machst.
Es bringt zumindest ans Licht, dass da was nicht stimmt - wenn der GCC
nichtmal sich selbst compiliert bekommt.
Post by Michael Kraemer
Es gibt vorkompilierte gcc-Versionen (auch fuer AIX 4.3.3),
zB auf
http://computer-refuge.org/classiccmp/aixpdslib/pub/
Die aixpdslib Leute haben damals ihren ganzen Kram mit gcc gebaut.
Der 2.95 den ich verwendet habe war ja ein Binaerpaket, mit irgendwas
muss man sich ja aus dem Sumpf ziehen. Leider kann man heute vieles
nichtmal mehr mit GCC 3.3 compilieren. Das meiste geht immerhin noch mit
3.4.

Dort liegt aber auch ein binaerer GCC 3.4.3, den werde ich auch noch
testen.
Post by Michael Kraemer
Post by Michael Baeuerle
Out-of-the-box tut da AIX-typisch
gar nichts,
das ist nicht aix-typisch, sondern OSS-typisch.
Sind halt grossenteils Stuemper.
Jein, bei AIX ist schon auch vieles kaputt. Deklarationen liegen in den
falschen Header-Files (nicht POSIX konform), kaputte C9X Macros, da gibt
es sicher noch mehr. Ich habe auch schon Reports fuer OSS geschrieben
damit die da Workarounds einbauen koennen (die haben meistens selber
keinen Zugang zu AIX Maschinen). Eigentlich lag es aber gar nicht an
ihrer Software, da jetzt die Schuld komplett der OSS zuzuschieben finde
ich nicht fair.
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
die Maschine ist viele Naechte durchgelaufen und es ging wieder nur bis
99% und ist dann erneut am Linker gescheitert ... */&$$%"=??//=()/!!!elf
Vielleicht compilierst Du erstmal ein "hello world" oder was einfaches
und stellst fest, was dem Linker wirklich fehlt?
Solche Sachen gehen, erst bei komplizierterm Zeug scheitert es dann. Das
Configure-Script testet ja ob der Compiler funktioniert und wuerde gar
nicht durchlaufen wenn dem was grundsaetzliches fehlen wuerde.
Post by Michael Kraemer
Post by Michael Baeuerle
AIX 4 mit OSS betreiben zu wollen ist echt was fuer
Hardcore-Masochisten.
Sorry, das ist Quatsch.
Als 4.3.3 noch "neu" war, ist sehr wohl OSS drauf gelaufen.
Es gibt bekanntlich von IBM die Toolbox mit OSS speziell fuer 4.3.3,
deren Horizont endet aber ca 2003, als 4.3.3 langsam aus dem Support fiel.
*Neue* OSS auf/fuer 4.3.3 zu bauen, ist genauso leicht/schwer wie
auf HP-UX, Tru64 etc, das liegt aber hauptsaechlich am
kranken "configure" Mechanismus.
Also mir kommt das nicht so vor, mit Solaris 7 und HP-UX 11 habe ich
auch schon rumgespielt und das war doch deutlich schmerzaermer. Speziell
ersteres ist ja jetzt auch nicht so wahnsinnig aktuell. Aber gut, mit
AIX habe ich mich schon deutlich intensiver beschaeftigt, vielleicht bin
ich bei den anderen nur noch nicht weit genug in "die Abgruende"
vorgedrungen.


Micha
Michael Kraemer
2010-11-04 18:36:45 UTC
Permalink
Post by Michael Baeuerle
Was zum Beispiel auch nicht geht ist einfach einen aktuellen GCC zu
compilieren. Der binaere 2.95 kann weder einen 3.4 noch einen 4.x
Compiler bauen. Einen 3.3er habe ich zu Stande bekommen, aber auch da
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
ich weiss nicht, ob der Hinweis der aixpdslib-Leute noch aktuell ist:
http://www.gsi.de/~kraemer/COLLECTION/AIX/aixpdslib.seas.ucla.edu/packages/gcc.html

vielleicht nimmst Du wirklich erstmal einen vorkompilierten gcc
und versuchst was einfacheres zu kompilieren.
Dann weisst Du wenigstens ob gcc und ld miteinander koennen.
(ich sehe eben keinen Grund warum nicht).
Post by Michael Baeuerle
Post by Michael Kraemer
Post by Michael Baeuerle
- einmal habe ich sie durch eine
bash ersetzt weil ich dachte ich erlebe es nicht mehr bis das configure
Script durchlaeuft, der Unterschied war echt unglaublich.
liegt wohl eher an der Missgeburt namens "configure" ...
Nein, die ksh ist bei manchen Sachen wirklich elend langsam. Ist mir bei
einem von meinen Skripten auf einer x86-Maschine auch schon aufgefallen
als ich es mit allen Shells durchgetestet habe (dort pdksh vs bash).
Ein intelligent gestricktes script laeuft auf allen shells so,
dass man nicht zu lange wartet ...
Post by Michael Baeuerle
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Am Ende ging es jedenfalls mit
beiden nicht, also nochmal bei Null angefangen und mit pkgsrc probiert
(bootstrap mit 2.95 und dann wie offiziell empfohlen den dort
vorgesehenen 3er GCC bauen lassen).
Ich weiss nicht warum Du es Dir so schwer machst.
Es bringt zumindest ans Licht, dass da was nicht stimmt - wenn der GCC
nichtmal sich selbst compiliert bekommt.
Erstens haben das offenbar schon etliche vor Dir geschafft,
und zweitens ist ein so komplexes Produkt wie der gcc
kaum ein geeignetes Uebungsobjekt. Bei OSS kann da alles
moegliche schiefgehen.
Post by Michael Baeuerle
Post by Michael Kraemer
Es gibt vorkompilierte gcc-Versionen (auch fuer AIX 4.3.3),
zB auf
http://computer-refuge.org/classiccmp/aixpdslib/pub/
Die aixpdslib Leute haben damals ihren ganzen Kram mit gcc gebaut.
Der 2.95 den ich verwendet habe war ja ein Binaerpaket, mit irgendwas
muss man sich ja aus dem Sumpf ziehen.
Dann probier doch mit dem mal was einfaches oder
mittelschweres damit zu kompilieren.
Post by Michael Baeuerle
Leider kann man heute vieles
nichtmal mehr mit GCC 3.3 compilieren. Das meiste geht immerhin noch mit
3.4.
Ja, das nennt man halt "Fortschritt":
Sachen die gestern noch gingen, gehen heute nicht mehr.

Du moegest auch bedenken, dass AIX 4.3.3 immerhin ca 10 Jahre
auf dem Buckel hat. Ich weiss nicht wieviel Zeux von heute
man noch auf einem 10 Jahre alten Linux gebacken bekommt.
Post by Michael Baeuerle
Dort liegt aber auch ein binaerer GCC 3.4.3, den werde ich auch noch
testen.
Es gibt auch noch neuere Versionen:

ftp://ftp.thewrittenword.com/packages/by-architecture/powerpc-ibm-aix4.3.3.0/

(wundert mich jetzt etwas, weil die zwischenzeitlich mal Geld verlangt hatten ..)

Die writtenword Pakete sind uebrigens loeblicherweise mit den
OS-eigenen Installern zu installieren, also kein rpm-Gehampel.
Post by Michael Baeuerle
Post by Michael Kraemer
Post by Michael Baeuerle
Out-of-the-box tut da AIX-typisch
gar nichts,
das ist nicht aix-typisch, sondern OSS-typisch.
Sind halt grossenteils Stuemper.
Jein, bei AIX ist schon auch vieles kaputt. Deklarationen liegen in den
falschen Header-Files (nicht POSIX konform),
zB?
Ich fand da bis jetzt nix auszusetzen.
Post by Michael Baeuerle
kaputte C9X Macros, da gibt
es sicher noch mehr. Ich habe auch schon Reports fuer OSS geschrieben
wenn dem so sein sollte, vielleicht sollte man das mal IBM sagen.
Post by Michael Baeuerle
damit die da Workarounds einbauen koennen (die haben meistens selber
keinen Zugang zu AIX Maschinen). Eigentlich lag es aber gar nicht an
ihrer Software, da jetzt die Schuld komplett der OSS zuzuschieben finde
ich nicht fair.
Es ist halt unter HP-UX et al dasselbe Bild, nur an anderen Stellen.
zB musste ich immer mal "rm -f" durch ein "rm -rf" ersetzen,
weil sonst irgendein obskurer sizeof() Test in die Hose geht.
Offensichtlich, gell?
Post by Michael Baeuerle
Also mir kommt das nicht so vor, mit Solaris 7 und HP-UX 11 habe ich
auch schon rumgespielt und das war doch deutlich schmerzaermer. Speziell
ersteres ist ja jetzt auch nicht so wahnsinnig aktuell. Aber gut, mit
AIX habe ich mich schon deutlich intensiver beschaeftigt, vielleicht bin
ich bei den anderen nur noch nicht weit genug in "die Abgruende"
vorgedrungen.
Naja, ich habe halt immer mal versucht, das eine oder andere
(kleine) OSS-Paket auf verschiedene U*Xen (meist AIX,HP-UX,Tru64) zusammenzubauen.
"Irgendwas war immer", ich konnte da keine Haeufungspunkte feststellen.
Wenn vorhanden nehme ich allerdings die nativen Compiler.
Michael Baeuerle
2010-11-04 22:34:17 UTC
Permalink
Post by Michael Kraemer
Post by Michael Baeuerle
Was zum Beispiel auch nicht geht ist einfach einen aktuellen GCC zu
compilieren. Der binaere 2.95 kann weder einen 3.4 noch einen 4.x
Compiler bauen. Einen 3.3er habe ich zu Stande bekommen, aber auch da
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
http://www.gsi.de/~kraemer/COLLECTION/AIX/aixpdslib.seas.ucla.edu/packages/gcc.html
Aha, den Assembler Fix habe ich schonmal nicht. Und da steht in dem Link
auch nochmal, man soll die ksh wegwerfen wenn man den Build noch erleben
will.
Post by Michael Kraemer
vielleicht nimmst Du wirklich erstmal einen vorkompilierten gcc
und versuchst was einfacheres zu kompilieren.
Dann weisst Du wenigstens ob gcc und ld miteinander koennen.
(ich sehe eben keinen Grund warum nicht).
Ich habe gerade nochmal nachgeschaut, also binaer hatte ich schon
probiert 2.95.3 (zu alt) und 3.4.3 (g++ fehlt). 3.3.6 aus pkgsrc (C++
funktioniert nicht wirklich), vielleicht wegen den Bugs im Assembler.
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Nein, die ksh ist bei manchen Sachen wirklich elend langsam. Ist mir bei
einem von meinen Skripten auf einer x86-Maschine auch schon aufgefallen
als ich es mit allen Shells durchgetestet habe (dort pdksh vs bash).
Ein intelligent gestricktes script laeuft auf allen shells so,
dass man nicht zu lange wartet ...
Hoere ich da unterschwellig heraus, dass du meinem Script einen geringen
IQ unterstellst ;-)

Bei meinem Script wird massenweise Zeug aufgerufen (awk, sed, etc.),
vielleicht liegt es daran. Wenn man das auf der 150MHz Maschine laufen
laesst ist der Unterschied zwischen bash und ksh jedenfalls auch nicht
zu uebersehen.
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Der 2.95 den ich verwendet habe war ja ein Binaerpaket, mit irgendwas
muss man sich ja aus dem Sumpf ziehen.
Dann probier doch mit dem mal was einfaches oder
mittelschweres damit zu kompilieren.
Da funktioniert durchaus auch dickeres Zeug: fvwm oder auch ImageMagick
machen z.B. keine Probleme. Das liess sich aber halt auch mit 2.95
compilieren.
Post by Michael Kraemer
Post by Michael Baeuerle
Leider kann man heute vieles
nichtmal mehr mit GCC 3.3 compilieren. Das meiste geht immerhin noch mit
3.4.
Sachen die gestern noch gingen, gehen heute nicht mehr.
Ja. Und wenn man dann schaut warum, liegt es an Sachen wie Variadic
macros in den Debug messages die man normal gar nicht braucht.
Post by Michael Kraemer
Du moegest auch bedenken, dass AIX 4.3.3 immerhin ca 10 Jahre
auf dem Buckel hat. Ich weiss nicht wieviel Zeux von heute
man noch auf einem 10 Jahre alten Linux gebacken bekommt.
Sehr viel mehr, ich betreibe auch ein Linux 2.2.26 mit einer libc von
IIRC 1999. Das ist im Vergleich der Himmel (wenn AIX die Hoelle ist),
und da muss man alles selber bauen - da gibt es binaer heute quasi
nichts mehr dafuer womit man noch was anfangen koennte.

Diese Linux-Maschine performt mit ihren zwei 180MHz PentiumPro CPUs
nebenbei die 42T in Grund und Boden, da macht das Compilieren richtig
Spass im Vergleich. Selbst wenn man nur eine CPU benutzt sieht die 42T
dagegen noch kein Land.
Post by Michael Kraemer
Post by Michael Baeuerle
Dort liegt aber auch ein binaerer GCC 3.4.3, den werde ich auch noch
testen.
Gerade mal das Archiv inspiziert: Da ist gar kein g++ drin, also genau
wie bei dem den ich hier schon hatte.
Post by Michael Kraemer
ftp://ftp.thewrittenword.com/packages/by-architecture/powerpc-ibm-aix4.3.3.0/
Interessant. Muss ich mir morgen in der 4ma mal runterladen und schauen
ob da ein g++ drin ist, hier ueber ISDN betraegt die prognostizierte
Download-Zeit ca. 15h ...
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Jein, bei AIX ist schon auch vieles kaputt. Deklarationen liegen in den
falschen Header-Files (nicht POSIX konform),
zB?
Ich fand da bis jetzt nix auszusetzen.
War IIRC ein Problem mit string.h und strings.h, das benoetigte Zeug war
im falschen File deklariert. Einfach das andere zusaetzlich includen und
das Problem war geloest. Und ja, es war wirklich der Header falsch und
nicht das #include.
Post by Michael Kraemer
Post by Michael Baeuerle
kaputte C9X Macros, da gibt
es sicher noch mehr. Ich habe auch schon Reports fuer OSS geschrieben
wenn dem so sein sollte, vielleicht sollte man das mal IBM sagen.
Haben sie bestimmt laengst repariert, und AIX 4 patcht wohl keiner mehr.
Viele configure Scripte haben deswegen auch extra Checks drin ("Checking
for AIX ...", "Checking for broken AIX ..."), da ist wohl einiges nicht
wie es sein sollte.

Und wie das bestellte Beispiel gerade eben frisch auf die Schnauze
geflogen (GCC 3.3.6):
----------------------------------------------------------------------
In file included from /usr/include/sys/pri.h:29,
from /usr/include/sys/sched.h:38,
from /usr/include/sched.h:52,
from /usr/include/pthread.h:47,
from dns.c:16:
/usr/include/sys/proc.h:203: error: parse error before "crid_t"
/usr/include/sys/proc.h:212: error: parse error before "p_class"
/usr/include/sys/proc.h:349: error: parse error before '}' token
make[3]: *** [dns.o] Error 1
----------------------------------------------------------------------
Keine Ahnung was da jetzt wieder in proc.h kaputt ist, das finde ich
auch heute nicht mehr raus, <gaehn> dafuer bin ich zu muede </gaehn>.
Post by Michael Kraemer
Post by Michael Baeuerle
damit die da Workarounds einbauen koennen (die haben meistens selber
keinen Zugang zu AIX Maschinen). Eigentlich lag es aber gar nicht an
ihrer Software, da jetzt die Schuld komplett der OSS zuzuschieben finde
ich nicht fair.
Es ist halt unter HP-UX et al dasselbe Bild, nur an anderen Stellen.
zB musste ich immer mal "rm -f" durch ein "rm -rf" ersetzen,
weil sonst irgendein obskurer sizeof() Test in die Hose geht.
Offensichtlich, gell?
?


Micha
--
http://micha.freeshell.org/
Michael Baeuerle
2010-11-06 10:49:26 UTC
Permalink
Post by Michael Baeuerle
Post by Michael Kraemer
Post by Michael Baeuerle
[...]
Nein, die ksh ist bei manchen Sachen wirklich elend langsam. Ist mir bei
einem von meinen Skripten auf einer x86-Maschine auch schon aufgefallen
als ich es mit allen Shells durchgetestet habe (dort pdksh vs bash).
Ein intelligent gestricktes script laeuft auf allen shells so,
dass man nicht zu lange wartet ...
Hoere ich da unterschwellig heraus, dass du meinem Script einen geringen
IQ unterstellst ;-)
Bei meinem Script wird massenweise Zeug aufgerufen (awk, sed, etc.),
vielleicht liegt es daran. Wenn man das auf der 150MHz Maschine laufen
laesst ist der Unterschied zwischen bash und ksh jedenfalls auch nicht
zu uebersehen.
<mode=Ingrid>
Zur Ehrenrettung der ksh noch folgendes:

Ich habe mein Script heute aus Neugier nochmal durch beide Shells gejagt
und die Zeit gemessen. Bei der Gesamtzeit waren beide fast gleichauf
(Differenz <10%), die ksh sogar einen Tick schneller. Die Langsamkeit
war in diesem Fall also eine Taeschung, subjektiv springen einem halt
mehr die Messages auf der Konsole ins Auge, und da gibt es Stellen wo
man mit der ksh regelrecht zuschauen kann wie die einzelnen Zeichen
gemalt werden. Z.B. bei dieser Schleife die dafuer sorgen soll, dass
eine Ueberschrift beliebiger Laenge korrekt unterstrichen wird:

----------------------------------------------------------------------
# Print name and version
echo
TITLE="Plant DataBase (PDB) $VER HTML generator"
echo "$TITLE"
I=0; while test $I -lt ${#TITLE}; do printf "="; I=$(($I + 1)); done
echo
----------------------------------------------------------------------

Das fuehrt die bash um Groessenordnungen schneller aus, vielleicht
benutzt die ksh ein externes printf und muss bei jedem Zeichen einen
neuen Prozess starten. Auf jeden Fall triggert configure wohl irgendso
einen Effekt, da ist die ksh naemlich wirklich erheblich langsamer.
</mode>


Micha
--
http://micha.freeshell.org/
Norbert Narten
2010-11-05 17:23:32 UTC
Permalink
Post by Michael Baeuerle
...
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
...
Hallo Michael,

halte mal ausschau nach dem Optimizer-Flag -O. Bei manchen Compilern
(z.B. Sinix C Entwicklungssystem unter Sinix-L 5.41D20) sorgt dieser
Schalter dafuer, das lesbarer Assembler-Code generiert wird. Ich habe
mir damit beholfen, das ich -O aus den Makefiles nachtraeglich raus
geloescht habe.


Vielleicht hilft der Tipp ja ...
Norbert Narten
Wilhelm Greiner
2010-11-05 18:58:34 UTC
Permalink
Hi,
Post by Norbert Narten
Post by Michael Baeuerle
...
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
...
halte mal ausschau nach dem Optimizer-Flag -O. Bei manchen Compilern
(z.B. Sinix C Entwicklungssystem unter Sinix-L 5.41D20) sorgt dieser
Schalter dafuer, das lesbarer Assembler-Code generiert wird. Ich habe
mir damit beholfen, das ich -O aus den Makefiles nachtraeglich raus
geloescht habe.
Bei sgi/mips war mir mal aufgefallen das Code mit -O kaputt war,
code mit -O3 aber sauber lief, keine Ahnung warum, aber da
ganz pragmatisch eine Einzelzeile bei Problemen nochmals zu
kompilieren und damit zu experimentieren kann wohl nicht schaden.

Die Mipspro man page von Irix enthält btw. ein paar Porting Tips,
für OSS, evtl. hilfts auch anderswo.
Es ist die Section "GNU CC NOTES" in der Man Page cc(1).
Wobei die meissten originalen CC wohl nicht mehr wirklich
verwendet werden, sondern hauptsächlich gcc, aber schade
weil tw. alles viel schneller wird.

Das man dennoch oft in den configure Files basteln muss ändert
sich dadurch nicht, einfacher wirds halt wenn man die gängigen
ganzen kleinen gnu Progrämmchen konsequent alle in ein Dir
kompiliert und das mit PATH vorneranhängt, viele kleinigkeiten
gehen denn einfacher. - Ist ja nur zum bauen nötig, später egal.

Wilhelm
Michael Baeuerle
2010-11-06 10:18:17 UTC
Permalink
Post by Wilhelm Greiner
Post by Norbert Narten
Post by Michael Baeuerle
...
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
...
halte mal ausschau nach dem Optimizer-Flag -O. Bei manchen Compilern
(z.B. Sinix C Entwicklungssystem unter Sinix-L 5.41D20) sorgt dieser
Schalter dafuer, das lesbarer Assembler-Code generiert wird. Ich habe
mir damit beholfen, das ich -O aus den Makefiles nachtraeglich raus
geloescht habe.
Bei sgi/mips war mir mal aufgefallen das Code mit -O kaputt war,
code mit -O3 aber sauber lief, keine Ahnung warum, aber da
ganz pragmatisch eine Einzelzeile bei Problemen nochmals zu
kompilieren und damit zu experimentieren kann wohl nicht schaden.
IIRC hatte ich damit auch schon rumgespielt, das Problem blieb aber,
dass fuer meine CPU unpassende Assemblerbefehle erzeugt wurden. Es half
dann am Ende nur den multilib support abzuschalten/rauszupatchen was
wohl eigentlich nicht vorgesehen/erlaubt ist. Jetzt hat sich ja im
nachhinein herausgestellt, dass der IBM Assembler broken ist und der GCC
vmtl. unschuldig.
Post by Wilhelm Greiner
Die Mipspro man page von Irix enthält btw. ein paar Porting Tips,
für OSS, evtl. hilfts auch anderswo.
Es ist die Section "GNU CC NOTES" in der Man Page cc(1).
Wobei die meissten originalen CC wohl nicht mehr wirklich
verwendet werden, sondern hauptsächlich gcc, aber schade
weil tw. alles viel schneller wird.
Das man dennoch oft in den configure Files basteln muss ändert
sich dadurch nicht, einfacher wirds halt wenn man die gängigen
ganzen kleinen gnu Progrämmchen konsequent alle in ein Dir
kompiliert und das mit PATH vorneranhängt, viele kleinigkeiten
gehen denn einfacher. - Ist ja nur zum bauen nötig, später egal.
Durch das Tal bin ich laengst durch, hier gibt es mittlerweile das volle
GNU-Programm (bash, gtar, gmake, flex, bison, etc.). Mit dem SysV make
kommt man nicht weit (eigentlich kaum einen Schritt vor die Tuer), die
ksh ist bei manchen Sachen elend langsam und lex/yacc sind auf meinem
System gar nicht dabei gewesen.

Aber meine Motivation AIX 4 zu treten ist jetzt wirklich erschoepft. So
wie es aussieht bekomme ich ein AIX 5.1, dann werde ich erstmal das
testen.


Micha
--
http://micha.freeshell.org/
Michael Kraemer
2010-11-03 07:24:21 UTC
Permalink
Post by Marc-Tell Volkmann
Wie der Titel schon sagt, suche ich für die alten IBM PS/2-Systeme eine
AIX Version ( 1.1 - 1.3 ). Sollte auf einem 386er oder 486er laufen.
Falls jemand soetwas verstauben läßt und einfach nicht weiss, wohin
damit, kann er sich ja bei mir melden.
bevor Du Dir einen Wolf suchst:

http://www.vetusware.com/

(sind noch mehr interessante Sachen drauf)
Lesen Sie weiter auf narkive:
Loading...