AMD dank Konsolen mit mehr x86-Marktanteil

[DSmon]

2. Meinst du es macht Spaß ein Windows Spiel mit wine irgendwie zum Laufen zu bekommen nur weil der Publisher den Mehraufwand scheut, plattformübergreifend zu veröffentlichen?

Mir schon. Ich spiele und nutze seit 4(?) Jahren nicht mal mehr Windows als Dualboot.

Allerdings sehe es mal anderes herum. Soll der Publisher nun für jedes OS extra programmieren? Dann sollten Programme deiner Meinung nach auch auf *BSD, sontigen Unixen usw laufen?

 

[neuli]

Allerdings sehe es mal anderes herum. Soll der Publisher nun für jedes OS extra programmieren? Dann sollten Programme deiner Meinung nach auch auf *BSD, sontigen Unixen usw laufen?

Im Idealfall ja. Das ist auch im Kommen und schimpft sich WebGl. Das ist exakt der Wunsch nach einfacher plattformübergreifender Programmierung. Allerdings wird so eine Anwendung sicher langsamer laufen als eine native Version.
Es muss ja nichteinmal eine native Version sein. Schau diie Spieleengine Unity an. Die löst das Problem indem sie die Anwendung in einem eigenen Webbrowser startet. Ist langsamer funktioniert aber. Und das ist ein Dialogklick im Buildmenü. Kann mir keiner sagen, dass das mit großem Mehraufwand verbunden sein soll.
Was mich aber wirklich aufregt sind Spiele, die mit einer Engine laufen, die Linux unterstützen und der Publisher gibt sie dennoch nur für Windows raus.

Mir schon. Ich spiele und nutze seit 4(?) Jahren nicht mal mehr Windows als Dualboot.

Gratulation. Ich schlag mich hier noch mit einem Dualbootsystem rum. Da es immer mehr Engines und Spiele für Linux gibt, wird sich das vielleicht in naher Zukunft ändern.

Edit: Es gibt so schöne Techniken wie IOMMU und VT-d mit denen man Grafikkarten ohne Leistungsverlust durchreichen können soll. Der Publisher muss seine Spiele also genau für ein einziges freies OS, dass man in einer Virtuellen Maschine, ohne Lizensgebühren bezahlen zu müssen, betreiben kann, veröffentlichen.
Dann könnte jeder das OS seiner Wahl nutzen. Ohne ein OS kaufen zu müssen, nur um ein Spiel spielen zu können.
Vielleicht wäre es sogar möglich die Konsolen zu emulieren. Dann hätte der Publisher sogar noch weniger Aufwand als wenn er für Windows portiert.

 

[DSmon]

Das Wörtchen "langsamer" ist hierbei aber auch deutlich untertrieben, dabei bewegt sich jetzt schon im CPU Markt recht wenig.
Viel Spaß beim Spielen von Battlefield 4 per WebGL.

Und das ist ein Dialogklick im Buildmenü

Bitte was und bitte wo?
Ich entwickel also mit D3D und wo kann ich das dann anklicken?

 

[CryptonNite]

Ja natürlich braucht er mehr Strom, wie soll sonst überholen möglich sein mit einem Fertigungsnachteil?

AMDFX: AMD FX 9590 vs intel i7 4770k - X264 V. 5.0

Schlechtes Argument, zumal noch von ner eindeutigen Seite. Ein objektiver Test wäre aussagekräftiger. Wenn ich mir etwas Zeit lasse und etwas intensiver suche, dann werde ich auch so'n Pseudotest finden, wo der AMD gegen irgendeinen Intel einfach nur abkackt, z.B. bei SuperPi. Ich konnte beide CPUs nutzen und der genannte Intel-Prozessor ist im Durchschnitt eindeutig schneller und er verbraucht weniger Strom (das ist übrigens ein Argument, was die Fanatiker von AMD damals beim Pentium 4 ständig gebracht haben und es ist nur gerecht, wenn euch das jetzt auch laufend unter die Nase gehalten wird). Trotzdem ist der FX 9590 nen Rohrkrepierer par ecellence. Zum Glück hat das auch AMD bereits eingesehen. Nun hoffe ich, daß es mal wieder was sinnvolles im HighEnd von AMD gibt.

 

[AliManali]

