Test Jedi: Survivor unter Linux: Die Macht ist mit Linux, wenn auch nicht überall

[Pummeluff]

Bei Firmen ist es häufig so dass sich die Programmierer besser mit Linux auskennen als die Admins. Es sind die Admins die in den Firmen versuchen Windows only durchzudrücken. Sehr häufig gegen die Anwender und Fachabteilungen.

Ich arbeite als Linux-Admin und kann Deine Aussage so nicht unterstreichen.

Der Treiber für den Einsatz von Microsoft liegen vor allem in:

• Active Directory: Und da konkret die Group Policies, damit verbunden aber auch DHCP, DNS, NTP, Kerberos, LDAP.
• Exchange: Mittlerweile auch in der Verzahnung mit Teams
• Office

Und seit neuestem kommt dann noch die Azure-Klaut hinzu.

Das Problem dabei sehe ich eher im Fachanwender- und Entscheiderbereich, weniger bei den Admins. Die BWLer werden mit M$-Excel ausgebildet. Also erwarten Sie dann auch die Microsoftumgebung. Dadurch ist dann auch Outlook gesetzt, damit Teams, Sharepoint. Der Rattenschwanz zieht sich dann durch die ganze Infrastruktur

Das führt dann zuerst zu einer Mischumgebung. Über SSSD bekommt man auch Linux-Server mittlerweile ganz gut in die AD. Trotzdem kommt es z.B. beim automatischen AD-Maschinenpasswortwechsel immer wieder zu Problemen. Wenn der Chef das dann so will, werden auch die für M$-Server geltenden Sicherheitsrichtlinien auf die Linux-Server übertragen, obwohl das evtl. nur bedingt Sinn ergibt.

Im Endeffekt führt das dazu, dass in einer gemischten Umgebung die Linux-Server nach und nach verdrängt werden. So war das in meiner bisherigen Abteilung der Fall.

 

[fdsonne]

Treiber und Hardwareprobleme hast Du auch unter Windows. Es ist doch so wenn es unter Windows Probleme mit einer Hardware und dem Treiber gibt ist der Hersteller Schuld. Und bei Linux ist bei allem immer Linux schuld.

Um es mal mit deinen Worten zu sagen: "Ich denke Du verstehst nicht im Ansatz um was es wirklich geht."


Es klingt für mich als willst du Linux lobpreisen und es darf nichts drauf kommen...
Sorry, aber das ist leicht kindisch. Niemand gibt irgendwem eine Schuld. Man kann ganz ohne Schuldzuweisungen über auflaufende Problemstellungen sprechen. Im Artikel wird nach Erfahrungen der Community gefragt. Es ist also auch klar im Topic. Auch wenn dir das offenbar nicht schmeckt...

Hast Du Mal eine Liveinstallation einer anderen Distribution ausprobiert? Es kann auch an der Hardwareerkennung liegen.

Japp. Die damals neueste KDE Neon und Arch mit KDE Version. Ändert nichts am Resultat.

Vielleicht weil LTS Ubuntu in Kombination mit KDE eine schlechte Wahl ist

Eine Aussage, die ich sehr sehr häufig vernehme, wenn irgendwer von seinen Problemen mit Linux berichtet. Ihr macht es euch damit bisschen zu einfach. Nimm einfach was anderes ist exakt das, was man dann nicht braucht als Aussage.

Ich nutze KUbuntu seit nunmehr 14.04 und das funktioniert 1a in VMs. Also in klar definierten "Hardwareumgebungen". Mal davon ab ist die Anforderung schlicht gesetzt, wenn ich mit Debian/Ubuntu Systemen beruflich agiere, dass ich mir privat nichts anderes antun möchte. Und KDE nutze ich seit es existiert und möchte es ebenso nicht missen.

Beide haben sich entschieden die alte Installation zu bügeln und Windows 10 neu zu installieren. Das Betriebssystem war schnell drauf. Bis dann alle Updates drauf sind und die Anwendungssoftware installiert ist dauert es eine Weile. Die eine IT hatte das vollkommen automatisiert und dann waren das ca 3 h bei denen ich immer wieder einen Neustart auslösen durfte um die nächste Installationsrunde zu starten. Bei der anderen IT haben es die Admins gemacht.

Dann haben die halt ihren Job nicht richtig gemacht?
Ein Firmenbook bei uns bekommt das Image in nichtmal ner halben Stunde draufgebügelt. Inkl. aller Software, Treiber und Settings. In einer Mittagspause ist so ein Job erledigt und der User kann weiter arbeiten.

"Bis dann alle Updates drauf sind und die Anwendungssoftware installiert ist dauert es eine Weile." -> bestätigt das übrigens auch. Das Baseimage impft man mit dem jeweils neuen Updates, damit man exakt das eben NICHT danach machen muss. Treiber und Co. werden während des Deployments unattended installiert und Software, die nicht im Image enthalten ist, verteilt üblicherweise eine Softwareverteillösung, eine GPO oder man scriptet das.




