staging.inyokaproject.org

Auf Wunsch hier auch noch einmal meine Bedenken gegen eine zu starke Integration von unfreier Software:

Eine Vermischung von open- und closed source birgt meiner Meinung nach die Gefahr, dass eine Konkurrenzsituation entsteht; dass sich Leute fragen, warum jemand mit Programmen Geld verdient, wo sie selbst für vielleicht mehr Arbeit keins bekommen. Der Grundgedanke des gemeinsamen Produktes, welches für alle völlig frei zur Verfügung steht, könnte unterhöhlt werden.

Ich denke man sollte genau überlegen inwieweit kommerzielle Produkte Einzug halten sollen. Ich habe nichts gegen eine einfache nachträgliche Installation von kommerziellen Programmen. Allerdings sollte man strenge Grenzen ziehen im Einfluss solcher Unternehmen auf die gesamte open source Idee. Da gab es beispielsweise die Idee vom "Freikaufen" bestimmter Software oder der direkten kommerziellen Produktion für die potenziellen (Linux-)Kunden. (ich kann die Stellen nicht mehr finden, vielleicht wurde das auch zurückgenommen) In der Beschreibung des Konzepts (http://linux-appstore.de/PAPPI-und-der-AppStore-f%C3%BCr-Linux.pdf) ist beispielsweise auch von finanziellen Interessen des App Store Betreibers die Rede.

Die grundlegende Frage entsteht dabei bei mir: Was haben solche Interessen und Firmen mit dem open source Grundgedanken zu tun? Wenn man nicht gemeinsam für alle arbeiten will, kann man doch gleich für Microsoft programmieren. Wenn Linuxbenutzer zu einem neuen Markt werden sollen, dann wird indirekt mit dem gemeinschaftlich Erarbeitetem von Wenigen profitiert und nichts zurückgegeben.

Das sind nur meine spontanen Gedanken, die bei der Einbeziehung der kommerziellen Firmen selbst aufkamen. Ich habe im Moment gerade keine Zeit das wirklich grundlegend zu durchdenken. Aber das ist sicher hier irgendwo schon einmal genauer diskutiert worden.

Zu den Bedenken, ein App Store mit einem großen Angebot an proprietärer Software könnte die Freie Software und das dahinter steckende Ideal bedrohen:

Vorwort

Freie Software bedeutet nicht zwangsläufig kostenlos. Gerade Unternehmensumfeld viel Geld für Bereitstellung, Integration und Pflege Freier Software viel Geld ausgegeben. Freie Open Source Software (FOSS) gibt dem Nutzer vor allem Freiheit. Diese Freiheit ist nicht allein an die Technik gebunden (studieren und erweitern der Funktion) oder auf die Distribution bezogen, sondern hat auch eine ganz Konkrete wirtschaftliche Bedeutung. Der Nutzer kann sich aussuchen, wem er Geld und wie viel er für FOSS bezahlt. Somit ist er, obwohl er an ein Produkt gebunden ist, völlig unabhängig (frei) von einem bestimmten Anbieter.

Das Prinzip der FOSS funktioniert, weil alle beteiligten von der Fortentwicklung und dem Nutzen Freier Software profitieren. Allerdings gibt es auch Bereiche in denen dieser Motor der Freien Software keinen großen Antrieb bewirkt. Im besonderen Maße ist hier die Spielindustrie betroffen. Ein Spiel ist nur für einen begrenzten Zeitraum interessant (z.B. bis es Durchgespielt ist). Ein Modell, das Einnahmen durch eine langfristige Bereitstellung, Pflege oder gar Integration eines solchen Produkts generiert, kann hier nicht angewendet werden. Die einzige Möglichkeit ein vernünftiges Verhältnis von Einnahmen und Kosten, der Herstellung eines Spiels ist Lizenzen zu verkaufen oder das Spiel im Rahmen eines kostenpflichtigen Dienstes anzubieten.

Sicher gibt es auch im Bereich der Spiele Open Source Projekte. Diese "finanzieren" sich jedoch hauptsächlich aus dem freiwilligen und kostenlosen Engagement weniger Entwickler.

Das Open Source Modell greift also im besonderen Maße bei Software mit langfristigem produktiven Nutzwert. Hier ist es meiner Meinung nach aus Kundensicht jedem anderen Geschäftsmodell überlegen.

Bedarf der Nutzer

Computer Nutzer haben mehrere Arten von Bedürfnissen.

Der Computer dient als Arbeitsgerät. Hiermit erschaffen Sie eigene Erzeugnisse (Texte, Bilder, Filme, Präsentation usw.). Dadurch begeben sie sich (mehr oder minder stark) in eine Abhängigkeit von der Software, die sie bei der Erstellung Ihrer Arbeiten verwenden. Aus den oben genannten Gründen spielt an dieser Stelle Open Source Software ihre Vorteile aus.

Der Computer wird zur Kommunikation genutzt. Die Offenheit und die uneingeschränkte Möglichkeit Open Source Software zu verbreiten, hat auch hier der Nutzer einen großen Vorteil durch FOSS.

Der Computer dient zur Unterhaltung. Unterhaltung ist kurzweilig (zumindest im Verhältnis zu Aufgaben wie Buchführung, Dokumentenarchivierung oder dem Schreiben eines Buches). Eine Abhängigkeit zu einem Unterhaltungsangebot kann nicht entstehen (; eine Sucht mal außen vor gelassen). Somit hat Open Surce hier keine Vorteile für den Benutzer, so lange er sich nicht aktiv an der Gestaltung eines Unterhaltungsprogramms beteiligen möchte. Das wäre aber wieder Arbeit und keine Unterhaltung, auch wenn die Arbeit Spaß macht.

Der Computer dient zur Lösung einer akuten (kurzfristigen) Aufgabe. Im geschäftlichen Umfeld werden solche Aufgaben gerne an Dienstleister gegeben. Im Privatbereich bieten sich oft bestimmte Programme an. Beispiele wären, die Digitalisierung der privaten VHS-Videothek, der Druck eines Fotobusches als einmaliges individuelles Geschenk oder das erlernen einer Fremdsprache. Bei diesen Anwendungen kann Open source gegenüber dem Nutzer keine Vorteile ausspielen. Sobald die Aufgabe erledigt ist, wird das Programm irrelevant.

Friedliche Koexistenz

Der Sinn der Linux App Store, ist das beste aus der Konsumwelt, auf eine freie Plattform zu holen. Ein proprietäres Vertriebsmodell bringt bei einer Reihe von Anwendungen große Vorteile für den Hersteller aber keine relevanten Einschränkungen für den Nutzer. Diese Programme sollen den Nutzern einer freien Plattform genauso umgänglich zur Verfügung stehen, wie den Nutzern proprietärer Plattformen.

Förderlich für Open Source

Bisher nutzt nur ein geringer Anteil der Bevölkerung bewusst Linux oder eine andere Offene Plattform. Einer der Gründe ist das geringe Konsumangebot im Verhältnis zu etablierten proprietären Plattformen. Eine Mehrheit von Menschen kommt mit dem Open Source Gedanken also gar nicht in Berührung und kann die Vorteile einer offenen Plattform auch nicht erleben. Bietet man diesen Menschen die Konsummöglichkeiten, die sie schätzen, auf einer Offenen Plattform, schafft man einen Anreiz diese Plattform zu nutzen und gibt Ihnen die Möglichkeit deren Vorzüge zu erleben.

Keine Gefahr für Open Sorce

Open Source und proprietäre Geschäftsmodelle existieren seit es Open Source Lizenzen gibt nebeneinander und immer schon haben letztere die Welt dominiert. Trotzdem konnte Open Source seit je her ein kontinuierliches Wachstum verbuchen. Es gibt also keinen Grund, warum plötzlich Entwickler, die bereits von FOSS überzeugt sind, proprietäre Software schreiben sollten. Keinem dieser Entwickler wird entgangen sein, das andere für die lizenzierte Nutzungserlaubnis ihrer Software Geld verlangen.

Den Appstore werd ich weiter mal verfolgen. Ob ich es jemals nutzen werde, weiß ich nicht, da mir das Software-Center eigentlich reicht.

Ich habe von dem Projekt vor ein paar Tagen bei Golem gelesen... Ich weiß ehrlich noch nicht, was ich davon halten soll.

Ich sehe folgende Probleme:

1. Sagen wir, es gibt ein PAPPI-Paket, welches auf libpng in Version 12 gelinkt wurde, und ein anderes, welches schon auf Version 14 referenziert. Sollten für beide Pakete die jeweiligen Versionen installiert werden, enden wir bald wie in der Windows-Welt: Weder System, noch Nutzer haben einen blassen Schimmer davon, welche Version der Lib wo liegt - Chaos. Selbst, wenn das alles noch funktioniert, haben wir einen gigantischen Haufen von redundant installierten Bibliotheken.

2. Verschiedene Distributionen haben unterschiedliche Release-Abläufe. Besonders durch die Mischung von Rolling-Release-Distributionen und "klassischen" Release-Verfahren ist es sehr schwer, eine gemeinsame Basis zu garantieren. Und irgendwie müssen ja auch die Abhängigkeiten (wie Emulatoren) auf das System kommen.

3. Die distributionseigenen Update-Mechanismen werden ausgehebelt. So bleibt veraltete Software auf dem Rechner, der Nutzer wundert sich, warum seine Spiele nicht auf dem neusen Stand sind.

4. PAPPI-Pakete unterliegen ja keinen besonderen Sicherheitsauflagen. Im Gegenteil. Sie bieten eine Möglichkeit, an den Sicherheitspatches der Distributionen vorbei auf einem System herumzupfuschen und Löchlein zu graben.

5. Nutzer werden dazu eingeladen, Programme zu installieren, ohne groß nachzudenken, was sie eigentlich machen. Die Passworteingabe bisher gibt schon ein Signal: "Pass auf, was du hier machst. Überlege es dir genau!"

6. Die meisten Distributionen wenden für ihre Pakete eigene Patches an, um die Programme zu ihren Richtlinien kompatibel zu gestalten. Das wird über PAPPI nicht möglich sein.

Rechtesystem, Paketmanager und co. sind (meiner Meinung nach) die wichtigsten Teile einer Linux-Distribution. Sie bieten Sicherheit, Zuverlässigkeit und an die Distribution angepasste Services. Dummerweise werden genau diese Punkte mit PAPPI ausgehebelt.

Ansonsten finde ich den Appstore-Aspekt nicht schlecht. Besonders für emulierte Software (Wine, GameBoy-Spiele, etc.) ist es interessant, weil diese "Applikationen" eher den Aspekt von "Daten" und nicht von "Programmcode" haben. Windows-Programme werden ja auch im Home-Ordner installiert (EDIT (war unklar?): für Wine). Auch für Desktop-Widgets (Screenlets, etc.) finde ich das Konzept nicht schlecht - und arbeite für Cream auch daran.

Aber für "richtige" Programme ist ein Appstore eher kontraproduktiv (subjektiv!)...

Ich hoffe, der Beitrag klingt nicht zu destruktiv... Ich habe einfach mal die Gedanken aufgeschrieben, welche mir in den Kopf gekommen sind... Eventuell hilft es dir ja bei der weiteren "Konzeptuierung" von PAPPI;)

