Umstieg von Windows 7 auf Linux

vnt

Fleet Captain Special
Mitglied seit
02.12.2011
Beiträge
324
Renomée
135
Hallo,

das Supportende von Windows 7 im Januar 2020 rückt unaufhaltsam näher und da mir ein zu wartender Windows 10 Rechner - nämlich das Notebook einer Frau - im Haus völlig ausreicht möchte ich meinen PC auf Linux umstellen, unter Beibehaltung der bestehenden Windows 7 Installation auf einer extra SSD.

Derzeit ist mein PC (AMD FX 6300, 8GB RAM, RX 460 Graka) wie folgt konfiguriert: Windows 7 Professional (64-Bit) und die Programme sind auf einer kleinen 128GB SSD installiert und meine Daten auf einer 1TB HDD; Dateisystem ist jeweils NTFS.
Da die Windows 7 Installation unverändert bleiben soll habe ich zusätzlich eine 512GB SSD gekauft auf die ich das Linux System installieren möchte; mit eigenen Partitionen für das System und Home, sowie falls sinnvoll Swap.

Was mir noch nicht ganz klar ist, ist wie ich den Linux Bootmanager GRUB auf die Linux SSD bekomme, dort aber einen Eintrag für Windows 7 habe ... die Bootreihenfolge im BIOS werde ich natürlich vor der Installation entsprechend einstellen, dass zuerst von der 512GB SSD gestartet werden soll.


Als für meine Zwecke geeignete Linux Distribution habe ich entweder Linux Mint 18.3, 19.1 (sobald es erschienen ist!) oder LMDE 3 ins Auge gefasst; nachstehend meine Anforderungen:
- problemloser Zugriff auf alle Freigaben im Heimnetzwerk (ist z.Zt. wohl Linux Mint 19 noch problematisch)
- die Möglichkeit GIMP und Darktable in der aktuellen Version, z.Zt. 2.10.8 bzw. 2.4.4 nutzen zu können ... möglichst ohne die Einschränkungen durch Flatpak und ohne die Notwendigkeit selbst kompilieren zu müssen.
- FlightGear und Supertuxkart in der aktuellen Version spielen zu können.
- Lightroom 3.6 und Anno 1404 via WINE unter Linux nutzen zu können. (Darktable 2.4.2 hatte ich unter Windows ausprobiert, die Performance war aber im Vergleich zu Lightroom 3.6 deutlich schlechter. Zudem habe ich mittlerweile sehr viele RAW-Fotos mit Lightroom bearbeitet und eine direkte Übernahme der Bearbeitungsschritte aus den Sidecar-Dateien in Darktable ist vielfach nicht möglich. Falls Darktable nativ unter Linux erheblich besser laufen sollte, würde ich aber zukünftig einen Wechsel zu Darktable in Erwägung ziehen.)
- Notensatzsoftware PriMus via WINE nutzen zu können inklusive MIDI-Soundausgabe mittels Soundfont.

Prinzipiell könnte ich natürlich die fünf letztgenannten Programme auch nach 2020 einfach weiter unter Windows 7 nutzen, da diese keine Internetverbindung benötigen ... unter Linux würde es mir aber besser gefallen.
Für das Homebanking per Finanzsoftware und Kartenleser habe ich vor auf Moneyplex zu wechseln, da das von mir bisher verwendete StarMoney unter WINE nicht lauffähig ist.
Treiber für Drucker und Kartenleser gibt es für alle drei vorgenannten Distributionen.

Eigentlich halten sich meine Anforderungen ziemlich in Grenzen, jedoch steckt der Teufel bekanntlich im Detail. Auch wenn ich langjährige Erfahrung mit der Wartung von Windows Systemen habe und seit ein paar Jahren ein Notebook unter Linux Mint betreibe, sowie generell keine Berührungsängste mit einer Kommandozeile habe möchte ich doch allzu großes Gefrickel vermeiden: der PC soll schlicht als stabiles Arbeitsgerät und gelegentlich zum Spielen nutzbar sein!

Für Anregungen von erfahrenen Linux Nutzern betreffend mein Vorhaben bin ich sehr dankbar ...

Gruß,
vnt
 
Zuletzt bearbeitet:
Während der Installation würde ich die Windows Platten abklemmen. Nach der Installation kann man bequem mit update-grub den Bootloader neu schreiben lassen. Wenn die Windows Platten angeschlossen sind gibt es automatisch einen Eintrag im Bootmenü.

Zu Anno 1404 https://appdb.winehq.org/objectManager.php?sClass=application&iId=9887
Ob es mit dem freien amd-gpu treiber oder mit dem amd-gpu-pro treiber läuft weiß ich natürlich nicht.

Die neusten Versionen von Prpgrammen werden meist in einem Ubuntu PPA eingepflegt, wie gut das die dann sich mit Mint vertragen? Ansonsten hilft einem meist Googlen wenn Probleme auftreten.
 
Hallo Peet007,

vielen Dank für die Tipps.

Die Datenbank von WineHQ war mir bekannt ... die konkreten Programme hatte ich nur informativ genannt, um eine Entscheidungsgrundlage für die für meine Zwecke passende Distribution zu liefern, da die Wahl der Distribution sonst ja auch eine Geschmacksfrage ist.
Wenn ich Dich richtig verstanden habe, werde ich wohl aufgrund der Vielzahl an PPAs und dem umfangreichen Wiki mit Ubuntu / Mint am besten bedient sein ... auch wenn nach dem was ich recherchiert habe Debian gemeinhin als die stabilere Distribution gehandelt wird, was mir ja grundsätzlich sehr zusagt.

Als langjährigem "Windows-Bastler" mutet es mir allerdings komisch an, dass es zum Teil problematisch ist native Linux-Software (z.B. Gimp, Darktable, FlightGear) unter aktuell unterstützten Betriebssystemversionen in der aktuellsten Version zu nutzen ... was mit der Windows-Portierung völlig problemlos ist.
Frage: Wenn ich selber kompiliere bekomme ich dann die z.B. die oben beispielhaft genannte Software auch unter Debian 9 oder Ubuntu 16.04 zum Laufen? Oder gibt es beim selber Kompilieren auch Probleme mit nicht erfüllten Abhängigkeiten?

