Altes Notebook, neues Leben

Publiziert am 4. April 2023 von dieter

Ich kaufe immer die leistungsfähigsten Notebooks, die gerade zu bekommen sind – und nutze sie dann jahrelang. Ich könnte mich mit einer vorbildlichen Nachhaltigkeit rühmen, aber tatsächlich ist mir der Austausch der Hardware immer eine Qual, ich nutze die Systeme also immer so lange, bis das aktuelle Windows signifikant langsam wird. Auch bei der Windows-Version bin ich eher konservativ, Stand heute (3.4.2023) sind alle Systeme auf dem neuesten Windows-10-Stand, Windows 11 ist bisher nur auf einem Testsystem im Einsatz.

Trotzdem fallen mit der Zeit immer wieder Notebooks an, die für das wuchernde Windows nicht mehr geeignet sind. Da die Rechner aber technisch noch nicht reif für die Verwertung sind, stellt sich die Frage, was man mit ihnen anfangen könnte.

Da kommt dann sehr schnell Linux ins Spiel. Da alle Server entweder unter OpenVMS 8.4 (auf den Digital Alpha DS15) oder als ESX-Clients mit Debian 12 auf IBM-/Lenovo-Server laufen, war die Wahl des Linux-Derivats klar. Zugleich bot es sich an, es auch gleich mit freien Alternativen zu den inzwischen doch recht teuer gewordenen Produkten wie Office 365 oder der Adobe-Suite zu versuchen.

Als Basis für den Versuch habe das alte Notebook meiner Frau, ausgestattet mit einem AMD-E-450Prozessor, 6GB Hauptspeicher , HDI- und VGA-Ausgang, 3 USB-2.0-Anschlüssen, Ethernet, WLAN und einer 240GB SSD,die wir schon zu Windows-Zeiten zur Leistungsverbesserungen eingebaut hatten. Der Bildschirm löst 1366×768 auf. Insgesamt also für seine Zeit eher ein gut ausgestattetes System, das allerdings unter Windows 10 schon erschreckend langsam lief.

Die Debian-Installation ist einfach, besonders, wenn man ohnehin schon einige Systeme in Betrieb und daher auch Erfahrung hat. Alle Hardwarekomponenten, die Grafikkarte, die Bildschirmauflösung werden einwandfrei erkannt, die Netzwerkverbindung sowohl über den Ethernet-Port wie auch über WLAN zuverlässig aufgebaut.

Als Software-Komponenten habe ich installiert:

  • Libreoffice als Ersatz für Microsoft Office
  • GIMP als Ersatz für Adobe Photoshop
  • Scribus statt Adobe Indesign
  • Darktable statt Adobe Lightroom
  • Freeplane ersetzt Mindmap
  • Draw.Io statt MS Visio.
  • Blender als Ersatz für Adobe Premiere (wobei Blender eigentlich eher Maja ersetzt)

Weitere Software-Pakete aus der Welt der freien Verfügbarkeiten:

  • Skype
  • Thunderbird als Email-Client
  • Keepath
  • Nextcloud-Client zum Zugriff auf meine eigene Cloud
  • Audacity für die Digitalisierung von Audioquellen
  • Filezilla für den FTP-Zugriff auf die OpenVMS-Server

Dazu meine persönlichen Präferenzen:

  • Emacs als leistungsfähiger Editor
  • Remmina für den Fernzugriff auf Xrdp-Systeme (Remote Desktop)

Das einzige Kaufprodukt, das installiert ist, ist NordVPN.

Fazit:

Das installierte System ist mit allen Zusatz-Softwarepaketen immer noch deutlich schlanker als ein Windows nach der Erstinstallation, und es startet deutlich schneller.

Die Ersatz-Software, bietet für mich die gleiche Funktionalität wie die Kaufprodukte (wobei ich sicher beide nicht bis aufs Letzte ausreize). Allerdings erfordert der Umstieg einiges an Eingewöhnung, da Funktionen oft anders benannt sind, anders parametrisiert werden und sich in anderen Menüs verstecken. Nach einer gewissen Eingewöhnungszeit sollte das aber kein Problem mehr darstellen.