Liebe Grüße und viel Spaß bei der Entwicklung,
Sebastian

Ein Stein schrieb:

Aber für "richtige" Programme ist ein Appstore eher kontraproduktiv (subjektiv!)...

So wie ich es verstanden habe, ist es dafür auch nicht ausgerichtet. Für "richtige" Programme soll weiterhin die Paketverwaltung zuständig sein.

JaiBee schrieb:

Ein Stein schrieb:

Aber für "richtige" Programme ist ein Appstore eher kontraproduktiv (subjektiv!)...

So wie ich es verstanden habe, ist es dafür auch nicht ausgerichtet. Für "richtige" Programme soll weiterhin die Paketverwaltung zuständig sein.

Ich habe auch gelesen, dass es für "richtige Programme" im Sinn von Server-Applikationen nicht gedacht ist. Aber ich würde auch Foto-Programme (wie im Beispiel-Video) darunter sehen.

Ich würde die Grenze da ziehen, wo Programme auf Abhängigkeiten setzen, die nicht durch sie selbst oder den Emulator/die Sandbox zur Verfügung gestellt werden.

Ach, ich wäre auch eventuell (sollten sich meine "Fragen" klären) gerne bereit, bei einer Implementation von PAPPI in einer "richtigen" Sprache zu helfen. Ggf. melde ich mich dann nochmal!

