Arch Linux auf der Pandora


eworm said:
Ok, ich trage mal zusammen was mir bisher so aufgefallen ist:
  • Die Konsole hat einen lustigen Türkis-Stich... Wo kommt das her? Ist zwar nicht tragisch, aber auch nicht schöne. Hat das noch jemand? Der Pinguin wird übrigens richtig angezeigt.

  • Ja, habe ich auch und hatte das selbe auch schon mit anderen Kerneln, die ich kompiliert hatte. Wenn da jemand etwas zu weiß, wäre ich über einen Hinweis dankbar. Ich konnte nichts offensichtliches entdecken, was diese eigenartige Farbe auslösen könnte.
    Übrigens ist die Pandora-Konfiguration die dem Pandora-Kernel beiliegt (omap3_pandora_defconfig) leider überhaupt nicht hilfreich, weil diese keinen bootbaren Kernel erzeugt. Deswegen blieb mir nichts anderes übrig, als wirklich alles von Hand zu konfigurieren.
    [*]Die "Maus" funktioniert nicht. Einmal hatte ich alle Funktionen, sonst klappt es aber nicht. Keine Ahnung warum... Die Einstellungen in der .xinitrc sollten übrigens auch in der /etc/skel/.xinitrc gemacht werden.
    [*]Die Erstinbetriebnahme des Netzwerks war recht anstrengend... Könnten wir vielleicht netcfg und eventuell auch einen anständigen Editor (vim) mit in das Image aufnehmen? Der installierte vi steht mit mir auf Kriegsfuss... :confused::
    Es ist auch noch der nano-Editor im Image vorhanden. Ansonsten kann ich aber auch sehr das wpa_passphrase-Tool empfehlen, mit dem man sich sehr einfach einen passenden Abschnitt für seine wpa_supplicant.conf generieren kann.
    [*]Der Touchscreen funktioniert nicht - vermutlich fehlt ein Kernelmodul. Pakete für tslib und xf86-input-tslib habe ich gebaut, siehe weiter oben.
    Ich werde mir das ansehen, aber eigentlich sollte alles nötige im Kernel aktiviert sein, da ich die Config basierend auf einer älteren Config von mir erstellt habe, in der der Touchscreen definitiv funktioniert hatte. Es ist natürlich möglich, dass sich inzwischen etwas verändert hatte. Werde mal danach gucken.
    [*]Die Akkuanzeige funktioniert nicht, ich habe immer 0% verbleibend.
    Hier könnte es tatsächlich sein, dass APM im Kernel nicht aktiviert ist.
    Und mplayer ist kaputt... <_< Soviel zu tollen Abhängigkeiten unter Arch. :-(( Naja, muss nur neu compiliert werden.
    Das war mir auch aufgefallen, dass dort die Abhängigkeiten nicht vollständig berücksichtigt werden. Es lässt sich aber mit ein paar manuellen Nachinstallationen beheben. mplayer funktioniert anschließend. Ich habe dieses Problem auch schon den PlugApps-Entwicklern mitgeteilt.
    Ich denke das waren erstmal alle Baustellen, weiter bin ich noch nicht gekommen weil mir Eingabemöglichkeiten fehlen. Aber ich finde das ist schonmal gar nicht schlecht... Bisher ließen sich die Pakete alle brav installieren. Wenn ich jetzt noch anständig mit dem System kommunizieren kann und die kleinen Macken behoben sind bin ich echt Glücklich damit. :wub:

    Sobald ich anständig mit dem System arbeiten kann schaue ich mir auch das PND-System mal genauer an... Wäre doch gelacht wenn wir das nicht auch ans Laufen bekommen. ;)
    Das sollte wirklich einfach möglich sein. :)
 