Alle Daten ließen sich problemlos im- und exportieren, ein Austausch mit Microsoft-Nutzers z.B. war mit den Dateien, die ich so produziert habe, kein Problem. Als erweiterten Test habe ich diese Produkte auch sowohl auf einem Windows-Testsystem als auch auf einem Mac Mini installiert, auch da gab es keine Probleme, damit kann man also ohne Lizenzprobleme saubere nutzbare Systeme auf beiden Plattformen aufbauen.

Da alle Softwarepakete schnell starten und sehr gut reagieren, hat man selbst bei einer heute nicht mehr aktuellen Prozessorleistung mit einer Linux-Basis ein nutzbares System.

Was fehlt?

Online-Banking geht fast immer nur über den Browser, die Banking-Software, die ich einsetze, ist nur für Windows verfügbar.

Digital Pathworks! Die meisten werden das Produkt nicht kennen, für mich als alten OpenVMS-Administrator, -Entwickler und -Nutzer ist es wichtig, da es diverse DEC-kompatible Terminals bereitstellt. Das in jedem Linux vorhandene Xterm kann nur ein VT100 emulieren, das reicht für eine vernünftige Arbeit auf den Alphas nicht aus. Aber ich muss zugeben, das ist ein Minderheitenproblem, das sich für 99% aller Notebook-Nutzer nicht stellt. Ich dagegen habe noch einen Kunden im Ausland, der immer wieder einmal etwas Expertenwissen benötigt. So hätte ich es gerne:

Debian selbst, und alle dort integrierten Produkte, hat einen langsamen Aktualisierungszyklus, nicht immer steht die letzte Version der Anwendungssoftware zur Verfügung. Dafür allerdings ist die Plattform gut getestet und sicherheitsrelevante Updates werden schnell bereitgestellt.

Eine Spielerei:

Das Projekt MaXX Desktop bringt die Oberfläche der IRIX-Systeme von Silicon Graphics auf das Notebook. Diese Bedienoberfläche war einmal das modernste, was der Workstation-Markt in den achtziger Jahren bot. Wer also nostalgisch an die Zeit zurückdenkt, kann sein System entsprechen gestalten. Tatsächlich ist es auch besser, als altes SIG-Systeme zu reaktivieren, das es auf der neuen Hardware natürlich um Klassen schneller arbeitet und man Zugriff auf aktuelle Werkzeuge erhält, die es in den Achtziger noch nicht gab und die auch nie portiert wurden.

Veröffentlicht unter Graphische Werkzeuge, Linux, Notebook, Workstation | Verschlagwortet mit , | Schreib einen Kommentar

Was man so beim Aufräumen findet

Publiziert am 25. März 2022 von dieter

Schätze aus alter Zeit, die ich beim Aufräumen gefunden habe:

  • Aus meiner PDP-11-Zeit, DECPack und RK02-Platte mit RSX-11M, Band mit der Bibliothek meiner eigenen Unterprogramm-Sammlung
DECpack
RK02
  • Disketten und Bandkassetten
  • TK50-,tk70-, TK85- und Dat-Bandkassetten. Dafür habe ich auch noch die passenden Laufwerke. Das TK50 hat die Installationsdateien einer alten VAX/VMS-Version gespeichert.
  • Den Quellcode für VMS 4.0 auf Mikrofilm. Einen Leser habe ich leider nicht, das liegt nur aus Nostalgie im Regal.
  • Ein Karte, die die Tastenbelegung eines VT-52-Terminals im Editor-Modus zeigt.
  • Eine Mappe mit den Ausdrucken alter Assemblerprogramme für IBM /370 MVS
Veröffentlicht unter Allgemein | Schreib einen Kommentar

Ein alter Kunde meldet sich

Publiziert am 6. März 2022 von dieter
Bahn zur Aufnahme des sich mit jedem Durchgang verlängernden Blechs eines Walzwerks

