[lug-ld] Unser Treffen 2024-04-18 (ZTL) - Thema dbus

[Pahle Heinz]

Liebe LUGer,

vornweg: Mein Grummeln darüber, dass man z.B. bei Wikipedia nicht mit
einfachen, allen Dummies verständlichen Worten dbus erklärte, nehme ich
zurück. Ich denke, dass die Mehrzahl aller Vortragslauscher von Ekki
eine tolle Einführung erfuhren und so die Komplexität von dbus voll
erkannten. Meine Erkenntnis: Das ist nichts für einfache
Dummy-Erklärsätze. Mit dbus arbeiten, das ist halt etwas für
Maschinenraum-Klempner, nicht für einfache Linux-Anwender, die nur ein
wenig Internet- und Büroarbeiten verrichten. Aber auch die, ich zähle
mich dazu, können sich über die dbus Entwicklungs-Arbeit begeistern,
wenn allgemein an Geheimnissen schnuppern bereits motiviert, sich das
wenigstens mal anzuhören (Rentner können auch Zeit haben).

Jeder hat halt Wissensschwerpunkte. Vor Jahren schon habe ich mich mit
Zeitrechnungen und Kalendern software mäßig "ausgetobt". Deswegen
erkannte ich an den Protokoll-Nachrichten von dbus sofort, dass da ein
2038-Problem in der Luft liegt. Meine Software zeigt mir die letzte
"Unix-Sekunde" an: 2038-01-19T03:14:07. Dann "platzt" der Zähler. Linux
muss da noch ein Problem lösen. Der Wettbewerb hat heute schon alt und
neu in der Software verankert. Da einige Linux und Windows auf einer
Maschine haben, zum Nachgucken in der Windows Registry, per Regedit (als
Administrator, bei Veränderungen) aufrufbar.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
InstallDate: 1692439931 ......... 2023-08-19T10:12:11 (Sa)
InstallTime: 01d9d2859e62c067 ... 2023-08-19T10:12:11,389 5527 (Sa)
Nur soviel noch dazu: InstallTime-Angabe im Beispiel startete
1601-01-01T00:00 aber mit einer Granularität von 100ns! Der merkwürdige
Start hat natürlich Kalendergründe. Ihr wisst ja: "Ein Schaltjahr ist
ein Schaltjahr, wenn ..., aber nicht, wenn ..., aber dann doch wenn...".
Über Zeiten, Kalender, auch Julian Day Number etc. gäbe es noch ganz
viel zu erzählen.

Bei den Zeiten kamen wir quasi ins Philosophieren. So: Reicht es, wenn
sich die Erde schneller dreht (Wassermasse aus geschmolzenen Eises
wandert zum Äquator, Rotation erhöht sich) mit negativen Schalt-Sekunden
zu arbeiten, oder die Sekunden zu verkürzen?

Ein weiteres Zeitproblem ploppte auf. Linux und Windows auf einer Kiste,
das gibt bei allen Voreinstellungen ein Zeitanzeigeproblem, das man aber
ganz einfach lösen kann. Es geht nur um die Anzeige, nicht um die
interne Realisation.
Windows speichert FileTime in UTC ab, Linux richtet sich nach UTC. Damit
beide Systeme gleich anzeigen, muss man Windows in der Registry eine
Vorgabe machen. Die: Eine Variable erschaffen, der einen Wert vergeben.
Auf meinem Spickzettel bei Neueirichtung steht (natürlich als
Administrator) Regedit aufrufen:
In Pfad
„HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation“
wechseln.
Neues DWORD (32-Bit) mit dem Namen „RealTimeIsUniversal“ schaffen, der
Var den Wert 1 geben

Soweit zu unserer Zusammenkunft, mit dem super Vortrag von Ekki und den
sich anschließenden interessanten Gesprächen

Gruß Heinz

PS:
Eine Hausaufgabe habe ich noch. Laut Mona, müsste bei einem secure boot
Rechner worauf auch Windows 11 läuft, ein Linux ohne Hin- und
Herschalten (secure boot an/aus) beim Start zu installieren sein.
Installieren von Linux mit abgeschaltetem secure boot, hinter her wieder
secure boot für beide Betriebsysteme eingeschaltet lassen. Ich kann es
nicht glauben, würde es aber sehr begrüßen. Ich habe selbst bei Windows
meine blauen Wunder erlebt. Eine nicht initialisierte Platte will secure
boot nicht. Also Platte in "Alt-Rechner" und auf GPT initialisieren.