PXML Format aktualisiert


als es noch nicht mal diesen Namen gab und als du vermutlich noch nix von dem Projekt gehört hattest.
Stimmt, kenne die Box erst seit Oktober 2008 . Kannte das Beagleboard schon länger, war aber v.a. schon seit einem Jahr beim Zugucken was beim OpenMoko läuft. Mittlerweile eher enttäuscht und hab auch begriffen, dass der Mix von Mobile und Handheld nur was für Gelegenheitsnutzer taugt. Denn die Verschmelzung macht es zu einem mässigen Telefon und einem mässigen Handheld (genau genommen sogar unbrauchbar mit nur einer Taste und einem virtuellen Keyboard). Also lieber die Pandora als genialen Handheld und ein kleines, leichtes, langlaufendes Kleinsthandy fürs nurTelefonieren.
Eigentlich hab ich auch geschrieben, dass es nur solange obsolet ist, bis sich ein Dev äußert...und nicht, dass der Thread allgemin überflüssig ist.
Also wiederhole ich mich: obsolet heisst, dass es "nicht mehr" von Nutzen ist. Du meintest aber, dass die Diskussion jetzt schon überflüssig ist, bis sich ein Dev äussert und die Diskussion als "nutzlich" anerkennt oder als "unwichtig" abstempelt (womit sie dann den Nutzen verliert und obsolet "wird"). Aber das ist sprachliches Feintuning... :p
Das hat nix mit Trollen zu tun.
Da mir wejb paar gute Haken verpasst hab, war ich etwas voreilig im Zurückschlagen gegen jeden im Ring. Das Trollen nehm ich zurück.
Und die "Standpauke" finde ich ehrlich gesagt ziemlich lustig. Ich selber hab nämlich schon seit das Pandora-Projekt öffentlich bekannt wurde ebenfalls Überlegungen in Threads geschrieben, Vorschläge gemacht und so weiter. Wie einige Andere User auch hab ich mir schon ernsthafte Gedanken über die Pandora gemacht, ... Wir haben Tonnen an Ideen ausgeworfen, ich selbst habe auch etliche Bilder und Renderings zur Hardware gemacht und hier und da Verbesserungsvorschläge empfohlen, bin auf Details eingegangen und habe wie Du einfach meine Gedanken dargelegt. Dass es z.B. Lieferprobleme mit LCD's geben könnte hab ich glaube auch schon vor Monaten orakelt.

yep, aber ein PXML Format selber löst nur einen Teil der Probleme, die Probleme, die ich anspreche mit der Diskussion ist das Problem der Verteilung der Software, ohne, dass ein Index besteht und nicht jede Software soll nun das "Suchproblem" selber lösen.
Ich sprech aus Erfahrung mit solchen abenteuerlichen Geschichten wie "Programmierung auf der DB", wo die "Möchte-Gern-Entwickler" ein Webframework gebastelt haben, dass seine "Programme" auf der DB ablegt. Die "Sprache" war selbst erfunden und die Programmierung erfolgt im WEB-UI. Sogar ein "Einrücken" (ein Codeblock wurde z.B. mit einem IF gekapselt) des Codes musste pro Zeile von Hand im Web-UI erfolgen... als ich die Leute dann nach einem Debugger oder einer Versionskontrolle fragte, nur komische Blicke und Ausflüchte. Aber den Entwicklungsprozess hatten sie trotzdem nicht im Griff. Aber man konnte sooo schnell damit ein paar Sichten im Web-UI einhängen. Zum Entwickeln war das System der reinste Horror. :wacko: :wacko:
Das will ich auch hier aufzeigen: Toll, das Format ist da, wir können die Software ohne Installieren nutzen. Aber viele (auf anderen Linuxdistributionen wunderbar funktionierende) conveniences, sind plötzlich nicht mehr "convenient", weil schlicht und einfach die Pfade nicht fix sind. Der reine Benutzer sieht nicht viel davon, das Teil funktioniert ja, aber die Entwickler schütteln den Kopf. Und ich bin als Softwareingenieur halt "entwicklerfixiert". Mir genügt es nicht, dass dem Benutzer das GUI ausgereift und schnell vorkommt, mir ist es wichtig, dass dafür keine Handstände und Einschränkungen bei den Entwicklern nötig sind.
Und wenn nur kleine Schritte erfolgen (Indexformat und Ort vordefiniert), weiss ich, dass ich damit dem einen oder anderen Entwickler eine Nacht sparen kann ^_^
Dagegen ist es mir weniger wichtig ob die Box nun perfekt designed ist, ob die Software schon fertig ist, ob die game Controls etwas unpraktisch positioniert sind (Auch wenn die Liste der Emu-Games, die ich gleich beim Erhalten der Box wieder mal durchzocken möchte verdammt laaaaaang ist). Da kann ich mich anpassen oder ich merk nicht viel davon. Aber, da ich auf der Box entwickeln möchte, interessieren mich Details zum Entwickeln viel stärker.
Wenn du dich als Laie outest, heisst das, du nichts zum Thema beitragen kannst, daher war für mich der Kommentar schlichtwegs überflüssig (nein, ich meine nicht obsolet :wink: ). Aber dafür hätte ich nicht die Geduld das Tastaturlayout durchzudenken oder Renderings der Box zu bauen. Wenn du da beiträgst, super.