Edit: Es gibt so schöne Techniken wie IOMMU und VT-? mit denen man wunderbar Grafaikkarten durchreichen kann. Der Publisher muss seine Spiele also genau für ein einziges freies OS, dass man in einer Virtuellen Machine ohne Lizensgebühren bezahlen zu müssen betreiben kann, veröffentlichen.
Dann könnte jeder das OS seiner Wahl nutzen. Ohne ein OS kaufen zu müssen, nur um ein Spiel spielen zu können.
Vielleicht wäre es sogar möglich die Konsolen zu emulieren. Dann hätte der Publisher sogar noch weniger Aufwand als wenn er für Windows portiert.

Soweit ich weiss, für Baremetal Hypervisoren nur bedingt bis gar nicht möglich, und für "normale" Virtualisierung in einer Box erst gar nicht verfügbar?! Ich lass mich gerne eines Besseren belehren!

Ich würds auch begüssen, ich könnte - mit vertretbarem Aufwand - die ganzen Multimedia- (insbesondere DVB-C) sowie Gaming Anwendungen (DirectX...) unter Linux ausführen. Dann würde ich Windows schleunigst den Rücken kehren.

 

[neuli]

Bitte was und bitte wo?
Ich entwickel also mit D3D und wo kann ich das dann anklicken?

Was soll man denn auf sowas antworten. Du hast dich anscheinend null mit der Materie auseinandergesetzt. Wenn ich eine plattformunabhängige Engine nutze, reicht zum Wechsel der Zielplattform im Buildmenü ein Klick.
Klar kannst du auch einen Editor nutzen ein Terminal öffnen und von Hand kompilieren. Das mach ich auch. Allerdings geht das in einer IDE eben auch mit einem Klick, wenn diese mehrere Plattformen unterstützt.
Siehe auch: https://unity3d.com/unity/multiplatform
Mit Dialogklick meinte ich halt im Dialog auswählen und klicken. War vielleicht doof formuliert.
Wieso du nun D3D nutzen willst um plattformunabhängig zu programmieren ist mir schleierhaft. Auch das würde gehen wenn man einen Komplier, Wrapper ein Tool ein automatisches Skript oder was auch immer hat der das für OpenGl portiert.
Macht Valve das nicht so? Die haben doch neulich erst ihren Wrapper veröffentlicht: [Phoronix] Valve Open-Sources Their Direct3D To OpenGL Translation Layer Na sieh an.

Soweit ich weiss, für Baremetal Hypervisoren nur bedingt bis gar nicht möglich, und für "normale" Virtualisierung in einer Box erst gar nicht verfügbar?! Ich lass mich gerne eines Besseren belehren!

Ich habe irgendwo mal gelesen, dass das jemand hinbekommen hat. Allerdings brauchte man dafür 2 Grafikkarten eine für das Host und eine für das Gastsystem. Dann kommt die integrierte intel Grafik eben mal zum Einsatz. Ich such mal, kann aber nicht versprechen, dass ich das noch finde. Ich bin auch nicht mehr sicher ob das eine freie Virtuallisierungssoftware konnte oder eine Kostenpflichtige. Zweiteres ist natürlich nutzlos.
Hm da hat sich einer damit auseinandergesetzt: http://debianforum.de/forum/viewtopic.php?f=25&t=140895 Ich bild mir aber ein, dass ich das auf Phoronix oder heise gelsehen hatte. Ich such mal weiter.
Hab ein Video gefunden: https://www.youtube.com/watch?v=37D2bRsthfI#t=95
Im Video verlinkter Thread: https://bbs.archlinux.org/viewtopic.php?id=162768

 

[AliManali]

Ich hab es natürlich schon versucht

 

[Phantomias88]

Schlechtes Argument, zumal noch von ner eindeutigen Seite. Ein objektiver Test wäre aussagekräftiger. Wenn ich mir etwas Zeit lasse und etwas intensiver suche, dann werde ich auch so'n Pseudotest finden, wo der AMD gegen irgendeinen Intel einfach nur abkackt, z.B. bei SuperPi. Ich konnte beide CPUs nutzen und der genannte Intel-Prozessor ist im Durchschnitt eindeutig schneller und er verbraucht weniger Strom (das ist übrigens ein Argument, was die Fanatiker von AMD damals beim Pentium 4 ständig gebracht haben und es ist nur gerecht, wenn euch das jetzt auch laufend unter die Nase gehalten wird). Trotzdem ist der FX 9590 nen Rohrkrepierer par ecellence. Zum Glück hat das auch AMD bereits eingesehen. Nun hoffe ich, daß es mal wieder was sinnvolles im HighEnd von AMD gibt.

