Allgemeiner Linux Frage-, Antwort- und Diskussionsthread

[Simon Moon]

Collectd wäre noch eine Alternative. Ist im Gegensatz zu Munin opportunistisch, d.h. die Daten werden je nach gewähltem Frontend erst bei Abruf/Aufruf verarbeitet/gerendert, bzw. können sogar lastmäßig auf die Clients (Browser) ausgelagert werden.


Hm. Ich denke, das wär wohl weniger das Problem. Rechenleistung hab ich auf dem Server noch genug. Was mir z.b. wichtig wär, dass ich nicht auf jedem gemonitoreten PC einen Webserver einrichten, TLS Zertifkte erstellen usw. muss, sondern effektiv nur die Daten abholen kann. Mir ist da nicht mal Echtzeit wichtig, von mir aus können die Daten gerne so 1x stündlich per Mail verschickt werden.



Interessant tönen bis jetzt alle drei Optionen - aber mir ist noch nicht so klar, wo denn nun die Stärken und Schwächen liegen. Und wenn ich zuerst mal ausprobieren müsste, würd ich im Zweifel auf die am wenigsten invasive Option setzen.



Hatte z.b. mal Cockpit und Nagios ausprobiert - Cockpit war zwar hübsch, aber irgendwie scheint es keine wirkliche Community zu geben, die Dokumentation ist auf den zweiten Blick relativ "dünn" und auch die Features sind... nun ja könnten besser implementiert sein. Nagios bietet dann wohl relativ viele Features, aber erfordert auch einen Webserver etc., was mir dann zuviel ist.

[HeldImZelt]

Was mir z.b. wichtig wär, dass ich nicht auf jedem gemonitoreten PC einen Webserver einrichten, TLS Zertifkte erstellen usw. muss, sondern effektiv nur die Daten abholen kann.
Das unterstützen doch fast alle: Munin, Collectd Graph Z, usw..
Collectd als reiner Datenerhebungsdienst eröffnet halt deutlich mehr Freiheiten und Kontrolle über die weitere Verarbeitung.

[Simon Moon]

Das unterstützen doch fast alle: Munin, Collectd Graph Z, usw..
Collectd als reiner Datenerhebungsdienst eröffnet halt deutlich mehr Freiheiten und Kontrolle über die weitere Verarbeitung.


Hm. Das tönt eigentlich ganz interessant. Ich hab da einfach kein Übersicht und meist ergibt sich aus einer geklärten Frage, nur die zwei nächsten.




Irgendwie fehlt mir da auch häufig eine kritische Quelle. Entweder sind die Blogs und Webseiten die ich finde inhaltlich gut brauchbar, bieten dann aber meist nur relativ wenig Beiträge, häufig auch schon Jahre bis Jahrzehnte ohne update oder es sind diese typischen Clickbaits, welche "Die 10 wichtigsten Bash Befehle" bringen und dir dann ls vorstellen. Bleibt natürlich noch die jeweils eigene Dokumentation, aber das bedeutet dann quasi sich in jede Lösung mal einzulesen um einen Überblick zu erhalten.



Irgendsowas wie heise nur für Linux wäre toll, eine Mischung halt aus "seicht genug um es überfliegen zu können" aber inhaltlich doch noch so anspruchsvoll, dass ich mir nicht verarscht vorkomme. Halt auch mal ein Thema behandeln ohne gleich konkrete Tutorials zu geben und doch nicht so flach, dass die apt Beschreibung etwa ähnlich aussagekräftig ist..

[vanquish]

Hmm ... das Standardwerkzeug ist collectd. Und das ist nicht wirklich schlecht dokumentiert. Ich sehe den Vorteil auch in der Last.

https://collectd.org/wiki/index.php/Main_Page

Der wesentliche Unterschied zwischen z. B. Munin und collectd ist, dass Munin "pullt" (holt sich allle x Minuten die Daten von den Clients) und collectd "pusht" (jeder client sendet alle x Minuten die Daten an den Server).

Bei Munin, hat man also alle x Minuten eine mehr oder weniger große Last (je nach Anzahl der Clients).

Und soweit ich mich erinnere (lange her, k. A. ob das mittlerweile anders ist) kann man bei den Graphen von Munin, ohne entsprechende Last, ad-hoc keine Zeiträume für die Graphen definieren, da Munin diese als statische Bilder generiert (was jedes mal Last erzeugt). Bitte berichtigen, wenn falsch. Hab' grad keine Lust zu suchen. :D

EDIT: Munin ist aber einfacher zu konfigurieren!

[aufkrawall]

*bump* :redface:
Kuriose Frage zwischendurch:
Könnt ihr euch auf dieser Seite Wörter vorlesen lassen?
https://tophonetics.com/
Weder mit Firefox noch Chromium kommt hier etwas aus den Lautsprechern und das Playback anderer Programme wird sogar durch Artefakte gestört bzw. anhaltend zerstört. :freak:
Seiten wie dict.cc gehen. wtf? :redface:

Btw: Hab ein Notebook Celeron Prozessor N4000 (UHD 600 GPU) da: Der Intel-Treiber verursacht Flackern am oberen Bildschirmrand und in mpv gibts, anders als in VLC, immer noch Ruckler. Reiht sich nahtlos ein in meine Reihe schlechter Erfahrungen mit Intel + Linux, imho völlig überbewertet.

[iuno]

Bin ich gerade nur zu bloed zum Suchen oder kann man chromium nicht mehr mit >60 FPS rennen lassen? --disable-gpu-vsync tat es mal, jetzt aber offenbar nicht mehr.

[aufkrawall]

Läuft hier mit 75Hz/fps, ist allerdings auch die einzig verfügbare Refreshrate in der edid.

[iuno]

Danke, wenn 144 Hz der einzige Eintrag in der EDID ist geht es in Chromium tatsaechlich. Dabei dachte das mit der EDID hat sich mit Polaris erledigt. Fuer qutebrowser (chromium benutze ich eh nicht), bringt es leider nichts. Aber das gibt sich hoffentlich mit einem neuen Qt Release. So wichtig ist es mir auch nicht, nur halt wieder mal nervig.

[aufkrawall]

Ist denn 144Hz an erster Stelle in der edid? In CRU kann man ja einfach die Reihenfolge ändern. Wenn Programme im Fenster eine abweichende Refreshrate annehmen, ist das natürlich trotzdem dämlich.

[Rooter]

Noob-Frage:

Ich habe begriffen, dass Wildcard-Befehle wie z.B. ls -d ???* von der Shell ausgewertet und alle sich aus ???* ergebenden Dateien an ls übergeben werden.
Aber was passiert wenn die Kommandozeile dabei wegen zu vieler (tausender) Dateien zu lang wird? Und wie umgeht man dieses Problem in der Praxis?

MfG
Rooter

[Ganon]

Aber was passiert wenn die Kommandozeile dabei wegen zu vieler (tausender) Dateien zu lang wird?

Dann kommt die Meldung "Too many arguments". Man kann hier dann z.B. mittels find -exec arbeiten, um pro Datei einen Befehl auszuführen. Was optimal ist, kommt immer auf den konkreten Anwendungsfall an.

[BBig]

Nach knapp 2 Jahren hatte ist das erste Mal "Probleme" mit Arch.

Ab und zu dead locks und random restarts. Erster Blick auf die SDD - die ist voll? :confused:
Nach hin und her suchen, den Schuldigen gefunden: CUPS!

Ein "Spezi" hatte in der default Konfiguration wirklich nachgedacht:
In der /etc/cups/cupsd.conf die

// MaxLogSize 0
// LogLevel debug


Nach 2 Jahren knapp 40 GB an Cups-Logs, :tongue:

[Ganon]

Oder einfach logrotate installieren ;)

[iuno]

Ist denn 144Hz an erster Stelle in der edid? In CRU kann man ja einfach die Reihenfolge ändern.
Ne, aber ist ja grad egal. Wenn ich eh ein custom EDID brauche nehme ich das mit nur einem Eintrag.

Ein "Spezi" hatte in der default Konfiguration wirklich nachgedacht:
In der /etc/cups/cupsd.conf die

// MaxLogSize 0
// LogLevel debug


Nach 2 Jahren knapp 40 GB an Cups-Logs, :tongue:
Gut dass ich fast nix drucke und CUPS nur bei Bedarf starte ;) Wobei ich logrotate eh auch drauf haette.

Auch sowas kann man als Bug melden. Ist auch offensichtlich ein Packaging-Problem. Der Maintainer deaktiviert die eingebaute logrotation (der Kommentar ist irrefuehrend) und verlaesst sich auf logrotate (entsprechende config kommt ja auch mit), ohne es aber als Abhaengigkeit eingetragen zu haben. Insofern eigentlich ganz guter Fund ;)

[BBig]

Oder einfach logrotate installieren ;)
...
Auch sowas kann man als Bug melden. Ist auch offensichtlich ein Packaging-Problem. Der Maintainer deaktiviert die eingebaute logrotation (der Kommentar ist irrefuehrend) und verlaesst sich auf logrotate (entsprechende config kommt ja auch mit), ohne es aber als Abhaengigkeit eingetragen zu haben. Insofern eigentlich ganz guter Fund ;)

Die "übergroßen" Logs waren schnell gefunden, ich hatte dann reingeschaut:
Ich glaube, das Problem ist noch nicht mal MaxLogSize 0, selbst mit logrotate sollte es nicht auf "unlimited" stehen, imo.
Das Problem ist LogLevel debug, in den Logs stand jeder "Pups" drin, :tongue:

[Charlie Chaplin]

Hallöle,
ich befinde mich gerade inmitten eines erneuten Versuches mich von Windows loszusagen und stoße bei Ubuntu 18.10 auf folgendes Problem:

Ich möchte die rückseitigen Audioausgänge so belegen, dass sowohl LineOut als auch MicIn zeitgleich Ton ausgeben. Ich habe bereits mittels hdajackretask MicIn zu einem Kopfhörerausgang 'umgemappt'. Das funktioniert gut, allerdings nicht zeitgleich mit dem LineOut. Wenn an LineOut und MicIn Geräte angeschlossen sind, bleibt der LineOut stumm und wird in der Lautstärkeregelung als 'unplugged' angezeigt. Ziehe ich dann den Stecker aus MicIn, erklingt aus LineOut augenblicklich Ton. Unter Windows habe ich es mit Einträgen in der Registry hinbekommen, eine Hardwarelimitierung liegt also nicht vor.
Hat jemand eine Idee wie ich beide zugleich zum Erklingen bringen kann? Kann man beide vll zu einem virtuellen Ausgang zusammenschließen, so wie paprefs unterschiedliche Ausgabegeräte (nicht Ausgänge) zu einem zusammenschließt?

[aufkrawall]

Das hier schon gesehen?
https://wiki.archlinux.org/index.php/PulseAudio/Examples#Having_both_speakers_and_headphones_plugged_in_and_switching_in_softwar e_on-the-fly

[iuno]

Die "übergroßen" Logs waren schnell gefunden, ich hatte dann reingeschaut:
Ich glaube, das Problem ist noch nicht mal MaxLogSize 0, selbst mit logrotate sollte es nicht auf "unlimited" stehen, imo.
Das ist schon richtig so, wenn logrotate benutzt wird soll das Programm schliesslich alles nur rausschreiben und logrotate kuemmert sich dann darum, sobald die Logs zu alt oder zu gross werden.

Das Problem ist, wie schon gesagt, dass mit der Paketkonfiguration logrotate vorausgesetzt, diese Voraussetzung aber im Paket nicht abgebildet wird. Und das sollte man dem Maintainer schon melden. Der sollte dann entweder wieder ein Maximum setzen oder logrotate als Abhaengigkeit eintragen.

[Ganon]

Wenn dann wäre die allgemeinere Lösung den Log-Punkt auf syslog umzustellen, dann braucht man auch kein logrotate. Der Maintainer setzt hier nämlich keine spezielle Konfig sondern nutzt die Standard-Config mit der Cups halt kommt. D.h. wenn dann müsste man das cups melden.

Pacman müllt dir ohne weitere Konfig auch die Platte mit distfiles zu.

edit:
Übrigens ist die Standard-Einstellung für Logs in Cupsd "LogLevel warn". Das "LogLevel debug" kommt dementsprechend nicht vom Paket.

[iuno]

Nein, das stimmt nicht. Vom PKGBUILD aus wird die Zeile+Kommentar in die CUPS config geschrieben. Cupsd default ist 1MiB.

[Ganon]

OK, das stimmt. Aber das LogLevel debug kommt trotzdem nicht vom Paket.

[iuno]

Das hatte ich auch nicht behauptet. Vielleicht hat BBig das mal gesetzt und vergessen?

[Ganon]

Gerade mal nachgesehen: logrotate ist Bestandteil von base... warum fehlt das bei BBig bzw. funktioniert nicht?

[iuno]

Ah, das hatte ich nicht ueberprueft. Vielleicht ist es daher auch nicht als Abhaengigkeit eingetragen ist. Wobei ich das immer schon ein bisschen bloed fand, denn man kann base-Pakete manuell und auch mal versehentlich deinstallieren, und damit geht die Abhaengigkeitsaufloesung halt kaputt, wenn man weiterhin davon ausgeht, base sei immer komplett da.
Guidelines sagen daher iirc auch, dass man Pakete aus base trotzdem eintragen soll und nur base-devel Pakete nicht in makedeps.

Vielleicht ist es bei ihm aber auch installiert und es wurde nur irgendwann mal der service deaktiviert.

[BBig]

Ich kann mich nicht daran erinnern, wenn ich das letzte mal - außer jetzt wegen den großen Logs - in die /etc/cups/cupsd.conf geschaut hätte.


Mit logrotate machte mich dann doch stutzig.

systemctl status logrotate.timer
● logrotate.timer - Daily rotation of log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: disabled)
Active: active (waiting) since Tue 2018-12-11 08:07:20 CET; 3 days ago
Trigger: Sat 2018-12-15 00:00:00 CET; 40min left
Docs: man:logrotate(8)
man:logrotate.conf(5)

systemctl status logrotate.service
● logrotate.service - Rotate log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor pr>
Active: inactive (dead) since Fri 2018-12-14 00:00:32 CET; 23h ago
Docs: man:logrotate(8)
man:logrotate.conf(5)
Process: 3241 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited,>
Main PID: 3241 (code=exited, status=0/SUCCESS)
Hmm, :rolleyes:

