xscreensaver

Arminius

Active member
Themenstarter
Registriert
27 März 2010
Beiträge
1.590
Stand: April 2016

Im Moment erscheint in ersten Sekunden nach dem Bootvorgang eine Fehlermeldung für den xscreensaver:
... is VERY OLD please upgrade ...

entweder ihr kopiert aus dem Debian-BUG-Report diese Zeilen nach /home/.xscreensaver:

Code:
# XScreenSaver Preferences File
# Workaround stubborn "This version of xscreensaver is VERY OLD! Please
upgrade!" bug

timeout:    0:05:00
cycle:        0:10:00
lock:        True
lockTimeout:    0:06:00
passwdTimeout:    0:00:30
splash:        False
splashDuration:    0:00:00
fade:        False
unfade:        False

mode:           off

Quelle: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#380


oder löscht das Programm komplett und ersetzt es durch das Programm "light-locker".

Ich denke, der Streit zwischen dem Autoren von "xscreensaver" und den Maintainern der großen Distributionen, die
"xscreensaver" beinhalten, könnte länger dauern.

Infos:
http://www.heise.de/open/meldung/Sc...70.html?wt_mc=nl.heiseopen-summary.2016-04-15
 
Zuletzt bearbeitet:
Konklusion: xscreensaver bei Debian mag zwar abgehangen sein, aber ist vom Debian-Team durchaus gepflegt und keinesfalls "löchrig" wie der Autor behauptet. Der sich selbst als R-A*loch geoutet hat und irgendwie ein Verständnisproblem seiner eigenen Lizenz hat.

Hat er nicht.

Siehe auch den Kommentar im Code:
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

Eine sehr spaßige Diskussion, jwz hat natürlich recht mit dem was er schreibt.
 
Zuletzt bearbeitet:
Ich will keine unliebsamen Überraschungen mitten in der Lebenszeit der Distribution
Nenne mir bitte irgend jemanden, der diese will. Das ist doch Rabulistik in Reinform.

da habe ich - wenn ich etwa (wie hier) in einem Rechenzentrum arbeite - gar nicht die Zeit zu, der Distribution immer hinterherzulaufen.
Damit stehst Du ebenfalls nicht allein. Niemand hat die Zeit dazu. Und auch der Xscreensaver-Maintainer hat keine Lust dazu, Zeit mit mit Fragen zu Versionen aus längst vergangenen Tagen zu vergeuden, nur weil Debians Maintainer partout keine Updates einpflegen wollen. Der will von denen doch nur noch in Ruhe gelassen werden: "I would like Debian to stop shipping XScreenSaver."

Mal eine Frage am Rande: Wozu braucht man auf Servern im Rechenzentrum einen Bildschirmschoner? Oder überhaupt einen X-Server?

Die ganz Diskussion ist doch unredlich, genauso wie der Heise-Titel "Screensaver bei Debian: Software mit Verfallsdatum", weil er schlicht eine bewusste Täuschung und Dramatisierung darstellt. Bei Uralt-Versionen erscheint ein freundlicher Hinweis, eine gut gemeinte Warnung, ansonsten ändert sich weiter überhaupt nichts, schon gar nicht an der Funktionalität. Was soll's?
 
Hat er nicht.

Siehe auch den Kommentar im Code:
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

Eine sehr spaßige Diskussion, jwz hat natürlich recht mit dem was er schreibt.

Nein, hat er nicht: Das hier:

To the surprise of nobody, many of the people commenting on the Debian bug report take the attitude of, "Well if it's legal to do something, then it must also be right to do it", and want to distribute an altered version of my software against my explicit wishes.

ist ja wohl kompletter Unfug. Wenn er nicht *will* das jemand eine veränderte Version seiner Software verbreitet, dann muss er das bitte in seinen Lizenztext aufnehmen. Er kann nicht einerseits eine Lizenz herausgeben, die solche Änderungen erlaubt, und andererseits herummosern, wenn's jemand tut.