Liebe Grüße,
Sebastian

1. Sagen wir, es gibt ein PAPPI-Paket, welches auf libpng in Version 12 gelinkt wurde, und ein anderes, welches schon auf Version 14 referenziert. Sollten für beide Pakete die jeweiligen Versionen installiert werden, enden wir bald wie in der Windows-Welt: Weder System, noch Nutzer haben einen blassen Schimmer davon, welche Version der Lib wo liegt - Chaos. Selbst, wenn das alles noch funktioniert, haben wir einen gigantischen Haufen von redundant installierten Bibliotheken.

Das ist richtig. PAPPI soll auch nicht die Paketverwaltung ersetzten oder mit Ihr konkurrieren. Es ist nicht schlimm, wenn eine Lib oder was auch immer öfter in verschiedenen Versionen vorhanden ist. Die meisten Programme (für PAPPI) sind ja proprietär, was dann oft auch für die Libs gilt. So verhindert schon die Lizenzpolitik, dass die Programme Teile gemeinsam nutzen. Viele Apps bleiben auch nicht lange auf dem PC des Nutzers. Sie sollen sofortigen "Nutzen" bringen, keinen Langfristigen.

2. Verschiedene Distributionen haben unterschiedliche Release-Abläufe. Besonders durch die Mischung von Rolling-Release-Distributionen und "klassischen" Release-Verfahren ist es sehr schwer, eine gemeinsame Basis zu garantieren. Und irgendwie müssen ja auch die Abhängigkeiten (wie Emulatoren) auf das System kommen.