logrotate -fv /etc/logrotate.conf
...
rotating pattern: /var/log/cups/*_log forced from command line (4 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/cups/access_log
Now: 2018-12-14 23:21
Last rotated at 2018-12-09 00:00
log needs rotating
considering log /var/log/cups/error_log
Now: 2018-12-14 23:21
Last rotated at 2018-12-09 00:00
log needs rotating
considering log /var/log/cups/page_log
Now: 2018-12-14 23:21
Last rotated at 2018-12-09 00:00
log needs rotating
...
Hmm, :rolleyes:

Verstehe ich richtig: logrotate.timer (wie ein conjob? legt zeiten fest) stößt logrotate.service an? Und auch wenn logrotate.service dead ausweist, dann ist das ok, da ja die Logs erst kürzlich rotiert wurden?
Erklärt aber dann nicht die riesigen Cups-Logs nach fast 2 Jahren. Die hätten ja dann - selbst mit LogLevel debug - aufgeräumt werden müssen. Dann wären ja max 4 Wochen in den Logs nach:

[root@knot bbig]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# restrict maximum size of log files
#size 20M <-- sowas halte ich persönlich immer für nicht Entwickler sinnvoll
...

[iuno]

Ja, fast alles richtig, bis auf den Punkt, dass du Logs von max. 4 Wochen haben solltest. Es sind 4 Wochen, die bereits "wegrotiert" wurden + das aus der aktuellen Woche.

Hat es denn jetzt nach dem manuellen Anstossen funktioniert?

[BBig]

Danke iuno.
Ja, schaut gut aus, :smile:

[bbig@knot /]$ ls -lha /var/log/cups/
insgesamt 1,5M
drwxr-xr-x 2 root root 4,0K 16. Dez 00:19 .
drwxr-xr-x 17 root root 4,0K 14. Dez 23:21 ..
-rw-r--r-- 1 root cups 0 14. Dez 23:21 access_log
-rw-r--r-- 1 root cups 810 13. Dez 07:03 access_log.1
-rw-r--r-- 1 root cups 429 5. Dez 10:35 access_log.2
-rw-r--r-- 1 root cups 557 2. Dez 17:55 access_log.3
-rw-r--r-- 1 root cups 429 5. Nov 15:33 access_log.4
-rw-r--r-- 1 root cups 0 14. Dez 23:21 error_log
-rw-r--r-- 1 root cups 546K 15. Dez 14:22 error_log.1
-rw-r--r-- 1 root cups 257K 9. Dez 07:03 error_log.2
-rw-r--r-- 1 root cups 465K 3. Dez 17:57 error_log.3
-rw-r--r-- 1 root cups 134K 23. Nov 10:36 error_log.4
-rw-r--r-- 1 root cups 0 14. Dez 23:21 page_log
-rw-r--r-- 1 root cups 198 13. Dez 07:03 page_log.1
-rw-r--r-- 1 root cups 125 5. Dez 10:35 page_log.2
-rw-r--r-- 1 root cups 131 2. Dez 17:55 page_log.3
-rw-r--r-- 1 root cups 220 5. Nov 15:34 page_log.4


Früher hätte mich das noch *wahnsinng* gemacht: warum "auf einmal" so große Logs; wieso ist logrotate nicht eingeschritten...
Heute: Fixed, schaut gut aus - funktioniert - done :tongue:

[aufkrawall]

Für Radeons kann man btw. mittels radeontop GPU-Auslastung und VRAM-Belegung auslesen:
https://github.com/clbr/radeontop
https://aur.archlinux.org/packages/radeontop/
Die gemeldete GPU-Auslastung scheint mit Polaris auch plausibel zu sein, anders als der Wert von amdgpu in sysfs.

[BBig]

BTW: https://aur.archlinux.org/packages/sway-git/ letzer Kommentar:
SirCmpwn commented on 2018-12-15 14:17
It was moved to community.

==> https://www.archlinux.org/packages/community/x86_64/sway/

Freue mich drauf! :D

[iuno]

Sway an sich ist schon lange in den Repos. Das ist halt noch die pre-1.0 ohne wlroots. Bei dem Kommentar ging es um eine Abhaengigkeit, die vom AUR in [community] gewandert ist.

[BBig]

Oh, dann habe ich das wohl falsch verstanden; hatte nur gesehen, dass das Community-Package aktueller geupdated wurde als das git aus dem AUR.


BTW schon den *hardware-p0rn* by ARM sponsored by Gigabyte gesehen? :eek:

vCodnn0HOyI

Selbst Wendell ist aus dem Häuschen.
Ich denke, das wird so 10k+kommen, dann fehlt "nur noch" der RAM und Storage. :tongue:

Ich fände einen ARM-Laptop super. CPU-Power brauche ich nicht, aber mal ne anständige Akkulaufzeit wäre toll!

[iuno]

Was ist anstaendig? Gibt auch Intel-Notebooks mit guten Laufzeiten, die sind zugegebenermassen halt recht teuer.
Ansonsten gibts ja glaube ich auch halbwegs aktuelle Chromebooks mit ARM, weiss aber nicht, wie frei die sind/sich machen lassen. Chromebooks haben aber leider oft wenig Speicher. Vielleicht kommt auch was nettes mit Qualcomm's neuem Notebook-SoC. Falls mit Windows allerdings vermutlich ohne Chance auf offenen bootloader, wie man das schon von WinRT kannte.

Grundsaetzlich sollte man da als Linux-Nutzer auch eher weniger Probleme haben als mit Windows. Die Software, die man hauptsaechlich benutzt ist eh frei und laesst sich groesstenteils fuer ARM kompilieren. Was es dann nicht in den Repos gibt, gibt es halt nicht. Mir waere es daher grundsaetzlich auch ziemlich egal, ob es nun ARM oder x86 ist.
Es bleiben Probleme wie dass Browser vergleichsweise schlechte Hardwarebeschleunigung am Linux Desktop haben.

[aufkrawall]

Es bleiben Probleme wie dass Browser vergleichsweise schlechte Hardwarebeschleunigung am Linux Desktop haben.
Hm? Bei Chromium ist eher das Gegenteil der Fall (bis auf Video), scrollt unter Linux wesentlich besser als unter Windows. Das Firefox-Rendering läuft auf lahmen GPUs unter Linux ebenfalls mit weniger Rucklern. Gibt halt ohne WebRender nur kein D2D-Äquivalent, braucht man aber auch nicht zwingend.
Konnte das mit Cherry Trail und Gemini Lake eindeutig so feststellen. Die haben btw. auch sehr lange Akkulaufzeiten auf Kosten der Performance, wobei Goldmont Plus schon ein netter Sprung war.

[Ganon]

ARM hat eher das Problem, dass die Grafiktreiber oft nicht nur geschlossen, sondern auch totaler Müll sind. Für den Arbeits-PC hätte ich prinzipiell auch keine Probleme mit einer ARM CPU, würde es aber nicht mögen, wenn mich ein geschlossener Grafiktreiber an eine einzige Kernel-Version bindet.

Privat ist das Problem "als PC Ersatz", dass Steam und GOG nicht auf ARM funktionieren. Hier müsste für die ferne Zukunft noch die Usermode-Emulation besser werden.

[iuno]

Schon richtig, aber GOG und Steam spielen da wohl keine Rolle, wenn man schon sagt, dass Laufzeit ueber der Leistung steht.

IIRC verwendet das aktuelle Google Pixel jetzt einen mainline DRM Treiber. Das betrifft zwar nur den Kernel-Space aber Freedreno macht sich glaube ich schon. Klar, realistisch gesehen haengt der noch bei GL 3.1 und hat keinen Vulkan Treiber, Video weiss ich nicht. Aber jetzt, wo Google contributet koennte das schon eine (ueberfaellige) Wende in dieser Hinsicht andeuten. Ich bin mal gespannt, ob da nicht wirklich was nettes kommt mit dem neuen Snapdragon. Und wenn die Geraetehersteller dann merken, dass das ja viel einfacher ist, Mainline Treiber zu verwenden (so sie denn fertig sind) wird fuer die der Snapdragon auch gleich nochmal interessanter. Da muessen die anderen SoC/GPU Hersteller vielleicht irgendwann nachziehen.

Edit: ja, ist das Pixel 3. Collabora hat auch seine Rolle gespielt. Offenbar hat Google da auch klare Plaene fuer die Zukunft ("All boards in AOSP are DRM/KMS atomic modesetting based", "All Q kernels have prerequisite DRM/KMS changes") https://linuxplumbersconf.org/event/2/contributions/229/attachments/53/60/10._DRM_KMS_for_Android_v1.pdf

@aufkrawall: Ich meinte Video, das allein macht halt schon einiges aus. OK, sonst hast du da sicherlich mehr aktuelle Erfahrungen als ich.

[aufkrawall]

Von Video im Browser halte ich in der Leistungsklasse auch unter Windows Abstand, der Overhead für die Einbettung in der Browserengine ist sowohl für CPU als auch GPU lächerlich hoch (außer bei Edge).
Ich würd ja jetzt auf mpv verweisen, aber, wie vor ein paar Seiten schon erwähnt, liefert der Intel-Treiber unter Linux für das Programm notorisch ein Trauerspiel ab. Nicht mal 1080p 60fps H.264 laufen ruckelfrei, während unter Window problemlos 4k 60fps VP9 gehen (Gemini Lake).
Ich würd aber auch befürchten, dass man die Treiber für ARM-SoCs in der Hinsicht sowieso komplett vergessen kann.

[Ganon]

Schon richtig, aber GOG und Steam spielen da wohl keine Rolle, wenn man schon sagt, dass Laufzeit ueber der Leistung steht.

Naja, mein Problem ist die Nische in die so ein Gerät soll. Generell kann man Akkulaufzeit stark beeinflussen:

- die Anzahl und Leistungsfähigkeit der Komponenten rund um die CPU
- Leistung der CPU
- Größe des Akkus / Größe des Geräts

Leider tendiert man irgendwie dazu die sparsamen CPUs immer in die kleinstmöglichen Geräte mit ebenso kleinstmöglichem Akku zu stecken. Ich hab zumindest noch kein Intel Atom in einem gewöhnlichen Notebook Gehäuse gesehen. Das ist immer alles so Tablet / NetBook Style. Das Gleiche trifft auch auf die ARM Geräte zu.

Wäre doch vermutlich kein Problem ein ARM Notebook auf den Markt zu bringen, was locker 2 Tage oder mehr Laufzeit hat, wenn so ein Tablet-Verschnitt schon auf fast einen Tag kommt. Kommt aber irgendwie auch nicht. Und ich kann ehrlich gesagt auch nicht verstehen, warum es das nicht gibt, wenn Laufzeit dann doch so wichtig ist. Ein x86 System wäre dann vermutlich irgendwo bei einem Tag dann. Und dann könnte man wieder überlegen wie lange ein Akku eigentlich halten müsste.

Ist imo alles gar nicht so ideal gelöst, wenn man so im Detail schaut.

Ich würd ja jetzt auf mpv verweisen, aber, wie vor ein paar Seiten schon erwähnt, liefert der Intel-Treiber unter Linux für das Programm notorisch ein Trauerspiel ab. Nicht mal 1080p 60fps H.264 laufen ruckelfrei, während unter Window problemlos 4k 60fps VP9 gehen (Gemini Lake).

Das "Gemini Lake" solltest du aber eher nach vorne ziehen und nicht hinten dran hängen ;) Das ist kein allgemeines Problem.

[aufkrawall]

Das "Gemini Lake" solltest du aber eher nach vorne ziehen und nicht hinten dran hängen ;) Das ist kein allgemeines Problem.
Ich hatte das schon irgendwann letztes Jahr u.a. mit meiner 6700k-IGP festgestellt.

[Ganon]

Ich hatte das schon irgendwann letztes Jahr u.a. mit meiner 6700k-IGP festgestellt.

Es ist trotzdem ein Unterschied ob etwas "notorisch" ist, oder halt mal vorkommen kann. Du neigst halt gerne zu völliger Übertreibung.

[aufkrawall]

Es ist trotzdem ein Unterschied ob etwas "notorisch" ist, oder halt mal vorkommen kann. Du neigst halt gerne zu völliger Übertreibung.
Und du zu empfindlichen Reaktionen, wenn etwas gegen Intel geht. Ich hab das Problem oft genug feststellen können, um die Beschreibung "notorisch" zu wählen. Mittlerweile sind die Windows-Treiber von Intel besser, einfach mal mit abfinden.

[Ganon]

Und du zu empfindlichen Reaktionen, wenn etwas gegen Intel geht. Ich hab das Problem oft genug feststellen können, um die Beschreibung "notorisch" zu wählen. Mittlerweile sind die Windows-Treiber von Intel besser, einfach mal mit abfinden.

Das hat weniger was mit Intel oder den Windows Treibern zu tun. Ich hab ebenso viele Systeme mit Intel CPUs in der Hand und keins davon hat die von dir genannten Probleme und bei vielen ist sogar die Hauptaufgabe eben genau Videos abzuspielen. Vielleicht hast du auch einfach nur mit diversen Patches und Custom-Krams irgendwelche Seiteneffekte eingefangen oder was anderes kaputt gemacht? Schon mal über Bug-Reports mit den Entwicklern Kontakt aufgenommen?

"Notorisch" ist halt einfach eine extreme Übertreibung... einfach damit abfinden... ;)

[iuno]

Seit ich jetzt das Notebook mit KBL habe (jetzt gerade ein Jahr), sind mir auch keine derartigen Probleme aufgefallen. Damit arbeite ich aber zugegebenermassen auch mehr, als ich konsumiere. Davor hatte ich im NB noch Sandy Bridge, das habe ich wenig benutzt und noch weniger auf sowas geachtet, aber auch keine Auffaelligkeiten gehabt.

Leider tendiert man irgendwie dazu die sparsamen CPUs immer in die kleinstmöglichen Geräte mit ebenso kleinstmöglichem Akku zu stecken. Ich hab zumindest noch kein Intel Atom in einem gewöhnlichen Notebook Gehäuse gesehen. Das ist immer alles so Tablet / NetBook Style. Das Gleiche trifft auch auf die ARM Geräte zu.
Ja, ich hatte ja oben schon geschrieben, dass man lange Laufzeiten auch mit Intel bekommen kann.
Das mit den unsinnigen Konfigurationen zieht sich leider schon lange durch den Markt. Wer hohe Laufzeit will soll entsprechend viel fuer ein Ultrabook bezahlen, demnach steckt auch ein Core iX drin. Allerdings muss man auch sagen, dass, wenn die Laufzeit so ein ausschlaggebendes Kriterium ist, man das halt machen kann und mit einem Ultrabook ueber den ganzen Tag kommt. Wenn Leistung keine Rolle spielt, wird die CPU ja nicht beansprucht und ist auch entsprechend sparsam. Bleibt halt der Punkt, dass man fuer einen Core-i bezahlt aber eigentlich nur einen Atom braucht.

[aufkrawall]

Vielleicht hast du auch einfach nur mit diversen Patches und Custom-Krams irgendwelche Seiteneffekte eingefangen oder was anderes kaputt gemacht?

Nein, alles standard. Schon testweise alle Energiesparmodi abgeschaltet sowie den Compositor, ist alles egal. Problem (Ruckler in 60fps-Video@60Hz) gibts nur mit mpv, VLC ruckelt nicht. mpv läuft aber korrekt mit AMD, Nvidia und sogar Nouveau, wenn man es nicht übertreibt. Ergo liegts an Intel, und das schon ziemlich lange.
Es hilft mir auch null, wenn andere User das Problem angeblich nicht haben.


Schon mal über Bug-Reports mit den Entwicklern Kontakt aufgenommen?

Haben andere schon gemacht, bei den i915-Entwicklern rennt man wohl allgemein nicht gerade offene Türen ein. Wahrscheinlich wieder so ein für die Linux-Welt notorisch-typisches (deal with it :cool: ) Vsync-Fuckup.

[Ganon]

Es hilft mir auch null, wenn andere User das Problem angeblich nicht haben.

Wenn du außer meckern auch mehr Infos geben würdest, könnte man dir vielleicht sogar helfen. ;) Und wenn es in mpv ruckelt und in VLC nicht, dann kann es auch ganz woanders liegen. Die Intel GPUs sind alle recht unterschiedlich und was auf einer GPU gut performt, muss auf der anderen nicht ebenso gut laufen. Gerade bei den SoC-Modellen.

Haben andere schon gemacht

Hast du mal einen Link?

[aufkrawall]

Wenn du außer meckern auch mehr Infos geben würdest, könnte man dir vielleicht sogar helfen. ;) Und wenn es in mpv ruckelt und in VLC nicht, dann kann es auch ganz woanders liegen. Die Intel GPUs sind alle recht unterschiedlich und was auf einer GPU gut performt, muss auf der anderen nicht ebenso gut laufen. Gerade bei den SoC-Modellen.

Ich hab es getestet auf Gen 9 (Desktop), Gen 9.5 (Mobile) sowie Gen 8 (Mobile). afair früher auch mal auf Gen 8 (Deskop) mit schon dem gleichen Ergebnis.
Wie soll mir da ein hilfsbereiter Mensch im Internet weiterhelfen können, wenn der Treiber einfach zu doof ist, Frames unter bestimmten Voraussetzungen in festen Intervallen auszugeben? :freak: :redface:
Schau dir einfach 60fps Videos wie Big Buck Bunny an und achte darauf, ob du irgendwelche Ruckler bemerkst.


Hast du mal einen Link?
https://github.com/mpv-player/mpv/issues/6037#issuecomment-440032629
(Die RedShift-Sache mit Atomic Modesetting ist auch wieder so ein Epic Fail der Linux-Welt. Man stellt mal wieder ersatzlos auf etwas grundlegend neues um, eh es überhaupt richtig fertig ist...)

[Ganon]

Siehst, du unterschlägst in deinen Aussagen mal eben eine Tonne von Informationen und Variablen und sagst schlicht "ist nicht in der Lage 1080p 60fps Content ruckelfrei abzuspielen". Dass es hier um das mpv-interne Resampling geht erwähnst du gar nicht erst.

Gerade bei einem 60fps Video hängt es halt eben schon stark davon ab, was dein Monitor für eine tatsächliche Wiederholrate hat, wenn du Resampling ohne Interpolation anwerfen willst. Bei meinem "echten" 60Hz Screen kann ich zumindest keinen Ruckler wahrnehmen.

An meinem externen ~59,95Hz Screen schon. Jedoch macht mpv hier teils echt seltsame Sachen. Im Log (-v Parameter) steht, dass er ständig neue Hz-Raten ermittelt hat und somit ständig das Resampling umstellt. Es dauert dann eine Weile bis sich das auf einen "echten" Wert eingependelt hat.

RetroArch z.B. ermittelt im Menü bereits im Vorfeld die tatsächliche Hz-Zahl des Monitors anhand mehrerer Messungen. Nimm dann z.B. einfach mal einen Sidescroller (Super Mario Bros, Gradius, R-Type, whatever) und suche dann dort mal nach Rucklern. Ich kann dort zumindest sowohl bei 60Hz als auch bei 59,95Hz keine Ruckler wahrnehmen.

Ich würde eher vermuten, dass mpv bei Intel Probleme hat für das Resampling die tatsächliche Wiederholrate zu ermitteln und sich ggf. sogar auf einen falschen Wert einigt. Darfst aber natürlich gerne weiter meckern, statt auf Ursachenforschung zu gehen ;)

[aufkrawall]

Siehst, du unterschlägst in deinen Aussagen mal eben eine Tonne von Informationen und Variablen und sagst schlicht "ist nicht in der Lage 1080p 60fps Content ruckelfrei abzuspielen". Dass es hier um das mpv-interne Resampling geht erwähnst du gar nicht erst.

Wo steht, dass es an video-sync=display-resample liegt? In dem verlinkten Bugreport steht nur, dass es dort genutzt wird, nicht, dass es explizit verantwortlich wäre. Und es liegt hier auch nicht daran, sonst hätte ich es erwähnt.


Gerade bei einem 60fps Video hängt es halt eben schon stark davon ab, was dein Monitor für eine tatsächliche Wiederholrate hat, wenn du Resampling ohne Interpolation anwerfen willst.

Quasi jedes Mobile-Gerät hat 60 oder 59,95Hz. Und letzteres ist für 60fps selbst ohne video-sync=display-resample immer noch ziemlich unproblematisch, wenn der Treiber einfach das macht, was er soll.


Bei meinem "echten" 60Hz Screen kann ich zumindest keinen Ruckler wahrnehmen.

Die Frage nach dem Bildschirm ist ziemlich irrelevant, wenn es unter Windows mit demselben (weil eingebauten) Bildschirm mit der gleichen Refreshrate einfach geht. Und unter Linux mit VLC auch...


Darfst aber natürlich gerne weiter meckern, statt auf Ursachenforschung zu gehen ;)
Interessiert offenbar keinen bei Intel, wenn sie es nach mittlerweile ~1,5 Jahren immer noch nicht selbst gemerkt haben. Ich melde auch lieber Dinge an Projekte, von denen ich Fan bin, wozu Intel-GPUs garantiert nicht zählen.

[iuno]

Lustigerweise habe ich gerade zwei Notebooks da, die ziemlich aehnlich ausgestattet sind. Beide haben den i5 KBL-R, beide FHD, eins mit 13", eins mit 14". Das eine hat glatt 60 Hz, das andere 59,x. Das mit 59 ruckelt tatsaechlich bei Big Buck Bunny, das andere ueberhaupt nicht. mpv config ist auch dieselbe. Es ruckelt sichtbar und ist auch an den "dropped frames" im Infotext zu sehen. Damit scheine ich bestaetigen zu koennen, dass es ein Problem gibt als auch, dass es nicht immer auftritt. Wenn ich demnaechst mal Zeit und Lust habe, schaue ich es mir vielleicht mal naeher an.

[Ganon]

Wo steht, dass es an video-sync=display-resample liegt? In dem verlinkten Bugreport steht nur, dass es dort genutzt wird, nicht, dass es explizit verantwortlich wäre. Und es liegt hier auch nicht daran, sonst hätte ich es erwähnt.

Wie soll denn sonst ein 60fps Video auf einem Non-60fps Bildschirm komplett ruckelfrei dargestellt werden? Ohne wird es immer alle X Frames ruckeln oder tearen.

Wenn du bei übereinstimmender Refresh-Rate weiterhin ruckeln hast, dann ist es nicht das Problem was du verlinkt hast. Darum sagte ich: Nicht nur meckern, sondern auch mal ordentlich berichten was du für Probleme hast und dir nicht immer alles aus der Nase ziehen lassen. Ich frag nicht umsonst nach Bug-Reports.

Die Frage nach dem Bildschirm ist ziemlich irrelevant, wenn es unter Windows mit demselben (weil eingebauten) Bildschirm mit der gleichen Refreshrate einfach geht. Und unter Linux mit VLC auch...

Wenn es ein Bug in der Refresh-Raten Erkennung von MPV ist (in der Konstellation), dann ist es dabei unerheblich wie es unter anderen Programmen oder Betriebssystemen ist. Unter Windows wird garantiert nicht der X11 oder Wayland Pfad aufgerufen.

Interessiert offenbar keinen bei Intel, wenn sie es nach mittlerweile ~1,5 Jahren immer noch nicht selbst gemerkt haben. Ich melde auch lieber Dinge an Projekte, von denen ich Fan bin, wozu Intel-GPUs garantiert nicht zählen.

Es hilft aber auch nichts einfach nur die Schuld woanders hin zu schieben, nur weil es dein Lieblingsprojekt einfach nicht sein kann, deiner Meinung nach... Wie gesagt, warum kriegt es denn RetroArch und auch andere Resampling-Emulatoren (z.B. snes9x) ruckelfrei hin? Wäre doch bei einem generellen Treiber-Problem unmöglich?

[aufkrawall]

Wie soll denn sonst ein 60fps Video auf einem Non-60fps Bildschirm komplett ruckelfrei dargestellt werden? Ohne wird es immer alle X Frames ruckeln oder tearen.

Aber nur alle x Minuten oder Stunden, und nicht alle paar Sekunden.
Btw. hab ich nochmal nachgeschaut, bei dem Gemini Lake-Notebook sind es 59,994Hz.


Wenn es ein Bug in der Refresh-Raten Erkennung von MPV ist (in der Konstellation), dann ist es dabei unerheblich wie es unter anderen Programmen oder Betriebssystemen ist. Unter Windows wird garantiert nicht der X11 oder Wayland Pfad aufgerufen.

Nochmal: Es ist sehr unplausibel, dass es ein Fehler in mpv wäre, wenn nur Intel-Linux betroffen ist.


Es hilft aber auch nichts einfach nur die Schuld woanders hin zu schieben, nur weil es dein Lieblingsprojekt einfach nicht sein kann, deiner Meinung nach... Wie gesagt, warum kriegt es denn RetroArch und auch andere Resampling-Emulatoren (z.B. snes9x) ruckelfrei hin? Wäre doch bei einem generellen Treiber-Problem unmöglich?
Ich habe nicht gesagt, dass Vsync generell kaputt wäre. Ich weiß jetzt auch nicht, warum du unbedingt noch andere Beispiele bringen willst. Ich habe selber mindestens eines gegeben, das nicht ruckelt. Mal abgesehen davon, dass es nicht besonders gut vergleichbar ist, Video mit Bildrate X mit Refreshrate Y darzustellen vs. Spiel direkt mit Wiederholrate Y zu rendern.

@iuno: Bei meinem Problem gibt es afair allerdings keine Statistik-Auffälligkeiten, es sieht einfach so ruckelig aus.

[Ganon]

Mal abgesehen davon, dass es nicht besonders gut vergleichbar ist, Video mit Bildrate X mit Refreshrate Y darzustellen vs. Spiel direkt mit Wiederholrate Y zu rendern.

Spielekonsolen von damals geben auch mit fester Wiederholrate aus (um die 60Hz +- ~0.1-0.5Hz). Deshalb ist dort auch ein resampling nötig, wenn man keine Ruckler haben will.

Und nein, es gibt auch bei einem Unterschied von ~0.05Hz bei 60 fps Content immer Ruckler alle paar Sekunden, nicht Minuten oder gar Stunden.

[aufkrawall]

Und nein, es gibt auch bei einem Unterschied von ~0.05Hz bei 60 fps Content immer Ruckler alle paar Sekunden, nicht Minuten oder gar Stunden.
Ja, mit mpv ohne display-resample & AMD-Linux ein Framedrop nach 47s. Total vergleichbar zu dem Intel-Geruckel. Nicht. :rolleyes:

So, mal ganz konstruktiv gefragt: Was würdest du mir empfehlen zu tun, wenn ich nun auf dem Gemini Lake-Gerät eine Live-Distribution und boote und das Problem wieder nachvollziehen kann?

[Ganon]

Ich hab gerade mal einen Vorschlag von deinem Link dort befolgt: xf86-video-intel installieren und noch mal probieren. Hat bei mir das besagte Problem gelöst. Ist also wohl irgend ein Problem mpv <-> Modesetting Treiber <-> Intel...

edit: Wenn es denn überhaupt das Problem ist was du hast. Du sagst ja weiterhin nichts.

[aufkrawall]

edit: Wenn es denn überhaupt das Problem ist was du hast. Du sagst ja weiterhin nichts.
Ich habe eindeutig, spätestens über die letzten Posts, zum Ausdruck gebracht, dass mindestens 60fps-Videos in mpv, im Gegensatz zu VLC, hier mit Intel alle paar Sekunden sichtbar ruckeln.

Und jetzt sind wir wieder beim Intel-Evergreen des DDX-Treibers. Kreuz und quer in Linux-Foren wird mal der eine, mal der andere Treiber empfohlen. Quintessenz ist offenbar, dass beide nichts taugen. ;D

[Ganon]

Ich habe eindeutig, spätestens über die letzten Posts, zum Ausdruck gebracht, dass mindestens 60fps-Videos in mpv, im Gegensatz zu VLC, hier mit Intel alle paar Sekunden sichtbar ruckeln.

Nein, du sagst nur dass es ruckelt, dann verlinkst du auf Resampling, dann sagst du es ist ohne Resampling, deine Grundaussage war Anfangs "kann nicht ruckelfrei abspielen", was auch sein kann: Es ruckelt immer. Und dann ruckelt es dann doch ohne Resampling bei dir immer (ist ja logisch), anfangs ja irgendwie nicht. Log-Ausgaben kamen von dir auch nicht, auch keine MPV-Configs.

Und scheinbar interessiert dich eine Lösung sowieso nicht, weil du dann nicht mehr meckern kannst? Probiere es doch einfach aus und wenn es dein Problem löst, fülle die Bug-Reports bei MPV mit konstruktivem Inhalt, statt nur meckern. ;)

[aufkrawall]

Du drehst es dir gerade so, wie es dir am besten passt. Macht wohl keinen Sinn, auf dieser Basis weiter zu "diskutieren". Ich werd es mir dieses Jahr evtl. nochmal mit Logs anschauen, damit auch ein Ganon einsieht, dass es ein Treiber-Bug ist. ;)

Btw. dürften, in aller Bescheidenheit, schon gut ein halbes Dutzend Bugs in mpv u.a. durch mein Feedback gefixt worden sein. Also mal lieber vor der eigenen Tür kehren, von wegen konstruktiv und so.

[Ganon]

Du drehst es dir gerade so, wie es dir am besten passt. Macht wohl keinen Sinn, auf dieser Basis weiter zu "diskutieren". Ich werd es mir dieses Jahr evtl. nochmal mit Logs anschauen, damit auch ein Ganon einsieht, dass es ein Treiber-Bug ist. ;)

Ich hab nirgendwo behauptet, dass es kein Treiber-Bug ist. Ich hab nur Fragen gestellt die du allesamt nicht beantworten konntest und nur ausgewichen bist. Und wenn du entsprechende Bug-Reports nur damit füllst, dass der Intel-Treiber schlecht ist, dann hilft das eben genau niemandem. Vielleicht auch ein Bug im Modesetting-Treiber?

Und ist doch schön, dass du andere Bugs melden konntest. Wenn ich mal zurückdenke was du mal für ein NVidia+madVR Verfechter warst und wie abwertend du über mpv geredet hattest... hatte ich doch ganz guten Einfluss auf dich, nicht? ;D

[aufkrawall]

Und wenn du entsprechende Bug-Reports nur damit füllst, dass der Intel-Treiber schlecht ist, dann hilft das eben genau niemandem.

Ich werte den fehlenden Konjunktiv mal so, dass du es langsam selbst akzeptierst. :P


Und ist doch schön, dass du andere Bugs melden konntest. Wenn ich mal zurückdenke was du mal für ein NVidia+madVR Verfechter warst und wie abwertend du über mpv geredet hattest... hatte ich doch ganz guten Einfluss auf dich, nicht? ;D
Es schwirrt halt viel Unsinn im Netz rum und man muss sich erstmal selbst ein Bild machen. Zumal hatte sich mpv im letzten Jahr rasant weiter entwickelt und ist halt viel schneller als madVR geworden, wenn man komplett vergleichbare Settings (Jinc 2D Scaler-Kernel) nimmt. Dürfte mit --d3d11va-zero-copy ca. Faktor 3-4 sein.

[Darkstar]

Zum Thema mpv, Intel-GPU und Ruckeln unter Linux hatte letztens der Fefe was geschrieben (k. A., ob’s hilfreich ist):
https://blog.fefe.de/?ts=a51b4ed1&css=fefe.css

[aufkrawall]

Nicht hilfreich, aber sehr unterhaltsam. :freak:
Er schreibt wirklich dummes Zeug: --vo=gpu läuft mit dem dumb-mode, der mit Standardeinstellungen genutzt wird, auf jedem Taschenrechner mit vernünftigem Treiber.
Wer auf dem mpv-Tracker blöd daher kommt, wird ziemlich runter geputzt. In den meisten Fällen selbst schuld.

Afair nutzt VLC noch vaapi-glx statt -egl, weshalb es etwa mit AMD noch nicht läuft, mpv aber schon. vaapi nehm ich beim nächsten Versuch nochmal unter die Lupe.

[aufkrawall]

So, habs mir mit Manjaro Xfce live angeschaut:
Ob modesetting oder xf86 DDX spielt hier mit Gemini Lake keine Rolle: Ohne display-resample ist die Bildausgabe mit Intel-Linux offenbar schon bei kleinsten Abweichungen der Refreshrate übelst anfällig und es gibt unregelmäßig alle paar Sekunden Framedrops. Zu Erinnerung: Unter Windows dropt auch ohne display-resample quasi gar nichts bzw. rein rechnerisch bei 60fps@59,994Hz halt nur alle paar Minuten.
Mit display-resample lief es dann allerdings auch unter Linux mehrere Minuten perfekt flüssig, 4k 60fps VP9 @ 1080p-Display wohlgemerkt (zumindest ohne Compositor). Also eigentlich auch ein ziemlich gutes Ergebnis, die Datei war gar mittels Samba (GvFS) übers WLAN geöffnet (Gemini Lake = Low Power 2C 2T CPU). ;)

Sonst hatte ich immer Plasma statt XfCE verwendet, womöglich kann die plasmashell als GPU-Prozess mit ~70MB VRAM-Verbrauch auch noch stören.

VLC verkackt VP9 btw., an mpv führt unter Linux einfach kein Weg vorbei.

[Ganon]

Zum Thema mpv, Intel-GPU und Ruckeln unter Linux hatte letztens der Fefe was geschrieben (k. A., ob’s hilfreich ist):
https://blog.fefe.de/?ts=a51b4ed1&css=fefe.css

Fefe hat im entsprechenden Bug-Report (https://github.com/mpv-player/mpv/issues/6301) vieles falsch gemacht:

1. er hat das Bug-Reporting Template nicht eingehalten
2. er hat überhaupt nicht mit einem mpv "Member" diskutiert, sondern "nur" mit einem Contributor
3. er fährt die Leute direkt im zweiten Kommentar volle Breitseite an

Der Rest wird dann von den "Membern" des Projekts auch ordentlich erklärt. Hier hat sich fefe selbst ein Ei gelegt und wohl auch darum den Bug-Report überhaupt nicht verlinkt.

[iuno]

Dazu kommt die Tatsache, dass er auch einfach ueberhaupt nicht die Docs gelesen hat. Der haette einfach von Anfang an gar nicht erst versuchen sollen, vo umzustellen, sondern hwdec auf auto und alles waere gut gewesen. Der hat mit unvollstaendigem Verstaendnis falsche Annahmen getroffen und darauf basierend gefordert, defaults umzustellen. Und dass er das gleich beleidigt auf seinen Blog spamt damit der Fanclub zum Spammen vorbeikommt, hilft halt auch nicht.

Was mich trotzdem etwas wundert ist, dass die CPU schnell genug zum Dekodieren sein soll, Software-Decoding mit vo=gpu aber trotzdem nicht brauchbar laeuft.

[aufkrawall]

Ich würd nicht davon ausgehen, dass SW-Deocding geht, ohne, dass der SoC irgendwann drosselt. Mit meinem 2C GL ist es schon komplett unmöglich, 1080p 60fps H.264 via SW-Decoding ohne Dutzende Framedrops/s abzuspielen.

Btw. hatte fefe Glück, dass wm4 nicht mehr aktiv ist. Er wäre dermaßen zu Konfetti zerrissen worden.. ;D

[DevilX]

Hab gerade freesync läuft mit Amdgpu/mesa erfolgreich getestet.
Hab dazu den Kernel amd-staging-drm-next kompiliert und Mesa aus dem git gebaut.

Bis jetzt geht allerdings Freesync nur mit OpenGL und nicht mit Vulkan. Spiele unter Wine hab ich auch noch nicht mit Freesync zum laufen bekommen.

[DevilX]

@Aufkrawall

Ich versuche gerade eine edid.bin für meinen Monitor mit angepasstem freesync range unter Linux zu erstellen.
wxEDID scheint ein passendes Tool zu sein. Hab mit xrandr die originale edid ausgelesen und bearbeite sie nun.
Angepasstes Range siehe unten.
Allerdings ist mir noch nicht klar wie ich die Standardfrequenz anpasse.

[aufkrawall]

Ich hab deine Edid mittels CRU angepasst und 1080p 146Hz als Standard-Auflösung hinzugefügt (mit den gleichen Timings, die 144Hz in der Edid hat).

[DevilX]

Sieht gut aus! DANKE!

[aufkrawall]

Schön. :)
CRU ist einfach mega praktisch, das sollte mal jemand nach Linux porten. :D

[DevilX]

wxEDID scheint auch ganz gut zu gehen. Aber so umfangreich ist es nicht ^^.

P.S. hab die 146er Raus genommen scheint nicht mehr syncron zu sein.
Fahre jetzt 144Hz mit dem Range 30-146 wie aus dem Beta Treiber.
Jetzt erst mal genug gebastelt,und ich hoffe bald geht auch Vulkan und Wine.

[aufkrawall]

Hm, wenn 146 als normale Auflösung nicht gehen, wär ich skeptisch, ob es dann im Rahmen der VRR-Range korrekt funktioniert. Sind doch nur 2Hz, wozu der Geiz? :)
Musstest du eigentlich den Git-Stand vom amdgpu DDX-Treiber nehmen?

[DevilX]

Ich hab mir gedacht ich mach es so wie es der Betatreiber macht, das sollte ja gehen.
Ob jetzt 144 oder 146 ist mir total schnuppe, die 30 Hz waren mir wichtig.

Den DDX hab ich auch aus dem Git ob das nötig ist, keine Ahnung.
Außderdem habe ich habe in der X11 config noch die Option hier gesetzt:

Section "Device"
Identifier "AMD"
Driver "amdgpu"
Option "VariableRefresh" "on"
EndSection

https://gitlab.freedesktop.org/kazlaus/xf86-video-amdgpu/issues/1

[iuno]

Danke fuer die Meldung. Ich bin bisher noch nicht dazu gekommen. Aber IIRC wollten die erstmal eine Whitelist benutzen. Schau doch mal, ob du da was findest (vielleicht in der drirc?) und damit ggf. deine Wine-Spiele zum Laufen bekommst.

[DevilX]

/usr/share/drirc.d/00-mesa-defaults.conf hat ne Blacklist für Freesync:

<!--

============================================
Application bugs worked around in this file:
============================================

* Unigine Heaven 3.0 and older contain too many bugs and can't be supported
by drivers that want to be compliant.

* Various Unigine products don't use the #version and #extension GLSL
directives, meaning they only get GLSL 1.10 and no extensions for their
shaders.
Enabling all extensions for Unigine fixes most issues, but the GLSL version
is still 1.10.

* If ARB_sample_shading is supported, Unigine Heaven 4.0 and Valley 1.0 uses
an #extension directive in the middle of its shaders, which is illegal
in GLSL.

* Dying Light and Dead Island Definitive Edition redeclare vertex shader
built-ins (specifically gl_VertexID), which causes the vertex shaders to fail
to compile.

* Applications that are not suitable for adapative sync are blacklisted here.

TODO: document the other workarounds.

-->

<driconf>
<!-- Please always enable app-specific workarounds for all drivers and
screens. -->
<device>
<application name="Unigine Sanctuary" executable="Sanctuary">
<option name="force_glsl_extensions_warn" value="true" />
<option name="disable_blend_func_extended" value="true" />
</application>

<application name="Unigine Tropics" executable="Tropics">
<option name="force_glsl_extensions_warn" value="true" />
<option name="disable_blend_func_extended" value="true" />
</application>

<application name="Unigine Heaven (32-bit)" executable="heaven_x86">
<option name="allow_glsl_extension_directive_midshader" value="true" />
<!-- remove dual_color_blend_by_location if 4.1 ever comes out -->
<option name="dual_color_blend_by_location" value="true" />
</application>

<application name="Unigine Heaven (64-bit)" executable="heaven_x64">
<option name="allow_glsl_extension_directive_midshader" value="true" />
<!-- remove dual_color_blend_by_location if 4.1 ever comes out -->
<option name="dual_color_blend_by_location" value="true" />
</application>

<application name="Unigine Valley (32-bit)" executable="valley_x86">
<option name="allow_glsl_extension_directive_midshader" value="true" />
<!-- remove dual_color_blend_by_location if 1.1 ever comes out -->
<option name="dual_color_blend_by_location" value="true" />
</application>

<application name="Unigine Valley (64-bit)" executable="valley_x64">
<option name="allow_glsl_extension_directive_midshader" value="true" />
<!-- remove dual_color_blend_by_location if 1.1 ever comes out -->
<option name="dual_color_blend_by_location" value="true" />
</application>

<application name="Unigine OilRush (32-bit)" executable="OilRush_x86">
<option name="disable_blend_func_extended" value="true" />
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Unigine OilRush (64-bit)" executable="OilRush_x64">
<option name="disable_blend_func_extended" value="true" />
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Savage 2" executable="savage2.bin">
<option name="disable_glsl_line_continuations" value="true" />
</application>

<application name="Topogun (32-bit)" executable="topogun32">
<option name="always_have_depth_buffer" value="true" />
</application>

<application name="Topogun (64-bit)" executable="topogun64">
<option name="always_have_depth_buffer" value="true" />
</application>

<application name="Dead Island (incl. Definitive Edition)" executable="DeadIslandGame">
<option name="allow_glsl_extension_directive_midshader" value="true" />

<!-- For the Definitive Edition which shares the same executable name -->
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
</application>

<application name="Dead Island Riptide Definitive Edition" executable="DeadIslandRiptideGame">
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
</application>

<application name="Dying Light" executable="DyingLightGame">
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
</application>

<application name="RAGE (64-bit)" executable="Rage64.exe">
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
</application>

<application name="RAGE (32-bit)" executable="Rage.exe">
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
</application>

<application name="Second Life" executable="do-not-directly-run-secondlife-bin">
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Warsow (32-bit)" executable="warsow.i386">
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Warsow (64-bit)" executable="warsow.x86_64">
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Rust" executable="rust">
<option name="glsl_zero_init" value="true"/>
</application>

<application name="Divinity: Original Sin Enhanced Edition" executable="EoCApp">
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Metro 2033 Redux / Metro Last Night Redux" executable="metro">
<option name="allow_glsl_extension_directive_midshader" value="true" />
</application>

<application name="Worms W.M.D" executable="Worms W.M.Dx64">
<option name="allow_higher_compat_version" value="true" />
</application>

<application name="Crookz - The Big Heist" executable="Crookz">
<option name="allow_higher_compat_version" value="true" />
</application>

<application name="Tropico 5" executable="Tropico5">
<option name="allow_higher_compat_version" value="true" />
</application>

<application name="The Culling" executable="Victory">
<option name="force_glsl_version" value="440" />
</application>

<application name="Spec Ops: The Line (32-bit)" executable="specops.i386">
<option name="force_glsl_abs_sqrt" value="true" />
</application>

<application name="Spec Ops: The Line (64-bit)" executable="specops">
<option name="force_glsl_abs_sqrt" value="true" />
</application>

<application name="Kerbal Space Program (32-bit)" executable="KSP.x86">
<option name="glsl_zero_init" value="true"/>
</application>

<application name="Kerbal Space Program (64-bit)" executable="KSP.x86_64">
<option name="glsl_zero_init" value="true"/>
</application>

<application name="Rocket League" executable="RocketLeague">
<option name="glsl_correct_derivatives_after_discard" value="true"/>
</application>

<application name="The Witcher 2" executable="witcher2">
<option name="glsl_correct_derivatives_after_discard" value="true"/>
</application>

<application name="Unreal 4 Editor" executable="UE4Editor">
<option name="allow_glsl_cross_stage_interpolation_mismatch" value="true"/>
</application>

<application name="Observer" executable="TheObserver-Linux-Shipping">
<option name="allow_glsl_cross_stage_interpolation_mismatch" value="true"/>
</application>

<application name="Steamroll" executable="Steamroll-Linux-Shipping">
<option name="allow_glsl_cross_stage_interpolation_mismatch" value="true"/>
</application>

<application name="Refunct" executable="Refunct-Linux-Shipping">
<option name="allow_glsl_cross_stage_interpolation_mismatch" value="true"/>
</application>

<application name="Google Earth VR" executable="Earth.exe">
<option name="allow_glsl_builtin_const_expression" value="true"/>
<option name="allow_glsl_relaxed_es" value="true"/>
</application>

<application name="No Mans Sky" executable="NMS.exe">
<option name="force_glsl_extensions_warn" value="true" />
<option name="allow_glsl_layout_qualifier_on_function_parameters" value="true" />
</application>

<application name="Wolfenstein The Old Blood" executable="WolfOldBlood_x64.exe">
<option name="force_compat_profile" value="true" />
</application>

<application name="ARMA 3" executable="arma3.x86_64">
<option name="glsl_correct_derivatives_after_discard" value="true"/>
</application>

<!-- The GL thread whitelist is below, workarounds are above.
Keep it that way. -->

<application name="Alien Isolation" executable="AlienIsolation">
<option name="mesa_glthread" value="true"/>
</application>

<application name="BioShock Infinite" executable="bioshock.i386">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Borderlands 2" executable="Borderlands2">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Civilization 5" executable="Civ5XP">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Civilization 6" executable="Civ6">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Dreamfall Chapters" executable="Dreamfall Chapters">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Hitman" executable="HitmanPro">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Renowned Explorers: International Society" executable="abbeycore_steam">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Saints Row 2" executable="saintsrow2.i386">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Saints Row: The Third" executable="SaintsRow3.i386">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Saints Row IV" executable="SaintsRow4.i386">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Saints Row: Gat out of Hell" executable="SaintsRow4GooH.i386">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Sid Meier's: Civilization Beyond Earth" executable="CivBE">
<option name="mesa_glthread" value="true"/>
</application>

<application name="The Witcher 2" executable="witcher2">
<option name="mesa_glthread" value="true"/>
</application>

<application name="American Truck Simulator" executable="amtrucks">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Euro Truck Simulator 2" executable="eurotrucks2">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Overlord" executable="overlord.i386">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Overlord 2" executable="overlord2.i386">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Oil Rush" executable="OilRush_x86">
<option name="mesa_glthread" value="true"/>
</application>

<application name="War Thunder" executable="aces">
<option name="mesa_glthread" value="true"/>
</application>
<application name="War Thunder (Wine)" executable="aces.exe">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Outlast" executable="OLGame.x86_64">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Spec Ops: The Line (32-bit)" executable="specops.i386">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Spec Ops: The Line (64-bit)" executable="specops">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Mount and Blade Warband" executable="mb_warband_linux">
<option name="mesa_glthread" value="true"/>
</application>

<!-- around 18% performance increase in min and avg fps, max fps capped at 60fps. -->
<application name="Medieval II: Total War" executable="Medieval2">
<option name="mesa_glthread" value="true"/>
</application>

<!-- min fps ~21 ===> ~27 while standing still in game, also higher gpu load. -->
<application name="Carnivores: Dinosaur Hunter Reborn (wine)" executable="Carnivores-master.exe">
<option name="mesa_glthread" value="true"/>
</application>

<!-- around 30% increase in avg fps -->
<application name="Far Cry 2 (wine)" executable="farcry2.exe">
<option name="mesa_glthread" value="true"/>
</application>

<application name="Talos Principle" executable="Talos">
<option name="mesa_glthread" value="true"/>
</application>
<application name="Talos Principle (Unrestricted)" executable="Talos_Unrestricted">
<option name="mesa_glthread" value="true"/>
</application>

<!-- Adaptive sync blacklist follows below: -->
<application name="gnome-shell" executable="gnome-shell">
<option name="adaptive_sync" value="false" />
</application>
<application name="Desktop — Plasma" executable="plasmashell">
<option name="adaptive_sync" value="false" />
</application>
<application name="kwin_x11" executable="kwin_x11">
<option name="adaptive_sync" value="false" />
</application>
<application name="ksmserver-logout-greeter" executable="ksmserver-logout-greeter">
<option name="adaptive_sync" value="false" />
</application>
<application name="ksmserver-switchuser-greeter" executable="ksmserver-switchuser-greeter">
<option name="adaptive_sync" value="false" />
</application>
<application name="kscreenlocker_greet" executable="kscreenlocker_greet">
<option name="adaptive_sync" value="false" />
</application>
<application name="startplasma" executable="startplasma">
<option name="adaptive_sync" value="false" />
</application>
<application name="krunner" executable="krunner">
<option name="adaptive_sync" value="false" />
</application>
<application name="marco" executable="marco">
<option name="adaptive_sync" value="false" />
</application>
<application name="compton" executable="compton">
<option name="adaptive_sync" value="false" />
</application>
<application name="xfwm4" executable="xfwm4">
<option name="adaptive_sync" value="false" />
</application>
<application name="Enlightenment" executable="enlightenment">
<option name="adaptive_sync" value="false" />
</application>
<application name="mutter" executable="mutter">
<option name="adaptive_sync" value="false" />
</application>
<application name="muffin" executable="muffin">
<option name="adaptive_sync" value="false" />
</application>
<application name="compiz" executable="compiz">
<option name="adaptive_sync" value="false" />
</application>
<application name="Firefox" executable="firefox">
<option name="adaptive_sync" value="false" />
</application>
<application name="Firefox ESR" executable="firefox-esr">
<option name="adaptive_sync" value="false" />
</application>
<application name="Chromium" executable="chromium">
<option name="adaptive_sync" value="false" />
</application>
<application name="Google Chrome" executable="chrome">
<option name="adaptive_sync" value="false" />
</application>
<application name="Iceweasel" executable="iceweasel">
<option name="adaptive_sync" value="false" />
</application>
<application name="Epiphany" executable="epiphany">
<option name="adaptive_sync" value="false" />
</application>
<application name="Konqueror" executable="konqueror">
<option name="adaptive_sync" value="false" />
</application>
<application name="Seamonkey" executable="seamonkey">
<option name="adaptive_sync" value="false" />
</application>
<application name="VLC Media Player" executable="vlc">
<option name="adaptive_sync" value="false" />
</application>
<application name="Totem" executable="totem">
<option name="adaptive_sync" value="false" />
</application>
<application name="Dragon Player" executable="dragon">
<option name="adaptive_sync" value="false" />
</application>
<application name="mpv" executable="mpv">
<option name="adaptive_sync" value="false" />
</application>
</device>
<!-- vmwgfx doesn't like full buffer swaps and can't sync to vertical retraces.-->
<device driver="vmwgfx">
<application name="gnome-shell" executable="gnome-shell">
<option name="glx_disable_ext_buffer_age" value="true" />
<option name="glx_disable_oml_sync_control" value="true" />
<option name="glx_disable_sgi_video_sync" value="true" />
</application>
<application name="Compiz" executable="Compiz">
<option name="glx_disable_ext_buffer_age" value="true" />
<option name="glx_disable_oml_sync_control" value="true" />
</application>
</device>
<device driver="radeonsi">
<application name="ARK: Survival Evolved (and unintentionally the UE4 demo template)" executable="ShooterGame">
<option name="radeonsi_clear_db_cache_before_clear" value="true" />
</application>
<application name="No Mans Sky" executable="NMS.exe">
<option name="radeonsi_zerovram" value="true" />
</application>
</device>
</driconf>


Zusätzlich habe ich mal in meiner user .drirc die fraglichen Anwendungen hinzugefügt mit Freesync an. Hat nix gebracht.

[aufkrawall]

Ist LFC eigentlich schon im Pull für 4.21 mit enthalten? Ich hatte dazu einen Commit im amd-staging-drm-next Branch gesehen, aber woanders nicht.
Spannend wär auch, ob es sich genau so wie FreeSync unter Windows verhält bez. fps-Limits und Vsync.

Na ja, Hauptsache, es funktioniert hier schon bei jemandem. :D

[DevilX]

kann ich nicht viel zu sagen, hab den Monitor nie unter Windows genutzt.

[Acid-Beatz]

Guten Abend zusammen, ich bin gerade etwas irritiert und wollte mal Eure Meinung hören. Was sagen mir diese hohen Nice-Werte: ich kann mich nicht erinnern, das schon irgendwann mal gehabt oder gesehen zu haben:

top - 18:52:17 up 6:26, 2 users, load average: 11,93, 11,68, 11,44
Tasks: 304 total, 3 running, 301 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1,0 us, 0,0 sy, 92,0 ni, 7,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu1 : 0,0 us, 0,0 sy, 92,7 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 0,0 us, 0,0 sy, 93,0 ni, 7,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 0,3 us, 0,0 sy, 92,4 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 0,0 us, 0,0 sy, 93,0 ni, 7,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu5 : 0,0 us, 0,3 sy, 92,4 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 0,0 us, 0,0 sy, 92,7 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu7 : 0,0 us, 0,0 sy, 92,7 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu8 : 0,0 us, 0,0 sy, 99,7 ni, 0,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu9 : 1,7 us, 0,0 sy, 91,3 ni, 7,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu10 : 0,3 us, 0,0 sy, 92,4 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu11 : 0,3 us, 0,3 sy, 91,7 ni, 7,3 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
MiB Mem : 11922,1 total, 8387,5 free, 1921,3 used, 1613,2 buff/cache
MiB Swap: 6028,0 total, 6012,7 free, 15,2 used. 9705,2 avail Mem

Sollte nichts zur Sache tun aber hier noch Infos:
Kernel 4.19.10-300 - Fedora 29
CPU hat 6 Kerne + HT, von daher stimmt die Load von knapp 12.

Die CPU rechnet an einer Milkyway at Home n-Body Simulation, allerdings hätte ich die Last dann bei us bzw sy erwartet ... .

Ideen zur Aufklärung, was ich gerade nicht verstehe :confused:

[iuno]

Das heisst nicht, dass die nice Werte besonders hoch waeren, sondern das Gegenteil, naemlich dass die CPU viel Zeit in Prozessen mit niedrigen nice Werten verbringt.

Die Simulaton wird mit entsprechend niedriger Prio laufen. Naechstes mal bitte Terminal output in Code Blocks, ist dann besser zu lesen, selbst wenn es in dem Fall hier nicht viel ausgemacht hat.

[Acid-Beatz]

Hey iuno,
Danke für Deine Antwort - das war mir in der Tat bisher unbekannt. Also Nice-Werte sagen mir natürlich was aber dass es sich dann so äußert, war mir neu.

Vielen Dank, wieder was gelernt :up:

[johla]

Frage zu dnscrypt-proxy und resolv: Wenn man hinter einem Router von Kabel Deutschland oder der Telekom sitzt, kann man auf seinem Linux überhaupt etwas machen oder muss man im Router etwas einstellen?

[sei laut]

Frage zu dnscrypt-proxy und resolv: Wenn man hinter einem Router von Kabel Deutschland oder der Telekom sitzt, kann man auf seinem Linux überhaupt etwas machen oder muss man im Router etwas einstellen?
Die resolv.conf wird beachtet und du musst es nicht auf deinem router einstellen. (wobei WebBrowser in Zukunft eigene DNS Einstellungen mitbringen wollen, zumindest Firefox, und dann die resolv.conf ignorieren werden)
Allerdings: Warum? Deinem Provider ist es sowas von egal, was du aufrufst. Da würde ich nicht eine zusätzliche Instanz dazwischen bauen, die im Zweifel irgendwas komisches macht.

[johla]

Die resolv.conf wird beachtet und du musst es nicht auf deinem router einstellen. (wobei WebBrowser in Zukunft eigene DNS Einstellungen mitbringen wollen, zumindest Firefox, und dann die resolv.conf ignorieren werden)
Allerdings: Warum? Deinem Provider ist es sowas von egal, was du aufrufst. Da würde ich nicht eine zusätzliche Instanz dazwischen bauen, die im Zweifel irgendwas komisches macht.
Ok, und ist unbound zu empfehlen? (Ich habs eingerichtet und laut https://dnssec.vs.uni-due.de/ funktioniert es.)

[sei laut]

DNSSEC besagt nur: Die Antwort kommt von dem, den du gefragt hast und niemand dazwischen hat das Ergebnis manipuliert.

In deiner vorherigen Frage gings aber vermutlich darum, dass jemand (dein Provider?) nicht sieht, welche Anfragen du stellst. Das verhindert dnssec nicht.

[lumines]

Ok, und ist unbound zu empfehlen? (Ich habs eingerichtet und laut https://dnssec.vs.uni-due.de/ funktioniert es.)

Unbound ist sehr gut. Es kann mittlerweile auch DNS over TLS, was die Anfragen sogar verschlüsselt, allerdings ist die Implementierung in Unbound relativ lahm.

Ich würde Unbound einfach ohne DNSSEC oder TLS nutzen. AFAIK manipuliert keiner der deutschen Provider aktiv Anfragen an andere DNS-Server. Außerdem kann man selbst mit DoT noch sehen, welche IPs aufgerufen werden, was für Provider trivial nachzuverfolgen ist. Unterwegs ist DoT aber eine sehr gute Sache.

Ich habe auf allen meinen Rechnern, wo das möglich ist, eine Unbound-Instanz laufen. Einfach als Fallback, falls das DNS spinnt. Kann sicher nicht schaden im Zweifel switchen zu können.

[johla]

Unbound ist sehr gut. Es kann mittlerweile auch DNS over TLS, was die Anfragen sogar verschlüsselt, allerdings ist die Implementierung in Unbound relativ lahm.

Ich würde Unbound einfach ohne DNSSEC oder TLS nutzen. AFAIK manipuliert keiner der deutschen Provider aktiv Anfragen an andere DNS-Server. Außerdem kann man selbst mit DoT noch sehen, welche IPs aufgerufen werden, was für Provider trivial nachzuverfolgen ist. Unterwegs ist DoT aber eine sehr gute Sache.

Ich habe auf allen meinen Rechnern, wo das möglich ist, eine Unbound-Instanz laufen. Einfach als Fallback, falls das DNS spinnt. Kann sicher nicht schaden im Zweifel switchen zu können.
Danke, ja, die DNS-Abfragen sind jetzt etwas langsamer. Wo finde ich gute Konfigurationstipps für unbound? Ich bin nach https://calomel.org/unbound_dns.html example 2 vorgegangen.

[vanquish]

Ich habe auf allen meinen Rechnern, wo das möglich ist, eine Unbound-Instanz laufen. Einfach als Fallback, falls das DNS spinnt. Kann sicher nicht schaden im Zweifel switchen zu können.

Unbound ist eigentlich nicht dafür gedacht auf Clients direkt zu laufen. Auf einem Router/Server der immer läuft macht der Cache viel mehr Sinn, um sich z. B. mehrfaches Anfragen der selben IP zu sparen.

Geht es nur um das verschlüsseln der Anfragen an sich würde ich stubby empfehlen (wenn es schon auf jedem Client laufen soll). Ich würde stubby aber auch wieder bevorzugt auf dem Router direkt installieren.

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby

DNSSEC verlangsamt jede DNS-Anfrage erheblich!

[lumines]

Unbound ist eigentlich nicht dafür gedacht auf Clients direkt zu laufen.

Klar ist es das, wird dir auch jeder der Entwickler bestätigen.

Auf einem Router/Server der immer läuft macht der Cache viel mehr Sinn, um sich z. B. mehrfaches Anfragen der selben IP zu sparen.

Das ist ein Anwendungsfall, aber Unbound ist einfach ganz allgemein ein cachender Resolver. Niemand hält dich davon ab ihn so zu benutzen wie du es für richtig hälst. Einige BSDs haben Unbound auch direkt im Base-System integriert.

Geht es nur um das verschlüsseln der Anfragen an sich würde ich stubby empfehlen (wenn es schon auf jedem Client laufen soll). Ich würde stubby aber auch wieder bevorzugt auf dem Router direkt installieren.

Aber ... warum? Der Sinn hinter TLS ist Ende-zu-Ende-Transportverschlüsselung. Klar, man kann TLS auch am Router terminieren, aber damit geht der größte Vorteil flöten.

Mit DNSSEC würde ich mich auch gar nicht rumschlagen wollen. Es ist zu fragil und der Nutzen ist sehr begrenzt, wenn überhaupt.

Danke, ja, die DNS-Abfragen sind jetzt etwas langsamer. Wo finde ich gute Konfigurationstipps für unbound? Ich bin nach https://calomel.org/unbound_dns.html example 2 vorgegangen.

Cloudflare hatte irgendwo eine kurze Anleitung für Unbound und DNS over TLS.

[vanquish]

Um Gottes Willen. Natürlich kann jeder Unbound auch als Client auf jedem System installieren. Man kann auch nur Teilfunktionen der Software nutzen. Ich persönlich finde es halt etwas übertrieben. Ich halte viel von der Regel nur jene Software/Funktion zu installieren die auch tatsächlich benötigt wird. Ich würde heutzutage auch keinen Ad-Blocker/Hosts-Datei mehr auf jedem Client einzeln installieren wollen. Aber jeder soll bitte das machen was er für richtig hält!
Ich wollte lediglich zum Ausdruck bringen, dass ich persönlich Unbound für den Einsatz als zentraler DNS-Server im LAN als geradezu prädestiniert empfinde und Unbound (IMO) auf einem Client System Overkill ist.
Als Alternative wollte ich Stubby emfehlen. Es ist auch spürbar schneller (kein extremer Unterschied!) bei der Namensauflösung. Eine weitere Alternative wäre DSNCrypt. DNSCrypt Ist bei den DNS-Providern aber leider kaum verbreitet und entstammt aus der Feder von den Machern von OpenBSD. Cloudflare z. B. unterstützt DNSCrypt.

[lumines]

Auch an Unbound sitzen OpenBSD-Core-Devs.

Ich wollte das auch nur betonen, weil es absolut nicht offensichtlich ist, warum unsere Betriebssysteme nicht standardmäßig so etwas wie Unbound direkt integriert haben. Daran ist auch nichts übertrieben. Wie gesagt, FreeBSD und OpenBSD haben sich explizit für Unbound entschieden und auch in vielen Cloud-Infrastrukturen ist Unbound auf den Hosts sehr beliebt, eben weil es eine sehr viel seriösere Implementierung ist als das, was man vorher benutzt hat.

[vanquish]

Ja, im Moment ist vieles in diesem Bereich im Fluss. Stubby ist auch relativ neu. Ich hoffe nur, dass sich DNS-over-HTTPS nicht durchsetzt und am Ende quasi jedes dumme Stück Software seinen eigenen Resolver zur Verfügung hätte.* Wodurch dem Anwender jegliche Kontrolle über den Zugriff auf Domains entgleiten würde.

*EDIT: Begründung: Es braucht keine Resolver-Software mehr implementiert/integriert werden. Sondern nur noch ein paar Zeilen Code (wenn ich es richtig verstanden habe).

EDIT2: Um es etwas weiter auszuführen (sind meine eigenen Gedanken!):

Ich kann mit DNS-over-HTTPS DNS-Anfragen nicht mehr sinnvoll nach Port filtern, denn über 443 wird ja nicht nur DNS gesendet.
Selbst wenn man mittels DPI noch feststellen könnte, dass es sich bei dem verschlüsselten Traffic um DNS Traffic handelt, müsste man einen etwaigen Filter auf jedem Client System installieren. Dieser theoretische Filter müsste allerdings die Fähigkeit besitzten für jede Software zwischen berechtigten und unberechtigen DNS-Anfragen unterscheiden zu können. Klar kann man bestimmte Software komplett blocken. Aber das erscheint mir in der heutigen Handy-/IoT-/Windows-Shop-Software-Welt als eher aussichtlos. Was bliebe wären IP-Sperren. Was mit IPv6 leider noch sinnloser wäre als es das mit IPv4 heute schon ist.

Aber vielleicht kann mich ja hier jemand "erhellen" und mir die "Angst" davor nehmen. ;)

[lumines]

Ich kann mit DNS-over-HTTPS DNS-Anfragen nicht mehr sinnvoll nach Port filtern, denn über 443 wird ja nicht nur DNS gesendet.

Genau das ist der Sinn hinter DoH. Ob man das gut findet, ist natürliche eine andere Frage.

[vanquish]

Genau da sehe ich den Widerspruch. Ich bezweifle, dass die Zensoren nicht erkennen können, dass es sich um eine DNS Abfrage handelt. Denn verschlüsselt ist ja DoT und DNSCrypt auch. Trotzdem kann über DPI z. B. bei DoT (das Feld heisst SNI) festgestellt werden, dass es ein DNS Paket ist. Das soll sich wenn möglich mit TLS v1.3 ändern (mein letzter Kenntnisstand). Da die Interessen hier recht breit sind bezweifle ich, dass es umgesetzt wurde. Zwar weiss kein Dritter mehr was abgefragt wird. Aber die Zensoren können über die Erkennung einer DNS-Abfrage die entsprechenden Pakete immer noch abfangen und umleiten, verknüpft mit der Aufforderung einen "erlaubten" DNS-Server zu verwenden (ist in Firefox bereits integriert). Selbst wenn wirklich _alles_ in einem Paket verschlüsselt ist, kann ich mir gut vorstellen, dass es über Mustererkennung (Zeit/Dauer, Paketgröße, Häuffigkeit des Kontakts, etc.), möglich ist ein DNS-Paket zu erkennen. Das einzige was ich mir tatsächlich vorstellen kann ist es ein entsprechendes Paket zu "tarnen", was ich für HTTPS und TLS bezweifle, da die Industrie/Politik hier viel zu viel mitredet und nicht "standardisiertes/lesbares" einfach aussortiert.
Bei Wireguard (wo der Port ja frei ist und der VPN wirklich nur Daten sendet wenn tatsächlich etwas gemacht wird) zerbrechen sich die Leute im Moment auch den Kopf darüber mit welcher Art von Traffic die Pakete getarnt werden könnten. Ein sehr schwieriges Feld.

[lumines]

Das soll sich wenn möglich mit TLS v1.3 ändern (mein letzter Kenntnisstand). Da die Interessen hier recht breit sind bezweifle ich, dass es umgesetzt wurde.

Wurde nicht umgesetzt, ist aber optional in Planung.

Zwar weiss kein Dritter mehr was abgefragt wird. Aber die Zensoren können über die Erkennung einer DNS-Abfrage die entsprechenden Pakete immer noch abfangen und umleiten, verknüpft mit der Aufforderung einen "erlaubten" DNS-Server zu verwenden (ist in Firefox bereits integriert).

Können sie machen, aber dann müssen sie komplett Cloudflare umleiten, wenn man die als Server benutzt. Die Resolver von Cloudflare laufen einfach auf deren normalen Servern mit.

Selbst wenn wirklich _alles_ in einem Paket verschlüsselt ist, kann ich mir gut vorstellen, dass es über Mustererkennung (Zeit/Dauer, Paketgröße, Häuffigkeit des Kontakts, etc.), möglich ist ein DNS-Paket zu erkennen.

Bei TLS 1.3 alles mit entsprechendem Padding schon bedacht. Zeit / Dauer als Seitenkanal spielt mit ChaCha20-Poly1305 auch keine Rolle, weil es sogar in Software in konstanter Zeit berechnet werden kann (im Gegensatz zu AES). Die Nachrichtenlänge wird auch verschlüsselt. Guck dir einmal das Protokoll an. Es ist sehr gut.

Das einzige was ich mir tatsächlich vorstellen kann ist es ein entsprechendes Paket zu "tarnen", was ich für HTTPS und TLS bezweifle, da die Industrie/Politik hier viel zu viel mitredet und nicht "standardisiertes/lesbares" einfach aussortiert.

"Tarnen" ist komplett unnötig, wenn das im Protokoll sowieso schon vorgesehen ist.

Bei Wireguard (wo der Port ja frei ist und der VPN wirklich nur Daten sendet wenn tatsächlich etwas gemacht wird) zerbrechen sich die Leute im Moment auch den Kopf darüber mit welcher Art von Traffic die Pakete getarnt werden könnten. Ein sehr schwieriges Feld.

Nicht nachgeguckt, aber ich würde 50 Internetgummipunkte wetten, dass das kein Ziel der Entwickler von Wireguard war oder ist.

[vanquish]

Ah, O.K. dann hat sich bei TLS 1.3 doch der Verstand durchgesetzt. :) Und wenn es wie die sagst ordentlich umgesetzt wurde habe ich Hoffnung, dass es auch irgendwann zum Einsatz kommt.

Bzgl. Wireguard habe ich auch keine Ahnung. Hab's im IRC mal aufgeschnappt wo sich ein Entwickler damit beschäftigen wollte. Ist aber schon länger her. Wireguard läuft bei mir mittlerweile einwandfrei weshalb ich mich nur noch sporadisch damit beschäftige.

[Simon Moon]

DNS over TLS und erst recht https halte ich für ziemlich hässliche Konstrukte, welche überhaupt nicht zu DNS passen. WireGuard wirkt hier viel eleganter und schlanker - eher wie man eine neue Technologie möchte.

Allein der Handshake über TCP benötigt bereits 3 Schritte und dann kommen nochmal 8(+) weitere für TLS dazu. Inwiefern dann TCP als solches ein Vorteil bei DNS ggü. UDP seinsoll, versteh ich auch nicht wirklich, benötigt aber nochmal eine Verabschiedung - wenn vll. in 30 die nächste Anfrage gesendet wird?

Ein Verbindung via Wireguard steht nach 2 Paketen und ist bereit ein simples UDP Paket zu füllen. Danach ist wieder Ruhe und die Verbindung bleibt sogar noch einen Moment erhalten (mit der Option diese gänzlich bestehend zu halten). Die Crypto dürfte dabei wohl etwa auf TLS1.3 Niveau sein, ohne Altlasten von vor 20 Jahren mitzunehmen (wobei natürlich sicher ein Argument ist, dass TLS bisher genauer analysiert wurde).

Die TLS Zertifikate erzeugen dann imo bei DNS auch ehrer Doppelspurigkeiten, als dass sie notwendig wären. Zumal ich eh nur bedingt ein Freund von Authoritäten bin und auch wenn TLS sehr gut ist, muss doch nicht gleich komplett alles darauf stützen (genauso wie nicht absolut alles über https in JSON gesendet werden muss).

Vielleicht überseh ich auch etwas, aber ich fand wireguard schon von anfang an wie gemacht für DNS und mit der Userspace-Implementation die es nun gibt, lässt sich schon etwas rumspielen und ist selbst in der Theorie sogar für Laien noch weitestgehend verständlich und überschaubar. Ist mir 100x als DoH, das einfach mal auf gängige Netzwerklayer scheisst, weil wieso auch nicht? SPDY auf DNS - dann kannst du die TLDs mit maximalem Transfer streamen :ulol:

[lumines]

Die TLS Zertifikate erzeugen dann imo bei DNS auch ehrer Doppelspurigkeiten, als dass sie notwendig wären. Zumal ich eh nur bedingt ein Freund von Authoritäten bin und auch wenn TLS sehr gut ist, muss doch nicht gleich komplett alles darauf stützen (genauso wie nicht absolut alles über https in JSON gesendet werden muss).

Für eigene Nutzung spricht auch relativ wenig gegen Wireguard, wenn man einen eigenen Server damit aufsetzen kann. Ich benutze es ja auch.

Der Vorteil bei TLS gegenüber Wireguard ist IMHO nicht so sehr das Protokoll, sondern überwiegend die PKI. Für Wireguard wird man immer manuell Schlüssel austauschen müssen, aber DoT ist sehr viel simpler und z.B. in Android 9 ja auch direkt integriert. Wenn man nur DNS gegen MitMs absichern will, dann ist es eigentlich ziemlich perfekt.

DoT per TLS 1.2 ist wahrscheinlich wirklich nicht so optimal, aber TLS 1.3 kann ja optional auch 0 RTT. Ich meine sogar ohne 0 RTT ist der Handshake bei TLS 1.3 unglaublich billig zu haben. Grundsätzlich kann man mit Session Tickets auch TLS 1.2 in "günstig" beim Handshake haben, aber das ist wieder mit relativ Aufwand auf der Serverseite verbunden, weil die Keys zu rotieren nicht so ganz trivial ist und nur wenige Server das selbstständig machen (been there, done that). Mit TLS 1.3 braucht man nicht einmal wirklich einen richtigen Cache für die TLS-Sessions.

[Simon Moon]

Der Vorteil bei TLS gegenüber Wireguard ist IMHO nicht so sehr das Protokoll, sondern überwiegend die PKI. Für Wireguard wird man immer manuell Schlüssel austauschen müssen, aber DoT ist sehr viel simpler und z.B. in Android 9 ja auch direkt integriert. Wenn man nur DNS gegen MitMs absichern will, dann ist es eigentlich ziemlich perfekt.


TLS ist für den Nutzer natürlich einfacher anzuwenden, weil out of the box schon alles eingerichtet ist. Wireguard lässt das halt bewusst offen und es soweit ich verstanden habe schon der Wunsch da, dass es für das Schlüsselmanagement Lösungen geben soll. Das könnte sich mittel bis längerfristig sogar zu einem Vorteil entwickeln, da sowohl Schlüsselserver als auch Zertifikate oder beides kombiniert eingesetzt werden kann.


DoT per TLS 1.2 ist wahrscheinlich wirklich nicht so optimal, aber TLS 1.3 kann ja optional auch 0 RTT. Ich meine sogar ohne 0 RTT ist der Handshake bei TLS 1.3 unglaublich billig zu haben. Grundsätzlich kann man mit Session Tickets auch TLS 1.2 in "günstig" beim Handshake haben, aber das ist wieder mit relativ Aufwand auf der Serverseite verbunden, weil die Keys zu rotieren nicht so ganz trivial ist und nur wenige Server das selbstständig machen (been there, done that). Mit TLS 1.3 braucht man nicht einmal wirklich einen richtigen Cache für die TLS-Sessions.


TLS1.3 scheint ja doch sehr gelungen zu sein. Nachdem im Vorfeld einige Wünsche der Industrie im Gespräch waren, hatte ich das eigentlich nicht mehr gross verfolgt und halt eher einen Aufguss erwartet. Schau ich mir wohl doch noch an, aber wohl erst in einem Jahr oder so, wenn die alten Zöpfe abfallen. Generell find ich halt, TLS hat seine Berechtigung und seinen Platz, das sollte dann aber nicht einer Vielfallt im Wege stehen. Und DoT kannibalisiert hier dann doch die Sicherheitsfeatures welche sich bei DNS über die Zeit entwickelt haben. Ich frag mich grad, wenn einer Root CAs herausgeben kann und den DNS Server kontrolliert. gibt es dann rein via TLS eine Möglichkeit zu kontrollieren on der Server mich jetzt zur richtigen Stelle umgeleitet hat oder nicht einfach für die Fakeseite ein CA aufgesetzt hat?

[lumines]

gibt es dann rein via TLS eine Möglichkeit zu kontrollieren on der Server mich jetzt zur richtigen Stelle umgeleitet hat oder nicht einfach für die Fakeseite ein CA aufgesetzt hat?

Einige Unternehmen wie Google und ein paar andere protokollieren alle Zertifikate, die ausgestellt werden. Nennt sich Certificate Transparency. Wenn sich eine CA schlecht verhält, dann distrusten die Browser die irgendwann und das war es dann auch für die meisten CAs. Es ist nicht perfekt, aber es funktioniert scheinbar mittlerweile relativ gut.

[Simon Moon]

Einige Unternehmen wie Google und ein paar andere protokollieren alle Zertifikate, die ausgestellt werden. Nennt sich Certificate Transparency. Wenn sich eine CA schlecht verhält, dann distrusten die Browser die irgendwann und das war es dann auch für die meisten CAs. Es ist nicht perfekt, aber es funktioniert scheinbar mittlerweile relativ gut.


Aber dann hat man, wenn man die diese CA als ganzes nimmt, einen single point of failure. Es kann daher also höchstens von Vorteiil sein, wenn das DNS System ein unabhängiges Kontrollsystem hat. Oder umgekehrt hab ich keinen zusätzliche Sicherheit, wenn die CA nun auch meinen DNS Provider beglaubigt, statt nur die Webseiten welche ich besuchen will.



Vielleicht ist das ja nur meine Aversie gegen Monokulturen und Authoritäten, gefällt mir aber trotzdem nicht.

[lumines]

Vielleicht ist das ja nur meine Aversie gegen Monokulturen und Authoritäten, gefällt mir aber trotzdem nicht.

Du kannst auch alle CAs für dich lokal distrusten und bei jeder Webseite entscheiden, ob du dem Zertifikat traust. Ob das skaliert und ob man das selbst sinnvoll für Server verifizieren kann, die man nicht selbst betreibt, ist natürlich eine andere Frage. PKIs haben schon ihren Sinn und Zweck.

Ganz davon abgesehen sind die Alternativen, von denen man glaubt, dass sie skalieren, auch nicht viel besser und tendenziell sogar schlechter. Guck dir die Shitshow rund um DNSSEC und DANE an. Auf einmal hängt deine Sicherheit von nationalen Interessen einiger Länder ab. Einige Leute mit hippen .io-Domains würden sich da eher wundern, wer auf einmal ihre CA ist.

[aufkrawall]

To boot, Nvidia is a bad actor on Linux. Compare the talks at FOSDEM 2018 from the nouveau developers (the open source Nvidia driver) and the AMDGPU developers (the only1 AMD driver - also open source). The Nouveau developers discuss all of the ways that Nvidia makes their lives difficult, up to and including signed firmwares. AMDGPU instead talks about the process of upstreaming their driver, discuss their new open source Vulkan driver, and how the community can contribute - and this was presented by paid AMD staff. I met Intel employees at XDC who were working on a continuous integration system wherein Intel offers a massive Intel GPU farm to Mesa developers free-of-charge for working on the open source driver. Nvidia is clearly a force for bad on the Linux scene and for open source in general, and the users who reward this by spending oodles of cash on their graphics cards are not exactly in my good graces.
https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

-> Wer Nvidia kauft, trägt mit dazu bei, dass Linux sich nicht auf dem Desktop durchsetzen kann.

[BBig]

https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

-> Wer Nvidia kauft, trägt mit dazu bei, dass Linux sich nicht auf dem Desktop durchsetzen kann.

Das hatten wir doch schon ein par mal im den Thread.
Für Umsteiger mag nvidia noch "ok" sein, sonst sollte man einen großen Bogen um sie machen.
Meine letzte war eine NVS 300 - und selbst da war der Support für die "business graphics solution" für Linux unterirdisch.

Wofür steht Linux & Open Source, wofür nvidia?
Nicht nur, dass sie 0 Bestrebungen haben, einen OpenSource-Treiber zu liefern, sie unterstützen nicht mal das Nouveau-Team, dass aus meiner Sicht ihre Arbeit macht. (s. Zitat oben)
Statt dessen kommen sie mit immer mehr proprietären Gewaffel: Gsync vs FreeSync oder auch die Diskussion um EGLStreams, um mal zwei aktuelle zu nennen.

Wähle Hardware, die deine Software unterstützt, nicht umgekehrt und stimme mit deiner Geldbörse ab!

[Ganon]

Übrigens liefert ArchLinux Chromium jetzt (bzw. seit ner Woche schon) mit den VAAPI Patches von Fedora aus.

[aufkrawall]

Ich bemerke einigen Fortschritt bei Wayland:
Mutter in Arch läuft jetzt auch auf Wayland mit echtem Vsync >60fps. =)
Der Mauscursor allerdings noch nicht, xwayland kann es im Fenster auch allgemein noch nicht (gibt aber einen PR).
Anwendungen mit KWin-Wayland können nun ganz normal den Cursor einfangen und Virtual Desktops sind nun auch unterstützt.
Ich hab mit meinem bleeding edge Treiber-Stand auch noch keine Crashes provozieren können.
Sway 1.0-rc lief auch offenbar problemlos, da müsste ich mich aber noch weiter in i3 einarbeiten (schon hardcore...).
Sehr erfreuliche Entwicklungen, evtl. ist die ganze Sache doch schon in 1-2 Jahren für 99% der Fälle zu empfehlen.

Komisches Problem: Ich bekomme Gnome-Wayland nicht automatisch per .bash_profile gestartet. Wenn ich global XDG_SESSION_TYPE=wayland als Variable setze und dann nach dem Einloggen händisch gnome-session starte, geht es problemlos. Per .bash_profile passiert einfach gar nichts, obwohl Plasma-Wayland problemlos geht. :confused:

[johla]

In KDE gibt es anscheinend keine Möglichkeit, so wie in Windows die Fensterleiste automatisch auszublenden?

[aufkrawall]

Du klickst rechts auf die Kontrollleiste, entsperrst sie öffnest dann über die dazugekommene Schaltfläche "Weitere Einstellungen". Dort kannst du die Sichtbarkeit einstellen.

Btw: LibreOffice Fresh hat jetzt im Arch-Repo die KDE/Qt5-Oberfläche dabei. Läuft wie Butter und integriert sich top in Plasma. =)
Die Performance der Windows-Version ist unfassbar schlecht im Vergleich.

[exzentrik]

Die Performance der Windows-Version ist unfassbar schlecht im Vergleich.

Jo. Meiner Erfahrung nach performt LO unter Linux generell spürbar besser als unter Windows. Und wirkt auch runder. Ich nutze das jedenfalls unter Manjaro sehr gern und ausgiebig.

[aufkrawall]

Einer der letzten Kernel hat bei mir offenbar den Herunterfahr-Vorgang gefixt. Mit meinem ASRock Z170-Board trat dieses Problem (Hardware nur teilweise abgeschaltet) als Nebenwirkung auf, nachdem man irgendwie die ACPI-Warnungen abgestellt hatte.

[Gast]

Jetzt hat mit IINA offenbar macOS den besten MPV-Player. Gnome MPV kann wenig und ist instabil. SMPlayer ist nicht gerade eine Schönheit und wirkt wie ein Fremdkörper.
https://iina.io

---

Exposure X4 für Windows und Mac basiert auf QT. Mit Linux wird es aber dennoch nichts werden.
Zuviel Aufwand, für vermutlich zuwenig Interesse: https://www.alienskin.com/blog/2018/exposure-x4-is-coming-soon/

---

Flatpak würde bei DaVinice Resolve (hat immer noch einige Einschränkungen unter Linux) Sinn ergeben (und anderer Closed Source Software), da es das offiziell nur für CentOS (AFAIK) gibt.


---
https://jangernert.github.io/FeedReader/

= der angeblich beste FeedReader für Linux. Was nutzt ihr?

[Gast]

Exposure X4 für Windows und Mac basiert auf QT. Mit Linux wird es aber dennoch nichts werden.
Zuviel Aufwand, für vermutlich zuwenig Interesse: https://www.alienskin.com/blog/2018/exposure-x4-is-coming-soon/

ON1 PhotoRaw basierte offenbar ebenfalls zum Großteil auf QT. Dort gibt es keine Bestrebungen für einen Linux-Port.


Mehr kommerzielle Software unter Linux wäre schön. Häufig gibt es zwar gute OpenSource-Software. Aber nicht immer sind die OpenSource-Varianten ideal bzw. mehr Auswahl wäre nicht schlecht.

Es sieht allerdings IMHO nicht danacht aus, dass es kurzfristig Besserung gibt. Siehe die obigen beiden Beispiele, die sogar auf QT basieren.


Affinity (nutzt AFAIK kein QT):
"We have no plans to develop a version for Linux and do not have a workaround for this. Sorry"
https://forum.affinity.serif.com/index.php?/topic/72023-linux-support/

[Showers]

N00bfrage: Die Sprachliste bei Linuxinstallern ist wirklich immens. Sind die Distris dann entsprechend auch vollständig in die jeweilige Sprache übersetzt, oder muss man da öfters mit z.B. englischen Pop-Ups oder so rechnen? Falls dem so ist, welche Distri/s haben die umfangreichste und beste deutsche Lokalisierung inkl. Apps?

Habe kostenlos einige 120GB SSDs bekommen und wollte ein bisschen herumspielen. Der Installer von Zorin OS kackt halt gleich im Patritionsmenü ab. Toller Start/Ersteindruck.:usad:

[aufkrawall]

In der Regel ist alles, was irgendwie einer DE zuzuordnen ist, komplett übersetzt, zumindest ins Deutsche. Wenn etwas brandneu ist, dauert es vielleicht schon mal eine Version.

Der Partitionierer von Ubuntu ist leider ein notorischer Haufen Dung, ja. Wenn du eh erstmal nur rumpropbieren willst, spricht imho auch nichts dagegen, gleich Manjaro zu nehmen.
Wobei ich Installer allgemein nicht gerade als Stärke von Distributionen ansehen würde.

[Showers]

In der Regel ist alles, was irgendwie einer DE zuzuordnen ist, komplett übersetzt, zumindest ins Deutsche. Wenn etwas brandneu ist, dauert es vielleicht schon mal eine Version.

Der Partitionierer von Ubuntu ist leider ein notorischer Haufen Dung, ja. Wenn du eh erstmal nur rumpropbieren willst, spricht imho auch nichts dagegen, gleich Manjaro zu nehmen.
Wobei ich Installer allgemein nicht gerade als Stärke von Distributionen ansehen würde.
Danke! Ich wollte zuerst das Zorin OS probieren, weil es so schön wie aus einem Guss aussieht und angeblich von der Bedienung her wie Windows sein soll. Bei Manjaro hat mich irgendwie immer beim Anblick von Screens/Videos der Kontrast der gewählten Farbkomposition total abgeturnt (ich weiß klingt komisch, aber ich lege zwanghaft Wert auf sowas). Daran ist bei mir schon Mint gescheitert. Elementary wäre an sich perfekt, aber viele Apps sind an die Umgebung gar nicht angepasst und geben dem ganzen OS einen ewigen Pre-Alpha Look.

Ich weiß das man theoretisch Deepin Desktop über Manjaro ziehen kann, aber so weit bin ich vom Linux-Verständnis her noch nicht.:redface:

[lumines]

Nimm erst einmal eine von den großen Distributionen. Du tust dir keinen Gefallen mit den "kleinen" anzufangen.

Generell ist GNOME immer ganz gut übersetzt.

[BBig]

Ich sehe das wie aufkrawall & lumines

Schau dir die Benutzer-Oberflächen an, welche dir zusagt:
==> https://www.youtube.com/user/linuxscoop/videos

Zum probieren vll eine der "Großen": KDE oder Gnome

===

==> https://manjaro.org/download/ <oder>
==> https://antergos.com/try-it/

==> https://www.ubuntu.com/download/flavours

Zwei Tipps:
- Installiere alle Pakete / Software über das Repo (https://en.wikipedia.org/wiki/Software_repository) der Distro. Google nicht nach Paketen z. B. sondern nimm die Oberfläche, die dir die Distro bereit stellt oder gleich ein Terminal.
Achja, so bekommst du auch alle Updates!

- Und zweitens, versuche zu verstehen, was du tust!
Du wirst sicher an einen Punkt kommen, wo du nach einer Lösung für ein Problem suchst. 'Copy & Paste' nicht einfach was in ein Terminal, ohne es zu verstehen!
Lerne "man pages (https://de.wikipedia.org/wiki/Manpage)".
Häufig verständlicher, wenn man englisch kann: https://wiki.archlinux.org/

Viel Spaß!

[Showers]

Wow, Danke! Kurz und bündig. Werde es zuerst mit KDE Manjaro versuchen. Free Drivers oder Non-Free bei der Auswahl am Anfang? Braucht Manjaro diese drei Partitionen, oder ist es wie Ubuntu und regelt alles auf einer?

[exzentrik]

Free Drivers oder Non-Free bei der Auswahl am Anfang?

Wenn du eine GeForce einsetzt, wird dir womöglich nur der Non-free-Treiber übrig bleiben, weil's mit dem Free-Treiber gar nicht bootet. Und selbst wenn's klappt: Im NV-Lager gilt der unfreie Treiber immer noch als ausgereifter. Bei Radeon ist's afaik umgekehrt, obwohl AMD beim unfreien Treiber anscheinend große Fortschritte macht. Wie der Stand bei Intel-GPUs ist, weiß ich nicht.

[Ganon]

Wie der Stand bei Intel-GPUs ist, weiß ich nicht.

Es gibt keinen geschlossenen Treiber für Intel GPUs.

[aufkrawall]

Bei Radeon ist's afaik umgekehrt, obwohl AMD beim unfreien Treiber anscheinend große Fortschritte macht.
Bei AMD nutzt man defakto auch nur die offenen Treiber. Einzige Ausnahme ggf. native Vulkan-Spiele in Wine, aber den proprietären Vulkan-Treiber kann man auch einfach dazu installieren.

[clm[k1]]

Bei AMD nutzt man defakto auch nur die offenen Treiber. Einzige Ausnahme ggf. native Vulkan-Spiele in Wine, aber den proprietären Vulkan-Treiber kann man auch einfach dazu installieren.
Das wäre mir neu. RADV steht doch AMDVLK und dessen proprietären Pendant in nichts nach. Bei dem ein oder andere Spiel mag AMDGPU-Pro vielleicht mal geringfügig schneller sein, dafür ist RADV bei anderen wieder schneller.
Und seit dem großflächigen Einsatz von DXVK zeigt sich ja gerade auch, dass Spiele unter wine davon stark profitieren können. Und ich wüsste auch von keinem nativen Vulkan Spiel unter wine, dass von AMDGPU-Pro massiv Performancegewinne hätte.
Insofern würde ich für Radeon Grafikkarten einfach beim offenen Treiber bleiben.


just my 2 cent
clm[k1]

[aufkrawall]

Habe ich nicht genau das mit "nutzt man defakto auch nur die offenen Treiber" zum Ausdruck gebracht?

[Showers]

Mkay, Manjaro ging nicht zu installieren. Debian war sofort zu kompliziert. Jetzt habe ich Ubuntu LTS installiert. Leider wurde bei der Installation nicht wie üblich gefragt, ob noch ein anderes OS mit auf dem Rechner drauf ist. Jetzt bootet der Rechner halt gleich ohne zu fragen ins Linux.:usad:

[Rooter]

Gib mal in der Konsole sudo update-grub ein, das hat bei mir Win7 wieder zugänglich gemacht.

MfG
Rooter

[exzentrik]

Mkay, Manjaro ging nicht zu installieren.

Woran genau hakte es denn?

[Showers]

Gib mal in der Konsole sudo update-grub ein, das hat bei mir Win7 wieder zugänglich gemacht.

MfG
Rooter
Danke, werde ich probieren.
Woran genau hakte es denn?
Im Partitionsmenü geht es nicht weiter. Also ich klicke auf weiter und es passiert nix. Ist mir bei einem anderen Installer auch schon passiert.

[Rooter]

Kennt hier eigentlich jemand MakuluLinux? Habe das schon seit 4-5 Jahren auf dem Schirm und finde der Typ baut da ein sehr schickes und vollständiges System. :)

MbdJouBY2AU

MfG
Rooter

[Rooter]

Okay, kennt scheinbar keiner. :D


Anderes Thema:
Wenn ich mir eine Mittelklasse-Graka zulegen möchte im Bereich GTX1050/RX560 rum, und es mir vor allem um unter Ubuntu oder Mint funzende Videobeschleunigung und DE "läuft problemlos" geht. Kaufe ich dann besser AMD oder nV? :confused:
Bisher dachte ich immer AMD weil "Fuck you nVidia!" ect., vorhin sah ich aber ein YT-Video auf dem von AMD abgeraten wird und nV empfohlen wird.
Proprietäre oder freie Treiber sind mir egal solange "läuft problemlos" erfüllt ist.

[HeldImZelt]

Wenn Du das YT-Video nennst, können wir die technischen Aspekte gerne durchgehen.

[Rooter]

https://www.youtube.com/watch?v=MoqxphFukTQ#t=4m20s

Video ist anderthalb Jahre alt.

MfG
Rooter

[lumines]

Definitiv AMD. Neben Intel die einzig sinnvolle Option.

[Rooter]

Definitiv AMD. Neben Intel die einzig sinnvolle Option.Okay und warum?

MfG
Rooter

[lumines]

Nur freie Treiber laufen problemlos, daher bleiben nur AMD und Intel.

[iuno]

https://www.youtube.com/watch?v=MoqxphFukTQ#t=4m20s

Ist Stuss, was der erzaehlt. Hat wohl einen Grund, warum Kommentare deaktiviert sind.

[Bartfratze]

https://www.youtube.com/watch?v=MoqxphFukTQ#t=4m20s

Video ist anderthalb Jahre alt.

Offensichtlich ist beim Videoproduzierenden die Entwicklung des freien Treibers (amdgpu) noch nicht angekommen, da er von Treibern im Kernel spricht, aufgrund dessen er von AMD abrät. Andererseits spricht er von jahrealter Hardware, die wurde und wird doch von radeon (der andere freie Treiber) ziemlich gut unterstützt. … Wat redet der denn da? :confused:


unter Ubuntu oder Mint funzende Videobeschleunigung und DE "läuft problemlos" geht. Kaufe ich dann besser AMD oder nV?

Auf dem Laptop (Ryzen-APU mit Vega 8) kann ich problemlos mehrere Videos (bis zu 4 bisher getestet) gleichzeitig abspielen lassen, ohne dass die Desktop-GUI ruckelt.

Auf dem Desktop (GTX 1060) kann ich ein Video abspielen lassen und muss hier schon eine merklich rucklige Desktop-GUI in Kauf nehmen. Bei zwei Videos wird er unbedienbar, Fenster verschieben reagiert mit etlichen Sekunden Verzögerung, Scrollen oder Zoomen geht gar nicht mehr.
Dazu seltsames Geraffel im Multimonitorbetrieb (erstmal bis zur Erkennung und dann wieder beim Deaktivieren des 2. Monitors), beim Laptop ist das ebenfalls feini-fein.
Ganz fehlerfrei ist amdgpu zwar nicht (Hearts of Iron 4 bringt ihn bei mir nach einiger Zeit zu Fall), aber in Anbetracht der Nvidiatreiberprobleme beiß ich mir derweil so in den Hintern, keine 480 oder 580 von AMD für den Desktop geholt zu haben. :frown:

[iuno]

da gabs amdgpu schon und davon abgesehen war radeon auch nicht schlechter.

[Ganon]

Man könnte jetzt einen mehrstündigen Vortrag über die Vorteile von Open Source Treibern halten. Man muss dazu auch sagen, dass einige Vorteile leider von diversen Distributionen kaputt gemacht werden, weil sie den Kernel und Mesa nur unregelmäßig oder gar nicht aktualisieren. In dem Fall ist das Aktualisieren des Treibers (z.B. für Bugfixes für ein neues Spiel) schon eine größere Herausforderung. Darüber denkt man z.B. als ArchLinux Nutzer vielleicht gar nicht mehr nach, weil man eh immer Up-To-Date ist. Für Ubuntu gibt's ein paar inoffizielle Repositories, welche dieses Problem beheben. Aber für diese ganzen Hipster-Distros, auf die alle Anfänger so abfahren, gibt's das oft nicht und/oder es wird fummelig.

Hier ist der Nvidia-Treiber mehr Windows-Like. Wenn man ihn, egal wie, mal installiert hat, dann kriegt man darüber meist auch immer die aktuellste Variante davon.

Wenn's aber nur darum geht ein Desktop-System zu haben und Spielen eher zweitrangig ist, ist ein Open Source Treiber einfach sorgenfreier und funktioniert out-of-the-box einfach besser, egal mit welcher Distribution.

Wenn ein Open Source Treiber immer und in jeder Lage besser sein soll als der Nvidia-Treiber, dann ist einfach die Wahl der Distribution SEHR relevant.

[Rooter]

Okay danke @all, dann hab ich mich von dem "Experten" in die Irre führen lassen. X-D

Hole mir irgendwann bei Bedarf eine gebrauchte Polaris Graka wie ich es vor hatte.

MfG
Rooter

[HeldImZelt]

Vermutlich meint er 'fglrx', den veralteten, proprietären Treiber von AMD.

[aufkrawall]

Es sei noch erwähnt, dass Vega/Raven Ridge wesentlich besser bez. Stromspar-Features funktionieren als Polaris. Mit RR hätte man halt auch beschleunigtes VP9 (YouTube).
Wenn maximale Effizienz nicht so wichtig ist, spricht natürlich nichts gegen Polaris. Die katastrophale Desktop-Performance von Nvidia ist einfach keine Alternative.

[Gast]

Und trotzdem nutzen dennoch mehr als genug Linuxer am Ende doch Nvidia, z.B. BabyWogue: https://www.youtube.com/watch?v=SiX0NtFScd8

Oder Leute, die anspruchsvolle Dinge, wie KI machen. Hier sei AMD keine Alternative.

Wieso gibt es das vielleicht beste Terminal unter macOS (iTerm) und nicht Linux?
https://www.iterm2.com

[Gizmo1200]

Für die meisten zählen die FPS. Und damit ist in vielen Fällen nun mal NVIDIA vorne. Egal ob Linux oder Windows. Wenn ich mich auf YouTube begebe und schaue mir, als Beispiel, alles neue rund um DXVK an, dann hat die Mehrheit NVIDIA. Bei mir läuft noch immer ein alter XEON 1230 mit einer alten 7950. Für mich kommen eh nur noch E-Sport Games in Frage oder etwas wie Path of Exile (mit DXVK) und das läuft unter Arch.

Andere Seite mit der Sache MESA-DX9, Beispiel das Game LoL, bin ich seit langen überhaupt nicht mehr zufrieden. Das lief früher mit älteren xorg Versionen (aktivierung von DRI3 in xorg.conf) besser. Seit DRI3 von Haus aus in xorg ist und ich wegen Vulkan auf AMDGPU bin, läuft das ganze schlechter. Gibt es in der Richtung einige Griffe ?

Die neue Sache um Mesa Gallum Nine, läuft schon bei mir und bringt nicht den erwünschten Erfolg.

[aufkrawall]

Mit GCN 1 ist man halt zwischen den Stühlen runter gefallen.

[Ganon]

Und trotzdem nutzen dennoch mehr als genug Linuxer am Ende doch Nvidia, z.B. BabyWogue: https://www.youtube.com/watch?v=SiX0NtFScd8

Wer auch immer BabyWogue ist, aber dass die meisten Leute unter Linux Nvidia nutzen liegt auch daran, dass allgemein im gesamten PC Markt die meisten Leute Nvidia nutzen.

Dass ändert aber nichts an der Tatsache, dass AMD unter Linux einfach wesentlich problemloser funktioniert und das war die Frage und nicht mit welcher GPU ich in Linux die meisten FPS bekomme.

Und ich hab einen PC mit einer Nvidia Grafikkarte hier am Laufen. Ich weiß wie beschissen das alles funktioniert.


Wieso gibt es das vielleicht beste Terminal unter macOS (iTerm) und nicht Linux?
https://www.iterm2.com

Was ist daran denn so toll?

[Gizmo1200]

Mit GCN 1 ist man halt zwischen den Stühlen runter gefallen.
Wer bei mir GCN 1.1

Vulkan DXVK läuft. Nur MESA - DX9 halt, hat abgenommen. CPU ist eingestellt auf Performance. Sollte meine GPU sich langweilen und nicht richtig takten ? ... Was gibt es da gleich unter Arch um das mal zu schauen ?

[aufkrawall]

Mit einer 7950 hast du GCN 1, und selbst GCN 2 soll sich bei einigen zickig mit amdgpu verhalten.

Gallium Nine funktioniert nicht mit jedem DX9-Spiel, aber z.B. UE3 läuft meist hervorragend.

[Gizmo1200]

Mit der GCN Version hast du Recht, ???, irgendwie habe ich da immer 1.1 im Kopf.

Aber Vulkan AMDGPU läuft bei mir.

Nine --- League of Legend schon immer gelaufen damit. Bin gerade dran eine ältere Wine Version mit Gallium Nine zu machen. Mal schauen wie es mit der aussieht.

Es ist so. Am Anfang um die 220FPS. Dann 180, 130. Je mehr das man im Spiel, auf den Schirm ist, desto weniger FPS. Früher waren konstant 180 - 210 drin.

[Ganon]

Wenn du es debuggen willst, dann halt wirklich ältere WINE-Versionen installieren und schauen ob sie das Problem beheben. Das Installationsskript von Lutris nimmt für League z.B. wine-tkg-3.20. Vielleicht also mal mit einem Wine-Nine 3.20 anfangen.

Wäre halt auch die Frage ob das beschriebene Problem auch ohne Gallium-Nine Patches auftritt. Da bleibt nur rumprobieren. Emulatoren allgemein werden nicht unbedingt für jedes Spiel in jeder Situation besser, wenn eine neue Version raus kommt.

[Gast]

Was ist daran denn so toll?

Weiss nicht. Da ich das aber schon mehr als einmal von unterschiedlichen Leuten gelesen habe, scheint das wirklich etwas zu haben, z.B. https://www.heise.de/forum/Mac-i/News-Kommentare/macOS-10-13-2-hat-erhebliche-Probleme-mit-Netzwerkfreigaben/Re-Apple-s-Software-wird-immer-schlimmer/posting-31573717/show/

Der Post ist übrigens interessant bzgl. Mac und Linux.

Auch:
"Ich muss Nvidia einsetzen, da ich KI/ML mache. Oder kannst Du mir eine andere GPU zeigen, mit der man so schnell so effizient Neuronale Netze programmieren kann wit mit Nvidia-Karten und CUDA/cuDNN?"
https://www.heise.de/forum/Mac-i/News-Kommentare/macOS-10-13-2-hat-erhebliche-Probleme-mit-Netzwerkfreigaben/Re-Apple-s-Software-wird-immer-schlimmer/posting-31576503/show/

[BBig]

Und trotzdem nutzen dennoch mehr als genug Linuxer am Ende doch Nvidia, z.B. BabyWogue: https://www.youtube.com/watch?v=SiX0NtFScd8

Oder Leute, die anspruchsvolle Dinge, wie KI machen. Hier sei AMD keine Alternative.
Ich kenne BabyWogue - ihr / sein Twitter ist schon mal gesperrt, :D.
Besonders bekannt ist der YT-Account auch nicht, mit 5000+ Followers.

Nagut; Gegenbeispiel:

qrWCgEbEcAA
Wieso gibt es das vielleicht beste Terminal unter macOS (iTerm) und nicht Linux?
https://www.iterm2.com
"Beste Terminal" sagt wer? :tongue:

Für die meisten zählen die FPS. Und damit ist in vielen Fällen nun mal NVIDIA vorne. Egal ob Linux oder Windows...

Was nützten dir die "Super-FPS", wenn beim nächsten Update der Kernel locked. :redface:
"Gamer" mag vll etwas speziell sein, aber wenn ich Freiheit und Offenheit will, dann sind ein paar weniger FPS wohl zu verkraften imo.
Dafür habe ich das proprietäre Win10 Gewaffel nicht am Bein.

[Ganon]

Weiss nicht. Da ich das aber schon mehr als einmal von unterschiedlichen Leuten gelesen habe, scheint das wirklich etwas zu haben, z.B. https://www.heise.de/forum/Mac-i/News-Kommentare/macOS-10-13-2-hat-erhebliche-Probleme-mit-Netzwerkfreigaben/Re-Apple-s-Software-wird-immer-schlimmer/posting-31573717/show/

Ohne Beispiele ist's halt nur eine Satz der da steht. Der ganze Text riecht allgemein sehr stark nach Gewohnheitstier Verhalten und dagegen kann man schlecht argumentieren. Ich z.B. brauche keine GUI um git zu benutzen und sehe auch keinen Sinn darin für "git add", "git commit" und "git push" unbedingt zur Maus greifen zu wollen. Der Andere programmiert hauptsächlich mit Maus und will unbedingt alles anklicken... keine von beiden Varianten ist inhärent "besser".

Auch:
"Ich muss Nvidia einsetzen, da ich KI/ML mache. Oder kannst Du mir eine andere GPU zeigen, mit der man so schnell so effizient Neuronale Netze programmieren kann wit mit Nvidia-Karten und CUDA/cuDNN?"

"Ich benutze Nvidia-APIs also brauche ich Nvidia".. logisch, nicht? Aber nochmal: Das war hier nicht die Frage. Die Frage war mit welcher GPU man den problemlosesten Desktop bekommt und das ist alles andere als Nvidia.

[Gizmo1200]

Das Installationsskript von Lutris nimmt für League z.B. wine-tkg-3.20. Vielleicht also mal mit einem Wine-Nine 3.20 anfangen.

Bin schon einiges durch. Das TKG oder Wine Staging usw. haben dieses CSMT. Das ist noch schlimmer. Darum schreien alle nach neuen Gallium Versionen.

Habe eben eine 3.13 Staging mit Gallium Nine probiert. Verhält sich gleich.


Was nützten dir die "Super-FPS", wenn beim nächsten Update der Kernel locked. :redface:

Als nicht NVIDIA User kann es mir Wurst sein. Wenn es aber so wer, dann würden viele es nicht kaufen und benutzen. Weiter weiß ich noch das mit DKMS es überhaupt keine Probleme gibt. Ich denke auch, das einige mit NVIDIA keine großen Kernel Sprünge machen werden und die kleinen Kernel Updates sollten mit DKMS kein Problem sein.

[iuno]

Als nicht NVIDIA User kann es mir Wurst sein. Wenn es aber so wer, dann würden viele es nicht kaufen und benutzen.
Es ist auch so.

Niemand mit Ahnung/Erfahrung kauft bewusst Nvidia fuer Linux es sei denn, fuer NV-Kram mit CUDA/ML.

Du musst "viele" halt schon auch in Relation zu dem Anteil der Linux-Nutzer setzen. Und dazu kommt noch, dass der Anteil der devs unter Linux auch wieder hoeher ist als im Gesamtschnitt/unter Windows. Der Anteil der freiwilligen Linux-Nutzer ist eh schon verschwindend gering und AMD hat kaum Marktanteil. Ist doch klar, dass mehr Ergebnisse mit Nvidia gibt.

[aufkrawall]

Bin schon einiges durch. Das TKG oder Wine Staging usw. haben dieses CSMT. Das ist noch schlimmer. Darum schreien alle nach neuen Gallium Versionen.

CSMT wird seit einiger Zeit standardmäßig genutzt und wird von Gallium Nine eh komplett ersetzt. ;)

[Gizmo1200]

CSMT wird seit einiger Zeit standardmäßig genutzt und wird von Gallium Nine eh komplett ersetzt. ;)

Tut es leider nicht.

Die Tage kam erst was neues in Richtung Gallium Nine. Es geht wohl um den freien Intel Treiber und Mesa Gallium. Gallium - Zink und Iris & RadeonSI.

Witcher 2 muss angeblich da richtig gut laufen oder macht damit gut einen Sprung nach vorn.

Gallium Nine Standalone - https://github.com/iXit/wine-nine-standalone

Habe ich ebenfalls schon durch. Verhält sich alles gleich mit der FPS in LoL.

Probiere gerade noch einige Parameter mit aktuellen Wine Versionen gerade durch.

[aufkrawall]

Tut es leider nicht.

CSMT ist für wined3d, und das wird mit Gallium Nine gar nicht genutzt.

[iuno]

Tut es leider nicht.

Die Tage kam erst was neues in Richtung Gallium Nine. Es geht wohl um den freien Intel Treiber und Mesa Gallium. Gallium - Zink und Iris & RadeonSI.
Koenntest du ausfuehren was du damit sagen willst?

Ansonsten wird bei gallium nine gerade daran gearbeitet, NIR support zu bringen, was auch fast fertig ist.

Damit nutzen radv, anv, Iris, radeonsi und Gallium nine demnaechst alle NIR.

Zink ist ein Gallium OpenGL Treiber ueber Vulkan. Ob das relevant wird, wird sich noch zeigen. Grundsaetzlich koennte das zukuenftig auch ermoeglichen, gallium nine auch fuer Hardware zu nutzen, die einen Vulkan- aber keinen Gallium-Treiber hat.

Es gibt da schon eine nette Konvergenz innerhalb von Mesa. Wenn nine dann auch auf Intel Hardware laeuft koennte es auch nochmal relevanter werden. Im Sinne von mehr Tests und mehr funktionierenden (aelteren) Spielen durch mehr Wartung.

[Gizmo1200]

CSMT ist für wined3d, und das wird mit Gallium Nine gar nicht genutzt.

Wie und was, das alles im Verhältnis steht, keine Ahnung.

Nur das ich feststelle, das Gallium gegenüber CSMT mit 10FPS mehr in LoL gegenüber steht und das Gallium nicht mehr die Leistung wie früher hat. Geschuldet ? Keine Ahnung.


Damit nutzen radv, anv, Iris, radeonsi und Gallium nine demnaechst alle NIR.

Zink ist ein Gallium OpenGL Treiber ueber Vulkan. Ob das relevant wird, wird sich noch zeigen. Grundsaetzlich koennte das zukuenftig auch ermoeglichen, gallium nine auch fuer Hardware zu nutzen, die einen Vulkan- aber keinen Gallium-Treiber hat.

Wir meinen das selbe und ich benutze diese Standalone Sache. Habe ich ja verlinkt. Habe das alles nur durchflogen und teste da einwenig. Wie und was alles drin ist und was noch nicht. Keine Ahnung. Kann nur feststellen das es anspringt, aber die selbe Leistung bringt wie frühere Nine versionen.

[Rampage 2]

Wo kann ich Knoppix 8.3 herunterladen? Auf der offiziellen Knoppix-Seite wird nur 8.1 angeboten und auf den restlichen Seiten im Netz höchstens 8.2!

Ich weiß, dass Version 8.3 exklusiv für das Linux-Magazin vorbehalten ist, aber ich hatte irgendwo gelesen, dass man sich irgendwo registrieren kann, um doch noch einen Download für K 8.3 zu erhalten;)

R2

[lumines]

Muss es unbedingt Knoppix sein? Wenn es dir nur um den Live-Betrieb geht, kannst du jedes Ubuntu oder Fedora nehmen. Speziell Fedora dürfte durch den sehr aktuellen Kernel auch auf neuer Hardware unproblematisch sein.

Wenn du viel Software willst, kannst du auch ein großes Debian-Image nehmen. Wenn ich das richtig in Erinnerung habe, dann ist Knoppix auch nur Debian mit einem eigenen Branding.

[Rampage 2]

Muss es unbedingt Knoppix sein? Wenn es dir nur um den Live-Betrieb geht, kannst du jedes Ubuntu oder Fedora nehmen. Speziell Fedora dürfte durch den sehr aktuellen Kernel auch auf neuer Hardware unproblematisch sein.

Wenn du viel Software willst, kannst du auch ein großes Debian-Image nehmen. Wenn ich das richtig in Erinnerung habe, dann ist Knoppix auch nur Debian mit einem eigenen Branding.

Da in einem anderen Thread von mir (auch in diesem Unterforum, erst ein paar Wochen alt;)) ebenfalls statt Knoppix was Anderes empfohlen wurde, nämlich Manjaro (= Arch Linux), stehe ich nun vor der Qual der Wahl zwischen folgenden Haupt-Distributionen:

Debian, Fedora, Arch Linux

Da Debian 9.8 immer noch den alten Linux-Kernel 4.9 unter der Haube hat, ist das für mich ein absolutes No-Go - Fedora hat aktuell Kernel 4.18 und Manjaro sogar 4.19 !

Da bleiben dann eigentlich nur noch Fedora und Manjaro bzw. ArchLinux - es sei denn, Jemand kann mir noch eine andere Distribution (gibt ja sehr viele...) ans Herz legen;)

Ich tendiere stark zu ArchLinux, da es von den o.g. Distributionen das derzeit aktuellste Linux-Kernel besitzt und vor allem weil es auf das "Rolling Release" Updatemodell setzt - die Distro bekommt häufiger Updates und somit sind Zeiträume veralteter Zustände viel kürzer oder gar nicht existent:)

Aber da du Einer der IT-Gurus hier im Forum bist, würde ich gerne genauer erfahren, warum du mir Fedora statt ArchLinux nahelegst? ;)

Bei der Distro-Auswahl sind mir Aktualität (Kernel, Security-Patches), Kompatibilität, Sicherheitsfeatures, ein ausreichend breites Software-Sortiment (muss nicht zwingend das Größte, wie etwa Debian, sein) und eine großzügige Standard-Ausstattung (OOTB-Sortiment an Software, das sämtliche Anwendungsspektren abdeckt) besonders wichtig.

1.) Ist Fedora auch als Live-CD/DVD erhältlich? - Flash-Medien sind nachträglich manipulierbar, da sie weiterhin beschrieben werden können... deswegen will ich unbedingt auf eine Live-CD setzen;)

2.) Hat Fedora ein größeres Repository als ArchLinux? Wenn der Unterschied aber nur marginal ist, dann fällt dieses Entscheidungskriterium weg;)

R2

[iuno]

Manjaro (= Arch Linux),

Manjaro!=Arch.

Ich weiss aus der naeheren Umgebung von mehreren kaputten Manjaro Systemen und von keinem kaputten Arch. Ich wuerde von diesen Distris abraten. Entweder macht man sich die (einmalige) Muehe mit Arch, oder man laesst es. Das hat nichts mit Elitismus zu tun, bevor das jetzt wieder kommt. Den einen passt es halt, den anderen nicht. Ist ja auch ok

[fezie]

Ich tendiere stark zu ArchLinux, da es von den o.g. Distributionen das derzeit aktuellste Linux-Kernel besitzt und vor allem weil es auf das "Rolling Release" Updatemodell setzt - die Distro bekommt häufiger Updates und somit sind Zeiträume veralteter Zustände viel kürzer oder gar nicht existent:)


Bei Debian könntest du ja auch den testing Zweig nehmen. Dann hast du genauso "Rolling Release"
Ich persönlich verwend ja sogar Debian unstable ohne große Probleme.

[Thoro]

Manjaro!=Arch.

Ich weiss aus der naeheren Umgebung von mehreren kaputten Manjaro Systemen und von keinem kaputten Arch. Ich wuerde von diesen Distris abraten. Entweder macht man sich die (einmalige) Muehe mit Arch, oder man laesst es. Das hat nichts mit Elitismus zu tun, bevor das jetzt wieder kommt. Den einen passt es halt, den anderen nicht. Ist ja auch ok

Das kann ich so nicht unterschreiben. Meine persönliche Erfahrung (habe vor gut einem Jahr meinen Rechner umgestellt und den meiner Freundin vor nem Monat) mit Manjaro ist, dass es überaus stabil und zugänglich ist. Ich bin als Linux-Noob umgestiegen und hatte - außer einer zu neuen Nvidia-Karte - keine Probleme mit Installation und Setup. In dem gut einem Jahr jetzt hatte ich genau einmal ein Problem mit Updates (vor nem Monat mit systemd) und daraus gelernt, dass man halt die Release-Notes lesen muss, das ganze aber durch den guten Foren-Support mit einem Live-Medium sehr schnell wieder gefixt.

Ergo: für meinen (End-)Anwender-Fall finde ich nicht, dass es nötig ist, "sich die Mühe mit Arch" zu machen. Ich kann Vorteile von Arch (bei mir vor allem quasi-Rolling Release) mit einer zugänglicheren Distro nutzen und mehr will ich auch nicht. Für diese Anforderung passt das gut und Manjaro wird ja doch inzwischen ganz gut genutzt, insofern dürften das auch einige andere so sehen.

[aufkrawall]

Könnte auch sein, dass Manjaro eher von unbedarften Usern verwendet wird, die sich ihr System häufiger zerschießen (bzw. es nicht wieder repariert bekommen).
Mir fehlt ehrlich gesagt aber auch einfach die Fantasie, wie sich etwas Arch-basierendes von selbst so zerschießen soll, dass man mit freien Treibern nicht mehr ganz normal in die grafische Oberfläche starten kann (außer ggf. irgendeine komische Treiber-Regression).
Ich hab kontinuierlich zig System-Komponenten mit git-Stand am Start, und es ist damit noch nicht ein einziges Mal irgendwas gecrasht oder sonst wie nennenswert kaputt gegangen. :freak:

[iuno]

Könnte auch sein, dass Manjaro eher von unbedarften Usern verwendet wird
Das ist sicherlich der Fall.

Ich behaupte nicht, dass Manjaro andauernd und von selbst kaputt geht. Das war nur eine anekdotenhafte Beobachtung. Die Leute finden Arch oder RR generell irgendwie toll, haben aber keine Lust sich um irgendwas zu kuemmern, also installieren sie Manjaro. Wie man das halt so macht wird google zu irgendwelchen Sachen befragt und irgendwas ausprobiert und dabei gut Zeug durcheinander geworfen bis es halt irgendwo kracht.

Dass man sich nicht mit dem System auseinandersetzen will, ist ja ok. Aber fuer diejenigen ist Arch mMn. nichts. Und eine Distribution, die so tut, als waere sie Arch, nur "einfacher", auch nicht.

In dem gut einem Jahr jetzt hatte ich genau einmal ein Problem mit Updates (vor nem Monat mit systemd) und daraus gelernt, dass man halt die Release-Notes lesen muss, das ganze aber durch den guten Foren-Support mit einem Live-Medium sehr schnell wieder gefixt.
Dann faellst du nicht in die Personengruppe, die ich meine. Bei dir stimmt das mindset schon, bei vielen anderen aber halt nicht. Damit koenntest du auch genausogut Arch benutzen.

[Thoro]

Dann faellst du nicht in die Personengruppe, die ich meine. Bei dir stimmt das mindset schon, bei vielen anderen aber halt nicht.

Ach so, dann hatte ich es falsch verstanden. Noch noobigeren Leuten als mir würde ich Manjaro keinesfalls empfehlen - ist halt so bei Arch, dass es sein kann, dass man selber mal was fixen muss, das liegt in der Natur von Rolling Release. Wobei, was man so hört ist das bei Win 10 ja nicht viel anders ;)

[Abnaxos]

Da Debian 9.8 immer noch den alten Linux-Kernel 4.9 unter der Haube hat, ist das für mich ein absolutes No-Go - Fedora hat aktuell Kernel 4.18 und Manjaro sogar 4.19 !
Was im Kernel drin ist, kannst du bei Linux nicht einfach an der Versionsnummer beurteilen. Die wichtigen Änderungen (nicht nur Security-Fixes) aus neueren Kernels werden meist backported, daher ist die Version des Basiskernels wenig aussagekräftig. Jede Distro hat ihren eigenen Kernel.

[Lokadamus]

Und der aktuelle Kernel ist momentan *Trommelwirbel* Akt. Version: 4.20.7 (6. Februar 2019).

Demnach benutzen die meisten Distris nicht den aktuellsten Kernel. :unono:

Edit: Wobei der auch nicht der Aktuelle ist.
https://www.kernel.org/
mainline: 5.0-rc8 2019-02-25
stable: 4.20.12 2019-02-23
longterm: 4.19.25 2019-02-23
long, long, long ...

[aufkrawall]

Trotzdem muss man schon sagen, dass mit so alten Kerneln einem zig Verbesserungen entgehen. Insbesondere bei Treibern und daran angeschlossener Infrastruktur.

[Ganon]

Bei Top-Aktueller Hardware vielleicht. Wenn das System selbst aber schon 1-2 Generationen älter ist, ist es praktisch egal ob du nun 4.9, 4.14, 4.19 oder 4.20 benutzt. Der Kernel wird ja nun nicht mit jeder Version total umgebaut und wie schon gesagt wurde, wird auch sehr viel in die LTS Kernel zurückportiert.

[Gimmick]

Bei der Distro-Auswahl sind mir Aktualität (Kernel, Security-Patches), Kompatibilität, Sicherheitsfeatures, ein ausreichend breites Software-Sortiment (muss nicht zwingend das Größte, wie etwa Debian, sein) und eine großzügige Standard-Ausstattung (OOTB-Sortiment an Software, das sämtliche Anwendungsspektren abdeckt) besonders wichtig.

1.) Ist Fedora auch als Live-CD/DVD erhältlich? - Flash-Medien sind nachträglich manipulierbar, da sie weiterhin beschrieben werden können... deswegen will ich unbedingt auf eine Live-CD setzen;)

2.) Hat Fedora ein größeres Repository als ArchLinux? Wenn der Unterschied aber nur marginal ist, dann fällt dieses Entscheidungskriterium weg;)

R2


Das Du zuerst Knoppix verwenden wolltest und nun nurnoch von Live-CD sprichst, verwirrt mich. ;)
Soll das nur von DVD laufen, ohne feste Installation?

Der größte Unterschied zwischen den Distris ist einfach das Release-Model. Wenn Du kein Problem mit häufigen Update-Meldungen hast und Dir Aktualität wirklich wichtig ist, kommst Du ja um eine Rolling-Release Distri nicht herum.

Also Arch, oder auch Antergos oder Manjaro, oder auch SuSE Tumbleweed :D

[aufkrawall]

Bei Top-Aktueller Hardware vielleicht.
Definiere "top-aktuell". Mit RR/Vega von 2017 bekommst du ohne amdgpu.dc nicht mal eine (beschleunigte) Bildausgabe, und ein für amdgpu.dc wichtiger Fix für 5.0 wurde bisher auch nicht rückportiert.
Es macht einfach keinen Sinn, als Consumer auf ältere Kernel-Branches zu setzen. Auch mit älteren Branches kann etwas kaputt gehen...
Sonderfälle wie nicht kompilierendes WLAN-Modul etc. mal ausgenommen, wo man sich aber häufig weiterhelfen lassen kann.

[Ganon]

Definiere "top-aktuell". Mit RR/Vega von 2017 bekommst du ohne amdgpu.dc nicht mal eine (beschleunigte) Bildausgabe, und ein für amdgpu.dc wichtiger Fix für 5.0 wurde bisher auch nicht rückportiert.

Hab ich doch gesagt. 1-2 Generationen. Und dass ggf. von 5.0 noch nichts zurückportiert wurde ist doch logisch, wenn 5.0 noch nicht final ist.

[aufkrawall]

Wäre mir neu, dass man mit dem Rückportieren generell wartet, bis der neue Kernel erschienen ist. Aber mal abwarten..

Und natürlich wird amdgpu in einem derart alten Branch auch einfach eine ordentliche Spur langsamer sein. Insbesondere mit Vulkan wird das ziemlich häufig prozentual zweistellig sein. Warum will man das noch gleich?

[Ganon]

Du willst mich vermutlich nicht verstehen, nehme ich an? Na egal. Hält dich ja keiner davon ab das zu installieren was du willst.

Nebenbei wird's mit neueren Kernel-Versionen auch nicht unbedingt in jedem Fall schneller:

https://openbenchmarking.org/embed.php?i=1811260-SK-VULKANRAD95&sha=fa0695d&p=2

[aufkrawall]

Nebenbei wird's mit neueren Kernel-Versionen auch nicht unbedingt in jedem Fall schneller:

Aha, jetzt muss der Einzelfall mal wieder als Krücke für die Argumentation herhalten.

Man kann dich schwerlich anders verstehen, als dass du mindestens implizit bestreiten würdest, neuer wäre tendenziell besser. Du kannst es ja versuchen klarzustellen, ansonsten hast du dich halt verrannt.

[Ganon]

Man kann dich schwerlich anders verstehen, als dass du mindestens implizit bestreiten würdest, neuer wäre tendenziell besser. Du kannst es ja versuchen klarzustellen, ansonsten hast du dich halt verrannt.

Wenn ich sage, dass sich ein neuerer Kernel bei älterer Hardware nicht unbedingt lohnt (und bestätige, dass es sich bei neuer Hardware lohnt) und du mir mit AMD Vega kommst und behaupten willst ich liege hier falsch, dann hast du mich einfach nicht verstanden und willst mich auch nicht verstehen und bist halt wieder nur "aufkrawall" aus :ugly:

[aufkrawall]

1. Es wird nicht jeder Fix zurückportiert.
2. Auch mit Polaris und wahrscheinlich auch Tonga profitiert man von neueren Kerneln.
3. Du drückst dich um die Frage herum, warum man nicht gleich einen neueren Branch verwenden sollte. Selbst wenn das Probleme bringen sollte, trifft einen ja nicht gleich der Blitz und das Leben ist vorbei, eh man auf einen LTS-Kernel hätte switchen können...

Ich bin überhaupt nicht auf Krawall aus, ich finde deine Argumente einfach esoterisch.

[Ganon]

Wo hab ich denn behauptet, dass man den neusten Kernel vermeiden sollte? Wo hast du denn das jetzt bitte gelesen?

[aufkrawall]

Dann können wir uns ja darauf einigen...

[Lokadamus]

Hauptfrage ist immernoch, was wo eingesetzt wird. Bei einem Server ist es nicht so wichtig den aktuellsten Kernel zu haben. Nur der, der installiert wurde, sollte aktuell wegen Sicherheitslücken sein.

Auf einem Desktopsystem sollte wegen den Graka Treibern ein aktueller Kernel installiert sein. Muss aber nicht, wenn die Kiste eh nur zum Eierschaukeln benutzt wird. Zum Surfen usw. brauch ich keine hohen Frameraten. :|

Prügel mich jetzt weiter mit FreeBSD und der NVidia Karte rum. Bekomm kein Bild raus.

[Ganon]

Hauptfrage ist immernoch, was wo eingesetzt wird. Bei einem Server ist es nicht so wichtig den aktuellsten Kernel zu haben. Nur der, der installiert wurde, sollte aktuell wegen Sicherheitslücken sein.

Beim Server hast du gerne mal Zusatzhardware, wo der Treiber nicht im Kernel ist, aber ggf. trotzdem Open Source verfügbar. RAID Controller, Bandlaufwerke und Co.
Dort willst du nicht beim Einspielen von Updates immer Angst haben, dass dein Treiber kaputt geht, weil sie wieder was an der Kernel API geändert haben. Aber so ziemlich alle Server-Distributionen laufen eh auf einem LTS Kernel und bei RedHat hat man sogar einen ganz eigenen Kernel-"Fork" auf Basis von der 3.10 API mit vielen vielen Backports.

[lumines]

Da Debian 9.8 immer noch den alten Linux-Kernel 4.9 unter der Haube hat, ist das für mich ein absolutes No-Go - Fedora hat aktuell Kernel 4.18 und Manjaro sogar 4.19 !

Haben andere schon gesagt, aber die Kernel-Version muss nicht bei jeder Distribution mit dem Upstream-Stand der jeweiligen Version übereinstimmen. Speziell Red Hat baut sich komplett eigene Kernel. Nur die ABI bleibt gleicht. Können sie auch machen, weil sie genug Kernel-Entwickler beschäftigen.

Nebenbei: In Fedora 29 ist Kernel 4.20 drin. Es wurde nur mit 4.18 releast.

Ich habe nur Fedora vorgeschlagen, weil ich dachte, dass du das System primär als Live-Medium benutzen willst. Da kann ein aktueller Kernel manchmal ganz nützlich sein.

Ich tendiere stark zu ArchLinux, da es von den o.g. Distributionen das derzeit aktuellste Linux-Kernel besitzt und vor allem weil es auf das "Rolling Release" Updatemodell setzt - die Distro bekommt häufiger Updates und somit sind Zeiträume veralteter Zustände viel kürzer oder gar nicht existent:)

Grundsätzlich ist daran nichts verkehrt. Arch Linux erkauft sich das allerdings damit, dass man viel von Hand machen muss. Wenn man das gewohnt ist, ist das überhaupt kein Problem und wahrscheinlich weniger wartungsintensiv als Major-Upgrades bei anderen Distributionen. Es ist aber sicher keine Distribution, die einfach so in 10min aufgesetzt ist.

Bei der Distro-Auswahl sind mir Aktualität (Kernel, Security-Patches), Kompatibilität, Sicherheitsfeatures, ein ausreichend breites Software-Sortiment (muss nicht zwingend das Größte, wie etwa Debian, sein) und eine großzügige Standard-Ausstattung (OOTB-Sortiment an Software, das sämtliche Anwendungsspektren abdeckt) besonders wichtig.

Also Debian in etwas aktueller ist praktisch Ubuntu.

1.) Ist Fedora auch als Live-CD/DVD erhältlich? - Flash-Medien sind nachträglich manipulierbar, da sie weiterhin beschrieben werden können... deswegen will ich unbedingt auf eine Live-CD setzen;)

Vielleicht verstehe ich deinen Anwendungszweck auch falsch, aber wenn du es fest installierst, brauchst du das Live-Medium sowieso nur ein Mal. Wenn du es regelmäßig benutzen willst, musst du es auch irgendwie updaten, was sich mit einer fest gebrannten Version schwierig gestalten wird. Speziell die Browser-Updates wirst du nach spätestens sechs Wochen haben wollen. Für jedes Update eine neue DVD oder CD zu brennen hört sich für mich nicht wirklich praktikabel an.

2.) Hat Fedora ein größeres Repository als ArchLinux? Wenn der Unterschied aber nur marginal ist, dann fällt dieses Entscheidungskriterium weg;)

Bis jetzt habe ich für beide noch alles bekommen. Allerdings habe ich Arch auch schon länger nicht mehr benutzt. Das AUR bei Arch hat auch ziemlich viel experimentelle Branches mancher Software, was manchmal praktisch sein kann.

[aufkrawall]

Im offiziellen Fedora-Repo fehlen zig Pakete wie mpv, und selbst inklusive rpmfusion dürfte es nicht mit Arch mithalten können.
Außerdem gibt es weitere Fallstricke wie z.B. restriktiv eingestelltes SELinux. Da werden Einsteiger schnell irgendwo nicht weiterkommen und verzweifeln.

Linux ist einfach nicht für jeden. Entweder, irgendein seriöses Debian/*buntu oder Manjaro funktionieren für jemanden, oder es muss die Zeit zum Herantasten mit Arch aufgebracht werden. Alles andere ist doch einfach nur unehrlich und höchstens eine Lösung auf Zeit.

[Ganon]

Um es mal einfach in den Raum rein zu sagen:

Man wird ja nun aber auch nicht auf die Erstwahl der Distribution festgenagelt. Es ist durchaus legitim erst mal auf Tuchfühlung mit einer einfachen Distribution zu gehen, statt direkt ins kalte Wasser zu springen. Selbst der jahrelange Portierer von Spielen für Linux Ryan C. Gordon hatte seine Probleme damit ArchLinux erfolgreich zu installieren. Siehe den Thread (https://twitter.com/icculus/status/868939796311310336). Irgendwann hat's geklappt und dann kam die "Erleuchtung" (https://twitter.com/icculus/status/874682138792251394)

Und hier kann man schon sagen: "Der Mann arbeitet seit Jahrzehnten mit Linux, hat dafür sogar eine Firma gegründet und schafft es nicht auf Anhieb, wie soll es da einer schaffen der noch nie Linux in der Hand hatte?"

Von daher sehe ich in erster Linie kein Problem damit, wenn man erst mal Debian/SuSE/Fedora nimmt und nicht direkt auf den Rolling-Release Zug aufspringt, auch wenn es ggf. hier und da Nachteile hat. Was man nur vermeiden sollte ist halt so eine Mini-Hipster Distribution zu nehmen, nur weil die Standard-Oberfläche hübscher ist. ArchLinux kann man dann später einfach mal probieren. Ich hab auch nicht mit ArchLinux angefangen, aber da gab es ArchLinux auch noch gar nicht :ugly:

Dann ist ja auch weiterhin viel in Bewegung. Bei mir hat z.B. Flatpak fast komplett das AUR ersetzt (so ziemlich für alles außer Fonts). Es ist einfach angenehmer und sicherer (im Kontext "System zerschießen") und funktioniert für so ziemlich alle Distributionen da draußen.

[Thoro]

Auf einem Desktopsystem sollte wegen den Graka Treibern ein aktueller Kernel installiert sein. Muss aber nicht, wenn die Kiste eh nur zum Eierschaukeln benutzt wird. Zum Surfen usw. brauch ich keine hohen Frameraten. :|


Die Argumentation checke ich immer noch nicht ganz. Die Graka wird doch durch den jeweiligen Treiber angesprochen (sei es nun Mesa, Nouveau oder proprietär), warum ist der Kernel dann da trotzdem so wichtig?

[Lokadamus]

Die Argumentation checke ich immer noch nicht ganz. Die Graka wird doch durch den jeweiligen Treiber angesprochen (sei es nun Mesa, Nouveau oder proprietär), warum ist der Kernel dann da trotzdem so wichtig?Wegen den Kernelmodulen, die für die Graka notwendig sind. https://de.wikipedia.org/wiki/Direct_Rendering_Infrastructure

[iuno]

"der Treiber" ist nicht eine Komponente, sondern besteht aus Kernel Modul(en), einzelnen userspace-Treibern für verschiedene APIs und den Schnittstellen dazwischen

[Thoro]

Es ist also möglich, dass ich den aktuellen Mesa drauf habe, aber nicht alle Vorteile davon nutzen kann, weil das über meinen Kernel zur Verfügung stehende DRM nicht aktuelle ist? Stimmt das so ungefähr?

[Ganon]

Die Argumentation checke ich immer noch nicht ganz. Die Graka wird doch durch den jeweiligen Treiber angesprochen (sei es nun Mesa, Nouveau oder proprietär), warum ist der Kernel dann da trotzdem so wichtig?

Um mal deine Liste aufzugreifen (wir bleiben mal bei OpenGL), mal grob gesagt:

In /lib/modules/<kernel>/kernel/drivers/gpu/drm/

i915 -> Intel Kernel Modul
radeon/amdgpu -> AMD Kernel Modul
nouveau -> Nvidia Kernel Modul


In /usr/lib/ (libGL, libOSMesa, ...):

Mesa -> eine OpenGL Implementierung


In /usr/lib/dri/

i965 -> Intels Verbindungsstück Mesa <-> Kernel Treiber
r600/radeonsi -> Gallium3D Implementierung für AMD
nouveau -> Gallium3D Implementierung für Nvidia


Gallium3D -> ein Treiberframework welches Mesa und den Kernel Treiber verbindet (ist Teil von Mesa).

Es ist also möglich, dass ich den aktuellen Mesa drauf habe, aber nicht alle Vorteile davon nutzen kann, weil das über meinen Kernel zur Verfügung stehende DRM nicht aktuelle ist? Stimmt das so ungefähr?

Jo. edit: Generell öffnet der Kernel Treiber halt die Hardware-Features für den Userspace-Treiber und setzt entsprechende Feature-Bits und -Flags in der Hardware, macht Power-Management und Display-Ansteuerung. Für den Endanwender wird sich das in erster Linie auf die Performance bzw. allgemeine Funktionstüchtigkeit der Hardware auswirken weniger auf die Rendering-Features (OpenGL Versionslevel).

[Simon Moon]

Also Debian in etwas aktueller ist praktisch Ubuntu.



Also was die Security-Patches betrifft, ist Debian doch vorbildlich. Und wenn man ein aktuelleres Debian will, probiert man halt einfach testing oder unstable. Letzteres ist dann im Prinzip ja auch nur ein Rolling Release und jetzt nicht wirklich instabiler als vergleichbare Distributionen.



Ich sah den Unterschied zu Ubuntu immer mehr darin, dass Debian stärker auf freie Lizenzen achtet und das Ziel verfolgt, dass sämtliche binären Pakete rekompilierbar sind.

[Ganon]

Zwischen Debian Testing/Unstable (Sid) und ArchLinux gibt es aber noch einen kleinen aber feinen Unterschied: ArchLinux betreut sein Rolling-Release Modell, Debian nicht. D.h. wenn z.B. ein Sicherheitsfix für eine Software raus kommt, ohne jedoch ein neues Release raus zu bringen, dann sieht sich Debian Testing/Unstable nicht dazu verleitet diesen Fix "Out-of-Release" einzuspielen. So zumindest die offizielle Erklärung dazu. Wie das dann in der Praxis aussieht steht natürlich auf einem anderen Blatt.

[fezie]

Zwischen Debian Testing/Unstable (Sid) und ArchLinux gibt es aber noch einen kleinen aber feinen Unterschied: ArchLinux betreut sein Rolling-Release Modell, Debian nicht. D.h. wenn z.B. ein Sicherheitsfix für eine Software raus kommt, ohne jedoch ein neues Release raus zu bringen, dann sieht sich Debian Testing/Unstable nicht dazu verleitet diesen Fix "Out-of-Release" einzuspielen. So zumindest die offizielle Erklärung dazu. Wie das dann in der Praxis aussieht steht natürlich auf einem anderen Blatt.

Also bei den wichtigen Paketen werden eigentlich die Security Fixes schnell nach unstable hoch geladen. Und das mit einer priority=high. Sollten also im Regelfall nach 2 Tagen dann in testing drin sein.
Könnte natürlich immer Probleme geben, dass es langsamer geht.
Verantwortlich sind da halt die Paket Maintainer selbst. Nicht das Debian Security Team.

[lumines]

Also was die Security-Patches betrifft, ist Debian doch vorbildlich. Und wenn man ein aktuelleres Debian will, probiert man halt einfach testing oder unstable.

Für die meiste systemkritische Software stimmt das auch. Debian stable hatte z.B. die Fixes für Heartbleed knapp zwei Stunden nachdem der Patch rauskam.

Ubuntu hat eben den Vorteil, dass sie einfach öfter Releases rausbringen. Zusätzlich releasen sie diese Hardware Enablement Updates. Debian backportet selten Treiber innerhalb eines Releases. Die offiziellen Backports sind IMHO auch nicht ganz so gut gepflegt.

Aber wenn man mit der Software in stable klarkommt, dann spricht wenig dagegen. Man kann es installieren und praktisch vergessen.

Zwischen Debian Testing/Unstable (Sid) und ArchLinux gibt es aber noch einen kleinen aber feinen Unterschied: ArchLinux betreut sein Rolling-Release Modell, Debian nicht. D.h. wenn z.B. ein Sicherheitsfix für eine Software raus kommt, ohne jedoch ein neues Release raus zu bringen, dann sieht sich Debian Testing/Unstable nicht dazu verleitet diesen Fix "Out-of-Release" einzuspielen. So zumindest die offizielle Erklärung dazu. Wie das dann in der Praxis aussieht steht natürlich auf einem anderen Blatt.

So hatte ich das auch in Erinnerung. Die Prozesse hinter Testing sind eher darauf ausgerichtet ein neues Stable-Release zu formen und weniger zeitnah Sicherheitsupdates wie bei Stable zu liefern.

Also bei den wichtigen Paketen werden eigentlich die Security Fixes schnell nach unstable hoch geladen. Und das mit einer priority=high. Sollten also im Regelfall nach 2 Tagen dann in testing drin sein.
Könnte natürlich immer Probleme geben, dass es langsamer geht.
Verantwortlich sind da halt die Paket Maintainer selbst. Nicht das Debian Security Team.

Unstable hatte auch andere Prozesse für die Aufnahme von Paketen als Testing, wenn ich mich richtig erinnere.

[fezie]

Unstable hatte auch andere Prozesse für die Aufnahme von Paketen als Testing, wenn ich mich richtig erinnere.

Wie genau meinst du das?
Debian funktioniert schon seit ich es kenne, also seit Ewigkeiten, so dass die Pakete zuerst nach unstable hochgeladen werden. Und dann (je nach priority) nach 2,5 oder 10 Tagen nach testing migrieren.
Und irgendwann wird dann aus testing eben stable.

Unterschiede gibts nur beim Freeze. Der Hard Freeze für buster startet am 12. März.
Dann muss in der Tat alles von den Release Mastern akzeptiert werden um nach testing zu gelangen.

[Simon Moon]

Für die meiste systemkritische Software stimmt das auch. Debian stable hatte z.B. die Fixes für Heartbleed knapp zwei Stunden nachdem der Patch rauskam.

Ubuntu hat eben den Vorteil, dass sie einfach öfter Releases rausbringen. Zusätzlich releasen sie diese Hardware Enablement Updates. Debian backportet selten Treiber innerhalb eines Releases. Die offiziellen Backports sind IMHO auch nicht ganz so gut gepflegt.



Mit Treibern hatte ich bisher eigentlich noch nie Probleme, aber ich nutz jetzt auch nicht die neuste/exotische Hardware. Dafür lief Debian dafür out of the box bisher immer am rundesten, während bei Ubuntu z.b. einmal der Software Store nicht lief (was bei einem Neueinstieg doch etwas frustriert, wenn man apt oder andere Paketverwaltungsprogramme noch nicht kennt) und es aus meiner Erinnerung tendenziell eher etwas buggy / rucklig war.


Aber wenn man mit der Software in stable klarkommt, dann spricht wenig dagegen. Man kann es installieren und praktisch vergessen.


Jupp. Ich denk, sobald Buster stable wird, werd ich wieder vom aktuellen unstable zurück switchen und für Spielereien mit qemu eine KVM aufsetzen. Weiss gar nicht mehr genau, wieso ich eigentlich auf unstable ging.

[Simon Moon]

Wie genau meinst du das?
Debian funktioniert schon seit ich es kenne, also seit Ewigkeiten, so dass die Pakete zuerst nach unstable hochgeladen werden. Und dann (je nach priority) nach 2,5 oder 10 Tagen nach testing migrieren.
Und irgendwann wird dann aus testing eben stable.

Unterschiede gibts nur beim Freeze. Der Hard Freeze für buster startet am 12. März.
Dann muss in der Tat alles von den Release Mastern akzeptiert werden um nach testing zu gelangen.





It must have been in unstable for 10, 5 or 2 days, depending on the urgency of the upload;
It must be compiled and up to date on all architectures it has previously been compiled for in unstable;
It must not have release-critical bugs which do not also apply to the version currently in testing (see below for more information (https://www.debian.org/devel/testing#faq));
All of its dependencies must either be satisfiable by packages already in testing, or be satisfiable by the group of packages which are going to be installed at the same time;
The operation of installing the package into testing must not break any packages currently in testing. (See below for more information (https://www.debian.org/devel/testing#faq).)




Und wenn ich das richtig verstanden habe, muss es zur Aufnahme in Testing quasi auch die Stable Bedingungen erfüllen. Das ist afaik bei Wireguard der Grund, weshalb es noch in unstable ist, da der Entwickler meinte, es könnte noch einen Wechsel beim ein oder anderen Algorithmus geben - was dann eben ein Update (und nicht nur Security Patch) zum weiteren funktionieren benötigen würde. Umgekehrt gibt's da aktuell mit dem Certbot für Let's Encrypt "Probleme", da die Version aus stable bald nur noch Validierungsmöglichkeiten bietet, welche aus dem ACME Standard nicht mehr als sicher gelten.

[Lokadamus]

Neuer 3D Treiber für Intel Grakas.
https://www.heise.de/newsticker/meldung/Linux-Neuer-3D-Treiber-fuer-Intel-Grafik-in-Mesa-integriert-4321917.html
Ziel bei der Entwicklung des neuen OpenGL-Treibers sei es gewesen, dass dieser möglichst effizient arbeite und weniger CPU-Overhead als bisher ... für den Iris-Treiber ein Linux-Kernel ab Version 4.16 benötigt.

[Ganon]

Für Leute die die News nicht lesen ist noch zusätzlich zu erwähnen, dass dieser erst ab Broadwell funktioniert.

[fezie]

Und wenn ich das richtig verstanden habe, muss es zur Aufnahme in Testing quasi auch die Stable Bedingungen erfüllen. Das ist afaik bei Wireguard der Grund, weshalb es noch in unstable ist, da der Entwickler meinte, es könnte noch einen Wechsel beim ein oder anderen Algorithmus geben - was dann eben ein Update (und nicht nur Security Patch) zum weiteren funktionieren benötigen würde. Umgekehrt gibt's da aktuell mit dem Certbot für Let's Encrypt "Probleme", da die Version aus stable bald nur noch Validierungsmöglichkeiten bietet, welche aus dem ACME Standard nicht mehr als sicher gelten.

Gut bei komplett neuen Paketen oder (was noch nicht so lang eingeführt wurde) bei aus testing entfernten Paketen dürfen halt keine RC bugs drin sein.
Aber meistens sind die RC Bugs ja schon in der testing version drin.
Aber ja das kann natürlich für Verzögerungen sorgen.

Und ich hab noch die großen Transistions vergessen wie Perl/Python zum Beispiel. Dann muss man natürlich auch länger warten.

Kommt davon wenn man schon lange von testing auf unstable umgestiegen ist. Da kriegt man die Migrationsprobleme nicht mit.

[Simon Moon]

Gut bei komplett neuen Paketen oder (was noch nicht so lang eingeführt wurde) bei aus testing entfernten Paketen dürfen halt keine RC bugs drin sein.



Der Satz ergibt so irgendwie keinen Sinn?



Die Diskussion zu Wireguard hab ich nochmal nachgeschlagen:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849308


Soweit ich verstehe, ist es also effektiv so, dass in Testing nur rein kommt, was auch für Stable in Frage kommt und dafür muss dann eine Software auch über den Support-Zeitraum ohne Updates genutzt werden können. Anderes Beispiel ist Firefox, welches in der nicht ESR Version auch nicht in Testing kommt, weil eh klar ist, dass da Updates kommen werden und es nie in Stable kommt.

[Lokadamus]

Soweit ich verstehe, ist es also effektiv so, dass in Testing nur rein kommt, was auch für Stable in Frage kommt und dafür muss dann eine Software auch über den Support-Zeitraum ohne Updates genutzt werden können. Anderes Beispiel ist Firefox, welches in der nicht ESR Version auch nicht in Testing kommt, weil eh klar ist, dass da Updates kommen werden und es nie in Stable kommt.Richtig. Testing ist die Testphase, woraus später stable generiert wird. Die Software wird getestet und geguckt, dass sie stabil ist. Dabei entsteht das Problem, dass libs nicht aktualisiert werden, wodurch Anwendungen nicht aktualisiert werden. Für einen Server ist es meistens egal, ob lib so und so, welche irgendwie für xorg benötigt wird, nicht ganz aktuell ist. Aber als Desktopsystem hab ich doch gerne ein aktuelles System.
https://www.debian.org/devel/testing.de.html

Jup. Firefox esr wird in stable nur Angeboten. Man kann aber manuell Firefox (ohne ESR, also die aktuelle Version) einrichten.
https://wiki.debian.org/Firefox

[fezie]

Der Satz ergibt so irgendwie keinen Sinn?


Mittlerweile gibt es die Möglichkeit der auto removals.
Also wenn ein Paket in testing drin ist kann es theoretisch auch wieder rausfliegen.
Die Kandidaten dafür stehen hier (https://udd.debian.org/cgi-bin/autoremovals.cgi)

Wenn ein Paket zuviel offene RC Bugs hat und gleichzeitig keine oder kaum? Reverse Abhängigkeiten hat kann es passieren dass es aus testing rausfliegt.
hier (https://lists.debian.org/debian-devel-announce/2013/09/msg00006.html) die Ankündigungs Email dazu.

Dabei entsteht das Problem, dass libs nicht aktualisiert werden, wodurch Anwendungen nicht aktualisiert werden. Für einen Server ist es meistens egal, ob lib so und so, welche irgendwie für xorg benötigt wird, nicht ganz aktuell ist. Aber als Desktopsystem hab ich doch gerne ein aktuelles System.

Naja man muss unterscheiden zwischen der freeze Phase und der normalen.
Wie oben schon erwähnt, gibt es ja die zB. Perl/Python /QT5 transistions. Wo alle Pakete neugebaut werden die davon abhängen um die neuen Versionen nach testing zu kriegen.
Bei der libc braucht es das hingegen nicht und die wird ganz normal regelmäßig aktualisiert.

Nur beim freeze ist es so, dass dann tatsächlich keine großen Updates mehr kommen.
Aber libs sind da nicht anders wie die anderen Softwarepakete

[registrierter Gast]

Eine "Gibt's da was?" Frage...

Unter Manjaro XFCE hätte ich gerne eine Tool, mit der im Bluetooth Manager automatisch ein Network Access Point zu einem Gerät aufgebaut wird. Aktuell muss ich das immer händisch tun. Und gehe ich mit dem Handy vom Rechner weg, muss ich es danach wieder händisch hinzufügen.

Mit dbus-send konnte ich bereits ein NAP im Terminal aufbauen, aber es ist nicht das Gleiche wie im Bluetooth Manager.
dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF org.bluez.Network1.Connect string:'nap'

Danach fehlt noch das Netzwerkinterface.

[Gast]

[imghttps://cdn-images-1.medium.com/max/1600/1*63IXMn2ZYiGZUb1KcWY0Mg.png[/img]
Does this look like a consistent UI to you?





More on Headerbars: Rebuttals
https://pointieststick.com/2019/03/06/more-on-headerbars-rebuttals/

https://www.reddit.com/r/kde/comments/ay5o7k/more_on_headerbars_rebuttals/ehz1zdb/



Unity-Headers Concept: using server-side hearderbars to create a consistent, customizable and space-saving UI, for most applications.
https://medium.com/@leftcrane/unity-headers-concept-using-server-side-hearderbars-to-create-a-consistent-customizable-and-fbdb0d9696c

[Tyrann]

ich suche für cinnamon ein Tool ähnlich wie NetWorx unter Windows
https://i.imgur.com/auBviM8.png

bisher habe ich nur das Systemmonitor Applet gefunden, da fehlt mir aber die Achsenbeschriftung oder Durchsatzanzeige

[Gast]

ich suche für cinnamon ein Tool ähnlich wie NetWorx unter Windows
https://i.imgur.com/auBviM8.png

bisher habe ich nur das Systemmonitor Applet gefunden, da fehlt mir aber die Achsenbeschriftung oder Durchsatzanzeige

Auf die Gefahr hin dass es schon bekannt ist, mit Conky kann man ziemlich alle Systeminformationen grafisch darstellen. Erfordert allerdings dass man ev. selber konfigs bzw lua code schreibt, was aber nicht weiter schwer ist.

[aufkrawall]

Mindestens acht Jahre alter Performance-Bug im NV-Treiber ;D :
https://github.com/yshui/compton/issues/11#issuecomment-471184366

[BBig]

sway 1.0 is da!

https://swaywm.org/assets/logo.png

==> Announcing the release of sway 1.0 @ drewdevault.com (https://drewdevault.com/2019/03/11/Sway-1.0-released.html)

1,315 days after I started the sway project, it’s finally time for sway 1.0! I had no idea at the time how much work I was in for, or how many talented people would join and support the project with me. In order to complete this project, we have had to rewrite the entire Linux desktop nearly from scratch. Nearly 300 people worked together, together writing over 9,000 commits and almost 100,000 lines of code, to bring you this release.


==> https://github.com/swaywm/sway/releases:


Sway 1.0 (together with wlroots) includes 6,875 changes from 205 contributors. This is the first stable release of sway. The recommended wlroots release for use with sway 1.0 is wlroots 0.5.

100% i3 compatible*
100% i3 IPC compatible*
100% i3-gaps compatible
100% i3bar compatible
* Not including a small number of features which are are deliberately unsupported, such as layout save/restore or features which only make sense on X11

== // ==

In your favorit linux distro soon™, or maybe even right now!
- https://www.archlinux.org/packages/community/x86_64/sway/ :D

[Ganon]

Ryan C. Gordon hat übrigens eine SDL 1.2 Kompatibilitäts-Bibliothek für SDL 2 geschrieben: https://www.patreon.com/posts/25321792

Eine uralt-Library weniger, die man sonst nie los wird... :) uuuuund:


So, in summary:

Want to run these games on Wayland without an X11 fallback? Done.

Want to run these games on Windows UWP? Metal? Direct3D 11? Done.

Want to run these games on platforms that conflict with the LGPL? Done.

Want to run these games on macOS Mojave with all the insane fixes we had to make to SDL2 just to keep things running? Done.

Want to update your dusty old SDL 1.2 package and find it's now several megabytes smaller? Done.

edit:
Wer es selbst bauen will: ggf. erst die SDL/X11 Pfade in der CMakeList fixen.

[Tyrann]

Auf die Gefahr hin dass es schon bekannt ist, mit Conky kann man ziemlich alle Systeminformationen grafisch darstellen. Erfordert allerdings dass man ev. selber konfigs bzw lua code schreibt, was aber nicht weiter schwer ist.

ich hätte die Anzeige aber gern in der Taskleiste

[Rampage 2]

Manjaro 18.0.4 Final (gilt nur für XFCE, KDE und Gnome) ist jetzt released:

[Stable Update] 2019-03-12 - Kernels, KDE, Deepin, LibreOffice, Nvidia, Browsers, Calamares (https://forum.manjaro.org/t/stable-update-2019-03-12-kernels-kde-deepin-libreoffice-nvidia-browsers-calamares/78740)

Aber die "Architect Edition" ist immer noch nur 18.0.2 - warum ist das so? :confused:

Und welche Kernel-Version ist jetzt drin? 4.19.28 oder 5.0.1 ? Da ich so gut wie gar keine Linux-Erfahrung habe, blicke ich da nicht so durch - ich kann mir aus den Release Notes (Abs. "Currently supported Kernels") nichts Eindeutiges zusammenreimen...

Und Übrigens: Ich finde die Versions-Nomenklatur für Linux-Kernel total für den Popo... die Primärziffer sollte erst dann erhöht werden, wenn auch wirklich größere und/oder umfangreichere Änderungen am Kernel vorgenommen wurden:facepalm:

R2

[Ganon]

Und Übrigens: Ich finde die Versions-Nomenklatur für Linux-Kernel total für den Popo... die Primärziffer sollte erst dann erhöht werden, wenn auch wirklich größere und/oder umfangreichere Änderungen am Kernel vorgenommen wurden

Was wäre denn für dich eine umfangreichere Änderung?

[BBig]

...

Und welche Kernel-Version ist jetzt drin? 4.19.28 oder 5.0.1 ? Da ich so gut wie gar keine Linux-Erfahrung habe, blicke ich da nicht so durch - ich kann mir aus den Release Notes (Abs. "Currently supported Kernels") nichts Eindeutiges zusammenreimen...

Sieht nicht so aus, als hättest du schon mal einen Blick in das Wiki (https://wiki.manjaro.org/index.php?title=Main_Page) geworfen:

==> https://wiki.manjaro.org/index.php?title=Manjaro_Kernels

Mach dein Terminal auf und:

mhwd-kernel -li

Plus, nun auch Kernel 5.0 laut Changelog, :tongue:

[Narolf]

Und Übrigens: Ich finde die Versions-Nomenklatur für Linux-Kernel total für den Popo... die Primärziffer sollte erst dann erhöht werden, wenn auch wirklich größere und/oder umfangreichere Änderungen am Kernel vorgenommen wurden:facepalm:
Aufgrund des Entwicklungsmodells des Kernels würde das faktisch bedeuten, dass die erster Ziffer sich nie mehr ändert, wenn sie es so machen würden wie du dir das vorstellst. Dann könnte man die erste Ziffer auch direkt weglassen und einfach hoch zählen, wie Chrome oder Firefox. (was übrigens auch zur Diskussion stand, wenn ich mich richtig erinnere)

[exzentrik]

Aber die "Architect Edition" ist immer noch nur 18.0.2 - warum ist das so? :confused:

Das hinkt scheinbar (!) immer etwas hinterher, hat aber nichts zu bedeuten. Architect aktualisiert sich während des Setup-Prozesses selbst und lädt auch stets die jeweils aktuellen Manjaro-Pakete der gewählten GUI, des Kernels, des Grafiktreibers usw. Die eigentliche Architect-Versionsnummer (also die des Installers) lautet derzeit übrigens 0.9.22.

[Ganon]

Das hinkt scheinbar (!) immer etwas hinterher, hat aber nichts zu bedeuten. Architect aktualisiert sich während des Setup-Prozesses selbst und lädt auch stets die jeweils aktuellen Manjaro-Pakete der gewählten GUI, des Kernels, des Grafiktreibers usw. Die eigentliche Architect-Versionsnummer (also die des Installers) lautet derzeit übrigens 0.9.22.

Wenn ich das richtig in Erinnerung haben will er nur das Live-CD System benutzen und das System nicht installieren.

[Rampage 2]

Das hinkt scheinbar (!) immer etwas hinterher, hat aber nichts zu bedeuten. Architect aktualisiert sich während des Setup-Prozesses selbst und lädt auch stets die jeweils aktuellen Manjaro-Pakete der gewählten GUI, des Kernels, des Grafiktreibers usw. Die eigentliche Architect-Versionsnummer (also die des Installers) lautet derzeit übrigens 0.9.22.

Ich habe im Moment auch ganz andere Probleme - vor ein paar Stunden die frischgebrannte Manjaro-DVD auf dem neuerem Laptop gestartet (im BIOS das UEFI-Laufwerk ausgewählt) und anscheinend will weder die iGPU von Intel, noch die dGPU von Nvidia, denn irgendwann bleibt das Setup einfach stecken bei einem dieser beiden Schritte:

- a stop job is running for LiveMedia MHWD script

oder, falls ich weiter komme:

- started TLP system startup shutdown

Bei der Hardware handelt es sich um eine 6700HQ Intel Skylake CPU (mit HD Graphics 530 iGPU) und eine GTX 960M Nvidia dGPU mitsamt 8GB RAM.

Und ich bin nicht der Einzige mit dieser unglücklichen CPU-GPU Kombination - diese spezifische Kombination scheint Manjaro wohl überhaupt nicht zu schmecken. Insbesondere die GTX 960M scheint bei vielen Benutzern zu Problemen zu führen - die ersten Problemberichte gingen schon 2015/2016 los...

Nachvollziehen kann ich es trotzdem nicht - wenn wirklich schon Kernel 5.0 enthalten ist, dann sollten sogar schon Turing-GPUs unterstützt werden, geschweige denn eine GPU aus dem Jahr 2015. Außerdem müsste es doch auch einen Standard-Anzeigetreiber geben? :|

R2

[exzentrik]

Wenn ich das richtig in Erinnerung haben will er nur das Live-CD System benutzen und das System nicht installieren.

Dann fällt Architect eh flach, da das eine reine CLI-Installations-Umgebung ist.

@Rampage2: Welche Manjaro-ISO verwendest du denn gerade für die Installation? Hast du den Free- oder Non-free-Treiber gewählt? Und meinst du wirklich das Setup, das mittendrin stecken bleibt, oder doch den Boot-Vorgang eines Live-Systems (die genannten Meldungen deuten eher auf letzteres)? Der Kernel 5.0 wird bei einem Live-System übrigens noch nicht aktiv sein. Ich tippe eher auf die 4.19 LTS. Du könntest als Erstes probieren, auf Free- oder Non-free-Treiber umzustellen und damit dein Glück zu versuchen.

[BBig]

Dann fällt Architect eh flach, da das eine reine CLI-Installations-Umgebung ist.

@Rampage2: Welche Manjaro-ISO verwendest du denn gerade für die Installation? Hast du den Free- oder Non-free-Treiber gewählt? Und meinst du wirklich das Setup, das mittendrin stecken bleibt, oder doch den Boot-Vorgang eines Live-Systems (die genannten Meldungen deuten eher auf letzteres)? Der Kernel 5.0 wird bei einem Live-System übrigens noch nicht aktiv sein. Ich tippe eher auf die 4.19 LTS. Du könntest als Erstes probieren, auf Free- oder Non-free-Treiber umzustellen und damit dein Glück zu versuchen.

Ich habe sofort wie exzentrik gedacht.
==> Beim Boot: http://gigenet.dl.osdn.jp/storage/g/m/ma/manjaro/Manjaro-User-Guide.pdf#page=34

[Gast]

ich hätte die Anzeige aber gern in der Taskleiste
Dann bleibt nur in der community suchen, auf die schnelle z.b. hier
https://cinnamon-spices.linuxmint.com/applets

oder wenn gar nichts passendes da ist selber schreiben
http://developer.linuxmint.com/reference/git/cinnamon-tutorials/write-applet.html
habs nur kurz überflogen, scheint nicht sonderlich schwer zu sein.

[Rampage 2]

Dann fällt Architect eh flach, da das eine reine CLI-Installations-Umgebung ist.


Das heißt...? (Bitte detaillierter begründen;))

@Rampage2: Welche Manjaro-ISO verwendest du denn gerade für die Installation?


18.0.4 (Stable) KDE-Edition (x64) .iso auf DVD


Hast du den Free- oder Non-free-Treiber gewählt?


Standardmäßig ist der Free-Treiber ausgewählt. So habe ich es auch beim 1. Versuch gestartet und blieb dann bei dem "LiveMedia MHWD" Dingsbums stecken - wie viele Andere anscheinend auch!

Danach der 2. Versuch mit "non-free" Treibern.

Bei "non-free" habe ich auch versucht, gezielt den Nouveau-Treiber (Nvidia) oder aber den i915-Treiber (Intel) zu aktivieren - k.A., ob ich es auch geschafft habe. Aber beim "Nouveau" kam ich IIRC etwas weiter - dafür kam dann stattdessen der Stuck bei "LWS". Auffällig war, dass dabei laute Lüftergeräusche zu hören waren - offensichtlich wurde die GPU(-Lüfter) aktiviert, die ansonsten NIE aktiv ist...

IIRC kam ich auch bei i915 bis "LWS", aber da bin ich mir weniger sicher:wink:


Und meinst du wirklich das Setup, das mittendrin stecken bleibt, oder doch den Boot-Vorgang eines Live-Systems (die genannten Meldungen deuten eher auf letzteres)?


Ich bin zuerst ins Auswahlmenü (Zeit-, Sprach-, Tastatur-, Treiber- und Boot-Optionen) gekommen. Nachdem ich die entsprechenden Einstellungen vorgenommen habe, begann dann der eigentliche Bootprozess - es wurden eine ganze Menge Sachen und Dienste geladen und gestartet, bis dieser Prozess irgendwann steckenblieb. (s.o.)


Der Kernel 5.0 wird bei einem Live-System übrigens noch nicht aktiv sein. Ich tippe eher auf die 4.19 LTS.


Wozu denn das? Wenn ein neuer Kernel neue Gerätetreiber enthält, dann ist das für ein erfolgreiches Booten bzw. Kompatibilität besonders wichtig... oder etwa nicht?


Du könntest als Erstes probieren, auf Free- oder Non-free-Treiber umzustellen und damit dein Glück zu versuchen.


IMO ist für mich das aktuell größere Problem, dass die Tastatureinstellungen (und vrmtl. auch die restlichen Präferenzen) anscheinend erst beim Bootprozess angewandt werden - jedenfalls habe ich große Probleme, mich im Auswahlmenü zurechtzufinden und vor allem mit der Command-Line... manche Zeichen kann ich auf meiner Tastatur gar nicht eingeben (US-Layout...) - auch mit Shift oder Alt nicht!

Auch scheint es keine Apply-Taste für die Command-Line zu geben - wenn ich die Return-Taste drücke, geschieht nichts außer einem Zeilenumbruch. Und mit der Esc-Taste kehrt man zwar ins Hauptmenü zurück, aber dann werden auch alle Änderungen verworfen...

Wie kann man seine Präferenzen für das Auswahlmenü selbst übernehmen? Also VOR dem Boot-/Setup-Prozess?

R2

[Kehaar]

Für ein altes System suche ich zum Testen (ohne Veränderungen, Installation oder Umbau) eine Live-DVD mit integrierten und funktionierenden I²C-Tools. Gib es derartige Linux-Varianten? Kann evtl. auch schon etwas älter (5 Jahre) sein. Oder muss man sich eine derartige Live-DVD selbst erstellen?

[exzentrik]

Das heißt...? (Bitte detaillierter begründen;))

Die Architect-ISO verfügt über keine klassische GUI und vorinstallierte Software, ist also kein autark nutzbares Livesystem wie etwa via Manjaro-KDE-ISO, sondern rein zu Installationszwecken gedacht.

Dass bei einem Livesystem nicht immer der neueste Kernel eingesetzt wird, hat sicherlich Stabilitätsgründe. Es soll ja möglichst auf vielen Systemen reibungslos funktionieren, weshalb man da besser auf altbewährte bzw. LTS-Kernel setzt. Daher vermute ich, dass die 5.0(.1) noch nicht als Basis dient – sie ist halt sehr frisch und zudem gerade erst überhaupt im Stable-Zweig der Manjaro-Paketquellen gelandet.

Was das Boot-Problem angeht, im Boot-Menü mal auf den Manjaro-Boot-Eintrag gehen und die Taste "E" drücken, ans Ende der Textausgabe scrollen und in eine eigene Zeile Folgendes eingeben:

nomodeset nouveau.modeset=0 systemd.mask=mhwd-live.service

Dann mit der entsprechenden Taste Manjaro booten lassen. Und die ganze Prozedur jeweils mit Free- und Non-Free-Treiber probieren, falls es nicht direkt fruchtet. (Das Zeichen "=" liegt im US-Layout übrigens links neben Backspace, ohne ALT oder STRG.)

Wenn das auch nicht hilft und du Manjaro richtig installieren willst, musst du dich wahrscheinlich doch mal mit Architect auseinandersetzen.

EDIT: Falls du zufällig einen Dell-Laptop einsetzt, könnte dich diese Anleitung (https://gist.github.com/MeirBon/c99ae4e9e40f7e542361f646e4f637f5) womöglich auch weiterbringen. "Secure Boot" scheint da zum Beispiel ein Fallstrick zu sein.

[Thoro]

Wozu denn das? Wenn ein neuer Kernel neue Gerätetreiber enthält, dann ist das für ein erfolgreiches Booten bzw. Kompatibilität besonders wichtig... oder etwa nicht?

Weil neuere Kernels auch manchmal Probleme machen können, die ältere Kernels nicht haben. Deswegen ist im Normalfall so weit ich weiß immer ein LTS-Kernel der Standard-Kernel von Manjaro bei der Installation und man kann sich dann einfach andere dazuinstallieren per GUI.

[lumines]

Dual-GPU-Setups speziell von Nvidia waren unter Linux übrigens schon immer problematisch. Ich habe keine Ahnung vom aktuellen Stand, aber vor ein paar Jahren war das keine Kombination, die man wirklich haben wollte.

[Tyrann]

Dann bleibt nur in der community suchen, auf die schnelle z.b. hier
https://cinnamon-spices.linuxmint.com/applets

oder wenn gar nichts passendes da ist selber schreiben
http://developer.linuxmint.com/reference/git/cinnamon-tutorials/write-applet.html
habs nur kurz überflogen, scheint nicht sonderlich schwer zu sein.


habe es z.Z. so am laufen: http://666kb.com/i/e20zacehfgn6mfabk.gif
leider sind Zahl und Graph von zwei unterschiedlichen Applets

[johla]

Auf meinem Kubuntu 18.10 laden teilweise Webseiten ewig (Verbindung über Router), sowohl in FF als auch Chromium, auf dem parallelen Windows 10 nicht. Gibt es eine Möglichkeit außer Neuinstallation, die Netzwerkeinstellungen (wirklich alles, was relevant sein könnte) zurückzusetzen?

[Ganon]

Da gibt's nicht viel relevantes zum Zurücksetzen. Ich vermute jetzt mal WLAN? Kann durchaus sein, dass dein WLAN Chipsatz nicht ordentlich unterstützt wird und er darum in einem langsameren Modus arbeitet.

Gib mal im Terminal:

nmcli dev wifi

ein und schaue mal welche Datenrate dort für deine WLAN Verbindung steht und vergleiche das ggf. mal mit Windows.

[DevilX]

Dolphin listet bei mir die Arbeitsgruppen und Freigaben nicht mehr auf, keine ahnung seit wann.
Wie sieht das bei euch aus?

P.S. Nutze Arch linux

[johla]

Da gibt's nicht viel relevantes zum Zurücksetzen. Ich vermute jetzt mal WLAN?
LAN/Ethernet. Es war einmal so schnell wie unter Windows, aber dann habe ich vermutlich Einstellungen verändert.

[iuno]

Wenn der Verbindungsaufbau lange dauert kann es auch an den DNS Einstellungen liegen. Hast du vielleicht mal mit DNS experimentiert? Wird z.B. gerne zu adblocking-Zwecken gemacht.
Oder ist der Durchsatz tatsaechlich extrem gering, wenn bereits eine Verbindung besteht? Vermiss doch mal die effektive Bandbreite von dem Rechner zu einem anderen im selben Netz.

[johla]

Ja, liegt wohl an der /etc/resolv.conf. Wie muss die "richtig" heißen für einen Speedport Smart 3 bei der Telekom, und wie mache ich, dass die Änderungen einen Neustart überleben?

[lumines]

Ja, liegt wohl an der /etc/resolv.conf. Wie muss die "richtig" heißen für einen Speedport Smart 3 bei der Telekom, und wie mache ich, dass die Änderungen einen Neustart überleben?

Eigentlich sollte man die gar nicht manuell anpassen. Die DNS-Einstellungen sollte bei Ubuntu der Networkmanager dynamisch von deinem Speedport per DHCP übernehmen.

Die Einstellungen kommen komplett auf dein restliches Netzwerk an, da gibt es keine "richtige" Konfiguration.

[johla]

Die /etc/resolv.conf ist bei mir durch irgendein Paket vermutlich geändert worden und wird nicht mehr vom Speedport übernommen. Wie bewirke ich, dass dies wieder gemacht wird?

Unter der Adresse speedport.ip sehe ich die IP-Adressen des primären und sekundären DNS-Servers auf dem Router. Diese sind von 127.0.0.53 in der /etc/resolv.conf verschieden.

[iuno]

127.xxx sind loopback Adressen auf deinem host. 127.0.0.53 wird von systemd-resolved benutzt. Ich weiss nicht, ob deine Distri das benutzt oder du damit was gemacht hast?

Du koenntest jetzt einfach die IP von deinem Router in die resolv.conf eintragen, aber wenn systemd-resolved oder z.B. auch NetworkManager entsprechend konfiguriert sind, wird die Datei einfach wieder ueberschreiben.

[johla]

127.xxx sind loopback Adressen auf deinem host. 127.0.0.53 wird von systemd-resolved benutzt. Ich weiss nicht, ob deine Distri das benutzt oder du damit was gemacht hast?

Du koenntest jetzt einfach die IP von deinem Router in die resolv.conf eintragen, aber wenn systemd-resolved oder z.B. auch NetworkManager entsprechend konfiguriert sind, wird die Datei einfach wieder ueberschreiben.
Genau das passiert. Wie kann ich das System so konfigurieren, dass alles so wie nach einer Neuinstallation ist?

[Account]

ein paar kleinere ärgernisse mit kde, weiß jemand abhilfe?

- knotes verbummelt hin und wieder meine notes, existieren einfach nicht mehr. hab keine regelmäßigkeit entdecken können wann und wie?

- gibt es ein temperatur-applet mit einer average-of funktion? meine cpu hat nur pro-kern fühler und der mainboard-sensor gibt müll von sich.

- im application menu werden mir kate und dolphin als favourites aufgedrängt. wenn ich sie entferne, sind sie nach dem nächsten neustart wieder da. wie werd ich die los?

[iuno]

Genau das passiert. Wie kann ich das System so konfigurieren, dass alles so wie nach einer Neuinstallation ist?

Wie gesagt weiss ich nicht, was bei dir Standard war.

Gib mal in einem Terminal `systemctl status systemd-resolved.service` und `systemctl status NetworkManager.service` ein, dann wird ersichtlich, was gerade eingestellt ist und wie die presets waren.
Ich gehe mal davon aus, dass du eigentlich NetworkManager benutzt (was idR. der Fall ist wenn man das Netzwerk mit GUI settings konfiguriert) und faelschlicherweise resolved an ist. Dann waere die Loesung `systemctl disable systemd-resolved.service` und im NM das DNS wieder einzustellen, der dann die /etc/resolv.conf ueberschreiben sollte.

Es gibt mit etckeeper uebrigens ein nettes Tool, das hilft, wenn man Systemeinstellungen verstellt und nachvollziehen will, wie es mal war und wann was geaendert wurde. Das macht aber nur Sinn, wenn man eh schon mit Tools fuer Versionskontrolle vertraut ist.


- gibt es ein temperatur-applet mit einer average-of funktion? meine cpu hat nur pro-kern fühler und der mainboard-sensor gibt müll von sich.
Durchschnitt kenne ich nicht, aber das thermal monitor applet kann aus einer Gruppe von Sensoren (also z.B. alle Kerne) immerhin den hoechsten Wert anzeigen. Zu den anderen Problemen kann ich nichts sagen.

[Abnaxos]

Dann waere die Loesung `systemctl disable systemd-resolved.service` und im NM das DNS wieder einzustellen, der dann die /etc/resolv.conf ueberschreiben sollte.

Normalerweise weigert sich NetworkManager eine resolve.conf zu überschreiben, die er nicht selber geschrieben hat. Es gibt irgendwo eine Option dazu. Sehr wahrscheinlich wird es daher auch nötig sein, die alte resolv.conf zu löschen, damit NM eine neue schreibt.

[fezie]

Also bei mir überschreibt der NM die resolv.conf immer.
Zumindest bei der IPv4 Einstellung "Automatisch DHCP"

[johla]

"systemctl disable systemd-resolved.service" gemacht, jetzt ist die /etc/resolv.conf leer bis auf Kommentare. Ich habe sie auch schon gelöscht und den NM restarted, bringt alles nichts. :(

[fezie]

Was für eine Einstellung im NM nutzt du denn? DHCP oder statisch?

[johla]

DHCP.

[Rooter]

Kurze Frage:
Wie suche ich mit grep nach einer Zeichenfolge, die mit einem Bindestrich beginnt? Denn der will das dann als Option verarbeiten.

MfG
Rooter

[Ganon]

Musst du mittels \ "escapen", z.B. grep "\-test". edit: Alternativ kannst du auch das Auswerten der Argumente mittels "--" beenden. Also z.B. grep -- "-test"

[Rooter]

Musst du mittels \ "escapen", z.B. grep "\-test". edit: Alternativ kannst du auch das Auswerten der Argumente mittels "--" beenden. Also z.B. grep -- "-test"Dann war ich ja ganz nah dran, an den \ zum escapen dachte ich schon, aber ohne die " geht es nicht... X-D

EDIT: -- ist auch gut! Geht das bei allen Programmen?

THX! :up:

MfG
Rooter

[fezie]

EDIT: -- ist auch gut! Geht das bei allen Programmen?


Das ist zumindest die übliche Variante.

[Ganon]

EDIT: -- ist auch gut! Geht das bei allen Programmen?

Das ist zumindest POSIX Standard (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02). Aber ob das bei allen Programmen geht, da würde ich nicht meine Hand für ins Feuer legen :D

[Rooter]

Das alle war ja nicht wörtlich gemeint. Aber POSIX Standard ist mir alle genug. ;)

MfG
Rooter