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

[Pahle Heinz]

Lieber Ekki, liebe LUGer,

ich widerrufe die Sache mit 2038-Linux-Problem, schreibe aber, dass ich
anscheinend im Bündel der vielen zukünftigen Änderungen, die eben
diskutiert wurden, das 2038-Problem als ein solches noch bestehend
verstanden habe. Entschuldigung! Aus diesem Grund, korrekt verstanden zu
haben, hatte ich (bis dato) keinen Grund zu recherchieren. Gelernt ist
aber, dass man fremdes Gehörtes in jedem Fall doch nochmal nachprüfen
soll. Das wäre etwas Positives, das ich aus dem Treffen mitnehme.

Gruß Heinz


Am 19.04.2024 um 15:20 schrieb Ekki Plicht:
> Heinz,
>
> Du schreibst:
>> Linux muss da noch ein Problem lösen.
>
> Das ist Unsinn, das Problem ist seit langem gelöst (Kernel 5.6 aus dem
> Jahr 2020). Bitte informiere dich vernünftig, bevor Du falsche
> Behauptungen aufstellst und verbreitest.
>
> Ich empfehle die Wikipedia.
> https://en.wikipedia.org/wiki/Year_2038_problem
>
>
>
> Ekki
>
>
>
>
>
>
>
>
>
>
>
> On 19.04.24 11:26, Pahle Heinz wrote:
>> 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.
>>
>> _______________________________________________
>> lug-ld mailing list
>> lug-ld at lists.lug-ld.de
>> http://lists.lug-ld.de/mailman/listinfo/lug-ld
>
> _______________________________________________
> lug-ld mailing list
> lug-ld at lists.lug-ld.de
> http://lists.lug-ld.de/mailman/listinfo/lug-ld