Überhaupt, die Box hat ein gigantisches Potential: viel Idealismus, viele Topleute, die es als Hobby erweitern und euphorische mitdenkende User, die schon vor dem Release eingebunden werden. Ich vermute, dass die versandten Entwicklerboards zum grossen Teil an einige ganz alte Hasen von Entwicklern gegangen sind. Das ganze hat für mich das Potential von einem BSD-Unix / GNU Unixtools / Linux in der Anfangsphase oder noch besser: Der Lord of the Rings Verfilmung. Diese wurde so genial weil viele begeisterte Helfer (vom Schmied bis zum Schreiner) sich ausgetobt haben und die ganzen Details mit Herzblut erstellt haben. Dieses Potential sehe ich auch bei der Pandora. Die Entwickler haben sich dem Projekt dediziert und uns top edge hardware, vollen Einsatz und einen grenzenlosen Spielplatz zum Austoben zugesprochen. Das spornt jeden anderen an sich in die Details zu stürzen, sich einzubringen, viel zu investieren, aus Überzeugung, dass ein Meisterwerk dabei herauskommen wird. Dass sie jetzt schon die Hardware parat haben und fast nur noch die Software fertig stellen, dass wir sehen, dass das Meisterwerk langsam immer konkreter wird, ist einfach nur... GEIL!!
Wenn jetzt ein Schreiner dem Schmied sagt, dass seine "Kunst" obsolet ist, reagiert dieser numal mürrisch :) :twisted:
Aber dabei bringt jeder von uns seinen vollen Einsatz, ist glücklich wenn er später "ein Teil" des Endproduktes ist, etwas beigetragen hat. Seine "Kunst" miteingebracht hat. Also bitte lass bei deinen nächsten Kommentaren etwas mehr Vorsicht mit meiner zarten Künstlerseele walten. Denn ich schätze auch deinen künstlerischen Beitrag zur Pandora. Wenn ich mich dann mal über eine gute Tastaturbelegung freuen werde, denk ich auch an deinen Beitrag.
Am Ende aber sind es nach wie vor die Devs, die entscheiden, was sie von den Vorschlägen umsetzen. Da kannst du noch so viel schreiben, glaub mir.
Darum schreib ich ja so viel, damit sie meinen Punkt verstehen und in die Überlegungen miteinbeziehen. Abgesehen davon ist die Box und das ganze System offen, also entscheiden die Entwickler nur über den Auslieferungsstatus! Danach wird das ganze ein Community-Projekt und wenn ich meinen Vorschlag umsetzen möchte, hack ich ihn selber!! :ph34r: Sie können mir vorschreiben, wie die Box aussieht, wie das Keyboard aussieht, aber die Software kann ich nach meinem Gutdünken anpassen. Das ist der Teil der mich so begeistert!
Wie ging das nochmal.... "They can take our lives but they’ll never take OUR FREEDOM!" - William 'Braveheart' Wallace. :lol:
Mal davon abgesehn, dass ich Apple hasse wie die Pest
Steve hatte genau wie Bill einen "Kumpel", der wirklich Entwickeln konnte und die eigentliche Arbeit tat. Während diese Entwickler nur an der Anerkennung interessiert sind, sind Bill und Steve brutale Geschäftsmänner, die ihre Entwickler auch schon mal belogen und um Kohle beschissen (yep, Steve hat Steve schon vor der Gründung von Apple um Kohle beschissen). Sie wollten einfach nur die grosse Cash-Maschine aufbauen. Der Unterschied ist, dass Bill Trends hinterherhechelt und durch brutale Marktmacht versucht Märkte brutal zu übernehmen, und Steve ein Work-aholic mit Visionen ist, der Trends nicht verpasst (online-music, napster, OO-Progammierung bei Openstep), aber zugleich auch zuviel fordert/erwartet (Mitarbeiterverschleiss, Nextstep mit eigener Hardware verkaufen) und dadurch Fehler begeht (Software ohne Hardwarebindung verkaufen). Bin ziemlich enttäuscht, dass er die Lizenzierung von Nextstep an IBM, Compaq und HP(?) vergeigte. Wir hätten heute wahrscheinlich alle ein nextstep/macosx vor der nase. Apple selber ist für mich ok. Leider eine Profitorientierte Firma, aber die Produkte sind wirklich beeindruckend "schön" in der Gesamtheit von Design, Useability und Leistung.

