Alle Postings (158)

2018

Physik und Software-Stacks

Das erste Suchergebnis

Reverse Engineering

2017

Best of 2017

Fernprojekte

Computer, Informatik und IT

Physik - die Ernte!

Subversiv? Physik?

Meine Philosophie!

Scripts erzeugen Scripts

2016

Theoretische Physik als Hobby

Selbstbezügliche Poesie

Stille Website

'Machst Du noch PKI?'

Meine Philosophie (?)

Wie wirkt Physik?

2015 ist nicht viel passiert

2015

Unaussprechliches

Selbst-Poesie

Letztes Posting...

Web-Projekt: Status-Update

Wir unterbrechen ...

Unsere Photovoltaik-Anlage

Soziale Schulden

PKI-Status-Update

Leben und Arbeit

IT-Postings

Alte Weisheiten - neue Popularität

Definition: 'Subversiv'

2014 in Büchern

Zu den Wurzeln von radices

Physik-Postings

Physiker oder Ingenieur?

Ing.-Postings

Wirkliche Expertin

2014

2014 - ein gutes Jahr

Fast 20 Jahre danach

Ingenieurs-Links

Jahresansprache

Was ist Kunst?

Bio

PKI FAQ

Worte und Google

Zertifikate und Wärmepumpen

Technet-Postings

WOP!

Leben, das Universum und überhaupt alles.

Oh-oh, kein Posting im März

Radices = Wurzeln = Roots

PKI-Probleme

PKI Ressourcen

PKI-Probleme

Arbeit

Schreiben

Was ist PKI?

Ich stehe auf den Schultern subversiver Giganten

PKI - Netzwerke - Smart Grid

Suchbegriffspoesie

Quantenfeldtheorie

Plattform für Poeten

2013 in Büchern

2013

Nutzbar machen, erklären, beurteilen

Lebensform Elke Stangl

Technologie

Was fasziniert mich an der Physik?

Naturphilosophische Praxis?

elkement and diese Site

Sind Netzwerke sozial?

Retrospektion

Newsletter-Wiederbelebung

Wilhelm Macke: Internet-Spuren

2012

Gratis, umsonst und nutzlos

Subversiver Jahresbericht

Was ist Energie?

Prof. Wilhelm Macke

Mein Leben ist ein Klischee(?)

Netzwerke (Kategorie)

Wissenschaft - Kindheitsmelodie

Freude am Klischeé

Möchtegern-Netizen

Der tägliche Untergrund

Parawissenschaften - Resümee

Profil

Parawissenschaft - Bücher

Das Element ist zurück!

Offline

PKI: Zwischenstand

2011

Warteschleife

Naturwissenschaft - Arbeitswelt

Nicht originell

Das ganze Internet...

Experte

Kurz vor einem Neubeginn

Die rote Pille

Erkenntnis

2008

Netizen (2)

2007

Das Ende

Früher einmal...

2006

Netzwerktheorie

2005

Tsunami-Physik

Nullpunktsenergie

Nr.9 - Krypton

radices.net - Internet

Hier ist der Ausgang

Element-Art

Skeptizismus und Esoterik

Der totale Spielraum

Nr.8 - Brave New Online World

Nr.7 - Wer ist DAS Element?

Moderner Networker

Liebe zur Weisheit

EPSI-Kult

EPSI

Nr.6 - The Art of Networking

Unterteilung der Physik

Ich bin ein Dilettant!

Bewusstseinserweiternd

Was ist 'subversiv'?

(Para-)Wissenschaften global

Epigonen

2004

Nr.4,5 - Welcome

Beruf, Berufung, Interesse

Nr.4 - Selbstfindung

Subversiver Römer für die Sammlung

Existenz

Parawissenschaften

Nr. 3: Internet-Apocalypse

Skeptizismus

Meta-Gefasel

Keine Ahnung von Kunst

Ur-Fragen

Umsonst

Dejavu

Bewegungsgleichung

Bildungsideal

Physik repräsentiert...

Nr. 2: Primzahl

Nerd, Geek, Techie

Nr. 1 von mindestens 42

Subversiver Newsletter

Best of Log

Netizen

Magie der Deadlines.

2003

Anstelle eines Lebenslaufes

Was ist Wissenschaft?

Captain Kirk's Lieblingsbefehl

Wissensmanagement

Keine Navigation

radices.net - Geschichte

Bücher: Meine Favoriten

2002

Elke war da

2000