So funktioniert freie Software nun mal. Oder Lizenzen im allgemeinen. Die Lizenz ist die Willensäußerung des Autors, wie man mit seiner Software umzugehen hat. Wenn die seinem Willen widerspricht, so hat er die falsche Lizenz gewählt.
 
Und die Lizenz verbietet ihm seine Meinung zu äußern? Natürlich muss sich Debian nicht an seine Wünsche halten, das ist auch ihm klar.

Mal eine Frage am Rande: Wozu braucht man auf Servern im Rechenzentrum einen Bildschirmschoner? Oder überhaupt einen X-Server?

Hauptaspekt von xscreensaver ist die Möglichkeit den Bildschirm zu sperren.
 
Und auch der Xscreensaver-Maintainer hat keine Lust dazu, Zeit mit mit Fragen zu Versionen aus längst vergangenen Tagen zu vergeuden, nur weil Debians Maintainer partout keine Updates einpflegen wollen.
Dieses Problem lässt sich doch sehr einfach lösen, indem man die Mail der Debian Maintainer hinterlegt.

Mal eine Frage am Rande: Wozu braucht man auf Servern im Rechenzentrum einen Bildschirmschoner? Oder überhaupt einen X-Server?
Computerpools, Schulungsräume in diesem Fall.


Die ganz Diskussion ist doch unredlich,
..unredlich ist es, eine Software mit einer "Open Source" Lizenz auszustatten und sich nicht über die Konsequenzen im klaren zu sein, was das bedeutet. Ich *bin* kein Anhänger der Open Source Religion. Soll er doch eine Lizenz nehmen, die solche Änderungen untersagen. Dann weiß man als Maintainer auch genau, woran man ist.

Bei Uralt-Versionen erscheint ein freundlicher Hinweis, eine gut gemeinte Warnung, ansonsten ändert sich weiter überhaupt nichts, schon gar nicht an der Funktionalität. Was soll's?

Ich kann eine solche Warnung nicht gebrauchen. Ich kann sie nicht mal abstellen. Nein, ich werde hier nicht mal rasch was neu compilieren und einspielen, das ist kein Betriebskonzept.

- - - Beitrag zusammengeführt - - -

Und die Lizenz verbietet ihm seine Meinung zu äußern? Natürlich muss sich Debian nicht an seine Wünsche halten, das ist auch ihm klar.

Offenbar nicht. Hier schwingt er eine "moralische Keule" dass es unredlich sei, seinem Wunsch nicht zu entsprechen. Wenn das sein Wunsch ist, was hindert ihn daran, genau das in die Lizenz aufzunehmen. Will er jetzt Änderungen an seinem Source zulassen oder nicht? Und warum schreibt er das nicht in der Lizenz auf, wenn er's nicht mag? Das ist doch absurd, sich auf etwas zu berufen, was man nicht eingefordert hat.
 
Nochmal: Wenn der Source geändert wird, muss auch der Name geändert werden. Das sind zwei völlig unterschiedliche Bereiche und die genutzte Lizenz bezieht sich ausschließlich auf den Code. Soll Debian halt eine Fork unter anderem Namen machen, damit hat niemand ein Problem.

Dieses Problem lässt sich doch sehr einfach lösen, indem man die Mail der Debian Maintainer hinterlegt.
Funktioniert nur dann, wenn die Leute nicht mit einer Suchmaschine nach "xscreensaver" suchen. Die Debian-ML bzw. Bugtracker gab es ja vorher schon, nur wenden sich die Leute zu oft direkt an den Softwareentwickler (was bei der aktuellen Version ja auch Sinn macht).
 
Offenbar nicht. Hier schwingt er eine "moralische Keule" dass es unredlich sei, seinem Wunsch nicht zu entsprechen. Wenn das sein Wunsch ist, was hindert ihn daran, genau das in die Lizenz aufzunehmen. Will er jetzt Änderungen an seinem Source zulassen oder nicht? Und warum schreibt er das nicht in der Lizenz auf, wenn er's nicht mag? Das ist doch absurd, sich auf etwas zu berufen, was man nicht eingefordert hat.