So jetzt warte ich auf die "offtopic", "Troll", "Contest wer am meisten schreibt" Flames!!
 
Frage: Inwiefern ist der Entwickler eingeschränkt?
Auch am gp2x wars so: Alles, was benötigt wird, ist ein einem relativen Pfad drin.
So sollte das auch hier sein.

Libraries, etc. (also das Grundsystem) SIND ja festgelegt (die sind ja auch auf dem NAND).
Es geht hier NUR um Programme, die auf der SD-Karte sind. Und die sollten einfach startbar sein, indem man in den Ordner cd'ed und das Programm startet - unabhängig davon, in welchem Unterverzeichnis sie liegen, etc.
Denn im Gegensatz zu anderen Linux-Systemen gibt es im Standard Pandora-OS KEINE Abhängigkeiten. Alle benötigten Libraries sind im Base OS im NAND - und eventuelle weitere Libraries müssen statisch gelinkt werden. Das wars.
WO sich das Programm befindet, ist also vollkommen egal, da es relativ in seinem Pfad arbeitet.

PXML ist ja nicht dafür gedacht, dass Programme wissen, wo sie sind, sondern dass die GUIs automatisch die Programme finden, in Kategorien sortieren und dann eben die Executable starten. MEHR NICHT.

Es soll auch KEIN INDEX auf dem NAND erzeugt werden. Das wäre ja nur unnötige Last - wenn die SD-Karte mal kaputt ist, hat man lauter UUID-Einträge drin, die es nicht mehr gibt. Blödfug.
WENN eine GUI cachen will, dann kann sie das ja auf der SD-Karte machen (und für die Karten ist der Mount-Pfad ja auch systemweit vorgegeben).

Insofern wüßte ich nicht, was mir die UUID-Einträge oder die Pfade bringen sollen, vor allem nicht, was mir diese im PXML-Format bringen sollen.

Der Sinn des PXML-Formates ist ja, dass jeder seine Apps dahin kopieren kann, wo ER sie möchte. Ich will ja genau NICHT Pfad-Vorgaben machen.
 