Für SuperPi gibt es auch schon eine alternative Software.
Der Verbrauch ist natürlich schlecht, das interessiert mich aber relativ wenig. (Enthusiast)
Denn wirklich schneller wird es nur mit deutlich größerem Finanziellen aufwand.

Wie du schon schreibst, wird der FX-9590 gerne ignoriert, vermutlich so lange bis es kein High-end mehr gibt von AMD, die Konsolen werden es reisen!

 

[Mick_Foley]

Die Konsolen reißen es jetzt schon, ohne die würde die Meldung hier bald eher lauten "AMD bangt um Einzug in den Bundestag". Gerade der AM3+ Sockel ist sowas von tot und irrelevant am Markt. Dass eine CPU-Architektur ohne CMT AMD über Wasser hält dürfte bei Intel ein riesen Treppenwitz sein...

 

[ONE_FOR_ALL]

Wenn AMD dies und das nicht hätte würden sie schon längst........Kommt mir seit Jahren vor wie"Warten auf Godot".

 

[Mick_Foley]

Ich dachte der Standard AMD-Spruch wäre "Mit der nächsten Generation in einem Jahr wird alles viel besser..." Naja was soll es bis zu einem i3 bietet AMD ja durch aus noch alternativen, auch wenn ich mir ein, zwei Kaveri-Athlons wünschen würde...

 

[Shino]

Kaveri Athlons hätte ich auch gern am liebsten als X6 mit L3 Cache.

 

[Mick_Foley]

Ich fände x4 schon nett. Ein Paar Modelle mit kleiner iGPU und ordentlich Takt wären auch nett, AMD limitiert sich da leider künstlich selbst.

 

[ONE_FOR_ALL]

Ich dachte der Standard AMD-Spruch wäre "Mit der nächsten Generation in einem Jahr wird alles viel besser..." Naja was soll es bis zu einem i3 bietet AMD ja durch aus noch alternativen, auch wenn ich mir ein, zwei Kaveri-Athlons wünschen würde...

Hab ich das jemals gesagt.

 

[CryptonNite]

Für SuperPi gibt es auch schon eine alternative Software.

Schön, nur nutzt die niemand. Für Prime95 bietet sich LinPack (z.B. als Programm "LinX") auch als Alternative an, die auch deutlich mehr das System belastet (z.B. Prime + WaKü ~50°C, LinX + WaKü ~ 65°C ). Es juckt aber niemanden.

 

[DSmon]

Jup neuli, da haben wir aneinander vorbei geredet. Ich bezog mich darauf, dass es eben damit langsamer ist und man dann wohl bei D3D bleibt und es damit eben nicht möglich ist.
WebGL basiert übrigens unter anderem auch auf JavaScript, müsste also auch erst vom Browser übersetzt werden, hinzu kommen dann noch gewisse Sandboxing Mechanismen, usw.
Aufgrund der Zielgruppe ist das auch nachvollziehbar, finde ich. Was nützt es mir, wenn ich zwar alle Plattformen anspreche, ich mir aber auch gleichzeitig die Zielgruppe wieder stark verkleinere, weil ich anstatt eines Dualcores einen neueren Quadcore benötige, um das Spiel flüssig zu spielen oder eben starke Einbußen bei der Grafik/Physik habe, nur damit es überall annehmbar läuft.

Auch beachten muss man, dass man eventuell schon Entwicklerteams hat, die in D3D voll drin stecken und diese eben auch erst auf WebGL "umlernen" müsste, was mit Zeitverlust und Kosten verbunden ist.

Macht Valve das nicht so?

Jupp, Valve macht das so. Allerdings sind bei ToGL auch noch nicht alle D3D-Funktionstransitionen implementiert. Außerdem ist ToGL sehr auf die Source Engine zugeschnitten, damit man dort keinen großen Overhead erzeugt. Für andere Engines müsste man auch hier wieder viel anpassen. ToGL schlägt übrigens in eine ähnliche Richtung wie winelib.

Kann mir keiner sagen, dass das mit großem Mehraufwand verbunden sein soll. Was mich aber wirklich aufregt sind Spiele, die mit einer Engine laufen, die Linux unterstützen und der Publisher gibt sie dennoch nur für Windows raus.

Erstens kommt hier noch das debuggen unter Linux hinzu. Wie war das noch mit den 3 Fehlern auf 1000 Zeilen Code?
Die Engine ist eben auch nur von Menschen gemacht, aber wenn ich sie als Spieleentwickler weiterverkaufe, muss ich auch dafür sorgen, dass das, was ich damit mache, beim Endkunden läuft.

