CommodoreOS

[Caramon2]

Man kann übrigens die CommodoreOS-Themes aus /usr/share/themes/ und /usr/share/icons/ in den eigenen Benutzerordner in die Ordner ".themes" und ".icons" (müssen ggfs. erst erstellt werden) übernehmen:

(die Hintergrundbilder sind in /usr/share/backgrounds/)​

Das ist Xfce und ich hatte es nur gerade schnell zusammenkopiert: Als Fenster-Theme habe ich z. b. "Default" genommen, da "Hoher Kontrast" (das nutzt COS) bei mir mich installiert ist und ich keine Lust hatte es nachzuinstallieren. - Ich wollte es nur kurz zeigen und habe es dann wieder rückgängig gemacht.

Auch die Mauszeiger hatte ich übernommen, aber dann nicht mehr daran gedacht das auch zu zeigen: Der Amiga-Ball war mir wichtiger.

Auf meiner Test-SSD habe ich COS inzwischen auf btrfs+zstd umformatiert (wie neulich beschrieben), die Partition auf 16 GiB verkleinert und dann noch Win11-22H2 (Win10 ist das 1803) installiert:

(weil Win11 ca. 8 GB "reserviert", musste ich die Partition größer erstellen: bei 16 GiB ("nur" etwas über 7 GB frei), zerschießt es sich beim booten irreparabel…)

 

[Caramon2]

Wie man die originalen Römer aus WinVice bekommt, ist im C64-Wiki beschrieben.

Das funktioniert bei COS nicht.

Ich habe die ROMs nach dem /usr/share/doc/vice/README.ROMs gerichtet:

But the most authentic source of the ROMs is the VICE source package itself,
under the data/ directory.
It can be downloaded from https://vice-emu.sourceforge.io/ .

Man lädt das Archiv, entpackt den "data"-Ordner, benennt ihn "vice" und verschiebt ihn nach ~/.local/share/

Beim LMDE 6, wo Vice ohne ROMs installiert wird, funktioniert das wunderbar, aber beim COS hat das keinen Effekt: Der C64 startet weiterhin mit dem freien ROM und der C128 und VC20 starten gar nicht. (andere habe ich nicht getestet)

Also das Terminal geöffnet, "sudo apt purge vice" ausgeführt, dann alles was ich noch mit "sudo find / -iname "vicerc*"" und "sudo find / -iname "vice"" finden konnte gelöscht und anschließend "vice" neu installiert. (es ist definitiv das originale aus den Debian-Quellen - also COS nutzt nur die anderen Voreinstellungen, die ich gelöscht hatte)

Ergebnis:

Offenbar liegt das an der uralten Version 3.5: Die erwartet "basic", "chargen" und "kernal" sucht, statt der vorhandenen "basic-901226-01.bin", "chargen-901225-01.bin" und "kernal-901227-03.bin".

Benenne ich die entsprechend um, funktioniert es wie es soll. - Dto. beim VC20 und dann wohl auch bei den anderen. Aber das habe ich nicht mehr getestet.

LMDE 6 nutzt die 3.7 und mein Produktivstem (Artix) die aktuelle 3.8: Da muss nichts umbenannt werden.

Am einfachsten könnte man das wahrscheinlich lösen, indem per Synaptic/Paket/Version erzwingen auf Vice 3.7 aktualisiert:

Auf die Art habe ich LMDE 6 vom Kernel 6.1-LTS auf den jeweils aktuellen "stable-backport" umgestellt: Vorletzte Woche hat es den 6.9.7 bekommen.

Aber bei COS passiert nicht: Es kommt keine Fehlermeldung, sondern es springt einfach wieder auf die 3.5 zurück.

Die Optik von Commodore OS st wirklich schön und aufwendig gemacht, aber unter der Haupt stoße ich auf immer mehr Murks und auch dieses Compiz ist eine Seuche:

Das Livesystem ist praktisch unbenutzbar, wenn ich bei der VM Hardware-3D (-vga none -device virtio-vga-gl) aktiviert habe: Die Anzeige wird nur aktualisiert, wenn ich das QEMU-Fenster minimiere und ist bei wiederhergestellten Fenster wieder eingefroren!

