Linux Flame

btw: so toll ist das neue Windows ;)
Moc06EyTzVYZAooca.jpeg

hAF2C476C
 
So... mal wieder was aus meinem Linux-Alltag. Ausgangssituation: Laptop mit Debian 7 als Desktop. Alles läuft problemlos. Sogar das Powermanagement für den Thinkpad macht was es soll (nachdem bei der Einrichtung des Laptops mehrere Stunden damit verbracht wurden es zum Laufen zu bekommen). Ziel: Update auf Debian 8.

Also was macht der User? Logischerweise stellt er in seiner sources.list alles auf Jessie um und macht das übliche 'apt-get update && apt-get dist-upgrade'. Resultat: Die Installation bricht mittendrin ab, weil irgendwelche Abhängigkeiten nicht korrekt aufgelöst werden. Lösung: Die beanstandeten Pakete deinstallieren um sie nach dem Upgrade wieder zu installieren. Nachdem dieses Spielchen einige Male gemacht wurde, läuft das Upgrade dann irgendwann auch endlich vollständig durch. Reboot!

Nach dem Reboot geht nicht mehr viel. Zwar präsentiert sich der grafische Login-Manager, aber ein Login auf der gewohnten LXDE-Umgebung liefert nur einen leeren Desktop. Selbiges bei Gnome. KDE funktioniert allerdings, will nur keiner benutzen. ;)

Nach einigem Suchen stellt sich heraus, dass es wohl Probleme mit der bereits beim User vorhandenen Config gibt. Also mal alle Konfigurationen aus dem User-Ordner entfernt und erneut ein Login auf dem LXDE. Endlich funktioniert er wieder. Aber... alle Einstellungen weg und kein WLAN!

Ursache: Mit dem Entfernen der Configs aus dem User-Ordner wurden natürlich auch seine Network-Manager-Einstellungen entfernt. Also WLAN neu einrichten, nachdem der Desktop wieder so konfiguriert wurde, wie er vorher mal war.

Als das WLAN endlich geht, wird der Laptop zugeklappt. Resultat: Der Rechner geht nicht in den gewohnten Sleep-Zustand. Also Laptop wieder aufgeklappt, Powermanagement durchgecheckt. Das Update hat die Thinkpad-spezifischen Powermanagement-Sachen zwar aktualisiert, aber die Default-Config hat sich etwas geändert. Also Powermanagement neu konfiguriert. Ergebnis: Rechner geht jetzt beim Zuklappen zwar wieder in den Sleep (Suspend to RAM), macht aber beim Aufklappen einen Hibernate (Suspend to disk) anstatt einfach wieder anzugehen. Ursache: konnte bisher nicht ermittelt werden. Sicher ist nur: In der Config ist dieses Verhalten nicht so festgelegt.

Beim nächsten Reboot stellt sich dann heraus, dass auch das LXPanel nicht korrekt geladen wird. Es präsentiert sich beim Starten des LXDE als grauer Balken. Ein 'killall lxpanel && lxpanel &' in einem Terminal behebt das Problem. Ursache: Bisher noch unbekannt.

Auch das Battery-Applet im Panel wird nur sporadisch angezeigt. Prinzipiell ist es eine leere Fläche, wenn der Rechner mit angestecktem Netzteil startet. Kurz das Netzteil abgesteckt und wieder rangemacht und schon wird es auch wieder korrekt dargestellt.

Obwohl in der Konfiguration eingestellt ist, dass das Touchpad des Thinkpads prinzipiell deaktiviert sein soll, ist das nach einem Reboot nicht der Fall. Erst ein manuell ausgeführtes 'synclient TouchPadOff=1' deaktiviert das Touchpad. Ursache: Bisher noch unbekannt.

Ja... so sieht die Usability von Linux aus. Die ganzen anderen kleinen Problemchen, wie nicht gespeicherte Panel-Applets zähle ich besser gar nicht auf.

Jeder normale Anwender wäre an diesen Problemen ziemlich sicher verzweifelt. Selbst für mich ist die Fehlersuche sehr aufwendig und zeitfressend.
 
Naja, das perfekte Betriebssystem gibt es halt nicht. Wenn du ein System mit zentraler Paketverwaltung einsetzt, hast du die Wahl, ob du ständig mit kleineren Problemen rechnen musst (z.B. Debian testing) oder die Probleme auf später verschiebst (z.B. Debian stable). Die Alternative ist jetzt, dass jedes Programm seine Abhängigkeiten selber mitbringt, wobei das sicherheitstechnisch und von den Ressourcen her nicht die optimale Lösung ist.
 
mucki hat gesagt.:
Naja, das perfekte Betriebssystem gibt es halt nicht. Wenn du ein System mit zentraler Paketverwaltung einsetzt, hast du die Wahl, ob du ständig mit kleineren Problemen rechnen musst (z.B. Debian testing) oder die Probleme auf später verschiebst (z.B. Debian stable).
Zum Vergrößern anklicken....

Debian 8.0 ist das aktuelle Stable. Die Probleme haben also mit Testing-Status nichts zu tun. Diese Probleme werden einem als "stable" angedreht.

mucki hat gesagt.:
Die Alternative ist jetzt, dass jedes Programm seine Abhängigkeiten selber mitbringt, wobei das sicherheitstechnisch und von den Ressourcen her nicht die optimale Lösung ist.
Zum Vergrößern anklicken....