3. Die distributionseigenen Update-Mechanismen werden ausgehebelt. So bleibt veraltete Software auf dem Rechner, der Nutzer wundert sich, warum seine Spiele nicht auf dem neusen Stand sind.

Es gibt keinen neuesten Stand. Es gibt nur einen Stand. Sollte das Spiel, oder das Programm tatsächlich Updates bekommen, muss es sich selbst darum kümmern. Es ist aber durchaus möglich hier einen Update-Mechanismus bereit zu stellen, den die Paketbauer verwenden können.

4. PAPPI-Pakete unterliegen ja keinen besonderen Sicherheitsauflagen. Im Gegenteil. Sie bieten eine Möglichkeit, an den Sicherheitspatches der Distributionen vorbei auf einem System herumzupfuschen und Löchlein zu graben.

Die Sicherheit wird durch folgende Maßnahmen gewährleistet:

• Die Installation wird für nur einen Benutzer durchgeführt und greift nicht ins allgemeine System ein. (Eine Installationssperre für Root kann man noch einbauen.)

• Bei der Installation wird kein Programm bzw. Skript, aus dem Paket ausgeführt. Es kann also ein gefährliches Programm erst dann Schaden anrichten, wenn es gestartet wird. Die Installation selbst, kann keinen Schaden anrichten.

• In der finalen Version sollen die Pakete von einem Vertrauenswürdigen dritten (Betreiber des jeweiligen App Stores) signiert werden, nachdem diese auf Unbedenklichkeit überprüft wurden. Nur entsprechend signierte Pakete werden dann installiert.

5. Nutzer werden dazu eingeladen, Programme zu installieren, ohne groß nachzudenken, was sie eigentlich machen. Die Passworteingabe bisher gibt schon ein Signal: "Pass auf, was du hier machst. Überlege es dir genau!"

Richtig. Sie verändern aber auch nichts am allgemeinen System, sondern nur an ihren persönlichen Daten. (siehe oben, zu Sicherheit)

6. Die meisten Distributionen wenden für ihre Pakete eigene Patches an, um die Programme zu ihren Richtlinien kompatibel zu gestalten. Das wird über PAPPI nicht möglich sein.

Anpassungen sind im gewissen Rahmen möglich, sollen sich aber auf ein Minimum beschränken. Hier gilt es vor allem darum einige Einstellungen und Parameter zu den verwendeten Eingabegeräten und der Anzeige zu setzen. (Tastatur oder Joystick / Fenster oder Vollbild / Auflösung / usw.)

Rechtesystem, Paketmanager und co. sind (meiner Meinung nach) die wichtigsten Teile einer Linux-Distribution. Sie bieten Sicherheit, Zuverlässigkeit und an die Distribution angepasste Services. Dummerweise werden genau diese Punkte mit PAPPI ausgehebelt.

Sie werden ergänzt. Alles was der Paketmanager besser verarbeiten kann, werden wir an diesen verweisen. Wir wollen auf keinen Fall, die gleiche Software anbieten, die es schon für die Distribution gibt.

Ansonsten finde ich den Appstore-Aspekt nicht schlecht. Besonders für emulierte Software (Wine, GameBoy-Spiele, etc.) ist es interessant, weil diese "Applikationen" eher den Aspekt von "Daten" und nicht von "Programmcode" haben. Windows-Programme werden ja auch im Home-Ordner installiert (EDIT (war unklar?): für Wine). Auch für Desktop-Widgets (Screenlets, etc.) finde ich das Konzept nicht schlecht - und arbeite für Cream auch daran.

Aber für "richtige" Programme ist ein Appstore eher kontraproduktiv (subjektiv!)...

Der App Store ist nicht für langfristig produktiv genutzte Software gedacht. Die werden mit den Mittel der Distributionen bereits hervorragend behandelt.

