Aki's Vibes

[Akira]

Huhu zusammen,

tl;dr In diesem Vibe geht es ums Aufräumen. Gedanken zu Plugins, Dependency Injection und Factories.

Diese Woche hab ich nicht viel am Simulator rumgevibed. War anderweitig engagiert. Deshalb erzähle ich nun etwas zu der Idee, warum ich am Sim oder genauer gesagt dem Region-Server rumwerkle. Was mich eigentlich schon längere Zeit stört, der Region-Server ist überladen! Eigentlich beginnt das schon beim Namen. Neben dem Region-Server, gibt es ja noch den Grid-Server, der "Robust" genannt wird. Ausser der Region Server wird im Standalone Modus betrieben, dann ist die Funktionalität im Region Server eingebaut, besser gesagt zusammengesteckt.

Dieses zusammenstecken ist im Prinzip eine spannende Sache, so können die Module im Region-Server für Standalone und im Robust Server wiederverwendet werden. Auch wird die Möglichkeit geboten, Plugins für den Simulator zu entwickeln. So weit, so gut. Ein Plugin System wird dann richtig lustig, wenn es dann irgendeinen Marketplace gäbe, in welchem Plugins geholt werden können, mit denen der Simulator mit Funktionalität erweitert werden könnte. Leider hat sich diesbezüglich ausser einigen Money Plugins nicht sehr viel entwickelt. Schön wäre es, wenn die Trennung zwischen dem Grundgerüst und den Plungins sauberer getrennt wären, sodass ich, falls ich gerne die Ubode Physik hätte, beispielsweise ein bereits geliefertes Physik Plugin austauschen könnte. Aktuell sind all diese Module oder Plugins mehr oder weniger wild im Code verteilt. Es existiert ein Folder addon-modules. Aber im OpenSim Code Folder existieren ebenfalls zwei Projekte OpenSim.Addon.Groups und OpenSim.Addon.OfflineIM. Und das ganze noch in mehreren Ausprägungen.

Für meinen Geschmack zu viel Durcheinander. Und wir Schweizer mögen Durcheinander nicht. Wir lieben es aufgeräumt. Wir räumen gerne alles auf:



Also hab ich mir ein paar Gedanken gemacht, was ich eigentlich gerne möchte.

• Brauche ich Robust? Nö ich habe den Php-Gridserver
  
• Brauche ich die Standalone Möglichkeit? Nö ich betreibe Sims nur im Hypergrid Modus.
  
• Brauche ich 10 Physik-Engines? Nö, Ubode und Bullet reichen eigentlich. Bullet brauch ich nur wegen der 3D Meshes die ich importiert hab, weil bei Ubode müsste ich nochmals importierten.
  
• Scripting Engines. Hat sich inzwischen auf eine reduziert. Glücklicherweise.
  
• Weitere Modules die ohne Sinn und Zweck rumliegen entfernen.
  
• Mono.Addins als Plugin System loswerden wird nicht mehr weiterentwickelt. Brauch ich wirklich Plugins?
  

Auch wenn die Konzeption der Mono.Addins ziemlich cool ist, die Tatsache, dass es nicht mehr weiterentwickelt wird und auch das Plugin Konzept nicht so prickelnd umgesetzt ist, sagte ich mir: Raus damit!

Um mit Modulen umzugehen, existieren mehrere Muster:

• Plugins
  
• Dependency Injection
  
• Factories
  

Die drei Muster im Vergleich

Plugin-System (Mono.Addins, System.Composition)

• Findet automatisch Implementierungen in Assemblies
  
• "Zeig mir alle Klassen, die ICommand implementieren"
  
• Für unbekannte, dynamische Erweiterungen
  

Dependency Injection (DI Container)

• Verwaltet Objektlebensdauer und injiziert Abhängigkeiten
  
• "Gib mir die registrierte Implementierung von ILogger"
  
• Für lose Kopplung innerhalb bekannter Komponenten
  

Factory

• Kapselt Objekterstellung mit Logik
  
• "Erstell mir ein Objekt basierend auf diesen Runtime-Parametern"
  
• Für komplexe oder parameterabhängige Instanziierung
  

Aktuell hab ich mich für eine Factory-Lösung entschieden. Aber könnte mir vorstellen, dass wenn ich das Testing überarbeite, ich vermehrt auf Dependency Injection umsteigen werde. Schon seit einiger Zeit erledigt:

• Mono.Addins rausfakturiert und durch Factories ersetzt
  
• Module die nur für den Standalone Betrieb notwendig sind entfernt
  
• Uralte Module die nicht mehr notwendig sind entfernt
  