Andere Systeme bekommen es aber auch auf die Reihe die Abhängigkeiten bei Bedarf nachzuladen. Spricht ja nichts dagegen, dass ein Installer auch Abhängigkeiten auflöst und bei Bedarf Libraries etc. nachlädt.

Bei einem Systemupdate erwarte ich auf jeden Fall, dass veraltete Konfigurationen auf den Stand gebracht werden, der für die neue System-Version notwendig ist. Aber bei Linux ist ja scheinbar selbst eine Meldung der Form "Konfiguration XY ist veraltet und muss neu gemacht werden." zu viel. Es werden prinzipiell nur die globalen Konfigurationen geprüft, aber nie die der User. Dabei wäre es ein Kinderspiel aus der passwd-Datei alle User-Homes zu holen und in diesen zu schauen ob dort irgendwelche Configs rumliegen, die ggf. aktualisiert werden müssen. Genau für solche Aufgaben unterstützen alle Paketformate Postinstall-Skripte. Aber Linuxer bekommen es offensichtlich nicht mal auf die Reihe ihre eigene Paketverwaltung korrekt einzusetzen.
 
Debian 7 stable hat bei Updates keinen Ärger gemacht und bei Debian 8 stable hatte ich auch noch keine Probleme. Dass diese mit dem Wechsel zwischen den Hauptversionen kommen ist ja auch keine Neuigkeit.
Ganz so einfach ist es mit den Abhängigkeiten dann auch nicht. Du kannst z.B. nicht einfach die Libs von Qt 4 durch die von Qt 5 ersetzen, wenn manche Programme noch gegen die alte Version gelinkt sind. Dies ist nur möglich, wenn sich lediglich der Patchlevel geändert hat (=Bugs behoben wurden).
 
Deswegen ist es üblich die SO-Dateien so zu benennen, dass auch die Version im Dateinamen vorkommt. Man müsste sich nur mal an diese Regel halten. Es ist also sehr wohl mit den Abhängigkeiten so einfach.

Um bei deinem QT-Beispiel zu bleiben. Würde jeder Entwickler nicht gegen die libqtgui.so sondern gegen die libqtgui.so.4 bzw. libqtgui.so.5 linken, könnte man QT4 und QT5 problemlos parallel einsetzen. Ein Ersetzen der Libs müsste nicht stattfinden. OSS-Entwickler sind aber offenbar nicht in der Lage ihre Linker richtig anzuwenden und lassen daher den User glauben, man könne verschiedene Versionen einer Lib nicht parallel betreiben. Das ist, gelinde gesagt, Bullshit. Es muss nur korrekt gelinkt werden um Abhängigkeitsprobleme zu vermeiden.
 
Natürlich kann man verschiedene Versionen der Library gleichzeitig installieren. Allerdings sind bei Qt nicht nur die Major, sondern auch die Minorversionen binär inkompatibel zueinander. Alleine mit Qt 4 und Qt 5 wäre es also nicht getan. Aus diesem Grund macht es schon Sinn, dass man sich für eine Version entscheidet.
 
Natürlich kann man für jeden Murks einen Sinn herbeireden anstatt die fehlende Abwärtskompatibilität der Libs einfach mal beim Namen zu nennen. Linuxer halten doch sonst immer so gern veraltete Technik in Ehren. Warum wird das bei veralteten Library-Calls nicht getan? ;)

Aber ernsthaft: Man muss schlechter Programmierung nicht noch einen Sinn andichten. Wir schreiben heutzutage Libraries ja nicht mehr in Assembler sondern in Sprachen, die auch Dinge wie das Überladen von Funktionen bereitstellen. Da kann man problemlos zum Zwecke der Abwärtskompatibilität auch obsolete Calls in Bibliotheken für eine Weile drin lassen. Bei Projekten wie PHP geht sowas auch. Was spricht also dagegen es zum Teil der Guidelines für Libraries zu machen? Und nebenher sollte sich die OSS-Gemeinschaft auch gleich überlegen, ob man mit dem Label "Freie Software" nicht endlich auch mal ein paar Qualitätsansprüche verbinden sollte.
 
Die fehlende binäre Abwärtskompatibilität liegt daran, dass es sich um eine C++ Bibliothek handelt. Die API ansich ist abwärtskompatibel, jedoch muss das Programm dann neu kompiliert werden.
 
Linux und Sicherheit... Sowohl Network-Manager als auch WiCD speichern die WLAN-Passwörter unverschlüsselt auf der Platte. Welcome to the 90s!
 
Linux

Hallo

@bitmuncher
Das war abr schon zu Zeiten von pppoe so, das stand das PW des accounts im Klartext. MUßt su mal vion der Seite sehen, wer mal sein PW vergißt, muß nicht weit suchen:P


@chromatin, naja besser als win10, das ja von einem Siherheitsforscher aus Holland, als Bot bezeichnet wurde allemal:D

mfg
schwedenmann
 
Das war abr schon zu Zeiten von pppoe so, das stand das PW des accounts im Klartext. MUßt su mal vion der Seite sehen, wer mal sein PW vergißt, muß nicht weit suchen
Zum Vergrößern anklicken....

Das liegt aber ausnahmsweise mal an den Authentifizierungsmethoden des PPP :)
 
omg, ich hab alle meine wlan-netzwerk-passes eh im plaintex eh in ner textdatei:

~/wlan

damit ich schnell terminal auf und

cat wlan

machen kann um schnell den richtigen key zu finden wenn ich ihn brauch
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben