VDRler aller Distributionen (ver-)einigt euch!

  • ...by the way: Warum muss man eigentlich überhaupt die .conf ändern, warum kann man nicht einfach unter Einstellungen/Plugins dem Plugin alles notwendige sagen?


    Viele Grüße, Mirko

  • wenn ich das richtig sehe hat jetzt auch graphlcd eine achritektur ähnlich wie lcdproc: ein backend mit einer lib und ein paar tools (aber ohne server).
    dadurch muss das plugin nur noch daten 'forwarden' und sich nicht mehr um die harware kümmern.
    und aus genau diesem grund kann man im plugin nicht mehr die hardware konfigurieren: das zeug wurde getrennt.

  • Quote

    Original von sdu


    die Kombination von beiden wäre ideal - z.B. mit einer selbst erweiterbaren blacklist bzw. default Liste



    Oder die statische - zeitsparende - Liste , die nicht manuell , sondern mittels Tool ( HW Erkennung etc pp ) also halbautomatisch beispielsweise beim Einbau einer weiteren Karte aktualisiert wird - daher nicht immer zewitfressend , sondern nur im Moment des Updates .


    HJS

  • Quote

    Original von hjs


    Oder die statische - zeitsparende - Liste , die nicht manuell , sondern mittels Tool ( HW Erkennung etc pp ) also halbautomatisch beispielsweise beim Einbau einer weiteren Karte aktualisiert wird - daher nicht immer zewitfressend , sondern nur im Moment des Updates .


    Ja so eine Kombination aus Script und Dialog vielleicht,
    manuelles Anschubsen und ein wenig Mithilfe vom User kann man ja erwarten oder :D
    Gruss Ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

    Edited once, last by Ulf ().

  • Quote

    Original von wilderigel
    http://www.heise.de/ct/06/14/003/


    Passt auch zum Thema?


    Jep ;)


    Der Schlüssel wäre für mich das endlich richtiges bug und feature tracking gemacht wird damit langfristig nicht nur bugs raus kommen,
    sondern auch die usability steigt.
    Bei der mehrzahl der distributionen ist das auf gutdünken des entwicklers beschränkt
    (ich erinnere mal an die leidigen timeshift debatten hier ;D ).
    Ohne tracking tool das dann nachweist das mehrere tausend user das feature für sinnvoll halten artet das jedesmal in religiöse kriege aus.


    Auch könnten so patches endlich richtig reported und eingepflegt werden
    (wenn jetzt einer von email an den entwickler faselt gibts was aufs :§$% )


    Peter


    P.S.
    Hatte doch M$ recht vor mutierten Pinguinen zu warnen
    :versteck

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

    Edited 2 times, last by PeterD ().

  • Quote

    Original von PeterD


    Jep ;)


    Der Schlüssel wäre für mich das endlich richtiges bug und feature tracking gemacht wird damit langfristig nicht nur bugs raus kommen,
    sondern auch die usability steigt.


    Reden wir jetzt von VDR und Plugins/Scripten oder von den Distries allgemein und deren config ?


    Sinnig wäre in letzterem Fall ne Einigung , was wo zu stehen hat , z.B. mit zentralen Configs .
    Suse geht da ja _seinen_ Weg - da gabs so ne Konvention , an die sich auch LFS hält ...


    In ersterem Fall ( VDR ) hat doch Klaus die Fäden weitestgehend in de Hand oder zumindest die Chance dazu ...


    HJS

  • Wie willst du vdr config Dateien angleichen, die sich ihrerseit aber auch an die Struktur ihrer Distribution halten "müssen".


    Also wäre es schon zuallererst mal wichtig, das sich die Distributionen (Linux) angleichen.

  • Quote

    Original von wilderigel
    Wie willst du vdr config Dateien angleichen, die sich ihrerseit aber auch an die Struktur ihrer Distribution halten "müssen".


    Also wäre es schon zuallererst mal wichtig, das sich die Distributionen (Linux) angleichen.


    Sicher - daher ja auch die Frage , worüber wir hier gerade reden :D


    HJS

  • Quote

    Original von hjs


    Sicher - daher ja auch die Frage , worüber wir hier gerade reden :D


    HJS


    Also bisher schien der konsens zu sein das bisher zu viele VDR distributionen ihr eigenes süppchen kochen.
    Ich denke hier eher and die grunddistributionen (Debian, Suse, RedHat).
    ctvdr, Ubuntu sind ja eigentlich nur (entbehrliche :duck ) varianten.
    Da sollte zuerst mal vereinheitlichung ansetzen.
    Hier geht es aber hauptsächlich um VDR nahe teile (vdrconvert, noad & Co).
    Warum hier jede distri ihr eigenes süppchen kochen muss hat wohl eher mit profilierungssucht der entwickler zu tun
    (:duck&wegrenn)
    Hier wäre auch wichtig die abhängigkeiten endlich in griff zu kriegen.


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

  • Hallo,


    ich sehe keinerlei Nutzen in einer vereinheitlichung der Distris oder auch VDRDistris. Wozu sollte das denn nutzen? Es gibt ja auch keine Apache oder Sendmail distri.
    VDR ist immer noch eine Anwendung die auf Linux läuft. Wie viele andere auch. Wenn jetzt jemand noch einen Mailserver dazu braucht. Gibts dann noch eine IdealStandartVDR+Mail Distri?


    Es gibt doch schon alles! LinVDR und ctVDR für Leute die sich nicht so gut auskennen. Alles vorgekaut (M$ style). Und jeder der sich besser auskennt kann vdr selber ziehen, patchen und compilieren. Ich bin seit VDR 0.78 dabei und mit Forum und mailingliste lesen hatt bisher noch alles geklappt.


    VDR ist für mich Hobby. Da muss man eben Zeit investieren. Wenn ich keine Zeit investiere kann ich auch nicht erwarten dass feature XYZplus sofort für mich tut

    mfg gorgo

    Mein vdr:
    vdr 1.7.15 - XXV 1.6 - Celeron 2,7 GHz - 2GB RAM - 460GB - eHD + TT 3200 oder Prof Revolution 7301 - 100er Gib mit Stab 90 HH Rotor und Smart TSX 11 LNB 0.2 dB
    fotoserviceathome

  • Quote

    Original von gorgo
    VDR ist für mich Hobby. Da muss man eben Zeit investieren. Wenn ich keine Zeit investiere kann ich auch nicht erwarten dass feature XYZplus sofort für mich tut


    Dem stimme ich uneingeschränkt zu - abba kein Grund um Standards aus zu schliessen ;)


    HJS

  • Quote

    Original von gorgo
    VDR ist für mich Hobby. Da muss man eben Zeit investieren. Wenn ich keine Zeit investiere kann ich auch nicht erwarten dass feature XYZplus sofort für mich tut


    Du verwechselst hier konfiguration und system.


    Eine ganze reihe anfänger und mittlerweise auch vorgeschrittener verzweifelt weil sich in jeder distribution jemand was geiles neues bei den scripten ausdenkt und dann alles auf die nase fällt.
    Das wäre halb so schlimm wenn es dann der "neue standart" wäre. Nur macht das halt bei jeder distri jemand wieder anders.
    Hier hat die c't eindeutig recht. Klarere standarts und bessere wartung der vorhandenen distries wären dutzenden neuen "hyper-super" distries vorzuziehen.


    gruss Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

  • Quote

    Original von gorgo
    Es gibt doch schon alles! LinVDR und ctVDR für Leute die sich nicht so gut auskennen. Alles vorgekaut (M$ style). Und jeder der sich besser auskennt kann vdr selber ziehen, patchen und compilieren. Ich bin seit VDR 0.78 dabei und mit Forum und mailingliste lesen hatt bisher noch alles geklappt.

    ...das sehe ich ein wenig anders. Zwar ist es wirklich keine große Hürde einen VDR auf einem Debian,... System aufzubauen. Bis man allerdings Features wie z.B. die extrem kurze Boot-Zeit von linvdr eingerichtet hat vergehen Tage oder Wochen. Und ich habe troz meines Hobbys VDR keine Lust das Rad zum x-ten mal neu zu erfinden.
    Ich verwende lieber meine Zeit darauf, bestehendes zu verbessern oder Neues zu schaffen.


    Ähnlich gelagert sehe ich es bei einem Näherrücken von linvdr und ct. Synergien können auch hier Parallelarbeit vermeiden und Resourcen zur Erhöhung des Komforts, der Stabilität und des Funktionsumfanges freisetzen.


    Gruß
    Wicky

  • Servus Peter,


    Quote

    Warum hier jede distri ihr eigenes süppchen kochen muss hat wohl eher mit profilierungssucht der entwickler zu tun
    (:duck&wegrenn)


    Absolut richtig! Ich stell mir grad vor, was ich machen würde, wenn ich nicht als "Herr LinVDR" oberschlaue Postings tippen würde. Fürchterlich! Ich müsste wahrscheinlich meine Zeit mehr mit Modellbau oder Auto-Tuning verbringen, anstatt hübsch am Schreibtisch zu sitzen und irgend welche Scripte oder Programme vom Stapel zu lassen.


    Ein Punkt in der Diskussion ist noch überhaupt nicht beleuchtet worden: Wenn denn alle ihr eigenes Süppchen kochen, was den Anwendern das Leben so schwer macht und bei den Anwendern immer wieder für Frust und Verwirrung sorgt -- warum benutzen dann so viele Leute diese Distributionen? Warum greifen die Leute nicht nach standardkonformen Distributionen mit Paket-Management und LFS bis unter's Dach, sondern ziehen sich so ne 30-MB-Klitsche aus dem Internet und werfen das auf die Platte?


    Viele Grüße, Mirko

  • Quote

    Original von cooper
    Ein Punkt in der Diskussion ist noch überhaupt nicht beleuchtet worden: Wenn denn alle ihr eigenes Süppchen kochen, was den Anwendern das Leben so schwer macht und bei den Anwendern immer wieder für Frust und Verwirrung sorgt -- warum benutzen dann so viele Leute diese Distributionen? Warum greifen die Leute nicht nach standardkonformen Distributionen mit Paket-Management und LFS bis unter's Dach, sondern ziehen sich so ne 30-MB-Klitsche aus dem Internet und werfen das auf die Platte?


    Nicht die einzelnen Distributionen machen den Anwender das Leben schwer, eher die Inkonsistenz zwischen den Programmen, die Inkonsistenz zwischen den Distributionen, ...


    Jede Distribution hat ihr Benutzerkonzept, jedes Programm hat sein Benutzerkonzept.
    Und das ist manchmal eben sehr weit auseinander.


    Wenn ich das Konzept von Windows verstanden hab, und von Office Excel, verstehe ich Word im großen und ganzen von alleine.


    Bei Linux Programmen oder Distributionen ist eben der Unterschied oft größer als die Gemeinsamkeiten.

  • Quote

    Original von wilderigel
    Jede Distribution hat ihr Benutzerkonzept, jedes Programm hat sein Benutzerkonzept.
    Und das ist manchmal eben sehr weit auseinander.


    Hm - da kann ich dir nicht ganz zustimmen .


    Das jede Distri ihr eigenes Konzept verfolgt - OK - Ähnlichkeiten sind erkennbar bei "benachbarten" oder z.B. Debian basierenden Distries - aber natürlich auch die Unterschiede .


    Programme werden natürlich in ihrer Handhabung durch den Programmierer geprägt .


    Aber wenn mir die M$ Programme nich zusagen , nehm ich halt Lotus oder den Schmetterling .


    Was die Ablage von Konfigurations und Verwaltungsinformationen angeht , so kreuzen immer wieder configure Optionen wie --exec-dir --with-conf-dir ( oder was in der Art ) meinen Weg .


    Tatsache ist , daß jede Binary basierende Distrie ( also fast alle ) diese Optionen bereits beim Compilieren vorgibt .


    Einn Grund mehr , solche Distries zu meiden - wenn ich andererseits bereit bin den Mehraufwand des Selbstcompilierens zu gehen .


    Wenn ich obigen configure Optionen aus dem Weg gehe und somit den Default des Programms akzeptiere , habe ich zumindest hier eine Übereinstimmung eines bestimmten Programms in allen Distries - da die Optionen ja nicht geändert wurden .


    Natürlich wäre es noch angenehmer , wenn es ein generelles Konzept gäbe , aber dann gäbe es die Vielfalt der Distries auch nicht mehr - worin würden sie sich denn auch noch unterscheiden ?


    Quote

    Wenn ich das Konzept von Windows verstanden hab, und von Office Excel, verstehe ich Word im großen und ganzen von alleine.


    Naja - wenn du die Testverarbeitung aus dem Openoffice "kapiert" hast , gilt das analog auch für die Tabellenkalkulation .
    Wenn Programme aus dem gleichen Haus Strukturabweichungen zeigen , dann wirds bedenklich ...


    Quote


    Bei Linux Programmen oder Distributionen ist eben der Unterschied oft größer als die Gemeinsamkeiten.


    War es nicht so , daß Linux eigentlich nur der Kernel ist ?


    HJS

  • Ich muss mich schuldig bekennen, an den Compiler-Optionen regelmäßig rumzuschrauben. Insbesondere an --prefix.


    Ich halte nichts davon, 2/3 der Programme nach /usr/local/bin, /usr/local/share/doc/..., /usr/local/lib uvvm. zu werfen, nur um /usr/lib, /usr/bin, /lib, /bin usw. auch noch in den Pfad reinzutun. Da breche ich regelmäßig mit den Vorstellungen der Entwickler, die häufig das Ganze nach /usr/local installieren wollen.


    BTW: /usr/local gibt's nicht bei LinVDR, und ich halte es im Sinne der Übersichtlichkeit nicht für förderlich, die Binaries in ein drittes Verzeichnis zu werfen -- wer soll das noch finden?


    Viele Grüße, Mirko

  • Quote

    Original von cooper
    Ich muss mich schuldig bekennen, an den Compiler-Optionen regelmäßig rumzuschrauben. Insbesondere an --prefix.


    Da fehlt ja nur noch der Schuldspruch :mua


    Quote


    Ich halte nichts davon, 2/3 der Programme nach /usr/local/bin, /usr/local/share/doc/..., /usr/local/lib uvvm. zu werfen, nur um /usr/lib, /usr/bin, /lib, /bin usw. auch noch in den Pfad reinzutun. Da breche ich regelmäßig mit den Vorstellungen der Entwickler, die häufig das Ganze nach /usr/local installieren wollen.


    Hab ich auch nie wirklich verstanden - gibbet Linux-Maschinen mit WWU ( World Wide Usern ) und LU ( Local User ) ?


    Unglücklicherweise gibbet ja auch Progs , die --prefix nichmal kennen und sich beim make install pauschal nach /usr/local installieren - was sich natürlich leicht bereinigen lässt :D


    Welchen Sinn ergab in diesem Zusammenhang /opt ?


    Quote

    BTW: /usr/local gibt's nicht bei LinVDR, und ich halte es im Sinne der Übersichtlichkeit nicht für förderlich, die Binaries in ein drittes Verzeichnis zu werfen -- wer soll das noch finden?


    Die Unterscheidung /[usr/][s]bin sollte langen - seh ich allerdings auch so .
    Configs in /etc[/prog] und gut ...


    HJS

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!