Beiträge von pcfreddy

Du schriebst; "Aber mal ehrlich, openSUSE Leap in der Version 15.0 läuft echt super!"

Seit wann arbeitest Du damit? Sind dir schon mal Unannehmlichkeiten aufgetaucht?

BTW: Was hälst Du von Tumbleweed?

Deswegen gibt es z. B. bei Packman auch noch keine Pakete für 15.1.
Alles klar.
Danke dafür.
Dann kommt nun 15.0 drauf in der Hoffnung, dass damit alles funktioniert und nicht so ein Shit dabei raus kommt.

Ist es denn nicht mehr so, dass die geraden Versionen schlechter sind als die ungeraden? Oder war das umgekehrt?

Soll es heißen, ich sollte lieber Leap 15,0 nehmen?

Moin zusammen,
ich habe nun meinen Laptop openSUSE Leap 15,1 (Beta) gegönnt.
Bislang lief alles perfekt. Bis ich den Stecker zog und das Laptop auf Akku lief. Dann kam das Problem und ich denke, dass es an der Energieverwaltung liegt.

Ich klappte den Bildschirm herunter.
Nach einiger Zeit wollte ich die Kiste wieder benutzen. Funktionierte aber nicht,
da sich der Desktop zwar -so denke ich- wiederhergestellt hatte aber der Bildschirm schwarz blieb.
Im Dunkeln sieht man, dass irgendwas am Bildschirm steht. Nur was?

In welcher Datei wird gespeichert. wie sich der Bildschirm nach dem Hochklappen verhalten soll (Er soll ja wiederhell werden)?

Sind das die Dateien unter $HOME/.config/
- systemmonitorrc und
- systemsettingsrc ?

Wenn ja, was muss ich darin einstellen damit sich der Bildschirm erholt?
Oder reicht es , wenn ich die Dateien umbenenne?

P.S.:
Ein Umschalten auf eine Konsole mit STRG-Alt (1-5) ist auch nicht möglich. Der Bildschirm bleibt schwarz
Selbst beim Start im Recovery Mode bleibt der Bildschirm schwarz

@Berichtigung Ich hab mir mal soeben Dein Tutorial angesehen.
Sehr einfach und lustig geschrieben. Na wenn alles mal soooo einfach wäre.

Zumindest hab ich jetzt mal 3 verschiedene Tools für systemd installiert. (KCM_Systemd, SystemD SystemManager und SystemdManager).
Ja, ich weiß, Zwei davon sind nicht von opensuse. Macht nix. Fliegen eh alle runter.
Der KCM_Systemd gefällt mir aber dennoch am besten. Schick gemacht.
Man kann direkt was in den unit-files ändern, wenn was sein muss.

@'wuzel99'
Danke für den Link. Wollte es eigentlich installieren. Es gibt aber ein Problem.
libQt5Core.so.5(Qt_5.11)(64bit) benötigt von systemdgenie-0.99.0-lp150.1.2.x86_64 wird nirgends zur Verfügung gestellt
Völliger Quatsch. Natürlich ist libQt5Core5 in der 64bit-Version installiert.
Na lassen wir das.

Wenn ich Scripte brauche schreibe ich sie mir eh selbst und benutze, nach Möglichleit, das SystemD.
Alles im Allem aber waren die Tools einen Augenschein wert.

Zitat von wurzel99

systemdgenie (man achte auf das D)

Na sag ich doch
Aber gut, dass es euch gibt.
@Sauerland Danke für den Link. Jetz hammers doch.
@Berichtigung Danke, dass Du mich darauf aufmerksam machst. Erst mal gucken, wie was geschrieben wurde. Dann schau ich mir auch Dein Tutorial an.Dann sehen wir weiter. Auf jeden Fall bleib ich am Ball. Es fängt an interessant zu werden.

Schade. Jetzt hatte ich vor mich mal ein wenig in die Programmierung von systemd timer zu fuchsen und dann sowas.
Vor dem programmieren hätte ich gern ein Tool installiert.
Den Systemd_KCM respektive den Systemgenie. Gibt ja beides auf GitHUB.
Strikt nach Readme.md installieren wollen.
Nur leider kommt die Fehlermeldung, dass er den Compiler nicht findet.

Zitat von Berichtigung

Tatsächlich versucht der Daemon eine möglichst gleichmäßige Lastverteilung.
Hintergrundjobs sollen ja möglichst wenig Ressourcen fressen.

Daher auch die vielen kleinen Häppchen (Scripte). Jaja.
Hat man viele kleine Dinge zu tun, machts ersten mehr Spaß und zweitens ist man, wenn man die vielen kleinen Häppchen auf einige Leute aufteilt, schneller fertig.
Und dann kommt noch der dritte Punkt ins Spiel, dass es auch etliche Arbeiten (Häppchen, Scripte) gibt die aufeinander warten.
Jepp. Is gebont. Hach, is det schööön. Wie im wahren Leben, ohne Rückenschmerzen.

Zitat von Berichtigung

Bei Systemd wird ein Prozess gestartet (der unter Überwachung von systemd selbst läuft),
der nur noch alle fälligen Jobs startet.

Bei Systemd wird ein Prozess gestartet. OK. Systemd ist in dem Fall wie ein Chef, der dem Prozess (dem Vorarbeiter) sagte was zu tun ist.
Und der Prozess (der Vorarbeiter) startet dann die fälligen Jobs (die Handlanger in der Firma)
Alles klar. Muss einem ja nur gesagt werden.
Is ja wie inner Firma.

Zitat von Berichtigung

Systemd.timers sind dem Cron- System also weit überlegen. Kein Wunder: cron ist fast 40 Jahre alt, Systemd- Timer noch jung.

Auweia. So alt ist cron schon? Der gehört in Rente. Lass mal die jungen ran.
Aber wenn die Cronjobs von alten Daemons weiter funktionieren sollen, darf cron nicht in Rente gehen.
Es sei denn ... Ich glaube das schafft Systemd auch noch.

Und da cron alle Jobs nacheinander abarbeitet und Systemd (mehr oder minder) alles parallel schafft, ist es wie in früheren Zeit mit dem Thema:
Nehmen wir jetzt serielle oder parallele Abarbeitung? Jaja. Parallel ist schneller.
Wir haben heute nicht umsonst mehrere Kerne in einer CPU.
Ein Kern tut was und die anderen schauen zu wie der eine sich abrackert? Kommt gar nicht in die Tüte.

Zitat von Berichtigung

Irgendwann kriegen wir euch auch.

Klasse gesagt.

Kann man überhaupt mit kcron irgendwelche systemd -timer verwalten? Sind die nicht komplett anders geschrieben oder hab ich was missgelesen?