... diesbezüglich macht Windows es einem einfacher indem benötigte Runtime-Bibliotheken normalerweise bei einer Softwareinstallation unproblematisch mitinstalliert werden ... was es im Grunde mit Flatpak unter Linux auch gibt, nur wieso funktioniert da dann z.B. der Datenaustausch zwischen dem aktuellen Gimp als Flatpak-Version und Darktable nicht?

Diese Probleme nehme ich aber gerne in Kauf, wenn ich mir dadurch das halbjährlich wiederkehrende Windows 10 Feature Upgrade Desaster und die Beglückung mit Zwangsupdates sparen kann. ;D

Gruß,
vnt
 
Was mir noch nicht ganz klar ist, ist wie ich den Linux Bootmanager GRUB auf die Linux SSD bekomme, dort aber einen Eintrag für Windows 7 habe ... die Bootreihenfolge im BIOS werde ich natürlich vor der Installation entsprechend einstellen, dass zuerst von der 512GB SSD gestartet werden soll.
Der Eintrag sollte automatisch hinzugefügt werden. Falls das nicht der Fall ist gibt es entsprechende Artikel im passenden Wiki, z.B.:
https://wiki.ubuntuusers.de/GRUB 2/

(Linux Mint basiert iirc auf Ubuntu, also müsste das da auch passen.)
- problemloser Zugriff auf alle Freigaben im Heimnetzwerk (ist z.Zt. wohl Linux Mint 19 noch problematisch)
Sollte eigentlich kein Thema sein, außer Linux Mint hat da was verbockt. Samba/CIFS funktioniert eigentlich ziemlich problemlos.
- die Möglichkeit GIMP und Darktable in der aktuellen Version, z.Zt. 2.10.8 bzw. 2.4.4 nutzen zu können ... möglichst ohne die Einschränkungen durch Flatpak und ohne die Notwendigkeit selbst kompilieren zu müssen.
Für Ubuntu gibt es ein ppa (d.h. zusätzliche Quellen für spezielle neuere Pakete). Ich hab bei beiden Anwendungen aber auch die Erfahrung gemacht, dass hier die neuesten Versionen nicht zwingend notwendig sind, außer man hat explizit ein Problem oder im Fall von darktable eine neuere Kamera die noch nicht unterstützt wird.
Gerade darktable nutze ich sehr häufig, daher kann ich das gut beurteilen.
Wenn man nicht eine Distribution wie Ubuntu nutzt, welche eine sehr seltsame Politik bzgl. Desktop-Anwendungen hat, dann sollte es aber auch kein Thema sein aktuelle Versionen zu bekommen.
Ubuntu und insbesondere Ubuntu LTS würde ich z.B. aus dem Grund für den Desktop nie empfehlen.

GIMP ist meiner Erfahrung nach extrem stabil, da hatte ich glaube ich noch nie einen Crash und auch sonst fast nie Bugs.
Da mit den neueren Versionen wenig Features hinzukommen sehe ich das absolut unkritisch.
- FlightGear und Supertuxkart in der aktuellen Version spielen zu können.
Das sollte wirklich kein Thema sein und mit der Grafikkarte auch gut laufen.
- Lightroom 3.6 und Anno 1404 via WINE unter Linux nutzen zu können. (Darktable 2.4.2 hatte ich unter Windows ausprobiert, die Performance war aber im Vergleich zu Lightroom 3.6 deutlich schlechter. Zudem habe ich mittlerweile sehr viele RAW-Fotos mit Lightroom bearbeitet und eine direkte Übernahme der Bearbeitungsschritte aus den Sidecar-Dateien in Darktable ist vielfach nicht möglich. Falls Darktable nativ unter Linux erheblich besser laufen sollte, würde ich aber zukünftig einen Wechsel zu Darktable in Erwägung ziehen.)
Anno geht wohl ganz gut per Proton (d.h. automatisch per Steam Play), wobei es aktuell ein paar Probleme geben soll:
https://www.protondb.com/app/33250

Lightroom ist schon eher ein Problem:
https://appdb.winehq.org/objectManager.php?sClass=version&iId=34490
Wenn du darauf angewiesen bist ist aktuell wohl Dual Boot die bessere Lösung.
Prinzipiell bevorzuge ich bei Windows ganz klar die VM Lösung, allerdings läuft darüber glaube ich OpenCL nicht oder nur, wenn man Grafikkarten-Virtualisierung nutzt.
Ohne das (oder eine andere Form der GPU Beschleunigung) ist es dann natürlich in der Performance stark begrenzt.

Gerade OpenCL ist bei darktable auch ein Punkt. Das gibt es mit den freien Treibern (noch) nicht out of box, da muss man Hand anlegen (OpenGL etc. läuft aber problemlos).
Ohne OpenCL ist darktable auch nicht performant, daher vermute ich, dass es unter Windows derzeit nicht läuft, wobei da evtl. weniger auf Grund der Treiber, sondern evtl. funktioniert die OpenCL Unterstützung von darktable unter Windows einfach noch nicht.
Das Gute ist, dass man nicht von den freien Open Source Treibern weg muss um doch OpenCL nutzen zu können, man muss aber einen Teil der geschlossenen amdgpu-pro Treiber installieren.
Die gibt es glücklicherweise als einzelne .deb Dateien, d.h. das sollte eine Sache von 5min sein und da die genaue Version hier relativ unerheblich ist, muss man das auch nur einmal machen und hat es dann erledigt.
Welche das genau sind weiß ich nicht aus dem Kopf, kann es dir aber raussuchen, das ist kein Thema.
So habe ich das auf meinem System (welches allerdings unter Exherbo und nicht Mint läuft) auch gemacht und es läuft super.
- Notensatzsoftware PriMus via WINE nutzen zu können inklusive MIDI-Soundausgabe mittels Soundfont.
Läuft wohl ganz gut:
https://appdb.winehq.org/objectManager.php?sClass=application&iId=9259