Ich spar mir mal das eingehen auf alle Aussagen, da du irgendwie gefühlt recht aggressiv dienen pro Linux Standpunkt vertrittst. Anstatt über die Dinge zu reden kommen Aussagen wie, "vielleicht was falsch war" oder "Windows ist doof"
Btw. versteh mich bitte nicht falsch. Ich bin weder pro Windows noch Kontra Linux. Ich bin beruflich Server Betreiber von u.A. Windows UND! Linux Servern in hohen dreistelligen Anzahlen. Nebenbei bin ich in der Pentesting Schiene unterwegs und entwickle auf Anforderung Automatisierungslösungen (aktuell per Ansible). Das ist mehr Linux als die meisten User hier vorweisen können. Vielleicht auch mehr als du es kannst Es gibt absolut keinen Grund mir hier mit so ner komischen Art und Weise ans Bein zu pieseln, als würde ich dein gelobpreistes Linux irgendwo schlecht machen. Ganz im Gegenteil. Ich weis sehr genau um die Vor- und Nachteile beider Welten. Und das nicht nur auf Anwenderseite, sondern vor allem auch auf Betreiberseite.
Was dieses komische Argument, Windows wäre nie Problemfrei, sein soll, erschließt sich mir nicht. Niemand behauptet das?? Also zumindest seh ich davon nix... Wieso sollen die Linux Dinge aber nicht benannt werden dürfen? Das Vorhandensein von irgendwelchen Microsoft Problemen verbietet das in keinster Weise.

Ich arbeite als Linux-Admin und kann Deine Aussage so nicht unterstreichen.

Der Treiber für den Einsatz von Microsoft liegen vor allem in:

• Active Directory: Und da konkret die Group Policies, damit verbunden aber auch DHCP, DNS, NTP, Kerberos, LDAP.
• Exchange: Mittlerweile auch in der Verzahnung mit Teams
• Office

Und seit neuestem kommt dann noch die Azure-Klaut hinzu.

Nicht nur das, das geht noch viel weiter. Da die MS Welt weitestgehend intern auf dem AD respektive dem Entra ID (ehemals Azure AD) basiert, hat es eine gemeinsame IDM Lösung für die gesamte Infrastruktur. Die Masse der Drittanbieter Software im Enterprisebereich koppelt sich da einfach an und nutzt die Synergieeffekte, das ist der quasi Standard.

Die Aussage, die Admin drücken das durch, kann ich allerdings durchaus nachvollziehen. Der Anwender versteht selten die Hintergründe warum eine Sache ggü. einer anderen nicht gewählt wird, wenn er die abgewählte aber präferiert. Ist aber in der heutigen Zeit absolut gar kein Problem - wir haben nen massiven Fachkräftemangel in Deutschland. Jeder Anwender ist eingeladen sich der IT Abteilung anzuschließen und mit konstruktiven Vorschlägen und Einsatz mit anzupacken. Ich bin mir zu 100% sicher, das würde nicht abgewiesen werden. Allerdings gehört dann eben auch dazu, die gesamte Anforderungsseite zu beachten und nicht nur "ich will aber Linux weil is so", während sich dann alle Welt verbiegen muss für diese eine Sonderlocke.

Zuhause arbeiten immer alle umsonst mit ihrem privaten Kram. In der Business IT funktioniert das aber nicht. Jeder Schalter, der unnötig umgelegt werden muss, kostet Geld. Und davon gibt es bei Custom Lösungen in aller Regel seeeehr viele

 

[dev/random]

Im übrigen ist diese "Debian Stabilitäts Denke" komplett an der Open Source Philosophie vorbei. Alle erfolgreichen Open Source Projekte setzen auf Unit Tests und Continuous Integration.

Da verstehst Du mich falsch. Und Open Source ist auch nicht das gleiche wie Continuous Deployment.
Ich halte Debian nicht deshalb für stabiler, weil sie nur alle paar Jahre ältere Software releasen. Sondern weil Debians Entwicklungs- und Testinfrastruktur deutlich umfangreichere Tests ermöglicht. Es gibt nicht nur CI sondern automatisierte Builds, Tests und Release workflows für alle Pakete, Architekturen und Releases, die Paket-Abhängigkeiten berücksichtigen und auch automatisierte Testen von Installationen und Upgrades ermöglichen (Beispielrefrenzen: buildd Kurzinfo, Release workflow).
Dadurch können mehr Fehler erkannt werden bevor diese bei Benutzern auftreten, zumindest im Vergleich zum "partial upgrades unsuported" Ansatz von arch.

Wer also möglichst wenig Aufwand mit Systemadministration haben möchte und nicht die neuesten Spiele spielen will, wird mit Debian vielleicht glücklicher als mit arch. Wer sich hingegen in die neusten Spiele stürzen will kommt um etwas mehr Aufwand mit einem rolling release oder Windows Grafiktreibern nicht herum 😀

 

