hier sieht man mal ein Beispiel für die Crux bei Linux: Entwickler-Streitigkeiten und -marotten lassen den Endanwender auf der Strecke. Es wäre außerordentlich bedauerlich, wenn ich kein Calibre mehr nutzen könnte.
Die Probleme gibt's nur bei Debian? Steht auch so im Artikel?
Nein, die Probleme gibt es (früher oder später) auch in anderen Distributionen, denn eigentlich will keiner mehr Python 2 haben.
Python 3 erschien Ende 2008, d.h. vor fast 11(!) Jahren. Die Entwickler hatten nun lange genug Zeit umzusteigen, irgendwann muss auch mal gut sein.
Übrigens gibt es die Situation unter Windows genauso. Programme, welche unter (z.B.) Windows XP liefen kann man häufig unter Windows 7 oder 10 auch nicht mehr verwenden. Tatsächlich funktionieren derartige Programme unter Wine häufig besser als nativ unter den neueren Windows Versionen. ^^
Ich glaube kaum das andere Distributionen von Qt 5.12 auf Qt 5.11 zurückgehen.
Der Gipfel des Paradoxen ist eigentlich dadurch erreicht, dass Qt 5.12 eine LTS-Version ist und 5.11 nicht. Debian muss also Qt selbst pflegen. Würden sie die Version 5.12 benutzen, würde Qt die Pflege fast zu 100% übernehmen.
Das Problem liegt bei Debian und seinen sogar in unstable veralteten Paketen sowie dem ewiggestrigem Calibre-Entwickler. Wann immer ich nicht den vollen Funktionsumfang brauche, mache ich möglichst einen Bogen um Calibre mit seiner schrecklichen Benutzeroberfläche und nutze Alternativen wie KOreader, Foliate, Polar Bookshelf.
Die genannten Alternativen zu Calibre sind nicht wirklich ein Ersatz. Ginge es nur um einen E-Book-Reader, dann gäbe es durchaus andere Möglichkeiten. Aber Calibre verwaltet die E-Books - und das für meine Zwecke richtig gut. Einen Ersatz habe ich bisher nicht gefunden.
Wieso Linux? Googel man nach DLL Hölle und ermittle mal wievielr Doppelte DLL Files Du in wievielen Versionen in unterschiedlichen Pfaden im System hast ... Bzw wieviele JAVA Runtimes gerade installiert sind ...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Okt 2019 um 15:21.
Sinnvoller wäre es, wenn er nicht nur nachsehen würde, wie viele verschiedene Versionen an DLLs einer bestimmten Lib er unter Windows installiert hat, sondern welche davon auch noch schwere Sicherheitslücken enthalten und noch nicht gefixt wurden.
Auch wenn hier einige diesen unerfreulichen Linuxzustand jetzt hinunterreden wollen, sehe ich es auch so. «Die Krux von Linux.»
Otto Normalverbraucher interessiert es doch einen Dreck ob nun das Kreti oder das Pleti Betriebssystem nicht funktioniert. Wenn solche Pannen passieren kommt sehr schnell der ruf nach Apfel oder Migrosaft. Ob jetzt etwas in Ubuntu nicht korrekt funktioniert aber in Debian, etwas anderes tut es, in Suse oder Arch ebenso, oder gar wenn sie dann noch hören müssen dass die Pythonschlange 2 nicht kongruent mit der Pythonschlange 3 ist und man deswegen entweder das Betriebsystem wechseln muss oder auf das Programm auf das man stark baut, verzichten muss. Ich selber hadere nach wie vor mit KDE weil sie rücksichtslos eines der besten Feature klammheimlich gelöscht haben: Unterschiedliche Hintergründe und Miniprogramme. Und uns etwas viel komplizierteres vor die Bildschirme geschmissen haben.
Von was ist das am Di, 15. Oktober 2019 um 21:43 #
Ich empfinde das als ziemlich konsequent und eigentlich ganz gut. Alte Software wird sowieso nicht mehr gewartet und reist schlimmstenfalls noch Sicherheitslöcher ins System. Ab jetzt muss man nur noch 64Bit-Software pflegen, was eben gewissen Entwicklungsaufwand reduziert.
Warum sollte es erstrebenswert sein, dass Linux für "Otto Normalverbraucher" geeignet ist?
Dass Computer eigentlich nicht in Laienhand gehören, sieht man doch täglich an den News über (Windows- oder Android-) Viren, Würmer und Verschlüsselungs-Trojaner.
Da nehme ich lieber in Kauf, hin und wieder ein bisschen basteln zu müssen.
Von Kein Beinbruch am Di, 15. Oktober 2019 um 16:26 #
Das ist kein Makel von Linux oder Debian. Auch wenn die Situation derzeit verfahren erscheint, gibt es frpüher oder später eine Lösung. Kovid Goval, der Entwickler von Calibre ist erst einmal für seine Mühe zu zu danken. Schließlich hat er viel Arbeit da rein gesteckt. Wenn er jetzt auf dem Schlauch steht, kann man ihn halt auch nicht zu phyton3 zwingen. User können aber auf andere Anwendungen ausweichen und Calibre kann, falls andere Entwickler in die Breche springen, auch notfalls geforkt werden. Das ist der Vorteil von freier Software. Auch wenn das Ganze erst mal bedauerlich ist, aber einen Anlass für allgemeine Linux Kritik sehe ich hier nicht. Und wer nicht gepflegte Bibliotheken auf seinem Rechner mag, kann ja immer noch ein altes flatpak oder snap einspielen. Böse Zungen behaupten, dass wäre genau dafür entwickelt worden.
Und wer nicht gepflegte Bibliotheken auf seinem Rechner mag, kann ja immer noch ein altes flatpak oder snap einspielen. Böse Zungen behaupten, dass wäre genau dafür entwickelt worden.
In Debian gibt es zwar ein Paket mit Versionsnummer 4 (4.0.0+really3.48.dfsg-1), darin steckt aber nicht die neue Version, sondern Calibre 3.48
Was soll das den? Wen 3.48 drin ist, dann hat das Paket auch entsprechend numeriert zu werden, und zwar mit 3.48 und nicht mit 4.0. IMHO die spinnen gewaltig bei Debian!
Nein, die spinnen nicht und das ist auch nicht das einzige Paket mit solchen Versionsnummern. das gab es zB vor ein paar Jahren bei gnutls schon einmal. Wenn debian einmal Version 4.0.0 in dem Repo hatte, dann aber ein Rollback auf 3.48 machen muss, ist dies die effizienteste Variante. Eine andere Variante ist, die Epoche hochzuzählen. Also ein (1: oder 2:) vorne an die Version anzustellen. Das wird aber eher ungern genutzt. Wenn debian einfach nach Version 4.0.0 die Version 3.48+support+securityFixes veröffentlichen würde, würden alle, die bereits 4.0.0 installiert haben kein Update bekommen. Schließlich ist die Versionsnummer kleiner.
Ich benutze Calibre 4.1 unter Arch Linux. Bei Rolling sehe ich fast nur Vorteile.
Python 2 ist bei Arch weiterhin verfügbar.
Moin,
hier sieht man mal ein Beispiel für die Crux bei Linux: Entwickler-Streitigkeiten und -marotten lassen den Endanwender auf der Strecke. Es wäre außerordentlich bedauerlich, wenn ich kein Calibre mehr nutzen könnte.
So wird das nicht mit Linux auf dem Desktop.
Wieso "bei Linux"?
Die Probleme gibt's nur bei Debian? Steht auch so im Artikel?
Python 3 erschien Ende 2008, d.h. vor fast 11(!) Jahren.
Die Entwickler hatten nun lange genug Zeit umzusteigen, irgendwann muss auch mal gut sein.
Übrigens gibt es die Situation unter Windows genauso.
Programme, welche unter (z.B.) Windows XP liefen kann man häufig unter Windows 7 oder 10 auch nicht mehr verwenden.
Tatsächlich funktionieren derartige Programme unter Wine häufig besser als nativ unter den neueren Windows Versionen. ^^
Im Artikel steht u.a.:
Ich glaube kaum das andere Distributionen von Qt 5.12 auf Qt 5.11 zurückgehen.
Das hat rein gar nix mit Linux zu tun. Python 2 hat sein Lebensende erreicht.
Red Hat unterstützt Python2 noch bis ~2028.
https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/
"It won’t be in RHEL 8, but there will come a day when support for Python 2 will end."
Das Problem liegt bei Debian und seinen sogar in unstable veralteten Paketen sowie dem ewiggestrigem Calibre-Entwickler.
Wann immer ich nicht den vollen Funktionsumfang brauche, mache ich möglichst einen Bogen um Calibre mit seiner schrecklichen Benutzeroberfläche und nutze Alternativen wie KOreader, Foliate, Polar Bookshelf.
Ja, die Benutzeroberfläche ist wirklich grauenvoll.
Ein gutes Beispiel dafür wie man mit Qt eine Oberfläche [b]nicht[/b] erstellen sollte.
Die von dir genannten Alternativen schau ich mir mal an, kannte ich bis dato noch nicht.
Die genannten Alternativen zu Calibre sind nicht wirklich ein Ersatz. Ginge es nur um einen E-Book-Reader, dann gäbe es durchaus andere Möglichkeiten. Aber Calibre verwaltet die E-Books - und das für meine Zwecke richtig gut. Einen Ersatz habe ich bisher nicht gefunden.
Nur der Vollständigkeit halber. Wird Dir auch nicht reichen, aber mir reicht da https://babluboy.github.io/bookworm/.
Wieso Linux?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Okt 2019 um 15:21.Googel man nach DLL Hölle und ermittle mal wievielr Doppelte DLL Files Du in wievielen Versionen in unterschiedlichen Pfaden im System hast ...
Bzw wieviele JAVA Runtimes gerade installiert sind ...
Sinnvoller wäre es, wenn er nicht nur nachsehen würde, wie viele verschiedene Versionen an DLLs einer bestimmten Lib er unter Windows installiert hat, sondern welche davon auch noch schwere Sicherheitslücken enthalten und noch nicht gefixt wurden.
Auch wenn hier einige diesen unerfreulichen Linuxzustand jetzt hinunterreden wollen, sehe ich es auch so. «Die Krux von Linux.»
Otto Normalverbraucher interessiert es doch einen Dreck ob nun das Kreti oder das Pleti Betriebssystem nicht funktioniert. Wenn solche Pannen passieren kommt sehr schnell der ruf nach Apfel oder Migrosaft. Ob jetzt etwas in Ubuntu nicht korrekt funktioniert aber in Debian, etwas anderes tut es, in Suse oder Arch ebenso, oder gar wenn sie dann noch hören müssen dass die Pythonschlange 2 nicht kongruent mit der Pythonschlange 3 ist und man deswegen entweder das Betriebsystem wechseln muss oder auf das Programm auf das man stark baut, verzichten muss.
Ich selber hadere nach wie vor mit KDE weil sie rücksichtslos eines der besten Feature klammheimlich gelöscht haben: Unterschiedliche Hintergründe und Miniprogramme. Und uns etwas viel komplizierteres vor die Bildschirme geschmissen haben.
Volle Zustimmung!
reden wir von dem Äppld as ohne Not alle 32bit Apps funktionsunfähig macht? Sehr witzig...
Ich empfinde das als ziemlich konsequent und eigentlich ganz gut. Alte Software wird sowieso nicht mehr gewartet und reist schlimmstenfalls noch Sicherheitslöcher ins System. Ab jetzt muss man nur noch 64Bit-Software pflegen, was eben gewissen Entwicklungsaufwand reduziert.
Warum sollte es erstrebenswert sein, dass Linux für "Otto Normalverbraucher" geeignet ist?
Dass Computer eigentlich nicht in Laienhand gehören, sieht man doch täglich an den News über (Windows- oder Android-) Viren, Würmer und Verschlüsselungs-Trojaner.
Da nehme ich lieber in Kauf, hin und wieder ein bisschen basteln zu müssen.
Goval zimmert einfach eine eigene Distro um sein Meisterwerk...
Das ist kein Makel von Linux oder Debian.
Auch wenn die Situation derzeit verfahren erscheint, gibt es frpüher oder später eine Lösung.
Kovid Goval, der Entwickler von Calibre ist erst einmal für seine Mühe zu zu danken. Schließlich hat er viel Arbeit da rein gesteckt. Wenn er jetzt auf dem Schlauch steht, kann man ihn halt auch nicht zu phyton3 zwingen. User können aber auf andere Anwendungen ausweichen und Calibre kann, falls andere Entwickler in die Breche springen, auch notfalls geforkt werden. Das ist der Vorteil von freier Software.
Auch wenn das Ganze erst mal bedauerlich ist, aber einen Anlass für allgemeine Linux Kritik sehe ich hier nicht.
Und wer nicht gepflegte Bibliotheken auf seinem Rechner mag, kann ja immer noch ein altes flatpak oder snap einspielen.
Böse Zungen behaupten, dass wäre genau dafür entwickelt worden.
Kovid bietet offensichtlich ein Binary mit allen Abhängigkeiten an:
Linux Apps on Flathub: Calibre
Anwendungen können dann gerne als SNAP Pakete u.a. eingebunden werden. Sollte kein Problem sein.
Was soll das den? Wen 3.48 drin ist, dann hat das Paket auch entsprechend numeriert zu werden, und zwar mit 3.48 und nicht mit 4.0. IMHO die spinnen gewaltig bei Debian!
Nein, die spinnen nicht und das ist auch nicht das einzige Paket mit solchen Versionsnummern. das gab es zB vor ein paar Jahren bei gnutls schon einmal.
Wenn debian einmal Version 4.0.0 in dem Repo hatte, dann aber ein Rollback auf 3.48 machen muss, ist dies die effizienteste Variante. Eine andere Variante ist, die Epoche hochzuzählen. Also ein (1: oder 2:) vorne an die Version anzustellen. Das wird aber eher ungern genutzt.
Wenn debian einfach nach Version 4.0.0 die Version 3.48+support+securityFixes veröffentlichen würde, würden alle, die bereits 4.0.0 installiert haben kein Update bekommen. Schließlich ist die Versionsnummer kleiner.