Hab den Sim schon mal angetestet, aber es traten noch einige Seiteneffekte auf also wieder zurück ins Labor. Und genau deshalb überleg ich mir auch den Smart Thread Pool zu entfernen, um noch mehr Standardkomponenten zu verwenden, mit dem finalen Ziel keine .dll mehr im Github Repository und alles mit NuGet managen. Bin mal gespannt, wozu ich nächste Woche komme.

Ob das ganze jemals die Qualität hat um im Grid eingesetzt zu werden, weiss ich noch nicht. Die Vibes sind Sachen an welchen ich im Moment herumexperimentiere, immer mit einem konkreten Ziel welches ich habe.

[Akira]

Huhu zusammen,

tl:dr Dll im bin verzeichnis ohne Source

In einem dem letzten Beitrage hab ich ja angekündigt den SmartThreadPool auszubauen. Ok das war kein grosses Ding. Claude brauchte genau 13 Minuten dafür und alles funktionierte auf Anhieb.

Nun kommt ein wesentlich komplizierteres Projekt: Die Änderungen vom OpenSim in meinen Sim hineinmergen. Mit Claude lass ich das nicht machen. Da gehe ich lieber händisch vor. Die Schwierigkeit: Vor einiger Zeit habe ich auf eine flache Struktur umgestellt. Die flache Struktur der Verzeichnisse entspricht der Projektstruktur, wie wir sie beispielsweise in der IDE sehen:



OpemSim hat seine Struktur jedoch in Verzeichnis Hierarchien abgelegt also beispielsweise OpenSim/Data/MySql. Ich hatte die Hoffnung, dass ich, wenn ich mit Symlinks die OpenSim Struktur nachbilde, der Merge einfacher ist. Leider hab ich schon zu viel geändert da muss ich ein anderes Vorgehen wählen.

Einige Dateien hatte ich bereits umgestellt, da fiel mir etwas auf: Nini hat sich geändert! Das ist hässlich! Klar das einfachste ist aus dem originalen OpenSim die korrekte Nini.dll holen und das Problem ist gelöst. Ich will das aber nicht, siehe meine früheren Posts. Libraries, welche ich nicht selbst baue sollen vom NuGet Repository bezogen werden. Im Falle der Nini.dll habe ich ein wenig geforscht. OpenSim hat die notwendige Info bereits gespeichert. In den ThirdPartyLicenses sind all die Lizenzen abgelegt, unter welchen die entsprechende Libraries veröffentlicht werden. In der Nini Lizenz sehe ich folgenden Entwickler: Brent R. Matzelle. Es existiert sogar ein Github Repository https://github.com/bmatzelle/nini

Zusätzlich gibt es diverse NuGet Repositories welche die entsprechende DLL zur Verfügung stellen. Bloss:



EnvConfigSource welche von OpenSim reingemerged wurde, existiert im Original nicht !!! Korrekt wäre in diesem Fall: Einen Pull Request an den Owner des https://github.com/bmatzelle/nini Source Repository, damit er eine neue Version baut. Falls er diese Aenderungen aus welchen Gründen auch immer nicht möchte, ein neues Repository erstellen und den Link irgendwo deutlich dokumentieren. Einfach eine neue Datei Nini.dll in dem bin Verzeichnis abzulegen ist in der heutigen Zeit nicht mehr State of the Art.

Wer weiss wo ich die Sourcen zur aktuellen Nini.dll finde und auch zu sämtlichen andern Third Party libraries. Für Sachdienliche Hinweise bin ich äusserst dankbar!

Liebe Grüsse
Akira

[Christoph Balhaus]

Wer weiss wo ich die Sourcen zur aktuellen Nini.dll finde und auch zu sämtlichen andern Third Party libraries. Für Sachdienliche Hinweise bin ich äusserst dankbar!

In https://github.com/opensim/opensim-libs hast du schon geschaut? Oder sind die Nini Sourcen darin nicht mehr aktuell? Ich habe das selber noch nicht genutzt...

[Akira]

In https://github.com/opensim/opensim-libs hast du schon geschaut? Oder sind die Nini Sourcen darin nicht mehr aktuell? Ich habe das selber noch nicht genutzt...

Vielen Dank Christoph! Habe kurz nachgeschaut. Folder trunk ist der Schlüssel, da hat es zwei Folder managed und unmanaged und im managed ist's drin zusammen mit den andern repos und sogar mit den entsprechenden Anpassungen!

Warum es in Nuget nicht zu finden ist, wird im Read.me schnell klar. Hier steht:

Opensim will avoid to use Nuget whenever possible. In same cases we may extract and use only the files we need out of the nuget packages garbage.

