Linux am Dienstag – Programm für den 7.11.2023

Linux am Dienstag macht weiter bei LPI 1,was das LPI halt so für sinnvoll betrachtet 😉

Linux am Dienstag – Programm für den 7.11.2023

u.a. im Programm am 7.11.2023, ab 19 Uhr:

  • Sicherheit – und noch eine VMWare Lücke
  • Vortrag – Grundlagen Linux nach LPI 1 – Teil 2 (Marius)
  • Sicherheit – Grüne stoppen Klage gegen Vorratsdatenspeicherung
  • Sicherheit – alte SSHs geben Key preis
  • Datenschutz – Ausmaß der Userüberwachung bei Microsoft bekannt gegeben

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Lutris 0.5.14: Kein Spiel startet mehr

Da denkt man sich: „Hey ,es ist Sonntagmorgen, laß und ein paar Rote abschießen“ und da startet EVE einfach mal nicht mehr. Schuld ist ein Fehler von Lutris, der sich jetzt rächt.

Lutris 0.5.14: Kein Spiel startet mehr

Heute hat es Lutris 0.5.14 ins Stable geschafft und wurde prompt aktualisiert. Was für ein mieser Start ins Gamerleben an diesem Sonntag 😀 Keins der Spiele hat mehr funktioniert und das nur, weil eine alte Versionen meinte: „och nehmen wir doch den ~/ Shortcut, statt den absoluten Pfad, wie bei allen anderen Pfadangaben“ 🙂

Kurz um, der Fehler ist leicht zu fixen:

cd ./.lutris/games/

dort findet Ihr für jedes Spiel eine Datei mit Endung .yml :

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: ~/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Das <XXXXXXXX> steht für den Benutzernamen von Euch, bei Prefix steht nun nur „~/“ statt „/home/<XXXXXXXX>/“ . Das ändert Ihr mit einem Texteditor Eurer Wahl und schon starten die Spiele wieder.

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: /home/<XXXXXXXX>/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Ihr müßt nur aufpassen, daß ihr Euren Homepfad irgendwann nicht mal ändert, weil sonst all die Config nicht mehr stimmen 😉

 

Verspätungen bei Fedora Releases – Ein Kommentar

Na alle gut Durch die Zeitumstellung gekommen? 🙂  In den letzten Tagen hatten wir Nachrichten von Verzögerungen bei Fedora 39, die mal einer kleinen Erläuterung bedürfen.

Verspätungen bei Fedora Releases – Ein Kommentar

Ich mache das jetzt ja schon mehr als ein Jahrzehnte mit und deswegen schockt mich so eine Verzögerung überhaupt nicht. Das ist meiner Meinung nach nicht mal eine Erwähnung im Blog wert. Beim letzten Linux am Dienstag hatten wir das Thema auch und es ist lächerlich daraus irgendwas abzuleiten.

Letztes Jahr z.b. verzögerte sich Fedora 37 auch vom Oktober in den November und es war kein Weltuntergang. Wieso das in einigen Portalen so klingt, weiß ich nicht.

Wie läuft das normalerweise ab?

Das Steuerungskomitee legt einen Zeitplan der u.a. vorsieht, wann die Betaphase anfängt und wann das normalerweise 6 monatige Intervallrelease live gehen soll. Bis zum Betafreeze können alle Updates und Neuerungen eingebracht werden, danach nur noch Bugfixe und wenn alle Bugs behoben sind, dann darf das neue Release in den Stablebereich und alle Newsportale laufen heiß mit Meldungen wie „Fedora 39 finally ready“ oder „Fedora 39 bringt Gnome 50.3.4.7.haste.nicht.gesehen“.

Dazu gibt diverse Meetings im IRC bei der die Projektleitung über den Fortschritt informiert wird. Bestimme Fehler sind tolerabel, z.b. wenn eine Lokalisierung noch nicht 100% ist, aber die nur jeder hundertste sehen würde usw. andere Fehler sind es nicht, weil grundlegende Funktionen nicht laufen. Jetzt testen das nicht nur die Maintainer, sondern auch normale Fans die helfen wollen. Dabei kann es passieren, daß Bugs erst entdeckt werden, wenn die Betaphase schon angefangen hat, die Zeit bis zum Releasedate aber schon knapp wird. So ist es auch diesmal passiert…gleich zweimal.

Alles halb so wild

Das ist aber kein Beinbruch, weil die Releasedaten sind exakt daran gebunden, daß keine Fehler auftreten, sind also schon immer fexibel. Es gibt im Projekt auch keinen Druck, weil die Maintainer das kaum beeinflussen können. Es kommt schwer drauf an, was nicht geht. Ist Software komplett kaputt, z.b. Gnome , kann man nur warten, bis der Fix da ist. Geht was bei der „Infrastruktur“ nicht, und da zählt das Installationsmedium dazu, dann können die zuständigen Spezialisten direkt was machen. Aber auch hier gibts keinen Druck, woher auch?

Sollte es zwei Monate dauern bis Fedora 39 raus kommt, dann ist das halt so. Ich kann mich daran entsinnen, daß schon mal ein ganzer Monat drangehängt werden mußte

Für wen haben die Zeitpunkte überhaupt einen Wert?

Es gibt nur zwei Dinge die von den Zeitpunkten bestimmt werden:

Beim Betafreeze steht fest, welche Software ins Image kommt und in welcher min. Version. d.b. danach kann keine neue Software und keine grundlegende Änderung z.b. am Distrilayout im Filesystem mehr gemacht werden.

Beim Final Go für die neue Release fängt die Upgrade Uhr an zu ticken, weil das „alte Release“, in diesem Fall Fedora 37, nur noch 4 Wochen mit Updates versorgt wird. D.b. hier sind die Admins betroffen, die dann in Firmen für die Upgrades sorgen müssen. Es wir aber natürlich niemand daran gehindert schon eher von 37 auf 38 zu Updaten 😉

Für Euch als Anwender ist das Releasedate völlig irrelevant. Aus diesem Grund verstehe ich die Aufregung auf den Newsportalen auch nicht, es kommt, wenn es kommt und damit hat es sich. Vermutlich muß man aber irgendwas „neues“ „berichten“ wenn man ein Newsportal ist.  Also Leute entspannt Euch, es gibt erst was zu sehen, wenn es was zu sehen gibt 😉