wejp said:
eworm said:
Ok, ich trage mal zusammen was mir bisher so aufgefallen ist:
  • Die Konsole hat einen lustigen Türkis-Stich... Wo kommt das her? Ist zwar nicht tragisch, aber auch nicht schöne. Hat das noch jemand? Der Pinguin wird übrigens richtig angezeigt.

  • Ja, habe ich auch und hatte das selbe auch schon mit anderen Kerneln, die ich kompiliert hatte. Wenn da jemand etwas zu weiß, wäre ich über einen Hinweis dankbar. Ich konnte nichts offensichtliches entdecken, was diese eigenartige Farbe auslösen könnte.
    Übrigens ist die Pandora-Konfiguration die dem Pandora-Kernel beiliegt (omap3_pandora_defconfig) leider überhaupt nicht hilfreich, weil diese keinen bootbaren Kernel erzeugt. Deswegen blieb mir nichts anderes übrig, als wirklich alles von Hand zu konfigurieren.

  • Fehlt vielleicht CONFIG_FB_BOOT_VESA_SUPPORT?
    wejp said:
    [*]Die "Maus" funktioniert nicht. Einmal hatte ich alle Funktionen, sonst klappt es aber nicht. Keine Ahnung warum... Die Einstellungen in der .xinitrc sollten übrigens auch in der /etc/skel/.xinitrc gemacht werden.
    [*]Die Erstinbetriebnahme des Netzwerks war recht anstrengend... Könnten wir vielleicht netcfg und eventuell auch einen anständigen Editor (vim) mit in das Image aufnehmen? Der installierte vi steht mit mir auf Kriegsfuss... :confused::
    Es ist auch noch der nano-Editor im Image vorhanden. Ansonsten kann ich aber auch sehr das wpa_passphrase-Tool empfehlen, mit dem man sich sehr einfach einen passenden Abschnitt für seine wpa_supplicant.conf generieren kann.
    Habe ich inzwischen auch gefunden. ;) Dummerweise war ich zu dämlich das bei der Installation zu nutzen... Habe die spitze Klammer ">" auf einer Shift- oder Fn-Belegung gesucht und entsprechend nicht gefunden. :unsure: Hat sich inzwischen geklärt. :p
    wejp said:
    [*]Der Touchscreen funktioniert nicht - vermutlich fehlt ein Kernelmodul. Pakete für tslib und xf86-input-tslib habe ich gebaut, siehe weiter oben.
    Ich werde mir das ansehen, aber eigentlich sollte alles nötige im Kernel aktiviert sein, da ich die Config basierend auf einer älteren Config von mir erstellt habe, in der der Touchscreen definitiv funktioniert hatte. Es ist natürlich möglich, dass sich inzwischen etwas verändert hatte. Werde mal danach gucken.
    Ok...
    CONFIG_TOUCHSCREEN_ADS7846=m
    Aber: In /lib/modules/ ist nix drin. Habe ich da kaputt gemacht oder hast du die Module nicht installiert?
    wejp said:
    [*]Die Akkuanzeige funktioniert nicht, ich habe immer 0% verbleibend.
    Hier könnte es tatsächlich sein, dass APM im Kernel nicht aktiviert ist.
    Im sys-Dateisystem (/sys/class/power_supply/bq27500-0/) findet man die entsprechenden Werte... Der Userspace kann das aber aus irgend welchen Gründen nicht auslesen. Wenn man ein wenig sucht findet man Pandora-Spezifische Patches für das Xfce-Panel-Plugin... Das müsste man nochmal einen Blick drauf werfen.
    wejp said:
    Und mplayer ist kaputt... <_< Soviel zu tollen Abhängigkeiten unter Arch. :-(( Naja, muss nur neu compiliert werden.
    Das war mir auch aufgefallen, dass dort die Abhängigkeiten nicht vollständig berücksichtigt werden. Es lässt sich aber mit ein paar manuellen Nachinstallationen beheben. mplayer funktioniert anschließend. Ich habe dieses Problem auch schon den PlugApps-Entwicklern mitgeteilt.
    Habe ich inzwischen auf festgestellt. Wenn das Problem noch jemand hat - benötigt werden "libass", "gsm", "mpg123", "faad2" sowie "rtmpdump".
    wejp said:
    Ich denke das waren erstmal alle Baustellen, weiter bin ich noch nicht gekommen weil mir Eingabemöglichkeiten fehlen. Aber ich finde das ist schonmal gar nicht schlecht... Bisher ließen sich die Pakete alle brav installieren. Wenn ich jetzt noch anständig mit dem System kommunizieren kann und die kleinen Macken behoben sind bin ich echt Glücklich damit. :wub:

    Sobald ich anständig mit dem System arbeiten kann schaue ich mir auch das PND-System mal genauer an... Wäre doch gelacht wenn wir das nicht auch ans Laufen bekommen. ;)
    Das sollte wirklich einfach möglich sein. :)
 