Keiner garantiert, dass die Engine unter Windows genauso einwandfrei läuft wie unter Linux. Kann gut sein, dass dsound wunderbar funktioniert, die Engine bei gleichem Output und ALSA aber abstürzt. Unter pulseaudio gibt sie gar keinen Sound aus und unter JACK lässt sie sich nicht einmal starten.

Dann sollte es am besten noch unter nouveau laufen, genauso wie es unter nvida läuft. Hinzu kommt noch radeon vs fglrx und dann natürlich noch intel. Also muss ich das Spiel noch unter diesen 5 Treiber testen.

Was ist denn dieses Linux? Nein ernsthaft, wie würdest du so ein Spiel auf die DVD packen? Als Installer.sh? Die ihr Zeug dann irgendwo unter /opt ablegt? Oder als .deb, .rpm, .pkg.tar.xz, ...?
Dann will es aber jemand unter Gentoo installieren, der entpackt einfach das .deb und wundert sich, dass danach sein System kaputt ist. Dann ruft er den Support des Spieleentwicklers an, das Spiel hat sein System geschrottet, die sollen das wieder richten. Dann wird eine lib benötigt in der Version x.y, wird dann aber in einer Distri geupdatet, ok, lösen wir, in dem wir alles statisch linken, endet es eben wie unter Windows, aber da wäre manchen das Linux ja auch am liebsten. Nun kann ich den Kernel aber nicht dynamisch linken, das Spiel soll aber bei allen laufen, die mit dem 3.14er und bei denjenigen mit einer LTS Distri, die noch 2.6.32 fahren.

Wenn ich ein Spiel _verkaufe_, muss ich auch garantieren, dass es bei den meisten auch läuft. Unter Linux ist das eben nicht so prall. Hinzu kommt, dass sich bei den 1% der Linux Nutzern eventuell auch nur 5% das Spiel kaufen würden. 4% würden sich das eh kaufen, da sie ein Dualboot haben oder eine zweite Kiste. Habe ich also 0.01% der Kunden gewonnen für einen immensen zusätzlichen Testaufwand.

 

[Mick_Foley]

Was ist denn dieses Linux? Nein ernsthaft, wie würdest du so ein Spiel auf die DVD packen? Als Installer.sh? Die ihr Zeug dann irgendwo unter /opt ablegt? Oder als .deb, .rpm, .pkg.tar.xz, ...?
Dann will es aber jemand unter Gentoo installieren, der entpackt einfach das .deb und wundert sich, dass danach sein System kaputt ist. Dann ruft er den Support des Spieleentwicklers an, das Spiel hat sein System geschrottet, die sollen das wieder richten. Dann wird eine lib benötigt in der Version x.y, wird dann aber in einer Distri geupdatet, ok, lösen wir, in dem wir alles statisch linken, endet es eben wie unter Windows, aber da wäre manchen das Linux ja auch am liebsten. Nun kann ich den Kernel aber nicht dynamisch linken, das Spiel soll aber bei allen laufen, die mit dem 3.14er und bei denjenigen mit einer LTS Distri, die noch 2.6.32 fahren.

Wenn ich ein Spiel _verkaufe_, muss ich auch garantieren, dass es bei den meisten auch läuft. Unter Linux ist das eben nicht so prall. Hinzu kommt, dass sich bei den 1% der Linux Nutzern eventuell auch nur 5% das Spiel kaufen würden. 4% würden sich das eh kaufen, da sie ein Dualboot haben oder eine zweite Kiste. Habe ich also 0.01% der Kunden gewonnen für einen immensen zusätzlichen Testaufwand.

An einem Sonntag-morgen mit der Nadel durch die Gegend laufen und Seifenblasen zerstechen...

 

[neuli]

Jup neuli, da haben wir aneinander vorbei geredet. Ich bezog mich darauf, dass es eben damit langsamer ist.

Und mir geht es darum aufzuzeigen, dass wenn die entsprechenden Entwicklungstools fertig sind, nicht für jedes OS programmiert werden muss, sondern nur einmal.
Es ist auch völlig unerhebleich mit was für einer Programmiersprache programmiert wurde. Wenn es ideallerweise Automatisierungstools/funktionen in der Entwicklungsumgebung gibt oder - nicht so ideal - externe Tools, die das portieren/kompilieren. Und ja derzeit gibt es da noch massiven Nachholbedarf. Interessanterweise unterstützen aber alle neueren Engines die neue Konsolengneration. Linux gibt es nun schon wesentlich länger. Es ist also eher ein BWL Problem (mir fällt im Moment keine bessere Formulierung ein) als ein technisches.