Ich dachte, ist es erst mal installiert und aktualisiert, ist das kein Problem mehr. - Falsch gedacht…

Aber selbst nur mit "-vga virtio" bleiben die Übergangsanimationen immer mal wieder für mehrer Sekunden hängen (die VM friert praktisch ein), so dass ich froh bin, wenn Compiz sich nach einiger Zeit deaktiviert (oder abstürzt: diesem Schrott traue ich nicht) und die Fensterdekoration nicht mehr so schön aussieht (wie bei den Shot oben - verglichen mit dem GParted-Shot von gestern), man es aber endlich halbwegs flüssig nutzen kann.

Ich werde es noch eine Weile behalten und erkunden, kann diesen Monat aber nicht mehr viel machen, da ich sonst bald "handlungsunfähig" bin: Nur noch 106 MiB Traffic…

COS hat mich 7/12 GiB gekostet: 5,5 GiB fürs ISO und ca. 1,5 GiB für Updates und Tests. - Sonst hätte ich wieder mehrere GiB übrig und müsste mir was mehr oder weniger sinnvollen suchen, um die nicht verfallen zu lassen.

 

[Caramon2]

Offenbar liegt das an der uralten Version 3.5: Die erwartet "basic", "chargen" und "kernal" sucht, statt der vorhandenen "basic-901226-01.bin", "chargen-901225-01.bin" und "kernal-901227-03.bin".
[…]
Am einfachsten könnte man das wahrscheinlich lösen, indem per Synaptic/Paket/Version erzwingen auf Vice 3.7 aktualisiert:

Noch einfacher ist, die dazu passende WinVice Version 3.5 zu laden und die ROMs daraus nach "~/.local/share/vice/" kopieren: Older Binaries

Das reicht schon, da die bevorzugte genutzt werden: Also an den vorinstallierten Konfigurationen und ROMs muss nichts geändert werden!

Einzig der PET funktioniert dann immer noch nicht, da trotz der selben Vice-Version div. Dateien nicht gefunden werden. - Ob umbenennen hilft, habe ich nicht getestet: Wen interessiert schon der PET?

Btw: Noch 61 MiB Traffic.

 

[Tanzmusikus]

Noch 61 MiB Traffic.

... und 29 Stunden um auch diesen noch zu nutzen. 🤓

 

[Caramon2]

Merkwürdigerweise bin ich lt. Handy schon 4 MiB drüber, ohne dass es auf 32 kpbs (lässt mich wieder an War Games denken ) gedrosselt wurde.

Da der Provider anders rechnet und auch den Traffic auf der eigenen Seite nicht mitzählt (zum Rechnung+EVN laden) variiert das etwas.

 

[Tanzmusikus]

4 MiB

4 MiB oder 4 MB? 😉

Dann kannst ja jetzt in Ruhe offline Commodore-Spiele zocken.

 

[Caramon2]

4 MiB oder 4 MB? 😉

Beides:

1. Das Handy zeigt für Blöde *) "MB" an, es sind aber natürlich "MiB" gemeint. - Ich finde es wirklich schade, dass Google das bei Android so verbogen hat, obwohl sie die Marktmacht gehabt hätten, das endlich richtigzustellen: MiB usw. wurden lt. Wikipedia schon 1996 spezifiziert: Windows zeigt das also schon seit über einem Vierteljahrhundert falsch an!
2. Da ich die Nachkommastelle weggerundet hatte, war das im Rahmen der Messetoleranz.

Erst als ich 12,4 MiB drüber war, kam die SMS, dass "dicht" gemacht wurde: Leider mit einem "Pling", statt dem Einwahlgeräusch eines Analogmodems.

Durch die hohe Opera-Mini-Komprimierung kann ich trotzdem noch brauchbar surfen.

…

*) evtl. missverständlich: Ich wollte damit nicht behaupten, jemand wäre blöde, sondern dass Google die Nutzer offenbar für blöde hält: Also macht man es genauso falsch wie Microsoft, da die Leute es ja nicht anders kennen und man ihnen offensichtlich auch nicht zutraut, es zu verstehen.

 