Das wäre aber für mich der klassische Fall, wo ich eher eine VM einsetzen würde, wenn man die zusätzliche Windows Lizenz hat.
Für das Homebanking per Finanzsoftware und Kartenleser habe ich vor auf Moneyplex zu wechseln, da das von mir bisher verwendete StarMoney unter WINE nicht lauffähig ist.
Ich kenne die Programme nicht, aber im Zweifelsfall könnte da auch eine VM eine Lösung sein.
Eigentlich halten sich meine Anforderungen ziemlich in Grenzen, jedoch steckt der Teufel bekanntlich im Detail. Auch wenn ich langjährige Erfahrung mit der Wartung von Windows Systemen habe und seit ein paar Jahren ein Notebook unter Linux Mint betreibe, sowie generell keine Berührungsängste mit einer Kommandozeile habe möchte ich doch allzu großes Gefrickel vermeiden: der PC soll schlicht als stabiles Arbeitsgerät und gelegentlich zum Spielen nutzbar sein!
Ich kenn deine Bedenken, ich hab das Problem regelmäßig unter Windows, wo ich (als langjähriger Linux Nutzer) oft am abkotzen bin.
Erfahrungsgemäß wird es immer zu ein paar Problemen kommen, die meistens keine großen Sachen sind, aber halt doch nerven und etwas Zeit brauchen, wenn man sich nicht so damit auskennt.

Während der Installation würde ich die Windows Platten abklemmen.
Wozu? Ich sehe dafür keine Notwendigkeit.
Man kann in den Installern problemlos erkennen, welches die Windowspartitionen sind und die eben nicht verwenden.
 
Ich bin mit Ubuntu eigentlich wunschlos glücklich.
Kann sein, dass ich da nicht die neueste Version diverser Anwendungen habe - aber ich habe gefühlt die größte Auswahl und nur das zählt für mich.
Noch dazu ist es sehr verbreitet und damit findet man fast immer zu einem Problem die Lösung.
Über die Stabilität kann ich auch nicht meckern, nur alle paar Monate wird mal neu gebootet, ansonsten läuft der Rechner einfach so die ganze Zeit durch.

Wine brauchte ich bisher nicht. Ich habe für alles eine Alternative gefunden und für den Schnitt von Videos des onlinetvrecorders einfach beschlossen, auf das Programm zu verzichten, weil es doch zu speziell ist. Im Notfall kann dafür immer noch Windows gebootet werden und dann schneide ich halt alle Filme, die sich angesammelt haben, auf einen Schlag und habe wieder ein halbes Jahr Ruhe.

Es gibt nur einen großen Kritikpunkt: Auf dem Ryzen-PC sind auch nach fast 2 Jahren immer noch keine Sensordaten mit den boardmitteln auslesbar.
Irgendwer hatte mal eine Möglichkeit veröffentlicht, diese aber nicht weiterentwickelt. Nach jedem Kernelupdate muss ich mir das Paket neu kompilieren, um zu sehen, wie warm es so wird.
 
Es gibt nur einen großen Kritikpunkt: Auf dem Ryzen-PC sind auch nach fast 2 Jahren immer noch keine Sensordaten mit den boardmitteln auslesbar.
Irgendwer hatte mal eine Möglichkeit veröffentlicht, diese aber nicht weiterentwickelt. Nach jedem Kernelupdate muss ich mir das Paket neu kompilieren, um zu sehen, wie warm es so wird.
Das ist ein Ubuntu Problem. Im offiziellen Linux Kernel ist das seit 4.15, d.h. grob einem Jahr integriert.
Wie zuvor auch schon: ich sehe absolut keinen Vorteil darin bei einer bestimmten Kernelversion hängen zu bleiben, insbesondere nicht bei einem relativ neuen System wie dem Ryzen.
Im Gegenteil, das ist sogar sehr unvorteilhaft, da für diese Hardware oft relevante Fixes kommen, welche aber nicht oder nur teilweise auf die früheren Kernelversionen backported werden.

Aber im Endeffekt halte ich jetzt Temperature Monitoring bei der CPU auch nicht für soooooooo kritisch. Das ist schon verschmerzbar.
 
Hallo,

vielen Dank für Eure Beiträge und Anregungen, die mir sehr bei der Entscheidungsfindung weiterhelfen.

Das Gute ist, dass man nicht von den freien Open Source Treibern weg muss um doch OpenCL nutzen zu können, man muss aber einen Teil der geschlossenen amdgpu-pro Treiber installieren.
Die gibt es glücklicherweise als einzelne .deb Dateien, d.h. das sollte eine Sache von 5min sein und da die genaue Version hier relativ unerheblich ist, muss man das auch nur einmal machen und hat es dann erledigt.
Welche das genau sind weiß ich nicht aus dem Kopf, kann es dir aber raussuchen, das ist kein Thema.

Auf das Angebot würde ich wenn die Installation von Darktable ansteht sehr gerne zurückkommen.
Bei meinem Testlauf mit Darktable 2.4.2 unter Windows 7 Professional 64-Bit wurde mir - soweit ich mich erinnere - OpenCL als funktionierend angezeigt; die Performance war aber trotzdem leider nicht gut ... was ein anderer Anwender im Darktable-Bugtracker auch bereits gemeldet hatte.
Darktable wäre zukünftig durchaus interessant für mich, da zumindest teilweise die Lightroom 3.6 Entwicklungseinstellungen für meine RAW-Dateien aus den XMP-Sidecar-Dateien importiert werden können. Allerdings unterscheiden sich die Entwicklungsprozesse von Lightroom 3.6 und Darktable an einigen Stellen doch signifikant, so dass ein Wechsel zu Darktable eigentlich nur bei einer deutlich besseren Qualität der entwickelten RAW-Dateien gegenüber Lightroom 3.6 Sinn macht. [OffTopic ->] ... beispielsweise aufgrund einer besseren Rauschreduzierung von abfotografierten Dias, bei denen das Rauschen hauptsächlich durch das Filmkorn verursacht wird. Das Ergebnis meines kurzen Testlaufes mit Darktable 2.4.2 hat mich aber diesbezüglich nicht überzeugt ... allerdings habe ich aufgrund der schlechten Performance auch nicht wirklich ausgiebig getestet, was bei der Aufgabenstellung für ein aussagekräftiges Resultat notwendig gewesen wäre. [<- OffTopic]