Auch beachten muss man, dass man eventuell schon Entwicklerteams hat, die in D3D voll drin stecken und diese eben auch erst auf WebGL "umlernen" müsste, was mit Zeitverlust und Kosten verbunden ist.

Wie oben schon geschrieben Portierungstools.

WebGL

WebGl eignet sich meiner Meinung schön für so Neuauflagen wie good old games. Das war auch eher als Beispiel für plattformübergreifendes Programmieren gedacht. Es gibt immer mehrere Lösungen. Dass damit nicht der neuste Grafikkracher läuft, dachte ich sei klar.

Erstens kommt hier noch das debuggen unter Linux hinzu.

Da geb ich dir Recht. Allerdings reift heutzutage das Produkt beim Kunden. Man schreibt also ein Fehlerbenachrichtungstool sammelt die Fehlermeldungen und bringt dann irgendwann mal ein Patch raus.
Und wie du auch schon irgendwo schriebst hat sich der Engineprogrammierer damit rumzuärgern. Denn wenn das Spiel auf einem OS läuft und auf einem anderen von der Engine unterstützten OS nicht, sollte die Spieleprogrammierung eigentlich passen und der Feher in der Engineprogrammierung zu suchen sein.

Was ist denn dieses Linux?

Ja Vielfalt ist ein Segen und ein Fluch. Wie oben schon geschrieben und mit AliManali diskutiert: Ich hätte gern ein Spiel das auf einer Linux LiveDVD (Linux deshalb da kostenlos verfügbar und meines Wissens die beste freie Hardwareunterstützung vielleicht SteamOS?) rauskommt. Wenn der Publisher kostenlos eine Windows DVD und Lizenz beilegt habe ich da nun auch nichts groß gegen. Da dann die unnötige Vorraussetzung Windows entfällt, da mitgeliefert.
1. Der Aufdruck PC Spiel, der derzeit eher Windows Spiel lauten müsste, auf der Spielepackung stimmt endlich. Ich kann die DVD entnehmen einlegen und loslegen.
2. So kann der Publisher zeigen: Seht her es funktioniert. Die Linuxcommunity wird maximal zwei Wochen brauchen bis für die meisten Distributionen ein HowTo geschrieben wurde, das beschreibt wie man das Spiel unter seiner Distribution zum Laufen bekommt (Wenn die LiveDVD auf Linux basiert)
3. Das Problem der shared Libraries entfällt. Wobei ich denke, dass die Spiele statisch gelinkt werden. So traurig das auch ist.
Falls man aus irgendeinem Grund das Spiel in seiner Distribution nicht zum Laufen bekommen sollte. Kann man die Live DVD in eine VM knallen und wenn die Techniken IOMMU und VT-d dann auch mal das tun was sie laut Herstellern tun sollen, sollte das wunderbar funktionieren.

Ansonsten ist derzeit wohl das tar.gz Format üblich: Java SE Development Kit 7 - Downloads | Oracle Technology Network | Oracle. Allerdings ist es ziemlich schnuppe in welchem Linuxpaketformat das Spiel nun vorliegen wird. Da die Linuxcommunity sich diesem Problem schnell annehmen wird.
Oder eben AMD kontaktieren, da die offensichtlich schon ein Automatisierungstool geschrieben haben, da sie in ihrem Linux Catalyst Treiber jedes mir bekannte Linuxpaket erstellen können.
Wie auch immer das ist eigenlich auch ein technisches Problem, dass sich wunderbar automatisch per Tool lösen lassen müsste.

Um den Bogen mal zum Thema zu spannen:
Mir ist klar, dass das derzeit noch utopisch ist. Allerdings wenn die Engineentwickler SteamOS unterstützen, sollte das doch machbar sein.

P.S. Ich bezieh mich auf DSmon. Beiträge die meiner Meinung gegen die Forenregeln verstoßen ignoriere ich.

Edit: ganz vergessen:

Dann sollte es am besten noch unter nouveau laufen, genauso wie es unter nvida läuft. Hinzu kommt noch radeon vs fglrx und dann natürlich noch intel. Also muss ich das Spiel noch unter diesen 5 Treiber testen.

Naja die Spiele die unter dem Windows Standard Treiber laufen halten sich doch auch sehr in Grenzen. Aber auch hier Live DVD allerdings bleiben dann immernoch intel, fglrx und Nvidia blob Treiber übrig. Aber auch in Windows läuft ohne Treiberpatch ein Spiel nicht immer rund. Genau so wird es in Linux auch sein. Support Anfrage "Spiel stürzt ab" Antwort Support "liegt am Grafiktreiber".