Das ist seine Meinung. Die Lizenz ist eindeutig. Finde es absurd warum er aufgrund der Lizenz nicht gegen Debian schimpfen darf. Klar kann er Forderungen stellen und die Moralkeule schwingen.
Warum nicht?
 
Die Meldung hielt ich auch für einen Joke bei einem frisch aufgesetzten Debian 8 mit LXDE. Irgendwie ist es ja ein wenig Kindergarten um einen BiSchiScho;-)

Dann fliegt es eben runter, denn wenn ich ungewollt aufpoppende Fenster sehen will, kann ich Windows installieren.
 
wenn ich ungewollt aufpoppende Fenster sehen will, kann ich Windows installieren.
Poppt "ungewollt" ein Fenster auf? Nein, natürlich nicht. Genau diese Verdrehung der Tatsachen zeigt das Unredliche an der Diskussion. An der Funktionalität der Software ändert sich eben genau rein gar nichts.

Ein alter Mann wird als alter Mann bezeichnet, und der schlägt daraufhin beleidigt wild um sich, weil jemand es wagt, diesen Fakt laut beim Namen zu nennen. Das ist doch skurril.
 
Dann fliegt es eben runter, denn wenn ich ungewollt aufpoppende Fenster sehen will, kann ich Windows installieren.
Mach doch! Gib xscreenshaver dann aber bitte nicht auch noch die Schuld, wenn Du irgendwann dein Windows-ThinkPad aus dem Fenster wirfst ... ;)
 
Einfache Lösung: Wer eine veraltete Version nutzt, bekommt keinen Support. Wer seine Version bei einer Anfrage nicht nennt, bekommt ebenfalls keinen Support. Fühlen sich die Nutzer jetzt besser?

Aus Sicht eines Softwareentwicklers geht einem dieses Gepatche von Debian – sorry für die harte Ausdrucksweise – mächtig auf den Sack. Zum einen steigt der Wartungsaufwand, wenn man upstream selbst ältere Branches wartet, andererseits tut es weh, wenn man zusehen muss, wie an seiner Software von einem Außenstehenden herumgebastelt wird (Patching von Debian). Nicht nur, dass dabei Sicherheitslücken nur unzureichend geschlossen werden können, auch besteht ein Risiko, dass neue Bugs eingeführt werden. Damit wenden sich die Nutzer entweder wieder an den Entwickler ("Habe ich nichts mit zu tun," es kostet aber reichlich Aufwand) oder direkt an die Distribution (richtig, aber schafft ein schlechtes Bild von der Software: "Hat lauter Fehler." – "Ja, aber nicht in der originalen Version."). Und das Patchen funktioniert nur so lange, wie upstream keine zu großen Änderungen geschehen sind. Es kommt oft vor, dass Software grundlegend (zumindest in Teilen) geändert wird und schon hat der Distributions-Maintainer reichlich zu tun.
 
Ein alter Mann wird als alter Mann bezeichnet, und der schlägt daraufhin beleidigt wild um sich, weil jemand es wagt, diesen Fakt laut beim Namen zu nennen. Das ist doch skurril.

Sag ich doch - Kindergarten;-)

Mir ist das ehrlich gesagt 'egal', ob das nn eine veraltete Version ist oder nicht. Wenn Debian diese nicht aktualisiert oder über ein zusätzliches Repo in einer neueren Version bringt, habe ich ja kaum eine Option, diesen Zustand zu ändern. Solche Dinge wie selbst kompilieren oder so lasse ich da mal aussen vor. Ungewollt ist es aus meiner Sicht deshalb, weil ich das Ding bei jedem Login präsentiert bekäme, ohne es dauerhaft abstellen zu können, denn als 'Lösung' bleibt ja nur deinstallieren.

Es war aber wirklich eher scherzhaft gemeint. Ich musste schon schmunzeln, als ich bei Fefe den Kommentar las, statt eines aktuelleren Pakets die Meldung im vorhandenen weg zu patchen;-)

@linrunner

Gib xscreenshaver dann aber bitte nicht auch noch die Schuld, wenn Du irgendwann dein Windows-ThinkPad aus dem Fenster wirfst ...

