English Creme Rezept:
500ml Milch
1 Vanilleschote
6 Eigelb
150g Zucker
Milch, Vanilleschote, 1/2 Zucker zum kochen bringen
Eigelb+1/2 Zucker schaumig schlagen, etwas Milch zugeben.
Alles zusammen bringen und unter rühren (nur nicht aufhören!!) aufkochen. (Notiz beachten!)
Rühren, bis alles kalt ist, durch ein Sieb geben.
---------------------------------------------------
Jetzt kann man das Zeug als Basis für Torteninnenleben verwenden (solo ist es zu dünn) oder - und das ist der Hit - ins Tiefkühlfach stecken. Hin und wieder mal umrühren.
Das gibt ein einmalig leckeres Vanille-Eis! Locker (kommt vom Aufschlagen), süß und vanillig - sogar mit echter Vanille!
Notizen:
Kurz bevor es dem Ei-Gemisch zu heiss wird, vergrößert es sein Volumen, jetzt ist es Zeit den Topf vom Herd zu nehmen. Und immer schön rühren!
Vanilleschote klassisch behandeln: Innenleben rauskratzen und in die Milch packen. Restschote ganz am Ende aus der Creme nehmen. Man könnte sie jetzt auch noch klein mahlen und die schwarzen Stipsen im Eis als Vanille verkaufen, bringt aber geschmacklich nicht mehr viel, weil der Geschmack bereits rausgekocht wurde - aber macht nur!
Freitag, 5. Juni 2009
English Creme - cool
Mittwoch, 20. Mai 2009
Trau keiner Statistik...
Donnerstag, 23. April 2009
Neue Küche - Im Keim erstickt
Ich will eine neue Küche. Schon seit 3 Jahren. Soweit nicht schlimm, aber: Im Gegensatz zu vielen anderen Kunden weiss ich sehr genau, was ich will. Und das ist das Killerargument. Denn:
Es gibt alles das, was ich will, aber nie in einem Laden und aus einer Serie.
Was ich so Besonderes will? Keine Ahnung.
Teil1 - Optik - erfüllt jeder Laden:
- Front: ist mir egal, findet sich dann schon (soll hell sein, kein Lack, der ist bald ab
)
- Glas: brauch ich nicht.
- Licht: bin ich flexibel, findet sich. Der Markt ist gross.
- Arbeitsplatte: Stabil, eventuell tauschbar, kein Stein - auch eher der harmlose Kundenwunsch.
Teil2 - Funktionen der Schränke - hier fliegen 99,9% aller Anbieter raus
- ich will Sockelschubladen. Die Beschlägehersteller Hettich, Blum und Grass bieten das an, nur die Küchenhersteller reichen das Angebot nicht weiter. Ausnahme: DanKüchen (leider nur ein Laden in München, braucht einen Nachtest, Test 1 war verheerend, hat aber wegen Wiesnzeit eine 2. Chance verdient)
Eigentlich sollte man ja annehmen, dass so Kandidaten wie Ikea (entdecke die Möglichkeiten, Platz- und Raumsparend, die Wände ausnutzend...) dieses Konzept mit Handkuss aufnehmen, aber die springen nicht drauf an.
- Ich will in den Oberschränken teilweise Apotheker-Artige Auszüge haben. In Schränken unterhalb der Augenlinie, kann man gut von oben reinschauen. Alles was drüber liegt, muss entweder erklettert/ertastet werden oder eben von unten einsehbar sein und da haben sich meine Apotheker: 30-40cm bewährt! Dumm nur, dass der Schrank drunter 60cm sein soll. Solche Kombinationen habe ich noch nirgends gesehen. Bei einem Beschlägehersteller habe ich nachträglich einbaubare Schub-Körbchen in Oberschränken gesehen, aber das machte keinen besonders stabilen Eindruck via PDF und die mechanische Lösung schien mehr Platz zu brauchen, als sie Nutzen bringt...
- Kochfläche in einer abgeschrägten Ecke. Sowas scheint aus der Mode gekommen zu sein....
- Der Rest ist nicht neu: Abfall-Sammelauszug, Ecklösung Unterschrank... Diverser Kleinkram halt, den haben sie wieder alle, ausser man will die tiefe Version, die den Sockel nutzt (wird angeboten, aber mal wieder eher nicht von den Küchenbauern).
- Die Mechaniken sollten allgemein stabil sein, Bluemotion (so nennt das Blum?) haben und an einer Stelle Klick-Tip (auch Blum-Speak - die anderen haben sowas auch, haben dem Baby nur andere Namen gegeben, aber Blum hat einen vollständigen PDF Katalog, die anderen nur fliegende Einzeldokumente im Web)
- eine Besonderheit: rechts und links der Kochstellen hätte ich gerne versenkbare Granitplatten als Topfuntersetzer. Hersteller: unbekannt. Gefunden bei: www.kuechen-werksverkauf.de -> Einbau-Granitfelder (wird mit einer Edelstahlwanne in der Arbeitsplatte versenkt, Stein kann zum putzen/ersetzen rausgenommen werden) - in Küchenstudios noch nie gesehen! Die verkaufen lieber fliegende Untersetzer.
- und noch etwas, was keiner zu wollen scheint - ausser mir: Ausnutzung der gesamten Tiefe. Was hilft es, wenn Schrank und Arbeitsplatten 70cm tief sind und dann in den Schränken Schubladen und Körbchen mit 50cm Tiefe stecken? (mal abgesehen davon, dass man dahinter dann gelegentlich lustige Dinge wieder findet.)
- die Besteckschubladen hätte ich beinahe vergessen: da passen in das Standardmodell Schublade locker zwei von rein - also bitte für mich eine Besteckschublade mit Innenschublade. Zwei Besteckkästen aufeinander gestellt geht zwar, ist aber nicht so wirklich praktisch.
Teil3 Elektrik/Elektronik&Co - auch hier wird es wieder dünn.
- Dominoplatten Gas+Induktion (z.B. Neff, ansonsten gute Auswahl versch. Hersteller)
- Gasherd (in Deutschland sehr mickrige Auswahl)
- Kombimicrowelle mit (Umluft)Backofen+Grill (für die Frühstückssemmeln und den kleinen Kuchen zwischendurch) - kommt gerade, der Markt ist noch etwas dünn
- Einbau-Kühlschrank, gross
- Einbau Tiefkühler, klein
- Spülmaschine, effizient (verstellbarer Oberkorb, Zeitvorwahl, Dreckspatz-Sensor...)
- Dunstabzugshaube Kopffrei, ca 900m^3/h (bei 1000 hört es dann praktisch auf, also nicht mal oberstes Ende, aber die offene Küche im Haus verlangt da etwas mehr Puste)
Alles für sich kein Problem, aber Küchenstudios bevorzugen immer ihre 2-3 Lieblingsanbieter und bei denen bekommt man das meist nicht kombiniert.
Wo möglich Energie-Effizienzklassen A++ (*ach*).
Bis hier her kann eventuell noch ein Küchenstudio mit viel gutem Willen (ich sag mal DanKüchen) mithalten.
Und jetzt kommt die Totschlag-Tatsache (Von Argument kann man nicht reden, weil nicht verhandelbar):
Meine Küche ist für die Standard-Elemente auf allen Seiten ca 2cm zu kurz! Zumindest bei meiner gewünschten Aufteilung. Das bemerken nicht mal die diversen Kunden-Klicky-Bunty-Küchenplaner. Das bemerkt man nur, wenn man die eingebaute Küche mal nachmisst und genau hinschaut. (Der Vorbesitzer hat einfach auf alle Abstandsregeln gepfiffen, eine Ikea-Küche genommen und an den entsprechenden Stellen die Holzblenden abgesägt.)
Es reicht, bei einigen Fronten die 2cm Überlapp für die Schöheit zu kürzen, dann geht es wieder. Namentlich die beiden Schubladenschränke an der schräg eingebauten Kochstelle, welche auch nicht ganz winklig ist, sondern ganz leicht schräg steht. Alternativ ginge es auch, die Schubladen selbst 3 cm schmäler zu machen... Und das macht kein Küchenstudio, weil die verkaufen genormte Fertigware.
Poff - das Leben ist grausam.
Falls also jemand einen creativen Schreiner kennt, der es schafft, solide Küchenstudioware und creative Schreinerarbeit zu verbinden: Hier ist ein Kunde der ziemlich genau sagen kann, was er will... bei der Umsetzung bin ich kompromissbereit, es muss nicht der Schrank von Hersteller XYZ sein, wenn auch Hersteller ABC etwas vergleichbares bietet.
Eine frustrierte neko
Es gibt alles das, was ich will, aber nie in einem Laden und aus einer Serie.
Was ich so Besonderes will? Keine Ahnung.
Teil1 - Optik - erfüllt jeder Laden:
- Front: ist mir egal, findet sich dann schon (soll hell sein, kein Lack, der ist bald ab
) - Glas: brauch ich nicht.
- Licht: bin ich flexibel, findet sich. Der Markt ist gross.
- Arbeitsplatte: Stabil, eventuell tauschbar, kein Stein - auch eher der harmlose Kundenwunsch.
Teil2 - Funktionen der Schränke - hier fliegen 99,9% aller Anbieter raus
- ich will Sockelschubladen. Die Beschlägehersteller Hettich, Blum und Grass bieten das an, nur die Küchenhersteller reichen das Angebot nicht weiter. Ausnahme: DanKüchen (leider nur ein Laden in München, braucht einen Nachtest, Test 1 war verheerend, hat aber wegen Wiesnzeit eine 2. Chance verdient)
Eigentlich sollte man ja annehmen, dass so Kandidaten wie Ikea (entdecke die Möglichkeiten, Platz- und Raumsparend, die Wände ausnutzend...) dieses Konzept mit Handkuss aufnehmen, aber die springen nicht drauf an.
- Ich will in den Oberschränken teilweise Apotheker-Artige Auszüge haben. In Schränken unterhalb der Augenlinie, kann man gut von oben reinschauen. Alles was drüber liegt, muss entweder erklettert/ertastet werden oder eben von unten einsehbar sein und da haben sich meine Apotheker: 30-40cm bewährt! Dumm nur, dass der Schrank drunter 60cm sein soll. Solche Kombinationen habe ich noch nirgends gesehen. Bei einem Beschlägehersteller habe ich nachträglich einbaubare Schub-Körbchen in Oberschränken gesehen, aber das machte keinen besonders stabilen Eindruck via PDF und die mechanische Lösung schien mehr Platz zu brauchen, als sie Nutzen bringt...
- Kochfläche in einer abgeschrägten Ecke. Sowas scheint aus der Mode gekommen zu sein....
- Der Rest ist nicht neu: Abfall-Sammelauszug, Ecklösung Unterschrank... Diverser Kleinkram halt, den haben sie wieder alle, ausser man will die tiefe Version, die den Sockel nutzt (wird angeboten, aber mal wieder eher nicht von den Küchenbauern).
- Die Mechaniken sollten allgemein stabil sein, Bluemotion (so nennt das Blum?) haben und an einer Stelle Klick-Tip (auch Blum-Speak - die anderen haben sowas auch, haben dem Baby nur andere Namen gegeben, aber Blum hat einen vollständigen PDF Katalog, die anderen nur fliegende Einzeldokumente im Web)
- eine Besonderheit: rechts und links der Kochstellen hätte ich gerne versenkbare Granitplatten als Topfuntersetzer. Hersteller: unbekannt. Gefunden bei: www.kuechen-werksverkauf.de -> Einbau-Granitfelder (wird mit einer Edelstahlwanne in der Arbeitsplatte versenkt, Stein kann zum putzen/ersetzen rausgenommen werden) - in Küchenstudios noch nie gesehen! Die verkaufen lieber fliegende Untersetzer.
- und noch etwas, was keiner zu wollen scheint - ausser mir: Ausnutzung der gesamten Tiefe. Was hilft es, wenn Schrank und Arbeitsplatten 70cm tief sind und dann in den Schränken Schubladen und Körbchen mit 50cm Tiefe stecken? (mal abgesehen davon, dass man dahinter dann gelegentlich lustige Dinge wieder findet.)
- die Besteckschubladen hätte ich beinahe vergessen: da passen in das Standardmodell Schublade locker zwei von rein - also bitte für mich eine Besteckschublade mit Innenschublade. Zwei Besteckkästen aufeinander gestellt geht zwar, ist aber nicht so wirklich praktisch.
Teil3 Elektrik/Elektronik&Co - auch hier wird es wieder dünn.
- Dominoplatten Gas+Induktion (z.B. Neff, ansonsten gute Auswahl versch. Hersteller)
- Gasherd (in Deutschland sehr mickrige Auswahl)
- Kombimicrowelle mit (Umluft)Backofen+Grill (für die Frühstückssemmeln und den kleinen Kuchen zwischendurch) - kommt gerade, der Markt ist noch etwas dünn
- Einbau-Kühlschrank, gross
- Einbau Tiefkühler, klein
- Spülmaschine, effizient (verstellbarer Oberkorb, Zeitvorwahl, Dreckspatz-Sensor...)
- Dunstabzugshaube Kopffrei, ca 900m^3/h (bei 1000 hört es dann praktisch auf, also nicht mal oberstes Ende, aber die offene Küche im Haus verlangt da etwas mehr Puste)
Alles für sich kein Problem, aber Küchenstudios bevorzugen immer ihre 2-3 Lieblingsanbieter und bei denen bekommt man das meist nicht kombiniert.
Wo möglich Energie-Effizienzklassen A++ (*ach*).
Bis hier her kann eventuell noch ein Küchenstudio mit viel gutem Willen (ich sag mal DanKüchen) mithalten.
Und jetzt kommt die Totschlag-Tatsache (Von Argument kann man nicht reden, weil nicht verhandelbar):
Meine Küche ist für die Standard-Elemente auf allen Seiten ca 2cm zu kurz! Zumindest bei meiner gewünschten Aufteilung. Das bemerken nicht mal die diversen Kunden-Klicky-Bunty-Küchenplaner. Das bemerkt man nur, wenn man die eingebaute Küche mal nachmisst und genau hinschaut. (Der Vorbesitzer hat einfach auf alle Abstandsregeln gepfiffen, eine Ikea-Küche genommen und an den entsprechenden Stellen die Holzblenden abgesägt.)
Es reicht, bei einigen Fronten die 2cm Überlapp für die Schöheit zu kürzen, dann geht es wieder. Namentlich die beiden Schubladenschränke an der schräg eingebauten Kochstelle, welche auch nicht ganz winklig ist, sondern ganz leicht schräg steht. Alternativ ginge es auch, die Schubladen selbst 3 cm schmäler zu machen... Und das macht kein Küchenstudio, weil die verkaufen genormte Fertigware.
Poff - das Leben ist grausam.
Falls also jemand einen creativen Schreiner kennt, der es schafft, solide Küchenstudioware und creative Schreinerarbeit zu verbinden: Hier ist ein Kunde der ziemlich genau sagen kann, was er will... bei der Umsetzung bin ich kompromissbereit, es muss nicht der Schrank von Hersteller XYZ sein, wenn auch Hersteller ABC etwas vergleichbares bietet.
Eine frustrierte neko
Sonntag, 19. April 2009
Projekte: neue Lebensmittel entdecken
Samstag, 18. April 2009
Couscous
...hat nichts mit Küsschen zu tun 
Danke an Nasim. Ich habe heute erfolgreich mein erstes Couscous-Gericht erstellt:
200g Couscous, 200ml Wasser, eine gute Prise Salz. Wasser und Salz zum kochen bringen, Couscous hinein, 2 Minuten leicht köcheln lassen. Vom Feuer nehmen, 2-3 Butterflocken dazu und mit einer Gabel verrühren und dabei auflockern.
Nebenbei einige rohe Würstel (spart das würzen, kann man natürlich auch selber machen: Hackfleisch würzen) in kleinen Kugeln aus ihrer Pelle holen und als Fleischbällchen in der Pfanne anbraten. Kurz rausnehmen und beiseite stellen.
1 fein geschnittene rote Zwiebel, eine Paprika, Schnittlauch, diverse Kräuter, Cumin in die noch heisse Pfanne geben, den Couscous dazu. Das Ganze kurz durchschwenken (das Fett der Fleischbällchen gibt noch etwas Geschmack ab). Die gebratenen Fleischbällchen wieder oben drauf und ab, auf den Tisch damit.
Schnell, einfach, lecker und für zwei nicht allzu hungrige Personen zu viel. Eine Portion für mich morgen Mittag ist noch übrig geblieben.
Das war ja einfach.
neko
Danke an Nasim. Ich habe heute erfolgreich mein erstes Couscous-Gericht erstellt:
200g Couscous, 200ml Wasser, eine gute Prise Salz. Wasser und Salz zum kochen bringen, Couscous hinein, 2 Minuten leicht köcheln lassen. Vom Feuer nehmen, 2-3 Butterflocken dazu und mit einer Gabel verrühren und dabei auflockern.
Nebenbei einige rohe Würstel (spart das würzen, kann man natürlich auch selber machen: Hackfleisch würzen) in kleinen Kugeln aus ihrer Pelle holen und als Fleischbällchen in der Pfanne anbraten. Kurz rausnehmen und beiseite stellen.
1 fein geschnittene rote Zwiebel, eine Paprika, Schnittlauch, diverse Kräuter, Cumin in die noch heisse Pfanne geben, den Couscous dazu. Das Ganze kurz durchschwenken (das Fett der Fleischbällchen gibt noch etwas Geschmack ab). Die gebratenen Fleischbällchen wieder oben drauf und ab, auf den Tisch damit.
Schnell, einfach, lecker und für zwei nicht allzu hungrige Personen zu viel. Eine Portion für mich morgen Mittag ist noch übrig geblieben.
Das war ja einfach.
neko
Mittwoch, 8. April 2009
SCO Unix, VMware und das Computermuseum
Hi,
machmal macht man ja Dinge, die nicht 100% rational erklärbar sind, aber man kann dann doch nicht aus seiner Haut, und so.
Wie der eine oder andere weiss, ist mein Arbeitsplatzrechner zu Hause ("das Ding mit Maus, Tastatur und Bildschirm dran") ein SCO Unix, genauer gesagt, ein SCO Open Server 3.0.
Installiert im März 1993(!). Ja, wirklich. Eine Betriebssystem-Installation, die seit über 16 Jahren stabil und ohne reinstall ausgekommen ist (und das ist gut, weil die Original-Boot-Diskette vermutlich nicht mehr lesbar ist, und ob mein aktueller Streamer die Original-Install-Bänder noch lesen kann, weiss ich auch nicht).
Natürlich ist die Hardware nicht ganz so alt - 1993 war das ein "echter" 386er mit 40 MHz und 16 Mbyte RAM, wurde dann mal zu einem 486 aufgerüstet (Asus SP3, das erste PCI-Mainboard auf dem Markt, signifikante Fehler in eigentlich jedem Chip auf dem Board) und später zu einem Pentium-200 (Tyan Tomcat-Board). Nach zwei Mainboard-Ausfällen aufgrund eines defekten Netzteils (grrr) ist inzwischen ein AMD K6-450 drin, mit gigantischen 384 Mbyte DRAM.
Die Platte wuchs von etwa 500 Mbyte (Fujitsu SCSI, 3.5" volle Bauhöhe, an einem Adaptec 1542B ISA-SCSI-Controller) zu meinem Traum: gespiegelte 2x 9Gbyte Ultra2-SCSI IBM an einem ICP/GDT Cache-RAID-Controller, PCI natürlich.
Die Graphikkarte entwickelte sich von einer Tseng ET4000 über eine MIRO S8 (die erste PCI-Graphikkarte auf dem Markt, S3 805 mit diskret aufgebauter PCI-Logik - volle Baulänge! - liegt hier im Museum noch rum) über eine Miro 20SV (S3 968) - wohlgemerkt: alle noch mit Original-SCO-Treibern! - zu einer Matrox MGA G450 mit einem selbst nach SCO portierten XFree86 3.3.6 (inklusive Kernel-Patch für mmap()-Unterstützung von PCI-Memory). Allerdings ohne Dual-Head, das geht erst ab XFree86 4.x und das war mir dann doch zu heftig.
Aktuelle Software ist auf dem System leider aus verschiedenen Gründen kaum noch zum Laufen zu bringen:
- kein Thread-Support im System
- keine unix sockets
- kein IPv6
- "kein Linux" (und ja, für heutige Software-Autoren ist das ein echtes Hindernis)
... weshalb ich seit Jahren den Firefox von Neko's Linux-Rechner per Remote-X11 verwende - tut prima, hat aber das Problem, dass der Rechner (AMD Athlon 900) auch gerade ausgemustert wird, und nachdem Neko inzwischen total verMACt ist, geht das damit nicht mehr.
Also: neuer Rechner, aktuelle Hardware (auf der das SCO nicht mehr booten würde, wegen "was ist das für ein Prozessor? was ist das für ein Bus? was ist das für eine Netzwerkkarte? *PANIK*"), Dual-Head-Graphikkarte, und so.
Aber gleichzeitig soll das venerable SCO natürlich weiterlaufen - und noch einen Rechner, der dauernd an ist, und Strom frisst, braucht's hier wirklich nicht.
Mit meinem Spielwindows habe ich es erfolgreich praktiziert, warum soll das nicht auch mit SCO gehen? Einfach virtualisieren. VMware workstation oder VMware server, "tut einfach".
Googeln gegangen: ja, es gibt Erfahrungsberichte, dass das geht (hier, hier oder insbes. hier). Dass es zwar mit Schmerzen verbunden ist (SCSI-Controller, Treiber, ...), aber es haben Leute erfolgreich hingekriegt. Allerdings nur mit OSR 5.0.<aktuell>, nicht mit 3.0 - welches wirklich ein paar Generationen älter ist.
Interessantes Tidbit am Rande: einer der SCO-Entwickler, mit dem ich früher viel zu tun hatte (Bela Lubkin), ist jetzt bei VMware und damit natürlich die Adresse für knifflige Fragen in diesem Zusammenhang. Bela hat sogar noch einen Account auf dem Rechner, um den es geht
Hier steht grad eh' ein Superduper-Server für einen Kunden, der da einen Teil seiner Altlasten (einen Windows-Server und ein SCO OpenServer 5.0.5) virtualisieren will. Xeon-Dual-Core, 2G RAM, schnelle Platten, damit macht das doch Spass
Unix-Platten "einfach so" in VMware-Disk-Images verwandeln geht nicht. Also:
Tja, wenn das mal alles so einfach wäre.
Der erste Teil ("SCO OSR 5.0.x installieren") hat verblüffend gut geklappt. Die Boot-Disketten waren alle noch lesbar, die Installation hat funktioniert, und meinen "free for private use"-License-Key aus der Zeit, wo SCO noch an "Leute verwenden unser Produkt!" interessiert war habe ich auch gefunden.
Netzwerk & die Einbindung der neuen Platte waren auch einfach, Fingerübung.
Die alte Platte mit "dd" kopieren war schon aufregender. Eigentlich war der Plan gut, aber ich vergass ein Detail: SCO ODT 3 hat keinerlei Support für Files grösser 2 Gbyte.
Das heisst:
# dd if=/dev/hd00 bs=512k | rsh neu dd of=/dev/hd10 bs=512k
hat zwar prima funktioniert, aber nur 2G von 9G kopiert, dann Abbruch mit Fehler.
Die wichtigen Sachen waren aber dabei (Partitionstabelle, Boot-Sektor, Root-Filesystem). Den Rest hab' ich dann halt Filesystem für Filesystem kopiert (SCO! es gibt Unix-Partitionen, und in diesen drin dann "divvy"-Slices, und da drin sind dann die Filesysteme) - statt einer Platte bzw. zwei Partitionen waren halt dann etwa 10 "dd...rsh..."-Aktionen nötig. Etwas nerviger als nötig, aber immer noch viel weniger Arbeit als "Partitionen und Filesystem von Hand anlegen und dann 10000e von kleinen Files per rsync kopieren" (was auf dem Zielrechner auch erstmal gar nicht drauf war, usw.)
So, dann also mal sehen...
... neue VM gebaut, besagte Platte als "primär" eingebaut, gebootet...
crash boom, Kernel Panic zu Besuch - klar, er findet sein Root-Filesystem nicht.
SCO Unix ist ein altes System, von dem die anderen gelernt und 10 Jahre verbessert haben - sprich: so nette Automatismen wie heute unter Linux "finde einfach die erste Platte im System und binde sie ein, und dann schau mal, wie weit Du kommst - und zur Not sagt man root=/dev/hda17 am Boot-Prompt" gab's halt nicht, die Zuordnung Devices<->Controller ist fest in den Kernel kompiliert.
Das war mir eigentlich klar, ich wollte auch nur sehen, ob's überhaupt zumindest den Kernel lädt - was es getan hat, also frisch ans Werk...
Die grundlegende Vorgehensweise war ganz klassisch, wie man das auch im Zweifel bei einem echten Problemrechner machen würde - nicht-bootende Festplatte in einen anderen Rechner einbauen, dort den Kernel fixen, dann wieder zurückbauen und testen. Bei VMware geht das natürlich einfacher, weil man einfach abwechselnd die SCO 5 und SCO 3 VM hochfahren kann.
In der SCO 5 VM (wo die SCO 3-Platte als "disk 1" dranhängt) kommt man dann mit
ziemlich schnell zu einem neuen Kernel. War natürlich trotzdem nicht so einfach, denn SCO 3 hat ab Werk keinen Treiber für den emulierten BusLogic PCI-SCSI-Controller, und der Treiber für SCO 5 (den da oben alle referenzieren) tut nicht, denn die interne PCI-Bus-Logik hat sich zwischen SCO 3 und SCO 5 dann doch geändert - es linkt nicht, mit einer klaren "hier geht's nicht weiter" Fehlermeldung:
... und das klang erstmal nicht gut. Also weitergesucht, und tatsächlich ein Treiberpaket für SCO 3.0 und BusLogic-Controller gefunden (auf der Mylex-Webseite, die BusLogic irgendwann mal gekauft haben). Das Paket bestand natürlich aus einem DOS-.exe, was dann eine Unix-BTLD-Diskette erstellt... gah. Aber mit einer Windows-XP VM, Samba und einem Floppy-Image in VMware ging das dann auch.
Installation in der SCO 3 chroot-Umgebung ("btldinstall /mnt", wohin vorher /dev/rfd0138ds18 gemounted war, in /etc/conf/cf.d/mscsi den Treiber für die erste Festplatte auf "blc" umstellen) hat auch geklappt, Kernel hat sich auch linken lassen, aber beim Booten trotzdem crash boom, kein SCSI-Controller gefunden.
Auf dem Weg noch ein paar kleinere Probleme gefunden:
Ging aber alles trotzdem nicht. Resümee: der SCO 3.0 blc-Treiber spielt nicht mit VMware-Buslogic-Controllern. (Bin grad noch dran, das Thema mit Bela zu diskutieren, weil "jetzt wollen wir's wissen" ).
Im alten System war im Lauf der Zeit so diverses drin - erstmal gar kein Netzwerk (1993? Ich bitte Euch, das war teuer! Und ich hatte auch nur einen Rechner...), dann eine günstig erstandene WD8013 aus einer Insolvenz (100 Mark für 2 Stück haben die damals gekostet, glaube ich - dafür war es eine 16-Bit-ISA-Karte mit BNC und 10BaseT und AUI!!), später dann mal eine DEC 21143-basierte 100Mbit-Karte (memory-leak im Kernel, ganz schlecht) und jetzt ist da so was billig-Realtek-basiertes drin, was 100Mbit spricht, einen SCO 3-Treiber mitbringt, und einfach funktioniert.
VMware bietet zwei verschiedene emulierte Netzwerkkarten an: eine AMD LANCE und eine Intel E1000 (1G). Und eine "pseudovirtualisierte", die natürlich einen Vmware-Treiber braucht (den es für Randgruppen-Betriebssysteme nicht gibt). Die 1G-Karte hat sicher auch keine Treiber für ein Betriebssystem aus der Zeit von 10 Mbit - also AMD. Oder aufgeben.
Erster Versuch: SCO's eigenes "netconfig" befragt. Nein, nichts, was auch nur annäherend nach AMD Lance aussieht.
Bei Intel geguckt, wegen e1000-Treiber - gibt's zwar für SCO, aber nur für SCO 5, was eine andere Netzwerkarchitektur als SCO 3 hat. Damit wird's nichts.
Also wieder Freund Google bemüht. Verschiedene erfolglose Treffer, aber bei einem Hersteller von AMD Lance-basierten Ethernetkarten tatsächlich fündig geworden - ein Treiberbundle, wo das zwar nicht draufstand, aber tatsächlich ein Treiber für SCO 5 und für SCO 3 drin war. Juhuu!
Die Installationsanleitung war auch, äh, interessant - ein Tarball, den man erstmal auspacken soll, und dann mit dem SCO-Tar (der ein wenig anders ist...) via tar cnv6 * auf (virtuelle) Diskette, dann mit custom installieren. Tja, wenn das mal so straightforward gewesen wäre - denn das SCO 3 hatte ja noch kein Netz, und das SCO 5 hat einen "tar", der Informationen über die directories mit speichert. Was den "tar" von SCO 3 zur Verzweiflung gebracht hat - weil er beim Auspacken den Directory-Eintrag von tmp/ gefunden hat, ein File namens tmp angelegt hat, und dann beim Auspacken des nächsten Files (tmp/perms/pnt.pre oder so) über das File namens tmp gestolpert ist...
Das hab' ich aber dann irgendwann hingebracht (unter SCO 3 mit "gtar" ausgepackt und mit dem
System-"tar" wieder eingepackt, dann waren nur noch Einträge für die Files da, nicht mehr für die Directory-Struktur).
SCO 3 wollte aber trotzdem nicht, weil custom auf /dev/install zugreift, was ein "autosense floppy device" ist, welches sich mit der virtuellen Floppy von VMware beisst. Nächster Versuch: custom -m /dev/fd0135ds18 - das ist wenigstens nicht mehr mit "tar: checksum error" gestorben, aber installiert hat es auch nicht - irgendein File hat gefehlt.
Eigentlich aber egal. So ein Installmedium besteht nur aus einem Tarball mit genau der Ziel-Verzeichnis-Struktur und ein paar Files in /tmp (Permissions, Pre-Install-Script, ...) - das kann man auch einfach von Hand draufballern.
Gesagt, getan, netconfig aufgerufen, pnt-Treiber ausgewählt (andere IP-Adresse konfiguriert, natürlich), und siehe da...
... es netzt (das sind die Bootmeldungen mit der erkannten Hardware, die Zeile mit %pnt und Ethernet ist die spannende).
Was jetzt nicht geht, ist X11. Das pack' ich evtl. noch an, wenn ich mal viel Zeit habe, aber es wird hochgradig knifflig...
... denn:
Also wenn mal jemand langweilig ist, und er ganz dringend graue Haare braucht, schick' ich ihm meine VM...
(SCO 5 kann es übrigens, das bringt einen Vesa-VGA-Treiber mit - das ist zwar mit der emulierten Busmaus vom VMware nicht wirklich 100% glücklich, aber für die Dinge, wo man wirklich X11 braucht, reicht's)
Sinnlos war's schon, aber es hat grossen Spass gemacht. Alte Unixe bringen manchmal eine Befriedigung, die so ein Vollkasko-Linux einfach nicht bringt - da tut's einfach "ab Werk" (im Zweifel), oder es haben schon 100 andere das Problem gehabt und Googlen bringt sofort die Lösung...
machmal macht man ja Dinge, die nicht 100% rational erklärbar sind, aber man kann dann doch nicht aus seiner Haut, und so.
Wie der eine oder andere weiss, ist mein Arbeitsplatzrechner zu Hause ("das Ding mit Maus, Tastatur und Bildschirm dran") ein SCO Unix, genauer gesagt, ein SCO Open Server 3.0.
Installiert im März 1993(!). Ja, wirklich. Eine Betriebssystem-Installation, die seit über 16 Jahren stabil und ohne reinstall ausgekommen ist (und das ist gut, weil die Original-Boot-Diskette vermutlich nicht mehr lesbar ist, und ob mein aktueller Streamer die Original-Install-Bänder noch lesen kann, weiss ich auch nicht).
Natürlich ist die Hardware nicht ganz so alt - 1993 war das ein "echter" 386er mit 40 MHz und 16 Mbyte RAM, wurde dann mal zu einem 486 aufgerüstet (Asus SP3, das erste PCI-Mainboard auf dem Markt, signifikante Fehler in eigentlich jedem Chip auf dem Board) und später zu einem Pentium-200 (Tyan Tomcat-Board). Nach zwei Mainboard-Ausfällen aufgrund eines defekten Netzteils (grrr) ist inzwischen ein AMD K6-450 drin, mit gigantischen 384 Mbyte DRAM.
Die Platte wuchs von etwa 500 Mbyte (Fujitsu SCSI, 3.5" volle Bauhöhe, an einem Adaptec 1542B ISA-SCSI-Controller) zu meinem Traum: gespiegelte 2x 9Gbyte Ultra2-SCSI IBM an einem ICP/GDT Cache-RAID-Controller, PCI natürlich.
Die Graphikkarte entwickelte sich von einer Tseng ET4000 über eine MIRO S8 (die erste PCI-Graphikkarte auf dem Markt, S3 805 mit diskret aufgebauter PCI-Logik - volle Baulänge! - liegt hier im Museum noch rum) über eine Miro 20SV (S3 968) - wohlgemerkt: alle noch mit Original-SCO-Treibern! - zu einer Matrox MGA G450 mit einem selbst nach SCO portierten XFree86 3.3.6 (inklusive Kernel-Patch für mmap()-Unterstützung von PCI-Memory). Allerdings ohne Dual-Head, das geht erst ab XFree86 4.x und das war mir dann doch zu heftig.
Aktuelle Software ist auf dem System leider aus verschiedenen Gründen kaum noch zum Laufen zu bringen:
- kein Thread-Support im System
- keine unix sockets
- kein IPv6
- "kein Linux" (und ja, für heutige Software-Autoren ist das ein echtes Hindernis)
... weshalb ich seit Jahren den Firefox von Neko's Linux-Rechner per Remote-X11 verwende - tut prima, hat aber das Problem, dass der Rechner (AMD Athlon 900) auch gerade ausgemustert wird, und nachdem Neko inzwischen total verMACt ist, geht das damit nicht mehr.
Also: neuer Rechner, aktuelle Hardware (auf der das SCO nicht mehr booten würde, wegen "was ist das für ein Prozessor? was ist das für ein Bus? was ist das für eine Netzwerkkarte? *PANIK*"), Dual-Head-Graphikkarte, und so.
Aber gleichzeitig soll das venerable SCO natürlich weiterlaufen - und noch einen Rechner, der dauernd an ist, und Strom frisst, braucht's hier wirklich nicht.
Die Idee
Mit meinem Spielwindows habe ich es erfolgreich praktiziert, warum soll das nicht auch mit SCO gehen? Einfach virtualisieren. VMware workstation oder VMware server, "tut einfach".
Googeln gegangen: ja, es gibt Erfahrungsberichte, dass das geht (hier, hier oder insbes. hier). Dass es zwar mit Schmerzen verbunden ist (SCSI-Controller, Treiber, ...), aber es haben Leute erfolgreich hingekriegt. Allerdings nur mit OSR 5.0.<aktuell>, nicht mit 3.0 - welches wirklich ein paar Generationen älter ist.
Interessantes Tidbit am Rande: einer der SCO-Entwickler, mit dem ich früher viel zu tun hatte (Bela Lubkin), ist jetzt bei VMware und damit natürlich die Adresse für knifflige Fragen in diesem Zusammenhang. Bela hat sogar noch einen Account auf dem Rechner, um den es geht
Der Plan
Hier steht grad eh' ein Superduper-Server für einen Kunden, der da einen Teil seiner Altlasten (einen Windows-Server und ein SCO OpenServer 5.0.5) virtualisieren will. Xeon-Dual-Core, 2G RAM, schnelle Platten, damit macht das doch Spass
Unix-Platten "einfach so" in VMware-Disk-Images verwandeln geht nicht. Also:
- in einer VM ein SCO 5.0.x installieren, Install-Medien liegen hier eh noch rum
- in dieser VM eine zusätzliche Festplatte einbinden, etwas grösser als auf dem alten System
- via "dd" das System blockweise rüberkopieren (über Netz vom laufenden System in die VM/disk1)
- die zusätzliche Festplatte als primäre Platte einer neuen VM einbinden
- booten, freuen, Treiber für Netzwerk, X11, usw. fixen
Die Umsetzung, und die lustigen Probleme
Tja, wenn das mal alles so einfach wäre.
Der erste Teil ("SCO OSR 5.0.x installieren") hat verblüffend gut geklappt. Die Boot-Disketten waren alle noch lesbar, die Installation hat funktioniert, und meinen "free for private use"-License-Key aus der Zeit, wo SCO noch an "Leute verwenden unser Produkt!" interessiert war habe ich auch gefunden.
Netzwerk & die Einbindung der neuen Platte waren auch einfach, Fingerübung.
Die alte Platte mit "dd" kopieren war schon aufregender. Eigentlich war der Plan gut, aber ich vergass ein Detail: SCO ODT 3 hat keinerlei Support für Files grösser 2 Gbyte.
Das heisst:
# dd if=/dev/hd00 bs=512k | rsh neu dd of=/dev/hd10 bs=512k
hat zwar prima funktioniert, aber nur 2G von 9G kopiert, dann Abbruch mit Fehler.
Die wichtigen Sachen waren aber dabei (Partitionstabelle, Boot-Sektor, Root-Filesystem). Den Rest hab' ich dann halt Filesystem für Filesystem kopiert (SCO! es gibt Unix-Partitionen, und in diesen drin dann "divvy"-Slices, und da drin sind dann die Filesysteme) - statt einer Platte bzw. zwei Partitionen waren halt dann etwa 10 "dd...rsh..."-Aktionen nötig. Etwas nerviger als nötig, aber immer noch viel weniger Arbeit als "Partitionen und Filesystem von Hand anlegen und dann 10000e von kleinen Files per rsync kopieren" (was auf dem Zielrechner auch erstmal gar nicht drauf war, usw.)
So, dann also mal sehen...
... neue VM gebaut, besagte Platte als "primär" eingebaut, gebootet...
crash boom, Kernel Panic zu Besuch - klar, er findet sein Root-Filesystem nicht.
SCO Unix ist ein altes System, von dem die anderen gelernt und 10 Jahre verbessert haben - sprich: so nette Automatismen wie heute unter Linux "finde einfach die erste Platte im System und binde sie ein, und dann schau mal, wie weit Du kommst - und zur Not sagt man root=/dev/hda17 am Boot-Prompt" gab's halt nicht, die Zuordnung Devices<->Controller ist fest in den Kernel kompiliert.
Das war mir eigentlich klar, ich wollte auch nur sehen, ob's überhaupt zumindest den Kernel lädt - was es getan hat, also frisch ans Werk...
... die Device-Treiber und die Boot-Festplatte
Die grundlegende Vorgehensweise war ganz klassisch, wie man das auch im Zweifel bei einem echten Problemrechner machen würde - nicht-bootende Festplatte in einen anderen Rechner einbauen, dort den Kernel fixen, dann wieder zurückbauen und testen. Bei VMware geht das natürlich einfacher, weil man einfach abwechselnd die SCO 5 und SCO 3 VM hochfahren kann.
In der SCO 5 VM (wo die SCO 3-Platte als "disk 1" dranhängt) kommt man dann mit
# mount /dev/i1.root /mnt
# chroot /mnt /bin/sh
# cd /etc/conf/cf.d
# <kernelconfig verfummeln>
# ./link_unix
# exit
# umount /mnt
# init 0
ziemlich schnell zu einem neuen Kernel. War natürlich trotzdem nicht so einfach, denn SCO 3 hat ab Werk keinen Treiber für den emulierten BusLogic PCI-SCSI-Controller, und der Treiber für SCO 5 (den da oben alle referenzieren) tut nicht, denn die interne PCI-Bus-Logik hat sich zwischen SCO 3 und SCO 5 dann doch geändert - es linkt nicht, mit einer klaren "hier geht's nicht weiter" Fehlermeldung:
undefined first referenced
symbol in file
pci_readbyte /etc/conf/pack.d/blc/Driver.o
pci_finddevice /etc/conf/pack.d/blc/Driver.o
pci_readword /etc/conf/pack.d/blc/Driver.o
... und das klang erstmal nicht gut. Also weitergesucht, und tatsächlich ein Treiberpaket für SCO 3.0 und BusLogic-Controller gefunden (auf der Mylex-Webseite, die BusLogic irgendwann mal gekauft haben). Das Paket bestand natürlich aus einem DOS-.exe, was dann eine Unix-BTLD-Diskette erstellt... gah. Aber mit einer Windows-XP VM, Samba und einem Floppy-Image in VMware ging das dann auch.
Installation in der SCO 3 chroot-Umgebung ("btldinstall /mnt", wohin vorher /dev/rfd0138ds18 gemounted war, in /etc/conf/cf.d/mscsi den Treiber für die erste Festplatte auf "blc" umstellen) hat auch geklappt, Kernel hat sich auch linken lassen, aber beim Booten trotzdem crash boom, kein SCSI-Controller gefunden.
Auf dem Weg noch ein paar kleinere Probleme gefunden:
- In der SCO 5.0-VM hatte ich "snapshots" aktiviert, damit sind die Änderungen an der SCO 3.0-Platte nicht auf die Platte geschrieben worden, und die neuen Kernel sind gar nicht erst angekommen (lösbar, snapshots abschalten)
- Aus irgendwelchen widrigen Gründen war die "SCSI"-Festplatte für die SCO 3.0-VM im VMware kein SCSI mehr, sondern IDE (lösbar, im .vmdk-File von controller="ide" auf controller="buslogic" umstellen - mit einer Linux-Boot-CD verifiziert: jetzt SCSI!)
Ging aber alles trotzdem nicht. Resümee: der SCO 3.0 blc-Treiber spielt nicht mit VMware-Buslogic-Controllern. (Bin grad noch dran, das Thema mit Bela zu diskutieren, weil "jetzt wollen wir's wissen"
).
Mmmh, was nun. IDE disks?
Bei einer Neuinstallation ist das kein (grosses) Problem, nachdem IDE ja "wd1003" kompatibel sind, und dieser Controller alt genug ist, dass SCO ihn wirklich unterstützt (mein erstes SCO wurde noch auf einer echten MFM-Platte an einem WD1006 installiert). Schwierig ist die Umstellung.
Einen anderen SCSI-Treiber zu verwenden ist ganz einfach - den neuen Treiber installieren (legt einen Haufen Zeug in /etc/conf/{pack.d,sdevice.d,...} ab), in /etc/conf/cf.d/mscsi die Zuordnung Platte<->Treiber anpassen, neuen Kernel bauen, rebooten, gut ist.
Das Problem mit dem IDE-Support ist aber, dass der bei SCO nicht als "SCSI"-Treiber läuft, und sich mit den normalen Bordmitteln für "mach mir einen neuen Controller / eine neue Platte" (mkdev hd) nicht um eine IDE-Platte erweitern lässt - das System sagt "wenn ich jetzt ein SCSI-System bin, wäre ich beim nächsten Booten ein IDE-System (Reihenfolge im System), und deshalb supporte ich diesen Prozess nicht".
Egal. Grosser Hammer, und nachher die Scherben richten
In /etc/conf/cf.d/mscsi erstmal dem SCSI-Subsystem alle Geräte weggenommen, und in /etc/conf/sdevice.d/$treiber die ganzen SCSI-Treiber abgeschaltet. Dann in /etc/conf/sdevice.d/wd den generischen WD-Treiber aktiviert (erste Spalte auf "Y"), festgestellt, es reicht nicht, und die "Instanzen 0 und 1" (.../sdevice.d/wd0 und .../wd1) auch aktiviert. Das ist bei SCO 5 anders, da gibt es nur einen Treiber "wd", der sich um alle Controller und die Platten kümmert.
Also, neuen Kernel als Boot-Kernel abgelegt, SCO 5 VM runtergefahren, die Platte wieder auf controller="ide" umgestellt (jetzt soll sie ja eine IDE-Platte sein), frohgemut die SCO 3 VM gebootet, und... bah... crash boom. Die Disk-Geometrie gefällt ihm nicht, und der SCO 3 "wd"-Treiber kann auch keine Platten grösser als 8 Gbyte - wir haben hier 9...
Jetzt war's aber einfach, denn der "proof of concept" ist erbracht. Also zwei IDE-VM-Disks mit jeweils 5G angelegt, die zwei Unix-Partitionen mit ihren ganzen Filesystemen von der 9G-Platte rüber-dd-t (also genauer: die Partitionen angelegt, die Filesysteme in "exakt gleich gross" angelegt, dann die Filesysteme dd't - es ist einfach schneller als rsync).
... und siehe da...
... es tut!!!
SCO 3.0 erfolgreich VMisiert!
... Netzwerk?
Im alten System war im Lauf der Zeit so diverses drin - erstmal gar kein Netzwerk (1993? Ich bitte Euch, das war teuer! Und ich hatte auch nur einen Rechner...), dann eine günstig erstandene WD8013 aus einer Insolvenz (100 Mark für 2 Stück haben die damals gekostet, glaube ich - dafür war es eine 16-Bit-ISA-Karte mit BNC und 10BaseT und AUI!!), später dann mal eine DEC 21143-basierte 100Mbit-Karte (memory-leak im Kernel, ganz schlecht) und jetzt ist da so was billig-Realtek-basiertes drin, was 100Mbit spricht, einen SCO 3-Treiber mitbringt, und einfach funktioniert.
VMware bietet zwei verschiedene emulierte Netzwerkkarten an: eine AMD LANCE und eine Intel E1000 (1G). Und eine "pseudovirtualisierte", die natürlich einen Vmware-Treiber braucht (den es für Randgruppen-Betriebssysteme nicht gibt). Die 1G-Karte hat sicher auch keine Treiber für ein Betriebssystem aus der Zeit von 10 Mbit
- also AMD. Oder aufgeben.Erster Versuch: SCO's eigenes "netconfig" befragt. Nein, nichts, was auch nur annäherend nach AMD Lance aussieht.
Bei Intel geguckt, wegen e1000-Treiber - gibt's zwar für SCO, aber nur für SCO 5, was eine andere Netzwerkarchitektur als SCO 3 hat. Damit wird's nichts.
Also wieder Freund Google bemüht. Verschiedene erfolglose Treffer, aber bei einem Hersteller von AMD Lance-basierten Ethernetkarten tatsächlich fündig geworden - ein Treiberbundle, wo das zwar nicht draufstand, aber tatsächlich ein Treiber für SCO 5 und für SCO 3 drin war. Juhuu!
Die Installationsanleitung war auch, äh, interessant - ein Tarball, den man erstmal auspacken soll, und dann mit dem SCO-Tar (der ein wenig anders ist...) via tar cnv6 * auf (virtuelle) Diskette, dann mit custom installieren. Tja, wenn das mal so straightforward gewesen wäre - denn das SCO 3 hatte ja noch kein Netz, und das SCO 5 hat einen "tar", der Informationen über die directories mit speichert. Was den "tar" von SCO 3 zur Verzweiflung gebracht hat - weil er beim Auspacken den Directory-Eintrag von tmp/ gefunden hat, ein File namens tmp angelegt hat, und dann beim Auspacken des nächsten Files (tmp/perms/pnt.pre oder so) über das File namens tmp gestolpert ist...
Das hab' ich aber dann irgendwann hingebracht (unter SCO 3 mit "gtar" ausgepackt und mit dem
System-"tar" wieder eingepackt, dann waren nur noch Einträge für die Files da, nicht mehr für die Directory-Struktur).
SCO 3 wollte aber trotzdem nicht, weil custom auf /dev/install zugreift, was ein "autosense floppy device" ist, welches sich mit der virtuellen Floppy von VMware beisst. Nächster Versuch: custom -m /dev/fd0135ds18 - das ist wenigstens nicht mehr mit "tar: checksum error" gestorben, aber installiert hat es auch nicht - irgendein File hat gefehlt.
Eigentlich aber egal. So ein Installmedium besteht nur aus einem Tarball mit genau der Ziel-Verzeichnis-Struktur und ein paar Files in /tmp (Permissions, Pre-Install-Script, ...) - das kann man auch einfach von Hand draufballern.
Gesagt, getan, netconfig aufgerufen, pnt-Treiber ausgewählt (andere IP-Adresse konfiguriert, natürlich), und siehe da...
Ein passender Treiber!
... es netzt (das sind die Bootmeldungen mit der erkannten Hardware, die Zeile mit %pnt und Ethernet ist die spannende).
X11?
Was jetzt nicht geht, ist X11. Das pack' ich evtl. noch an, wenn ich mal viel Zeit habe, aber es wird hochgradig knifflig...
... denn:
- VGA spezifiziert als Auflösungen nur 640x480 mit 16 Farben (kann XFree gar nicht) oder 320x200 mit 256 Farben (das funktioniert sogar, ist aber hinreichend sinnlos)
- wenn man aus einer "VGA"-Karte mehr rausholen will, muss man wissen, was das für ein Chipsatz ist und wie man da die Auflösungen umstellt
- VMware emuliert eine "generische" VGA-Karte, d.h. der XServer findet keinen "bekannten" Chipsatz
- XOrg in "aktuell" verwendet in diesem Fall einen VESA-Bios-Aufruf zur Umstellung der Auflösung und danach den generischen VGA-Treiber fürs Pixel-Schubsen - das tut, ist auch (dafür) ausreichend performant, aber...
- ... das kann "mein" XFree86 3.3.6 natürlich noch nicht, ich müsste also noch ein aktuelles XOrg portieren, und das setzt im Zweifelsfall Kernel-Infrastruktur voraus (fürs Vesa-Bios), die einfach nicht da ist.
Also wenn mal jemand langweilig ist, und er ganz dringend graue Haare braucht, schick' ich ihm meine VM...
(SCO 5 kann es übrigens, das bringt einen Vesa-VGA-Treiber mit - das ist zwar mit der emulierten Busmaus vom VMware nicht wirklich 100% glücklich, aber für die Dinge, wo man wirklich X11 braucht, reicht's)
Resumee
Sinnlos war's schon, aber es hat grossen Spass gemacht. Alte Unixe bringen manchmal eine Befriedigung, die so ein Vollkasko-Linux einfach nicht bringt - da tut's einfach "ab Werk" (im Zweifel), oder es haben schon 100 andere das Problem gehabt und Googlen bringt sofort die Lösung...
Dienstag, 31. März 2009
Windows XP und IPv6, manuell konfiguriert
Erstaunlicherweise tut das einfach...
> netsh interface ipv6 install
OK.
> netsh interface ipv6 show int
...
(aha, es heisst "LAN-Verbindung")
> netsh interface ipv6 add address LAN-Verbindung 2001:608:8003::dead
OK.
(huch? einfach so? Windows, ohne Widerspruch??)
Also noch ein paar Routen:
> netsh interface ipv6 add route 2001:608:8003::/64 LAN-Verbindung
> netsh interface ipv6 add route 0::0/0 LAN-Verbindung 2001:608:8003::1
... *geht*.
Sagenhaft
Hintergrund des Problems: $hier im Netz gibt's IPv6, aber es wird nicht autoconft, weil hier ein paar Vista-Rechner sind, auf denen Java-Entwickler entwicklern. Und solange die nicht ausdruecklich "wir brauchen das jetzt, $Kunde fragt" zu dem Thema sagen, zieh ich mir den Schuh "Du hast IPv6 angemacht und seitdem geht mein Netz nicht mehr!!" nicht an. Ich will aber natuerlich auch auf meinem Spiel-und-Test-XP IPv6, also statisch... mein NetBSD macht das schon lang und problemlos.
> netsh interface ipv6 install
OK.
> netsh interface ipv6 show int
...
(aha, es heisst "LAN-Verbindung")
> netsh interface ipv6 add address LAN-Verbindung 2001:608:8003::dead
OK.
(huch? einfach so? Windows, ohne Widerspruch??)
Also noch ein paar Routen:
> netsh interface ipv6 add route 2001:608:8003::/64 LAN-Verbindung
> netsh interface ipv6 add route 0::0/0 LAN-Verbindung 2001:608:8003::1
... *geht*.
Sagenhaft
Hintergrund des Problems: $hier im Netz gibt's IPv6, aber es wird nicht autoconft, weil hier ein paar Vista-Rechner sind, auf denen Java-Entwickler entwicklern. Und solange die nicht ausdruecklich "wir brauchen das jetzt, $Kunde fragt" zu dem Thema sagen, zieh ich mir den Schuh "Du hast IPv6 angemacht und seitdem geht mein Netz nicht mehr!!" nicht an. Ich will aber natuerlich auch auf meinem Spiel-und-Test-XP IPv6, also statisch... mein NetBSD macht das schon lang und problemlos.
Sonntag, 29. März 2009
*haps* das Kreuz mit dem TAG
Mittwoch, 11. März 2009
Computer und Telefax = lustige Probleme
Sonntag, 22. Februar 2009
127.0.0.1
Freitag, 20. Februar 2009
IPv6 und SSL suckt...
Hoi,
also die Kombination aus "IPv6 und SSL und Apache" suckt irgendwie... man muss alles doppelt eintragen, weil man den SSL-Vhost natürlich nicht mit "*:443" definieren kann (sofern man mehr als einen SSL-Vhost laufen hat), und dann wird die Konfiguration lang und unhandlich... und wenn man dann evtl. auch noch SSL und nicht-SSL will (oder zumindest für nicht-SSL einen redirect, statt einer Fehlermeldung) ist es endgültig vorbei
Listen 195.30.8.32:80
Listen [2001:608:0:1007::32]:80
Listen 195.30.8.32:443
Listen [2001:608:0:1007::32]:443
<VirtualHost *:80>
ServerName planlosi.de
...
</VirtualHost>
<VirtualHost 195.30.8.32:443>
ServerName planlosi.de:443
SSLEngine on
SSLCertificateFile ...
...
</VirtualHost>
<VirtualHost [2001:608:0:1007::32]:443>
# und nochmal das ganze Gesums, wenn man nicht dafür jetzt ein Include definiert
</VirtualHost>
... aber jetzt hat planlosi.de auch SSL, was für "wir sind unterwegs und wollen was bloggen" schon irgendwie netter ist als "einfach so über plain HTTP authentisieren".
gert,
für ein IPv6-only Internet "rettet die Apache-Configs!"
also die Kombination aus "IPv6 und SSL und Apache" suckt irgendwie... man muss alles doppelt eintragen, weil man den SSL-Vhost natürlich nicht mit "*:443" definieren kann (sofern man mehr als einen SSL-Vhost laufen hat), und dann wird die Konfiguration lang und unhandlich... und wenn man dann evtl. auch noch SSL und nicht-SSL will (oder zumindest für nicht-SSL einen redirect, statt einer Fehlermeldung) ist es endgültig vorbei
Listen 195.30.8.32:80
Listen [2001:608:0:1007::32]:80
Listen 195.30.8.32:443
Listen [2001:608:0:1007::32]:443
<VirtualHost *:80>
ServerName planlosi.de
...
</VirtualHost>
<VirtualHost 195.30.8.32:443>
ServerName planlosi.de:443
SSLEngine on
SSLCertificateFile ...
...
</VirtualHost>
<VirtualHost [2001:608:0:1007::32]:443>
# und nochmal das ganze Gesums, wenn man nicht dafür jetzt ein Include definiert
</VirtualHost>
... aber jetzt hat planlosi.de auch SSL, was für "wir sind unterwegs und wollen was bloggen" schon irgendwie netter ist als "einfach so über plain HTTP authentisieren".
gert,
für ein IPv6-only Internet "rettet die Apache-Configs!"
Montag, 16. Februar 2009
Ebay hat ein neues Spiel... Teil2
Dienstag, 10. Februar 2009
Redundanz und Load-Sharing, anschaulich erklärt
Hoi,
in bester Tradition von Dyfas Loadbanana habe ich hier ein schönes Bild zur Erklärung "was ist eigentlich Load-Sharing" bzw. "was ist ein redundantes Setup, was beim Ausfall einer Komponente noch funktioniert"
Spricht eigentlich für sich, oder?
(Quelle: Sheraton-Hotel in Riad, Saudi-Arabien - sehr nettes Hotel übrigens ).
Load-Sharing und Failover!
Spricht eigentlich für sich, oder?
(Quelle: Sheraton-Hotel in Riad, Saudi-Arabien - sehr nettes Hotel übrigens
).
Montag, 9. Februar 2009
Ebay hat ein neues Spiel...
Versuch: Ebay Sofortkauf (Artikel? Seid nicht so neugierig!)
Gefunden:
1. Button: Sofort-kaufen (bekannt)
2. Button: Preis vorschlagen
Den musste ich ausprobieren 100% Spieltrieb (proforma 13.99 auf 12.00 versucht 'runterzuhandeln').
Der Verkäufer hat jetzt 48h Zeit zuzusagen oder abzusagen.
Ich bin gespannt!
Gefunden:
1. Button: Sofort-kaufen (bekannt)
2. Button: Preis vorschlagen
Den musste ich ausprobieren
100% Spieltrieb (proforma 13.99 auf 12.00 versucht 'runterzuhandeln').Der Verkäufer hat jetzt 48h Zeit zuzusagen oder abzusagen.
Ich bin gespannt!
Samstag, 7. Februar 2009
Strom am Flughafen!
Moin,
in den letzten Jahren galt es an den Flughäfen ja als "schick", dass man die Dinge des täglichen Lebens nicht sieht - insbesondere "keine offen sichtbaren Steckdosen".
Als Viel-Laptop-Herumflieger hat man irgendwann einen gewissen Blick dafür, wo wohl die Steckdose für die Putzteams (Bodenwischmaschinen, Staubsauger, ...) sein wird, aber die sind dann oft weit von der nächsten Sitzgelegenheit entfernt, also auch unpraktisch.
Um so größer die Überraschung gestern am Münchner Flughafen, Terminal 2 - ein deutliches Hinweisschild an der Wand "Here be Powa!"
... gefreut, suchen gegangen...
... weiter gesucht...
... aus dem Fussboden kommendes Kabel gefunden, was im Kabelschacht verschwindet...
... komisch, hier muß doch irgendwo...
Oh ja, tatsächlich. Gut versteckt, und nur zu finden, wenn man wirklich danach sucht (und dabei vermutlich ein recht sonderbares Bild abgibt...). Aber so positioniert, daß man von den Sitzen - zumindest von denen relativ nah am Fenster - gut drankommt. Wunder dieser Welt!
in den letzten Jahren galt es an den Flughäfen ja als "schick", dass man die Dinge des täglichen Lebens nicht sieht - insbesondere "keine offen sichtbaren Steckdosen".
Als Viel-Laptop-Herumflieger hat man irgendwann einen gewissen Blick dafür, wo wohl die Steckdose für die Putzteams (Bodenwischmaschinen, Staubsauger, ...) sein wird, aber die sind dann oft weit von der nächsten Sitzgelegenheit entfernt, also auch unpraktisch.
Strom!
... gefreut, suchen gegangen...
... weiter gesucht...
... aus dem Fussboden kommendes Kabel gefunden, was im Kabelschacht verschwindet...
... komisch, hier muß doch irgendwo...
Komisches Kabel
gut versteckt