Frage: Inwiefern ist der Entwickler eingeschränkt?
Enwtickler, die in ihren apps andere Apps referenzieren wollen. Dazu braucht es die Info was für Apps "per PXML installiert" sind.
Aber das Ursprüngliche Problem war die Suche nach Apps auf der SD. Bei nem 4GB SD mit paar Foldern ok, aber bei nem 32gb oder mehr SD mit paar hundert Foldern wärs nicht so toll, wenn Apps jeweils alle Verzeichnisse durchsuchen. Wenns nur die GUI macht weniger das Problem (dies ist ja der Punkt wo ich zweifle).
Libraries, etc. (also das Grundsystem) SIND ja festgelegt (die sind ja auch auf dem NAND).
Es geht nicht um zum Starten benötigte Libs, sondern um Apps, die für eine Tätigkeit (siehe frühere Beispiele) wissen wollen was für apps auf der SD "installiert" sind.
PXML ist ja nicht dafür gedacht, dass Programme wissen, wo sie sind, sondern dass die GUIs automatisch die Programme finden, in Kategorien sortieren und dann eben die Executable starten. MEHR NICHT.
Wenn dabei das "GUI" und nur das GUI als Verwendungszweck für die PXML fixiert wird, und ihr solche von mir vorgeschlagenen Apps ignoriert, klar.
Es soll auch KEIN INDEX auf dem NAND erzeugt werden. ...WENN eine GUI cachen will, dann kann sie das ja auf der SD-Karte machen (und für die Karten ist der Mount-Pfad ja auch systemweit vorgegeben).
So wars auch gemeint, wie schon früher im Thread durchdiskutiert. Und es ging nur darum diesen Cache(Index) pro SD für andere Programme zugänglich zu machen.
Insofern wüßte ich nicht, was mir die UUID-Einträge oder die Pfade bringen sollen, vor allem nicht, was mir diese im PXML-Format bringen sollen. Der Sinn des PXML-Formates ist ja, dass jeder seine Apps dahin kopieren kann, wo ER sie möchte. Ich will ja genau NICHT Pfad-Vorgaben machen.
UUID -> eindeutig referenzierbar (falls meine Vorschläge zu solchen Apps nicht eh grad ignoriert werden). Fixe Pfade in PXML?? Wo wurde denn das geschrieben?
Pfadvorgaben war nur ein Vorschlag zur Einschränkung des Suchraums. Dann bin ich ja mal gespannt, wenn ich dann einst eine 32gb SD mit meinem ganzen EMU-Archiv mit hunderten von Foldern einlege und das GUI mit Suchen loslegt...
Zum Glück ist ja der Source frei, dann kann ichs dann immerhin selber hinbiegen.
 
EvilDragon said:
Insofern wüßte ich nicht, was mir die UUID-Einträge oder die Pfade bringen sollen, vor allem nicht, was mir diese im PXML-Format bringen sollen.
Die UUID-Einträge kann die GUI dazu verwenden eine Anwendung eindeutig zu identifizieren. Z.B. könnte die GUI, falls mehrere Versionen von ein und dem selben Programm vorhanden sind (sogar dann wenn sich der Name des Programms in irgendeiner Weise ändert), erkennen, dass es sich um verschiedene Versionen des selben Programms handelt und entweder nur die neuste anzeigen, oder die Versionen gruppiert darstellen. Oder eventuell sogar vorschlagen, die alten Versionen zu entfernen.
Pfade im PXML-File zu speichern, wurde hier im Thread ja von niemandem vorgeschlagen. Das wäre in der Tat ziemlich sinnlos.
Das Speichern von Pfaden wurde nur im Kontext der Indexdateien diskutiert. Dort ging es ja darum die PXML-Files ggf. schneller zu finden, in dem der Index durchsucht wird, statt das Dateisystem erneut zu durchsuchen.
Der Sinn des PXML-Formates ist ja, dass jeder seine Apps dahin kopieren kann, wo ER sie möchte. Ich will ja genau NICHT Pfad-Vorgaben machen.
Das ist klar, deswegen hatte ich ja auch vorgeschlagen, dass der Benutzer in der GUI (optional) einen Pfad einstellen kann, in dem nach Programmen gesucht werden soll. Wenn man sehr viele Dateien auf der Karte hat, kann der Suchvorgang ansonsten nämlich unnötig zeitaufwändig werden.
 