Edit2:
An den Typ unter mir. SteamOS läuft auf x86 Hardware und ist meiner Meinung nach ein Konsolen OS. Titel lautet: AMD dank Konsolen mit mehr x86-Marktanteil Achja AMD baut auch x86 Hardware und SteamOS läuft darauf.

 

[rossi94]

 

[fdsonne]

Ja Vielfalt ist ein Segen und ein Fluch. Wie oben schon geschrieben und mit AliManali diskutiert: Ich hätte gern ein Spiel das auf einer Linux LiveDVD (Linux deshalb da kostenlos verfügbar und meines Wissens die beste freie Hardwareunterstützung vielleicht SteamOS?) rauskommt. Wenn der Publisher kostenlos eine Windows DVD und Lizenz beilegt habe ich da nun auch nichts groß gegen. Da dann die unnötige Vorraussetzung Windows entfällt, da mitgeliefert.

Du vergisst dabei aber scheinbar eine entscheidende Sache.
Linux ist kein Betriebssystem wie es ein Windows ist. Linux ist in erster Linie ein Kernel. Darauf setzen viele verschiedene Distributionen auf und "verkaufen" das ganze dann als Linux Derivat. Und hier ist auch schon das Problem. Der eine hätte gern Debian, der andere gern RedHed. Ein nächster kommt mit OpenSuse um die Ecke und wieder andere schwören auf Ubuntu usw. Unterm Strich ist das zwar alles irgendwie "Linux", aber es ist zum Teil mehr oder weniger verschieden...
Willst du wirklich flächendeckend unabhängig ein Programm anbieten, müsstest du deine Sources mit frei geben... Warum? Weil es immer irgendwo einen Punkt geben wird, wo du den Spaß selbst anpassen musst, weil eben in der gerade verwendeten Distribution aus welchen Gründen irgendwas oder irgendwer quer schießt. -> das ist der Tod für Bezahlmich Software.

Auch halte ich es persönlich für äußerst fraglich den Support und die Lauffähigkeit auf die Community abzudrücken. Das kann man machen für Communityprojekte ala Mods oder ähnliches. Aber nicht für die Basesoftware! Schon gleich gar nicht für Bezahlmich Software. Auch nutzt da die idR schnell vorhandene Reaktionszeit der Community nix, denn selbst 14 Tage wie du sie benennst sind viel zu lange für den Käufer eines Titels der ersten Stunde. Die Leute meckern ja jetzt schon über Releasepatches und Releasetreiberupdates und warum das nicht schon vorher drin war.
Auch ist das ganze nur bei AAA-Titeln überhaupt potentiell tragbar. Was machst du mit kleinen IndieGames oder ähnlichem, die von deutlich weniger Leuten im Vorfeld erwartet wurden. Entsprechend die Bekantheit auch deutlich geringer ist wie bei nem AAA Titel ala BF, Crysis und Co? Was ist mit Software, die monate nach Release dann durch irgendwelche Updates der Linuxdistribution auf einmal nicht mehr läuft? Wer kümmert sich dann um die Pflege der Lauffähigkeit? Vor allem bei Titeln, wo es schon einen oder mehrere Nachfolger gibt und das alte quasi in der Community nur noch bedingt anklang findet?

Zu guter letzt, was Windows angeht. Seit Win8 ist doch Windows so günstig wie nie...
Ich verstehe ehrlich das Problem daran nicht. MS hat nach Release von Win8 für gut und gerne 6 Monate für 30€ vollwertige Updatelizenzen auf Win8 verschleudert... Was will man mehr? Und selbst heute, so ein Win8/8.1 kostet effektiv im Laden keine 80€ mit DVD und Schlüssel. Ich mein, du hast davon mehrere Jahre was und bist auf dem aktuellen OS. (inkl. Update auf 8.1 nebst dessen Updates)
Aber selbst ein Windows 7 bekommt man hier und dort mit ein wenig suchen auch günstig. Ggf. gebraucht. Ist ja vollkommen wurscht, sofern man die Lizenz selbst nachweisen kann!
Geht man sogar mal etwas weg vom Selbstschrauber PC Bastelpersonen, so bekommt man eine Windows Lizenz idR mit sogut wie jedem fertig PC nachgeworfen. Und die Stangenware ist mit mindestens 50%, eher mehr im privaten Umfeld ein großer Batzen.
Ich mein, man muss es nicht nutzen, keine Frage, aber wenn man es braucht (bspw. für Games) warum nicht? Es gibt effektiv keinen Nachteil. Selbst ein billiges Vista/7 mit ner Lizenz irgendwo von nem fertig PC ausm Schrott gerettet wäre eine Option. -> und kostet effektiv nix. Die Entwickler von Games denken auch nur nach dem Wirtschaftlichkeitsprinzip. Und mit Windows erreicht man mal eben 90% vom Markt... Mit einem Linux bestenfalls 5-10%. Und das hat wie gesagt noch diverse Probleme aufgrund der x tonnen verschiedenen Versionen und Patchstände...