[Tanzmusikus]

Mach dir kein Kopf. Das ist Marketing.
Wie sollen die Datenträger-Hersteller damit umgehen, dass sie auf einmal z.B. 0,931TiB statt 1TB verkaufen.
Oh ... oh echt? ... oh ja ... oh nein ... oh doch ... oh bitte nicht ... ach na gut ihr bekommt 1TiB dafür.


Ist doch mit der Sommerzeit +1h ähnlich. Wer braucht die schon ... bietet es wirklich mehr Vor- als Nachteile? 😆

 

[Caramon2]

vorab: Ich habe oben etwas nachgetragen.

Mach dir kein Kopf. Das ist Marketing.
Wie sollen die Datenträger-Hersteller damit umgehen, dass sie auf einmal z.B. 0,931TiB statt 1TB verkaufen.

1 TB bei Datenträgern ist doch richtig.

Falsch ist, dass Windows es als 0,909 TB *) anzeigt: Da die Laufwerke immer größer werden, klafft das immer weiter auseinander und ist bei TB<>TiB schon größer als die Differenz zwischen Yards und Metern:

Bei Microsoft muss sozusagen ein 100 Meter Läufer nur 91,44 "echte" Meter laufen. Und bei einem Auto wäre der angegebene Verbrauch auf 100 km tatsächlich nur für 91,44 km ermittelt.

Und Google macht das bei Android genauso.

*) du hattest GB<>GiB berechnet

Ist doch mit der Sommerzeit +1h ähnlich. Wer braucht die schon ... bietet es wirklich mehr Vor- als Nachteile? 😆

Meine BS (auch Windows) nutzen schon lange die UTC.

Früher, mit zwei parallelen Windows-Installationen war das immer wieder nervig:

Das Haupt-Windows setzt die Zeitumstellung lokal um und wenn ich irgendwann (vielleicht erst Wochen später - es war nur als Backup gedacht, falls sich das primäre zerlegt) das andere boote, verstellt es auch die lokale Uhrzeit und sie geht falsch.

Ich hatte die Windows-Partition regelmäßig als Image gesichert und als ich es einmal wiederherstellte, ging anschließend die Uhr falsch, weil das Image von vor der letzten Zeitumstellung war…

Nachdem ich erfahren hatte, dass (und wie) man Windows auf UTC stellt, kam so etwas nie wieder vor.

…

Außerdem hat Windows "schon immer" ein generelles Problem damit: s. Anhang

 

[Tanzmusikus]

Meine BS (auch Windows) nutzen schon lange die UTC.

... meine Windows-BS auch seit ein paar Jahren. 👍
Gibt da einen entsprechenden Registry-Eintrag, womit auch Windows die UTC nutzt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

---

Ich meinte allerdings die Sommerzeitumstellung +/-1h Sommerzeit/Winterzeit, womit eigentlich Strom gespart werden sollte usw. Dies hat wie Vieles nicht wirklich funktioniert. Stattdessen werden die Menschen (und ggf. auch die Haustiere!!) in DL 2x im Jahr quasi gezwungen, sich auf die +/-1h Zeitverschiebung umzustellen.

Falsch ist, dass Windows es als 0,909 TB *) anzeigt:

Da hast Du Recht: 0,909 TiB = 931,323 GiB = 953.674,316 MiB = 976.562.500 kiB = 1TB.
M$ berechnet da einiges falsch. Es nutzt z.B. die Dezimalschreibweise für beide Zahlensysteme.

Es ist auch m.M.n ein (nicht ganz unwichtiges) Problem, was M$ da mit sich schleppt.
Ich sehe eine "falsche Anzeige" in Dezimal- statt Binärschreibweise und sogar eine "fehlerhafte Berechnung".

Berechnet wird z.B. für ein Datenträger von 1TB = 1000GB. Dies wäre korrekt wg. 10⁴ = 1000 * 10³.

