VDR-Philosophie: Warum dieser steinige Weg beim Bauen aus den Quellen?

Hallo zusammen,

ich traue mich heute mal mit einer Frage aus der Deckung, die mich als langjährigen Bastler schon länger beschäftigt.

Kurz zu meinem Hintergrund: Ich bin ein absoluter Verfechter davon, meine Systeme selbst aus den Quellen zu bauen. Ob mein aktuelles Setup mit TVHeadend (direkt von GitHub kompiliert) oder mein zweites großes Projekt – eine CNC-Fräsmaschine auf Basis von LinuxCNC (ebenfalls komplett aus dem Source aufgebaut) – ich liebe es einfach, die volle Kontrolle über den Code zu haben.

Trotzdem bleibe ich beim VDR immer wieder an einem Punkt hängen, der mich grübeln lässt. Ich finde den VDR an sich fantastisch: Die Haptik, die Reaktionsgeschwindigkeit und dieses "echte" Receiver-Gefühl sind bis heute ungeschlagen.

Aber jetzt kommt mein "Warum":

Wenn man den VDR-Core heute pur aus den Sourcen baut, landet man in einer regelrechten Patch-Odysee. Man sucht sich Core-Patches aus Forenthreads zusammen, flickt Plugins manuell für Dinge wie Kodi oder MPV ein und stellt fest, dass viele wichtige Entwicklungen nie den Weg in den offiziellen Core finden. Man verbringt gefühlt mehr Zeit mit dem Mergen und Suchen als mit allem anderen.

Bevor der (sicher gut gemeinte) Rat kommt: "Nimm doch eine fertige Distribution wie yaVDR oder MLD" – genau das ist nicht mein Ziel. Ich baue gerne selbst, um das System zu verstehen.

Deshalb meine ganz ehrliche Frage an die Community:

Wieso tut man sich dieses "Patch-Gefriemel" heute noch an? Was ist für euch der Grund, warum der Core so konservativ bleibt und man diese Hürden beim Selbstbauen beibehält? Ist es die pure Stabilität eines "Never change a running system" oder gibt es architektonische Gründe, die ich übersehe?

Ich frage das aus echtem Interesse an der Philosophie, weil ich den VDR eigentlich gerne wieder zu meinem Hauptprojekt machen würde, aber an dieser speziellen Hürde immer wieder hängen bleibe.

Beste Grüße,

Andre

"Ich habe die Ruhe des Nachmittags mal genutzt, um über eure Antworten nachzudenken – danke dafür. Aber wenn ich ehrlich bin: Was hier oft als 'überschaubarer Aufwand' oder 'Gewöhnung' beschrieben wird, ist für mich das Kernproblem.

Ihr fragt nach meiner Patch-Liste, als wäre die bloße Anzahl der Beweis für den Aufwand. Aber das ist ein Trugschluss. Es geht nicht um 2 oder 10 Patches. Es geht um die Software-Archäologie, die man im Jahr 2026 betreiben muss, um diese überhaupt zu finden, zu bewerten und gegen einen starren Core zu prüfen.

Es wird hier als völlig normal 'hingenommen', dass man:

1. Foren-Threads nach der 'echten' letzten Version eines Patches durchwühlt.

2. Manuell prüft, ob Patch A die Zeilen für Patch B zerschießt.

3. Sich damit arrangiert, dass Basisfunktionen im Core fehlen, weil man sie ja 'irgendwie ranbasteln' kann.

Man kann mich gerne 'bequem' nennen, aber in der modernen IT heißt das Effizienz. Warum sollte ich Lebenszeit in die manuelle Pflege einer Infrastruktur stecken, die in anderen Projekten seit 15 Jahren durch moderne APIs, Pull Requests und zentrale Repositories (GitHub/GitLab) gelöst ist?

Ein Blick über den Tellerrand zu LinuxCNC zeigt das Dilemma: Ein Projekt mit extremen Echtzeit-Anforderungen und einer ebenso alten Codebasis. Aber dort schneidet man gerade radikal 'alte Zöpfe' ab (https://github.com/LinuxCNC/linuxcnc/issues/3878). Warum? Nicht um Nutzer zu ärgern, sondern um als Gesamtprojekt wartbar und attraktiv für neue Leute zu bleiben.

Beim VDR habe ich das Gefühl, wir pflegen stolz lauter kleine 'Insel-Lösungen'. Das funktioniert für den Einzelnen im Moment gut, führt aber dazu, dass selbst versierte Köpfe wie M-Reimer irgendwann aufgeben, weil das Patch-Mikado zu mühsam wird.

Stabilität ist das höchste Gut des VDR, aber sie darf nicht zur Unbeweglichkeit werden. Wenn der Einstieg in ein Projekt nur noch über das Studium von jahrealten Foren-Beiträgen gelingt, isoliert sich das System von der Zukunft. Mein Ziel ist es nicht, zu basteln, um den Status Quo mühsam zu erhalten – ich möchte meine Energie lieber nutzen, um auf einer modernen Basis etwas Neues zu erschaffen."

"Genau das ist der Punkt, M-Reimer! 'Vor Jahren im Gespräch' beschreibt das Dilemma leider perfekt.

Es unterstreicht eigentlich genau meine Kritik: Es ist ja ein Konsens da, dass diese Funktionen (wie eine strukturierte Menü-Config) notwendig sind, um das System zeitgemäß zu halten. Aber solange solche essenziellen Dinge nicht den Weg in den Standard finden, bleibt die Last beim Nutzer hängen. Man muss sich dann eben doch wieder durch Foren und Repos arbeiten, um den Standard-Core auf einen Stand zu bringen, der sich nach 2026 anfühlt.

Wenn wir über Jahre bei der Diskussion bleiben, anstatt die 'Zöpfe' durch eine moderne Lösung im Core zu ersetzen, entsteht genau diese Unbeweglichkeit. In der Zeit, in der über die Notwendigkeit solcher Änderungen gesprochen wird, haben andere Projekte ganze Architekturen modernisiert, um zukunftsfähig zu bleiben.

Es wäre doch für alle ein Gewinn – vom langjährigen Experten bis zum neuen User –, wenn wir von 'war mal im Gespräch' zu 'ist jetzt Standard' kommen würden. Das würde die Energie weg von der bloßen Verwaltung des Status Quo hin zu echter Innovation lenken. Mein Ziel ist ja nicht Kritik um der Kritik willen, sondern der Wunsch nach einer Basis, die mit der Zeit geht."

Ups, das mit der Schriftgröße war keine Absicht. Da hab ich wohl im Eifer des Gefechts auf die falschen Knöpfe gedrückt. Sollte jetzt wieder passen! 👍

Danke für die Einblicke, SHofmann. Das mit der Schriftgröße habe ich hoffentlich jetzt korrigiert – war keine Absicht, mein Fehler!

Es ist eigentlich genau das, was ich gehofft hatte zu hören: Dass sich im Hintergrund doch Gedanken gemacht werden, wie man den Core modernisieren und von den ewigen Patches wegkommen kann. Dass Klaus bei den zwei Ziffern noch zögert, ist zwar schade, aber es ist ja schon viel wert, dass das Thema überhaupt wieder im Dialog ist.

Ich wollte mit meinem 'Rundumschlag' auch niemanden persönlich angehen. Mir ging es einfach darum, dass wir dieses tolle Projekt fit für die Zukunft halten und die Einstiegshürden nicht unnötig hoch lassen.

Ich verziehe mich jetzt erst mal wieder an meine Fräse und baue da weiter. Bin gespannt, was sich beim VDR in nächster Zeit tut. Danke an alle für die sachliche Diskussion!