Die Betriebssoftware eines Stahlwerks gliedert sich in mehrere Ebenen, die gewöhnlich als “Level1”, “Level 2” und “Level 3” bezeichnet werden.

Der “Level 1” besteht aus den Automaten oder SPS, die die Anlage auf unterster Ebene steuern.

Bei dem  “Level 2” handelt es sich um Software, die den Produktionsprozess verfolgt, dazu mit allen Automaten kommuniziert, alle Produktionsinformationen sammelt und basierend auf diesen Informationen  die Durchführung einer Schmelze steuert. Schon bei der Planung der Produktion  bestellt der Level 2  die notwenigen  Rohstoffe  beim  Schrottplatz, errechnet aus der angeforderten Stahlgüte Vorgaben zu Dauer, Temperatursteuerung und Zuschlagsstoffen für Schmelze und steuert die Materialzugaben.  Während der Schmelze kommuniziert der Level 2 mit dem Schrottplatz, dem Labor, der Qualitätssicherung. Er informiert die Operateure über alle Details des produktionsverlaufs. Nach Abschluss der Schmelze werden die Stahlmenge, die erzeugte Güte und Verbrauchswerte an den Level 3 zur kommerziellen Behandlung geliefert und an die nachgelagerte Gussstation geliefert.

Der Level 3 ist die kommerzielle Steuerungsebenen. Hier werden Bestellungen zu Schmelzenreihen zusammengestellt, um eine möglichst kontinuierliche Auslastung der Gesamtanlage zu erhalten. Diese Schmelzenreihen gehen dann als Bestellungen an den Level 2, der sie zum Abruf und zur Abarbeitung bereit hält. Nach Abschluss der Abarbeitung der Bestellungen durch den Level 2 verwertet der Level 3 die gemeldeten Produktionsdaten und Ergebnisse für die kommerzielle Behandlung: Lieferungen zusammenstellen, Rechnungswesen, langfristige Datenhaltung zur Qualitätskontrolle etc

Rosin war schon fast zehn Jahre Lieferant für Level 2  Systeme, mit weltweiten Installation, als über eine große deutsche Industrieanlagenbaufirma der Auftrag für die Aktualisierung einer Anlage in Spanien an uns vergeben wurden.

Dieser Auftrag war ein guter Anlass, eine komplette Neuentwicklung unserer Level 2-Software in Angriff zu nehmen, um folgende Ziele zu erreichen: Das neue Systeme sollte multilingual,  Hardware- und Betriebssystem-unabhängig, datenbankunabhängig, und zukunftssicher sein.

Durch moderne Systemware-Methoden wie Objektorientierung, Java aus Entwicklungssprache, und Oracle als Datenbank wurden diese Kriterien erreicht.

Als  Hardware-Plattform wurden Alpha-Server unter OpenVMS gewählt, zu dieser  Zeit der Standard in  Automation. Die  Benutzeroberfläche wurde in englisch und spanisch bereitgestellt, aber schon im ersten Release war sie leicht um weitere Sprachen erweiterbar, auch in arabisch und chinesisch. Die Entwicklung erfolgte weitgehend unter Windows und Unix, die Portierung auf OpenVMS  erfolgte fortlaufend während de Erstellung, sodass die aktuelle Entwicklungsstand jederzeit auf allen drei Betriebssystemen lauffähig war. Parallel liefen Tests mit Opensource-Datenbanken wie Postgres und Mysql.

2003 wurde der Level 2 beim Kunden installiert, in Betrieb gesetzt und übergeben.

Nach fast neunzehn Jahren meldet sich der Kunde zu unserer Überraschung  im Herbst 2021 mit einem Problem. Das große Rätselraten, was denn nach so vielen Betriebsjahren nun Sorgen bereiten könnte, löste sich auf überraschende Weise:  Die IT-Mannschaft, die sich mit dem System auskennt, geht in Rente, das Systems selbst hat sich aber als so stabil erwiesen, dass man es gerne weiterbetreiben möchte. Die Lösung ist die Übernahme der Betreuung durch uns – dem Kunden kommt dabei zu Gute, dass das System inzwischen für andere Einsätze  deutlich weiterentwickelt wurde, und der Kunde nunmehr auch von den Neuerungen profitieren kann.