Okay, wenn die Nuget schon als garbage bezeichnen. 99.9% der Entwickler sehen das wohl anders. Nuget ist offizieller Standard und heutzutage entwickelt niemand mehr ohne Library Management. Hat durchaus Vorteile. Automatische Versionskontrolle, automatische Security Scans. Klar unterbricht es den flow etwas, wenn deine Pipeline failed, wenn du plötzlich eine vulnerability drin hast. Aber typischerweise sind dies rasch gefixt und man kann das Projekst schnell auf die gefixte Version anheben. Für mich sieht Garbage anders aus.

[Akira]

Huhu zusammen,

Diese Woche hatte ich auch nicht so viel Zeit etwas zum viben. Ich bin ja aktuell am Mergen der Änderungen im OpenSim Code von Ubit und Co in meinen Sim. Typischerweise ist das ein recht einfacher Vorgang, solange man nicht am Simulator Code herumschraubt. Tja nun ist es etwas komplizierter, aber ich denke in ein oder mehren Wochen sollte ich auf dem aktuellsten Stand sein.

Die Nini Library hab ich inzwischen auf dotnet 8 angehoben und ins Nuget Repository gestellt. Also aktuell viel einfaches Gedöns, welches völlig uninteressant ist. Werde mich wieder melden, wenn ich wieder an etwas Interessanterem arbeite.

Liebe Grüsse
Akira

[Akira]

Hab mal eine kleinere Uebung mit Linux durchgemacht übers Wochenende:

MacBook Pro Dual-Boot Setup
macOS + CachyOS Linux mit rEFInd & GRUB
Hardware: MacBook Pro 16" 2019 (Intel, T2-Chip) | Datum: 1. März 2026

---

1. Ausgangslage & Ziel

Das Ziel war ein funktionierendes Dual-Boot-System auf einem MacBook Pro 16" (2019) mit Intel-Prozessor und T2-Sicherheitschip. Als Linux-Distribution wurde CachyOS gewählt, als Boot-Manager rEFInd.

Herausforderungen

• T2-Chip blockiert unsignierte Bootloader
  
• FileVault-Verschlüsselung verhindert rEFInd-Start
  
• Broadcom BCM4364 WLAN benötigt proprietäre Firmware
  
• btrfs-Dateisystem wird von rEFInd nicht automatisch erkannt
  

---

2. Vorbereitung macOS

Sicherheitseinstellungen deaktivieren

1. SIP deaktivieren: Recovery Mode → Terminal →
   Code:

   csrutil disable
2. Secure Boot deaktivieren: Recovery Mode → Dienstprogramme → Sicherheitsdienstprogramm → "Ohne Sicherheit" + "Externes Booten erlauben"
   
3. FileVault deaktivieren: Systemeinstellungen → Datenschutz & Sicherheit → FileVault ausschalten (vollständig warten bis Entschlüsselung fertig!)
   

Partitionierung

500 GB SSD aufgeteilt in:

• disk0s1: 314 MB EFI (Apple, original)
  
• disk0s2: 250 GB APFS (macOS)
  
• disk0s3: 2.1 GB EFI FAT32 (Linux EFI, neu erstellt)
  
• disk0s4: 247 GB Linux Filesystem (CachyOS)
  

---

3. rEFInd Installation

Installationsweg

rEFInd muss aus macOS (nicht Recovery) installiert werden, da der T2-Chip nur NVRAM-Einträge akzeptiert die von macOS selbst gesetzt werden. Installation mit SIP deaktiviert:

Code:

sudo ./refind-install

Probleme & Lösungen

• fcopyfile failed Fehler: Harmlos — nur macOS-Dateiattribute können nicht auf FAT32 kopiert werden. rEFInd funktioniert trotzdem.
  
• Hängt beim Booten: Verursacht durch fehlende btrfs_x64.efi Treiber. Gelöst durch Entfernen unnötiger Treiber aus drivers_x64/
  
• Linux nicht im rEFInd-Menü: CachyOS verwendet btrfs, rEFInd kann das Dateisystem ohne Treiber nicht lesen.
  

refind.conf Konfiguration

• Code:

  timeout 5
  — 5 Sekunden Wartezeit
  
• Code:

  default_selection "Boot macOS from Preboot"
  — macOS als Standard
  
• Unnötige Treiber entfernt: ext2, hfs, iso9660, reiserfs
  

---

4. CachyOS Installation

Bootloader-Wahl

Ursprünglich rEFInd gewählt, aber Calamares installiert rEFInd nicht korrekt auf die EFI-Partition. Lösung: GRUB als Bootloader gewählt — dieser wird von Calamares zuverlässig installiert.

Partitionierung im Installer

• Manuell partitioniert
  
• disk0s3 (2.1 GB EFI) → /boot/efi, nicht formatieren
  
• disk0s4 (247 GB) → / (root), btrfs, formatieren
  
• Apple EFI (disk0s1) nicht angetastet
  

LTS-Kernel