[satansbraten330]

Gegen einen ergebnisoffenen Test spricht wenig, sei es in VMs oder gleich auf irgendeine SSD. Die Leute im Linux-Unterforum hier sind kompetent und einigermaßen geduldig, Hilfestellungen wirst du sicher bekommen.
Es ist keine Magie, sondern einfach nur anders.
Wirklich relevant für Umsteiger, abseits von special interest, sind nur wenige etablierte Distributionen. Alles andere ergibt sich imo von selbst und hängt von deinen eigenen Prioritäten ab.


Meine Prognose ist, es wird kein SteamOS für PC von Valve geben, das OS ist spezifisch für deren Geräte.
Steam gibts auf Desktops und auch alle Tools die Valve kombiniert hat. Plus noch wesentlich mehr, weil die Open Source Community sehr aktiv ist.

Wenn du mit Windows oder anderen „fertigen“ Lösungen glücklicher bist, auch okay. Missionieren werde ich nicht.

Dito.
Wozu sollte es das auch brauchen? Ubuntu, ZorinOS, Mont, oder Manjaro, funktioniert alles out of the box mit Steam und den Spielen dort.
Wenn man dann noch mehr braucht stehen Lutris oder diverse andere Spiele-Clients zur Verfügung (lutris geht ja glaube ich auf dem steam deck auch, hab ich aber noch nie gebraucht).

Von daher ware es für Steam Ressourcen Verschwendung ein (weiteres) DesktopOS auf den Markt zu werfen.

 

[ETI1120]

Von daher ware es für Steam Ressourcen Verschwendung ein (weiteres) DesktopOS auf den Markt zu werfen.

Ich würde sogar sagen es wäre kontraproduktiv.

 

[ETI1120]

Da verstehst Du mich falsch.

Ich denke wir verstehen uns ganz gut, reden aber mit der Wortwahl aneinander vorbei.

Also will ich kurz meine Weltsicht mit anderen Bezeichnungen skizzieren

Rolling Distributions mit Arch als Idealbild würde ich mit als kontinuierliche Änderung beschreiben. Diese Distributionen sind heute anders als gestern und morgen anders als heute. Das hört sich schlimmer an als es tatsächlich ist. Erstens gibt es automatisierte Tests und zweitens kann man sich durch die Wahl der Distribution bzw. des Branch sehr gut aussuchen wie dynamisch. bzw. wie gut getest man es will.

Debian ist das andere Extrem. Die releasebasierten Distributionen bilden den klassischen Softwareprozess nach. Hier wird von Zeit zu Zeit ein Relase veröffentlicht wird was einen größeren oder kleineren Versionssprung bewirkt. Alleine schon wie man eine Software released ist eine Wissenschaft an sich. Hierfür gibt zig Philosophien. Wie häufig veröffentlicht man neue Releases, unterscheidet man zwischen Major und Minor Release, ... Vor allem der Umgang mit Bugfixes unterscheidet sich massiv. Zwischen-Release vs Patch.

Als Linux aus der akademischen Szene ausgebochen ist, die es im Sturm erobert hatte, hat sich bald gezeigt, dass die vielen Kernel-Releases für einige Anwender ein Hindernis darstellen. Also also wurden die Kernel-Relases mit Long Term Support geschaffen.

Debian ist durch den großen zeitlichen Abstand der Releases per se LTS. Debian hat sich für eine quasi-statische Herangehensweise entschieden. Also keine Änderungen zwischen den Releases und einen großen Abstand zwischen den Releases.

Was man nie oft genug wiederholen kann ist, dass jede einzelne Distribution weit mehr Software zur Verfügung stellt als es Microsoft mit Windows bringt. D. h. es geht nicht nur um Betriebssystemkern, Systembibliotheken, Treiber, die Grafischen Oberflächen samt Desktop und Bibliothken. Es geht auch um sehr viel Anwendungspakete und Spiele die alle ihren eigenen Release-Zyklus haben. Wenn man es vereinfacht ausdrücken will: Es geht bei den einzelnen Distributionen darum

• wie sie Linux einpacken, (grafische Oberfäche + Desktop)
• welche Software sie mitliefern,
• wie sie den Anwendern Zugriff auf diese Software geben und
• wie sie damit umgehen dass sich alles (Betriebssystem, Bibliotheken und Anwendunssoftwar) stetig ändert.

Und Open Source ist auch nicht das gleiche wie Continuous Deployment.

Nein ist es nicht. Aber jedes großes Open Source projekt an dem sich viele Leute beteiligen hat Nightly Builds. Open Source mit vielen beteiligten funktioniert nur durch eine umfassende Buildt- und Testinfrastruktur.

Bei einer OnePerson Show ist das nicht notwendig. Hier genügt rigoroses UnitTesting.