PS: ich wüsste auch nicht, was das in Summe mit den Konsolen zum Beispiel gemein hat.
Ich mein, gerade die Konsolen zeigen doch, das flächendeckend über viele verschiedene Produkte/Platformen gar nicht so gut ist. Lieber ein Produkt über mehrere Jahre, wo man sich drauf konzentrieren kann.
Diesen Umstand hat AMD ja hier auch erkannt und bietet die APU für beide große Gamekonsolen an. Ein absehbarer Erfolg für die nächsten Jahre ist damit garantiert! Wie man anhand der hierigen Zahlen sehen kann.
Wobei ich persönlich die Zahlen nicht ganz trivial finde. Aber die Statistik ist nunmal so wie sie ist. -> aus meiner Sicht gehören nämlich die Konsolenchips nur bedingt in den x86 Markt. Ich seh das aber eher vom PC Markt selbst... Denn dort nutzt der gesteigerte globale x86 Marktanteil für AMD leider dehnen gar nix.

 

[neuli]

Linux ist kein Betriebssystem wie es ein Windows ist.

Wie auf der vorrigen Seite schon angedeutet kein Problem offiziell wird dann halt SteamOS unterstützt. Den Rest erledigt die Linux Community.
Und im Gegensatz zu Windows kann ich SteamOS ohne zusätzlich Lizenzgebühren zahlen zu müssen, in einer VM laufen lassen, falls es wider Erwarten doch nicht klappen sollte.
Das ist dann hoffentlich in deinen Augen ein Betriebssystem. Vielleicht kann AMD ja noch ein paar APUs absetzen, die dann im Wohnzimmer in einem kleinen kompakten Klötzchen mit SteamOS laufen.

 

[DSmon]

Auf den Rest bin ich gerade zu faul einzugehen, aber OMFG?

Oder eben AMD kontaktieren, da die offensichtlich schon ein Automatisierungstool geschrieben haben, da sie in ihrem Linux Catalyst Treiber jedes mir bekannte Linuxpaket erstellen können.

Ist mir vollkommen neu, sag mir mal, wie das geht?

 

[neuli]

Ist mir vollkommen neu, sag mir mal, wie das geht?

Oh klar Ich probier es mal mit Bildern:
Bild: catalystpaketerstelluw8ir8.png - abload.de
Ich hoffe es ist klar welche Option ich meine.
Und jetzt nicht an der Version aufhängen. Ich nutzte seit längerem den radeon Treiber und habe den noch in /usr/portage/distfiles gefunden.
Diese kann das Tool generieren:

 AMD Catalyst(TM) Proprietary Driver Installer/Packager 
=====================================================================
List of generatable packages:

Package Maintainer(s): Aric Cyr <aric.cyr@gmail.com>
                      Mario Limonciello <superm1@gmail.com>
Status: *UNVERIFIED*
Debian Packages:
        Debian/sid
        Debian/unstable
        Debian/etch
        Debian/stable
        Debian/lenny
        Debian/testing
        Debian/experimental

Package Maintainer(s): Niko Mirthes <nmirthes@gmail.com>
                      Michael Larabel <michael@phoronix.com>
Status: *UNVERIFIED*
Fedora Packages:
        Fedora/FC3
        Fedora/FC4
        Fedora/FC5
        Fedora/FC6                                                                                                                        
        Fedora/F7                                                                                                                         
        Fedora/F8                                                                                                                         
        Fedora/F9                                                                                                                         
        Fedora/F10                                                                                                                        
        Fedora/RHEL3                                                                                                                      
        Fedora/RHEL4                                                                                                                      
                                                                                                                                          
Package Maintainer(s): Anssi Hannula <anssi@mageia.org>                                                                                   
Status: *UNVERIFIED*                                                                                                                      
Mageia Packages:                                                                                                                          
        Mageia/1                                                                                                                          
        Mageia/2                                                                                                                          
        Mageia/3                                                                                                                          
                                                                                                                                          