Ich hoffe, der Beitrag klingt nicht zu destruktiv... Ich habe einfach mal die Gedanken aufgeschrieben, welche mir in den Kopf gekommen sind... Eventuell hilft es dir ja bei der weiteren "Konzeptuierung" von PAPPI;)

Ein wesentlicher Grund für die frühe Veröffentlichung des Konzepts, ist meine Überzeugung, dass es lange dauern wird und viel Erklärung bedarf, bis das Konzept in der Linux-Gemeinde "angekommen" ist. Ich habe also mit solchen Fragen und viel Kritik von Anfang an gerechnet. 😉

Hallo chris109,

vielen Dank für deine ausführliche Antwort!

chris109 schrieb:

Wir wollen auf keinen Fall, die gleiche Software anbieten, die es schon für die Distribution gibt.

Der App Store ist nicht für langfristig produktiv genutzte Software gedacht. Die werden mit den Mittel der Distributionen bereits hervorragend behandelt.

Diese beiden Aussagen machen mich vollends glücklich! Ich habe nur ein Problem in eventuellen Überschneidungen von Appstore und Paketmanager gesehen. Wie bereits gesagt stehe ich dem Appstore-Konzept aufgeschlossen gegenüber.

Mein Angebot, bei der Entwicklung zu helfen, besteht immer noch. Solltest du Unterstützung brauchen, melde dich einfach;)

Liebe Grüße,
Sebastian

Was muss ich tun wenn ich Sonic nicht mit dem Lenkred spielen will?

Hat es nur ein Packet oder find ich einfach kein weiteres?

Sonst funktioniert es unter Linux Mint 8, aber ich möchte ja nicht immer das Lenkrad ein und ausstecken ☺

In deinem persönlichen Ordner sollte die Datei .PersonalAppPreferences zu finden sein.

# Preferences for Personal Applications
PAP_ENABLE_SOUND="yes"
# "yes"|"no"
PAP_ENABLE_MUSIC="yes"
# "yes"|"no"
PAP_DISPLAY_MODE="window"
# "window" | "fullscreen"
PAP_KEYBOARD="with_num_pad"
# "with_num_pad"|"without_num_pad"
PAP_USE_JOYSTIKS="auto"
# "none"|"one"|"two"|"auto"

Dort kannst Du die Verwendung des Joysticks grundsätzlich unterbinden. Die ganze Konfiguration wird im Verlauf der Entwicklung aber noch kräftig überarbeitet. Diese Informationen können also bald veraltet sein.

Hallo,

erstmal vorweg: Das Konzept find ich gut; das dürfte sicherlich ne Verbesserung gegenüber den gepackten Archiven oder den ganzen Variationen von anderen Installern sein. Allerdings: es gibt ja schon einige ähnliche Sachen - irgendwer hat Klik und 0install erwähnt - du bräuchtest früher oder später irgendeinen einflussreichen Unterstützer (Canonical?), damit das Ganze überhaupt jemals eine kritische Masse erreicht.

Ansonsten hätt ich noch ein paar eher technische Vorschläge dazu:

• Das Paketformat ist zwar simpel, aber ich bezweifle, dass es sonderlich flexibel oder einfach erweiterbar ist. Anstatt diese 3 Dateien in dem Archiv würde ich nur eine vorgeben, nennen wir sie "metadata.ini", in irgendeinem einfachen Format mit Schlüssel-Werte-Zuordnungen. Ein paar mögliche Felder für diese Datei könnten dann sein:

  • Version des Paketformats - *falls* man dann das Paketformat mal so ändern müsste, dass alte Pakete nicht mehr funktionieren, dann könnte das Clientprogramm einfach erkennen, wie es das Paket behandeln muss

  • Name der Anwendung, Beschreibung, Versionsnummer etc., sowas halt

  • Pfad zur Icon-Datei, relativ zur Wurzel des Pakets

  • Befehl zum Starten des Programms

Die Verknüpfung würde dann aus diesen Information vollständig generiert und nicht mitgeliefert.

• Ich fände es sinnvoll, das ganze Prinzip ... nun, plattformunabhängig zu machen. Ein Paket würde dann wissen, für welche Plattform es geeignet ist (eine Plattform ist dabei ne Kombination aus Betriebssystem und Prozessorarchitektur, also bspw. "linux-x86" oder so). Das Installerprogramm müsste dann wissen, welche Plattformen es unterstützt, aber wenn du auch nur Linux abseits von Desktopdistris unterstützen willst, bräuchtest du sowas, schließlich werden die kaum nen x86-Prozessor haben. Außerdem könnte man dann das gleiche Paketformat und die gleiche Infrastruktur für *BSD, Solaris oder - oh Schreck - Windows benutzen. Vllt. ist das aber auch nur mein Hang, solche Sachen allzu allgemein zu entwerfen.