Wer also möglichst wenig Aufwand mit Systemadministration haben möchte und nicht die neuesten Spiele spielen will, wird mit Debian vielleicht glücklicher als mit arch. Wer sich hingegen in die neusten Spiele stürzen will kommt um etwas mehr Aufwand mit einem rolling release oder Windows Grafiktreibern nicht herum 😀

Bei einer Kiste, die nicht am Internet hängt, ist Debian draufhauen und sich dann nicht mehr ums Betriebssystem zu kümmern eine richtig gute Option.

Aber leider werden immer wieder Lecks gefunden die eine Software angreifbar machen und die durch einen Bugfix behoben werden muss. Natürlich kann ich die Bugfixes ignorieren. Aber ist es wenn die Kiste am Internet hängt wirklich eine gute Option? Also müssen die Bugfixes installiert werden.

Meine Ansicht ist, dass für den normalen Anwender Rolling Releases die bessere Option sind, weil es irgend wann unweigerlich zu einem Update kommt. Ich hatte 2015 eigentlich keine andere Wahl als ein Rolling Relase zu wählen weil ich nicht die Lust hatte erst meine Kiste aufzusetzen und mich ein halbes Jahr später um ein großes Update (KDE 5) zu kümmern.

Das schöne an Linux ist, dass man die Wahl hat. Es gibt bei allem Pros und Contras, die muss man abwägen. Und da je nach Anforderungsprofil die Gewichte anders sind, kommen unterschiedliche Entscheidungen raus. Es geht alleine darum bei diesen Pro und Contras offen und ehrlich zu sein und richtig zu gewichten.

Wer an einem PC sitzt muss sich auf die Technik einlassen oder jemanden haben der dies erledigt. Wenn dies nicht gegeben ist, sind Mac, Tablet bzw. Spielkonsole, je nach dem was man am Computer machen will, die bessere Option.

Was ich bei der Post, auf Du geantwortest hast, noch nicht gesehen habe ist der Fall eines Servers der fertig konfiguriert ruhig und unauffällig über viele Jahre hinweg seinen Dienst verrichtet. Und wenn ich diesen Server nie updaten will ist die Herangehensweise von Debian ideal.

 

[ETI1120]

Ich arbeite als Linux-Admin und kann Deine Aussage so nicht unterstreichen.

Ich habe eine andere Perspektive als Du, ich bin Anwender ich sehe es von außen und Du von Ihnen. Wenn ich Admins schreibe meine ich die Admins und die IT-Abteilungen.

Als Linux-Admin bist Du eine kleine Minderheit. Die meisten Admins sind mit Dos und Windows großgeworden.

Im Rahmen eines Projkets hatte ich im Jahr 2000 mit dem stellvertrenden IT-Leiters eines deutschen Maschinenbauers zu tun. Er hat ganz stolz erzählt dass er in seiner IT nur eine Datenbank und nur noch zwei Betriebssysteme hat. Es war doch klar, dass in dem Moment als eine Anwendungssoftware, die bisher nur auf Unix lief auch für Windows vorhanden war, auf Windows gewechselt wurde.

IMO ist das Bestreben eine einheitliche IT-Landschaft zu haben, das was bei den großen Konzernen dazu führt dass die fast ausschließlich mit Windows arbeiten. Ausnahmen werden nur geduldet solange es mit Windows nicht geht.

Der Treiber für den Einsatz von Microsoft liegen vor allem in:

• Active Directory: Und da konkret die Group Policies, damit verbunden aber auch DHCP, DNS, NTP, Kerberos, LDAP.
• Exchange: Mittlerweile auch in der Verzahnung mit Teams
• Office

Und seit neuestem kommt dann noch die Azure-Klaut hinzu.

Da hast Du sehr viel mehr Ahnung als ich und ich werde Dir da nicht wiedersprechen. Aber Du selbst sagst Treiber. In den späten 2000er Jahren war es SharePoint. Ich stelle allerdings fest dass ich fast nichts mehr von SharePoint höre und mitbekomme.

Das Problem dabei sehe ich eher im Fachanwender- und Entscheiderbereich, weniger bei den Admins. Die BWLer werden mit M$-Excel ausgebildet. Also erwarten Sie dann auch die Microsoftumgebung. Dadurch ist dann auch Outlook gesetzt, damit Teams, Sharepoint. Der Rattenschwanz zieht sich dann durch die ganze Infrastruktur

Es gibt den sau dummen Spruch dass alle Word und Excel können. Wenn man genau hinschaut, können es die wenigstens. Aber mit einem anderen Office kämen die Anwender eben noch viel weniger zurecht.

Eine Annektode: Wir hatten eigentlich intern alles auf OpenOffice umgestellt. An einem Wochenende wollte unser Chef ein Dokument schreiben und für ihn war OpenOffice fremd und etwas hat nicht geklappt. Wutentbrand hat er am Montag angeordnet, wieder auf MSOffice zu wechseln.

