Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Web App]

Nochmal zur Verdeutlichung:

Ich baue eigentlich einen Docker-Container für Telerising-Binaries. Damit dieser möglichst klein ist erstelle ich die Binary und packe sie in einen Scratch-basierten Container. "Scratch" bedeutet, dass es sich um ein absolut minimales Linux handelt, das im Prinzip nur und ausschließlich bootfähig, aber ansonsten komplett nackt ist. Da Docker grundsätzlich Container für mehrere Architekturen erlaubt bei denen es dann selbst entscheidet, welcher Container passt, baue ich aktuell hierfür für amd64, arm32v7 und arm64v8. Das ist das, wofür ich mich aktuell eigentlich verantwortlich fühle - und das bauen dauert momentan ca. 3-4 Stunden für diese 3 Versionen. Als OS für das Bauen wird dabei noch ein Debian Buster benutzt, da es hier in der Vergangenheit mit neueren Versionen Probleme gab.

Nun gab es mit den anderweitig bereitgestellten Binaries immer mal wieder Probleme, so das ich letztlich (weil ich sie eh bauen muss) in meinem Repo die Standalone Binaries mit an das Release hänge. Die meisten von Euch verwenden irgendein Modell des RPIs und haben jetzt irgendwie gefühlt den Anspruch, es müsse da doch laufen...

Dazu kann ich Euch nur sagen: Nein, muss es nicht. Denn leider ist in diesem Zusammenhang ARM sehr viel komplizierter als AMD64 und die Entscheidung von Raspberry einfach mal so von 4k Pagesize (was normal ist) auf 16k umzustellen macht die Sache nochmal deutlich komplizierter. Docker z.B. ist gar nicht dazu in der Lage die Pagesize irgendwo mit einfließen zu lassen. Ein Image ist armv7, oder eben nicht. Passt es von der Architektur her zusammen, dann wird es genommen. Laufen muss es deswegen aber nicht zwangsläufig.

Ich bin gerne bereit meine Binaries, ab vom Docker, etwas zu erweitern. Dafür brauche ich aber Eure Unterstützung. Was die RPIs dieser Welt angeht gehe ich momentan von folgendem aus:

RPI mit Pi OS auf Basis von Debian Buster:

=> Da die Pagesize hier 4k sein müsste und die Binaries für Docker auf Buster gebaut werden sollten hier die arm32v7 bzw. arm64v8 binaries laufen

RPI mit Pi OS auf Basis von Debian Bullseye:

=> Auch hier ist die Pagesize meines Wissens nach 4k und es sollten eigentlich die arm32v7 bzw. arm64v8 binaries aus Buster laufen

RPI mit Pi OS auf Basis von Debian Bookworm:

=> Pagesize ist hier 16k, ergo müssen sowohl die arm32v7 als auch die arm64v8 binaries explizit darauf/dafür gebaut werden

Für Pi OS auf Basis von Bullseye und auch Bookworm gibt es Docker base-images. Die könnte ich also bauen. Allerdings dürfte Bullseye eigentlich nicht nötig sein, da hier die Buster-binaries laufen sollten. Ergo gehe ich aktuell davon aus, dass lediglich Bookworm-binaries neu hinzukommen.

Ist das so korrekt?

Und bitte immer mit angeben auf welcher Basis Euer Pi läuft, Buster/Bullseye oder Bookworm und auch ob es 32 oder 64bit sind...

Was ich mich frage - wieso ist das Binary von der Pagesize abhängig? Ich meine (als ich noch eigene Programme unter Linux bereitstellte) dass das identische Binary auf Redhat mit huge page size lief, wie auf Suse mit normaler (4k) page size. Alles andere fände ich auch überraschend, da ein "normales" Programm ja die page size nicht irgendwie eingebrannt haben sollte. Vielleicht werden malloc oder calloc aufgerufen - aber da ist die page size dem aufrufenden Programm egal. Eine Ausnahme, an die ich mich auf Anhieb erinnere ist mmap, wo ein Aufrufparameter ein Multiples der page size sein muss. Aber da würde doch niemand 4096 hart kodieren, sondern sowas wie ps = sysconf(_SC_PAGE_SIZE) nehmen, und damit unabhängig von der page size bleiben.

Früher (in legacy code) gab es in manchem C/C++ Code noch die Konstante PAGE_SIZE (die nicht POSIX konform ist) - kann es sein, dass das hier irgendwo verwendet wird?

Klar, das was ich hier nannte, ist primär auf C/C++ gemünzt. Ich sehe aber nicht, wieso da bei anderen Sprachen ein Abhängigkeit von der page size reinkommen sollte. Man kann doch (in einigen/allen? Linux Installationen) die page size ändern/konfigurieren. Da muss man doch nicht sämtliche Binaries austauschen. Oder habe ich da was missverstanden?

buers es gibt hier einen Unterschied, Recht deutlich: die von nuitka erstellten "standalone binaries" sind streng genommen weder standalone, noch echte binaries. Das ist eher eine Art Archiv, was im Normalfall die libs aus dem Betriebssystem nutzt. Da die aber anders heißen oder evtl auch nicht vorhanden sind, muss man sie manuell mit rein packen, aus dem erstellenden Betriebssystem heraus.

Und hier müssen dann die libs halt (teilweise) von der Pagesize her passen.

Im Anhang dann mal 2 Binaries der aktuellen 0.13.5 für die RPIs mit 16k Pagesize, also vermutlich Bookworm based Pi OS:

Download Data package from December 26th.

filetransfer.io

Und: sollte buers übrigens Recht haben, dann könnten tatsächlich in dem entsprechenden Archiv wohl tatsächlich die libs einfach gegen die des Betriebssystems getauscht werden