Ich habe mal die Config auf die genannten Dinge überprüft und tatsächlich war (wie inzwischen auch korrekt angemerkt) der Touchscreen-Treiber nicht im Kernel. Ich habe einen neuen Kernel compiliert, der diesmal sowohl den Touchscreen-Treiber, als auch das APM-Interface enthält. Touchscreen läuft damit bei mir ohne weiteres zutun, jedoch muss man in der Xorg-Config die X- und Y-Achsen für den Touchscreen spiegeln.

Kernel Download

Das Kernel-Image einfach nach /boot/ auf der SD-Karte kopieren. Evtl. vorher den alten Kernel sichern.

Dass keine Module vorhanden sind hat übrigens schon seine Richtigkeit. Es war meine Absicht zumindest während der Testphase alles wichtige direkt in den Kernel zu kompilieren. So kann man einfach den Kernel austauschen, was für das Testen praktischer ist, als auch immer darauf zu achten die aktuellen Module mitzunehmen. Wenn die Kernel-Config dann mal einen Stand erreicht hat, bei dem alles wichtige funktioniert, werde ich vermutlich die optionalen Sachen in Module auslagern.

Edit:
Fehlt vielleicht CONFIG_FB_BOOT_VESA_SUPPORT?
Die Option ist nicht anwählbar, ist vielleicht auf x86 beschränkt.
 
Ok, mein Touchscreen bewegt sich auch... Allerdings noch falschrum. :p
Da war meine Arbeit mit der tslib wohl umsonst...

Allerdings geht mir jetzt Xorg auf den Keks - jedes Mal wenn die ihre Konfiguration komplett über den Haufen werfen komme ich erstmal nicht mehr damit klar. Wie kann ich das denn jetzt auf die Schnelle spiegeln?
 
geniale Sache, vielen Dank an euch beide!!
Fehlt nur noch meine Pandora :-((
 
Es wird langsam... Ich habe jetzt in der /etc/X11/xorg.conf.d/10-evdev.conf in der InputClass für Touchscreen Folgendes eingetragen:
Code:
Option "InvertX" "true"
Option "InvertY" "true"
Jetzt müsste ich nur noch bis in die Ecken kommen, irgendwie muss ich das jetzt also kalibrieren.
 
eworm said:
Jetzt passt es...
Code:
Option "Calibration" "100 3900 200 3800"
musste nach dazu. ;)
Wollte auch grade schon was dazu schreiben, aber Du warst schneller. ;)
Um die Werte zu ermitteln kann man übrigens xinput verwenden (Package: xorg-xinput).
Mit "xinput 12 237 32 w x y z" mit w,x,y und z jeweils Zahlenwerte, kann man sich herantasten.
 
Sehr nice, würde euch gerne unterstüzten nur ohne entschrechende hw geht das leider nicht so einfach. ^^
Nur eine bitte hätte ich vorab, wenn ihr irgendwie patches selbst schreibt, wäre das sehr cool wenn ihr die öffentlich zur Verfügung stellen könntet, dann muss man später die Arbeit nicht doppelt machen :)
 
taake said:
Sehr nice, würde euch gerne unterstüzten nur ohne entschrechende hw geht das leider nicht so einfach. ^^
Nur eine bitte hätte ich vorab, wenn ihr irgendwie patches selbst schreibt, wäre das sehr cool wenn ihr die öffentlich zur Verfügung stellen könntet, dann muss man später die Arbeit nicht doppelt machen :)
Klar, machen wir! ;) Also ich zumindest.
Wobei es bisher auch noch nicht wirklich viele bzw. gar keine Patches gibt... Man braucht die richtigen Optionen im Kernel und ein paar Konfigurationen (das mit den invertierten Achsen und der Kalibierung z.B.) - läuft also praktisch out of the box.
ED sollte sich vielleicht wirklich überlegen ob das nicht als Basis für die nächste Version zu benutzen ist...