Das ist ein Ubuntu Problem. Im offiziellen Linux Kernel ist das seit 4.15, d.h. grob einem Jahr integriert.

Linux Mint 19 als Ubuntu 18.04 LTS Abkömmling verwendet meines Wissen standardmäßig diesen Kernel, während LMDE 3 auf Debian 9 mit Kernel 4.9 aufbaut.

... also doch noch ein paar Wochen auf Linux Mint 19.1 warten und hoffen, dass die Netzfreigaben im Heimnetz dann ohne Gefrickel funktionieren ...

Gruß,
vnt
 
Allerdings unterscheiden sich die Entwicklungsprozesse von Lightroom 3.6 und Darktable an einigen Stellen doch signifikant
Ja, das stimmt. Liegt allerdings eher daran, dass Lightroom einen sehr speziellen Prozess anbietet, den es glaube ich sonst in keinem Programm so gibt (oder zumindest in keinem das ich kenne).
Da muss man sich beim Umstieg auf jeden Fall umgewöhnen.
, so dass ein Wechsel zu Darktable eigentlich nur bei einer deutlich besseren Qualität der entwickelten RAW-Dateien gegenüber Lightroom 3.6 Sinn macht. [OffTopic ->] ... beispielsweise aufgrund einer besseren Rauschreduzierung von abfotografierten Dias, bei denen das Rauschen hauptsächlich durch das Filmkorn verursacht wird. Das Ergebnis meines kurzen Testlaufes mit Darktable 2.4.2 hat mich aber diesbezüglich nicht überzeugt ... allerdings habe ich aufgrund der schlechten Performance auch nicht wirklich ausgiebig getestet, was bei der Aufgabenstellung für ein aussagekräftiges Resultat notwendig gewesen wäre. [<- OffTopic]
Rauschreduktion gehört angeblich bei darktable zu den Schwachpunkten der Software, wobei ich persönlich zufrieden bin und auch noch keine Tests angestrebt habe (weil eben zufrieden).
Wie es sich nun im Vergleich mit LR 3.6 verhält kann ich nicht sagen, aber gegen die neuen Lightroom Versionen oder sowas wie DxO kommt es angeblich nicht an.
Das zumindest habe ich schon mehrfach gehört, kann es allerdings eben nicht aus erster Hand bestätigen.
Da darktable aber eh kostenlos ist würde ich es einfach ausprobieren, verlierst dabei ja nichts.

Ubuntu 18.04 ist auf 4.15 - 16.04 HWE ebenso.
Dann sollte das mit dem Ryzen Sensor eigentlich kein Problem sein.
Gab zwar noch ein paar Fixes für einzelne Modelle (i.e. Ryzen 2700X), aber prinzipiell wurde der Treiber mit 4.15 hinzugefügt.
https://git.kernel.org/pub/scm/linu...5&id=9af0a9aecdb945cd5513941ffdcbcc031009b402
 
Zuletzt bearbeitet:
also ganz ehrlich...ich spiele auch schon seit langem mit dem Gedanken auf linux umzusteigen. Es gibt nur einen Punkt der mich davon abhält: Die Creative Suite von Adobe. ICH WEISS! es gibt GIMP und Inkscape...aber ich weiss nicht ob man mit GIMP wirklich so gut Bilder fürs Web modifizieren und optimieren kann wie mit PS. Hat jemand von euch damit Erfahrungen gemacht ? Würde mich mal interessieren und hoffe das ich hier nicht zuweit ins Offtopic gehe :)
 
Hallo foxyfox,

meiner Meinung nach ist es weniger eine Frage der Leistungsfähigkeit von GIMP und PS, die für das eine oder eben für das andere Programm spricht, sondern vielmehr eine Frage der persönlichen Erfahrung mit dem Arbeitsablauf des jeweiligen Programms.
Mit Sicherheit könnte ich meine RAW Aufnahmen alle mit Darktable statt mit Lightroom 3.6 bearbeiten und würde mindestens gleichwertige Ergebnisse wie mit LR erzielen, zumal LR 3.6 ja nun auch schon etwas "älter" ist. Allerdings ist unterscheiden sich die RAW-Entwicklungsmodule von Darktable und LR 3.6 signifikant und die Konvertierung der Entwicklungseinstellungen der in LR 3.6 bearbeiteten RAW-Aufnahmen auf Darktable wäre somit extrem zeitintensiv.
An LR 3.6 bin ich gewöhnt, an Darktable muss ich erst gewöhnen. Da ich mit der Qualität der RAW-Entwicklung von LR 3.6 zufrieden bin werde ich die Software dementsprechend solange wie möglich weiter nutzen.
Um PS unter Linux zum Laufen zu bekommen gibt es grundsätzlich nur zwei Wege: WINE oder die Ausführung in einer VM mit installiertem Windows und einer gültigen Windows Lizenz.
Ob WINE mit Deiner PS Version funktioniert kannst Du hier recherchieren: https://appdb.winehq.org/

Gruß,
vnt
 
Das ist ein Ubuntu Problem. Im offiziellen Linux Kernel ist das seit 4.15, d.h. grob einem Jahr integriert.
Wie zuvor auch schon: ich sehe absolut keinen Vorteil darin bei einer bestimmten Kernelversion hängen zu bleiben, insbesondere nicht bei einem relativ neuen System wie dem Ryzen.
Im Gegenteil, das ist sogar sehr unvorteilhaft, da für diese Hardware oft relevante Fixes kommen, welche aber nicht oder nur teilweise auf die früheren Kernelversionen backported werden.

Aber im Endeffekt halte ich jetzt Temperature Monitoring bei der CPU auch nicht für soooooooo kritisch. Das ist schon verschmerzbar.

