Unterschiede/Vorteile vom OE 2.0 zum OE 1.6

  • Wer kann mir bitte die Unterschiede erklären, zwischen den beiden Image-Arten OE2.0 und OE1.6, bzw. welche Vorteile wird es für den USER geben bei OE 2.0 gegenüber dem OE1.6?

    • Offizieller Beitrag

    1.6 wird eingestellt. - nix mehr neues

    no brain no pain! :495:
    Auf gar keinen Fall die GP-Wiki lesen!!
    sie könnte Deinen Kopf zu schwer für Deinen Hals machen :grinning_squinting_face:
    :sonne:458859-modellist-gif


    attachment.php?attachmentid=158292 Wir wollen uns für das Update bedanken!!
    attachment.php?attachmentid=204594

  • Auf der normalen 800er ohne SE? Der ist gut....


    Ausser regulärem Fernsehgucken wird das auf der Kiste eh nix werden.
    Der MOMENTANE größte Unterschied, die 800er ist selbst mit dem blanken Image so voll das nocht nicht mal mehr platz für einen Skin oder Fritzcall ist.
    Usb geht auch noch gar nicht.
    Abwarten es lohnt noch lange nicht umzusteigen

  • Mache mal bitte ein update - usb auf der 800er geht - seit heute

  • Bis jetzt hatte ich keine Speicherprobleme...


    Gibts evtl. Vorteile zwecks Bootzeit, Performace bei Umschaltzeiten?


    Was gibt es den nun neues bei OE 2.0?

  • Update 0 Pakete da kommt nix. Kein USB

    Einmal editiert, zuletzt von bumbum69 ()

  • Das bedeutet:
    OE 2.0 ist interessant für HbbTV, DLNA und User die "unverschlüsselte" Blurays über die Dream abspielen möchten...


    Die Vorteile von OE2.0 werden daher vermutlich nur die wenigsten Anwender zu schätzen wissen.


    Danke :)

  • Wird denn mit 2.0 löschen endlich mal schneller gehen? Denn das geht mom. so ätzend langsam, dass die ganze Box lahmt. Ich rede nicht von paar GB, sondern von 50GB und mehr.


    Bei Win geht das blitzschnell, weil da schlauerweise nur der Dateiheader gelöscht wird. (Daten sind physikalisch noch da)
    Aber Linux auf der Box meint, es müsste gleich den zu löschenden Bereich formatieren. Warum ist das so?

  • Hi,

    Zitat

    Original von DeMaddin
    Wird denn mit 2.0 löschen endlich mal schneller gehen?


    das hat nichts mit OE2.0 oder OE17.3 zu tun sondern mit dem Dateiformat der Platte.


    Zitat


    Bei Win geht das blitzschnell, weil da schlauerweise nur der Dateiheader gelöscht wird. (Daten sind physikalisch noch da)


    das ist bei Linux eigentlich sogar noch besser dank journaled filesystem. Bei ext3 wrd mehr Wert auf Sicherheit und Datenkonsistenz gelegt und das kostet halt Zeit. ext2 hat kein Journal also weniger Sicherheit aber mehr Geschwindigkeit. Einen Ausweg soll ext4 bieten also Geschwindigkeit mit Sicherheit. Such mal hier da gibt es Tipps wie man ext4 benutzen kann.


    Ach ja einen embedded Prozessor mit vermutlich einem Dual- oder Quadcore der letzten/vorletzten Generation zu vergleichen ist auch etwas unfair.


    ciao

    ---
    7020, Combo, Solo2, Ultimo

    Einmal editiert, zuletzt von Trial ()

  • Dummerweise werden die Lesezeichen von Netzwerkmounts jetzt nur noch angezeigt, wenn diese beim Boxenstart schon online sind.
    Auch dumm ist, dass mein TV " kein Signal " meldet, wenn ich den bei schon gebooteter 8k einschalte.


    Aber vielleicht ändert sich das noch, ist ja noch very experimental.

  • bitte wie bekomme ich die sky karte zum laufen ?


    google hat mirs nicht erklärt ..


    muß das "ding" unbedingt ein "mips32el" sein ?


    danke für verschleierte auskunft.

    schöne grüße,
    sascha


    TVR - because loud is not enough

  • Es geht alles immer so wie immer, mehr Info gibts nicht. :winking_face:

    TunerA: Multifeed
    13°O, 19,2°O, 23,5°O, 28,2°O
    TunerB: LAMINAS OFC-1200
    45°O, 42°O, 40,0°O, 39°O, 36,0O, 33,0°O, 31,0°O, 28.2°O, 26,0°O, 23.5°O, 21,6°O, 19.2°O
    , 16,0°O, 13°O, 10,0°O, 9°O, 7°O, 5°O, 4,8°O, 0,8°W, 4°W, 5°W, 7°W, 8°W, 11,0°W, 12.5°W
    , 15°W, 18,0°W, 22,0°W, 24,5°W, 30°W
    TunerA/B: In Gebrauch
    0,8°W, 9°O, 13°O, 19.2°O, 23.5°O, 28.2°O
    Dreambox: 7000, 7020SI, 7020HD
    Telekom-Entertain


  • Der war gut!!

  • Zitat

    Originally posted by DeMaddin
    Bei Win geht das blitzschnell, weil da schlauerweise nur der Dateiheader gelöscht wird. (Daten sind physikalisch noch da)


    Das ist bei anderen Filesystemen, auch ext3 auf Linux, nicht anders. Wie lange es dauern würde, Deine hypothetischen 50GB komplett zu überschreiben, kannst Du ausrechnen - bei den bescheidenen SATA-Controllern und schlaffen CPUs, von denen wir hier reden, mal grob mit 15MB/s reingehen...

    Zitat

    Aber Linux auf der Box meint, es müsste gleich den zu löschenden Bereich formatieren. Warum ist das so?


    Es ist nicht so. Wenn Dich interessiert, wie es wirklich ist: Wie das klassische Unix FS, BSD FFS, UFS und ext2 benutzt auch ext3 die Blockadressierung über direkte, indirekte, doppelt indirekte und dreifach indirekte Blöcke. Je größer ein File wird, um so mehr Indirektion über Metadaten steckt drin. Außerdem sind alle Blöcke in Bitmaps verzeichnet, um schnell entscheiden zu können, ob sie belegt oder frei sind. Ein richtig großes File zu löschen bedeutet also, massenweise Blockpointer auf Blockpointer zu entsorgen und parallel Bitmaps zu manipulieren. Nun, das geht nicht so sehr schnell, aber man kann schon noch damit leben - wie ext2 und die anderen Exemplare dieser FS-Generation (Stand späte 80er/frühe 90er) demonstrieren. Pappt man jetzt aber an so ein FS ein Log aka Journal dran, in dem jede Metadatenoperation zunächst abgelegt, synchron rausgeschrieben und erst dann an den Live-Daten appliziert werden muss, und hat dieses Journal auch noch I/O-Priorität vor dem Rausschreiben gewöhnlicher Daten, und macht man zur Krönung auch noch den Fehler, dem FS ein Autocommit nach spätestens 5 Sekunden zu verpassen, ja dann - hat man das ext3-Problem "Löschen vieler oder großer Files, oder gar vieler großer ist langsam wie die Krätze und blockiert die eigentlichen Funktionen des FS destruktiv".


    Die Lösung, damit das wieder skaliert, heißt Reduktion der zu loggenden Metadaten-Operationen. Macht man am besten, indem man von Blockmapping auf Extents umsteigt. Ext4 tut das, behält aber ansonsten die Struktur von ext2/3 bei. XFS tut das, aber auf modernerer Grundlage. Beide zippen olle Files wieder so, wie man das erwartet. Ext4 momentan noch ein winziges bissel schneller als XFS bei geringer Parallelität (ein oder zwei Cores), danach überholt XFS. Auf der Dream und ähnlichen PVRs sind sie daher gleichwertig, XFS hat aber noch andere Vorteile, die letztlich wohl auch erklären, warum DMM es momentan favorisiert. Im Prinzip ist XFS sogar kompatibel mit OE 1.6, denn das gab es schon dazumal. Vielleicht kriegen sie ja wenigstens hin, dass die 800HD mit XFS läuft, wenn es da schon nicht zu einem Kernel aus diesem Jahrzehnt reicht...


    Andre.