Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Hardware für Linux
- Ersteller JuarX
- Erstellt am
kernel panic
Lt. Commander
- Registriert
- Jan. 2010
- Beiträge
- 2.024
Du musst auf nichts achten, es ist allerdings ratsamer eine Graka von Nvidia zu benutzen (bessere Treiber), falls du überhaupt vor hast eine zu nutzen.
Falls du planst Steam für Linuxzu testen, dann ist NV wirklich die bessere Wahl, ansonsten werden die üblichen Chipsätze und CPUs unterstützt. Nur bei zB TV Karten sollte man sich vorher erkundigen. Aber man findet im Internet schnell immer Listen.
puffisworld
Commodore
- Registriert
- Juni 2005
- Beiträge
- 4.316
Es kommt ja auch darauf an, was du mit Linux vor hast?
Grafikkarte kommt mit grosser Wahrscheinlichkeit nicht rein, da der PC nicht zum Spielen verwendet wird. Die zwei Drucker die ich habe sollten eigentlich kein Problem sein. SSD kommt auch nicht rein. Irgendwelche TV-Karten werden auch nicht verbaut.
Vielen Dank für eure Auskunft.
Vielen Dank für eure Auskunft.
Fruchtnektar
Lieutenant
- Registriert
- Okt. 2003
- Beiträge
- 942
Daaron schrieb:...
Was wirklich zu beachten ist: Bei SSDs verhält sich Linux nicht so elegant wie Win7. TRIM ist dort komplett anders gelöst und erfordert etwas Beachtung.
Hi, in wie fern? Das widerspricht so ziemlich allem was ich bisher gelesen habe und selbst erlebt habe. TRIM muss in der fstab explizit aktiviert werden, aber ansonsten verhält es sich absolut wie unter Windows, da die Aktionen in der Hardware umgesetzt werden und absolut transparent für das OS erfolgen. Um direkten Zugriff darauf zu erhalten muss man (wie auch unter Windows) Herstellertools einsetzen.
Ich gehe jetzt nicht auf die Verschlüsselung ein, da hier andere Dinge gelten (könnten - eben aufgrund der OS-Transparenz) - unter Windows und Linux.
@Topic: Standardhardware funktioniert gut. Intel CPUs und GPUs sind in der Kombination am problemlosesten. AMDs GPUs und IGPs sind da bezüglich der Treibersituation der proprietären Treiber schlechter. Aktuell unterstützt der Catalyst nur Xorg 1.13 und nicht die aktuelle Version 1.14. Aber solltest du Ubuntu und Co nutzen sollten die Probleme recht gering sein.
Zuletzt bearbeitet:
Fruchtnektar schrieb:TRIM muss in der fstab explizit aktiviert werden,
Ist das tatsächlich so? Auch bei einer aktuellen, einsteigerfreundlichen Distribution? Wenn Otto-Normalverbraucher jetzt also Ubuntu 12.10 auf seiner SSD installieren will, muss er erst in der fstab frickeln, damit TRIM aktiviert wird?
Fruchtnektar
Lieutenant
- Registriert
- Okt. 2003
- Beiträge
- 942
Also wenn ich gerade so auf die Ubuntu-Wiki-Seite sehe: da muss man manuell ran um es zu aktivieren - ich gehe mal davon aus, dass es damit zumindest auf alle Debian-Distris zutrifft.
OpenSuse habe ich mir jetzt nicht angesehen. Auch nicht RedHat/CentOS - wobei ich hier davon aussgehe, dass es wenn nur manuell unterstützt wird (keine Ahnung ab wann Trim im Kernel war und wann falls überhaupt nötig ein Backport aus neueren Kernel erfolgte).
Definitiv muss es manuell unter Arch und Gentoo aktiviert werden.
Ich sehe auch gerade, dass meine Methode (fstab) dort wohl in einigen Fällen zu Problemen führen kann und ein Aufruf per Cron-Job empfohlen wird - das muss ich mir mal ansehen (warum Cron und warum fstab nicht gut).
OpenSuse habe ich mir jetzt nicht angesehen. Auch nicht RedHat/CentOS - wobei ich hier davon aussgehe, dass es wenn nur manuell unterstützt wird (keine Ahnung ab wann Trim im Kernel war und wann falls überhaupt nötig ein Backport aus neueren Kernel erfolgte).
Definitiv muss es manuell unter Arch und Gentoo aktiviert werden.
Ich sehe auch gerade, dass meine Methode (fstab) dort wohl in einigen Fällen zu Problemen führen kann und ein Aufruf per Cron-Job empfohlen wird - das muss ich mir mal ansehen (warum Cron und warum fstab nicht gut).
Fruchtnektar schrieb:Hi, in wie fern? Das widerspricht so ziemlich allem was ich bisher gelesen habe und selbst erlebt habe. TRIM muss in der fstab explizit aktiviert werden, aber ansonsten verhält es sich absolut wie unter Windows
Aktives Discard per fstab funktioniert zwar als Nobrainer, kostet aber Performance, da hier ein TRIM bei jeder Lösch-Operation durchgeführt wird. Wenn man viele kleine Dateien durch die Gegend schubst kostet das einiges an Leistung. Besser ist da ein Batched Discard via fstrim, der z.B. einmal pro Stunde oder einmal pro Tag durchgeführt wird.
Fruchtnektar
Lieutenant
- Registriert
- Okt. 2003
- Beiträge
- 942
Danke für die Antwort.
Da sollte aber bei halbwegs aktuellen Controllern die Firmware eingreifen und in diesem Fall die Befehle ignorieren bzw. sammeln. Aber sollte müsste hätte können. Ein andauerndes Erstellen/Löschen von vielen kleinen Dateien fällt bei mir nicht in die tägliche Arbeit. Somit ist es für mich ein Randfall der höchstens bei einem git/svn cleanout eines lokalen Reps auftreten kann. Aber gut zu wissen. Danke nochmal!
Da sollte aber bei halbwegs aktuellen Controllern die Firmware eingreifen und in diesem Fall die Befehle ignorieren bzw. sammeln. Aber sollte müsste hätte können. Ein andauerndes Erstellen/Löschen von vielen kleinen Dateien fällt bei mir nicht in die tägliche Arbeit. Somit ist es für mich ein Randfall der höchstens bei einem git/svn cleanout eines lokalen Reps auftreten kann. Aber gut zu wissen. Danke nochmal!
davidbaumann
Commodore
- Registriert
- Aug. 2004
- Beiträge
- 4.867
Du löschst die Dateien vielleicht nicht selbst.
Aber was denkst du macht dein System, wenn du mal 10-20 Pakete aktualisierst? Richtig: Viele Dateien löschen und neu erstellen.
Das gleiche gilt fürs Browsen, temporäre Dateien...
Gruß.
Aber was denkst du macht dein System, wenn du mal 10-20 Pakete aktualisierst? Richtig: Viele Dateien löschen und neu erstellen.
Das gleiche gilt fürs Browsen, temporäre Dateien...
Gruß.
Fruchtnektar
Lieutenant
- Registriert
- Okt. 2003
- Beiträge
- 942
Um einen solchen Effekt zu erzeugen musst du schon mehrere 10k Dateien permanent touchen/deleten mit sync/flush. Ein einmaliger Effekt (alle 24h Updates), browsen wird keinen spürbaren Einbruch liefern - beobachte mal bitte den Browsercache auf Änderungen dieses verhält sich im niedrigen zweistelligen Bereich. Meine Auslagerungsfile ist zur Zeit genau 0,1MB groß -> diese ist egal wie groß diese ist immer genau ein File!
Und wozu gibt es ReadWrite-Caches um genau solche Flaschenhälse abzufangen. Ich habe hier es gerade explizit getestet (keine wissenschaftliche Methode): per Skript parallel leere Dateien erstellen und mit einem anderen Skript parallel löschen lassen (lief ca. 5 Minuten) -> keinerlei Slowdown. Erst als ich nach jeder Dateiaktion einen sync-Befehl zum vollziehen der Änderungen gesendet habe wurde es lahm (auch ohne Trim) -> ich schlussfolgere demnach dass wirklich tragende Probleme erst dann eintreten wenn explizite Änderungen erst geschrieben werden müssen (z.B. File-basierende-DB im Dauereinsatz). Und in welchem Anwendungsfall auf einem Arbeits/Heim-PC passiert dies? Ein Home/Work-User wird in 99,9% der Fälle nichts merken.
btw. gerade nachgelesen:
Das Problem tritt nicht mehr bei Sata3 (6 Gb/s) auf - ich habe eine 3rd Gen. SSD. Quele: Link
-> Also das Problem _kann_ bei SSDs Gen <=2 auftreten (muss aber nicht, Zitat wikipedia.org)
Und wozu gibt es ReadWrite-Caches um genau solche Flaschenhälse abzufangen. Ich habe hier es gerade explizit getestet (keine wissenschaftliche Methode): per Skript parallel leere Dateien erstellen und mit einem anderen Skript parallel löschen lassen (lief ca. 5 Minuten) -> keinerlei Slowdown. Erst als ich nach jeder Dateiaktion einen sync-Befehl zum vollziehen der Änderungen gesendet habe wurde es lahm (auch ohne Trim) -> ich schlussfolgere demnach dass wirklich tragende Probleme erst dann eintreten wenn explizite Änderungen erst geschrieben werden müssen (z.B. File-basierende-DB im Dauereinsatz). Und in welchem Anwendungsfall auf einem Arbeits/Heim-PC passiert dies? Ein Home/Work-User wird in 99,9% der Fälle nichts merken.
btw. gerade nachgelesen:
Das Problem tritt nicht mehr bei Sata3 (6 Gb/s) auf - ich habe eine 3rd Gen. SSD. Quele: Link
- Queued Trim Command – allows SATA SSDs to execute Trim without impacting normal operation, improving SSD performance
-> Also das Problem _kann_ bei SSDs Gen <=2 auftreten (muss aber nicht, Zitat wikipedia.org)
QuelleTRIM can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection (GC) cycle.
Ähnliche Themen
- Antworten
- 47
- Aufrufe
- 4.229
- Antworten
- 248
- Aufrufe
- 15.460
- Antworten
- 351
- Aufrufe
- 19.806
- Antworten
- 18
- Aufrufe
- 1.407