Beiträge von dlueth

Bei Docker hat man halt ein gekapseltes System was man ggf. nach belieben starten und beenden kann. Alles, was gebraucht wird ist drin und das umgebende System benötigt nur und ausschließlich Docker. Klar, die Config muss man ggf. wegsichern - aber das sollte man ja sowieso tun.

Ich persönlich finde (und das muss nicht jeder so sehen), dass es durchaus von Vorteil ist, dass ich außer Docker rein gar nichts auf dem umgebenden System brauche. Es gibt hier dann nämlich auch null komma null null Potential für Konflikte (was durchaus auch vorkommt, wenn man viel installiert hat, z. B. bei Java) und auch keine "Update-Sorgen", sofern die Container vernünfitg gewartet werden von den Erstellern. Ich kann also auch beliebige Software einfach testen ohne irgendwelche Rückstände auf dem System zu hinterlassen. Ich kann sogar solche Software testen oder benutzen, die es für meine Distribution oder sogar meine CPU-Architektur z.B. gar nicht gibt.

Für unsere Fälle mag das vielleicht nicht ganz so relevant sein, aber auch ein "Neu Aufsetzen" kann (nicht muss) mit Docker durchaus um einiges schneller sein. Nacktes Betriebssystem drauf, Docker installieren, Konfiguration der Container Wiederherstellen, Container starten, läuft... (gilt allerdings nicht für TVHeadend, was aber an deren Konfiguration liegt)

Ich persönlich benutze folgende Images:

lscr.io/linuxserver/tvheadend:latest

qoopido/telerising.minimal:latest

qoopido/easyepg.minimal:lite-scratch

Wobei letzterer die "Scratch"-Variante ist, die nochmal deutlich kleiner ist als "latest". Telerising von mir gibt es sowieso nur noch als "Scratch".

LooseMyMindOnLinux das ist echt komisch, da bookworm ja neuer ist als bullseye. Aber bullseye war ja auch problematisch, was das Bauen angeht, weswegen ich letztlich auf Buster geblieben bin...

Und LooseMyMindOnLinux also wenn klar ist, dass die Version so weit stabil läuft würde ich sie bei mir - solange es geht - als festen Bestandteil mit aufnehmen

Also: gebaut wird die arm32v6 Version auf einem buster basierenden raspbian Image in arm/v6, von daher wüsste ich jetzt nicht, wo da ein Fehler passieren sollte. Insbesondere, weil es ja auf einem PiZeroW sauber zu laufen scheint.

Aber generell bestätigst Du meine Vermutung, die neulich schonmal auftauchte: die Pagesize scheint hier nur die inkludierten libs zu betreffen, nicht aber die binary Ansich. Ergo kann man die nachträglich austauschen wie es scheint. Und ja, mein build ist statisch. Vielleicht würde es mit einem dynamischen build auf den rpis besser/einfacher laufen? Da ich für Docker baue brauche ich allerdings statisch...

vossi68 du meinst die v7 läuft nicht auf dem PiZeroW? Das wäre ja so weit korrekt, denn der kann nur v6. Allerdings müsste die v6 Version auch auf einem 32bit v7 System laufen.

Kleiner kann sie durchaus sein, denn ich lasse noch ein paar Optimierungen drüber laufen um sie so klein wie möglich zu bekommen

So, hier nun die Binaries gesammelt mit der Bitte um Feedback: https://limewire.com/d/172c526f-e89…hQi_30RrmPLmk4A

arm32v6 war etwas anstrengender als erwartet, da Debian das gar nicht mehr offiziell bereitstellt, aber könnte/müsste laufen

Ach, wer weiß wer die noch brauchen kann evtl. XD

Das Bauen wird voraussichtlich bis morgen brauchen. Mein neues MacBook mit Arm-Architektur kommt erst mitte Januar und bis dahin bin ich noch auf Intel unterwegs, was das bauen für Arm extrem verlängert.

So, ich baue jetzt mal neue binaries für alle Architekturen, also amd64, arm64v8, arm32v7 und zusätzlich arm32v6 + arm64v8-16k für die RPI5 Besitzer und packe sie dann hier dazu. Bitte die dann mal gegenchecken und ich setze mich im Nachgang hin und ändere den GitHub Workflow entsprechend.

Für Docker bedeutet das, dass es nun zusätzlich ein arm32v6 image gibt, mehr erstmal nicht. Der läuft also vorerst nicht auf einem Pi5 mit Pagesize 16k. Im GitHub Repo sollte sich dann aber eine kompatible Binary beim release finden. Da Docker anhand der Pagesize nicht unterscheiden kann, muss es demnach im weiteren Nachgang wohl einen extra "Tag" für die 16k-Version geben.

easy4me d.h. es reicht hier eigentlich ein einiziges build für die 16k Pagesize, nämlich das für arm64v8, korrekt? Oder gibt es auch die Möglichkeit, dass es ein arm32v7/arm32v6 mit 16k Pagesize braucht?

vossi68 Die Frage hier hattest Du gesehen? RE: Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Web App]

OK, und da easy, soweit ich weiß, die Binaries direkt auf einem Pi gebaut hat wird das wohl deswegen hingehauen haben...

Und, noch ne Frage, vermutlich vossi68 : Hat nur Bookworm auf den RPI 5 die 16k Pagesize oder auch schon Bullseye?

Ah, OK! Das mit dem PiZeroW leuchtet mir übrigens ein, der braucht armv6 und nicht v7. Ist halt nur die Frage warum es vorher lief. vossi68

Tja, das klingt schonmal gut! Aber wir bekommen wir jetzt ganz genau heraus was wo und vor allem warum läuft? XD

Weil eigentlich bestätigst Du ja, vossi68 , dass der bisherige Build schon läuft...

Starfoxfs hm, das ist doch merkwürdig. Weil alle mit Problemen waren ja RPI Nutzer mit einer Pagesize von 16k?

Starfoxfs Bist Du Dir wegen des "ohne Veränderungen" sicher? Ich dachte mit Umstellung auf Bookworm hätte RPI generell auf 16k Pagesize umgestellt? Oder hast Du es einfach via config auf 4k zurückgestellt?

Bitte nochmal um Klärung/Feedback in Bezug auf die RPIs, wo meine Binaries jetzt laufen:

"arm"-Binary aus dem GitHub-Repo: müsste auf den 32-Bit RPIs mit Pi OS auf Basis von Buster & Bullseye (und Bookworm mit via config auf 4k zurückgerehter Pagesize), also 4k Pagesize, laufen

"arm64"-Binary aus dem GitHub-Repo: müsste auf den 64-bit RPIs mit PiOS auf Basis von Buster & Bullseye (und Bookworm mit via config auf 4k zurückgerehter Pagesize), also 4k Pagesize, laufen

"arm16k"-Binary aus meinem Post oben: müsste auf den 32-Bit RPIs mit Pi OS auf Basis von Bookworm, also 16k Pagesize, laufen

"arm6416k"-Binary aus meinem Post oben: müsste auf den 64-Bit RPIs mit Pi OS auf Basis von Bookworm, also 16k Pagesize, laufen

Mögen/können das vielleicht ein paar Leute bestätigen?

easy4me entweder nimmst du die binaries aus meinem repo oder ich gebe dir die passenden Scripte für GitHub. Was auch immer die lieber ist ggf )

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