ZitatAuf was bezieht sich dein Kommentar???
Ich komm gerade nicht mit, was du uns sagen möchtest!!
Ich hatte in meinem Posting die Preise der Packete erwähnt.
Wenn hier von PW die Rede ist, mag das evtl. mittlerweile stimmen. Die sind ja mit ihren Preisen etwas runter. Dafür ziehen sie den Mist mit den Modulen durch. Meine Aussage bezog sich aber allgemein auf Provider. Premiere ist ja nur einer von vielen.
cheers 
Also ich hab dann mal php und apache auf der Box gebaut. Es fehlt noch ein Tool namens flex, welches nicht in der Toolchain enthalten ist. Das ist der Grund, warum beim php builden configure abgebrochen ist.
Hat übrigens alles ohne patchen funktioniert, ich habe es aber noch nicht getestet. Die Builds liefen aber feherfrei durch.
Zu erst packe alle Packete auf die Festplatte nach /hdd
Deine beiden Packete, sowie flex was du hier bekommst.
Telnet auf deine Box und betrete mit "env-chroot" deine Entwicklungsumgebung.
Erstelle flex:
gzip -dc flex-2.5.33.tar.gz|tar -x
cd flex-2.5.33
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" CXXFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" ./configure --build=powerpc-tuxbox-linux-gnu --prefix=/usr --with-gnu-ld --disable-nls --disable-rpath
make
strip -s flex
strip -g libfl.a
make installErstelle Apache:
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" CXXFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" ./configure --build=powerpc-tuxbox-linux-gnu --prefix=/hdd/server/apache
make
make install
strip -s /hdd/server/apache/bin/*Die Apache Header werden bei der php Configure irgendwie im falschen Pfad gesucht. Deshalb linken wir das Verzeichnis hier.
mkdir -p /hdd/server/apache/src
ln -s /hdd/server/apache/include /hdd/server/apache/src/includeApache lässt sich zunächst nicht starten, da ein User Nobody fehlt. Mußt du mal schauen, ob du den erstellen kannst, andernfalls evtl. die Sourcen Patchen oder eine Möglichkeit in der configure nutzen. It's your job.
Vergesse auch nicht den Port 80 auf z.B. 8080 in der httpd.conf zu setzen. Port 80 wird ja schon vom Webif besetzt.
Erstelle php:
cd /hdd
gzip -dc php-4.4.6.tar.gz|tar -x
cd php-4.4.6
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" CXXFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os" ./configure --build=powerpc-tuxbox-linux-gnu --prefix=/hdd/server --exec-prefix=/hdd/server --with-apache=/hdd/server/apache --with-config-file-path=/hdd --with-gnu-ld --disable-rpath
make
make installSo das wars von meiner Seite. Du kannst ja mal über deine Tests berichten.
cheers
Der Vergleich mit dem Auto hinkt wohl etwas eher, meiner Meinung nach.
Nichts für Ungut, aber ich bin der Meinung du solltest dich nach ner anderen Box umschauen.
Manchmal habe ich das Gefühl manche Leute haben nichts zu tun. Setzen sich vor die Box und protokollieren die Bootzeiten. *Kopfschüttel*
Und das ganze Theater wegen 2W Ersparnis. Ich gebe mich ja auch nicht schnell mit allem Zufrieden, aber finde ich doch diese Thematik hier sehr übertrieben.
Wenn du so ein Linuxanhänger bist, kauf die die Box akzeptiere die lange Bootzeit, bzw. den enormen Mehrverbrauch von ca. 2W und genieße die Vielfalt der Ports, die auf der Box dank Linux laufen werden.
Andernfalls bleibt wohl nur ein anderes Gerät, fertig.
ZitatWelche praktische Gründe sind es denn, die DMM davon abhalten, bspw. mit http://suspend2.net/ zu arbeiten? Wenn ich Zeit, Muse und Geld hätte, wäre ich bspw. hergegangen und hätte auf den Flash-Speicher der 600er ein werksseitig vorbereitetes suspend-Image gepackt, das der Kernel bei jedem (Neu)Start einfach "resumed". Somit könnte man sich einen regulären Boot der Box sparen. Und wenn ein resume bei einem "ausgewachsenen" PC schon schneller läuft (der auch mehr Daten zu resumen hat), wird das auch bei einer 600er schneller laufen, als ein reguärer Boot.
Jagut, dann soll Dream aber auch die Option offen lassen, das Suspend Image zu löschen, um den wertvollen Speicherplatz für sinnvolle Sachen nutzen zu können.
cheers
ZitatIch habe php4 mal auf der Dream probiert, configure lief aber nicht
durch, ist ohne Fehlermeldung abgebrochen,bei apache1 auch.
Was heißt abgebrochen?
Auf der Dreambox dauert bei der configure Prozedur beispielesweise das Suchen nach der Maximalanzahl der Zeichen sehr lange, manchmal bis zu 5 Minuten. Dort bleibt configure dann so lange stehen.
Achso hast du auch swap aktiviert? Ist auf der Dreambox eigentlich ein Muß beim compilieren größerer Packete.
Ich schau mir das bei Gelegenheit mal an und schicke dir auch ne config.cache damit die configure schneller durchläuft. Momentan bin ich sehr beschäftigt mit einem arm-elf Prozessor, da will setjmp() nicht so richtig funzen. Brauche ich für die msh schell.
cheers
Zitatconfigure: error: can not run test program while cross compiling
make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden. Schluss.
emanuel@falcon:~/php-4.4.6>
Jaja, genau das meinte ich mit Patchen der Sourcen oder files. Ich finde es immer lustig, das für das Maken von Sourcen die Option des Crosscompilens angeboten wird, dies aber im späteren configure Verlauf an solchen Sachen wie "can not run test programm" scheitert. Dann soll die Option doch ganz weggelassen werden.
Du benötigst im einfachsten Fall eine config.cache dafür. Diese müßte ich dir mal für php auf meiner Box erstellen, das wäre das einfachste. Dort stehen ein paar systemspezifische Variablen drin, die fürs Bauen benötigt werden.
Vielleicht schaue ich mir auch mal php an, hast du einen Link zu den Sourcen?
cheers
NeNe du mußt auch nicht das Image installieren. Ich habe ein extra Howto reingestellt, womit du die Packete auf die Festplatte entpackst und dann von deinem Image (egal welches) via telnet aus in chroot betrittst. Danach ist der Rest wie immer.
Schau mal hier
ZitatJa kallekit,
jetzt probiere ich mal Dein Entwicklerpaket für die Dream.
Hab dich schon gerade als neuen User vernommen.
Zu deinem Script
#! /bin/sh
PATH=${PATH}:/home/emanuel/dreambox-cvs/root/cdk/bin
CROSS=/home/emanuel/dreambox-cvs/root/cdk/bin/
export CC=${CROSS}powerpc-tuxbox-linux-gnu-gcc
export CXX=${CROSS}powerpc-tuxbox-linux-gnu-g++
export AR=${CROSS}powerpc-tuxbox-linux-gnu-ar
export RANLIB=${CROSS}powerpc-tuxbox-linux-gnu-ranlib
export LD=${CROSS}powerpc-tuxbox-linux-gnu-ld
export STRIP=${CROSS}powerpc-tuxbox-linux-gnu-strip
export NM=${CROSS}powerpc-tuxbox-linux-gnu-nm
export PATH=$PATH
export CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s"
export CXXLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s"Das könnt vielleicht etwas zu viel des guten sein.
Folgendes, wenn du den Pfad deines Crosscompilers exportiert hast, mußt du beim exportieren der binutils und des Compilers nicht extra den Pfad mit angeben. "configure" sucht automatisch in allen Verzeichnissen der Pfadvariable nach dem richtigen Tool, deswegen setzt man auch das Verzeichnis beim exportieren an die erste Stelle. Weiterhin werden deine exportierten CFLAGS vom configure Script bzw. spätestens beim Maken vom Makefile und make wieder überschrieben, es bringt hier also wenig.
Besser wäre alles in einem Script:
#!/bin/sh
CROSS_PATH="/home/emanuel/dreambox-cvs/root/cdk/bin"
TARGET="powerpc-tuxbox-linux-gnu"
export PATH=${CROSS_PATH}:${PATH}
cd your_php_unpacked_sourcen
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" \
CXXLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" \
CC=${TARGET}-gcc \
CXX={TARGET}-g++ \
AR=${TARGET}-ar \
RANLIB=${TARGET}-ranlib \
STRIP=${TARGET}-strip \
NM=${TARGET}-nm \
./configure \
--prefix=/hdd/php/usr \
--build=i686-pc-linux-gnu \
--host=${TARGET} \
--exec-prefix=/hdd/php/usr \
--with-config-file=/home/emanuel/dreambox-cvs/cdk/apache_1.3.37/conf \
--with-apache=/home/emanuel/dreambox-cvs/cdk/apache_1.3.37 \
--with-config-file-path=/hdd
make \
CFLAGS+="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" \
CXXLAGS+="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" \
CC=${TARGET}-gcc \
CXX={TARGET}-g++ \
AR=${TARGET}-ar \
RANLIB=${TARGET}-ranlib \
STRIP=${TARGET}-strip \
NM=${TARGET}-nm && make install
exit 0Mußt nur mal schauen, wie sich das mit den Backslash am Zeilenende mit der Shell macht. Bei einem Makefile kein Problem, aber hier weiß ich es nicht 100%. Für solche Sachen ziehe ich deswegen immer ein eigenes Makefile dem Shellscript vor.
cheers
Im großen und ganzen gebe ich dem Recht, was dort steht. Allerdings bin ich der Meinung, daß die Hackerei weitaus weniger Ausmaße hätte, wenn die Provider ihre Packete zu halbwegs humanen Preisen anbieten würden und vor allem receiverkompatibel, heißt Modul etc.. Ich sehe es nicht ein mir bei jedem neuen Abo nach Lust und Laune des Providers einen neuen Receiver in die Stube zu stellen. Ich will meine Dream dort stehen haben, fertig, da wird kein anderes Gerät geduldet. Man hat ja schließlich nicht umsonst damals die Schnittstelle für die Module entwickelt. Dadurch soll ja die Kompatibilität zwischen den Geräten gewährleistet sein.
Wenn das nicht aufhört, wird sich nie was ändern und die Dream, wird dank Linux immer für diese Zwecke mißbraucht werden.
cheers
Was noch wichtiges zu erwähnen wäre!
Du wirst php sicherlich dynamisch gelinkt bauen. Das sollte auch normalerweise der richtige Weg sein, sofern alle libs auf dem Zeilsystem vorhanden sind.
Das ist "leider" bei den Dreamboximages nicht so. Die libs sind zwar meist vorhanden, aber selten vollständig vom Funktionsumfang her dank "mklibs.py".
Du wirst evtl. das Problem haben, das dein php nicht so ohne weiteres auf der Box laufen wird, wegen fehlender aufgelöster Abhängigkeiten.
Was nun tun.
Es gibt 4 Möglichkeiten.
1. Du packst dein php + stuff mit ins cdkflash in deine Entwicklungsumgebung und baust auf dieser Basis ein Image selbts. Dann läuft php auch problemlos allerdings ist die Kompatibilität zu anderen Images nicht gegeben.
2. Du baust php statisch (setze zu den FLAGS ' LDFLAG="-static" ' beim compilieren). Das hat wiederum den Nachteil, dass alle libs (glibc etc.) statisch mit ins binary gelinkt werden und das Tool recht groß wird, mitunter sogar an Performance im Betrieb verliert.
3. Du lässt deinen php/Apache Server in einer chroot Umgebung laufen. Dann kannst du alle benötigten vollständigen libs mit dorthin liefern und unabhängig von den libs im Image deinen Apache & php in chroot betreiben. Diese Variante scheint mir angesichts von php und Apache hier am sinnvollsten zu sein. Du wirst die eingerichteten Apps ja nicht permanent hin und her portieren. Welche libs du benötigst sagt dir ein /lib/ld.so.1 --list dein_tool auf der Dreambox.
4. Du tauschst die libs in dem Image gegen deine eigenen. Allerdings bin ich davon kein Fan, denn ins Image gehören die libs, die auch zum Bauen des Images verwendet wurden. Da weicht ja doch das ein oder andere zwischen den CVS ab.
Bonusvariante -> Werbung in eigener Sache.
Ich habe auf h**p://imageonhd.info eine komplette Enticklungsumgebung (xdevels) bereitgestellt. Diese agiert als Linuxdistri und kann von jedem beliebigem Image aus als chroot Umgebung betreten werden. Du kannst dort quasi alles laufen lassen, was auf einer waschechten Linuxdistri auch funzt (begrenzt natürlich durch die Hardware der Dream). Die Basis dazu ist geschaffen. Die Umgebung verfügt so z.B. über den GNU Compiler C/C++, Binutils, Perl, Phyton, make und was alles noch benötigt wird. Sollte also auch dein php builden in der Cross Environment versagen, kannst du versuchen es direkt auf der Dreambox zu bauen. Das Forum dort würde auch etwas mehr Aktivität begrüßen.
cheers
Warum im cdk bauen?
Du kannst das auch außerhalb vom cdk machen. So habe ich mir z.B. einen Compiler + komplette Entwicklungsumgebung für die Dreambox gebaut -> läuft auf der Dreambox.
Zeig doch mal deine configure, die du erstellt hast.
Vorweg wird nicht alles so einfach auf einer Crossumgebung zu bauen sein. Perl habe ich auf diese Weise nicht hinbekommen. Ich habe das dann komplett auf der Dream gebaut. Ist auch ein Grund für die Entwicklungsumgebung auf der Box gewesen. Wie es mit php aussieht.. keine Ahnung, einige Packete wirst du aber ohne leichte Patches nicht so einfach compiliert bekommen.
Die Basis ist eigentlich immer.
./configure --build=i686-pc-linux-gnu --host=powerpc-tuxbox-linux-gnu
bzw.
./configure --build=i686-pc-linux-gnu --host=powerpc-tuxbox-linux-gnu --target=powerpc-tuxbox-linux-gnu
Build bezeichnet dabei dein Buildsystem, hier i686-pc-linux-gnu und Host dein Gastsystem, das den Crosscompiler enthält. Target wäre hierbei das Zielsystem, auf dem die Binaries laufen sollen. Da Target und Host aber die gleichen Systeme sind, braucht man Target nicht mit anzugeben. Manche configure Scripts versagen auch bei der Angabe des Targets, deswegen sollte Variante 1 reichen. Target und Host können auch verschieden sein, dann nennt sich das ganze Canadian Crosscompile, das nur nebenbei.
Dann setzt du noch ein paar CFLAGS beim Maken bzw. in der configure.
Also
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s"
CXXFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s"
Diese CFLAGS habe ich aus dem Makefile meiner Crossumgebung im Rootverzeichnis.
Einfach mal öffnen und nach TARGET_CFLAGS suchen. Die Optionen -g oder ggdb3 kannst "mußt du" weglassen, sonnst hast du Debuginfos drinn und die Files werden riesig. Die Options "-s" sorgt für das Strippen (entfernen unnötiger Infos mal einfach ausgedrückt) der Binaries auf ein Minimum der Größe. Wenn "-s" nicht funktioniert mal in die Manpage von gcc schauen, stehe da gerade etwas auf dem Schlauch. Ich habe das ganze immer zum Schluß per Hand gestrippt.
Das ganze sieht dann grob in etwa so aus:
1. Entpacke die Sourcen in irgend einen Pfad deines Home Verzeichnisses
2. Exportiere die PATH Variable, so daß dein Crosscompiler gefunden wird.
Befindet sich dein powerpc-tuxbox-linux-gnu-gcc also in /root/cdk/bin dann wie folgt:
export PATH=/root/cdk/bin:$PATH
3. Öffne die Konsole, wenn nicht schon getan, cd in das Verzeichnis der ausgepackten Sourcen, und tippe erstmal ./configure --help für die Übersicht evtl. nötiger Optionen.
4. Erstelle das Makefile
CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" CXXLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" ./configure --prefix=your_path --build=i686-pc-linux-gnu --host=powerpc-tuxbox-linux-gnu your_options...5. Dann kannst du mit make das Packet bauen. Sollten deine gesetzten CFLAGS hier ignoriet worden sein. Kannst du diese auch alternativ beim Maken adden.
Also:
make CFLAGS+="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s" CXXLAGS+="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -s"6. Installiere das Packet in deinen gewünschten Pfad, der bei configure mit --prefix angegeben wurde.
make install7. Alternativ Binaries noch strippen
cheers
Ja, ja sieht ja auch schick aus so ein PC Tower im Wohnzimmer. *Ironie*
Der Vergleich ist meiner Meinung nach nicht gerade gut getroffen oder?
Für dich mögen sich evtl. die Wünsche mit der Hauppauge Karte erfüllen, für mich jedoch nicht. Abgesehen davon habe ich das Disaster mit der TV Karte schon durch. Da verliebt man sich ja förmlich eine eine STB.
Also nichts für Ungut
Zu deinem letzten Statement im Post muß ich sagen, es geht mir genauso
Nun leider kann ich dir spezifisch nicht weiterhelfen, aber da du meinst auf einer x86 Plattform (PC) läuft die Geschichte sauber, wäre für mich evtl. fehlende Performance auf der 7025 denkbar, also heißt evtl. ist beim Anhalten und wieder Starten des Songs die CPU ausgelastet, sodaß es zum Abhacken des Sounds kommt, bis sich die Software wieder fängt.
Wenn es dir möglich ist, versuche das Phänomen doch mal zeitgleich mit top via telnet zu verfolgen, dort siehst ja dann wieviel der daemon an CPU und RAM wegrasselt.
PS: Ich sehe gerade auf der Dox funzt es auch, also wird es daran wohl nicht liegen. Ein Versuch ist es trotzdem wert.
Hast du das Tool auch für die Dbox übersetzt?
Welche Optionen hast du bei configure angegeben?
Hast du evtl. ppc Patches in den Daemon Sourcen drin? Könnte bezüglich Mipsel die Fehler bringen.
Auf welche Geräte greift der Daemon zu? Evtl. sind die nicht korrekt.
cheers
Ohne mir den Log genau angeschaut zu haben, hast du schon mal seriell mit Dreamup ein Original Image geflashed oder nur via Netzwerk?
cheers
Genaueres kann hier sicher niemand sagen, also mal meine Spekulationen und Infos.
1. Starker Prozessor ist nicht gleich starker Prozessor. Die Dream verfügt wohl über einen AMD Chipsatz. Die Frage ist aber ob die Videode/encodierung darüber auch geregelt wird oder es eine Multichip Lösung (Prozessor und Videochip getrennt) wird. Der Chip wird schon von Hause aus einige Formate decodieren können und ich denke Dream wird das Potential schon zu wissen nutzen. Nebenbei ist es mit einer einfachen Implementierung von Codecs nicht getan. Divx und xvid sollen aber kein Problem sein.
2. Network Filesystem sind hier das Stichwort. Funzt ja auch bei den bisherigen Boxen auch, wieso nicht auch bei der 8000er.
Alles andere sollte in irgendeiner Weise immer ein Stream sein, wie soll es auch anders funktionieren? Ob nun mit kontinuierlicher Server/Client Kommunication oder einfach Raw gestreamt sei mal dahingestellt.
3. Nun gut das ist reine Geschmackssache allerdings würde ich mir persönlich keine GUI in irgendeiner Form des Windows Media Centers wünschen. Zum einen ist es prioritär ein Receiver mit vielen Sonderfunktionen und weiterhin hasse ich Windoof.
Enigma ist wie jeder andere GUI auch nur ne Benutzeroberfläche und erfordert etwas Einarbeitung. Abgesehen davon hindert dich das offene Betriebssystem ja nicht daran deine eigene GUI zu basteln.
Diverse Portierung von sinnvollen Tools und Plugins werden schon für die 8000er erscheinen. Du kannst dir sicher sein daß es genügend Leute gibt, die sich nach erscheinen der Box an die Entwicklung machen, mich inbegriffen, sobald ich die Box besitze.
cheers
Ah ok thx, daß reicht mir schon als Info.
Ähm mal nur so ne doofe Frage. So richtig verstehe ich nicht den Sinn des ganzen Projekts. Was genau bringt die Anmeldung meiner Geräte außer irgendwelche Statistiken über mhh... Zugriffszeiten, Downloadzeiten, Betriebsdauer, ich weiß es nicht? Auf der Page steht ja auch nicht viel in den FAQ's. Was hat es denn mit dem ganzen uptime auf sich? Eine kurze "ausführliche" Erklärung wäre nett.
thx
ZitatTrotzdem wäre es nett wenn die long options mitcompiliert würden, weil es tut nicht weh und hilft bei der kompatibilität mancher scripts.
Oder man macht als "guter" Devel das Script compatibel. Sollte doch nicht an einfachen test Abfragen scheitern oder? Ich persönich finde es ok, wenn auf schmalen Systemen mit den Argumenten und Outputs gesparrt wird. Wichtig ist ja nur, daß auch die gewünschten Funktionen integriert sind, ob nun '--bind' oder '-o bind' spielt dabei kaum eine Rolle.
Nebenbei habe ich damals auch die --bind Option bei der Busybox gesucht.
cheers
Hast du mal
mount -o bind dir1 dir2
probiert ?
Ich weiß nicht, wie es aktuell bei der 7025er aussieht, aber die busybox unterstützt nicht zwingend das Argument --bind.
cheers
Zitat- Plugins von der einen laufen nicht auf der anderen und umgekehrt.
- Konfigurationen können nicht einfach abgeglichen werden (z.B. Senderlisten, evtl. Timer, etc)
- Ich muss zwei Linux- Systeme "lernen", ich kenne ja alles nur vom mitlesen, aber so wie mir scheint, fängt es ja schon mit unterschiedlichen Standard- Pfaden an..
1. Naja wenn schon die Codes für die Plugins beider Boxen DM600 und DM8000 bzw. DM7025 übereinstimmen, wirst du aber das jeweilige Plugin nicht auf der anderen Box zum laufen bekommen, da alle 3 Boxen unterschiedliche Architekturen bezitzen. Du benötigst dann also mindestens 2 Crosscompiler und musst die Plugins für jede Box separat übersetzen. Zusätzlich kommt noch das Problem der ungelösten Abhängigkeiten, da gestripte libs in den Images. Ich nehme ja an es wird weiter die glibc auf der Box verwendet und nicht ein Sprung zur uClibc oder anderen µ C-Bibliotheken gemacht?
Zu den Architekturen soweit meine Infos:
DM600 -> Powerpc
DM7025 -> Mipsel bzw. Mips (Welches war noch mal ohne MMU?)
DM8000 -> Laut letzter Info ein AMD-i586, also eine x86 Platform.
2. Bei den Senderlisten gebe ich dir recht.
3. Es gibt eigentlich nur ein Linux. Wenn man es einmal verstanden hat, werden dich auch die unterschiedlichen Pfade, bzw. einige Unterschiede der Konfigurationsdateien und Scripte nicht mehr abschrecken. Da findet man sich schnell zurecht. Das gleiche gilt übrigens auch für große Distris, wie Gentoo, Slackware, Suse ....und wie sie alle heißen, so zumindest meine persönlichen Erfahrungen. Der Unterschied liegt eigentlich nur im Aufbau der Installation und den Benutzeroberflächen bzw. großen Tools zur System- und Packageverwaltung, wie z.B. bei Suse Yast, bei Gentoo Emerge & Co.
Die Basis ist aber die selbe.
ZitatUnd ausserdem: ich will nicht auf einer "neuen" Box ein "altes" Betriebssystem... (Informatiker- Krankheit...)
Naja bei Linux kann man eigentlich nicht unbedingt von einem altem Betriebsystem reden. Es gibt einfach zu viel, was man ändern kann, wobei es hier vielmehr um die Vorteile der Performance und bessere Sicherheit ankommt anstatt auf das Alter der Tools. Klar neuere Sachen sollten meist Vorteile bringen, aber das ist bei Linux nicht zwangsläufig so. Oft genug selbst erlebt.
Abgesehen davon ist enigma nur die GUI und nicht der Kern der Box. Enigma hat zwar viel Einfluß auf das Verhalten der Box, da der Normaluser den größten Teil der Funktionen auf der Box über dieses regelt, aber ansonsten steckt noch mehr dahinter.
Aber ich denke als Proggi wirst du schnell die Vor- und Nachteile selbst herausfinden. Ich kann nur sagen es macht ein heiden Spass alles mögliche Zeuch's auf der Box zu verwirklichen.
cheers