wenn ich das richtig in erinnerung habe gibt es doch ein tool namens showpic, das bei graphlcd-base dabei ist. wie bekommst du sonst bilder auf dein display währen des boot-vorgangs?
VDRler aller Distributionen (ver-)einigt euch!
- habichthugo
- Closed
-
-
...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
Gruss Ulf -
-
Quote
JepDer 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 ).
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 -
Quote
Original von PeterD
JepDer 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
HJS
-
Quote
Original von hjs
Sicher - daher ja auch die Frage , worüber wir hier gerade reden
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
-
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
-
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 tutDem 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
-
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,
QuoteWarum 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 ?
QuoteWenn 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
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
Welchen Sinn ergab in diesem Zusammenhang /opt ?
QuoteBTW: /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!