Bei MS Office gibt es einen weiteren Aspekt. Die Unternehmen haben Unsummen in die VBA-Programmierung von MS Office versenkt. Ein Umstieg ist wegen des Aufwands alles anzupassen unmöglich. Auf der anderen Seite ist es eben fraglich, ob es sinnvoll ist viel in der Anwendungssoftware zu programmieren. Dies macht jede Umstellung der auf eine neue Version der Anwendung aufwändig und teuer.

Meine Sicht ist: Microsoft ist kurzfristig immer die billigere Lösung. Also wählen die Unternehmen diese billige Lösung. Langfristig machen sich die Unternehmen immer weiter von Microsoft abhängig. Microsoft weiß allerdings auch ganz gut wie teuer sie sein dürfen.

Für IT-Leiter gilt, es wurde noch nie jemand entlassen weil er sich für eine Lösung von Microsoft entschieden hat. Wenn man eine Alternative wählt und etwas schief geht (es muss nicht Mal mit der Alternative zu tun haben) kommt man sofort in Erklärungsnot.

Ein andere Aspekt ist, dass Microsoft neue Produkte leicht und einfach zugänglich macht und über die Preise erst dann redet wenn sich das ganze etabliert hat. Aber auch hier gilt, Microsoft ist nicht gierig.

Microsoft ist das am besten geführte Softwareunternehmen. Nur Steve Ballmer war eine Pfeife.
Microsoft haben immer drei Dinge ausgezeichnet:

• Gutes Gespür was die Anwender wollen. Aber eben kein untrügliches wie die Oberfläche von Windows zeigt.
• Gutes Gespür was technisch Umsetzbar ist.
• Gutes Gespür für Entwicklungen die für Microsoft auf Dauer bedrohlich sind.

Dass Microsoft auf dem Mobilphone-Markt so vollkommen versagt hat, schreibe ich vor allem Steve Ballmer zu.

 

[ETI1120]

Um auch ein bisschen was zur Sache beizutragen, eine sau blöde Frage:

Kann sich ein RealTimeKernel auf die FrameTimes auswirken?



Ich finde es gut dass Valve Bewegung in die Sache gebracht hat. Sie machen es allerdings nicht uneigennützig. Valve hat erheblich mehr Kontrolle über ihr Produkt als Asus. Ich bin davon überzeugt dass es sich auszahlen wird.

Der Steam Client war ein wichtiger Grund warum ich Manjaro gewählt habe. Aber ich muss zugeben dass ich ihn nie angeworfen habe. Die Games, die ich in der Distro gefunden habe, haben mir genügt.



Meiner Erfahrung nach kann man mit Linux nur dann zurechtkommen, wenn man folgendes beachtet:

• Man sucht sich Hardware aus die von Linux unterstützt wird. Eigentlich bedeutet dies unterstützt der Hersteller Linux durch bereitstellen von Treibern bzw. durch Einhalten von Hardwarestandards.
  PC-Standardhardware ist heute kein Problem mehr. Probleme machen aber neue Hardwaretypen, Spezialhardware, Notebooks und viele Ultrakompakt-PCs. Bei Notebooks war es vor Jahren schier unmöglich Linux zu verwenden. Das ist besser geworden, aber man sollte sich vorher versichern das Linux läuft.
• Es gibt so gut wie keine kommerzielle Desktopanwendungen. Das ist für Firmendesktops ein Ausschlusskriterium, muss es aber für Privatanwender nicht sein. Es gibt ein riesiges Softwareangebot aus OpenSource, das bietet in vielen Fällen Alternativen. aber nicht in allen.
• Linux ist nicht Windows. Wenn Window-Anwender Linux anschauen, dann müssen sie sich auf etwas neues einlassen. Sie werden etwas Neues lernen müssen.
• Die Idee dass man einen PC betreiben kann ohne sich um Betriebssystem und Hardware zu kümmern ist eine Illusion. Das gilt für Linux und für Windows. Entweder kümmert man sich selbst oder überlässt es jemanden anders. Mit Linux hat man aber andere Probleme als mit Windows.

Wenn man die Einschränkungen an Hard- und Software nicht akzeptieren kann oder will und nicht wirklich offen an die Sache heran geht wird man unweigerlich feststellen dass Linux nicht passt.

 

[Pummeluff]

Kann sich ein RealTimeKernel auf die FrameTimes auswirken?

Ich glaub, der alte Post erklärt's ziemlich gut.

RT-Kernel setzt du im Embedded-Bereich, bei Audio-Produktionen, zur Anlagensteuerung und überall da ein, wo du eine exakte Zeitgebung im hochgranularen Bereich benötigst.