Angezeigt wird i.d. Datenträgerverwaltung: 1TB = 931,51GB*. Dies wäre fast** korrekt.
*M$ benutzt ausschließlich die Dezimalschreibweise (auch für Binär): 1TB = 931,xxGiB sollte das eigentlich sein.
**Korrekt umgerechnet wäre es aber so: 1TB = 931,32GiB -> NICHT: 1TB = 931,51GiB. 🤓👍
M$ geht bei der Umrechnung leider nicht auf die unterste Ebene "Byte", sondern nur bis "kByte".
Somit wird wirklich nochmals mit falschen Werten umgerechnet.

 

[Caramon2]

Angezeigt wird i.d. Datenträgerverwaltung: 1TB = 931,51GB*. Dies wäre fast** korrekt.
*M$ benutzt ausschließlich die Dezimalschreibweise (auch für Binär): 1TB = 931,xxGiB sollte das eigentlich sein.

Das kannst du so nicht sagen. Mir ist jedenfalls noch nie ein Datenträger untergekommen, der ganz genau die angegebene Kapazität hatte.

MS rechnet quasi richtig, nur nutzen sie die falschen Einheiten: Sie schreiben immer noch MB & Co. *), obwohl MiB & Co. gemeint sind.

*) da es vor 1996 noch kein MiB & Co. gab, hatten sich damals KB, MB, usw. als Näherungswerte eingebürgert

Ein sehr gutes Beispiel hat mal der Heinz Schmitz geliefert (u. a. unterrichtet er Informatik auf der Uni (oder sowas in der Art - er erzählt jedenfalls immer mal wieder was von Vorlesungen, die er hält und in vielen Dingen hat er wirklich was drauf) - sollte sich also auskennen…):

Er zeigte in einem seiner Videocasts, wie er in einem GUI-Dialog einen 50 MB Container erstellte und wunderte sich dann, dass der im Explorer mit 51200 KB angezeigt wurde: Er hat das dann damit erklärt, dass es durch den Protokoll-Overhead "natürlich" etwas größer wird.

Dabei sind 50*2^20 genau 51200*2^10
(2^10=1024, 2^20=1024^2, 2^30=1024^3, usw.)

Ich nenne sowas "Windows-verblödet" - und kenne das auch gut aus eigener Erfahrung: Für mich wurde erst Licht, nachdem ich 2015 damit anfing mich intensiv mit Linux zu beschäftigen:

Mir war vorher überhaupt nicht klar, was für ein Idiot ich war, wenn ich aus tiefster Überzeugung behauptete, ich würde mich sehr gut mit PCs auskennen! - Ich wusste fast gar nichts!

Würde ich mein damaliges Ich jetzt treffen und es würde das genauso überzeugt behaupten, würde ich wahrscheinlich vor lauter lachen zusammenbrechen.

 

[Tanzmusikus]

Das kannst du so nicht sagen.
Mir ist jedenfalls noch nie ein Datenträger untergekommen, der ganz genau die angegebene Kapazität hatte.

Doch, das kann ich so sagen.
Ob und wie viele zusätzliche Sektoren bzw. Speicherzellen auf dem Datenträger verfügbar sind, ist dabei unwichtig. Es zählt letztlich die vom Hersteller angegebene Größe des Speicherplatzes.

Das Problem ist, dass seitens Windows die Umrechnung 1TB in GiB nicht korrekt zu sein scheint.
Bei mir werden z.B. mehrere 1TB-Datenträger (2x NVMe, 1x HDD) mit der selben Größe angezeigt.

Rechne ich dies allerdings aus, dann komme ich bei 1TB statt 931,51 GiB auf nur 931,32 GiB.

Quelle: https://www.unitjuggler.com/memory-umwandeln-von-GiB-nach-TB.html?val=931.51

Quelle: https://www.online-rechner.net/datenmenge/gibibyte/

Ich hoffe, man versteht jetzt, was ich meine mit "falschem Umrechnen" seitens M$ Windows.

Wenn nicht, dann TL;DR:
Selbst wenn M$ Windows' Speicherplatzwerte: 1TB = 931,XXGB als GibiByte: 1TB = 931,XXGiB interpretiert werden, gibt es zusätzlich noch den Umrechungsfehler: 1TB = 931,51GiB seitens M$, da 1TB = 1000 GB = 931,32GiB sind.
Linux zeigt es auch nicht anders an.

Spoiler: Wie kann das sein?