Inzwischen sind die Servercomputer auf lokale Umgebungen in Linz und Ronda geclont, erste Probleme durch die Änderungen, die der Kunden in den letzten Jahren eingearbeitet hatte, gelöst, und ein Plan für die nächsten Upgrades erstellt.

Und es macht Spass, wieder mit OpenVMS zu arbeiten

Foto und Text: Dieter Roßbach

Veröffentlicht unter Allgemein | Schreib einen Kommentar

Austausch der SAN-Hardware

Publiziert am 5. März 2022 von dieter

Alpha-Hardware mit OpenVMS am SAN ist eine gute Idee, da man dadurch Cluster aus mehreren Systemen bilden kann, die sich dann eine Systemplatte teilen und so die Vewaltung der Gesamtumgebung deutlich vereinfachen. Das gleiche gilt natürlich auch für die Datenplatten, der Clustermanager synchronisert die Zugriffe und stellt den Inhalt quasi lokal zur Verfügung. Zudem steht eine clusterweite Quorum-Platte zur Verfügung, die hilft, die Konsistenz des Clusters beim Ausfall einer oder mehrerer Rechner aufrecht zu erhalten. Dazu kommen noch die weiteren Vorteile des SANs: Bereitstellung von großen virtuellen Platten, Raidlevel, die die CPU-Leistung der Rechner nicht beeinträchtigen und eine schnelle Anbindung über Glasfaser.

Für VMS gibt es aber eine entscheidende technische Voraussetzung: das SAN muss das Betriebssystem unterstützen. Und hier kommen die MSA-Lösungen von DEC/Compaq/HP ins Spiel: die können das. Die erste erschwingliche Lösung war MSA1000. Sie erlaube eine vollständig redundante Konfiguration mit bis zu drei Plattenboxen und je zwei Controllern und Glasfaser-Switchen. Pro Box konnten bis zu 14 SCSI-Platten installiert werden, die dann boxenübergreifend in den gängigen Raid-Leveln genutzt werden. Die dadurch generierten logischen Platten konnten eine oder mehrere LUNs bedienen. Zudem war die Lösung offen, ein gemischter Betrieb mit VMS-, Unix-, Windows- und ESX-Servern war problemlos möglich.

Solch ein SAN hatte ich mit 3 ALPHAs unter OpenVMS 8.4 und 2 IBM-Servern unter ESX in Betrieb.

Nun ist diese Hardware mittlerweile recht alt und damit nicht mehr sinnvoll betreibbar, die Gründe dafür sind:

  • SCSI-Platten sind inzwischen teuer geworden.
  • Der Stromverbrauch ist durch die alten Platten sehr hoch
  • Größenbeschränkung des möglichen Plattenplatzes auf maximal 42 Laufwerke mit insgesamt 12 TB
  • Die Fibre-Switche sind dedizierte Lösungen, die über Einschübe in die Boxen angeschlossen werden. Bei Defekten muss der Einschub gegen gleiche Module ersetzt werden, die neu kaum, und wenn dann teuer zu beschaffen sind.

Auf die SAN-Plattform kann ich nicht verzichten, da sie die notwendige Flexibilität im Tagesbetrieb bietet. Um zukunftssicher zu sein, muss also eine Lösung her, die die oben genannten Einschränkungen umgeht und natürlich auch die OpenVMS-Systeme weiter unterstützt.

Als einfachste Lösung bietet sich der Wechsel auf die Folgegeneration MSA1500 an: Hier können sowohl SCSI- wie auch SATA-Platten mit einer Gesamtkapazität 96TB von eingesetzt werden, mit der Einschränkung, das nur Platten mit bis zu 1TB unterstützt werden. Für meinen Bedarf ist das vollkommen ausreichend. Die SATA-Platten sind preiswert verfügbar. Als Fibre-Switches können alle auf dem Markt verfügbaren genutzt werden. Ich setzt HP- und Brocade-Geräte ein – wobei der HP-Switch ein umbenannter Brocade ist. Die Verfügbarkeit von preiswerten Ersatz ist also gegeben.

Die Hardware war über Ebay einfach und preiswert zu beschaffen. Für einen reibungslosen Betriebsübergang habe ich erst einmal eine Test- und Migrationsumgebung aus einem Alpha-, einem ESX-Server und einem Fibre-Switch aufgebaut.

Drei 80GB-Platten, 2 im Spiegel und eine als Reserve, reichen für die VMS-Umgebung vollkommen aus. Darauf sind 5 LUNs in verschiedenen Größen abgebildet. Der Datastorage DS1 ist für die Systemplatten der auf ESX betriebenen Debian-Systeme vorgesehen.

Die Testumgebung habe ich dazu genutzt, mit mit der Konfiguration der Fibre-Switche vertraut zu machen – Reset, Zugang trotz nicht bekanntem Admin-Passwort zu bekommen, Konfiguration etc., die Hardware auf Stand zu bringen (Säubern, Pufferbatterien austauschen etc) und dann das Zusammenspiel der einzelnen Komponenten zum Laufen zu bekommen. Im nächsten Schritt habe ich dann die Platten entsprechend der geplanten Aufteilung konfiguriert und das VMS- und ein Debian-System testweise umgezogen. Das alles lief relativ reibungslos, da die eigentliche Konfiguration des MSA1500 sich nicht von der des MSA1000 unterscheidet.

Der Umzug der Systeme ist je nach Plattform unterschiedlich aufwändig.

In Produktion. Das Plattenchassis ist nun voll bestückt. Bei Bedarf können aber noch drei weitere angeschlossen werden.

Der Umzug von VMS-Systemen ist denkbar einfach. Meine regelmäßigen Sicherungen bestehen aus einem Vollabzug aller Platten am Samstag und inkrementellen Sicherungen unter der Woche. Daraus lässt sich ein System mit wenigen Befehlen rekonstruieren. Aus Redundanz- und Sicherheitsgründen halte ich auf jedem Rechner auf einer lokalen Platte eine bootbare Systemplatte bereit. Die wird angestartet, dann die Sicherungsdateien über da Netz kopiert und je nach Platzbedarf auf eine lokale oder eine temporär eingerichtete SAN-Platte abgelegt und dann per Backup/image auf die neuen Zielplatten kopiert. Danach ist die neue Produktionsumgebung fertig und betriebsbereit.

Die Debian-Systeme habe ich per ESX-Funktion umgezogen. Im ersten Schritt wurden alle Systeme auf lokale Platten im Server verschoben und dort wieder gestartet. damit war die Ausfallzeit minimiert und ich konnte die SAN-Hardware in Ruhe umbauen. Dann alles wieder zurück auf das neue SAN und der Umbau war abgeschlossen. Meine Stromrechnung wird es mit danken und die hauseigene Cloudd kann nun auch üppigen Platz bereitstellen.

Veröffentlicht unter DIgital Equipment Alpha, DS15, ESX, MSA1500, SANStorage | Schreib einen Kommentar

Die Wiederbelebung der SGI-Systeme

Publiziert am 5. März 2022 von dieter

Funktionsfähige Geräte weg zuwerfen fällt mir schwer. Daher steht im meinen Lager das eine oder andere alte System herum, mit dem man eigentlich nicht viel anfangen kann, so auch die SGI Indy und die O2, die schon lange nicht mehr hochgefahren wurden.

Diese Systeme wieder in Betrieb zu nehmen, klingt im ersten Moment ganz einfach. Schließlich funktionierten sie ja tadellos, als sie das letzte Mal ausgeschaltet wurden. Die Realität ist aber doch eine andere: Mäuse bewegen den Zeiger auf dem Bildschirm eher zufällig, alte Monitore melden sich beim Einschalten genau einmal mit einem Blitz – und dann nie wieder- Festplatten geben unschöne Geräusche von sich, die Indy verliert immer ihre IP-Einstellung und zu guter Letzt hat man nach der Zeit auch noch das System/root-Kennwort der O2 vergessen – und wie man die Hintertür ins System öffnet natürlich auch.