• Irgendeine Form von Abhängigkeitsverwaltung: nicht Abhängigkeiten zwischen Paketen, sondern Abhängigkeiten von anderer, externer Software, die relativ verbreitet ist und/oder sich schlecht mit der Anwendung zusammenpacken lässt. Als Beispiel mal ... "gtk". Programme, die angeben, von "gtk" abzuhängen, könnten sich beispielsweise darauf verlassen, dass sie Gtk in mindestens irgendeiner bestimmten Version kriegen. Deine jetzige harte Abhängigkeit auf Wine und UAE könnte man auch damit modellieren; ein Amiga-Programm würde dann eine Abhängigkeit auf "uae" oder so festlegen. Das Installerprogramm würde sich dann darum kümmern, dass diese Abhängigkeiten erfüllt sind, wenn es ein Paket installiert - dann wohl mit plattform- und distributionsspezifischer Magie.

Von diesen Abhängigkeiten sollte es natürlich nur sehr wenige geben, damit das nicht völlig chaotisch wird, schließlich muss jede dieser Abhängigkeiten für jede unterstützte Plattform irgendwie definiert sein.

• Eine Idee eher am Rande: man könnte diesen Appstore irgendwie in das Ubuntu-Software-Center integrieren. Könnte ein langfristiger Plan sein; aber Integration in Ubuntu würde wahrscheinlich die Akzeptanz und Verbreitung gut verbessern.

So, das wars erstmal. Ich habe mir übrigens nur kurz das Paketformat angeguckt, nicht deine ganzen Konzepte oder so im Detail durchgelesen, kann also sein, dass du das ganze Zeugs schon so geplant hast.

Gruß,
Felix

Hallo Felix!

Danke für Deine Anregungen.

erstmal vorweg: Das Konzept find ich gut; das dürfte sicherlich ne Verbesserung gegenüber den gepackten Archiven oder den ganzen Variationen von anderen Installern sein. Allerdings: es gibt ja schon einige ähnliche Sachen - irgendwer hat Klik und 0install erwähnt - du bräuchtest früher oder später irgendeinen einflussreichen Unterstützer (Canonical?), damit das Ganze überhaupt jemals eine kritische Masse erreicht.

Auf die Dauer sind sicherlich prominente Unterstützer notwendig. Das ist ein Grund für die frühe Veröffentlichung. Das Konzept muss möglichst vielen bekannt sein, damit auch die "richtigen Leute" damit vertraut werden.

Ansonsten hätt ich noch ein paar eher technische Vorschläge dazu:

• Das Paketformat ist zwar simpel, aber ich bezweifle, dass es sonderlich flexibel oder einfach erweiterbar ist. Anstatt diese 3 Dateien in dem Archiv würde ich nur eine vorgeben, nennen wir sie "metadata.ini", in irgendeinem einfachen Format mit Schlüssel-Werte-Zuordnungen. Ein paar mögliche Felder für diese Datei könnten dann sein:

Das Paketformat ist bisher nicht final und es wird sicherlich noch Änderungen geben.

• Version des Paketformats - *falls* man dann das Paketformat mal so ändern müsste, dass alte Pakete nicht mehr funktionieren, dann könnte das Clientprogramm einfach erkennen, wie es das Paket behandeln muss

• Name der Anwendung, Beschreibung, Versionsnummer etc., sowas halt

• Pfad zur Icon-Datei, relativ zur Wurzel des Pakets

• Befehl zum Starten des Programms

Die Verknüpfung würde dann aus diesen Information vollständig generiert und nicht mitgeliefert.

• Ich fände es sinnvoll, das ganze Prinzip ... nun, plattformunabhängig zu machen. Ein Paket würde dann wissen, für welche Plattform es geeignet ist (eine Plattform ist dabei ne Kombination aus Betriebssystem und Prozessorarchitektur, also bspw. "linux-x86" oder so). Das Installerprogramm müsste dann wissen, welche Plattformen es unterstützt, aber wenn du auch nur Linux abseits von Desktopdistris unterstützen willst, bräuchtest du sowas, schließlich werden die kaum nen x86-Prozessor haben. Außerdem könnte man dann das gleiche Paketformat und die gleiche Infrastruktur für *BSD, Solaris oder - oh Schreck - Windows benutzen. Vllt. ist das aber auch nur mein Hang, solche Sachen allzu allgemein zu entwerfen.