Antwort: Die Hersteller verwenden 1.000.204.886.016 Bytes (= 931,51 GiB bzw. 1000,204 GB) für 1TB-Datenträger.
(Siehe auch nächsten Beitrag! Besten Dank an @Caramon2!)

 

[Caramon2]

Das Problem ist, dass seitens Windows die Umrechnung 1TB in GiB nicht korrekt zu sein scheint.
Bei mir werden z.B. mehrere 1TB-Datenträger (2x NVMe, 1x HDD) mit der selben Größe angezeigt.

Ich denke das sollten wir jetzt lassen, da das eher eine Hardwaresache ist und mit der Kernthematik, dass Microsoft für die 1024er Basis immer noch GB usw. schreibt (was 10er Basis bedeutet), nichts zu tun hat.

Rechnerisch richtig ist es nur mit der tatsächlichen Größe des Laufwerks (mit GParted, Rechenweg und Gegenprobe):

("Laufwerke" ist "gnome-disks", der Rechner ist "gnome-calculator")​

Rückfragen bitte per PN.

---

Grund meines Schreibens ist, dass ich endlich herausgefunden habe, wie man die Lokalisierung vollständig umsetzt:

Man logt sich kurz aus:

Wichtiger Nachtrag: Offenbar hatte ich bei meiner Installation schon was anderes geändert, weil bei einer frischen Installation reicht kurzes ausloggen nicht, sondern man muss dort beides auf Deutsch stellen:

Wenn man sich wieder einloggt, wird gefragt, ob die Standardordner umbenannt werden sollen (das bestätigen):

Fertig:

Es gibt zwar noch ein paar nicht lokalisierte Sachen, aber dafür gibt es dann eben keine deutsche Übersetzung.

Dann gibt es bei "Software & Updates" auch endlich Server für Deutschland (vorher Australien - noch weiter weg wäre nur noch Neuseeland):

 

[Caramon2]

Update: Es hat sich neues bzgl. der Lokalisierung ergeben.

 

[Caramon2]

bei einer frischen Installation reicht kurzes ausloggen nicht, sondern man muss dort beides auf Deutsch stellen

Das funktioniert auch beim Livesystem und dann ist auch der Installer deutsch.

Da er keinen Startmenüeintrag hat, muss man das Terminal öffnen, sich mit "sudo -i" rooten und dann "/bin/minstall-launcher" ausführen:

Der Installer zeigt das "TB" übrigens falsch an: Das Image hatte ich mit glatten 4 TB (4*10^12 Byte) erstellt: ca. 3,638 TiB (4×10^12÷1024^4).

Von daher ist das "GB" dort auch falsch, da die Root-Partition ca. 74 GiB hat (Rundungsfehler durch den ungenauen Schieberegler):

und definitiv keine 74 GB:

Wichtig ist, dass eine Swap eingerichtet wurde, obwohl im Installer nichts von einer zu sehen war. Auch stört mich der freie Platz hinten, was auch nur ein Rundungsfehler ist und ext4 gehört meinen Erfahrungen nach zu den schlechtesten Dateisystemen, auf dem man Linux installieren kann: Ich bevorzuge xfs, da sehr schnell und nahezu unkaputtbar, oder btrfs+zstd, wegen der Komprimierung.

Deshalb partitioniere ich selbst: Der automatischen Partitionierung kann man bei keinem einzigen Installer trauen: Weder Windows noch Linux.

Bei einem hier aus dem Forum, der Suse Tumbleweed auf seiner NVMe-SSD installiert hatte, passte letztes Jahr bei der Swap-Partition (also worauf bei entsprechender Speicherlast besonders oft geschrieben wird + S2D) noch nicht mal das Alignment!

 

[Caramon2]

Ich habe seit längerem mal wieder C=OS aktualisiert: u. a. hat es den Kernel 6.10.6 bekommen - wie auch meine LinuxMint Debian-Edition Testinstallation, wie auch letzte Woche mein Produktivsystem (Artix: ein Arch-Derivat).

Also die Zeiten, dass eine Debian-Basis "veraltet und Rückständig" bedeutet, sind offenbar vorbei.