Alles in allem ist das also eine nette Aufgabe für arbeitsarme Zeiten, zum Beispiel während der Corona-Beschränkungen.

Die Ursache für den Verlust der IP-Einstellungen nach jedem Neustart war, dass die Batterie des Dallas Chip verbraucht war – und sie ist eingegossen, also nicht so einfach zu ersetzen. China sei Dank gibt es neue Chips für wenig Geld und der Einbau ist simpel.

Das Monitor-Problem ist in so fern nicht einfach zu lösen, also die Indy keinen VGA-Ausgang hat, folglich auch nicht an einem einfachen Bildschirm betrieben werden kann. Er muss mindestens Sync-on-green unterstützen und braucht einen speziellen Adapter. Der Anschluss für den Monitor sieht genauso aus wie der der Solaris-Systeme, aber es gibt Unterschiede, die die Nutzung eines Solaris-Monitorkabels verhindern. Recherchen im Internet führen zu einer etwas schrägen Lösung:

Am Kabelstrecker müssen die Pins 1,2,4,5,6 und 7 entfernt werden, dann funktioniert das, die Indy meldet sich auf dem Bildschirm – und bootet. Die letzte veröffentlichte IRIX-Version ist 6.5, leider meldet sich der Rechner mit 6.2, da ist eine Aktualisierung fällig. Zu Glück liegen hier noch die Original-Installations-CDs von Silicon Graphics im Lager, allerdings hat die Indy kein CD-Laufwerk und das externe SCSI-Gerät ist defekt. Nun waren die SGI-Rechner zu ihrer Zeit sehr innovativ und daher gibt es die Möglichkeit, eine Installation über das Netzwerk durchzuführen – und ich habe ja auch eine O2, die ein internes Laufwerk hat. Die Installation kann also beginnen.

Sie geht wie folgt:

– O2 booten, IP-Adresse und Hostnamen ermitteln – nun gut, die kenne ich ohnehin
– Die Installations-CD #1 einlegen
– Die Indy einschalten. Sobald die Meldung „System Starting up“ erscheint, den Mainteance Mode auswählen, oder die ESC-Taste drücken, falls keine Auswahlmöglichkeit erscheint.
– Vom Menue den Punkt „INSTALL SYSTEM SOFTWARE“ auswählen
– Als Installationequelle „Remote Directory“ auswählen
– Den Namen der O2 eingeben
– Die IP-Adresse der O2 eingeben
– Quellpfad eingeben: /CDROM/dist
– Installation vom Menü auswählen
– Auf den Inst-Prompt mit o2:/CDROM/dist „O2 ist dabei durch den Hostnamen zu ersetzen“
– Sobald die Meldung „Install software from [/CDROM/dist]“ erscheint, die nächste CD einlegen.

  • Die Auswahl der Installationspakete treffen und die Installation starten:
  • Inst> keep *
  • Inst> install standard
  • Inst> install prereqs
  • Inst> go

Am Ende Done auswahlen. Dann kann die Indy mit dem aktualisierten System gebotet werden.

CD Sequenz:
– Installations Tools
– Foundation 1
– Foundation 2
– Applications

Im Vergleich zur Indy war die O2 viel einfacher wieder in Betrieb zu nehmen. Sie kann ein einem Standard-VGA-Schirm betrieben werden, Tastatur und Maus werden über PS2-Stecker angeschlossen und ein funktionsfähiges CD-ROM-Laufwerk gibt es. Zwei kleine Probleme gab es zu lösen: die Tastatur war auf französisch eingestellt und das Root-Passwort, dass zur Änderung erforderlich ist, verloren gegangen. Über den Maintance-Mode der Konsole ließen sich beide Probleme leicht lösen.

Veröffentlicht unter Indy, O2, Silicon Graphics, Unix, Workstation | Schreib einen Kommentar