Zugegeben, es gibt besseres als Java für Spiele. Aber Games wie Minecraft zeigen, dass es möglich ist und von vielen genutzt wird. Viele Wege führen nach Rom - wieso wird denn da nun so ein Einschnitt gemacht?
Eine gute Java-Umsetzung ist besser als gar keine Linux-Variante. Ohoh, ich weiss - da kommen jetzt Einsprüche von unseren C++-Devs?
Von Mal anders aufgefedelt am Mi, 21. Oktober 2015 um 09:11 #
Naja, solange ein Spiel Spaß macht und leistungstechnisch auf allen gängigen Geräten läuft, sollte die Implementierung Nebensache sein, indes C++ auch Nachteile birgt.
Die Spiele werden ja nicht "verbannt" weil sie auf Java aufsetzen, sondern weil sie nicht ohne Zusatzsoftware spielbar sind. Dafür gibt es aber Alternativen. Mann kann das Java-Kompilat an einer JavaVM + Standardbibliothek hängen und als ausführbares Programm ausliefern. Oder man übersetzt den Bytecode in Maschinenbefehle um oder man erzeugt aus dem Javacode C++-code. All diese Ansätze haben den Vorteil das jede ohne vorinstallierte JavaVM auskommen und ohne Abhängigkeiten ausgeliefert werden können, aber meines erachten nach, wäre es sinnvoller, den Steam Klienten so zu gestalten, dass er das Paketsystem fragt, ob Java installiert werden kann und dies veranlasst oder falls dies nicht möglich ist ein vom Entwickler erstelltes "Standalone-kompilat" herunterlädt.
Diese Variante hat den Vorteil, dass die Distribution eigene Java-Runtime verwendet wird und somit alle Spiele auf eine für dass System erstellte Runtime aufsetzten. Des Weiteren müssen sich die Entwickler nicht um Updates der vlt vom Spiel mitgelieferten Runtime kümmern.
Nachteilig ist aber, dass Steam einen Haufen Aufwand betreiben muss, um die Logik dafür zu implementieren und die Spiele als "Java abhängig" markieren muss.
...Denn während die Installation von Zusatzpaketen unter den meisten Distributionen kein Problem darstellt, wird der Anwender gerade bei SteamOS oftmals keine Möglichkeit haben, Alternativpakete zu installieren....
^^ Was ist den das für eine Aussage? Bitte erzähl nicht so einen Stuss! SteamOS ist nichts anderes als Debian mit ein paar Änderungen am Kernel und Userland. Da kann man sehr wohl Software installieren, auch Java! Und sogar per "apt-get". Einfach Steam beenden und man landet in einer Gnome-Session!
Das nur partiell korrekt. Der Einsatzbereich von SteamOS ist die Konsole, genauer gesagt die Steam Machines zusammen mit dem Steam Controller. Diese Systeme sind zugenagelt. Zu sehen beispielsweise bei der Maschine von Alienware, wo man nicht mal an die Spiele rankommt. Hier ist nix mit Gnome oder gar einer Installation von Zusatzanwendungen. Insofern ist deine Aussage nicht wirklich richtig.
Das eine schließt das Andere nicht aus. Laut Berichten über Alienware Machines, die letzte Woche an Magazine ausgeliefert wurden, kann man auf ihnen nichts installieren, die Spielstände sind verschlüsselt und auf SteamApps kann nicht zugegriffen werden. Woher also die Aussage, dass die Konsolen offen sind?
Q: What software runs on SteamOS? SteamOS is designed to run Steam and Steam games. It also provides a desktop mode which can run regular Linux applications. SteamOS makes use of the standard APT package manager for software updates; you can add third-party sources to your subscribed repositories to gain access to more applications. SteamOS currently provides a limited set of packages, but many Debian wheezy packages work fine on SteamOS. We plan to make a wider variety of packages vailable directly from the SteamOS repositories over time.
Q: How do I get to the desktop on SteamOS? All I see is Steam. To access the SteamOS desktop, it must be enabled from the Steam Settings menu. Select Settings (the gear icon in the top right) then select Interface and check the "Enable access to the Linux desktop" box. Now the Exit button will have an additional option, "Return to Desktop" that will switch to the SteamOS desktop.
From the desktop, click on the "Return to Steam" icon to switch back to Steam.
Q: How do I get root access to SteamOS? The desktop account can gain root access, but ships with no password. Before you can use this account to gain root access, you need to assign it a password. From the desktop session, start a terminal window and type "passwd". Enter your new password twice. Now you can use the "sudo" command to perform privileged operations.
Eine Steammachine ist ja keine herkömmlich Konsole :D. Kannst auch eine andere Distribution deiner Wahl installieren, oder wenn es den unbedingt sein muß auch ein Windows.
Von Offen ist eine Eigenschaft am Mi, 21. Oktober 2015 um 09:16 #
Naja, da es so offen ist, können die Hersteller selber über die Konfiguration der Systeme bestimmen und wenn Alienware das offene System schließt, liegt dies in der Freiheit eines offenen Systems.
Von Penguin Gamer am Mi, 21. Oktober 2015 um 11:04 #
Nochmal! Tastertur & Maus!
DAS SYSTEM IST NICHT GESCHLOSSEN! Der Linux-Desktop und der root-Zugang sind immer noch zugänglich. Das einzige was Alienware hier treibt, ist das es anscheindend den Steamfolder & Savefiles irgendwie verschlüsselt(?).
Von Martin1991zab am Di, 20. Oktober 2015 um 08:52 #
Es wurde den Spielen das Logo entzogen die mehr brauchen als die "Standard" 3D API (also OpenGL) und die Steam Runtime. Launcher sind also OK (auch wenn es bevorzugt AUCH ohne gehen soll). Valve bietet den Entwicklern ein paar Scripte zum testen an.
Außerdem können die Spiele denen das Logo entzogen wurde auch weiterhin gekauft und unter Linux gespielt werden (sofern der Hersteller den Support nicht von sich aus eingestellt hat). Sie werden nur nicht mehr dafür beworben (sofern der Hersteller nicht nachbessert).
Man muss also eher sagen das Valve hier was gutes getan hat: Nämlich nur noch Spiele zu kennzeichnen die möglist unproblematisch laufen (hatte damit auch schon Probleme). Und da die Spiele weniger Äbhängigkeiten haben dürften die auch besser auf mehr Distros laufen.
Von Penguin Gamer am Di, 20. Oktober 2015 um 11:27 #
Außerdem können die Spiele denen das Logo entzogen wurde auch weiterhin gekauft und unter Linux gespielt werden (sofern der Hersteller den Support nicht von sich aus eingestellt hat). Sie werden nur nicht mehr dafür beworben (sofern der Hersteller nicht nachbessert).
Ja, können, wenn man sie den noch findet, wenn man nach SteamOS-Games sucht. Ganz schlecht für die eh schon schlechten Verkaufszahlen.
Man muss also eher sagen das Valve hier was gutes getan hat: Nämlich nur noch Spiele zu kennzeichnen die möglist unproblematisch laufen (hatte damit auch schon Probleme).
Es mag auf lange Sicht was Gutes sein, aber kurzfristig schadet es mehr als nutzt. Zumal Valve es ja noch nicht einmal kommuniziert hat. Selbst die Entwickler waren komplett überrascht. Sinnvoller wäre es gewesen, die Entwickler darauf aufmerksam zu machen und ihnen dann eine Frist zu geben, bevor man das Icon entfernt. Wurde aber Valve-Typisch nicht getan
Der Großteil der Spiele bei denen das Icon entfernt wurde liefen auch jetzt schon unproblematisch, und das auf unterschiedlicher Hardware & Distributionen. Einmal auf Install klicken und Spaß haben. Da soll Valve lieber mal ihr SteamOS nachbessern, wenn es da Probleme gibt.
Betrifft das auch den Starbound Server? Der läuft auf meiner Linux Box in Netz, wäre ziemlich doof wenn der support auch gedroppt wird. Vorallem da Starbound ohne Probleme läuft
Von Penguin Gamer am Di, 20. Oktober 2015 um 11:29 #
Der läuft auch weiterhin. Die Icons wurden Valve entfernt, und nicht von den Enwicklern/Publishern.
Quote von den Starbound-Entwicklern:
To my knowledge we've not yet had official communication with Valve about this, we've e-mailed them asking wtf, but we haven't gotten a response and probably won't until at least Monday. This is our best guess to the problem. Who knows, it might be the launcher. I just can't say it's necessarily the launcher yet.
Von Oiler der Borg am Di, 20. Oktober 2015 um 09:25 #
auch wenns erstmal lästig klingt... aber mittelfristig dürfte es Linux mehr nützen als schaden, wenn die q´n´d-Reinfrickellösungen rausfallen.. Die nährten sonst das Gerücht um einen unsicheren Kantonisten für Spiele
Ich finde es auch eher gut als schlecht weil jetzt dadurch jene die sich tatsächlich die mühe machten ihre Spiele nativ zum laufen zu bekommen dafür endlich auch entsprechend anerkannt werden. Die Typen welche Java und/oder wine benutzen um ihren Schund durch die Hintertür zum laufen zu bekommen sind doch meistens nichts anderes als Parasiten welche sich an der Arbeit anderer bereichern wollen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Okt 2015 um 10:39.
Von Minecraftian am Di, 20. Oktober 2015 um 11:34 #
Langfristig ist es sicher gut, aber kurzfristig: WTF? VALVE?!?!?
ie Typen welche Java und/oder wine benutzen um ihren Schund durch die Hintertür zum laufen zu bekommen sind doch meistens nichts anderes als Parasiten welche sich an der Arbeit anderer bereichern wollen.
Interessant Minecraft ist also Schund?
Bei älteren Titeln kann ich Wine verstehen, aber bei neueren ist es nur ein Frechheit. Kann aber kein Problem bei Java sehen.
Von Oiler der Borg am Mi, 21. Oktober 2015 um 09:38 #
Langfristig ist es sicher gut, aber kurzfristig: WTF? VALVE?!?!?
Man kann nunmal den Kuchen nicht sowohl behalten als auch aufessen Das Ziel , dass wir ja anscheinend alle hier begrüssen, ist sauber implementierte SW für Linux und dazu gehört nun mal das Auskehren des Schmutz.
Warum sollte man nicht gegen die Wine-API programmieren dürfen?
Persönlich stelle ich es mir auch unangenehm vor, aber ich sehe jetzt nicht warum ein Entwickler das nicht dürfen sollte. Wenn es gut läuft, dann spricht von meiner Seite aus nichts dagegen.
"Wenn" Ist das Stichwort. Innerhalb von wine mag ja speziell darauf angepasste Software zufriedenstellend laufen aber sobald es darüber hinausgeht, und sei es auch nur für Peripheriegeräte, geht das ganze einem schnell mal nur noch auf die Nerven. Die ganze Energie die manche dort hinein stecken wäre im Nativ-Support weit besser aufgehoben.
Kleines Beispiel: TeamViewer gibt es nicht, und wird es vermutlich nie, nativ für Linux weil die Devs ja sagen können: "Es läuft doch, irgenwie..." Aber andere wie AnyDesk wollen es richtig machen und haben inzwischen auch eine Version (zwar noch Alpha aber immer hin etwas) herausgebracht welche tatsächlich nativ auf Linux funktioniert und dazu auch noch portabel.
Vielen fehlt es einfach am Willen es RICHTIG zu machen und solche [nennt diese typen wie ihr wollt, für mich sind das Parasiten] sollte man nicht auch noch mit einem "Ja es ist, genau wie die anderen, für Linux verfügbar."-Sticker belohnen.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 20. Okt 2015 um 12:56.
Der Unterschied ist : TeamViewer läuft doch! Als Anwender ist es mir egal. Und ob irgendwelche Ideologen sagen, dass es so und so besser wäre, ist mir Wurstkäse.
"We've been removing the store bit from games that cannot run against just the Steam Runtime, without additional dependencies on the host system."
Es geht nicht darum, dass man java verbieten möchte oder Unity (die Programme benötigen ja auch eine mono runtime).
Was Valve will ist, dass alles, was zur Ausführung des Spiels nötig ist, mit dem Paket mitgeliefert wird, also auch die java JRE. Bei Spielen, die mit Unity erstellt wurden, wird die mono runtime mitgeliefert.
Das selbe Problem könnte man auch bei nativen Spielen haben, die mit C++ erstellt wurden, wenn man irgend eine externe Lib verwendet. Die müsste man dann auch mitliefern, anstatt diese erst als Abhängigkeit bei Installation des Spieles vorauszusetzen.
Also genau das Gegenteil von dem Kurs, den Admins und Distributoren im Allgemeinen fahren, nämlich viele sehr kleinteilige Abhängigkeiten zu schaffen, so dass möglichst keine Shared Lib in zwei verschiedenen Versionen auf dem System vorhanden sein muss. Was mit Aufwand verbunden ist.
Das macht das Einpflegen von systemweiten Verbesserungen und Sicherheitsupdates zwar im Endeffekt einfacher, würde aber für Valve zu einem Support-Albtraum führen, wenn die das plötzlich für alle Hersteller und Lieferanten koordinieren müssten. Bleibt die stille Hoffnung, dass die Spielehersteller sich in Zukunft auf die von Valve supportete Steam Runtime beschränken können, statt ihre jahrealten, ungepatchten, ranzigen Uralt-Libraries mitzuliefern...
Von Penguin Gamer am Mi, 21. Oktober 2015 um 11:23 #
Also genau das Gegenteil von dem Kurs, den Admins und Distributoren im Allgemeinen fahren, nämlich viele sehr kleinteilige Abhängigkeiten zu schaffen, so dass möglichst keine Shared Lib in zwei verschiedenen Versionen auf dem System vorhanden sein muss.
Deswegen braucht man sie trotzdem meistens, weil die Entwickler der Lib so nett sind die Libs von einer auf die nächste Version inkompatibel zu machen, d.h. eine Applikaton läuft z.B. mit der neuen Lib nicht, und braucht zwingend die alte. Das herauszufinden und entsprechend einzurichten ist auch mit ordentlich Aufwand verbunden.
Bleibt die stille Hoffnung, dass die Spielehersteller sich in Zukunft auf die von Valve supportete Steam Runtime beschränken können
Das ist keine Hoffnung, sondern ein Albtraum! Auf GOG fehlen jetzt schon Linux-Versionen wegen der Steam Runtime
statt ihre jahrealten, ungepatchten, ranzigen Uralt-Libraries mitzuliefern...
Unter Windows ist z.B. a) üblich und b) werden die Libs meistens statisch gelinkt. Bei Linux steht einem meist die GPL beim statisch linken im Weg, und dynamisch kann manchmal zum Albtraum werden.
Das war lediglich eine Festellung, dass Valves Bedürfnisse offenbar konträr zu denen der Distro Maintainer und dem Bedarf typischer Server Admins steht, d.h. möglichst kleinteilige Änderungen ermöglichen.
Die Steam Runtime baut auf eine ganze Reihe von Valve mehr oder weniger supporteten Open Source Bibliotheken, die auch ohne Steam eingesetzt werden können und die man prima über den Distro-Ansatz zentral pflegen kann. Valve will nicht, dass die installierten Spiele und Programme dann zusätzliche Abhängigkeiten über den Distro-Ansatz reinziehen. Weil sie dafür dann evtl. Support leisten müssten, z.B. wenn dadurch Inkompatibilitäten mit anderen Produkten auftreten. Deswegen sollen die Hersteller ihre Abhängigkeiten selbst mitliefern, am Distro-Mechanismus vorbei (wie bei Windows).
Windows ist kein Vorbild, aber das ist hierbei evtl. nur Wunschdenken. Ich dachte das wird aus meinem Kommentar klar, ohne dass ich es direkt dranschreibe
Von Kubunturaner am Di, 20. Oktober 2015 um 14:18 #
Zum großen teilen dürfte es nicht mal an den Programmen selbst liegen. Es ist nur einfach Fakt, dass Java Apps und Apps die einen Launcher haben, der vor dem Spiel startet die Desktops (und damit auch SteamOS) aus dem Tritt bringen. Legt euch z.B. mal eine Launcher für Minecraft in Plasma5 ins Panel, und zwar nicht über das Icon, sondern über "Rechtsklick auf die App -> Einen Starter anlegen". Nun Minecraft zu machen und wieder darüber starten wollen -> geht nicht. Weil man eben nicht Minecraft öffnet, sondern Java.
Gleiches ist es bei Wine. Genauso kann es bei Spielen sein, die einen Starter erwarter, bevor die eigentliche Binary ausgeführt wird (Hedgewars fällt mir hier ein).
Das ganze Betrifft natürlich nicht nur Plasma5, es ist nur der einzige Desktop wo ich jetzt mit Sicherheit über diese Funktionalität weiß.
Solche Sachen funktionieren eben unter Windows ohne Probleme aber sind ein gefrikel auf Linux Desktops.
Dann scheint aber das Problem eher bei den Linuxdesktops zu liegen, oder verstehe ich etwas falsch?
Ein Spiel kann ja ein Shellkript mitliefern, dass den java foobar.jar Befehl ausführt, zu diesem Skript werde ich mir doch dann einen Launcher anlegen können?
Zugegeben, es gibt besseres als Java für Spiele. Aber Games wie Minecraft zeigen, dass es möglich ist und von vielen genutzt wird. Viele Wege führen nach Rom - wieso wird denn da nun so ein Einschnitt gemacht?
Eine gute Java-Umsetzung ist besser als gar keine Linux-Variante. Ohoh, ich weiss - da kommen jetzt Einsprüche von unseren C++-Devs?
Naja, solange ein Spiel Spaß macht und leistungstechnisch auf allen gängigen Geräten läuft, sollte die Implementierung Nebensache sein, indes C++ auch Nachteile birgt.
Die Spiele werden ja nicht "verbannt" weil sie auf Java aufsetzen, sondern weil sie nicht ohne Zusatzsoftware spielbar sind. Dafür gibt es aber Alternativen. Mann kann das Java-Kompilat an einer JavaVM + Standardbibliothek hängen und als ausführbares Programm ausliefern. Oder man übersetzt den Bytecode in Maschinenbefehle um oder man erzeugt aus dem Javacode C++-code. All diese Ansätze haben den Vorteil das jede ohne vorinstallierte JavaVM auskommen und ohne Abhängigkeiten ausgeliefert werden können, aber meines erachten nach, wäre es sinnvoller, den Steam Klienten so zu gestalten, dass er das Paketsystem fragt, ob Java installiert werden kann und dies veranlasst oder falls dies nicht möglich ist ein vom Entwickler erstelltes "Standalone-kompilat" herunterlädt.
Diese Variante hat den Vorteil, dass die Distribution eigene Java-Runtime verwendet wird und somit alle Spiele auf eine für dass System erstellte Runtime aufsetzten. Des Weiteren müssen sich die Entwickler nicht um Updates der vlt vom Spiel mitgelieferten Runtime kümmern.
Nachteilig ist aber, dass Steam einen Haufen Aufwand betreiben muss, um die Logik dafür zu implementieren und die Spiele als "Java abhängig" markieren muss.
...Denn während die Installation von Zusatzpaketen unter den meisten Distributionen kein Problem darstellt, wird der Anwender gerade bei SteamOS oftmals keine Möglichkeit haben, Alternativpakete zu installieren....
^^ Was ist den das für eine Aussage? Bitte erzähl nicht so einen Stuss! SteamOS ist nichts anderes als Debian mit ein paar Änderungen am Kernel und Userland. Da kann man sehr wohl Software installieren, auch Java! Und sogar per "apt-get". Einfach Steam beenden und man landet in einer Gnome-Session!
...wirklich muss das sein?
Das nur partiell korrekt. Der Einsatzbereich von SteamOS ist die Konsole, genauer gesagt die Steam Machines zusammen mit dem Steam Controller. Diese Systeme sind zugenagelt. Zu sehen beispielsweise bei der Maschine von Alienware, wo man nicht mal an die Spiele rankommt. Hier ist nix mit Gnome oder gar einer Installation von Zusatzanwendungen. Insofern ist deine Aussage nicht wirklich richtig.
Da ist garnichts zugenagelt. Tastatur & Maus dran und los geht's!
Das eine schließt das Andere nicht aus. Laut Berichten über Alienware Machines, die letzte Woche an Magazine ausgeliefert wurden, kann man auf ihnen nichts installieren, die Spielstände sind verschlüsselt und auf SteamApps kann nicht zugegriffen werden. Woher also die Aussage, dass die Konsolen offen sind?
Woher die Aussage? Einfach mal SteamOS runterladen und testen!
http://store.steampowered.com/steamos/download
Guckst du hier:
SteamOS FAQ
Eine Steammachine ist ja keine herkömmlich Konsole :D. Kannst auch eine andere Distribution deiner Wahl installieren, oder wenn es den unbedingt sein muß auch ein Windows.
Naja, da es so offen ist, können die Hersteller selber über die Konfiguration der Systeme bestimmen und wenn Alienware das offene System schließt, liegt dies in der Freiheit eines offenen Systems.
Nochmal! Tastertur & Maus!
DAS SYSTEM IST NICHT GESCHLOSSEN! Der Linux-Desktop und der root-Zugang sind immer noch zugänglich. Das einzige was Alienware hier treibt, ist das es anscheindend den Steamfolder & Savefiles irgendwie verschlüsselt(?).
Es wurde den Spielen das Logo entzogen die mehr brauchen als die "Standard" 3D API (also OpenGL) und die Steam Runtime. Launcher sind also OK (auch wenn es bevorzugt AUCH ohne gehen soll). Valve bietet den Entwicklern ein paar Scripte zum testen an.
Außerdem können die Spiele denen das Logo entzogen wurde auch weiterhin gekauft und unter Linux gespielt werden (sofern der Hersteller den Support nicht von sich aus eingestellt hat). Sie werden nur nicht mehr dafür beworben (sofern der Hersteller nicht nachbessert).
Man muss also eher sagen das Valve hier was gutes getan hat: Nämlich nur noch Spiele zu kennzeichnen die möglist unproblematisch laufen (hatte damit auch schon Probleme).
Und da die Spiele weniger Äbhängigkeiten haben dürften die auch besser auf mehr Distros laufen.
MfG Martin
Quelle: http://www.gamingonlinux.com/articles/valve-rep-confirms-why-some-games-have-their-steamos-icon-removed.6092
Und: https://www.reddit.com/r/linux_gaming/comments/3p55xv/starbound_dev_on_valve_removing_the_linux_icon/cw37a0r
MfG Martin
Ja, können, wenn man sie den noch findet, wenn man nach SteamOS-Games sucht. Ganz schlecht für die eh schon schlechten Verkaufszahlen.
Es mag auf lange Sicht was Gutes sein, aber kurzfristig schadet es mehr als nutzt. Zumal Valve es ja noch nicht einmal kommuniziert hat. Selbst die Entwickler waren komplett überrascht. Sinnvoller wäre es gewesen, die Entwickler darauf aufmerksam zu machen und ihnen dann eine Frist zu geben, bevor man das Icon entfernt. Wurde aber Valve-Typisch nicht getan
Der Großteil der Spiele bei denen das Icon entfernt wurde liefen auch jetzt schon unproblematisch, und das auf unterschiedlicher Hardware & Distributionen. Einmal auf Install klicken und Spaß haben. Da soll Valve lieber mal ihr SteamOS nachbessern, wenn es da Probleme gibt.
Betrifft das auch den Starbound Server? Der läuft auf meiner Linux Box in Netz, wäre ziemlich doof wenn der support auch gedroppt wird.
Vorallem da Starbound ohne Probleme läuft
Der läuft auch weiterhin. Die Icons wurden Valve entfernt, und nicht von den Enwicklern/Publishern.
Quote von den Starbound-Entwicklern:
auch wenns erstmal lästig klingt...
aber mittelfristig dürfte es Linux mehr nützen als schaden, wenn die q´n´d-Reinfrickellösungen rausfallen.. Die nährten sonst das Gerücht um einen unsicheren Kantonisten für Spiele
Ich finde es auch eher gut als schlecht weil jetzt dadurch jene die sich tatsächlich die mühe machten ihre Spiele nativ zum laufen zu bekommen dafür endlich auch entsprechend anerkannt werden. Die Typen welche Java und/oder wine benutzen um ihren Schund durch die Hintertür zum laufen zu bekommen sind doch meistens nichts anderes als Parasiten welche sich an der Arbeit anderer bereichern wollen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Okt 2015 um 10:39.Langfristig ist es sicher gut, aber kurzfristig: WTF? VALVE?!?!?
Bei älteren Titeln kann ich Wine verstehen, aber bei neueren ist es nur ein Frechheit. Kann aber kein Problem bei Java sehen.
Mag sein das es ausnahmen gibt aber was mir bis jetzt untergekommen ist war schlicht zum schreien (im negativen sinne).
technisch betrachtet... durchaus.
Warum sollte man nicht gegen die Wine-API programmieren dürfen?
Persönlich stelle ich es mir auch unangenehm vor, aber ich sehe jetzt nicht warum ein Entwickler das nicht dürfen sollte. Wenn es gut läuft, dann spricht von meiner Seite aus nichts dagegen.
"Wenn" Ist das Stichwort.
Innerhalb von wine mag ja speziell darauf angepasste Software zufriedenstellend laufen aber sobald es darüber hinausgeht, und sei es auch nur für Peripheriegeräte, geht das ganze einem schnell mal nur noch auf die Nerven. Die ganze Energie die manche dort hinein stecken wäre im Nativ-Support weit besser aufgehoben.
Kleines Beispiel:
TeamViewer gibt es nicht, und wird es vermutlich nie, nativ für Linux weil die Devs ja sagen können: "Es läuft doch, irgenwie..."
Aber andere wie AnyDesk wollen es richtig machen und haben inzwischen auch eine Version (zwar noch Alpha aber immer hin etwas) herausgebracht welche tatsächlich nativ auf Linux funktioniert und dazu auch noch portabel.
Vielen fehlt es einfach am Willen es RICHTIG zu machen und solche [nennt diese typen wie ihr wollt, für mich sind das Parasiten] sollte man nicht auch noch mit einem "Ja es ist, genau wie die anderen, für Linux verfügbar."-Sticker belohnen.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 20. Okt 2015 um 12:56.Der Unterschied ist : TeamViewer läuft doch! Als Anwender ist es mir egal. Und ob irgendwelche Ideologen sagen, dass es so und so besser wäre, ist mir Wurstkäse.
"We've been removing the store bit from games that cannot run against just the Steam Runtime, without additional dependencies on the host system."
Es geht nicht darum, dass man java verbieten möchte oder Unity (die Programme benötigen ja auch eine mono runtime).
Was Valve will ist, dass alles, was zur Ausführung des Spiels nötig ist, mit dem Paket mitgeliefert wird, also auch die java JRE. Bei Spielen, die mit Unity erstellt wurden, wird die mono runtime mitgeliefert.
Das selbe Problem könnte man auch bei nativen Spielen haben, die mit C++ erstellt wurden, wenn man irgend eine externe Lib verwendet. Die müsste man dann auch mitliefern, anstatt diese erst als Abhängigkeit bei Installation des Spieles vorauszusetzen.
Also genau das Gegenteil von dem Kurs, den Admins und Distributoren im Allgemeinen fahren, nämlich viele sehr kleinteilige Abhängigkeiten zu schaffen, so dass möglichst keine Shared Lib in zwei verschiedenen Versionen auf dem System vorhanden sein muss. Was mit Aufwand verbunden ist.
Das macht das Einpflegen von systemweiten Verbesserungen und Sicherheitsupdates zwar im Endeffekt einfacher, würde aber für Valve zu einem Support-Albtraum führen, wenn die das plötzlich für alle Hersteller und Lieferanten koordinieren müssten. Bleibt die stille Hoffnung, dass die Spielehersteller sich in Zukunft auf die von Valve supportete Steam Runtime beschränken können, statt ihre jahrealten, ungepatchten, ranzigen Uralt-Libraries mitzuliefern...
Deswegen braucht man sie trotzdem meistens, weil die Entwickler der Lib so nett sind die Libs von einer auf die nächste Version inkompatibel zu machen, d.h. eine Applikaton läuft z.B. mit der neuen Lib nicht, und braucht zwingend die alte. Das herauszufinden und entsprechend einzurichten ist auch mit ordentlich Aufwand verbunden.
Das ist keine Hoffnung, sondern ein Albtraum! Auf GOG fehlen jetzt schon Linux-Versionen wegen der Steam Runtime
Unter Windows ist z.B. a) üblich und b) werden die Libs meistens statisch gelinkt. Bei Linux steht einem meist die GPL beim statisch linken im Weg, und dynamisch kann manchmal zum Albtraum werden.
Hat alles sein Vor- & Nachteile
Das war lediglich eine Festellung, dass Valves Bedürfnisse offenbar konträr zu denen der Distro Maintainer und dem Bedarf typischer Server Admins steht, d.h. möglichst kleinteilige Änderungen ermöglichen.
Die Steam Runtime baut auf eine ganze Reihe von Valve mehr oder weniger supporteten Open Source Bibliotheken, die auch ohne Steam eingesetzt werden können und die man prima über den Distro-Ansatz zentral pflegen kann. Valve will nicht, dass die installierten Spiele und Programme dann zusätzliche Abhängigkeiten über den Distro-Ansatz reinziehen. Weil sie dafür dann evtl. Support leisten müssten, z.B. wenn dadurch Inkompatibilitäten mit anderen Produkten auftreten. Deswegen sollen die Hersteller ihre Abhängigkeiten selbst mitliefern, am Distro-Mechanismus vorbei (wie bei Windows).
Windows ist kein Vorbild, aber das ist hierbei evtl. nur Wunschdenken. Ich dachte das wird aus meinem Kommentar klar, ohne dass ich es direkt dranschreibe
Zum großen teilen dürfte es nicht mal an den Programmen selbst liegen.
Es ist nur einfach Fakt, dass Java Apps und Apps die einen Launcher haben, der vor dem Spiel startet die Desktops (und damit auch SteamOS) aus dem Tritt bringen.
Legt euch z.B. mal eine Launcher für Minecraft in Plasma5 ins Panel, und zwar nicht über das Icon, sondern über "Rechtsklick auf die App -> Einen Starter anlegen". Nun Minecraft zu machen und wieder darüber starten wollen -> geht nicht. Weil man eben nicht Minecraft öffnet, sondern Java.
Gleiches ist es bei Wine. Genauso kann es bei Spielen sein, die einen Starter erwarter, bevor die eigentliche Binary ausgeführt wird (Hedgewars fällt mir hier ein).
Das ganze Betrifft natürlich nicht nur Plasma5, es ist nur der einzige Desktop wo ich jetzt mit Sicherheit über diese Funktionalität weiß.
Solche Sachen funktionieren eben unter Windows ohne Probleme aber sind ein gefrikel auf Linux Desktops.
Dann scheint aber das Problem eher bei den Linuxdesktops zu liegen, oder verstehe ich etwas falsch?
Ein Spiel kann ja ein Shellkript mitliefern, dass den java foobar.jar Befehl ausführt, zu diesem Skript werde ich mir doch dann einen Launcher anlegen können?
Das Problem liegt eher am User!
Wenn man dem Starter nicht sagt was er tun soll.
Im Starter einfach unter Befehl folgendes eingeben:
java -jar /home/~user~/.minecraft/launcher.jar
und fertig ist das ganze!
oder man nimmt ordentlich implementierte SW