|
|
|
|
|
|
|
| | Zitat von hoschi
| | Zitat von FuSL
| | Zitat von hoschi
JAVA/JRE/JNI
| |
Weia. 
| |
Hat sich als schlimmer herausgestellt als gedacht 
| |
Schlecht geschriebene Legacysoftware. Überraschung, dass das mit egal welcher Technologie stinkt.
|
|
|
|
|
|
|
|
|
|
|
Hat irgendjemand hier schon mal das Problem mit Screentearing unter Manjaro mit Gnome bei Nvidia Karten gelöst?
Laut Recherche finde ich nur einen Fix aus den arch Foren, der Performance Einbussen und nicht ganz sauber ist, im Gegensatz zu z.B. Intel Treibern (TearFree true). Das wollte ich nicht unbedingt.
Was das nervigere Problem dabei ist, dass ich ab und zu weisse Frames zwischendrin habe auf einem der Displays. Das ist relativ verstörend, wenn das LaptopDisplay ab und zu einen weissen Screen anzeigt für eine ms. Dazu finde ich auch nur Fragen und Lösungen zu blank Screens after boot und so was. Vllt beschreibe ich das Problem falsch?
// abgesehen davon,hat Manjaro direkt nach der Installation schon ewige Bootzeiten.
Ich hab noch n DualBoot Windows drauf (Rechner ovn der Arbeit, mit Win wollte ich nur zocken  )
Angeblich funktioniert das gar nicht mit bitlocker, aber ich hatte damit keine Probleme.
Nur von der Verschlüsselung (LUKS) zum bootsplash (?) dauert es schon recht lang.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von KingGinord am 12.12.2020 12:29]
|
|
|
|
|
|
|
|
|
Ich will nem Ü60-jährigen Nachbarn als Hilfe gegen Vereinsamung mein altes T400 geben, damit er per Zoom kommunizieren kann.
Mein erster Gedanke für das OS wäre Xubuntu. Fahre ich damit immer noch gut oder hat sich da was besseres herauskristallisiert?
|
|
|
|
|
|
|
|
|
|
|
Ich hatte meinem Opa vor ein paar Jahren einen Laptop mit Linux Mint eingerichtet; einer anderen älteren Dame aus der ferneren Verwandschaft Manjaro. Beide kamen jeweils gut zurecht – Manjaro war nur für mich etwas praktischer, da ich aufgrund der Arch-Basis "leichter" bei Problemen unterstützen konnte.
Müsste beides auch auf älteren Geräten noch entspannt laufen.
|
|
|
|
|
|
|
|
|
|
|
xubuntu ist schon in ordnung, t400 ist relativ alt da könnte mint+co schon zuviel resourcen ziehen.
was sich bei mir übrigens bewährt hat ist ein icon auffem desktop das ich immer "jan zuriff" nenne. das öffnet dann nen terminal das automatisch nen ssh reverse tunnel zu der maschine aufbaut so dass ich mich remote connecten kann und einfach auch "mal so schnell helfen"
hab auch 1-2 leute bei denen sie es explizit wollen dass das (im hintergrund) immer läuft dmait ich halt auch so drauf komm, aber allen andern geb ich da schon gern die "kontrolle" drüber, so dass ich nur remote drauf komm wenn sies auch explizit erlauben.
|
|
|
|
|
|
|
|
|
|
|
|
Bei meinen Eltern läuft mein uralter core2duo mit xubuntu. Papa ist begeistert, macht wenig bis keine Probleme und schnell genug ist er auch noch zum surfen. Steckt ne SSD drin, ansonsten ist das Ding bestimmt 12 Jahre alt.
|
|
|
|
|
|
|
|
|
|
|
Für auf der Couch nehme ich jetzt auch wieder mein X201, was ja jetzt auch zehn ist. Läuft (Arch/i3, wie früher). Die Browser Firefox scheint in den letzten Jahren sehr viel optimiert zu haben, weil ich das zäher in Erinnerung hatte. Braucht natürlich einiges an Strom und der Akku hält auch nur ein paar Stunden statt ~nen Tag wie bei meinem Netbook, aber das Netbook hat halt nur 2 GB fest eingebauten RAM (und einen viel viel langsameren Prozessor) und das reicht heute halt einfach nicht mehr fürs "Net".
tl;dr Wenn 4+ GB RAM und eine SSD drinstecken, sollte das nach wie vor gut funktionieren.
e: Es gibt sie natürlich immernoch, die furchtbar langsamen, CPU-schmelzenden, RAM-füllenden Seiten. Reddit schafft das irgendwie immer, und einige Nachrichtenseiten, trotz Anabolikamissbrauch bei meinen Adblockern...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.12.2020 17:23]
|
|
|
|
|
|
|
|
|
Okay, dann fahre ich erstmal mit Xubuntu los. Danke! 
|
|
|
|
|
|
|
|
|
|
|
Gtk-Dateidialoge hängen bei mir seit ein paar Tagen die ganze Anwendung für ne ganze Weile auf, woran mag das liegen?
Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.UDisks2VolumeMonitor: Failed to activate service 'org.gtk.vfs.UDisks2VolumeMonitor': timed out (service_start_timeout=120000ms) (g-dbus-error-quark, 20)
Yeeehawwwww, 30 Sekunden (die Fehlermeldung ist falsch) blockender Timeout im GUI-Thread für Localhost-IPC, solider Default...
Aber warum failt dieser Gtk-Service denn?
gvfs-udisks2-volume-monitor[52639]: /usr/lib/gvfs-udisks2-volume-monitor: symbol lookup error: /usr/lib/gvfs-udisks2-volume-monitor: undefined symbol: g_unix_mount_point_at
D.h. der failt instant (pacman -Syu wird's sicher beheben), aber Gtk wartet trotzdem 30 Sekunden weil...?
e: Und warum merkt sich Gtk das nicht? Jedes "Open"/"Save as" -> wieder wird versucht den Dienst zu starten, wieder wird das GUI für 30 Sekunden geblockt etc. ... Old man yells at cloud: Was ist das überhaupt, dass der Dateidialog versucht einen Systemdienst zu starten, und dann auch noch blockend darauf wartet? Das ist ja bestimmt was um den Inhalt von Kameras und anderen Dingen aufzulisten, die keinen Dateisystemzugriff geben, warum macht man das nicht im Hintergrund, und aktualisiert die GUI mit den zusätzlichen Infos? "Ich starte hier jetzt mal Dienste synchron" ist doch schon grundsätzlich etwas, dass selbst wenn es klappt, nur auf Entwicklermaschinen mit x Cores und SSDs halbwegs akzeptabel ist, weil die schnell genug sind, dass die GUI dann nur 0.1 Sekunde statt ein paar Sekunden hängt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.12.2020 18:56]
|
|
|
|
|
|
|
|
|
GTK wild "critical errors" und "fatal" wefend ist doch eher ein zeichen dass es lebt/geht als der hinweis dass irgendwas nicht stimmt...
|
|
|
|
|
|
|
|
|
|
|
Aber die Gtk-Entwickler finden, dass das der Pain ist den man da feeled, und man soll ja nicht den Pain wegmachen [1], sondern die Ursachen beseitigen [2]. Eigentlich wäre "Gtk: The pain you feel" ein hervorragender Slogan für das Projekt.
Edit: so in der Art!
(Edit: Funfact: Zum Hochladen der Datei brauchte ich einen Gtk-Dateiauswahldialog, der wieder 30 Sekunden braucht um hochzukommen. Jetzt liegt's aber nicht mehr an dem "ls-as-a-service", sondern anscheinend an org.freedesktop.hostname1, was laut systemd aber normal startet (ist das "hostname-as-a-service"? -- edit: Ja, das ist wort-wörtlich ein D-Bus-Daemon, um den Hostnamen abzufragen. Wat.)).
Manchmal kann man die beseitigen, aber manchmal wird man die einfach. nicht. los. Beispiel letztens: Für jedes Widget einer bestimmten Art 3-4 CRITICAL ASSERTION FAILURES!!!111 bei der Initialisierung, weil die Widgets halt 0.000001 Sekunde lang existieren, bevor sie in ein Layout getan werden.
[1] g_log_set_writer_func > /dev/null.
Wenn es mal jemanden wirklich, wirklich interessieren sollte, kann man das immernoch ausschalten und sich den Spam anschauen.
[2] Ich wünschte ich hätte mir das ausgedacht, aber sowas schreiben die halt wirklich wörtlich zu Endnutzern.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 13.12.2020 22:18]
|
|
|
|
|
|
|
|
|
Ich kann Dir empfehlen den Matrix Channel von Gtk zu benuetzen, gerade wenn man keinen bestehenden Issue findet. Die Leute da sind auch immer hilfsbereit, zumindest was mich angeht.
#gtk:gnome.org
Zugegeben, ich fremdel auch mit DBus und haette gerade bei der Dokumentation von Systemd lieber gleich die C API gelistet - statt DBus. Wenn ich was von Systemd moechte, will ich das von Systemd und nicht ueber DBus von Systemd. Der Nutzen von DBus zur Interprozesskommunikation ist klar, neben Pipes, Semaphore und Message Queues. Und das die APIs auch ueber DBus bereit stehen ist gut.
Ich habe in den letzten Wochen auch Probleme gesammelt:
- Direkter Shutdown oder Reboot aus GNOME haengt zwei Minuten lang. Ein Fehler in gnome-session mit DBus, erst aufgreteten durch ein Update von Systemd. Schon gefixt, aber Archlinux hat den Fix immer noch nicht und ich sehe das als ein kritisches Problem.
- Fullscreen hat mit vielen Spielen nicht mehr funktioniert.
- Und Geeqie hat lange bekannte Fehler nicht realisiert. Hat keine Ursache in GNOME oder Gtk. Einmal MACRO nicht verstanden (Wayland), einmal Fehler in XLib (X11).
Ich denke die ersten Beiden Problem haetten mit mehr Testern abgefangen werden koennen. Schwierig. Dazu braucht man mehr Nutzer oder Firmen. Systemd koennte besser reagieren, es blinkt erstmal nur der Cursor zwei Minuten lang, bis Systemd beschliesst - dass das nichts mehr wird. Wenn man hart abbricht, muss man hinterher Journalrecovery erblicken. Nicht schoen, auch wenn da nichts passiert ist. Wenn Systemd bei sowas sofort auf den Bildschirm klar macht, hier passt was nicht, haette man das eher erledigen koennen.
Beim letzten Fehler merkt man, dass die Entwickler mal nur unter X11, mal nur unter Wayland entwickeln und dann auch aeltere Versionen der Bibliotheken verwemdem. Da haette ich wohl auch als Anwender schon bei Geeqie 1.5 mich nochmal melden sollen *anmeineeigenenasefass*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die letzte Zeile liest sich wie eine Drohung 
|
|
|
|
|
|
|
|
|
|
|
|
dann drück halt nicht CTRL+G
|
|
|
|
|
|
|
|
|
|
|
Ich habe es mit Escape versucht
|
|
|
|
|
|
|
|
|
|
|
Hab grad Updates gemacht und apt spuckt mir das hier am Ende aus:
| |
| Code: |
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu
|
|
Da ich sonst keine Probleme mit der Grafik habe, denke ich nicht, dass das irgendwie für mich relevant ist.
Trotzdem bin ich neugierig: Brauche ich diese Firmware?
e: mx-linux 19.3 Kernel 5.8.0-3
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Farbkuh am 25.12.2020 11:18]
|
|
|
|
|
|
|
|
|
|
Nein, außer du nennst einen AMD Instinct MI100 dein Eigen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von red
Nein, außer du nennst einen AMD Instinct MI100 dein Eigen.
| |
Äh, nein. 
|
|
|
|
|
|
|
|
|
|
|
|
Meine Fritzbox stellt LAN Ports einfach so zwischendurch von GBit auf 100Mbit. Laut hier geschieht das, wenn man ein Synology NAS mit beiden LAN Ports (über ein Switch) an der Fritze hat. Offenbar ist das auch bei mir der Grund. Was für Sachen es gibt...
|
|
|
|
|
|
|
|
|
|
|
|
urgs. ich hätte ja bei sowas irgend einen energiesparfick vermutet. aber das ist ja auch echt :/
|
|
|
|
|
|
|
|
|
|
|
Nervtötende "Features" von Linux/Steam:
Wenn ich Doom eternal spiel muss ich den zweiten Monitor in Linux abschalten, also auf single Monitor.
Sonst rutscht die Maus auf den zweiten Bildschirm irgendwann und ich komm nichtmehr ins Spiel zurück.
Monitor abschalten reicht nicht...
Acid
|
|
|
|
|
|
|
|
|
|
|
|
Kein nativer Port. Richtig?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von AcidPils
Nervtötende "Features" von Linux/Steam:
Wenn ich Doom eternal spiel muss ich den zweiten Monitor in Linux abschalten, also auf single Monitor.
Sonst rutscht die Maus auf den zweiten Bildschirm irgendwann und ich komm nichtmehr ins Spiel zurück.
Monitor abschalten reicht nicht...
Acid
| |
Schau mal ob es einen Fake Fullscreen oder änhliches gibt. Viele Spiele haben heutzutage diesen Modus und es löst das Problem manchmal.
|
|
|
|
|
|
|
|
|
|
|
Ich hab schon wieder irgendwie mein Grub zerfickt.
Das Thinkpad hat beim booten auf einmal "Fan Error" angezeigt. Hab nach der Lenovo-Anleitung dann die Standardeinstellungen im Bios wiederhergestellt. Jetzt bootet er nicht mehr in Grub sondern gleich nach Windows.
Ich hasse Probleme mit Grub, weil ich da immer so ratlos bin und mich das heillos überfordert.
Die Partitionen verwirren mich schon total...
2x EFI Systempartition
1x Primäre Partition
1x Wiederherstellung
1x Windows
Muss das so kompliziert sein?
e: NVM. Habs gelöst. 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Farbkuh am 27.12.2020 22:18]
|
|
|
|
|
|
|
|
|
Ok, denvercoder9.
2 mal ESP klingt jedenfalls schlecht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Farbkuh
e: NVM. Habs gelöst.
| |
ja und wie?
das ist meistens für andere auch hilfreich.
lass mich raten: im uefi grub als config wieder hinzugefügt?
|
|
|
|
|
|
|
|
|
|
|
Ja, sorry. War etwas angefressen, weil ich den halben Abend damit verbracht habe ein Problem zu lösen das ich nicht selber verursacht habe und von dem ich keine Ahnung habe. Außerdem hab ich bei Grub-related Problemen immer Angst mir das ganze Gerät zu zerschießen.
Ich hab den MX-Bootstick genommen und hab das Boot-Reparatur Tool benutzt und diesmal auch die richtige Variante (ESP) ausgewählt. Geht wieder einwandfrei.
Der/Die/Das alte Grub war auch noch vorhanden wurde halt nur nicht erkannt.
Whatever. Geht wieder und ich hoffe, dass ich mich erst wieder damit beschäftigen muss, wenn ich mal verstanden hab, wie dieser Vodoo funktioniert.
|
|
|
|
|
|
|
|
|
|
|
hmmm ok, komisch, danke für die ausführung aber WAS da jetzt genau kaputt war kann ich dir leider auch nicht sagen
finds nur amüsant dass wir da wohl diametral entgegenegesetze "ängste" haben.
wenn "grub kaputt ist", ist das schlimmste was man so machen müsste vonner live cd booten und das dann von der aus zu reparieren.
wenn der windows boot kaputt ist ja keine ahnung, ich glaub nicht wenige sind da schon mit ner kompletten neuintsallation beglückt worden.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 28.12.2020 10:39]
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