Pinkes Raumschiff

1998

Worte

Goldene Talente

Lebensplanung oder Chaos

Wissenschaftliche (?) Laufbahn

1996

Rede zur Promotion

1987

Die 'heutige Jugend'

Postings zum Schlagwort 'Ingenieur', nach dem Erstelldatum sortiert in absteigender Reihenfolge. Alle Postings angezeigt.

Ich sage ja oft: Eigentlich / wirklich / im Grund ist alles was ich mache ... Reverse Engineering von Blackboxen! Das betrifft Software, Drähte, Hydraulik - und alles dazwischen, wie die Steuerung.

Irgendwann war ich offiziell technischer Spezialist für bestimmte (Software-)Produkte. Da nimmt der Kunde an, man hätte langjährige Erfahrungen und zig Schulungen hinter sich. De facto hab ich manchmal das betreffende Produkt am Wochenende vor dem Auftritt als Experte auseinander genommen und untersucht.

Was verbinde ich mit Reverse Engineering?

Pragmatischer Ansatz - 80/20. Jahrelang hatte ich an akademischen Publikationen gefeilt: Jede Formulierung x-mal umgedreht - oft nach zermürbenden Besprechungen, um die These wasserdicht zu machen, jedes Messergebnis hinterfragt. Und dann flog ich durch ein Wurmloch in die Welt des kleinen Computer-Fuzzis: Du stehst beim Kunden vor der störrischen Maschine und musst ein Problem lösen. Besser schnell als perfekt.

Jahre später könnte man dazu vielleicht sogar ein wissenschaftliches Paper schreiben. Das ist aber uninteressant, weil es nicht darum geht, andere Experten in demselben Fach zu beeindrucken. Ein dringendes Problem muss behoben werden, hier und jetzt ... aber nicht mehr.

Tiefe und Breite. Ja, man muss beim Reverse Engineering und Troubleshooting 'out-of-the-box' denken, wie man heute sagt. Das bedeutet aber nicht, dass es unwichtig wäre, Grundlagen und 'Theorie' zu betroffenen Problem zu lernen. Für optimal halte ich die Kombination von tiefem Wissen in einem Spezialgebiet - jenes, das man sich auch offiziell auf die Fahnen heftet - und breitem Halbwissen über die Gebiete darum herum. Also so, dass man mittels gezieltem Schnüffeln / Debuggen / Forschen auch in diese Gebiete tiefer eindringen kann und eventuell ein langsam ein neues Spezialgebiet erorbert.

Ursprünglich war mein Thema: Public Key Infrastructure, nun sind es seit einiger Zeit Wärmepumpen und Thermodynamik. Und plötzlich ergibt sich die Notwendigkeit, sich mit CAN-Bus-Netzwerkprotokollen zu beschäftigen, oder mit Wärmepumpen ohne elektrisch angetriebenem Kompressor.

Kein falscher Stolz. Es ist interessant und lohnend - und vor allem praktisch - an Problemen zu tüftlen, die man alleiner lösen kann. Ohne große Support-Organisation und Entwicklungsabteilung im Hintergrund. Besser einmal kurz sniffen und tracen als zu versuchen, einer Kontakt zu dem menschlichen Schöpfer der Blackbox herzustellen - einer unbekannten menschlichen Lebensform die vielleicht oder vielleicht auch nicht in einer Firma mit 1000en Mitarbeitern arbeitet.

Aber Aufwand/Nutzen für Sniffen versus Kontak sollte pragmatisch abgewogen werden - es ist manchmal nicht leicht, den Geek-Ethos zu dämpfen und sich durchzutelefonieren oder -e-mailen. Ich habe Social Engineering betrieben (mit guter Absicht!) ohne es wissen, um an Manuals, Passwörter etc. zu gelanden.

Letzendlich kann es Win-Win-Situation werden für alle Beteiligten - es gibt keine Art des Lernens, die so effizient ist wie das Fachsimpeln mit Kollegen. Und es gibt keine Art des 'Netzwerkens' die so sinnvoll und selbstverständlich ist wie Fachkollegen 'im Notfall' - also wenn man beim  Kunden nicht mehr weiter weiß - kontaktieren zu können. Umgekehrt ist man selbst auch Anlaufstelle bei Notfällen im eigenen Spezialgebiet. Glücklicherweise waren die Fälle selten, in denen das Verständnis von Win-Win sehr unterschiedlich war.