Was mir noch fehlt ist Claws-Mail - warum gibt es das nicht in den repos? Wieder eine Sache, an die man sich mal dransetzen kann.

Wejp, machst du deine Kernel eigentlich von Hand oder gibt es da ein PKGBUILD zu?
 
eworm said:
taake said:
Sehr nice, würde euch gerne unterstüzten nur ohne entschrechende hw geht das leider nicht so einfach. ^^
Nur eine bitte hätte ich vorab, wenn ihr irgendwie patches selbst schreibt, wäre das sehr cool wenn ihr die öffentlich zur Verfügung stellen könntet, dann muss man später die Arbeit nicht doppelt machen :)
Klar, machen wir! ;) Also ich zumindest.
Ich natürlich auch.
Wobei es bisher auch noch nicht wirklich viele bzw. gar keine Patches gibt... Man braucht die richtigen Optionen im Kernel und ein paar Konfigurationen (das mit den invertierten Achsen und der Kalibierung z.B.) - läuft also praktisch out of the box.
Ich habe übrigens extra die Kernel-Config mit in den Kernel compiliert (/proc/config.gz), so dass sich jeder die Konfiguration ansehen kann und darauf basierend auch selbst Kernel kompilieren kann. Die verwendeten Kernel-Sourcen habe ich in meinem Blog-Eintrag verlinkt.
ED sollte sich vielleicht wirklich überlegen ob das nicht als Basis für die nächste Version zu benutzen ist...
Das würde mir auch sehr gefallen, insbesondere die Aktualität von Arch ist sehr angenehm und man hat eine große Menge an verfügbaren Paketen die man einfach über pacman installieren kann.
Was mir noch fehlt ist Claws-Mail - warum gibt es das nicht in den repos? Wieder eine Sache, an die man sich mal dransetzen kann.
Das ist eigenartig, weil es claws-mail im normalen Arch ja gibt. Sollte aber einfach sein, da ein Paket für zu basteln.
Wejp, machst du deine Kernel eigentlich von Hand oder gibt es da ein PKGBUILD zu?
Bisher mache ich das komplett von Hand, habe aber bereits geplant ein PKGBUILD zu erstellen. Ich wollte den Kernel zunächst einigermaßen lauffähig haben, aber ein richtiges Paketist letztendlich natürlich sehr sinnvoll.
 
So mal nen kleiner Erfahrungsbericht von einem Arch N00b :)
Ich habe bis auf Arch eigentlich schon alle Linuxe zum rennen gebracht deswegen fand ich das mal spannend :)

Booten:

Hey man das rennt ja wie ein Junges Fohlen. Das ist wirklich eine komplett andere geschichte wie das Orginal Angstrom image.. Kann das daran liegen das nicht Sysv-init sondern upstart benutzt wird? ich gebe zu ich habe nicht reingeschaut, die Zeit war zu kurz :)

Desktop und Arbeiten:

Ok openbox mögen einige.. ich gehöre nicht dazu, aber was leider wirklich nicht so schön ist, NOCH(nicht das wieder einer rummosert!), ist das die Tastatur und die Maustasten noch nicht wirklich funktionieren :) Die Shift taste mit dem Shoulderbutton funktioniert bei mir immer nur beim 2. Buchstaben was ziemlich nervig ist beim eintippen von wpa_supplicant :)
Die FN-Taste prellt leider.. Beim pacman kann man Großbuchstaben zum glück mit --sync umgehen. Danke an zLoud hier :)
Insgesammt muss ich sagen das das System leider noch einen unausgegorenen Eindruck hinterlässt.
ABER!!!11einseinself..

Man sieht die möglichkeiten und die sind schon ehrlich gesagt fantastisch. Man sieht wie schnell eine Pandora wirklich booten könnte und wie gut sie reagieren könnte. Ich denke wenn ED das mal probiert wird er auch begeistert sein. Das orginal Image ist gut und funktioniert auch gut, aber das hier hat gezeigt wo wir hin kommen könnten, ob mit angstrom auch das kann ich nicht beurteilen. Wejp super Arbeit wenn du jetzt noch den GMU reinbaust kriegste noch ne Eins :)
 
