staging.inyokaproject.org

Ach wie freue ich mich das langsam viele neue Spiele, auch für mein Ubuntu/Kubuntu raus kommen, Welche ich dann an den Feiertagen auch meiner Nichte schenken kann. Das konnt' ich nun mit World of Goo ,und QuantZ wird *hoffentlich* zu Weihnachten folgen. Nun sind diese beiden aber wohl richtige Ausnahmen. Denn im Normalfall werden die Spiele nicht für Ubuntu oder sonst eine Distribution gebaut sondern einfach als ein .run oder .bin bereit gestellt. "Kack doch auf die Kunden, die sollen froh sein überhaupt nen Port bekommen zu haben." So ist das wie ich es sehe. Warum stellt denn fast niemand eine DEB und oder RPM Version zu Verfügung? Diese können genauso "Static" sein und ihre Abhängigkeiten mitbringen(Opera macht dies z.B. auch). Aber nein, man bekommt irgendwelche installer die man als Änfängen nicht installiert bekommt und wenn einmal installiert das verschwinden die Daten irgendwo im System so das man den Uninstaller niemals wieder findet(wenn es überhaupt einen gibt).
Daher frage ich mich hier: wieso stellen "wir" uns auf der Plattform Linux immer wieder selbst ein Bein und erfinden das Rad dauernd neu(und schlechter dazu) wenn wir schon gute Wege haben?
Grund für diese negative Aussage hier ist das Spiel "Aquaria".Ich mag es wirklich und würde es mit 100%iger Sicherheit kaufen, wenn es denn eine DEB Version gäbe. Diese Installer, welche an meiner Paketverwaltung vorbei arbeiten will ich wirklich nicht nutzen. Was nun bleibt ist noch das "Warum nur als *.run/*.bin?". Es liegt sich an dem nicht lohnenden Mehraufwand für den Erstellungsvorgang. lohnt nicht? http://2dboy.com/2009/02/12/world-of-goo-linux-version-is-ready/ 😀 scheinbar lohnt sich sowas schon! Aber wie sehr ihr das ganze?

Denkt nun nicht das ich undankbar bin gegenüber den Leuten die das alles portieren. Mir gehts einfach nur darum, dass viele es nicht installieren können und wenn man dafür dann Geld zahlt ist das schon recht böse. (Meine Nichte hat sich mal Neverwinter Nights von mir geliehen und es lag 2 Monate bei ihr, sie hats nie gespielt ^^)

Es liegt sich an dem nicht lohnenden Mehraufwand für den Erstellungsvorgang.

Für die Firma lohnt es sich nicht. Du hast mindestens 2 Paketformate (deb/rpm), die jeweils für mindestens zwei Architekturen (x64/x86) bereitgestellt werden wollen (32Bit-DEB unter 64Bit-Linux ist wäh), und wenn man nicht alles statisch macht, muss das ganze noch für mindestens ein Dutzend Distris getestet werden... es ist ja nicht so, als hätten alle Linux-User immer das aktuellste Ubuntu in der 64Bit-Version. 😉

Ich denke ehrlich gesagt, dass an dieser Stelle nicht die Spielehersteller im Zugzwang sind sondern wirklich von Linux eine vernünftige Lösung gestellt werden muss. Nicht, dass wir alle Paketsysteme weg schmeissen müssen, aber so ne Art "unified solution" fehlt im Moment defintitv.

Außerdem sehe ich das schon so, dass wir Linux User froh sein müssen, mit den tausend Paketmanagern und unserem geringen prozentualen Anteil an den Spielekonsumenten überhaupt ein Spiel nativ für Linux zu bekommen.

Aber das Problem kenne ich zu gut. "Judith" oder "the Passage" (zwei runterladbare, sehr empfehlenswerte Indie Spiele) zum laufen zu kriegen gestaltete sich unter zwei verschiedenen Distributionen völlig anders, war ein Abenteuer und in einem Fall auch ne ganze Menge arbeit. Obwohl es native Linux Pakete gibt.