Wieder verwenden statt Green Field. Ich verbinde Reverse Engineering automatisch mit: Reparieren und Sanieren - anstelle von Wegwerfen / Löschen und Neukauf / Neuinstallation. Es kann meine persönliche Präferenz sein, da die 'Einschränkung' durch Vorhandenes einen ganz besonderen Reiz hat und die Kreativität anspornt.

Ein übernommenes Altsystem ist immer eine Blackbox, die es zu entschlüsseln gilt. Aber auch Dinge, die man selbst gebau hat vor Jahren, können einem selbst irgendwann Rätsel aufgeben, die man schneller mit Debugging löst als mit dem Nachlesen der eigenen Dokumentation (.... das sage ich als legendär-exzessiver Dokumentator).

Was die Experten sagen ... muss nicht immer richtig sein. Zu wissen, was diese Dinge machen und wie sie funktionieren ist die Basis für die Kontrolle darüber - und kein externer Profi / Lieferant / Dienstleister kann einem dann ein Gschichtl erzählen.

Wenn der Fachexperte (der oft auch gleichzeitig der Verkäufer von neuem Zeug ist) behauptet Das geht nicht, dann kann man das nur widerlegen, indem man zeigt, dass es geht.Vielleicht ist das der wichtigste Aspekt überhaupt - in Zeiten von immer mehr Schnittstellen zu externen Diensten, Clouds und immer schöner verpackten und versiegelten Blackboxen, die man unter Androhung legaler Konsequenzen keinesfalls reverse engineeren darf.

Wärmepumpe hacken

Was mache ich eigentlich seit Jahrzehnten - in praktisch jedem Job, den ich jemals hatte ... und als Teil jeder Ausbildung, akademisch oder im Selbststudium?

Antwort: Software-Entwicklung! Diese Erkenntnis nehme ich zum Anlass, über meine Beziehung zur Computern und den dazugehörigen Wissenschaften und Aktivitäten zu philosophieren. Wie so oft, denke ich in Gegensatzpaaren.

Solide Ausbildung versus 'Learning by Doing'. Wie es ein IT-Kollege so treffend formulierte: In den Pionierzeiten war man gleich ein Experte, wenn man die Maus richtig halten konnte. Die 'IT-Branche' war ein Sammelbecken, offen für Leute mit 'irgendwelchen' oder keinen Qualifikationen.

Resultat: Die 'Hacker Ethic'. Es zählen die Fähigkeiten, die Du jetzt live demonstrieren kannst, nicht die Papiere. In den 1990ern - vor der dotcom-Krise - konnte man quasi ein handgeschriebenes Schild aufstellen 'Mache alles mit Computern' und bekam einen Vertrauensvorschuss.

Aufbau versus Zerstörung. Disclaimer: Ich war und bin lange genug verantwortlich dafür, 'Systeme' am Leben zu erhalten. Manche leben länger als es mir lieb ist; ich fühle mich wie der COBOL-Programmierer im Jahr 2000.

Aber das Interessanteste war immer herauszufinden, wie etwas funktioniert. Das kann auch kontrollierte Zerstörung erfordern. Debugging. Reverse Engineering. Troubleshooting. ... Was wiederum die Basis ist für die konstruktive Aufbauarbeit: Wie soll man sonst verwaiste System-'Blackboxen' oder undokumentierte Schnittstellen verstehen? Für mich war diese Reverse-Engineering-Mentalität immer die natürliche und direkte Verbindung zwischen Physik und IT.

... wichtiger als der mathematische Unterbau von Physik sowie Informatik oder die Programmierfähigkeiten, die man als Physiker angeblich so mitbekommt. Von FORTRAN - 'Programmierung für Physiker' weiß ich nicht mehr viel. Als Experimentalphysiker ein 'System der Natur zu debuggen', mit 'out-of-the-box' Ideen, war das eigentliche IT-Training: Welchen Parameter muss man ändern, um welchen Effekt zu erzielen? (Wenn man supraleitende Schichten erzeugt indem man mit Laserpulsen auf eine kleine keramische Probe schießt). Wie schließt man möglichst schnell und effizient aus, welche Parameter keinen Einfluss haben?

'Good-enough' Ansatz versus Perfektionismus. 80/20 oder vielleicht sogar 99/1. Man muss nicht alles wissen. Ich erinnere mich an mein erstes 'Live-Troubleshooten', als frischgebackener Computerberater. Mein Hintergrundwissen war spärlich - so gering, dass es mir heute fast peinlich ist diese Leistungen damals angeboten zu haben. Andererseits hatte ich alle Probleme tatsächlich gelöst - meistens sehr schnell.