Danke für das Feedback, Holliefant! Ein Gmu-Paket werde ich noch erstellen. Das ist ja klar. ;)
Die anderen Problemchen, werden sich hoffentlich auch noch lösen lassen.
taake said:
Für den X11 input, also die Tasten kann ich euch xev empfehlen
http://www.x.org/archive/X11R7.5/doc/man/man1/xev.1.html
Wenn sie schon ein event erzeugen ist es um einiges einfacher die Tasten richtig zu mappen.

Nur so als Tipp, wenn es ihr es nicht eh schon kennt.
xev ist wirklich ein nützliches Tool. Leider hilft es allerdings in diesem speziellen Fall nicht weiter, weil das eigenartige Verhalten der Tastatur von einem Bug im Kernel herrührt. Ich habe die Ursache inzwischen auch etwas eingrenzen können. Der Fehler scheint vom gpio_keys-Treiber, oder zumindest in Zusammenhang mit diesem, ausgelöst zu werden. Dazu muss man wissen, dass die Tasten der Pandora elektrisch unterschiedlich angebunden sind. Die meisten Tasten des normalen Keyboards sind als Matrix-Keyboard verdrahtet und das ganze ist über den TWL4030-Hilfschip angeschlossen, während die Tasten für die Spielsteuerung und ein paar weitere direkt an GPIOs hängen. Wenn ich nun den Treiber für die GPIO-Tasten deaktiviere, funktioniert der Rest der Tastatur auf einmal völlig normal. Die Spielsteuerungstasten funktionieren so natürlich gar nicht, allerdings waren die bei aktivem Touchscreen ohnehin gestört (Interruptproblem?).
 
Erst auch mal von mir vielen Dank :)

Ich wollte nur kurz einwerfen, dass es vlt. sinvoll wäre, wenn wir uns zusammen erst mal auf ein OS konzentrieren. Ja ich weiß es lebe die Vielfalt und ich finde es auch wirklich toll, dass das geht. Aber wir sind ja insgesamt in einem noch recht jungen Stadium, wäre es da nicht besser erst mal am Angstrom rumzuschrauben, bis die Pandora wirklich gut stabil läuft?
Das ist aber natürlich nur meine Meinung, was denkt ihr dazu?
 
ABC said:
Erst auch mal von mir vielen Dank :)

Ich wollte nur kurz einwerfen, dass es vlt. sinvoll wäre, wenn wir uns zusammen erst mal auf ein OS konzentrieren. Ja ich weiß es lebe die Vielfalt und ich finde es auch wirklich toll, dass das geht. Aber wir sind ja insgesamt in einem noch recht jungen Stadium, wäre es da nicht besser erst mal am Angstrom rumzuschrauben, bis die Pandora wirklich gut stabil läuft?
Das ist aber natürlich nur meine Meinung, was denkt ihr dazu?
Ich muss sagen, dass das Pandora OS auf mich ziemlich zusammengefrickelt wirkt (nicht böse gemeint), wodurch ich relativ wenig Lust habe, daran etwas zu optimieren oder groß Arbeit hineinzustecken. Es ist auf der anderen Seite aber auch kein gutes Test-System oder eine Beta-Version für eine kommende stabile Version, weil es auf ziemlich alten Komponenten basiert. Es wirkt mehr wie eine Übergangslösung, bis etwas vernünftiges da ist. Ich sage nicht, dass Arch das sein soll (wobei es nicht unbedingt verkehrt wäre darauf aufzusetzen). Ich habe auch mal gehört, dass bereits eine neue Pandora OS-Version in Arbeit ist, davon gesehen habe ich allerdings noch nichts.
Wichtiger war für die Motivation, etwas Neues zu probieren, für mich aber einfach die Herausforderung und der Spaß an der Sache.
Eines darf man aber ohnehin nicht vergessen: Der kritischste und wichtigste Teil am ganzen OS ist immer noch der Kernel und von Verbesserungen am Kernel profitieren alle Systeme, die den jeweiligen Kernel einsetzen und hier denke ich ist es nicht schlecht, wenn der aktuelle Pandora-Entwicklungszweig vom Kernel auch mal etwas in einem richtigen System getestet wird. Das Pandora OS setzt ja momentan noch immer auf den alten 2.6.27-Kernel.
 