Package Maintainer(s): Dmitry Mikhirev <dmikhirev@mandriva.org>
Status: *UNVERIFIED*
Mandriva Packages:
        Mandriva/2007.0
        Mandriva/2007.1
        Mandriva/2008.0
        Mandriva/2008.1
        Mandriva/2009.0
        Mandriva/2009.1
        Mandriva/2010.0
        Mandriva/2010.1
        Mandriva/2010.2
        Mandriva/2011.0
        Mandriva/2012.0

Package Maintainer(s): AMD
Status: Verified
RedHat Packages:
        RedHat/RHEL5_64a
        RedHat/RHEL6_64a
        RedHat/RHEL5
        RedHat/RHEL6

Package Maintainer(s): Emanuele Tomasi <tomasi@cli.di.unipi.it>
Status: *UNVERIFIED*
Slackware Packages:
        Slackware/Slackware

Package Maintainer(s): Sebastian Siebert <freespacer@gmx.de>
Status: *UNVERIFIED*
SuSE Packages:
        SuSE/SLE10-IA32
        SuSE/SLE10-AMD64
        SuSE/SLE11-IA32
        SuSE/SLE11-AMD64
        SuSE/SUSE113-IA32
        SuSE/SUSE113-AMD64
        SuSE/SUSE114-IA32
        SuSE/SUSE114-AMD64
        SuSE/SUSE121-IA32
        SuSE/SUSE121-AMD64
        SuSE/SUSE122-IA32
        SuSE/SUSE122-AMD64
        SuSE/SUSE-autodetection

Package Maintainer(s): Mario Limonciello <superm1@gmail.com>
                      Aric Cyr <aric.cyr@gmail.com>
                      Alberto Milone <alberto.milone@canonical.com>
Status: *UNVERIFIED*
Ubuntu Packages:
        Ubuntu/Unable
        Ubuntu/to
        Ubuntu/install
        Ubuntu/sudo.
        Ubuntu/Please
        Ubuntu/manually
        Ubuntu/install
        Ubuntu/and
        Ubuntu/try
        Ubuntu/again.

Ist doch eine ganze Menge. Wenns dich wirklich interessiert kannst du dich ja mit dem Thema Autopaketerstellung beschäftigen. Da gibt es diverse Tools, die aus einem Quellcode + autotools ( ja ist blöd dass das so heißt: GNU Build System ) ein Paket für diverse Distributionen bauen können oder aus anderen schon vorhanden Distributionspaketen. Ich habe halt AMD genannt, weil ich dachte es sei bekannt.
Das seh ich ein ist off Topic. Allerdings ist der Post nur eine Antwort auf DSmons Frage.

 

[DSmon]

Interessant, ist mir neu. Trotzdem werden die Maintainer das wohl weiterhin selbst machen, einfach um Schmuh zu vermeiden.
Build Systems sind mir schon bekannt, nutze ja auch das ABS, trotzdem ist die von mir genutzte Distri nicht dabei. Viel würde ich es nicht nennen, sind immer hin nur 7.

GNU Build System
Womit wir wieder beim Aufwand wären.

 

[CryptonNite]

Das der ATI-Treiber spezifische Pakete generieren kann ist doch ein alter Hut. Der Vorteil ist halt, daß man den Treiber dann einfach über das Paketmanagement deinstallieren kann.

 

[Sandy93]

Und ob es AMD zu einem größeren Intel Konkurrenten macht. Die Konsolen werden (im Gegensatz zu diversen Desktop Chips) über etliche Jahre hinweg verkauft. AMD verdient somit längerfristig an diesen Deals.

Im Übrigen sind nun auch die "Mullins" und "Beema" APUs für kleine Notebooks und Tablets veröffentlicht worden.
Dort zeigt sich ein deutlicher Optimierungsprozess, der die Leistung drastisch erhöht, die Leistungsaufnahme gleichzeitig deutlich verringert hat.

Jetzt ist es an den Geräteherstellern, ordentliche Angebote mit diesen APUs zu bringen.

 

[Mick_Foley]

Die Konsolen werden (im Gegensatz zu diversen Desktop Chips) über etliche Jahre hinweg verkauft. AMD verdient somit längerfristig an diesen Deals.

Wobei die Einnahmen bei den Konsolen mit der Zeit sinken werden. Eine Konsole wird über die Jahre ja immer günstiger, also wird der Chip-Hersteller bestimmt nicht konstant die selbe Summe bekommen.