Hallo

Was ist denn daran so schwer??? hier mal 3 Möglichkeiten

1. Methode

sh spiel.run

oder

sh spiel.bin

2. Methode

chmod -x spiel.run
./spiel.run 

oder

chmod -x spiel.bin
./spiel.bin 

3. Methode (falls du Angst von der Konsole hast)

• rechte Maustaste auf die .run oder .bin datei

• Eigenschaften

• im Reiter "Zugriffsrechte" das häckchen auf "Ausführbar" stellen

• mit Doppelklick die Datei ausführen

P.s ausserdem, ist es kein grosses Problem ein .deb oder .rpm Paket davon zu erstellen. (Wobei mein Beispiel für 32bit Systeme ist)

sudo sh spiel.run --buildpkg Ubuntu/jaunty

oder

sudo sh spiel.bin --buildpkg Ubuntu/jaunty

danach hast du dein .deb Paket, wo du wie gewohnt installieren kannst

gruss

olivier1979

Tids schrieb:

"Kack doch auf die Kunden, die sollen froh sein überhaupt nen Port bekommen zu haben." So ist das wie ich es sehe. Warum stellt denn fast niemand eine DEB und oder RPM Version zu Verfügung? Diese können genauso "Static" sein und ihre Abhängigkeiten mitbringen(Opera macht dies z.B. auch). Aber nein, man bekommt irgendwelche installer die man als Änfängen nicht installiert bekommt und wenn einmal installiert das verschwinden die Daten irgendwo im System so das man den Uninstaller niemals wieder findet(wenn es überhaupt einen gibt).

Hier muss sich Linux an die eigene Nase fassen. 1000 Distributionen, keine wie die andere. Jede Distribution noch unterteilt in verschiedene Versionen, jede davon noch in 32 und 64 Bit. Selbst statisch gelinkt müssten mehrere Pakete angeboten werden. Und wo ist das Problem, eine *.bin oder *.run Datei auszuführen?

olivier1979 schrieb:

P.s ausserdem, ist es kein grosses Problem ein .deb oder .rpm Paket davon zu erstellen. (Wobei mein Beispiel für 32bit Systeme ist)

sudo sh spiel.run --buildpkg Ubuntu/jaunty

oder

sudo sh spiel.bin --buildpkg Ubuntu/jaunty

danach hast du dein .deb Paket, wo du wie gewohnt installieren kannst

Danke nebenbei, das kannte ich noch nicht. Ist das ein Feature von sudo, sh oder...? Sprich in welcher manpage o.ä. kann ich mehr darüber lesen?

Hallo

Sprich in welcher manpage o.ä. kann ich mehr darüber lesen?

dies ist eine gute Frage ❓ ❓ ❓, ich habe keine Ahnung. 😳

am naheliegensten ist meiner Meinung nach

man dpkg-buildpackage

http://www.nongnu.org/buildpkg/

gruss

olivier1979

olivier1979 schrieb:

P.s ausserdem, ist es kein grosses Problem ein .deb oder .rpm Paket davon zu erstellen. (Wobei mein Beispiel für 32bit Systeme ist)

sudo sh spiel.run --buildpkg Ubuntu/jaunty

oder

sudo sh spiel.bin --buildpkg Ubuntu/jaunty

danach hast du dein .deb Paket, wo du wie gewohnt installieren kannst

Ist jetzt nicht böse gemeint aber bei welchem Spiel funktioniert denn das? Ich weiß das man so beim Radeon Catalyst(fglrx) die DEB bauen lassen kann aber mir ist kein Spiel bekannt bei dem das funktionieren würde.

burli schrieb:

[...] Und wo ist das Problem, eine *.bin oder *.run Datei auszuführen?

Meine Mutter und meine Nichte verstehe nicht wie es geht und wenn der installer dann läuft, nach /opt installieren will und das geht nicht, weil die Rechte halt fehlen, dann ist das ganze halt "ein Müllsystem auf dem nix geht"