Es ist spannend die Anpassung von Arch auf p&|a mitzuverfolgen. Also, weiter so! :yes: Das offizielle Angström wird davon auch profitieren.
 
wejp said:
ABC said:
Ich wollte nur kurz einwerfen, dass es vlt. sinvoll wäre, wenn wir uns zusammen erst mal auf ein OS konzentrieren. Ja ich weiß es lebe die Vielfalt und ich finde es auch wirklich toll, dass das geht. Aber wir sind ja insgesamt in einem noch recht jungen Stadium, wäre es da nicht besser erst mal am Angstrom rumzuschrauben, bis die Pandora wirklich gut stabil läuft?
Das ist aber natürlich nur meine Meinung, was denkt ihr dazu?

Ich neige dazu, dir zuzustimmen, zumal das System der Pandora IMHO nicht wirklich so schlecht ist, wie es hier angeklungen ist ...
ABC said:
Ich muss sagen, dass das Pandora OS auf mich ziemlich zusammengefrickelt wirkt (nicht böse gemeint), wodurch ich relativ wenig Lust habe, daran etwas zu optimieren oder groß Arbeit hineinzustecken.

Was meinst du da konkret? Im grossen und ganzen ist es doch gar nicht so schlecht (OK, man sollte mit opkg doch etwas vorsichtig sein, bevor einem das wichtige Systemkomponenten gegen evt. inkompatible ersetzt, aber sonst)?

Ich wuerde es uebrigens begruessen, wenn in kuenftigen Firmware-Versionen per Default die "dosfstools" und "cifs" vorhanden waere (OK, das sind Pakete, die man anscheinend auch gefahrlos per opkg nachziehen kann, aber warum nicht gleich per Default mit hineinpacken? Zumal der Zugriff auf SMB/CIFS/Windows-Freigaben von der Pandora aus doch durchaus sinnvoll ist und ebenso die Moeglichkeit, nach einem evt. crash das Filesystem auf der Flash-Karte checken zu koennen ... natuerlich nur, nachdem man es vorher ausgehaengt hat ...).
ABC said:
Es ist auf der anderen Seite aber auch kein gutes Test-System oder eine Beta-Version für eine kommende stabile Version, weil es auf ziemlich alten Komponenten basiert. Es wirkt mehr wie eine Übergangslösung, bis etwas vernünftiges da ist.

"Immer das neueste vom neuen" ist nicht wirklich immer die bessere Loesung ...
ABC said:
Ich sage nicht, dass Arch das sein soll (wobei es nicht unbedingt verkehrt wäre darauf aufzusetzen). Ich habe auch mal gehört, dass bereits eine neue Pandora OS-Version in Arbeit ist, davon gesehen habe ich allerdings noch nichts.

Ja, das ist wohl so.
ABC said:
Wichtiger war für die Motivation, etwas Neues zu probieren, für mich aber einfach die Herausforderung und der Spaß an der Sache.

Das ist natuerlich ein Argument (das selbe, das mich dazu bewogen hat, eine native GCC-Umgebung mit aktuellsten Versionen auf der Pandora zu bauen) ...
ABC said:
Eines darf man aber ohnehin nicht vergessen: Der kritischste und wichtigste Teil am ganzen OS ist immer noch der Kernel und von Verbesserungen am Kernel profitieren alle Systeme, die den jeweiligen Kernel einsetzen und hier denke ich ist es nicht schlecht, wenn der aktuelle Pandora-Entwicklungszweig vom Kernel auch mal etwas in einem richtigen System getestet wird. Das Pandora OS setzt ja momentan noch immer auf den alten 2.6.27-Kernel.