Ist jetzt nur ein Schuss ins Blaue: Ich würde davon ausgehen, dass ein RT-Kernel durchaus Auswirkungen auf die Frametimes haben kann - und zwar dahingehend, dass die runter gehen bzw. du sogar Aussetzer haben könntest.

Probleme machen aber neue Hardwaretypen,

Echt?

Probleme macht eigentlich fast immer nur billige Schrotthardware, bei denen fehlende Hardwarefunktionalität über den (Windows-)Treiber kompensiert wird.

Ich hatte z.B. mal vor vielen Jahren eine Maus, bei denen die Buttons 5,6 und 7 über die Kombination der anderen Buttons realisiert wurde (1+3, 2+3, 1+2). Das war Schrott. Ich hab damals dann die für den Maustreiber im Linux-Kernel verantwortlichen Entwickler angeschrieben. Die hätten eine Treibererweiterung dafür entwickelt. Allerdings hätte ich da so eine Billigmaus um die Welt schicken müssen. Das war's mir nicht wert.

Bei Notebooks war es vor Jahren schier unmöglich Linux zu verwenden.

Echt? Mein erstes Notebook mit Linux hatte ich 2006. Das lief eigentlich ganz gut.

Es gibt so gut wie keine kommerzielle Desktopanwendungen. Das ist für Firmendesktops ein Ausschlusskriterium,

Auch das ist nicht ganz korrekt. Es gibt haufenweise Spezialsoftware, die es eigentlich nur für Linux gibt. In der Uni hatte ich mal den Auftrag, eine Schaltkreissimulationssoftware zu installieren. War damals auf Scientific Linux.

Wenn man die Einschränkungen an Hard- und Software nicht akzeptieren kann oder will

Trifft bei mir zu. Deswegen verwende ich kein Windows.

 

[dev/random]

Kann sich ein RealTimeKernel auf die FrameTimes auswirken?

So allgemein gefragt ist die Antwort ja
Allerdings stimme @Pummeluff zu, dass die Auswirkungen eher negativ sein würden. Der weiter oben verlinkte Phoronix-Artikel steuert dazu einige Zahlen bei.

Ich glaube dass Gamemode wesentlich relevanter ist, wenn es um Frametimes geht.
Wäre mal interessant, die Spiele-Performance ohne Gamemode / mit Gamemode / mit Gamemode und renice zu vergleichen.

 

[ETI1120]

Ich wollte aus der unproduktiven Debatte Linux vs Windows etwas positives ziehen. Deshalb versucht kompakt zusammenzuschreiben was die Hürden bei einem Umstieg von Windows zu Linux sein können.

Es ist meine Überzeugung, dass man besser damit zurecht kommt, wenn man weiß was auf einen zukommt. Und vier konkrete Punkte finde ich besser, als die Wolke die herumschwebt.

Der wirklich kritische Punkt ist die Bereitschaft sich auf etwas Neues einzulassen. Wer also erwartet dass alles so ist wie bei Windows und alles was anders funktioniert grundsätzlich für schlecht empfindet, verschwendet nur Zeit. Ich habe Mal erlebt wie ein paar Windows DAUs einen Mac-Admin in die Verzweiflung und beinahe zu Tränen getrieben haben. Alle geduldigen Erklärungen und Hilfen wurden in den Wind geschlagen. Alles was beim Mac nicht so wie bei den Windowskisten funktioniert hat, war schlecht. Auch dass die Macs über die Tastatur gestartet werden konnte.

Auf der anderen Seite werden alle, die sich auf die Reise begeben etwas lernen. Also als Folge davon auch Windows besser verstehen.

Probleme macht eigentlich fast immer nur billige Schrotthardware, bei denen fehlende Hardwarefunktionalität über den (Windows-)Treiber kompensiert wird.

Damit meine ich wenn eine neue Hardwareklasse entsteht, die massive Treibererweiterungen oder von Grund auf neue Treiber benötigt.
Wenn die Hersteller in einem solchen Fall nicht von vorne herein Linux unterstützen und erst die Kommunity mit der Treiberentwicklung startet, dann gibt es eine Verzögerung.

Dieser Fall ist inzwischen sehr selten.

Standardhardware wie Grafikkarten funktioniert oft sofort beim Launch. Als ich meine aktuelle Kiste zusammengestellt habe kam gerade die RX5500 raus, alles hat problemlos funktioniert.

Bei einem Desktop PC mit Standardkomponenten ist Linux problemlos. Aber in anderen Fällen können Probleme auftreten .Z. B. bei Notebooks und Kompakt-PCs, die Notebook-Komponenten verwenden. AFAIK ist die Treiberunterstützung bei Notebookkomponenten schlechter als bei Desktopkomponenten.

Und wenn die passenden Treiber nicht existieren, verschwinden die Probleme nicht mit zwei Klicks oder einem Zauberspruch. Dann muss sich jemand hinsetzen herauskriegen was klemmt und einen bestehenden Treiber erweitern oder einen neuen schreiben. Also den Job des Herstellers erledigen.