Vielleicht versteht ED die PXML Installations Variante als "Ausnahme" um einige Apps für weniger versierte Nutzer bzw. für versierte um das NAND nicht zu belasten bzw. um schnell und bequem etwas auszutesten. Die Apps sind dann einfach nur per GUI gestartete einfache Apps wie Emus, Games. Während z.B. ein mp3-player eher in die Distribution reinkommt. Für mein Beispiel mit der "Wecker-App", die eine gewünschte App zur gewünschten Zeit startet, sollten eher nur solche im NAND fix installierten Apps als Ziele dienen. Die PXML installierten sollen "eigenständig" sein.
Irgendwie sagt mir meine Erfahrung, dass immer wenn eine "Variante" nur für andere Anwendungszwecke besteht, diese dann immer von jemand auch missbräuchlich genutzt wird. :wink:

Mir bleibt dann immer noch das Argument, dass so gestartete Programme ermutigt werden das GUI abzuschiessen und das danach neu startende GUI wieder alles Suchen muss, wenn es keinen persistenten Cache/Index hat. Und hier wärs ein leichtes dieses Indexformat vorzugeben. Das sollte niemanden "belasten", aber für den Fall der Fälle hat man später noch etwas, worauf man zurückgreifen kann.
übrigens, wenn jemand ein alternatives GUI programmiert, wie können die startenden Apps dann entscheiden welche App das abzuschiessende GUI ist?

Vielleicht vergesse ich aber auch, dass Flash Zugriffzeiten unterhalb der von heutigen magnetischen Festplatten liegen und daher die Suche doch auch auf grossen SDs mit vielen Unterverzeichnissen massiv schneller ablaufen könnte als meine "innere Cassandra" befürchtet. ^_^
 
PandoraSuechtig said:
Mir bleibt dann immer noch das Argument, dass so gestartete Programme ermutigt werden das GUI abzuschiessen und das danach neu startende GUI wieder alles Suchen muss, wenn es keinen persistenten Cache/Index hat. Und hier wärs ein leichtes dieses Indexformat vorzugeben. Das sollte niemanden "belasten", aber für den Fall der Fälle hat man später noch etwas, worauf man zurückgreifen kann.
übrigens, wenn jemand ein alternatives GUI programmiert, wie können die startenden Apps dann entscheiden welche App das abzuschiessende GUI ist?
Ich denke es wird eher so laufen, dass sich die GUI beim Start einer Anwendung selbst beendet und anschließend wieder neu startet. Die gestartete Anwendung müsste dann gar keine Informationen darüber haben, welche GUI jetzt verwendet wird. Das ließe sich z.B. sehr einfach mit einem Wrapper-Script erledigen.
 
Frage an ED: Wenn vom SD gebootet wird, durchsucht der Code dann trotzdem die SD-Karte nach PXML Dateien? Oder technisch formuliert: überspringt er das root-medium? Durchsucht er nur die /mount/sd1/ und /mount/sd2/ oder die dateisysteme auf den /dev/sd1/ und /dev/sd2 devices?
 
PandoraSuechtig said:
Frage an ED: Wenn vom SD gebootet wird, durchsucht der Code dann trotzdem die SD-Karte nach PXML Dateien? Oder technisch formuliert: überspringt er das root-medium? Durchsucht er nur die /mount/sd1/ und /mount/sd2/ oder die dateisysteme auf den /dev/sd1/ und /dev/sd2 devices?

Das kommt doch ganz auf Dein Betriebssystem auf der SD-Karte an ;)
 
Nunja, denke du weisst schon was ich meine. Das GUI der Pandora (nach langem Knatsch konnt ich ja niemand überzeugend, dass die PXML Suche nicht unbedingt im GUI drin sein sollte) und das entwickelst du mit?
Aber meine Frage war ja auch mehr ein "hast du auch berücksichtigst dass...", was hab ich da schon für eine Antwort erwartet :p
 
Back
Top