Posts by ABPSoft

    Quote

    Originally posted by marcus010676
    Und genau dort sind auch Sachen von dmm zurückgeflossen.


    Und selbst wenn sie es nicht wären, wäre es trotzdem völlig Ok. So lange die Lizenzen eingehalten werden, ist niemand irgendein Schmarotzer. Die Frage, ob DMM eigentlich an die hunderten von benutzten FLOSS-Projekte, auf deren Schultern man steht (das erschließt sich so richtig, wenn man mal ein OE selber baut und zusieht, was da alles durchläuft) "was bezahlt", stellt sich genausowenig (es sei denn wie hier als rhetorische Frage eines Advocatus Diaboli) wie die, ob ein Nutzer eines GPL-Forks von E2 "was an DMM bezahlt".


    Essenziell lag der Fehler bei DMM selbst, indem sie eine Lizenz zusammenwürfelten, die nicht-reziproken Codefluss begünstigte, wenn nicht sogar erzwang. "Lieber Konkurrent, Du kannst entweder auf Vertragsbasis nach unserer Pfeife auf unserem proprietären Tree mitspielen, oder Deine eigene GPL-Sandbox ziehen, aus der nie was zurückfließen wird" war eher unglücklich, da jeder Konkurrent, der genau wie DMM der im Embedded-Umfeld so grassierenden Control-Freakery unterliegt, Option 2 wählen würde. Und der Witz: Jedes neue Release konnte man wieder GPL-Forken und seine eigenen Änderungen darauf Rebasen. Nur DMM guckte in die Röhre.


    Die Lehre daraus: Watch your (FLOSS) Licenses.


    Andre.

    Quote

    Originally posted by Jogi29


    um so unverständlicher ist deine Haltung, wenn du ein Fan davon bist, solltest du dich ein die Firma halten, die E2 entwickelt hat, weiter entwickelt und nicht die Schmarotzer.


    Zirkuläre Argumentation?


    Die besagte Firma hat (ihr) E2 nun aber aus dem FLOSS-Ökosystem entfernt, d.h. sie ist für jemanden, der zuallererst mal darauf achtet, gerade indifferent bis irrelevant geworden. Und wir wollen nicht vergessen, dass auch zuvor nie ein richtiges FLOSS-Entwicklungsmodell existiert hat - wo ist das Äquivalent zur LKML, wo reicht die Community ihre Patches ein, die dann diskutiert, verbessert, verworfen oder aufgenommen werden? E2 war selbst früher ganz weit am Rand des proprietären Spektrums, mit einer eigenen, AFAIK nicht OSI-gelisteten Lizenz lediglich mit der Gnade, einen GPL-Fork ziehen zu dürfen. Eigentlich konnte da nie eine echte (FLOSS-Entwickler-)Community entstehen, und das schien beabsichtigt - daraus einen Vorwurf zu konstruieren wirkt also eher fragwürdig.


    Die prinzipielle Frage ist IMO, ob einer dieser GPL-Forks es schafft, genügend Mindshare zu akkumulieren, um das proprietäre Produkt von hinten zu überrollen (die aktuelle Lizenzsituation ist dafür sogar günstig, denn DMM könnte keinen GPL-Code zurück ins eigene E2 mergen). Dazu braucht es aber richtige Entwicklung, innovative Features, Leistungen die Pluginschreiber ganz schnell dazu bringen, die "DMM hardware only"-Mätzchen wieder zu entfernen, weil letztlich auch auf 80% aller DMM-Kisten das freie und bunt sprießende "OpenE2" läuft, und dann könnten sich die Hardwarehersteller darum kümmern, um Kisten mit dem besten Preis-Leistungsverhältnis (bzw. deren Käufer) zu konkurrieren. Und ihre eigenen Entwickler in die Community zu verankern und auf diese Weise die Entwicklung mitzugestalten und finanziell abzusichern (selbstverständlich ohne die ach so liebgewonnene absolute Kontrolle). Ich glaube bloß nicht, dass irgendwas in der Richtung wirklich geschehen wird. Die Community ist viel zu fragmentiert, hat zu wenige Köpfe deren Entwicklungskapazitäten über begeistertes Freizeit-Frickeln hinausgehen und sitzt in "WWW-Boards", die verdächtig wie Türmchen und Burgen aussehen, von deren Zinnen aus man sich dann gegenseitig anscheißt (ein gewisses Bild von Monty Python will sich aufdrängen ;).


    FLOSS-Entwicklung ist Evolution. "Schmarotzer" sind in ökologischen Systemen etwas ganz normales und entwickeln sich gern mal zu Symbionten. Und selbst wenn nicht, sind sie nichts Böses. Als Beleidigung für jemanden, der "sträflich" mit dem eigenen Geschäftsmodell interferiert, wirkt das etwas hilflos. Letztendlich gilt Survival of the fittest. In diesem Sinne: Mal sehn wie's weitergeht.


    Andre.

    Quote

    Originally posted by Kajatan
    Der Technisat schmiert schon ab wenn man einen usb stick mit der ts datei rein steckt...


    Ich habe schon Aufnahmen von einer DM800 und einer DM7020HD auf USB-Stick in einen TechniStar S2 verfrachtet, die liefen dort anstandslos. War aber SD, nie mit HD-Aufnahmen getestet. Musste auch nicht mehr umbenannt werden wie früher (ältere Technisats wollten nur .mpg anfassen, es durfte dann aber ein Transport Stream drinstecken).


    Nervig ist nur, dass der TechniStar da gleich mal ein paar Verzeichnisse drauf anlegt und reinwechselt, auch wenn man nur wiedergeben will. Der denkt wohl, alles was man an den USB steckt ist ein Aufnahmemedium.


    HTH,
    Andre.

    Quote

    Originally posted by DonDavici
    wenn ich eine lauffähige 1.6 umgebung habe wie kann ich diese um oe2.0 erweitern.


    Lass die 1.6-Umgebung in Ruhe. Der Vorteil, wenn Du die schon hast, ist dass Deine Devel-Pakete weitgehend komplett installiert sein sollten.


    Es war nie einfacher.


    Geh ins Toplevel Deiner Entwicklungsarbeiten (~/devel oder was immer Du benutzt, es sollten dort mindestens 40GB frei sein - ja, im Ernst). Dort dann:


    Code
    git clone git://git.opendreambox.org/git/opendreambox.git
    cd opendreambox
    make image


    Und warten. Und evtl. doch fehlende Pakete nachschieben und wieder versuchen. Und wenn nix mehr hilft, http://git.opendreambox.org/?p…opendreambox.html;hb=HEAD lesen.


    HTH,
    Andre.

    Quote

    Originally posted by juanito_perez
    Was nicht funktioniert ist der Explorer (explorer.exe).


    Lies noch mal :winking_face:
    Der Explorer funktioniert auch. Du landest lediglich in einem völlig leeren Verzeichnis, weil OE2.0 Dich nach /home/root wirft. Wenn er allerdings nicht gestattet, von da wegzunavigieren, dann ist das hässlich. Leider ist im Directory Listing auch kein ".." drin, mit dem man nach oben käme.


    Netman hat die Lösung hier aber schon anderswo gepostet: Einen Nutzer anlegen, der FTP-Zugriff gestattet und / als HOME hat.


    HTH,
    Andre.


    Edit: Richtig lesen gilt bilateral :winking_face:

    BTW, blkid ist sogar noch cooler, ohne Parameter sagt es einem alles, was sich zu irgendwelchen angeschlossenen block devices sagen lässt:

    Code
    root@dm800:~# blkid 
    /dev/sda1: LABEL="hdd" UUID="49bde8eb-f1f7-4a89-9c56-9ad640979f5e" TYPE="ext2" 
    /dev/sdb1: LABEL="USB1" UUID="9fd3eef8-1f06-4784-8e65-bf5561c8163c" TYPE="ext3"


    Was die Konvertierung von ext2/3 nach ext4 angeht, kann ich nur auf https://ext4.wiki.kernel.org/i…n_ext3_filesystem_to_ext4 verweisen, da steht alles was es zu wissen gibt. Vorher umount versteht sich :winking_face:


    HTH,
    Andre.

    Quote

    Originally posted by msxler
    Ich habe jetzt die bei meiner DM8000 die Festplatte mit dem Speichermanager von DMM neu formatiert und ich kann nirgens erkennen ob es jetzt ext3 oder ext4 formatiert ist.
    Im fstab steht nur noauto.
    Gibt eine Anzeige (die man im Telnet) eingeben kann um das zu sehen??


    Code
    cat /proc/mounts


    Das zeigt allerdings, wie es gemounted ist, nicht wirklich was da für ein FS drauf ist. Um 100% sicher zu sein, braucht man dumpe2fs, aber das liegt bei Dreams üblicherweise nicht dem Image bei. Könnte sich aber mit OE2.0 geändert haben. Dann

    Code
    dumpe2fs /dev/sda1 | head


    und das Gerät anpassen. Ein ext4 erkennt man an extent unter den Filesystem Features.


    Quote

    Zum weiteren habe ich gelesen, dass man ext3 in ext4 konvertieren kann. (Ohne die Daten zu verlieren)
    Auch hier welche eingaben müssen da gemacht werden??


    Willst Du das wirklich? Du kommst nicht mehr zurück, kannst also kein OE1.6 mehr nutzen, ohne das FS zu versenken. Das will wohlüberlegt sein...


    HTH,
    Andre.

    Quote

    Originally posted by netman


    adduser ftp -h / -S -D -H


    (ftp ist mein hier gewählter neuer User, ihr könnt natürlich auch andere Namen verwenden.
    Mit dem Parameter -h / wird dem User das rootverzeichnis zugewiesen)


    Vorsicht. Der Nutzername ftp hat unter Unix traditionell eine Sonderbedeutung, er aktiviert den anonymen FTP-Zugang. Mag sein, dass das auf der Dream mit dem aktuell beiliegenden FTP-Daemon keine Auswirkung hat, aber ich wollt's gesagt haben. Insbesondere, falls jemand die Idee auf andere Linux-motorisierte Appliances oder Server überträgt.


    HTH,
    Andre.

    Quote

    Originally posted by sin
    Hab grade bestimmt 30-40x "opkg remove blala --force-depends" eingegeben umd das image wieder "sauber" zu machen. :tongue:
    Davon ab das z.t. die geringsten sachen schon nen "--force-depends" brauchen.


    Das könnte sich mit diesem Update deutlich geändert haben:
    http://git.opendreambox.org/?p…5677f5f96d9c73322d91b275f
    Falls wirklich Recommends als harte Depends gewertet wurden, dann verwundert ein solches Verhalten nicht mehr.


    HTH,
    Andre.

    Quote

    Originally posted by oneone
    ich weiß hier einfach iChat mehr weiter, warum klappt der Pc und die dream nicht... Es ist mir ein Rätsel.


    Erstmal Gratulation zum Umbau. Damit, und mit dem Switch am Ende, hinter dem bereits ein anderes Gerät funktioniert, kann man die physikalische Qualität der Strecke eigentlich komplett aus der weiteren Fehlerbetrachtung entfernen. Leider gibt es auch oberhalb des Layer 1 noch genug weitere Schichten, auf denen was schief gehen kann...


    Fragen/Tests:
    [list=1]
    [*]Wer ist in Deinem LAN eigentlich der DHCP-Server?
    [*]Benutzt der NC10 DHCP?
    [*]Bekommt die Dreambox im STOP-Modus eine IP? Kannst Du die dann pingen und kommst Du mit dem Browser auf das WebIF des SSL?
    [*] Wie hängt die neue Strecke eigentlich genau an der Headendseite am Netz? Speziell im Vergleich zum Anschluss des Powerline-Modems?
    [/list=1]
    HTH,
    Andre.

    Quote

    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...

    Quote

    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.

    Quote

    Originally posted by deadcantdance
    Okay, danke für die schnelle Info. Wenn Du mir jetzt noch sagst, was ich wo ändern muss, damit das Clonen funktioniert...


    Edit: Ich denke ich habs gefunden, GIT_BRANCH im Makefile, korrekt?


    Ja, wobei das eigentlich da drin stehen sollte, wenn es das Makefile aus OE 1.6 ist. Ich hab mir das einfach aus dem Repo gezogen und damit den Rest bootstrapped.

    Code
    ...
     * [new tag]         shr/testing2009-1rc1 -> shr/testing2009-1rc1
    You asked me to pull without telling me which branch you
    want to merge with, and 'branch.opendreambox-1.6.merge' in
    your configuration file does not tell me, either. Please
    specify which branch you want to use on the command line and
    try again (e.g. 'git pull <repository> <refspec>').
    See git-pull(1) for details.


    Ähm, sieht aus als wäre Dein geclontes Repository unrund, evtl. durch den kaputten GIT_BRANCH. Am einfachsten dürfte es sein, alles automatisch Erzeugte außer dem Makefile wegzuschmeißen, ein "make initialize" zu geben und dann nochmal zu gucken. Ich weiß nicht genau, wie die Umgebung aussieht, die das hier diskutierte Script präpariert, das nackte OE 1.6 Makefile macht unter dem Toplevel ein Directory für den Boxtyp (MACHINE mit Default dm8000), da drin liegt der Clone von openembedded. Im einfachsten Fall reicht zum Aufräumen also ein "rm -rf dm8000/openembedded" gefolgt von "make initialize". Man kann aber gefahrlos alles wegwerfen, das Makefile in ein leeres Directory stecken und dort starten, der Rest wird angelegt und geholt.


    HTH,
    Andre.


    Edit: Aktuelles Makefile gibt's hier, hab vergessen dass das in 'nem anderen Repository steckt: http://git.opendreambox.org/?p…-opendreambox-1.6;hb=HEAD

    Quote

    Originally posted by deadcantdance


    Code
    git branch --track opendreambox origin/opendreambox || true; \
    		git checkout -f opendreambox \
    	)
    fatal: Not a valid object name: 'origin/opendreambox'.
    error: pathspec 'opendreambox' did not match any file(s) known to git.
    make: *** [/home/user/openembedded/1.6/openembedded/.git] Fehler 1


    Was läuft schief?


    Der remote branch, den Du tracken willst, heißt opendreambox-1.6. Wenn Du nachsehen willst, geht das (ohne Git-Fu) am schnellsten auf http://git.opendreambox.org/?p=openembedded.git;a=summary.


    BTW, OE2.0 braucht wirklich kein Script mehr. Repo clonen, reingehen, make image. Bzw. momentan vorher noch vor die kaputten letzten Commits zurückspulen :winking_face:


    HTH,
    Andre.

    Quote

    Originally posted by elisen-jens


    danke; cooler Tipp; aber das heisst, dass mein TV-Browser und DCC immer mit neuen IPs versorgt werden müssen, oder? Hab das alles auf meinem Windoof-PC so schön verlinkt...


    DHCP kann die Dream (und alles andere) genauso gut immer mit der selben IP "versorgen". Meist per MAC Address Reservation.


    HTH,
    Andre.

    Quote

    Originally posted by gutemine
    Das debian etch kann mann nicht mehr mit debootstrap runterladen weil schon zu alt


    Auch nicht mit archive.debian.org als Mirror? Dort geht's mit buzz los :winking_face:


    Andre.

    Quote

    Originally posted by pepo83


    Also bei dem Test ist XFS eine Spur schneller.


    Klingt ja schon recht vernünftig, nach den ersten Meldungen hier konnte einem Angst werden. Eine vernünftige Blocksize zum Testen mit dd wäre wohl eher 1MiB oder 2MiB, glaube kaum dass E2 auf Boxen mit so wenig RAM noch größere Puffer beim Rausschreiben benutzt. Hast Du das mit Standard-Mountoptions laufen? Mal allocsize probiert? Und das wichtigste - fühlt sich das bei Aufnahme und Wiedergabe auch vernünftig an?


    TIA,
    Andre.

    Quote

    Originally posted by LukaNoah
    Ich kopiere gerade nen Film zurück auf die Box. Übertragungsraten zwischen 4 und 5 Mbit/s. (WinSCP)


    Ich würde jetzt nicht gerade SCP als Benchmark nutzen. Das testet primär den Crypto-Durchsatz der beteiligten CPUs, und mindestens eine davon ist schwächlich. FTP ist da näher dran (und sollte 100Base-TX saturieren, also ca. 11MB/s zeigen), aber am besten sind lokale Tests mit dd(1) von bzw. nach /dev/zero bzw. zwischen zwei Files.


    Kannst Du mal "grep sda /proc/mounts" machen, mich interessiert mal, wie die Parameter bei Defaults aussehen. Für einen PVR wäre als erstes sowas wie "allocsize=4m" hilfreich, eventuell auch noch größer (64m). Preallocation block clustering hilft sehr gegen übermäßiges Fragmentieren. Apropos, XFS hat den großen Vorteil, dass mit xfs_fsr ein bewährter Online-Defragger verfügbar ist. Der von ext4 ist AFAIK immer noch Alpha.


    HTH,
    Andre.