Ich hatte z.B. mal vor vielen Jahren eine Maus, bei denen die Buttons 5,6 und 7 über die Kombination der anderen Buttons realisiert wurde (1+3, 2+3, 1+2). Das war Schrott. Ich hab damals dann die für den Maustreiber im Linux-Kernel verantwortlichen Entwickler angeschrieben. Die hätten eine Treibererweiterung dafür entwickelt. Allerdings hätte ich da so eine Billigmaus um die Welt schicken müssen. Das war's mir nicht wert.

Ich versuche im Vorfeld rauszubekommen wie es mit Linux aussieht. Es hat eigentlich immer ganz gut geklappt. Es ist ein bisschen mehr Aufwand als bei Windows. Aber es schadet nie vor dem Geld auszugeben ein bisschen länger nachzudenken. Einerseits kauft man besser, andererseits erspart man sich oft Regalware zu kaufen.

Echt? Mein erstes Notebook mit Linux hatte ich 2006. Das lief eigentlich ganz gut.

Das hast Du sicher blind im Laden gekauft und dann Linux drauf gespielt. Stimmts?

Es gab bei einigen Herstellern immer einige Notebooks bei denen Linux gut lief. Aber bei der Masse der Notebooks war es eben problematisch.

Es hat schon einen Grund warum sich z. B. Tuxedo und System 76 etabliert haben. Die hätten sich IMO nicht etabliert wenn der Linux-Support der großen OEMs gut gewesen wäre.

Auch das ist nicht ganz korrekt. Es gibt haufenweise Spezialsoftware, die es eigentlich nur für Linux gibt. In der Uni hatte ich mal den Auftrag, eine Schaltkreissimulationssoftware zu installieren. War damals auf Scientific Linux.

Ich finde es witzig, dass Du mir das um die Ohren haust.

Wer diese Software benötigt verwendet Linux und nicht Windows. Diese Leute müssen also Linux nicht ausprobieren. Richtig?

Auf der anderen Seite weißt Du auch ganz gut wie langfristig der Hase läuft. Du hast Dich ja in einem anderen Post beklagt.

Trifft bei mir zu. Deswegen verwende ich kein Windows.

Ich wollte auf Linux wechseln weil ich gerne gegen den Strom schwimme. Ich bin Anwender und niemand der tief im System herumwühlt und bin auch kein Softwareentwickler. Meine Überzeugung ist dass Monokulturen langfristig schlecht sind. Deshalb habe ich auch immer AMD-Produkte gekauft, wenn sie in mein Anforderungsprofil gepasst haben.

Und als ich mein Linuxsystem am Laufen hatte, habe ich festgestellt, dass das was mir wichtig ist bei Linux besser als bei Windows funktioniert. Das ist meine Erfahrung, andere können eine andere Erfahrung haben.

 

[ETI1120]

So allgemein gefragt ist die Antwort ja

Es war auch eher ein dezenter Hinweis, ob es sich nicht lohnt zu schauen.
Bei Arch sollte es doch relativ einfach gehen, den kernel auszutauschen.

Vielleicht könnte man sehen ob das Problem eher in der Kommunikation zwischen CPU und GPU liegt oder eher in der GPU (Treiber).

Allerdings stimme @Pummeluff zu, dass die Auswirkungen eher negativ sein würden. Der weiter oben verlinkte Phoronix-Artikel steuert dazu einige Zahlen bei.

Danke für den Hinweis, den hatte ich übersehen.

Die Gamingperformance des RealTime Kernels schwankt in diesem Test massiv. 3 Mal die besten Frames 1 Mal die 2. schlechtesten und 1 Mal die schlechtesten.

Über alles liegt der Real Time Kernel hauptsächlich wegen der ganz schlechten Performance bei einigen Stresstests so weit hinten, was den von @Pummeluff verlinkten Post bestätigt.

 

[dev/random]

Bei einem Desktop PC mit Standardkomponenten ist Linux problemlos. Aber in anderen Fällen können Probleme auftreten .Z. B. bei Notebooks und Kompakt-PCs, die Notebook-Komponenten verwenden. AFAIK ist die Treiberunterstützung bei Notebookkomponenten schlechter als bei Desktopkomponenten.

Das stimmt nicht mit meiner Erfahrung überein, hatte in den letzten 15 Jahren keine Notebooktreiberprobleme mit Linux. Es macht aber keinen Sinn, diese offtopic Unterhaltung fortzusetzen, da eigene Erfahrungen nur beschränkt aussagekräfitg sind und man diese nicht verallgemeinern sollte.

Das hast Du sicher blind im Laden gekauft und dann Linux drauf gespielt. Stimmts?

Abgesehen davon dass ich nichts blind kaufe, achte ich bei Notebooks nicht speziell auf Linux oder Windows Kompatibilität.