In diesem Moment wurde mir der Kontrast zwischen pragmatischem Anpacken trotz unvollständigen Wissens und den endlosen Schleifen des Feilens an akademischen Veröffentlichungen bewusst. Wenn da ein Satz noch ergänzt wurde mit Tentatively, we assume,... nur um ganz sicher zu gehen; obwohl man eh schon ein Spezialist in einer sehr begrenzten Nische war.

Pragmatismus heißt auch: Kein falscher Stolz! Es wird die Lösung gewählt, die am vielversprechendsten erscheint: Tief hineinknien, oder auch: intelligent googeln oder jemanden mit Erfahrung fragen. (Letzteres aber nur, wenn man in ähnlicher Weise auch einmal selbst etwas beitragen konnte.)

Top-down, bottom-up, oder irgendwo in der Mitte beginnen. Ich war nicht der typische Computer-Nerd als Teenager; ich hatte keinen Computer außer dem programmierbaren Taschenrechner, auf dem man immer nur eine Zeile BASIC-Code sehen konnte. (Was aber reichte, um z.B. den Simplex-Algorithmus zu programmieren...).

Ich war eigentlich nur ein 'Benutzer', bis ich an der Reihe war, meinen Beitrag zur klassischen universitären Patchwork-Programmierung zu leisten: am Turbo-Pascal-Code zur Steuerung einer Anlage - Tieftemperaturmessungen elektrischer Eigenschaften von Proben.

Aber kurz darauf war ich dann plötzlich ganz oben in der Ebene der Abstraktionsschichten und habe - zugegeben :-) - in Visual Basic for Applications, ASP, VBScript programmiert. Langsam bewege ich mich 'nach unten', lerne endlich C++ und wärme ins Unterbewusste verdrängtes Wissen auf ... über 'Registermaschinen' und Assembler. Wobei das ja eigentlich die logische Grenzfläche zwischen Hardware und Software wäre, an der man als Physiker arbeiten sollte.

Grüne Wiese oder Renovier und ('Refactoring'). Selten habe ich etwas so richtig 'from scratch' entwickelt, und selten war mir das ein Bedürfnis. Harte Einschränkungen, Schnittstellen oder Schnipsel von mysteriösem Alt-Code sind die interessante Herausforderung - ähnlich wie die Sanierung eines alten Hauses im Vergleich zu einem Neubau.

Ich bin gerne Systemärchäologin - inklusive von 'Eigenforschung', was meine eigenen Kreationen betrifft, die ich jahrelang nicht angefasst habe.

Das Ausgraben von Alt-Daten oder -Code ist ohnehin ein Job, der bei vielen nicht sehr beliebt ist - also ist es umso besser im Sinn einer Arbeitsteilung, wenn man genau das gerne macht. Es ist das Gegenteil davon, die Chance zu haben, das neueste coolste Tool ausprobieren zu können.

Philosophische Grundlagen versus: die banale Lösung einer relativ alltäglichen Problemstellung.. Ein Meta-Thema meines kürzlich veröffentlichten Postings: Joel Spolsky empfiehlt (Bewerbern für Softwareentwickler-Jobs) ihre Leidenschaft für die Sache zu untermauern indem sie erwähnen wie die Lektüre von Structure and Interpretation of Computer Programs sie zu Tränen gerührt hat.

So weit hergeholt ist das gar nicht: Ich habe selten ein Lehrbuch gelesen bzw. eine Vorlesung besucht, die gleichzeitig so viele philosophische Erkenntnis-Lämpchen gedrückt hat und andererseits so nützlich war für die Programmieraufgabe, die gerade auf meinem Schreibtisch lag.

In der Hälfte meiner älteren Essays 'im Internet' geht's um meine qualvolle Suche nach diesen philosophischen wissenschaftlichen Tiefen - angesichts der harten Realität im Alltag des arbeitenden Techies. Auf der Uni hatte ich - noch sehr grün hinter den Ohren - angeboten bekommen, an einem Optimierungsprojekt für die Produktion von Plastikfenster mitzuarbeiten. Natürlich hatte ich das abgelehnt. Was denn auch sonst - unter dem Eindruck von Gödel, Escher, Bach und getrieben von dem Wunsch die tiefsten Rätsel des Universums zu entziffern und die Probleme der Menschheit zu lösen als Wissenschaftler-Ingenieur-Philosoph.