Der Standard CachyOS-Kernel startete nicht korrekt (Plymouth-Hänger). Gelöst durch Wechsel zum LTS-Kernel (linux-cachyos-lts, Version 6.18.15). GRUB-Standard auf LTS gesetzt:

Code:

GRUB_DEFAULT="1>1"
GRUB_CMDLINE_LINUX_DEFAULT=""

---

5. WLAN-Konfiguration (BCM4364)

Problem

Der Broadcom BCM4364 (rev 04, Codename "bali") benötigt proprietäre Apple-Firmware. Der broadcom-wl Treiber unterstützt diesen Chip nicht. Der brcmfmac Treiber funktioniert, braucht aber die richtigen Firmware-Dateien.

Lösung

1. broadcom-wl-dkms deinstallieren — blockierte brcmfmac:
   Code:

   sudo pacman -R broadcom-wl-dkms
   
   
2. Richtigen Chip-Codename ermitteln — aus dmesg ablesen welche Firmware der Kernel sucht:
   
   Code:

   sudo dmesg | grep -i brcm
   Ausgabe zeigt: using brcm/brcmfmac4364b3-pcie for chip BCM4364/4 und Codename bali
   → MacBookPro16,1 verwendet B3-Chip mit Codename "bali" (nicht B2/ekans!)
   
   
3. Firmware-Dateien in macOS auf USB kopieren — alle drei Dateien werden benötigt:
   
   Code:

   cp /usr/share/firmware/wifi/C-4364__s-B3/bali.trx /Volumes/USB/brcmfmac4364b3-pcie.bin
cp /usr/share/firmware/wifi/C-4364__s-B3/bali.clmb /Volumes/USB/brcmfmac4364b3-pcie.clm_blob
cp /usr/share/firmware/wifi/C-4364__s-B3/bali.txcb /Volumes/USB/brcmfmac4364b3-pcie.txcap_blob
   Wichtig: Alle drei Dateien sind notwendig! Ohne clm_blob und txcap_blob schlägt der Scan mit Fehler -52 fehl.
   
   
4. Dateien in CachyOS installieren:
   
   Code:

   sudo cp /run/media/akira/USB/brcmfmac4364b3-pcie.* /lib/firmware/brcm/
sudo modprobe -r brcmfmac
sudo modprobe brcmfmac
   
   
5. brcmfmac für automatisches Laden eintragen:
   
   Code:

   echo "brcmfmac" | sudo tee /etc/modules-load.d/brcmfmac.conf

WLAN verbinden

Code:

nmcli device wifi connect "Netzwerkname" key-mgmt wpa-psk password "Passwort"

---

6. Endresultat

Funktioniert ✅

• Dual Boot macOS + CachyOS über GRUB
  
• rEFInd als optionaler Boot-Manager (über Apple EFI)
  
• WLAN (BCM4364) mit Apple-Firmware
  
• AMD Radeon RX 5500M GPU
  
• Akku-Erkennung
  
• Display (3072x1920)
  

Noch ausstehend

• Audio (Texas Instruments TAS2770 Verstärker)
  
• Touch Bar (
  Code:

  tiny-dfr
  aus AUR)
  
• rEFInd Theme verschönern
  
• WLAN automatischer Start beim Boot verfeinern
  

---

7. Wichtige Erkenntnisse

• FileVault muss deaktiviert sein bevor rEFInd als Bootloader funktioniert
  
• rEFInd muss aus macOS (nicht Recovery) installiert werden damit NVRAM-Einträge korrekt gesetzt werden
  
• Separate Linux-EFI-Partition empfohlen um Konflikte mit Apple EFI zu vermeiden
  
• GRUB ist für CachyOS/Calamares zuverlässiger als rEFInd als primärer Bootloader
  
• broadcom-wl-dkms und brcmfmac sind inkompatibel — nur eines kann aktiv sein
  
• Apple-Firmware für BCM4364 liegt in macOS unter
  Code:

  /usr/share/firmware/wifi/C-4364__s-B3/
  (Codename "bali" für MacBookPro16,1)
  

[Bogus Curry]

Bei mein macbook air m3 chip würde glaube ich, nicht so einfach?

[Dorena Verne]

Da kann ich dir sogar antworten, Bogus. Definitiv nein.

[Akira]

Bei mein macbook air m3 chip würde glaube ich, nicht so einfach?

So einfach ... du bist lustig. Das was ich hier gepostet habe, war ein Zwischenstand. Da läuft noch einiges nicht. Im Moment kämpfe ich gerade mit der Touchbar.

Die Apple Chips M* sind ein anderes Kaliber, ist ja eine völlig andere Prozessorarchitektur. Soviel ich weiss gibt es erst Asahi Linux welches auf M*-Macs läuft.