Es gab bei einigen Herstellern immer einige Notebooks bei denen Linux gut lief. Aber bei der Masse der Notebooks war es eben problematisch.

Es gibt immer auch problematische Hardware, aber das ist nicht nur Linux-spezifisch. Zum Beispiel schreibe ich das hier gerade auf einen Lenovo Notebook das unter Linux einwandfrei unterstütz wird inkl. Sondertasten, Touchpad, Touchscreen, Kamera, WiFi, BT. Aber unter Windows 10/11 kann ich keine AMD Grafiktreiber installlieren, da nur Lenovo-eigene Treiber für die APU akzeptiert werden - und die werden seit zwei Jahren nicht mehr aktualisiert.

 

[Kaito Kariheddo]

Artikel-Update: Der Artikel wurde um Benchmarks eines AMD Ryzen 9 7900 mit 105 Watt Config-TDP und Radeon RX 6700 XT unter Windows ergänzt. Das entspricht der Konfiguration, die für die Linux-Benchmarks Verwendung fand. Die zusätzlichen Ergebnisse unter Windows zeigen, dass in der Tat die Plattform und nicht der Wechsel vom 7950X3D in den Standard-Windows-Benchmarks auf den 7900 in den Linux-Benchmarks für die deutlich schlechteren Frametimes unter Linux verantwortlich war.

 

[Mimir]

Danke für das Update.

Das zeigt also, dass Linux oder der Linux Grafiktreiber von AMD, GPU Seitig etwas mehr Performance rauskitzelt, da höhere AVG FPS im GPU Limit, jedoch gibt es (vermutlich mit dem CPU seitigen Code) große Probleme mit den Frametimes.

Wäre schöner, wenns umgekehrt wäre.

Wenn man die Frametimes mal in den Griff bekommt, und die 1% lows da sind wo sie sein sollen, dann werden auch die AVG FPS nochmal ein wenig ansteigen.

Das zeigt aber auch, dass es sowohl auf Linux als auch Windows noch ungenutztes Potenzial gibt.

 

[polyphase]

Super, danke für das Update 👍

Interessant wären jetzt noch die Ergebnisse mit dem 7900X3D unter Linux, um zu sehen wie sich der V-Cache hier verhält 🤔

Gibt's eigentlich einen Grund für den Zen Kernel?
Meines Wissens bietet der keinen Vorteil mehr gegenüber dem normalen Kernel 😅

 

[pacifico]

Ob das Spiel nun unter Windows oder Linux besser läuft ist doch nebensächlich, es ist und bleibt ein 100% 0815 Konsolenspiel. Alles auf dümmliche Joypad Spieler ausgelegt

Das ist interessant.

Dir fehlen die Skillz um das Game mit deiner Maus und Tastatur zu spielen?

-> Echte Mastor Roxxor Racer von deinem Schlag können alles mit Maus und Tastatur spielen.

Dümmlich ist in erster Linie dein altmodischer Kommentar.

Wir haben 2023 und nicht 1999...

 

[Kaito Kariheddo]

Gibt's eigentlich einen Grund für den Zen Kernel?

Einfach ausgedrückt:
Der normale Linux Kernel versucht die ihm zugewiesene Aufgabe schnellstmöglich auszuführen, also in dem Fall das Spiel. Andere Anwendungen welche im Hintergrund laufen wie beispielsweise Browser, OBS usw müssen hinten anstehen. Da konnte es schon mal sein, dass wenn man auf dem zweiten Monitor ein Video laufen hatte während man gespielt hat, das Video entsprechend geruckelt hat
Beim Zen-Kernel bekommen alle was vom Kuchen. Der Browser will Prozessorzeit ? Kriegt er. Dem Spiel macht das nicht wirklcih was aus, aber das Video läuft dann flüssig.

 

[polyphase]

Ah ok,

Ich hatte damals das Gefühl, das die Games mitm normalen Kernel flüssiger laufen.
Seit dem 6er Kernel nutze ich daher den Zen nicht mehr.

Da ich aber auch während dem Spielen keine Videos schaue, ist das nicht so schlimm, wenn andere Programme weniger Rechenzeit abbekommen 😅

 

[Ranayna]

Da konnte es schon mal sein, dass wenn man auf dem zweiten Monitor ein Video laufen hatte während man gespielt hat, das Video entsprechend geruckelt hat

Da muss ich ja sagen, das ich in dem Bereich mit Stock Manjaro (Kernelversionen 5.irgendwas bis 6.2) ueberhaupt keine Probleme mit sowas hatte.
Egal ob Youtube, Netflix oder ein Video von der Platte, geruckelt hat da nie was beim nebenbei Zocken.

Ich finde solche Benchmarks wie diesen sehr gut. Ich hoffe das es sowas auch fuer weitere Spiele geben wird, oder vielleicht sogar direkt in mehr generelle Spielebenchmarks einfliessen wird.