ubuntuusers.de

Letalis_Sonus schrieb:

Das zuständige Skript sucht sich einfach selbstständig die nächste verfügbare Swap wenn keine dafür konfiguriert worden ist.

Aha, danke für die ausführliche Erklärung. Mir ist das vorher nie aufgefallen, dass da immer eine Suspend-Partition konfiguriert wird.

Allerdings ... ich habe den Befehl jetzt mal auf einem anderen Rechner ausgeführt, wo ich noch nie uswsusp installiert hatte. Da bekomme ich keine solche Ausgabe.

Da kann ich genau gegenteiliges berichten: Ich habe hier ein System auf dem ich es nie installiert habe, und die Meldung kommt trotzdem jedes mal.

UlfZibis schrieb:

Ich habe es nun aber mal doch mit dem 20.04 probiert, und zwar auch unter Unity. Zu meiner Überraschung funktioniert es damit.

Nach dem Aufwachen habe ich alles direkt wieder auf dem Schirm. Schön und gut, aber dass ich da nicht mehr nach dem Passwort gefragt werde, irritiert mich doch. Dann ist der Rechner ja "Freiwild". Sollte da nicht dennoch erst mal die Passwortabfrage kommen, so wie nach "Bereitschaft" auch?

Üblicherweise löst die Desktopumgebung dafür schlicht den Lock-Screen aus, der Kernel stellt ja nur den vorherigen Zustand her und hat mit dem ganzen Session Management nicht viel zu tun. Das kannst du also wohl auf deine "Zombie"-Desktopumgebung schieben, entweder erwartet Unity für den Lock-Screen ein bestimmtes Programm das nicht installiert ist oder etwas anderes läuft da in dem Kontext schief.

Letalis_Sonus schrieb:

Da kann ich genau gegenteiliges berichten: Ich habe hier ein System auf dem ich es nie installiert habe, und die Meldung kommt trotzdem jedes mal.

Alles sehr merkwürdig. Nachdem ich es nun wieder installiert habe, diesmal in Kombination mit zRam, kam die Anzeige nach sudo apt-get install hibernate uswsusp und erstmaligem sudo dpkg-reconfigure -pmedium uswsusp (um zu kontrollieren, ob der sich nicht wieder das zRam-Volume für das hibernate-image geschnappt hat) noch, alle weiteren Aufrufe, auch von sudo update-initramfs -u -k all zeigen die 3 Zeilen jetzt nicht mehr an. Und der Ruhezustand funktioniert dennoch, zumindest auf dem alternativen 20.04 hier.

Letalis_Sonus schrieb:

Üblicherweise löst die Desktopumgebung dafür schlicht den Lock-Screen aus, der Kernel stellt ja nur den vorherigen Zustand her und hat mit dem ganzen Session Management nicht viel zu tun. Das kannst du also wohl auf deine "Zombie"-Desktopumgebung schieben, entweder erwartet Unity für den Lock-Screen ein bestimmtes Programm das nicht installiert ist oder etwas anderes läuft da in dem Kontext schief.

Ich liege also richtig damit, dass ich, wenn alles richtig liefe, nach dem Passwort gefragt werden müsste. Na dann muss ich wohl auch damit leben.

UlfZibis schrieb:

Alles sehr merkwürdig. Nachdem ich es nun wieder installiert habe, diesmal in Kombination mit zRam, kam die Anzeige nach sudo apt-get install hibernate uswsusp und erstmaligem sudo dpkg-reconfigure -pmedium uswsusp noch, alle weiteren Aufrufe, auch von sudo update-initramfs -u -k all zeigen die 3 Zeilen jetzt nicht mehr an.

Evtl hat das auch schlicht etwas mit der Tatsache zu tun, dass eine dedizierte Swap Partition schon länger nicht mehr Umfang der Standard-Installation ist - meines Wissens nach wird dies stattdessen wie bei Windows nun über eine Art Pagefile gelöst. Ich habe bei meinem System noch von Hand partitioniert und dementsprechend auch noch eine dedizierte Swap Partition.

Basis-Sytem ist Lubuntu-32 18.04 minimal (dürfe wohl ohne uni- und multiverse sein)

Nein. Schmeiß doch mal universe und multiverse raus und zeige

 apt list |grep lokal

DJKUhpisse schrieb:

Basis-Sytem ist Lubuntu-32 18.04 minimal (dürfe wohl ohne uni- und multiverse sein)

Nein.

Ja schon klar. Allein schon wegen ubuntu-unity-desktop.

Ich kann aber auch ohne Updates mit dem System leben. Soll ja hauptsächlich zur Nebenbei-Nutzung auf dem Sofa dienen, und auch mal für Testinstallationen dienen, damit mein Haupt-Arbeitsrechner entlastet bleibt. Auch mein Auto bekommt schon ewig keine Updates mehr, ist aber noch lange nicht reif für den Schrott. Und bei meinen Palm-Treo-Handy hat das sogar Vorteile, da es weder fernabgehört werden kann noch der Standort genau abgefragt werden kann. Damals gab's so perfide Uberwachungs- und Tracking-Techniken noch nicht.

Ist es denn für dich so ein Problem, da amd64 zu installieren? Einfach mal machen.

DJKUhpisse schrieb:

Ist es denn für dich so ein Problem, da amd64 zu installieren? Einfach mal machen.

Siehe 9277763

Verstehe doch bitte einfach mal, dass 32 Bit bei Ubuntu Geschichte ist - ist zwar schade, ist aber so. In 20.04 scheint es dein Problem aber nicht zu geben:

Ich habe es nun aber mal doch mit dem 20.04 probiert, und zwar auch unter Unity. Zu meiner Überraschung funktioniert es damit. Nur was heißt das jetzt?

Dass du jetzt einfach 20.04 nutzt.

DJKUhpisse schrieb:

Verstehe doch bitte einfach mal, dass 32 Bit bei Ubuntu Geschichte ist - ist zwar schade, ist aber so.

Für mein Palm-Treo-Handy gibt es schon viel länger keine Updates mehr. Ich bin dennoch sehr glücklich damit, genauso wie mit meinem alten Auto ... selbst da kann ich noch Verbesserungen einbauen wie z.B. ein Radio. Warum soll ich die netto 1,6 GiB mit 64-Bit belasten, in mein kleines Auto baue ich doch auch nicht noch Akku und Hybrid-Antrieb rein, nur weil das moderner ist. Der schnelle Befehlssatz der 64-Bit CPU kommt ja auch unter 32-Bit-OS zum Tragen und wird unter 64-Bit nicht schneller.

In 20.04 scheint es dein Problem aber nicht zu geben:

Aber dafür andere, und ich hoffe, dass sich auch für das Ruhezustands-Problem noch eine Lösung findet, notfalls die pm-hibernate-Methode. Außerdem ist Ruhezustand auf dem "Schätzchen" für mich auch nur ein "nice to have".

UlfZibis schrieb:

Für mein Palm-Treo-Handy gibt es schon viel länger keine Updates mehr.

Und, quälst du den auch mit aktueller Software und einer Internetverbindung? Ich hör gerade mein Nokia 6120 laut lachen.

UlfZibis schrieb:

Warum soll ich die netto 1,6 GiB mit 64-Bit belasten

Das Problem sind nicht die 64-Bit, das Problem sind die Browser und "modernes" Webdesign. AMD64 hat den Speicherbedarf im Schnitt fast komplett durch Architekturverbesserungen kompensiert bekommen, allgemein gesprochen spielt das hier tatsächlich keine Rolle.

Jegliche Art von modernem Browser - sei es nun Firefox, Chrome/Chromium oder Edge - explodiert hingegen im RAM Verbrauch wenn die 2GB Adressraumgrenze wegfällt, völlig egal wie stark man selbst über die Konfiguration versucht das ganze einzuschränken. Das gilt auch für Anwendungen, die im Hintergrund versteckt eine Browser Engine verwenden, wie zB Microsoft's Electron Framework - mit populären Anwendungen wie Teams und Atom. Das perverse an der Geschichte ist, dass die Geschwindigkeitszugewinne die bei den Browsern mit dem hohen RAM Verbrauch teuer erkauft werden, statistisch am Ende schlichtweg überhaupt nichts bringen. Es gibt übrigens auch noch weitere, altbackenere Browser mit deutlich weniger RAM Verbrauch wie Pale Moon (ein immer noch aktiver Fork einer alten Firefox Version, bevor die alte Add-On API massakriert worden ist).

Obendrauf kommt der Trend, Webseiten heutzutage für kleine Hilfsfunktionen direkt mit haufenweise an fertigen JavaScript Bibliotheken dichtzubomben, die die Seite nicht nur extrem fett und langsam machen, sondern auch noch durch das Einbinden von Fremquellen ein ernstzunehmendes Sicherheitsproblem schaffen, das schon zahlreich ausgenutzt worden ist. Es ist ein allgemeiner Trend dass Software Entwickler lieber fetten Overhead in Kauf nehmen um "angenehmer" mit modernen Mitteln entwickeln zu können, weil ja alles immer leistungsfähiger wird - das betrifft praktisch die gesamte Web- und Anwendungsentwicklung, Effizienz interessiert in vielen Bereichen nur noch wenn man ohnehin sehr Hardware-nah arbeitet. Das ist allerdings insbesondere im Web besonders extrem.

Unity frisst übrigens auch viel zu viel RAM, es gibt deutlich besser geeignete Desktopumgebungen die optisch kompakt und sparsam sind, wie zB Fluxbox und Enlightment. Letzteres bietet dir sogar dazu noch Compositing an, was unter den Leichtgewichten schon echt selten ist. Compiz war auch deutlich sparsamer, bevor man es in C++ neu geschrieben und praktisch Unity-exklusiv gemacht hatte.

Aber gut, genug Kink-Shaming. Wenn du beim Quälen dieser armen alten Kiste deine sadistischen Triebe befriedigen kannst... Da sollte ich wohl eher darauf aufpassen, dass mein T60p bei dem Anblick keinen CPU-Infarkt bekommt (die alte Möhre läuft übrigens auch schon auf 64-bit).

DJKUhpisse schrieb:

Dass du jetzt einfach 20.04 nutzt.

Bringt nix, denn er nutzt ja Unity. Heißt maximal 9 Monate im Support → Abgelaufen im Januar 2021.