Es wird Systemanforderungen geben und auch einen Weg, zu prüfen, ob diese vom eigenen System erfüllt werden. Nachdem jedoch viele der Pakete gekauft werden, ist es wenig sinnvoll das in das Paket selbst zu integrieren. Das bekommt man ja erst, wenn man es schon gekauft hat und man sollte vorher wissen, ob man es überhaupt nutzen kann.

• Irgendeine Form von Abhängigkeitsverwaltung: nicht Abhängigkeiten zwischen Paketen, sondern Abhängigkeiten von anderer, externer Software, die relativ verbreitet ist und/oder sich schlecht mit der Anwendung zusammenpacken lässt. Als Beispiel mal ... "gtk". Programme, die angeben, von "gtk" abzuhängen, könnten sich beispielsweise darauf verlassen, dass sie Gtk in mindestens irgendeiner bestimmten Version kriegen. Deine jetzige harte Abhängigkeit auf Wine und UAE könnte man auch damit modellieren; ein Amiga-Programm würde dann eine Abhängigkeit auf "uae" oder so festlegen. Das Installerprogramm würde sich dann darum kümmern, dass diese Abhängigkeiten erfüllt sind, wenn es ein Paket installiert - dann wohl mit plattform- und distributionsspezifischer Magie.

Von diesen Abhängigkeiten sollte es natürlich nur sehr wenige geben, damit das nicht völlig chaotisch wird, schließlich muss jede dieser Abhängigkeiten für jede unterstützte Plattform irgendwie definiert sein.

Es wird keine Abhängigkeiten geben, sondern nur Systemanforderungen. Wer PAPPI auf seinem System installiert, erhält damit eine definierte Umgebung.

• Eine Idee eher am Rande: man könnte diesen Appstore irgendwie in das Ubuntu-Software-Center integrieren. Könnte ein langfristiger Plan sein; aber Integration in Ubuntu würde wahrscheinlich die Akzeptanz und Verbreitung gut verbessern.

Das Software-Center und PAPPI verfolgen völlig unterschiedliche Ansätze. Ich persönlich halte es für einen der größten Vorteile des "App Store"-Konzepts, dass es sich aus der Paketverwaltung der Distributionen völlig heraushält.

So, das wars erstmal. Ich habe mir übrigens nur kurz das Paketformat angeguckt, nicht deine ganzen Konzepte oder so im Detail durchgelesen, kann also sein, dass du das ganze Zeugs schon so geplant hast.

Wenn Dich die Sache interessiert, probiere es ruhig mal aus und schau Dir ein bisschen den Code an. Bisher ist er noch sehr leicht zu durchschauen.

chris109 schrieb:

Das Paketformat ist bisher nicht final und es wird sicherlich noch Änderungen geben.

Gut 😉

Es wird Systemanforderungen geben und auch einen Weg, zu prüfen, ob diese vom eigenen System erfüllt werden. Nachdem jedoch viele der Pakete gekauft werden, ist es wenig sinnvoll das in das Paket selbst zu integrieren. Das bekommt man ja erst, wenn man es schon gekauft hat und man sollte vorher wissen, ob man es überhaupt nutzen kann.

Dann müsste man aber, bspw. wenn man das in den App-Store lädt, irgendwelche Anforderungen extra eintragen - dann hätte man die Metadaten *über* das Paket getrennt vom Paket selbst. Das finde ich wiederum wenig sinnvoll; wäre es nicht besser, alle möglichen Informationen auch über Systemanforderungen in das Paket zu packen, in irgendeiner Metadaten-Datei, und die dann automatisch auszulesen, wenn das Paket in den Store kommt?

Nebenbei: Was meinst du mit Systemanforderungen? Hardware: Prozessorgeschwindigkeit, Speicher, Grafikkarte? Prozessortyp?

Es wird keine Abhängigkeiten geben, sondern nur Systemanforderungen. Wer PAPPI auf seinem System installiert, erhält damit eine definierte Umgebung.

Ich muss sagen, ich bin mit meinem Ansatz da auch nicht so ganz glücklich 😕 Ich fände es persönlich psychologisch besser, nicht diverse Sachen vorneweg zu installieren, sondern stattdessen etwas kleinere Brocken, wenn die auch wirklich gebraucht werden ...