Hast du mal nachgesehen, welche Neuerungen die aktuelleren Kernel auf der Pandora bieten? Dass muss gar nicht so furchtbar viel sein (ich habe noch nicht nachgesehen, aber ein alter besser angepasster Kernel waere mir auf der Pandora lieber, als ein neuerer, bei dem es an allen Ecken und Enden mit der optimalen Anpassung hakt ...
 
jilse: Du hast da etwas mit dem Zitat durcheinandergewürfelt. Die Textpassagen waren von mir nicht von ABC. Ich antworte trotzdem mal darauf. ;)

Zum Zusammengefrickelt: Ich meine hier weniger das Erscheinungsbild für den Endanwender, als viel mehr den Unterbau. Das sieht arg nach "mit heißer Nadel zusammengstrickt" aus, was sich unter anderem darin zeigt, dass eben das Paketmanagement völlig zerlegt ist. Hier sind Teile der offiziellen Angstrom-Repository-Pakete mit für die Pandora angepasstem Kram vermengt, zumindest teilweise sogar völlig ohne Pakete.
"Immer das neueste vom neuen" ist nicht wirklich immer die bessere Loesung ...
Darum geht es gar nicht. Mir geht es viel mehr darum, dass es für die Entwicklung nicht förderlich ist, wenn das System auf einem sehr alten Stand verbleibt. Insbesondere der alte Kernel ist hier problematisch. Das ist aus mehreren Gründen ein Problem und da rein spielt auch die Frage von dir, was denn am neueren Kernel für die Pandora Neues dabei ist.
Als Problem hat man hier erstmal, dass der alte Kernel mit aktuellen Userland-Programmen zum Teil gar nicht zusammenarbeiten kann. Arch Linux lässt sich z.B. gar nicht korrekt mit dem 2.6.27 booten. Schon alleine deswegen musste ich hier einen neueren Kernel verwenden. Dazu kommen aber auch noch Neuerungen, die im Kernel hinzugekommen sind, die in den 2.6.27 natürlich nicht zurückportiert werden, z.B. funktioniert Power-Management mit dem 2.6.27 ja praktisch gar nicht. Aber auch neuere Treiber werden nicht in den alten Kernel zurückportiert. Die Pandora hat schließlich USB-Host, so dass man grundsätzlich beliebige USB-Geräte anschließen kann - hier sind aktuelle Treiber schon sehr nützlich. Selbst wenn man mit Mühe Treiber backporten könnte - ich halte das für keine gute Idee. Das ist vergeudete Mühe, die an anderer Stelle sinnvoller genutzt werden könnte, wie z.B. dem Arbeiten am aktuellen Kernel. Dort passiert ja zum Glück auch etwas, wenn auch nur von sehr wenigen Personen (insbesondere notaz).
Wenn man bei dem alten Kernel bleibt, setzt man quasi auf einen sterbenden Zweig. Die Hauptentwicklung findet nun einmal im Mainline-Kernel statt.
Dass es aktuell noch an einigen Stellen beim neueren Kernel hakt, ist natürlich nicht schön, lässt sich aber nicht vermeiden. Deswegen bei altem Krempel zu bleiben halte ich für keine gute Idee.
Dass momentan das Pandora OS noch in dieser Konfiguration ausgeliefert wird, hat durchaus seine Berechtigung. Hier aber noch groß Entwicklungsarbeit reinzustecken, halte ich für unangebracht.

Mein Arch-Linux-Tarball ist auch als Experiment zu sehen. Was kann man mit aktuellen Komponenten auf der Pandora machen und wo hakt es noch? Das alles zeigt sich doch am besten, wenn man es tatsächlich auch ausprobiert.
 
Hallo, danke erst mal für die vielen Details. Ich interessiere mich zwar sehr für OS Innereien, binn da aber leider noch nicht so fit :-(

ich wollte hier auch nicht die Stimmung vermiesen, ganz im Gegenteil denke ich, dass du echt Tallent beweißt und ich fände es einfach schade, wenn das nur "just another OS on pandora" wird. Vielleicht könnte man das mit den Hauptentwicklern besser absprechen? Ich denke dann hätten viel mehr Leute was davon :yes:
 
Back
Top