Das dürfte mir seeeehr schwerfallen. Isch `abe gar keine Thinkpad mit Windows;-)
 
Einfache Lösung: Wer eine veraltete Version nutzt, bekommt keinen Support. Wer seine Version bei einer Anfrage nicht nennt, bekommt ebenfalls keinen Support. Fühlen sich die Nutzer jetzt besser?
Die Version bei Debian ist ja gar nicht veraltet, das ist ja der Punkt. Sie *basiert* auf einer alten Version, aber sicherheitsrelevante Probleme werden ja nachgepatcht. Insofern ist der Hinweis grob irreführend.

Aus Sicht eines Softwareentwicklers geht einem dieses Gepatche von Debian – sorry für die harte Ausdrucksweise – mächtig auf den Sack. Zum einen steigt der Wartungsaufwand, wenn man upstream selbst ältere Branches wartet, andererseits tut es weh, wenn man zusehen muss, wie an seiner Software von einem Außenstehenden herumgebastelt wird (Patching von Debian).
Das alte Problem von Anwender und Entwickler. Natürlich will der Entwickler nur die neueste Version gewartet haben. Natürlich will der (professionelle) Anwender eine stabile Version und keine Überraschungen. Aber um genau diesen Widerspruch zu überwinden, gibt's ja die Maintainer. Du musst ja nicht die Debian-Pakete maintainen. Das macht Debian. Und wenn Du der Meinung bist, dass Dich das Patchen stört, wähle eben eine Lizenz, die das ausschließt und verbietet. Dann nimmt's Debian nicht. Ist ja auch gut.


Nicht nur, dass dabei Sicherheitslücken nur unzureichend geschlossen werden können, auch besteht ein Risiko, dass neue Bugs eingeführt werden. Damit wenden sich die Nutzer entweder wieder an den Entwickler ("Habe ich nichts mit zu tun," es kostet aber reichlich Aufwand) oder direkt an die Distribution (richtig, aber schafft ein schlechtes Bild von der Software: "Hat lauter Fehler." – "Ja, aber nicht in der originalen Version.").
Debian patcht sehr konservativ. Natürlich können da auch Fehler entstehen, aber das ist unwahrscheinlicher, als wenn man Codeteile aus anderen Gründen ändert. Darüberhinaus betrifft Dich als Entwickler das ja nicht. Wenn Du einen Bugreport für eine alte Version bekommst - wo ist das Problem zu sagen, dass es nicht Dein Problem ist?

Wenn Dir ein Zacken aus der Krone fällt, weil jemand Deine Software patcht, dann hast Du bei Open Source was grundsätzlich nicht verstanden. Mache halt kein Open Source, ist auch eine vollkommen berechtigte Entwicklungsstrategie gegen die ich grundsätzlich nichts einzuwenden habe.
 
Die Version bei Debian ist ja gar nicht veraltet, das ist ja der Punkt. Sie *basiert* auf einer alten Version, aber sicherheitsrelevante Probleme werden ja nachgepatcht. Insofern ist der Hinweis grob irreführend.

Mit zwei Zeilen einfügen ist es aber oft nicht getan, wenn man sich die neueste Version ansieht. Wurde die Sicherheitslücke mit der neuesten Version entdeckt, weiß man noch nicht ob die in der alten Version auch so existiert. Was die ganze Situation absurd macht.

Das man dieses "Feature" erst jetzt bemerkt hat spricht auch nicht gerade dafür dass man sich intensiv damit auseinandergesetzt hat.
 
Punkt 1: Natürlich ist so ein einzelner Hinweis kein Beinbruch, aber man stelle sich einmal vor, jeder Software-Entwickler würde so etwas bei sich einbauen. Daher halte ich diese Maßnahme für definitiv den falschen Weg, dem Ursprungsproblem zu begegnen, und deswegen finde ich auch das Ausmaß der Diskussion gerechtfertigt. Bei mir laufen viele "veraltete" VMs mit bestimmten Buildumgebungen, warum sollte ich diese VMs auf aktuelle Versionen hochziehen? (Was meistens gar nicht geht, davon mal ganz abgesehen.) Es geht ja gerade darum, alte Versionen zur Verfügung zu haben. Internetzugang haben diese VMs nicht, wo ist also das Problem, wenn alte Versionen zum Einsatz kommen?

Punkt 2: Was ist das Ursprungsproblem? Er bekommt Bugreports zu alten Versionen. Ach was. Ich kann mir nicht vorstellen, daß es einen Software-Entwickler gibt, der dieses Problem nicht hat, egal ob Open Source oder Closed Source. Die bügelt man mit dem Hinweis auf die aktuelle Version ab bzw. verweist die Debian-Anwender auf den Debian-Bugtracker. Ob er den Debian-Bugtracker verfolgt oder nicht ist sein Bier. Er tut es, was ich löblich finde, verstehe aber nicht, warum er sich dann darüber auskotzt. Der Debian-Maintainer des Debian-Paketes sollte eigentlich die Bugreports auf dem Debian-Bugtracker behandeln und nur bei Bedarf den Upstream-Maintainer, also ihn, kontaktieren. Warum nutzt er diesen Filtermechanismus nicht?

Punkt 3: Linux-Distributionen leben davon, unterschiedliche Ansätze zu haben, und den Ansatz von Debian mag man für sich persönlich nicht praktikabel finden, dennoch sollte man ihn IMHO akzeptieren und respektieren, denn offensichtlich finden viele Leute diesen Ansatz praktikabel. Wer also das Problem bei Debian sucht, sucht IMHO an der falschen Stelle.

Mein persönliches Fazit: Das Projekt wächst gerade dem Entwickler über den Kopf. Das ist ganz normal, solche Phasen gibt es nun einmal. Der richtige Weg wäre es IMHO, sich eine Auszeit vom Debian-Bugtracker zu nehmen, und auch eingehende E-Mails haben keinen Anspruch darauf, zeitnah oder überhaupt beantwortet zu werden. Das Problem aber auf unbeteiligte Anwender abzuwälzen und anschließend Debian die Schuld in die Schuhe zu schieben, ist IMHO der falsche Weg. Natürlich kann er es trotzdem so machen, es ist sein Projekt, und er stellt es gebührenfrei zur Verfügung. Aber genauso, wie Debian damit leben muß, daß der Entwickler so vorgeht, muß der Entwickler damit leben, wie Debian vorgeht. (Und BTW: Wieso muß das Projekt umbenannt werden, wenn es gepatcht wird? Das lese ich aus der GPL nicht heraus, und Debian und RedHat und Suse und Canonical und ... haben Komponenten schon immer gepatcht, angefangen beim Linux-Kernel.)
 
(Und BTW: Wieso muß das Projekt umbenannt werden, wenn es gepatcht wird? Das lese ich aus der GPL nicht heraus, und Debian und RedHat und Suse und Canonical und ... haben Komponenten schon immer gepatcht, angefangen beim Linux-Kernel.)

xscreensaver ist nicht GPL.
 
xscreensaver ist nicht GPL.
Stimmt, Mist.

Aber MIT/X11 ist AFAIK dahingehend kompatibel zur GPL, daß man MIT/X11-Teile in ein GPL-Projekt integrieren darf. Also unterstelle ich einfach mal der MIT/X11-Lizenz, ohne sie im Detail gelesen zu haben, daß es auch dort kein Problem ist, Patches ohne Änderung des Projektnamens vorzunehmen. (Außerdem unterstelle ich den Lizenzbeamten des Monats, auch "Debian Projekt" genannt, daß sie es nicht tun würden, wenn sie es nicht dürften.)
 
Der Source ist doch völlig egal. Wenn der Autor sagt "Ihr dürft den Namen nicht verwenden", dann muss das Paket entfernt oder umbenannt werden. Der Name ist nicht von der Lizenz abgedeckt. Schau dir die Situation bei den großen Projekten an, beispielsweise Arch, Libreoffice, Firefox, Thunderbird …
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben