Welche Images gibt es und wie sind sie entstanden?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Welche Images gibt es und wie sind sie entstanden?

      Neu

      Hallo,

      mal in eigenen Worten erklärt was ich recherchiert bzw. verstanden habe. Ich wäre für Verbesserungen und Ergänzungen dankbar. Ich habe den Kram auch schon in einem anderen Forum geschrieben, ich hoffe es ist OK es hier noch einmal zu schreibe?

      - Enigma1 wurde vor zig Jahren von der Firma „Dream Mulitmedia (kurz DMM)“ entwickelt. Enigma1 spielt heute keine Rolle mehr.

      - Enigma2 wurden ebenfalls von der Firma DMM entwickelt, als Enigma1 den modernen Anforderungen nicht mehr gerecht wurde.

      - Mittlerweile heißt die Firma DMM nichtmehr DMM sondern „Dream Property (kurz DP)“. Deshalb werde ich im weiteren nur noch von DP sprechen. Was ich nicht verstehe ist warum ihr alle noch von DMM sprecht. Korrekt müsste man doch von DP sprechen. DMM gibt es nicht mehr.

      - Enigma2 wurde seitens DP unter einer F(L)OSS Lizenz veröffentlicht. Ob das nun eine OpenSource oder eine GPL-Lizenz war. Keine Ahnung. Weiß das jemand?

      - Enigma2 wurde primär von DP und von der freien Community weiter entwickelt. Anders als sich das DP erhofft hatte beteiligten sich andere Receiver-Hersteller kaum an der Weiterentwicklung von Enigma2. Die anderen Receiver Hersteller nutzen das fertige Enigma2 (was sie ja aufgrund der F(L)OSS Lizen dürfen) für Ihre Receiver. Die anderen Hersteller hatten somit im Gegensatz zu DP keinen Zeit und Geldaufwand für die Entwicklung des OS. Aus diesem Grund konnten die anderen Hersteller Ihre Receiver wesentlich günstiger als DP anbieten. Um diesen Nachteil wett zu machen forkte DP einen Enigma2 Ableger den man dann DreamOS nannte. DreamOS war im Gegensatz zu Enigma2 Closed Source. Closed Source bezieht sich an dieser Stelle allerdings nur auf den Kern von Enigma2. Dadurch das der Kern seitens Enigma2 nun Closed Source war, war es den anderen Receiver Herstellern nicht mehr möglich auf den Kern zuzugreifen, deshalb konnten keine Treiber mehr für die eigene Hardware entwickelt werden (für Treiber Entwicklung benötigt man Zugriff auf den Kern). Aus diesem Grund verwenden ausschließlich die Dreamboxen DreamOS. Die Boxen anderer Hersteller verwenden grundsätzlich Images die auf Enigma2 (als es noch nicht Closed Source war) basieren.

      - Dadurch, das bei DreamOS nur der Kern Closed Source ist kann die freie Community trotzdem wunderbar weiterhin Plugins und dergleichen entwickeln, wie es z.B. @gutemine macht.

      - Nun kennen wir den Unterschied zwischen Enigma2 und DreamOS, deshalb kann man nun auch den Begriff Open-Image erklären. Ein Open-Image ist ein Image welches auf Enigma2 beruht. Open-Images haben irgendwann mal von Enigma2 geforkt undwurden dann eigenständig weiterentwickelt. Bekannte Open-Images sind z.B. OpenATV oder OpenNFR.

      - Neben den Open-Images gibt es allerdings auch noch Closed-Images. Diese Images bezeichnet man deshalb als Closed-Images, weil diese im Gegensatz zu Open-Images nicht auf Enigma2 sondern auf auf DreamOS beruhen. Bekannte Closed-Images sind z.B. Newnigma2, Merlin, Oozoon oder Dreamelite. Diese Images basieren alle auf DreamOS 2.5.

      - Die Closed-Images (Newnigma2, Merlin, Oozoon, Gemini (V1 und V2 ist ein Image, V3 und V4 ein Plugin) oder Dreamelite usw.) unterscheiden sich im Kern NICHT von Enigma2. Sie unterschieden sich nur in den Dingen, die sich nicht auf den Kern beziehen, von Enigma2 z.B. bezogen auf Plugins, Skins usw.. Closed-Images werden neben der freien Community auch von DP in der Weiterentwicklung unterstützt. Bei Open-Images erfolgt die Weiterentwicklung ausschließlich durch die freie Community.

      Als Baum sieht das dann wie folgt aus:

      - 1. Enigma 1
      - 2. Enigma 2
      - 2.1. Dream OS (z.B. 2.0, 2.2 und 2.5)
      - 2.1.1. Closed Image (z.B. Newnigma2, Oozoon, Merlin usw.)
      - 2.2. Open Image (z.B. OpenATV und Open NFR)

      Einige Fragen dazu:

      1. Könnt Ihr das oben bestätigen, ergänzen und berichtigen?

      2. Warum war Gemini früher (V1 und V2) ein Image und wird jetzt (V3 und V4) nur noch als Plugin angeboten. Ich verstehe den Sinn nicht. Dann könnte man aus Newnigma2 (V 3.0) ja auch ein Plugin machen. Warum sollte man das tun?

      3. Man spricht ja immer von OE 2.0, OE 2.2 und OE 2.5. Bezieht sich das auf Enigma2 oder auf DreamOS? Ich vermute mal auf DreamOS.

      4. Welche Images basieren auf OE 2.0 oder OE 2.2? Ich kenne keines. Newnigma2, Merlin, Oozoon oder Dreamelite basieren doch auf OE 2.5 oder?

      Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von grhansolo ()

    • Neu

      puhhhh, wenn man das alles erklärt, wird ja eine Geschichtsstunde draus ;) .

      grhansolo schrieb:

      - Mittlerweile heißt die Firma DMM nichtmehr DMM sondern „Dream Property (kurz DP)“. Deshalb werde ich im weiteren nur noch von DP sprechen. Was ich nicht verstehe ist warum ihr alle noch von DMM sprecht. Korrekt müsste man doch von DP sprechen. DMM gibt es nicht mehr.
      Nicht alle sprechen jetzt noch von DMM. Da DP aus DMM hervorgegangen ist, kann man durchaus auch noch DMM verwenden, was dann aber wohl eher Macht der Gewohnheit ist. Ist eben historischer Kontext.

      grhansolo schrieb:

      - Enigma2 wurde seitens DP unter einer F(L)OSS Lizenz veröffentlicht. Ob das nun eine OpenSource oder eine GPL-Lizenz war. Keine Ahnung. Weiß das jemand?
      enigma2 (OE1.6 und früher) wurde noch unter, wie du so schön schreibst, OpenSource oder einer GPL-Lizenz entwickelt/veröffentlicht. Kann jemand anderes sicher genauer erklären.

      grhansolo schrieb:

      - Enigma2 wurde primär von DP und von der freien Community weiter entwickelt. Anders als sich das DP erhofft hatte beteiligten sich andere Receiver-Hersteller kaum an der Weiterentwicklung von Enigma2. Die anderen Receiver Hersteller nutzen das fertige Enigma2 (was sie ja aufgrund der F(L)OSS Lizen dürfen) für Ihre Receiver. Die anderen Hersteller hatten somit im Gegensatz zu DP keinen Zeit und Geldaufwand für die Entwicklung des OS. Aus diesem Grund konnten die anderen Hersteller Ihre Receiver wesentlich günstiger als DP anbieten. Um diesen Nachteil wett zu machen forkte DP einen Enigma2 Ableger den man dann DreamOS nannte. DreamOS war im Gegensatz zu Enigma2 Closed Source. Closed Source bezieht sich an dieser Stelle allerdings nur auf den Kern von Enigma2. Dadurch das der Kern seitens Enigma2 nun Closed Source war, war es den anderen Receiver Herstellern nicht mehr möglich auf den Kern zuzugreifen, deshalb konnten keine Treiber mehr für die eigene Hardware entwickelt werden (für Treiber Entwicklung benötigt man Zugriff auf den Kern). Aus diesem Grund verwenden ausschließlich die Dreamboxen DreamOS. Die Boxen anderer Hersteller verwenden grundsätzlich Images die auf Enigma2 (als es noch nicht Closed Source war) basieren.
      Kommt so im groben gesagt hin. Die erste closed Source Version war dann das OE2.0, welches aber noch keinen wirklichen Namen wie DreamOS trug.

      grhansolo schrieb:

      - Dadurch, das bei DreamOS nur der Kern Closed Source ist kann die freie Community trotzdem wunderbar weiterhin Plugins und dergleichen entwickeln, wie es z.B. @gutemine macht.
      Korrekt

      grhansolo schrieb:

      - Nun kennen wir den Unterschied zwischen Enigma2 und DreamOS, deshalb kann man nun auch den Begriff Open-Image erklären. Ein Open-Image ist ein Image welches auf Enigma2 beruht. Open-Images haben irgendwann mal von Enigma2 geforkt undwurden dann eigenständig weiterentwickelt. Bekannte Open-Images sind z.B. OpenATV oder OpenNFR.
      an den open Images kann sich immernoch jeder an der "Entwicklung" beteiligen. Bestes Beispiel eben openATV oder NFR, gibt aber auch noch andere.

      grhansolo schrieb:

      - Neben den Open-Images gibt es allerdings auch noch Closed-Images. Diese Images bezeichnet man deshalb als Closed-Images, weil diese im Gegensatz zu Open-Images nicht auf Enigma2 sondern auf auf DreamOS beruhen. Bekannte Closed-Images sind z.B. Newnigma2, Merlin, Oozoon oder Dreamelite. Diese Images basieren alle auf DreamOS 2.5.
      open oder closed Images sagt man nicht dazu. Seit OE2.0 entwickelt DMM/DP nur noch closed source und erst seit OE2.5 nennt sich das ganze erst DreamOS.

      grhansolo schrieb:

      - Die Closed-Images (Newnigma2, Merlin, Oozoon, Gemini (V1 und V2 ist ein Image, V3 und V4 ein Plugin) oder Dreamelite usw.) unterscheiden sich im Kern NICHT von Enigma2. Sie unterschieden sich nur in den Dingen, die sich nicht auf den Kern beziehen, von Enigma2 z.B. bezogen auf Plugins, Skins usw.. Closed-Images werden neben der freien Community auch von DP in der Weiterentwicklung unterstützt. Bei Open-Images erfolgt die Weiterentwicklung ausschließlich durch die freie Community.
      NN2, Merlin, oozonn Images unterscheiden sich im Kern nicht voneinander. Das "Grundgerüst" ist überall gleich. Unterschieden gibt es eben bei alles Sachen, die rund um das enigma2 programmiert werden können, wie Skins und plugins. DreamOS wird von DP weiterentwickelt, wobei da auch schon Vorschläge der Community mit eingeflossen sind, und natürlich die ganzen plugins ringsrum, von zahlreichen Usern. Bei den open Images gibt es sicher auch ein Team von "Chefprogrammieren", die da die Richtung vorgeben, also ganz so wild geht es da nun auch nicht zu.

      zu 4. auf OE1.6 basieren z.B openATV, openNFR, PurE2, usw., auf OE2.0 basieren z.B. das NN2 weekly Image, Merlin 3, oozoon hats sicher auch ein OE2.0 basiertes Image. OE2.2 ist das unmittelbare Vorgängerimage zum OE2.5 und trägt den Beinamen DreamOS. zu beiden OE-Versionen gab/gibt es Images von DP, NN2,Merlin,oozoon usw.
      Gruß
      Hilfsbereit

      ... jeder GS, ist ein GS zu viel ...

      mediaportal-weed-skins
      Screenshot richtig erstellen

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Hilfsbereit ()

    • Neu

      Die alten "Hasen" (schon mehr als 15Jahren in der Szene dabei und bekannt) kommen ursprünglich aus der DBox2 Community ... einige davon hatten sogar schon eine DBox1 und wurden damals mit dem D-Fieber infiziert und treiben sich teils unter anderen Nick noch hier und da herum oder sind noch aktiv an der Entwicklung beteidigt/beratend dabei.

      Ein guter Einstiegstpunkt ist hier: wiki.tuxbox-neutrino.org/wiki/DBox2-Story, Ich empfehle die mal in das Interview reinzuhören.


      gruß
    • Neu

      das mt dem Baum müsste etwa so aussehen, der OE Wechsel ging oft mit dem Erscheinen neuer Dreamboxen und einem Kernel major realease update einher
      schematisch etwa so (kein Anspruch auf Vollständigkeit oder Richtigkeit ;) )

      - 1. Enigma 1
      - 2. Enigma 2
      |-- OE1.?: DM7025
      |-- OE1.5: DM7025, DM800HD, DM8000, DM500HD, DM800se
      |-- OE1.6: DM7025, DM800HD, DM8000, DM500HD, DM800se, DM7020HD ---------------------------------|--> fork ->> Open Image (z.B. OpenATV und Open NFR)
      |-- OE2.0: DM800HD, DM8000, DM500HD(v2), DM800se(v2), DM7020HD(v2)
      |-- OE2.2: DM7080HD, DM820HD, DM52xHD, (DM900UHD ?)
      |-- DreamOS:(OE2.5): DM900UHD, DM920UHD; DM7080HD, DM820HD, DM52xHD

      ab OE2.0. ist der enigma2 core closed sourde (seitens DP), deshalb gibt es nur Open Images auf Basis OE1.6
      seit OE2.5 heisst es eigentlich erst DreamOS

      Newnigma2, Oozoon, Merlin sind keine closed source Images, sie basieren auf dem original experimental image des jeweiligen OE, d.h. auch ab OE2.0 nur closed enigma2 core

      im Newnigma2 ist zwar der Großteil vom Team hinzugefügte Teil closed source (Newnigma2 Services) aber sonst alles offen.
      im Merlin, OoZooN und original Image ist alles bis auf dem enigma2 core offen.

      Warum aus Gemini ein Plugin wurde, können dir nur die Ersteller sagen, Tatsache ist, dass das Gemini Image gerne buggy wurde, vor allem wenn es seites DP updates gabe, weil Gemini gerne im E2 code rumpatchte und das Update das wieder zunichte machte.

      Im Gemini sind sogar teilweise Plugins closed source und die feeds sind nicht über http(s) im Browser oder FTP etc. erreichbar. D.h. heisst, wenn man div. Plugins haben möchte, muss man GP installieren.

      So gesehen ist GP das geschlossenste System der gängigen Images / Plugins im Dreambox Zweig

      Die Open Images wurden vor allem für Trittbrettfahrerbox erstellt, die sich das damals komplett offene Enigma2 schnappten (VU, Gigablue und wie sie alle heissen).
      Seit dem der Enigma2 core (inkl. Treiber etc.) closed source ist, bauen die Open Images auf dem OE1.6 auf, weil man da den enigma2 core noch entsprechend an die Hardware anpassen kann, was ab OE2.0 nicht mehr funktioniert.
      Gruß Fred

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Neu

      Zu 1: Einiges ist noch ungenau oder falsch, aber im großen und ganzen hast du das ganz gut zusammengefasst.

      grhansolo schrieb:

      - Mittlerweile heißt die Firma DMM nichtmehr DMM sondern „Dream Property (kurz DP)“. Deshalb werde ich im weiteren nur noch von DP sprechen. Was ich nicht verstehe ist warum ihr alle noch von DMM sprecht. Korrekt müsste man doch von DP sprechen. DMM gibt es nicht mehr.
      Dream Property gibt es schon lange und wurde eigentlich für die Verwaltung der Lizenz- und Markenrechte genutzt. Warum DMM irgendwann eingestampft wurde, weiß glaube ich keiner so genau. Insgesamt sind die Firmenkonstrukte in Lünen manchmal etwas undurchsichtig. Es wurde ja auch mal Leontech aus HongKong ins Boot genommen, ist aber augenscheinlich auch nicht mehr dabei?


      grhansolo schrieb:

      - Enigma2 wurde seitens DP unter einer F(L)OSS Lizenz veröffentlicht. Ob das nun eine OpenSource oder eine GPL-Lizenz war. Keine Ahnung. Weiß das jemand?
      Das war eine proprietäre Open-Source Lizenz, bei der alle Forks gezwungen wurden unter der GPL zu stehen. Kannst du im Detail noch bei OpenPLi nachlesen: github.com/OpenPLi/enigma2/blo…c63ca30d2954ff6a0/LICENSE
      Meines Erachtens war das auch einer der Hauptgründe, warum Dream ihren Teil im Kern irgendwann geschlossen hat. Die Lizenz vorher war einfach dämlich, weil man selbst ja nicht unter GPL releasen wollte und somit gar nicht die (wenigen) Beiträge der sonstigen Communities und Anbieter verwenden durfte. Da hättest deutlich besseres (z.B. LGPL, Apache, whatever) gegeben. Der andere Grund waren Clones...

      grhansolo schrieb:

      - Enigma2 wurde primär von DP und von der freien Community weiter entwickelt. Anders als sich das DP erhofft hatte beteiligten sich andere Receiver-Hersteller kaum an der Weiterentwicklung von Enigma2. Die anderen Receiver Hersteller nutzen das fertige Enigma2 (was sie ja aufgrund der F(L)OSS Lizen dürfen) für Ihre Receiver. Die anderen Hersteller hatten somit im Gegensatz zu DP keinen Zeit und Geldaufwand für die Entwicklung des OS. Aus diesem Grund konnten die anderen Hersteller Ihre Receiver wesentlich günstiger als DP anbieten. Um diesen Nachteil wett zu machen forkte DP einen Enigma2 Ableger den man dann DreamOS nannte. DreamOS war im Gegensatz zu Enigma2 Closed Source. Closed Source bezieht sich an dieser Stelle allerdings nur auf den Kern von Enigma2. Dadurch das der Kern seitens Enigma2 nun Closed Source war, war es den anderen Receiver Herstellern nicht mehr möglich auf den Kern zuzugreifen, deshalb konnten keine Treiber mehr für die eigene Hardware entwickelt werden (für Treiber Entwicklung benötigt man Zugriff auf den Kern). Aus diesem Grund verwenden ausschließlich die Dreamboxen DreamOS. Die Boxen anderer Hersteller verwenden grundsätzlich Images die auf Enigma2 (als es noch nicht Closed Source war) basieren.
      Das ist sehr, sehr stark verkürzt, was passiert ist. Etwas genauer war der Zeitablauf in etwa so:
      - 2005 kam enigma2 mit der 7025 das erste Mal auf den Markt
      - 2008 ging der Boom mit der ersten HD fähigen Dreambox (800) richtig los
      - Quasi sofort wurde insbesondere die 800 sehr oft kopiert. Dreams Software lief ohne jede Änderung oder mit kleinen Patches auf diesen sog. Clones.
      - 2010 kam mit VU der erste "echte" Wettbewerber auf den Markt, der seine eigene Hardware und damit eigene Version von enigma2 genutzt hat. Unter Berufung auf die GPL Klausel
      - In dem Rahmen wurde 2011-2012 auch vor Gericht entschieden, dass Dream nicht ausreichend Rechte an der Marke "enigma2" hat. dejure.org/dienste/vernetzung/…?Text=I-20%20U%20176%2F11

      Ergebnis war:
      - 2011 bringt Dream mit enigma2 3.2 die erste Version ohne offene C++ Sources des Kerns raus. Das war zu Zeiten des OE 1.6. Ergebnis war im Wesentlichen, dass das Patchen für Clones aufwendiger wurde.
      - Im Laufe der Zeit kamen weitere e2 Versionen bei Dream raus. Oft aber nur mit der jeweiligen Entwicklungsumgebung bezeichnet. e2 4.0 kam mit OE 2.0, e2 4.2 mit OE 2.2, e2 4.3 mit OE 2.5
      - Ab e2 4.2 hat Dream den Markennamen enigma2 durch DreamOS ersetzt (vermutlich wegen des Urteils oben).

      Das war also ein langsamer Prozess und ist im Grunde 2011 wegen der Clones losgetreten worden.

      Hilfsbereit schrieb:

      puhhhh, wenn man das alles erklärt, wird ja eine Geschichtsstunde draus ;) .

      zu 4. auf OE1.6 basieren z.B openATV, openNFR, PurE2, usw., auf OE2.0 basieren z.B. das NN2 weekly Image, Merlin 3, oozoon hats sicher auch ein OE2.0 basiertes Image. OE2.2 ist das unmittelbare Vorgängerimage zum OE2.5 und trägt den Beinamen DreamOS. zu beiden OE-Versionen gab/gibt es Images von DP, NN2,Merlin,oozoon usw.
      Auch das ist ungenau bis falsch. Alle genannten "OE 1.6 Images" basieren auf ihren eigenen Forks, die im Kern (PLi) schon vor OE 1.6 bestanden. Erst ab e2 3.2 (das war aber auch noch im OE 1.6!) haben sie sich dann aber deutlich in andere Richtungen entwickelt, weil der Kern nicht mehr freigegeben war.


      grhansolo schrieb:

      - Dadurch, das bei DreamOS nur der Kern Closed Source ist kann die freie Community trotzdem wunderbar weiterhin Plugins und dergleichen entwickeln, wie es z.B. @gutemine macht.
      Ja. Es geht sogar noch weiter, weil ja nur der C++ Kern Closed Source ist. Also nur der Source Code für die einzelne Datei /usr/bin/enigma2 ist "unter Verschluss". Die Schnittstellen dazu sind alle in Python frei verfügbar und auch viele, wesentliche Bestandteile des engima2 Kerns sind nach wie vor verfügbar. So konnte @Dr.Best z.B. damals die Kanalliste komplett neu bauen, obwohl das eindeutig zum Kern von e2 gehört ;)


      Zu 2:
      Frag das doch die Gemini-Entwickler. Der Ansatz als Plugin hat Vor- und Nachteile.
      Wenn man ein eigenes Image bereitstellt, kann man vieles mehr auch im Linux-Bereich ändern. Man kann auch im e2 Kern nach wie vor viel ändern, was im Image einfacher ist. Auch bietet man durch ein Image alles in einer geschlossenen Umgebung an, die man weitestgehend kontrollieren kann. Das hilft bei der Fehlersuche.
      Andererseits bringt ein komplettes Image auch viel Overhead mit und man muss Sachen im Zweifel doppelt und dreifach machen. Auch mag es nicht jeder als Vorteil sehen, dass verschiedene Leute quasi die gleiche Basis anbieten, wo es das doch schon vom Hersteller fertig gibt.

      Zu 3 und 4:
      OE steht für OpenEmbedded, welches in Form von OpenDreambox (git.opendreambox.org/) als Entwicklungsplattform für die Dreambox Images und enigma2 dient. Die Entwickler von Dream betreuen diese Plattform und wechseln von Zeit zu Zeit auf ein neues OE. In aller Regel ist ein neues OE auch mit neuer Hardware oder wenigstens grundlegend neuer Software verbunden.
      Beispiele:
      - HD Fähigkeiten wurden mit OE 1.5 eingeführt
      - OE 1.6 war eher eine sanfte Evolution, z.B. wurde von ipkg auf opkg umgestellt. Im Laufe von enigma2 erfolgte aber auch die Einführung von Closed Source enigma2 3.2
      - enigma2 4.0 wurde mit OE 2.0 eingeführt. Außerdem die "v2 Hardware" Versionen mit mehr RAM und Flash-Speicher. Für die 7025 gab es kein OE 2.0 mehr.
      - DreamOS (enigma2 4.2) wurde mit OE 2.2 eingeführt. Der gesamte Linux Unterbau wurde neu gestaltet und z.B. auf dpkg (.deb Pakete), systemd und weitere "große Tools" umgebaut. Außerdem gab es mit der 7080 und 820 deutlich schnellere Hardware. Sämtliche vorherige Hardware wird mit OE 2.2 nicht mehr unterstützt.
      - OE 2.5 hat erstmals UHD Unterstützung eingeführt und wurde mit der 900 released. Es ist (Stand Heute) der neueste Entwicklungszweig mit neuem Linux Kernel, neuem gstreamer Framework, etc.

      Stand heute kann man zusammenfassen: OE 2.0 ist die neuste Version für alte Hardware (außer 7025). OE 2.5 ist die neuste Version für neue Hardware.
      Im OE 2.0 passiert entsprechend nicht mehr viel. Es gibt noch ein Merlin OE 2.0, das aber so gut wie gar nicht mehr aktualisiert wird. Von NN2 gibt es noch ein OE 2.0 weekly.
      Das OE 2.2 ist inzwischen durch das OE 2.5 abgelöst und wird daher auch von keinem Team mehr raus gebracht: OE Änderungen ab Dezember 2016

      Mir persönlich gefällt die Unterteilung in OE Versionen gar nicht, weil das am Ende rein aus Image-Bauer und Entwickler Sicht ist, aber für den Nutzer viel zu viele Sachen durcheinander wirft. So gab es z.B. innerhalb des OE 1.6 deutlich größere Änderungen, als es von OE 1.5 auf OE 1.6 war.

      Die Open* Images haben sich von der Benennung seitens Dream schon lange gelöst. Manche versuchen noch Dream zu übertrumpfen (bei VU gibt es in "3.0 Images"), aber das so als würde man die Version von Firefox mit der von Chrome vergleichen... Deshalb reagiere ich auch allergisch darauf, wenn jemand Open* Images als OE 1.6 Images bezeichnet (s.o.).

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von m0rphU ()

    • Neu

      Ja. VTI ist eine ganz besondere Frechheit. Dream wird mit Verweis auf Open Source und Closed Core verteufelt. Alles, was nicht bei drei auf den Bäumen ist wird wegen Open Source integriert und aufgenommen. Aber selbst, gibt man überhaupt gar nichts Preis oder gar zurück. Das alles unter dem Deckmantel der vermeintlich freiwilligen Community Arbeit.
      Andererseits bietet man bei VU wenigstens eine eigene, offizielle GPL Code-Basis. Die nutzt nur keiner in der Reinform, sondern in Form des Closed-Source VTI.

      Und natürlich enthalten viele Versionen der e2 Forks in der Tat noch viel OE 1.6 Code, bzw. sind zumindest fast vollständig dazu kompatibel. Aber das heißt ja nicht, dass das nicht heute eine Weiterentwicklung wäre. Über die Qualität der Anpassungen und Weiterentwicklung mag ich nicht urteilen.
      Mir gefällt halt die Bezeichnung OE 1.6 Image nicht, weil die unreflektiert übernommen wird und damit zu Missverständnissen führt. Da wird dann behauptet, dass ALLES in JEDEM Open* Image veraltet wäre. Das ist in sachlichen Diskussionen extrem schädlich, weil einfach wiederlegbar (man achte nur auf Kernel, GStreamer und co). VU hat soweit ich das Überblicken kann in deren Code Basis tatsächlich auch Weiterentwicklungen angetreten.

      Meine Sichtweise der Open* Images ist so, dass dort in aller Regel viel Arbeit in Integration und "Verwaltung" gesteckt wird. Dafür fehlt es dort an echtem Willen zu eigenen Neuentwicklungen. Vielleicht wird dort auch deshalb viel wert auf Rückwärts- und Cross-Plattform-Kompatibilität gelegt, damit man eben viel Code weiter- und wiederverwenden kann.

      Demgegenüber steht Dream mit fundiertem Entwickler-KnowHow, das sich über Jahre entwickelt hat und von Dream ja auch hoffentlich gut finanziert wird. Mit dem Background wird dann schneller mal etwas grundlegend neues eingeführt oder der Bestand inkompatibel gemacht. Das funktioniert manchmal sehr gut (z.B. systemd, neue DreamOS APIs, EPG-Datenbank, etc.), manchmal weniger gut (CEC, HbbTV).
    • Neu

      Frage in welche Kategorie gehören die HDMU-Image[1] die Plattform (SH4, MIPS und ARM) übergreifend sind ?

      [1] hdmedia-universe.com/board/pages.php?pageid=1&tabid=33
      Wahres Wissen beruht auf Erfahrung, alles andere ist nur Information.
      (Albert Einstein)

      Μπορώ να ζήσω στην Ελβετία αλλά στο δεοξυριβονουκλεϊκό οξύ μου είναι η κυπρος της επαρχίας Αμμοχώστου
    • Neu

      Eing gutes Beispiel von Geben und Nehmen und Missachtung der GPL ...

      dort liegt sogar das Partnerbox Plugin mit folgender maintainer.info

      Quellcode

      1. maintainer.info
      2. OpenPLi team <forum@openpli.org>
      3. Partnerbox
      4. control file:
      5. Description: Partnerbox (Remote Timer and Remote TV Player)
      6. Maintainer: OpenPLi team <forum@openpli.org>
      7. Homepage: http://www.openpli.org

      echt zum Kotzen

      und das ist nur einer der vielen Gründe warum die Trittbrettfahrer forken mussten
      Gruß Fred
    • Neu

      2. Warum war Gemini früher (V1 und V2) ein Image und wird jetzt (V3 und V4) nur noch als Plugin angeboten. Ich verstehe den Sinn nicht. Dann könnte man aus Newnigma2 (V 3.0) ja auch ein Plugin machen. Warum sollte man das tun?

      Nachdem der Hauptentwickler gesundheitsbedingt nicht mehr zur Verfügung stand, war es mit eigenem Image vorbei.
    • Neu

      Fred Bogus Trumper schrieb:

      Eing gutes Beispiel von Geben und Nehmen und Missachtung der GPL ...

      dort liegt sogar das Partnerbox Plugin mit folgender maintainer.info

      Quellcode

      1. maintainer.info
      2. OpenPLi team <forum@openpli.org>
      3. Partnerbox
      4. control file:
      5. Description: Partnerbox (Remote Timer and Remote TV Player)
      6. Maintainer: OpenPLi team <forum@openpli.org>
      7. Homepage: http://www.openpli.org
      echt zum Kotzen

      und das ist nur einer der vielen Gründe warum die Trittbrettfahrer forken mussten
      das war mal bei denen das 3rd party plugin, mittlerweile haben die das im Image integriert, wer das zuerst hatte, ATV oder PLi weiss ich nicht, die dürfen voneinander abkupfern
      wiki.openpli.org/Fallback_remote_receiver
    • Neu

      Nö das ist Blödsinn, ich habe das mit dem Fallback gerade am Wochenende mit nicht mal einer halben Codeseite ins Tuner Error Plugin fürs DreamOS eingebaut, ganz ohne Partnerbox Funktionalität :teach:
      Bilder
      • screenshot.png

        58,48 kB, 1.280×720, 74 mal angesehen
      Bad mood, bad manners, bad Plugins, you have been warned :whistling:

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von gutemine ()

    • Neu

      marthom schrieb:

      2. Warum war Gemini früher (V1 und V2) ein Image und wird jetzt (V3 und V4) nur noch als Plugin angeboten. Ich verstehe den Sinn nicht. Dann könnte man aus Newnigma2 (V 3.0) ja auch ein Plugin machen. Warum sollte man das tun?
      Nachdem der Hauptentwickler gesundheitsbedingt nicht mehr zur Verfügung stand, war es mit eigenem Image vorbei.
      Das Stimmt aber nicht. Sonst würde es auch kein GP3/GP3.x/GP4 geben.
      Warum nicht im Wiki nachlesen?

      wiki.blue-panel.com/index.php/Gemini_Project_3
      Wir haben uns entschlossen, vorerst keine Gemini-Images mehr zu veröffentlichen, weil das mehrere Vorteile bringt:
      1. Wenn es ein neues GP3 Plugin oder GP3 Erweiterungen gibt, muss nicht neu geflasht werden. Ein einfaches Update reicht.
      2. Jeder User kann selbst entscheiden, welches Image er aufspielen will (Kompatibilität mit GP3 vorausgesetzt).


      Sehr schönes Thread.
      Erhoffe das es sachlich bleibt.
      IHAD Teammember
    • Neu

      Naja, wobei man fairerweise auch sagen muss, selbst wenn es im NN2 oder im Merlin Image neue Plugins oder Erweiterungen geben sollte, muss da auch nicht neu geflasht werden. Da reicht zum aktualisieren auch nur ein Image-Update, und schon ist alles wieder aktuell.

      War aber jetzt auch nur so am Rande erwähnt, nicht dass jetzt jemand auf komische Gedanken kommt, wir müssten ständig neu flashen ;) .

      PS: schön, dass es hier bisher so sachlich geblieben ist :thumbup:
      Gruß
      Hilfsbereit

      ... jeder GS, ist ein GS zu viel ...

      mediaportal-weed-skins
      Screenshot richtig erstellen
    • Neu

      Diese Satz ist ende 2010 geschrieben worden.
      Damals gab es ja auch sehr oft update das nur über neuflashen aktuell gebaute image lief. Anpassungen hier und da, könnte nicht anders durchgeführt werden.
      Im Prinzip macht heutige NN2 image auch nicht viel anders mit dem daily oder weekly image, Andere wie Merlin, machen halt weiter wie damals, und bei größere Änderung innerhalb des selbe OE, währe ein neuflashen nötig.
      IHAD Teammember
    • Neu

      Ich denke, so langsam ist alles zu dem Thema gesagt. Ich bin gespannt, was der Threadersteller aus den ganzen Informationen für sich entnehmen kann, und ob alle seine Fragen beantwortet werden konnten.

      Ich spüre schon eine kleine Gereiztheit, das muss ja nicht sein, weil sonst ein Wort das andere gibt. ;)
      Gruß
      Hilfsbereit

      ... jeder GS, ist ein GS zu viel ...

      mediaportal-weed-skins
      Screenshot richtig erstellen
    • Neu

      cepheus schrieb:

      marthom schrieb:

      2. Warum war Gemini früher (V1 und V2) ein Image und wird jetzt (V3 und V4) nur noch als Plugin angeboten. Ich verstehe den Sinn nicht. Dann könnte man aus Newnigma2 (V 3.0) ja auch ein Plugin machen. Warum sollte man das tun?
      Nachdem der Hauptentwickler gesundheitsbedingt nicht mehr zur Verfügung stand, war es mit eigenem Image vorbei.
      Das Stimmt aber nicht. Sonst würde es auch kein GP3/GP3.x/GP4 geben.Warum nicht im Wiki nachlesen?

      wiki.blue-panel.com/index.php/Gemini_Project_3
      Wir haben uns entschlossen, vorerst keine Gemini-Images mehr zu veröffentlichen, weil das mehrere Vorteile bringt:
      1. Wenn es ein neues GP3 Plugin oder GP3 Erweiterungen gibt, muss nicht neu geflasht werden. Ein einfaches Update reicht.
      2. Jeder User kann selbst entscheiden, welches Image er aufspielen will (Kompatibilität mit GP3 vorausgesetzt).

      Sehr schönes Thread.
      Erhoffe das es sachlich bleibt.
      @'cepheus
      Vielleicht weißt Du es ja nicht, Dr.Best und ich waren im IHAD Team.
      Wir haben auch nach unseren Abgang weiterhin Kontakt zu vielen Team Mitgliedern.

      Aber ist ja egal, wie Ihr das verkaufen wollt, ist alles schon lange her.