Außerdem lebt "Linux" von der Community, wieso also nicht einfach die Paketschnürraufgabe in diese auslagern? Das klappt sicher ganz gut. Eigentlich würde es auch reichen die Pakete als RPM zu bauen. Das wäre, soweit ich weiß LBS konform und dank alien nicht wirklich weit zu nem DEB hin. Vielleicht sehe ich das alles viel zu verklemmt aber ich wünsche mir ein sauberes System. Hoffentlich kommt irgendwann dieser Zeitpunkt auch noch 😀

olivier1979 schrieb:

1. Methode

sh spiel.run

oder

sh spiel.bin

2. Methode

chmod -x spiel.run
./spiel.run 

oder

chmod -x spiel.bin
./spiel.bin 

3. Methode (falls du Angst von der Konsole hast)

• rechte Maustaste auf die .run oder .bin datei

• Eigenschaften

• im Reiter "Zugriffsrechte" das häckchen auf "Ausführbar" stellen

• mit Doppelklick die Datei ausführen

Dienen diese 3 Methoden zur Installation oder zum Starten der Anwendung?

WilhelmHH schrieb:

Dienen diese 3 Methoden zur Installation oder zum Starten der Anwendung?

Sie dienen zum Ausführen der angegebenen Datei. Das ist ähnlich, wie zu fragen, ob ein Doppelklick in Windows eine Anwendung startet oder sie installiert. Kommt halt auf die .run/bin an, wie auf die .exe in Windows. 🤓

Ich will in diesem Thread das Thema "bin" behandeln

Eine .bin - Datei bedeutet also nicht automatisch Installationsdatei?

(BIN/CUE ist keine Binary sondern ein CD - Image.)

Tids schrieb:

Warum stellt denn fast niemand eine DEB und oder RPM Version zu Verfügung? Diese können genauso "Static" sein und ihre Abhängigkeiten mitbringen(Opera macht dies z.B. auch). Aber nein, man bekommt irgendwelche installer die man als Änfängen nicht installiert bekommt und wenn einmal installiert das verschwinden die Daten irgendwo im System so das man den Uninstaller niemals wieder findet(wenn es überhaupt einen gibt).

Diese Installer, welche an meiner Paketverwaltung vorbei arbeiten will ich wirklich nicht nutzen.

Gibt es keine Paketverwaltung die eine solche Installation bemerkt?

Static etwas mit static libraries zu tun?

Es gibt auch noch die bin - Ordner und die sbin - Ordner.

WilhelmHH schrieb:

Eine .bin - Datei bedeutet also nicht automatisch Installationsdatei?

Jupp.

Wikipedia schreibt:

Die Erweiterung .run bei einem Dateinamen unter Linux kennzeichnet eine Linux-Installer-Datei. Bisweilen wird .bin als alternative Dateinamenserweiterung genutzt.

Letztlich muss sich aber kein Installer dahinter verbergen. Genausowenig wie bei einer .exe-Datei unter Windows.

@WilhelmHH: Befreie dich von der Vorstellung das Dateiendungen bei Linux eine genormte Bedeutung haben. Sie sind optional. Wenn jemand möchte kann er seinem Installationsprogramm auch die Endung .txt geben, das wird genau so funktionieren wie .bin, .run, .sh oder anderen Endungen, oder auch gar keine Dateiendung.

Einzig und allein Entscheidend ob ein Programm ein Programm ist (im Sinne von ausführbar) entscheidet das Ausführungsflag. Und ob das Programm dann ein Installationsprogramm ist, entscheidet der Programmierer 😉

Aber auch bei Windows gibt es keine genormte Endung für Installationsprogramme. Sie können die Endung .exe, .com, .bat oder .cmd haben. Allerdings ist Windows diesbezüglich ein wenig unflexibler als Linux/Unix-Systeme. Änderst du die Endung einer *.exe Datei in .txt, so glaubt das System es wäre nun eine Textdatei. Bei Linux/Unix bleibt es eine ausführbare Datei.

Schöne Zusammenfassung, Pumeluk2. 👍