Ja, solche Probleme hat man bei Roling Release Distributionen nicht. Wenn mein Ryzen Notebook (Honor Magicbook) endlich hier mal ankommt, dann wird dort Manjaro Linux drauf installiert. Dies basiert auf Arch Linux, kommt aber mit fertigt installiertem Desktop. Man hat also immer den Kernel und alle anderen Betriebssystem Komponenten auf neusten Stand (mit einer kurzem Verzögerung von ein paar Tagen um schlimme Fehler auszuschließen) ohne Arch typisch alles über die Konsole hinfrickeln zu müssen. Ein weiterer Pluspunkt ist das AUR von Arch. Wenn man dies einmal aktiviert hat, dann hat man sofort Zugriff auf ein riesiges Software Archiv, ohne jedesmal erst einzelne PPAs hinzufügen zu müssen. Ich habs jetzt ein paar Monate in einer VM getestet und für mich ist Mint nun nicht mehr benutzerfreundlich genug.
 
Das A und O ist bei Linux das man selbst aktiv wird und sich selber weiterhilft.

Zitat Linus T. "Linux ist ein Baukastensystem und jeder muss kann sich sein System wie er es braucht zusammenstellen. Und das ist gut so."

https://github.com/M-Bab/linux-kernel-amdgpu-binaries

Läuft bei mir sogar mit dem amdgpu-pro Treiber unter Ubuntu.
 
Ja, mit dem 4.15er Kernel ist tatsächlich der AMD-Sensor auslesbar.
Nur das Mainboard spuckt nichts aus, weil der IT87 im Kernel noch fehlt.
Und da der Entwickler des Paketes für den IT87 sowieso das Handtuch geworfen hat, ist es wohl entweder bereits in einem neueren Kernel drin oder wird nie reinkommen, bis nicht Jemand Anderes sich des Themas annimmt.
Ich wollte eigentlich schon längst mal den Kernel aktualisieren. Aber die Kiste rennt ja und so lange CPU und GPU-Temperatur bekannt sind, ist das immerhin etwas. Wegen Boinc-Dauerlast sehe ich die Temperaturanzeige schon sehr kritisch. Die sollte vorhanden sein und stimmen. HWinfo unter Windows konnte die Daten kurz nach Release des Boards bereits auslesen. Also Hexenwerk scheint das auch nicht zu sein.
 
Mit Sicherheit könnte ich meine RAW Aufnahmen alle mit Darktable statt mit Lightroom 3.6 bearbeiten und würde mindestens gleichwertige Ergebnisse wie mit LR erzielen, zumal LR 3.6 ja nun auch schon etwas "älter" ist. Allerdings ist unterscheiden sich die RAW-Entwicklungsmodule von Darktable und LR 3.6 signifikant und die Konvertierung der Entwicklungseinstellungen der in LR 3.6 bearbeiteten RAW-Aufnahmen auf Darktable wäre somit extrem zeitintensiv.
Da ich noch nie Lightroom in Verwendung hatte kann ich das nicht mit Bestimmtheit sagen, aber angeblich kann man in darktable die Entwicklungsdaten von Lightroom importieren:
https://www.darktable.org/2013/02/importing-lightroom-development/
Ob und wie gut das funktioniert, keine Ahnung.

Ansonsten könntest du notfalls Lightroom 3.6 auch noch in einer VM laufen lassen. Soweit ich auf die schnelle in Erfahrung bringen konnte hat die Version noch keine Unterstützung für GPU Beschleunigung (OpenCL o.ä.), es sollte in einer VM also genauso schnell laufen wie nativ.
Zudem geht es ja scheinbar hauptsächlich um schon entwickelte Fotos, da braucht man jetzt die Geschwindigkeit eher nicht so, da man ja typischerweise keine so großen Änderungen mehr macht, sondern nur kleinere Anpassungen.

bzgl. darktable würde ich einfach empfehlen mal das eine oder andere Video anzuschauen. Ich fand damals beim Einstieg die von Robert Hutton ganz nett, gibt aber sicherlich noch viele andere auf Youtube die empfehlenswert sind.
evtl. hilft das bei der Entscheidung, ob darktable was für dich sein könnte oder nicht.
https://www.youtube.com/user/rhutton86/videos

Edit: eine Funktion, die mir bei darktable wirklich fehlt und die bei Lightroom Nutzern sehr beliebt ist ist die Möglichkeit Bilder direkt zu vergleichen.
Leider wird sich da wohl auch nix tun. Der entsprechende Funktionswunsch ist schon viele Jahre alt und es sieht nicht so aus, als wenn dieser mal erfüllt würde. :(
Ja, solche Probleme hat man bei Roling Release Distributionen nicht. Wenn mein Ryzen Notebook (Honor Magicbook) endlich hier mal ankommt, dann wird dort Manjaro Linux drauf installiert. Dies basiert auf Arch Linux, kommt aber mit fertigt installiertem Desktop. Man hat also immer den Kernel und alle anderen Betriebssystem Komponenten auf neusten Stand (mit einer kurzem Verzögerung von ein paar Tagen um schlimme Fehler auszuschließen) ohne Arch typisch alles über die Konsole hinfrickeln zu müssen. Ein weiterer Pluspunkt ist das AUR von Arch. Wenn man dies einmal aktiviert hat, dann hat man sofort Zugriff auf ein riesiges Software Archiv, ohne jedesmal erst einzelne PPAs hinzufügen zu müssen. Ich habs jetzt ein paar Monate in einer VM getestet und für mich ist Mint nun nicht mehr benutzerfreundlich genug.
Ich habe selbst Arch Linux auf dem Spiele-PC am Laufen, eben weil es Rolling Release ist.
An sich ist das Konzept von Arch wirklich sehr cool (Rolling Release, binäre Pakete, pragmatisch umgesetzt) und insbesondere weiß ich auch die umfangreichen Wikis zu schätzen, die meistens besser, detaillierter und auch allgemeiner anwendbar sind als die anderer Distributionen (insbesondere im Vergleich zu Ubuntu und dem teilweise echt grauseligen Gentoo Wiki).
Selbst als Nicht-Arch Nutzer habe ich mich da öfter mal rumgetrieben, wenn ich mich mit einer Software auseinandersetzen musste, welche ich nicht oder nur leidlich kannte.

Problematisch bei Arch sehe ich aber eben den Paketmanager pacman.
Dessen Interface (auf der Kommandozeile, graphische Tools nutze ich dafür nicht …) ist wirklich grausam und echt für die Tonne. Zum Glück gibt es aber zsh, das dämpft es ein bisschen.
Die AUR sind eine nette Idee, die ähnlichen Ideen bei Gentoo (e.g. layman oder wie es inzwischen genannt wird) und Exherbo (User Repositories) sehr nahe kommen, aber die Umsetzung ist hier eine Gräueltat.
Als (halb-)aktivem Paketentwickler von Exherbo bluten mir da jedesmal die Augen, wenn ich das ansehen muss.
Ich bin ja schon kein so großer Freund der Gentoo ebuilds (wobei sich die in den letzten Jahren massiv verbessert haben), aber gegenüber den pkgbuild von Arch sind die schon eine absolute Wohltat.
Ich weiß schon, es ist halt eine Form von Pragmatismus, aber ich finds scheußlich.
Das A und O ist bei Linux das man selbst aktiv wird und sich selber weiterhilft.
Ehrlich gesagt sehe ich nicht, wo sich hier Linux von Windows unterscheidet.
Die, die sich hier bei Linux gerne so sehr beschweren vergessen meistens, dass genau das für sie bei Windows schon zur Selbstverständlichkeit geworden ist und sie es einfach gewohnt sind schnell zu wissen wie und wo und wonach sie suchen müssen.
Ich selbst habe z.B. inzwischen mehr Erfahrung mit Linux als mit Windows, muss aber auf dem Spiele-PC teilweise und auf der Arbeit komplett mit Windows klar kommen und bin oft genug am Abkotzen, weil ich es einfach nicht so gut kenne wie "mein" Linux.
Ja, mit dem 4.15er Kernel ist tatsächlich der AMD-Sensor auslesbar.
Nur das Mainboard spuckt nichts aus, weil der IT87 im Kernel noch fehlt.
Und da der Entwickler des Paketes für den IT87 sowieso das Handtuch geworfen hat, ist es wohl entweder bereits in einem neueren Kernel drin oder wird nie reinkommen, bis nicht Jemand Anderes sich des Themas annimmt.
Ich wollte eigentlich schon längst mal den Kernel aktualisieren. Aber die Kiste rennt ja und so lange CPU und GPU-Temperatur bekannt sind, ist das immerhin etwas. Wegen Boinc-Dauerlast sehe ich die Temperaturanzeige schon sehr kritisch. Die sollte vorhanden sein und stimmen. HWinfo unter Windows konnte die Daten kurz nach Release des Boards bereits auslesen. Also Hexenwerk scheint das auch nicht zu sein.
hm, das kann man natürlich nicht ausschließen, allerdings ist IT87 doch eigentlich schon lange (>10 Jahre) im Kernel.
Oder meinst du eine bestimmte IT87 Variante?
Aber natürlich kann man im Spezialfall immer mal Pech mit bestimmter Hardware haben, komplett ausschließen lässt sich das leider nie.
 
Zuletzt bearbeitet:
Unter https://github.com/groeck/it87 gabs da jedenfalls ein Paket, womit der IT87 auf diversen Ryzen-Boards angesprochen werden konnte.
Irgendwas Spezielles wird wohl dabei gewesen sein, wenn er nicht mit dem Standard im Kernel funktionierte.
Immerhin hat das Paket Jemand hier gesichert und bietet es weiter an: https://github.com/a1wong/it87
Aber es erfolgt seitdem keine Weiterentwicklung mehr. Und Dinge, die keiner pflegt, wir man sicherlich in der Kernelbauabteilung eher nicht so gern einbauen.
Theoretisch muss man sich die Einzelschritte ja nur als Script ablegen und nach jedem Reboot ausführen (ich boote nur, wenn der Rechner es wegen größerer Kernel-updates verlangt)
 
An Pacman kann man sich genauso gut gewöhnen wie an Apt ;)

ob
Code:
apt-get install <paketname>

oder

Code:
pacman -S <paketname>

macht keinen großen Unterschied. Die Apt Kommandos sind leichter zu merken, bei Pacman spart man sich ein paar Zeichen und kann es schneller einhacken (z.B pacman -Syu statt apt-get update und danach apt-get upgrade)

Aber damit kommt der Linux Noob User in der Regel selten in Kontakt, sondern nutzt einfach den grafischen Installer.
Die Debian basierten Ubuntus und Mints sind toll, keine Frage. Aber wer einen aktuellen Kernel braucht weil er neue Hardware benutzt, oder die neuste Version einer bestimmten Software, oder kein Bock hat jedes halbe Jahr ein Dist Update zu machen ... der ist mit den "Noob" Varianten von Arch wie Antergos (genauso bleeding edge wie Arch) oder Manjaro (wo die Pakete erst mit leichter Verzögerung erscheinen um die schlimmsten Unfälle, die bei bleeding edge passieren können, zu vermeiden) sicherlich besser bedient.
Das ist ja das Tolle an Linux: Jeder Jeck ist anders und für fast jeden gibt es die passende Distribution (man muss sie nur finden). Bei Windows gibt es nur friss oder stirb. ;D
Wer gerne mal verschiedene Distributionen ausprobiert sollte sich mal netboot.xyz angucken. Damit kann man einen Netinstall von vielen Linux Distributionen, FreeDOS, FreeBSD, OpenBSD und Windows durchführen, und hat auch noch wichtige Tools wie memtest, GParted oder Pogostick dabei.
 
Ne,
Code:
pacman -Syu
ist UI-mäßig totaler Mist.
Ja, es sind weniger Zeichen, aber das ist doch wurscht, dafür gibt es ja TAB Completion.
Und für die, die unbedingt weniger tippen wollen bietet praktisch jeder andere Paketmanager auch Kurzformen.
 
An Pacman kann man sich genauso gut gewöhnen wie an Apt ;)
Es ist ja kein fertiges Paket, das habe ich vielleicht missverständlich geschrieben.
Man muss den Quellcode jedes Mal neu kompilieren.
 
Im meinem Fall muss ich Ubuntu benutzen, den amd-gpu-pro gibt es halt nur für bestimmte Distris. Und die macht mir am wenigsten Probleme.

Es soll zwar auch gehen die opencl packete unter Arch zu installieren aber so richtig schlau wurde ich aus den Anleitungen nicht. Hat mal geheisen das alles obensource wird aber das wird sich wohl über Jahre hinziehen.
 
Unter https://github.com/groeck/it87 gabs da jedenfalls ein Paket, womit der IT87 auf diversen Ryzen-Boards angesprochen werden konnte.
Irgendwas Spezielles wird wohl dabei gewesen sein, wenn er nicht mit dem Standard im Kernel funktionierte.
Immerhin hat das Paket Jemand hier gesichert und bietet es weiter an: https://github.com/a1wong/it87
hm ok, der Code dort scheint Support für ein paar neue Chips hinzuzufügen.
Generell scheint ITE aber nicht der kooperativste Hersteller zu sein und da hat man bei Linux dann eben gerne mal Pech, da es eben einen engagierten Entwickler benötigt, der bereit ist das Reverse Engineering durchzuführen.
Aber es erfolgt seitdem keine Weiterentwicklung mehr. Und Dinge, die keiner pflegt, wir man sicherlich in der Kernelbauabteilung eher nicht so gern einbauen.
Naja, der ursprüngliche Betreiber von dem github Repo war ja der Maintainer der hwmon Treiber im Linux Kernel, ich denke der hat einen ganz guten Überblick was rein soll und was nicht.
Wahrscheinlich war einfach die Codequalität noch nicht gut genug, schwierig zu sagen.
Theoretisch muss man sich die Einzelschritte ja nur als Script ablegen und nach jedem Reboot ausführen (ich boote nur, wenn der Rechner es wegen größerer Kernel-updates verlangt)
Ich glaube da hast du was falsch verstanden. Das was du da verlinkt hast ist ein Kernel-Modul.
Das musst du nur neu bauen, wenn du (oder deine Distribution) einen neuen Kernel installierst und nicht bei jedem Reboot.
Wenn du die dkms Funktionalität nutzt, dann passiert das sogar automatisch, d.h. du musst dich nicht mehr darum kümmern.
Nach einem Reboot müsstest du nur sicherstellen, dass dein selbstgebautes Modul geladen wird, aber das kann entweder lm_sensors für dich erledigen oder /etc/modprobe.d
Im meinem Fall muss ich Ubuntu benutzen, den amd-gpu-pro gibt es halt nur für bestimmte Distris. Und die macht mir am wenigsten Probleme.
Es soll zwar auch gehen die opencl packete unter Arch zu installieren aber so richtig schlau wurde ich aus den Anleitungen nicht.
Nur wegen OpenCL brauchst du den amdgpu-pro wirklich nicht installieren.
Ich habe hier amdgpu (also den offenen Treiber) zusammen mit dem proprietären OpenCL Teil laufen und das läuft wunderbar (bei mir hauptsächlich für darktable im Einsatz).
Das hier ist die Liste der Dateien, die ich aus amdgpu-pro extrahiert und installiert habe:
Code:
/etc
/etc/OpenCL
/etc/OpenCL/vendors
/etc/OpenCL/vendors/amdocl-orca64.icd
/opt
/opt/amdgpu-pro
/opt/amdgpu-pro/lib
/opt/amdgpu-pro/lib/x86_64-linux-gnu
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libamdocl-orca64.so
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libamdocl12cl64.so
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1
/opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so -> libOpenCL.so.1
/opt/amdgpu-pro/bin
/opt/amdgpu-pro/bin/clinfo
Prinzipiell kann man sowas auch unter /usr installieren, aber da es proprietärer Code ist gehört es für mich nach /opt (und dorthin installiert es das .deb Paket auch richtigerweise standardmäßig).
Danach muss man noch ld mitteilen, dass es auch libraries in dem Pfad einbeziehen soll, d.h. hier /opt/amdgpu-pro/lib/x86_64-linux-gnu.
Dazu erstellt man (unter Arch, kann bei anderen Distributionen wieder anders sein) eine Datei in /etc/ld.so.conf.d:
Code:
echo "/opt/amdgpu-pro/lib/x86_64-linux-gnu" > /etc/ld.so.conf.d/00-amdgpu-pro-opencl.conf
Zuletzt noch /opt/amdgpu-pro/bin zum Suchpfad hinzufügen. Wie man das unter Arch am geschicktesten macht konnte ich auf die Schnelle leider nicht herausfinden.

Um an die entsprechenden Dateien zu kommen muss man die .deb Dateien entpacken. z.B. für 18.20-579836:
Code:
tar xf amdgpu-pro-18.20-579836.tar.xz
cd amdgpu-pro-18.20-579836
mkdir install; cd install
ar -x ../opencl-orca-amdgpu-pro-icd_18.20-579836_amd64.deb data.tar.xz
tar xf data.tar.xz && rm data.tar.xz
Dann hast du im Verzeichnis install alle Dateien, die das Paket opencl-orca-amdgpu-pro-icd_18.20-579836_amd64.deb installieren würde.
Das Gleiche noch mit clinfo-amdgpu-pro_18.20-579836_amd64.deb und libopencl1-amdgpu-pro_18.20-579836_amd64.deb und du müsstest eigentlich alles haben was du benötigst.
Man kann dann noch ein bisschen aufräumen (ich hab z.B. die ganzen Changelogs entfernt, da ich die nicht brauche) und das dann installieren, am Besten per Paketmanager (falls möglich) oder notfalls per Hand.
Hat mal geheisen das alles obensource wird aber das wird sich wohl über Jahre hinziehen.
Das ist aktuell in der Mache und für einige Chips klappt das auch schon. Das Projekt nennt sich ROCm.
Leider gilt die Unterstützung nur für neuere Chips, die alten schauen in die Röhre bzw. kommen nicht vom closed source Teil weg.
Genauer gesagt funktioniert es für Fiji, Polaris und Vega in Kombination mit Ryzen CPUs oder Haswell CPUs.
Details sowie ein paar Ausnahmen sind hier zu finden:
https://github.com/RadeonOpenCompute/ROCm

Ich finde es sehr schade, dass die alten Chips bei closed source bleiben werden, aber habe mich inzwischen damit abgefunden.
Da ich aber nächstes Jahr ein Upgrade auf Zen 2 plane ist es mir inzwischen auch relativ egal, bis dahin sollte ROCm auch noch etwas weiter gekommen sein.
 
Zuletzt bearbeitet:
Ich glaube da hast du was falsch verstanden. Das was du da verlinkt hast ist ein Kernel-Modul.
Das musst du nur neu bauen, wenn du (oder deine Distribution) einen neuen Kernel installierst und nicht bei jedem Reboot.
Wenn du die dkms Funktionalität nutzt, dann passiert das sogar automatisch, d.h. du musst dich nicht mehr darum kümmern.
Nach einem Reboot müsstest du nur sicherstellen, dass dein selbstgebautes Modul geladen wird, aber das kann entweder lm_sensors für dich erledigen oder /etc/modprobe.d

Nur wegen OpenCL brauchst du den amdgpu-pro wirklich nicht installieren.
Ich habe hier amdgpu (also den offenen Treiber) zusammen mit dem proprietären OpenCL Teil laufen und das läuft wunderbar (bei mir hauptsächlich für darktable im Einsatz).
...
Nein, hab ich nicht. :)
Es wird ja in Ubuntu so oft der Kernel geupdated, dass bei mir bei jedem Neustart ein anderer Kernel da ist. Manche werden vermutlich installiert, aber nie aktiv, weil in der Zwischenzeit schon wieder der Nächste kommt.

Mit dkms kann ich mich ja mal befassen, wenn ich zu viel Zeit hab.

Der amdgpupro-Treiber ist mir da wesentlich lieber, als eine ziemlich lange Anleitung, die womöglich beim nächsten größeren update wieder nicht mehr funktioniert.
Man muss halt bei der Auswahl der Ubuntu-Version genau schauen, dass CPU und GPU zusammen passen, sprich unterstützt werden. Mittlerweile dürfte das mit Ryzen klappen, aber ich habe es noch nicht probiert.
 
Der amdgpupro-Treiber ist mir da wesentlich lieber, als eine ziemlich lange Anleitung, die womöglich beim nächsten größeren update wieder nicht mehr funktioniert.
Diese Libraries haben keine Abhängigkeiten (außer dem typischen glibc/gcc Zeug), insofern brauchst du da nix updaten.
Sollte im Grunde auch relativ egal sein, welche amdgpu-pro Version man nimmt, nur sollte es mindestens 18.20 sein, da es in 18.10 einen Bug gab, der einen segfault nach sich zog.
Insofern ist das echt unkritisch und so eigentlich sogar die stressfreiere Variante als ständig den amdgpu-pro aktuell zu halten, da sich um ja die Distribution darum kümmert Mesa/amdgpu aktuell zu halten.

Ich würde die freuen Treiber immer dringend nahelegen, wenn man ein stressfreies System haben will, es sei denn man ist auf ein spezielles Feature des amdgpu-pro angewiesen.
Dazu gehörte OpenCL früher auch, aber mittlerweile ist es auskoppelbar und damit das Problem eben auch gelöst.
Soweit mir bekannt ist es ansonsten noch Freesync, aber auch das ist mittlerweile auf dem Weg und sollte in einem halben Jahr für aktuelle Distributionen im freien Treiber verfügbar sein.

Edit: übrigens kann man bei Ubuntu auch einfach nur besagte .deb Dateien installieren, das genügt für OpenCL (alternativ eine neuere Version, e.g. amdgpu-pro-18.50-708488-ubuntu-18.04):
Code:
opencl-orca-amdgpu-pro-icd_18.20-579836_amd64.deb
clinfo-amdgpu-pro_18.20-579836_amd64.deb
libopencl1-amdgpu-pro_18.20-579836_amd64.deb
Die restlichen .deb Dateien kann man sich sparen (insofern ich nicht eine vergessen habe, sollte aber passen).

Nur für Distributionen, die nicht .deb verwenden muss man die .deb Archive extrahieren und manuell installieren. Ist aber auch kein Beinbruch, wie oben aufgezeigt.

Diese "Teilinstallation" des amdgpu-pro Treibers (d.h. nur opencl) wird übrigens von AMD explizit so unterstützt.

Edit: gerade 18.50 getestet und der gibt bei mir wieder einen Segfault. Empfehle also explizit Version 18.20. Der funktioniert bei mir (Kaveri APU) wunderbar.
 
Zuletzt bearbeitet:
Grafiktreiber gehören zu den Dingen, die ich möglichst nie update, wenn das System erst mal einwandfrei läuft.
Ich muss halt jedes Mal höllisch aufpassen, weil der Nvidia-Kram immer wieder aufs Neue fragt, ob er aktualisiert werden darf. Ich hab da noch keine Möglichkeit gefunden, das abzustellen.
 
Für Boinc braucht man auch die llvm Pakete oder noch andere. Und da ich kein Informatiker bin hört bei mir das Machbare auf wenn mir das Verständnis dafür fehlt.
Einfache Sachen gehen.

Rein interesse halber hab ich mir auch Centos installiert um zu sehen ob es läuft. Bis ein neuerer Kernel installiert ist hakelt es ein bischen, aber dann läufts wie bei Ubuntu trotz kernel 3.16. Anscheinend sind da die ganzen Treiber und Patches für Ryzen eingepflet.
 
Zurück
Oben Unten