Ich muss lächeln; diese Anekdote demonstrierte so Vieles so perfekt. Nach x Jahren Praxis denke ich, dass man 'begeistert' ('passionate' wie das in der einschlägigen Literatur heißt) ist bzw. wird ... genau für jene Sache und jene Themen, in denen man gut ist. Nicht umgekehrt. Ich könnte sagen, ich habe zum philosophischen Überbau zurückgefunden und 'rette die Welt mit erneuerbaren Energien'. Aber eigentlich ist und war es immer das technische Rätsel, das mich angespornt hat - die 'Debugging-Challenge'. Und jedes Stückchen von noch so bodenständigem Code, das zur Lösung produziert werden muss spiegelt das die grunsätzlichen tiefen Wahrheiten (in Gödel, Escher, Bach or Structure and Interpretation) wider.

Letzte Änderung: Recherche-Ergebnisse - Zähler für elektrische Energie, Monitoring des Eigenverbrauchs. Motivation: das eigene Smart Meter vom EVU ist mangels Datenanbindung an die Zentrale noch nicht smart genug.

Wärmepumpe

Nutzung von Wärmepumpen in verschiedenen Ländern und Geschichte der Wärmepumpe

Ungewöhnliche Wärmequellen

Unser Eisspeicher-Wärmepumpensystem LEO_2

... wird auf unserem Blog vorgestellt. Für einen Überblick siehe vor allem

Hier eine Liste einiger Artikel, die einen Überblick über das System geben und Besonderheiten beleuchten:

Stromnetz und Verfügbarkeit

Stromerzeugung

Wasserkraftwerke

In Schweden wird - eventuell - das größte Pumpspeicherkraftwerk der Welt geplant:

  • Siehe Seite 30 am Ende dieses Forschungsberichtes:
    Besides the official estimations there are some discussions [28b] about building pumping capacity between the lakes Vänern and Vättern in Southern Sweden. The difference in altitude is 44 meters between these lakes.?
  • ... und die letzte Seite dieser Präsentation:
    Possible future? Mariestads Kraftverks AB & others 50 km tunnel between the lakes Vänern & Vättern Cost: 250 billion SEK. Installed capacity: 50000 MW 

Frei verfügbare Wetterdaten

Inputdaten für eigene Simulationen.

Österreich und Deutschland:

Welt:

Außergewöhnliche Ereignisse:

  • Der Winter 1962/63 in Europa hat einen eigenen Wikipedia-Eintrag:
    … ungewöhnlich lange Frostdauer, die sich im Bereich eines 250-jährigen Ereignisses bewegt….
    … Von Januar bis März 1963 war der ganze Bodensee zugefroren, zum ersten Mal seit 1830 (ein sehr seltenes Ereignis, weil der Bodensee sehr tief ist).
    … Herausragend ist aber, dass gebietsweise auch in tiefen Lagen bis zu 120 Eistage in Folge lagen. Damit ist der Winter die größte Kälteperiode seit 1739/40 gewesen …

Verschiedene Heizungssysteme

Statistik: Heizungen 2003 bis 2012 nach Bundesländern, verwendetem Energieträger und Art der Heizung. Der Anteil von Einzelöfen ist maximal 15% (in Tirol) und fallend.

Einheiten, Heizwerte, Energiekosten

Tools zur Konvertierung von Einheiten:

Heizwerte und Brennwerte

Eigenschaften von Wasser zum Vergleich

Energiekosten - international

Energiekosten - Österreich

Steuerung, Regelung, Logging

Zähler für elektrische Energie, Monitoring des Eigenverbrauchs.

Manuals für Datenlogger von Technische Alternative GmbH (für die frei programmierbaren Regelungen UVR1611, UVR16x2)

CAN-Bus

Heizen mit der Abwärme von Computern

Computer, die Teil einer Cloud sind und Rechenleistung zur Verfühung stellen, heizen gleichzeitig private Häuser:

Wärmeübertragung

Physik-Grundlagen - Mechanik, Elektrodynamik

The Feynman Lectures of Physics (Englisch)

  • Volume 1: Mainly mechanics, radiation and heat.
  • Volume 2: Mainly electromagnetism and matter

Persönliche Website von Elke Stangl, Zagersdorf, Österreich, c/o punktwissen.
elkement [ät] subversiv [dot] at. Kontakt