Das Software-Center und PAPPI verfolgen völlig unterschiedliche Ansätze. Ich persönlich halte es für einen der größten Vorteile des "App Store"-Konzepts, dass es sich aus der Paketverwaltung der Distributionen völlig heraushält.

Ich meinte nicht, das Ding mit die Paketverwaltung zu integrieren; eher, das Software-Center als Oberfläche zu benutzen, um PA-Pakete (wofür steht eigentlich ".pappp"? "Personal Application Package", und weiter?) zu installieren. Beide installieren ja Software; im Prinzip ist es doch für den Anwender egal, wo die jetzt herkommt.

Sicher braucht man auch ein einfach zu installierendes, distributionsunabhängiges Clientprogramm, aber nichts ist einfacher, als wenn das Programm schon beim System mitgeliefert wird; und warum sollte es 2 Programme geben, um Programme zu installieren? Ergibt aus meiner Sicht keinen Sinn.

Gruß,
Felix

Interessant: Erst verlangen alle eine Trennung von PAPPI und Paketmanagement und jetzt kommt wieder der Vorschlag, alles zu vereinheitlichen... PAPPI mit Abhängigkeiten wäre eine Art zweite Paketverwaltung... Ich weiß nicht, ob das zu den Projektzielen gehört, tippe aber mal stark auf nein.
Vielleicht sollte man echt mal eine Umfrage zu diesem Thema in der internationalen Linuxcommunity machen...

Targion schrieb:

Interessant: Erst verlangen alle eine Trennung von PAPPI und Paketmanagement und jetzt kommt wieder der Vorschlag, alles zu vereinheitlichen...

Was soll das denn jetzt heißen? Ich habe sicher nicht vorgeschlagen, PAPPI und apt zu vereinheitlichen. Ich meine nur, dass man beide Arten der Paketinstallation mit einer einheitlichen Oberfläche machen könnte – eben beispielsweise Ubuntus Software-Center; der Name suggeriert schließlich, das es alle Arten von Software verwaltet (das stimmt natürlich auch nicht), nicht nur Apt-Pakete.

Wie mir gerade klargeworden ist, meinte ich einfach gesagt, die *Bedienung* zu vereinheitlichen, nicht die drunterliegende Technik.

PAPPI mit Abhängigkeiten wäre eine Art zweite Paketverwaltung... Ich weiß nicht, ob das zu den Projektzielen gehört, tippe aber mal stark auf nein.

Naja, streng genommen *ist* es eine Art zweite Paketverwaltung, insofern, als es Pakete verwaltet. Aber das sind nur Spitzfindigkeiten 😉

Ich meinte nicht Abhängigkeiten im Sinne von Debian-Abhängigkeiten, dass ein Paket angibt, welche anderen Pakete es benötigt. Das kann offensichtlich nur bei (fast) völlig zentralisierten Systemen funktionieren – wie eben den Repositories diverser Linux-Distributionen. Aber um mal Chris zu zitieren:

chris109 schrieb:

Es wird keine Abhängigkeiten geben, sondern nur Systemanforderungen. Wer PAPPI auf seinem System installiert, erhält damit eine definierte Umgebung.

Meine Idee war, diese Plattform in eine *sehr* kleine Anzahl von Einzelteilen aufzuteilen. Das PAPPI-Installationsskript zieht momentan Wine, UAE (ein Amiga-Emulator) und Dosbox rein, diese 3 Programme bilden also im Moment diese definierte Umgebung (mehr oder weniger). Anstatt alle diese Sachen mit der Installation des PAPPI-Clients zu installieren, könnten Pakete dann Abhängigkeiten auf "uae", "wine" oder "dosbox" angeben; dann würde das entsprechende Programm nur installiert, wenn ein Programm explizit danach fragt.

Allerdings ... der einzige Vorteil wäre wohl, wenn diese vorgegebene Plattform wächst, dass man nicht immer soviele Sachen installiert haben muss. Dafür müsste dann aber das Clientprogramm in der Lage sein, für jede unterstützte Plattform (bzw. Linux-Distri) zu jeder dieser Plattformkomponenten die richtige Pakete auf die richtige Art zu installieren (oder man würde trotzdem alles bei der Installation der PAPPI-Clientsoftware installieren, dann wärs eh egal). Vermutlich ist dieser kleine Vorteil den zusätzlichen Aufwand nicht wert, das alles zu verwalten.

Vielleicht sollte man echt mal eine Umfrage zu diesem Thema in der internationalen Linuxcommunity machen...

Das ist vermutlich sehr sinnvoll, nicht dass hier irgendetwas entsteht, das dann niemanden interessiert.

Gruß,
Felix