Hallo! Habe lange Zeit Linux Mint benutzt und war eigentlich immer zufrieden bis sehr zufrieden damit. Das einzige, was mir nicht ganz gefiel, war der Look. Deshalb hab ich immer wieder mal auf Ubuntu gewechselt, festgestellt, dass zu viele Bugs drin sind und wieder zurück gewechselt. Ubuntu 20.04 hat mich wieder mal verführt und optisch gut bewährt, nur funktional gibt es wieder Probleme. (Ton weg, Kabelnetzwerk weg -.-) Meine Frage ist: habt ihr positive Erfahrungen mit anderen Distros mit GNOME-Oberfläche? Oder sind die Bugs eher genau in diesem (Mint hat ja auch eine Ubuntu-Basis, trotzdem läuft es besser...) Danke für alle Impressionen im Voraus!
Hallo, nehme doch einfach das Original https://www.debian.org/ Da kannst du natürlich Gnome als Desktop wählen. P.S. Die stable Version heisst so, weil der Entwicklungsstand stabil ist, d.h. sich kaum noch ändert. Bei unstable werden die Pakete oft auf die neueste Version aktualisiert, d.h. die Versionsnummern sind nicht stabil.
Muss es auf Debian, dh *.deb Paketen basieren, oder darf es auch Red Hat auf *.rpm Paketen basierend sein?
Wenn's dir hauptsächlich um den Look geht, vielleicht erst mal ein paar Versionen in einer Virtuellen Box ausprobieren?! Ist die Gnome Oberfläche wirklich schöner als Cinemon oder Mate - und funktionaler? Frage ist ernst gemeint. G.
Nimm halt den Cinnamon-Desktop, ist doch von Gnome geforkt. Das ganze auf Mint, wenn's LTS sein soll, oder auf Manjaro (als Community-Edition mit Cinnamon), wenn Du RR willst.
Dieter D. schrieb: > Muss es auf Debian, dh *.deb Paketen basieren, oder darf es auch Red Hat > auf *.rpm Paketen basierend sein? Bin prinzipiell für alles offen, solang es sich lohnt... (Sprich, wenn es wirklich stabiler läuft, als Ubuntu) An Debian habe ich auch schon gedacht. Soll ja sehr stabil sein und ich bräuchte mich kaum umgewöhnen, da vieles gleich läuft. (Auch wenn ich auf die Ubuntu-PPAs verzichten müsste, wobei es ja mit Flatpak und Snap nicht all zu schwer sein dürfte...) Manjaro wäre natürlich cool, da man immer aktuelle Software hat, aber eine Rolling Release-Distro assoziiert man wohl eher nicht mit Stabilität. Mein Rechner ist übrigens erst ein Jahr alt, ein Lenovo ThinkCentre m920t mit i7-8700. Habe 2x 4k Monitore. Deshalb mach ich mir auch etwas Sorgen, ob die stabilen Distros da zufriedenstellend laufen werden. Die 200%-Skalierung z.B. ist in GNOME meines Wissens noch gar nicht so lang dabei... Von Treibern spreche ich noch gar nicht...
PC schrieb: > Manjaro wäre natürlich cool, da man immer aktuelle Software hat, aber > eine Rolling Release-Distro assoziiert man wohl eher nicht mit > Stabilität. Meine Erfahrung ist da anders. Bei Debian wird die "Stabilität" bei vielen Paketen dadurch erreicht, dass einfach irgendeine zwei Jahre alte Version eingefroren wird. Ob die dann vernünftig funktioniert oder nicht, ist im Zweifel zweitrangig. Klar gibt es keine neuen, unerwarteten Bugs in dieser Software, dafür aber die alle, die seit zwei Jahren bekannt und gefixt sind. Bei Arch ist ab und zu mal was kaputt. Aber kurz. Nach 3 oder 5 Tagen wird das dann repariert, weil es wird ja ständig aktualisiert. Ob Manjaro das sinnvoll weg-buffert oder einfach (wie Debian) im Wesentlichen random irgendwelche Zustände für einige Zeit einfriert, weiß ich nicht, ich hab das noch nicht so lange benutzt.
Sven B. schrieb: > PC schrieb: >> Manjaro wäre natürlich cool, da man immer aktuelle Software hat, aber >> eine Rolling Release-Distro assoziiert man wohl eher nicht mit >> Stabilität. > > Meine Erfahrung ist da anders. Bei Debian wird die "Stabilität" bei > vielen Paketen dadurch erreicht, dass einfach irgendeine zwei Jahre alte > Version eingefroren wird. Ob die dann vernünftig funktioniert oder > nicht, ist im Zweifel zweitrangig. Klar gibt es keine neuen, > unerwarteten Bugs in dieser Software, dafür aber die alle, die seit zwei > Jahren bekannt und gefixt sind. > > Bei Arch ist ab und zu mal was kaputt. Aber kurz. Nach 3 oder 5 Tagen > wird das dann repariert, weil es wird ja ständig aktualisiert. > > Ob Manjaro das sinnvoll weg-buffert oder einfach (wie Debian) im > Wesentlichen random irgendwelche Zustände für einige Zeit einfriert, > weiß ich nicht, ich hab das noch nicht so lange benutzt. Klingt interessant! In diesem Fall würde ich es gerne nutzen. V.a. passt der neue Kernel mit all den aktuellen Treibern auch besser zu meinem PC. Vielleicht können andere noch etwas zur Stabilität von Manjaro sagen?
PC schrieb: > Vielleicht können andere noch etwas zur Stabilität von Manjaro sagen? Ist auf jeden Fall besser als bei Arch, weil nicht ganz so bleeding edge.
Schon wieder einer, der nicht begriffen hat, was Linux ist und wie es funktioniert. Das, was hier permanent als Ubuntu, Mint, Debian, Fedora bezeichnet und empfohlen wird ist nichts anderes als ein einfacher Pkw mit unterschiedlicher Ausstattung, der nur einen Produktnamen (Kompilation) trägt. Du darfst also das Auto (Distribution) in der Lieblingsfarbe (Displaymanager) lackieren, eine Anhängerkupplung (firmware, kernelmodule) anbauen und es nennen wie du möchtest (mein Jeep), oder eben zusammengestellt (Ubuntu, Mint, Debian) fertig beziehen. PC schrieb: > festgestellt, dass zu viele Bugs drin sind So, hast du also festgestellt? PC schrieb: > Oder sind die Bugs eher genau in diesem Oder doch nicht... > (Mint hat ja auch eine > Ubuntu-Basis, trotzdem läuft es besser...) Linux ist nix für dich (Umdenken). Bleib lieber bei Windows. Das wird dir weder GNOME, noch eine andere hier empfohlene Distro ändern/lösen können.
PC schrieb: > V.a. passt der neue Kernel mit > all den aktuellen Treibern auch besser zu meinem PC. Jo, so sieht's nämlich in der Praxis dann aus mit der "Stabilität" ;)
Mister A. schrieb: > Du darfst also das Auto (Distribution) in der Lieblingsfarbe > (Displaymanager) lackieren, eine Anhängerkupplung (firmware, > kernelmodule) anbauen und es nennen wie du möchtest (mein Jeep) Schön kluggeschissen. Macht aber keiner, der MIT dem Rechner statt AN dem Rechner (als Selbstzweck) was machen will. > eben zusammengestellt (Ubuntu, Mint, Debian) fertig beziehen. No shit. Die machen dann diese Arbeit. Daß unterschiedliche Distros je nach System unterschiedlich gut laufen können, ist durchaus nicht ungewöhnlich. Ebenso, daß Upstream-Sourcen mal modifiziert werden, oder Bugfixes zurückportiert, oder eben auch nicht. > Linux ist nix für dich (Umdenken). Alter, der OP nutzt schon lange Linux, merk mal was.
PC schrieb: > In diesem Fall würde ich es gerne nutzen. V.a. passt der neue Kernel mit > all den aktuellen Treibern auch besser zu meinem PC. Ich kriege hier auch in Mint 20 neben dem 5.4er LTS-Kernel auch einen 5.8er-Kernel angeboten, also daran scheitert's nicht.
Ich habe lange Debian, Ubuntu und Mint genutzt (in der Reihenfolge). Auch habe ich Ausflüge zu diversen anderen Distributionen unternommen. Unter anderem Arch und BSD Derivate. Seit einigen Jahren nutze ich auf dem Desktop Fedora und verspüre keinen Wechselwillen mehr. Es ist für mich alles andere als perfekt, aber ich habe (Windows und Mac OS eingeschlossen) bisher keine bessere Alternative gefunden.
Ich nutze seit Jahren Fedora, die liefern auch GNOME mit aus aber ich bin eher der i3/sway Nutzer. Ich nutze es privat und geschäftlich und bin seit einigen Jahren nur noch am Updaten, ca seit. Fedora 26 ohne Probleme trotz vieler exotischer repos. Einfach alles was nicht Standard ist vor dem update deaktivieren und danach für die passende Version wieder aktivieren. Läuft super. Da ich auf Servern und Cluster auch CentOS betreibe bin ich ganz froh in meinem Ökosystem sowohl aktuelle Desktops und lange Zeit stabil laufende Systeme zu haben. Selbst auf der Himbeere wird die Unterstützung besser. Naja man merkt wohl ich bin überzeugt. Viel Spaß beim Testen
Ich werfe mal Xubuntu ins Rennen. Viel Platz auf dem Desktop und läuft auch perfekt als virtualisiertes System. Der Unterbau ist Ubuntu aber trotzdem einen Versuch wert. Funktioniert auch gut mit X2Go.
Nop schrieb: >> Linux ist nix für dich (Umdenken). > > Alter, der OP nutzt schon lange Linux, merk mal was. Ich bin nicht dein Alter, auch nicht dein Kumpel. Merk du dir das bitte "Gast ohne Namen". Ja, er nutzt schon lange Linux, weshalb er wegen Look and feel die Distro wechselte. Anscheinend nicht lange genug, um zur Erkenntnis zu komme dass man GNOME auf jede x-beliebige Distro bekommt. Deswegen sucht man also wieder eine neue Distro. Ohne zu wissen dass der Unterbau weiterhin und immernoch Debian, Ubuntu, Fedora etc. bleibt. Daher ärgern mich derartige Ratschläge und Distroempfehlungen. Keiner von euch sagt: Lieber TO, gehe einfach in den Paketmanager/Paketverwaltung und installiere dir GNOME, Mate, Cinnamon, Xfce oder sonstwas. Damit bekommst du jede Distro ohne alle nacheinander abzugrasen.
Mister A. schrieb: > Ja, er nutzt schon lange Linux, weshalb er wegen Look and feel die > Distro wechselte. > Anscheinend nicht lange genug, um zur Erkenntnis zu komme dass man GNOME > auf jede x-beliebige Distro bekommt. Deswegen sucht man also wieder eine > neue Distro. Ich bin sogar so lange dabei, dass ich weiß, dass Linux Mint auf Ubuntu basiert und die selben GNOME-Pakete hat. Weshalb ich davon ausgehe, dass sie genauso stabil/instabil sind, wie in Ubuntu selbst. Cinnamon wird dagegen von Mint entwickelt und Ubuntu hat eben nicht die gleichen Pakete. Als ich zu Ubuntu gewechselt bin, stand eine Neuinstallation an, denn Mint hatte noch keine Ubuntu 20.04 Basis und ich brauchte neuere Pakete. Seit 2009 nutze ich Linux, seit 2013 als Hauptsystem. Zufrieden? Bevor ich wieder zu Mint wechsle (20.0) wollte ich eben ausloten, ob andere Distros stabiler sind. Meine Erfahrungen basieren nämlich zu 99% auf die Ubuntu/Mint Linie. Würde natürlich auch gerne andere Zweige kennenlernen, wenn es sich lohnt. Wenn allerdings GNOME auch in anderen Distros Probleme macht, dann lass ich es lieber sein. Deshalb hab ich gehofft, dass es hier Erfahrungsberichte gibt. "Bleib bei Windows" hab ich nicht erwartet. Schon gar nicht von einem registrierten User. Den anderen Beitragenden danke ich für die Nachrichten und hoffe auf weitere Erfahrungsberichte bzgl. Stabilität. Interessant für mich sind Debian, Fedora, Manjaro, OpenSUSE, CentOS. Neuere Pakete bevorzuge ich. Aber wenn jemand eine Distro nennen kann, die kaum Bugs hat (auch die von früher, als die älteren Pakete rauskamen nicht), dann bitte unbedingt nennen!
Auch sehr stabil ist CentOS, als freie Distribution des Red Hat Enterprise Linux. Aber Stabilität und "ich will immer die neueste Version" vertragen sich auch hier schlecht.
PC schrieb: > (Ton weg, Kabelnetzwerk weg -.-) Welche Fehler meinst du eigentlich? Gar kein Ton und Netzwerk oder wie? Es wird nichts erkannt und du brauchst irgendwelche spezielle Treiber?
natürlich ist Software fehlerhaft schrieb: > PC schrieb: >> (Ton weg, Kabelnetzwerk weg -.-) > > Welche Fehler meinst du eigentlich? > > Gar kein Ton und Netzwerk oder wie? Es wird nichts erkannt und du > brauchst irgendwelche spezielle Treiber? Nach dem Aufwachen aus der Bereitschaft funktionierte die kabelgebundene Netzwerkverbindung manchmal nicht mehr. Seit einiger Zeit funktioniert es gar nicht mehr. (Nur WLAN) Der Ton war nach einem Update weg. (Übrigens auch snapd, das konnte ich aber schnell wieder installieren) Kommt auch nur vorübergehend mit pulseaudio --check und pulseaudio -D Immer wieder schmiert das Ding auch ab, meist gleich nach dem Start am Login-Bildschirm noch. Das äußert sich darin, dass das Bild einfriert, sodass man auch die Maus nicht mehr bewegen kann. Verschiedene Kernel haben nichts gebracht. Dann noch die Kleinigkeiten, z.B. dass ein Fenster nach dem Bildschirm-Standby auf einem anderen Bildschirm ist, oder ein Bildschirm schwarz ist oder dass ein Bildschirm nicht mehr erkannt wird (das meist nach dem Absturz). Bei Mint hatte ich solche Probleme nicht. Das einzige, was war, dass Cinnamon abgestürzt ist, wenn man einen Bildschirm erst später eingeschaltet hat. Das wurde allerdings angeblich behoben, wie ich las.
Hi, Xubuntu benutzt Xfce als Window Manager und ist extrem stabil. Ich benutze es privat und in der Firma fuer embedded Linux development (yocto). Ich benutze es sowohl unter VirtualBox (host windows) als auch nativ. Remote Desktop Zugriff ueber X2GO. Einfach mal probieren.
Danke für den Tipp, aber XFCE ist für HiDPI nur bedingt geeignet und gefällt mir ehrlich gesagt auch nicht so gut...
" > In diesem Fall würde ich es gerne nutzen. V.a. passt der neue Kernel
mit
> all den aktuellen Treibern auch besser zu meinem PC.
Ich kriege hier auch in Mint 20 neben dem 5.4er LTS-Kernel auch einen
5.8er-Kernel angeboten, also daran scheitert's nicht."
Wenn etwas zwischen Distributionen anders ist, dann die
Kernelkonfiguration - 5.8 aus Distribution X kann sich völlig anders
verhalten als 5.8 aus Distribution Y.
PC schrieb: > Danke für den Tipp, aber XFCE ist für HiDPI nur bedingt geeignet und > gefällt mir ehrlich gesagt auch nicht so gut... xfconf-query -c xsettings -p /Gdk/WindowScalingFactor -s 2 xfconf-query -c xfwm4 -p /general/theme -s Default-xhdpi > gefällt mir ehrlich gesagt auch nicht so gut... mit xfce muss man erst warm werden. Das dauert und war bei mir auch so. Man kann sehr viel einstellen auch wenn es machmal versteckt und schwer zu finden ist. Ich habe sehr lange Suse Linux, Red hat, Mint und Ubuntu benutzt und bin dann bei Xubuntu gelandet und geblieben.Ist halt schlicht und einfach.
Tester schrieb: > Xubuntu benutzt Xfce als Window Manager und ist extrem stabil. Xubuntu hat doch unter der Haube die gleiche Softwarebasis wie Ubuntu, oder sehe ich da was falsch? Da hat der TE im Zweifel doch die gleichen Probleme, die er jetzt unter Ubuntu hat.
Andy D. schrieb: > Wenn etwas zwischen Distributionen anders ist, dann die > Kernelkonfiguration - 5.8 aus Distribution X kann sich völlig anders > verhalten als 5.8 aus Distribution Y. Ubuntu (und damit Mint) hat einen ausgesprochen guten HW-Support, und wenn es um aktuellere Treiber geht, die im Mainline-Kernel sind, dann sind die auch in Ubuntu. Also, sofern ein 5.8er Kernel ausreichend aktuell ist und man nicht einen noch neueren braucht.
Bei uns läuft auf neuen Linux-PCs immer noch die CDE, haben sich damit wunderbar in die Solaris und HPUX-Kisten integriert. Aber wahrscheinlich ist die CDE für viele einfach zu "angestaubt" und zu "un-bunt-u".
Mark schrieb: > wahrscheinlich ist die CDE für viele einfach zu "angestaubt" und zu > "un-bunt-u". Das macht man heute über Themes fürs DE. Willkommen in der Gegenwart.
Nee bei uns kommt auf die Kisten nix anderes drauf! Wir sind alles verkappte CDE'ler und brauchen den blinky-blinky- Mist der anderen Desktops nicht.
Gnome-Distros: Fedora, Manjaro, Arch- oder Void-Linux. Letztere beiden wenn (etwas) Konsolentätigkeit erlaubt ist. Ubuntu Budgie, Manjaro Budgie oder gleich Solus, wenn's mal was anderes GTK-basiertes sein darf, elementary OS (basiert auf Ubuntu), wenn's etwas mehr nach Mac aussehen darf/soll.
PC schrieb: > An Debian habe ich auch schon gedacht. Soll ja sehr stabil sein und ich > bräuchte mich kaum umgewöhnen, da vieles gleich läuft. Es ist insbesondere bessere als Linux Mint und Ubuntu im Hinblick auf Sicherheitspatches. > (Auch wenn ich > auf die Ubuntu-PPAs verzichten müsste, wobei es ja mit Flatpak und Snap > nicht all zu schwer sein dürfte...) Für Debian gibt es noch Backports. Flatpak kann für ausgewählte Programme aber auch Sinn machen. > Mein Rechner ist übrigens erst ein Jahr alt, ein Lenovo ThinkCentre > m920t mit i7-8700. Habe 2x 4k Monitore. Deshalb mach ich mir auch etwas > Sorgen, ob die stabilen Distros da zufriedenstellend laufen werden. Im Fall von Debian solltest du dann das aktuelle Point Release verwenden und dann da den aktuellen Kernel installieren. Derzeit wäre das also Version 10.5. https://linuxnews.de/2020/08/debian-gnu-linux-10-5-buster-freigegeben/
Sven B. schrieb: > PC schrieb: >> Manjaro wäre natürlich cool, da man immer aktuelle Software hat, aber >> eine Rolling Release-Distro assoziiert man wohl eher nicht mit >> Stabilität. > > Meine Erfahrung ist da anders. Bei Debian wird die "Stabilität" bei > vielen Paketen dadurch erreicht, dass einfach irgendeine zwei Jahre alte > Version eingefroren wird. Das stimmt nicht. Der Freeze findet meist im Frühjahr statt, da die Pakete von unstable (sid) kommen, sollten die Paketmaintainer bis zu diesem Termin möglichst ihre Pakete aktualisieren. Danach ist ein Anhebung auf eine neue Version nur noch in Ausnahmefällen möglich. Anschließend wird in der Freezezeit versucht, restliche Bugs zu beheben, bis man einen Punkt erreicht, an dem Debian als stable released werden kann. Als Richtwert kann man hier mit ca. 6 Monaten rechnen. Die meiste SOftware ist somit zum Releasezeitpunkt ca. >= 6 Monate alt und jeder weitere Monat hängt davon ab, wann der Maintainer das letzte mal das Paket in unstable upgedated hat. Es kann aber auch sein, dass die Entwickler bei Upstream lange Zeit keine neue Version herausgebracht haben und die dann erst nach dem Freeze rauskommt, die schafft es dann natürlich nicht mehr in Debian. Der Zeitplan für Debian 11 sieht bspw. so aus: https://linuxnews.de/2020/03/debian-11-bullseye-wird-vorbereitet/ Auch nach dem Release werden keine Versionssprünge mehr durchgeführt. D.h. je später man einen Release installeirt, desto älter ist die Software gegenüber der aktuellen Version bei Upstream. Wer also ein zum Installationsdatum recht aktuelles Debian haben will, der sollte es nach Release installieren. Dann sind die meisten Pakete so im Schnitt 5-10 Monate alt, mit obigen Abweichungen für Software, wo die Entwickler lange keinen Versionssprung bei Upstream mehr gemacht haben. > Ob die dann vernünftig funktioniert oder > nicht, ist im Zweifel zweitrangig. Klar gibt es keine neuen, > unerwarteten Bugs in dieser Software, dafür aber die alle, die seit zwei > Jahren bekannt und gefixt sind. Es zerschießt einem allerdings auch nicht das System. Bei einem Rolling Release kann das schon vorkommen, dass man dann plötzlich da steht und es nach dem Update nicht mehr wie gewünscht geht. Wer also ein Rolling Release will, der kann genauso gut Debian Unstable (sid) installieren. Da kriegt man im Prinzip das gleiche. > Bei Arch ist ab und zu mal was kaputt. Aber kurz. Nach 3 oder 5 Tagen > wird das dann repariert, weil es wird ja ständig aktualisiert. Mag sein, aber jetzt kann man sich mal vorstellen, dass die Software für den Login nicht funktioniert, oder die Desktop Oberfläche hat nen Bug und friert nach dem Login ein. Dann steht man 3 bis 5 Tage ohne Rechner da. Gut, das ist jetzt ein extrembeispiel. Bei so wichtiger Software dürfte ein Fix auch schneller kommen, aber wenn man in 10 min weg muss aber vorher dringend schnell noch was ausdrucken wollte, hilft das in so einem Fall dann auch nicht weiter. Deswegen sind die nichts für den Produktiveinsatz, da man sich für diesen Einsatzzweck auf Systeme verlassen können muss, die durchgehend verfügbar sind. Debian Stable kann das liefern. Ein Rolling Release wird das nicht liefern können.
Mister A. schrieb: > Das, was hier permanent als Ubuntu, Mint, Debian, Fedora bezeichnet und > empfohlen wird ist nichts anderes als ein einfacher Pkw mit > unterschiedlicher Ausstattung, der nur einen Produktnamen (Kompilation) > trägt. Das ist falsch. Es gibt schon erhebliche Unterschiede bezüglich der Sicherheitspolitik und der Verfügbarkeit von Patches für Sicherheitslücken. Bei Ubuntu wird zeitnah nur das was in den main Repos drin ist von Canonical supported. Alles was in universe und multiverse liegt, kriegt höchstens Updates, wenn sich einer aus der Community dafür berufen fühlt. Rechnen kann man damit aber nicht. Bei Debian ist wenigstens ein Maintainer zuständig und wenn der keine Zeit hat, dann kriegt man das wenigstens mitgeilt, dass ein Paket ein Sicherheitsupdate benätigt, aber noch keines erhalten hat. Bei Ubuntu gehen solche Informationen im Bugtracker unter, wenn sie überhaupt verfügbar sind, also jemand die Sicherheitslücke überhaupt gemeldet hat.
Tester schrieb: > PC schrieb: >> Danke für den Tipp, aber XFCE ist für HiDPI nur bedingt geeignet und >> gefällt mir ehrlich gesagt auch nicht so gut... > > xfconf-query -c xsettings -p /Gdk/WindowScalingFactor -s 2 > xfconf-query -c xfwm4 -p /general/theme -s Default-xhdpi Nicht dein ernst oder? XFCE hat seit Gnome 3 eine durchaus große Nutzerbasis und du willst mir sagen, dass die bis heute keine Konfigurationsmöglichkeit per GUI haben um so etwas einzustellen? Was noch nicht vorgeschlagen wurde ist übrigens KDE.
Nano schrieb: >> Meine Erfahrung ist da anders. Bei Debian wird die "Stabilität" bei >> vielen Paketen dadurch erreicht, dass einfach irgendeine zwei Jahre alte >> Version eingefroren wird. > > Das stimmt nicht. > Der Freeze findet meist im Frühjahr statt, da die Pakete von unstable > (sid) kommen, sollten die Paketmaintainer bis zu diesem Termin möglichst > ihre Pakete aktualisieren. > Danach ist ein Anhebung auf eine neue Version nur noch in Ausnahmefällen > möglich. > Anschließend wird in der Freezezeit versucht, restliche Bugs zu beheben, > bis man einen Punkt erreicht, an dem Debian als stable released werden > kann. Als Richtwert kann man hier mit ca. 6 Monaten rechnen. > Die meiste SOftware ist somit zum Releasezeitpunkt ca. >= 6 Monate alt > und jeder weitere Monat hängt davon ab, wann der Maintainer das letzte > mal das Paket in unstable upgedated hat. Also ziemlich genau was ich gesagt habe, oder? 6-12 Monate ist kein unüblicher Upstream-Releasezyklus. Dazu kommen 6 Monate von Debian *beim Release*, was auf 18 Monate ansteigt bevor das nächste Debian kommt. Im Moment ist in Debian Buster z.B. KDevelop 5.3.1 von Dezember 2018, ziemlich genau 2 Jahre alt. Seitdem erschienen sind von KDevelop die Versionen 5.3.2 5.3.3 5.4.0 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.5.0 5.5.1 5.5.2 5.6.0 Nach welcher für den Nutzer (oder irgendwen) nachvollziehbaren Logik bekomme ich jetzt im aktuellen Debian ausgerechnet die 5.3.1? Nach keinem Kriterium ist das irgendwie die beste oder stabilste Version der Software, außer "das war die, die es zufällig grad gab, als wir auf den Freeze-Knopf gedrückt haben". Das "stabil"-Argument würde ich mir gefallen lassen, wenn jemand evaluiert hätte, ob es in 5.3.3 größere Regressions gab und dann 5.3.3 geshippt würde. Sowas passiert aber grundsätzlich nicht. Stattdessen gibt's effektiv einen Archlinux-Snapshot ohne Updates. Change my view.
:
Bearbeitet durch User
Sven B. schrieb: >>> Meine Erfahrung ist da anders. Bei Debian wird die "Stabilität" bei >>> vielen Paketen dadurch erreicht, dass einfach irgendeine zwei Jahre alte >>> Version eingefroren wird. >> snip > > Also ziemlich genau was ich gesagt habe, oder? Das obige liest sich eher so, dass die Version schon 2 Jahre alt ist und die dann so eingefroren wird. Das ist aber nicht der Fall, da in unstable immer reecht zügig die neuen Versionen reinkommen. > 6-12 Monate ist kein > unüblicher Upstream-Releasezyklus. Wenn die Entwickler bspw. also im Oktober ihre neue Version rausbringen, dann kommt das noch meist rechtzeitig nach unstable und somit meist auch vor dem Freeze noch nach Testing. D.h. wenn dann im Juni Release ist, ist die Version gerademal 8 Monate alt. Das sind keine 2 Jahre. > Dazu kommen 6 Monate von Debian *beim > Release*, was auf 18 Monate ansteigt bevor das nächste Debian kommt. Man kann Debian nur die Zeit anlasten, die sie selber brauchen. Wenn die Entwickler der Software 3 Jahre nichts neues rausbringen, dann ist das nicht Debians schuld, wenn die Software dann zum Releasezeitpunkt 3,5 Jahre alt ist. > Im Moment ist in Debian Buster z.B. KDevelop 5.3.1 von Dezember 2018, > ziemlich genau 2 Jahre alt. Zum Zeitpunkt des Release war es genau 6 Monate alt. Dass die Software dann nach Release altert ist was ganz anderes und dazu habe ich oben ja schon etwas geschrieben. > Seitdem erschienen sind von KDevelop die Versionen Spielt keine Rolle. Zum Zeitpunkt des Release war die KDevelop Version mit nur 6 Monate alter recht aktuell für eine Distribution ohne Rolling Release. > Nach welcher für den Nutzer (oder irgendwen) nachvollziehbaren Logik > bekomme ich jetzt im aktuellen Debian ausgerechnet die 5.3.1? Nach > keinem Kriterium ist das irgendwie die beste oder stabilste Version der > Software, außer "das war die, die es zufällig grad gab, als wir auf den > Freeze-Knopf gedrückt haben". Ersetze mal KDevelop durch eine Bibliothek. Dann hast du dutzende Software die auf eine bestimmte Version aufbauen. Da ist es dann nicht mehr so einfach, die dann einfach auszutauschen und darauf zu hoffen, dass die ganze Software dann mit der noch läuft. Deswegen gibt es bei Distributionen dieses Freezes und darauf wird dann Stück für Stück das Bauwerk errichtet. Dass man hier dann keinen Stein mehr unten rausziehen und durch einen Tetraeder erstezen darf, ist nur logisch. Sinnvoll wäre es natürlich, wenn man Biliotheken von Anwendungen oder allgemeiner, Software für darauf aufbauendes, von Software, auf das nichts mehr aufbaut, in eigenen Repositories trennen und somit verschieden pflegen werden, aber dafür fehlt den meisten Distributionen die kein Rolling Releases haben die Manpower. Und dann gibt's ja da noch die Plugins und sonstige Erweiterungen bei Software, auf die man normalerweise nicht erwarten würde, dass da noch etwas aufbaut. Das zu Kategorisieren dürfte allein schon genug Arbeit bedeuten. Man denke da nur mal an Gimp. Da bauen bswp. noch Filter auf die irgendwer irgendwo als Pugin ins Netz stellt. Würde man Gimp regelmäßig updaten, dann wäre nicht mehr gewährleistet, dass ein bestimmter Filter mit den neuen Versionen harmoniert. So aber kann der Filterschreiber zumindest sagen, mit der Gimp Version aus Debian 10 läuft der Filter und für Debian 11 gibt's ne neue Version, sofern notwendig. Solche Sachen sind das. Im Prinzip kommt so eine Vorgehensweise aus dem Industrieumfeld, wo halt bestimtme Software für bestimmte Versionen zertififiert werden und nichts anderes. Da schmeißt man das Kartenhaus auch nicht ständig durcheinander. Der Heimanwender Zuhause updated da anders, der will immer das neuste. Allerdings kaschiert man das dann eben im Falle von Windows einfach dadurch, dass es die alten Libs einfach zusätzlich mitliefert und die Entwickler compilieren das dann eben für diese stabile "Runtime"Umgebung. Die Umwerfungen, die im MS internen Windows Entwicklerhaus stattfinden, kriegen Dritte außen gar nicht mit, sondern die kriegen dann halt erst wieder die nächste Majorversion zu Gesicht und dann können bzw. müssen sie damit ein paar Jahre Leben. Im Open Source Umfeld gibt es diese Umwerfungen bei den Grundgerüstlibs eben ständig in aller Öffentlichkeit und die Distris versuchen der Entwicklung dann halt hinterherzurennen. In den Griff kriegt man das dann eben mit diesen festen Releases. > > Das "stabil"-Argument würde ich mir gefallen lassen, wenn jemand > evaluiert hätte, ob es in 5.3.3 größere Regressions gab und dann 5.3.3 > geshippt würde. Das stabil bezieht sich in erster Linie auf die Paketierung. D.h. Programm x läuft mit den auf dem System befindlichen Versionen von Lib a, b, c usw.. Ergänzend wird dann noch zugesehen, dass es in dieser Kombination keine schweren Bugs, wie offensichtliche Abstürtze gibt. Ein Bug, der dann unten durchrutscht, weil er nur unter ganz bestimmten Konstellationen auftritt oder so tief im Programm versteckt ist, dass die meisten Nutzer bei normaler Nutzung kaum darauf stoßen, bleibt dann halt ungesehen und wird den Upstream Entwicklern überlassen, die sich dann halt darum kümmern, was dann aber halt nach Release der Distrie nicht in die Distri mehr reinkommen kann, es sei denn natürlich, jemand portiert den Fix auf die alte Version zurück, wofür dann wieder Manpower notwendig ist. Letzten Endes kann man also nur sagen. Willst du immer das neuste, dann wirst du um Flatpak nicht herumkommen. Da man aber üblicherweise nicht für jede Software immer das allerneuste braucht, sondern nur für die, wo man eine bestimmte Funktion braucht, die aber erst in der aktuellen Version verfügbar oder bugfrei ist, kann man das intallieren von Software via flatpak in Grenzen halten. Bezüglich flatpak wäre lediglich wünschenswert, dass die Upstream Entwickler auch offizielle Flatpak Builds zur Verfügung stellen. Da ist bei vielen leider noch nicht der Schuss angekommen, die ignorieren flatpak gekonnt selbst dann, wenn man sie darauf hinweist, weil sie die Wichtigkeit eines offiziellen Flatpak Pakets nicht kapieren.
PC schrieb: > XFCE ist für HiDPI nur bedingt geeignet Nano schrieb: > XFCE hat seit Gnome 3 eine durchaus große Nutzerbasis und du willst mir > sagen, dass die bis heute keine Konfigurationsmöglichkeit per GUI haben > um so etwas einzustellen? Einstellungen → Erscheinungsbild → Schriften → Eigener DPI-Wert ← auf tatsächliche Gegebenheiten stellen. Leisten und Symbole sind sowieso frei skalierbar. Nano schrieb: > die > ignorieren flatpak gekonnt selbst dann, wenn man sie darauf hinweist, > weil sie die Wichtigkeit eines offiziellen Flatpak Pakets nicht > kapieren. Weil Flatpack nunmal ’ne ganz hässliche Krücke ist. Du scheinst immer noch dem Irrtum aufzusitzen, dass die meisten Devs ihren Kram für andere machen. Ist nicht so.
:
Bearbeitet durch User
Mister A. schrieb: >> (Mint hat ja auch eine >> Ubuntu-Basis, trotzdem läuft es besser...) > Linux ist nix für dich (Umdenken). Bleib lieber bei Windows. > Das wird dir weder GNOME, noch eine andere hier empfohlene Distro > ändern/lösen können. Kannst mal deine ausgeleierte Platte fixen die du immer auflegst sobald jemand ein Problem mit Linux hat? Ps: Löse erst mal dein Problem, bevor du so "kaiserliche" Ratschläge gibst.
Nano schrieb: > Das ist aber nicht der Fall, da in unstable immer reecht zügig die neuen > Versionen reinkommen. Updates von Upstream kommen zum Teil über Jahre nicht an, weil die Maintainer-Kapazitäten nicht ausreichen. Ich erinnere nur an das Drama um xscreensaver, und das ist seitdem nicht besser geworden. Bei prominenten Programmen geht's ja noch, aber kleinere werden in Debian oftmals überhaupt nicht mehr aktualisiert. Hier ein Beispiel, Free42: https://packages.debian.org/sid/science/free42-nologo Das ist in Sid mit Version 1.4.77. Von wann ist denn die? https://thomasokken.com/free42/history.html Oh, von 2013. Seitdem ist das Projekt jedes Jahr aktiv weiterentwickelt worden, aber Debian pflegt Upstream-Updates überhaupt nicht mehr ein.
Nano schrieb: > Ein Bug, der dann unten durchrutscht, weil er nur unter ganz bestimmten > Konstellationen auftritt oder so tief im Programm versteckt ist, dass > die meisten Nutzer bei normaler Nutzung kaum darauf stoßen, bleibt dann > halt ungesehen und wird den Upstream Entwicklern überlassen, die sich > dann halt darum kümmern, was dann aber halt nach Release der Distrie > nicht in die Distri mehr reinkommen kann, es sei denn natürlich, jemand > portiert den Fix auf die alte Version zurück, wofür dann wieder Manpower > notwendig ist. Ein Bug, der die Anwendung abstürzen lässt, wenn man einfach nur eine Datei aufmacht, aber auch. Ich erinnere mich noch gut an das Qt-Release mit dem Memory-Bug im JIT-Compiler der JS-Engine. Anwendungen, die häufig Skripte ausgeführt haben, sind ständig zufällig abgestürtzt. Das war kein Nischen-Problem, mit dem Texteditor Kate konnte man keine fünf Minuten arbeiten. JAHRE nachdem der Fehler in einem Qt-Patch-Release behoben war, schlugen immer noch Debian-User im Bugtracker auf, weil Debian sich dafür natürlich nicht interessiert und einfach weiter das kaputte Release shippt. Denen konnte man immer nur sagen "sorry, nix zu machen, deine Distribution ist besonders 'stabil' und deshalb crasht das Programm jetzt halt für dich jahrelang bei jedem Tastendruck". Was meinst du mit "jemand portiert den Fix auf die alte Version zurück"? Das ist passiert. GENAU DAFÜR stellen Upstream-Maintainer ja Patch-Releases zur Verfügung. Die Debian aber nie shippt. Ich bleibe dabei: Das "Stabilisierungs"-Modell von Debian ist Unsinn. Es bietet keinen nennenswerten Vorteil gegenüber "ich nehme einfach einen random Snapshot vom Arch-Repo von 2018". Was tatsächlich helfen würde, wäre ein bisschen crowdsourced Qualitätssicherung der Upstream-Anwendungs-Releases zu machen, indem man z.B. für die alten Distro-Releases die Patch-Versionen der Upstreams als "experimentell" packt und dann einen Poll macht, ob das stable auf dieses Patch-Release geupdated wird. Nur durch so etway erreicht man eine tatsächliche Stabilisierung der Arbeitsumgebung.
:
Bearbeitet durch User
Sven B. schrieb: > GENAU DAFÜR stellen Upstream-Maintainer ja > Patch-Releases zur Verfügung. Die Debian aber nie shippt. Sven B. schrieb: > Das "Stabilisierungs"-Modell von Debian ist Unsinn. Es > bietet keinen nennenswerten Vorteil gegenüber "ich nehme einfach einen > random Snapshot vom Arch-Repo von 2018". Das ist nicht vollkommen richtig: sofern es ein sicherheitsrelevantes Problem war, pflegt Debian das sehr wohl auch in Stable ein. Darüberhinaus portieren sie entsprechende Fixes für neuere Versionen auf die alten, in Stable vorliegenden, Versionen zurück. Es gibt nur keine Feature-Updates, und halt auch keine mit Bugfixes, sofern die Bugs nicht die Sicherheit betreffen. Das ist nunmal die Definition von „Stable“. Es bedeutet im Umkehrschluss nämlich auch, dass keine neuen Bugs reinkommen. Das kann man mögen, oder nicht. Und wenn nicht, hat man Optionen: Backports, Testing, ganz was Anderes.
:
Bearbeitet durch User
Jack V. schrieb: > Das ist nicht vollkommen richtig: sofern es ein sicherheitsrelevantes > Problem war, pflegt Debian das sehr wohl auch in Stable ein. Ok, aber sehen wir der Sache in's Auge: das betrifft real ziemlich genau 3 Pakete, den Kernel, Firefox und Thunderbird. Und lustigerweise ist Debian genau da aufgefallen, dass ihr Modell nicht funktioniert, denn geshippt wird zwar KDevelop 5.3.1 von 2018, aber Firefox 78 von 06/2020. Der natürlich haufenweise neue Features, Änderungen, Bugs und Inkompatbilitäten hat gegenüber dem, was zum Release-Zeitpunkt von Debian Buster verfügbar war.
:
Bearbeitet durch User
Sven B. schrieb: > Ok, aber sehen wir der Sache in's Auge: das betrifft real ziemlich genau > 3 Pakete, den Kernel, Firefox und Thunderbird. Nein – wenn du der Sache ins Auge sehen möchtest, guckst du an, welche Pakete seit Release ein Sicherheitsupdate erhalten haben. Das betrifft mehrere hundert, wenn nicht tausend, Pakete. Und die Sache mit FF war nicht lustig; sie haben einfach nicht die Ressourcen, die enorm vielen problematischen Sachen bei diesem Monster von Software zuverlässig zu fixen. Nicht zuletzt, weil sich gerade da in der Zwischenzeit auch Sachen ändern, die sowas direkt unmöglich machen. Deswegen ist FF die eine große Ausnahme – was für die, welche die Eigenschaften von Stable schätzen, vermutlich kein zu großes Problem ist, solange es den Rest des Systems nicht beeinflusst: auf Servern, die rockstable und dennoch sicher laufen müssen, gibt’s in der Regel keinen FF. Die, denen das nicht so wichtig ist (Desktopuser), nutzen in der Regel sowieso Backports oder gleich Testing, wenn sie Debian bevorzugen. Oder eines der unzähligen Derivate.
:
Bearbeitet durch User
Ich denke wir müssen hier differenzieren zwischen Server- und Desktop-Usecases. Du denkst an den Server-Usecase, wo ich meine Position etwas relativieren muss: hier ist die Strategie von Debian gar nicht so schlecht. Ich habe eher über den Desktop-Usecase geredet, weil es darum in diesem Thread ja ging. Da bleibe ich bei meiner Position. Ob da nämlich in PHP, Python, Ruby, exim oder drupal ein Sicherheitsupdate geshippt wird, ist mir herzlich egal.
Jack V. schrieb: > sie haben einfach nicht die > Ressourcen, die enorm vielen problematischen Sachen bei diesem Monster > von Software zuverlässig zu fixen. Sie haben nicht die Ressourcen, um Dinge zu tun, die sie ohnehin nicht tun sollten - nämlich in der Upstream-Software herumzufummeln. Wenn sie das mal einfach unterlassen, passiert auch nicht sowas wie seinerzeit das key-Desaster mit OpenSSL unter Debian.
Nop schrieb: > aber Debian pflegt Upstream-Updates überhaupt nicht mehr ein. Mag an „All third-party code used in Free42 is either in the public domain, or licensed under terms compatible with GPLv2, or used with the authors' permission.“ (https://thomasokken.com/free42/) liegen. Software muss zweifelsfrei und umfassend frei sein, um in Debian zu landen – das ist eine der Grundsäulen der Distri. Und „used with the author's permission“ deutet darauf hin, dass die Anforderung nicht erfüllt ist → die letzte Version, die dem entspricht, hält sich in Debian, bis sie nicht mehr funktioniert, oder Sicherheitsbedenken dafür sorgen, dass sie rausgenommen wird.
Nop schrieb: > Sie haben nicht die Ressourcen, um Dinge zu tun, die sie ohnehin nicht > tun sollten - nämlich in der Upstream-Software herumzufummeln. Benutze halt was anderes, wenn dir deren Philosophie nicht passt. Es gibt Leute, die’s genau deswegen nutzen: der Kram funktioniert bis zum EOL des Releases gleich. Sicherheitsprobleme werden behoben, aber es ändert sich nix. Ich muss keine Sorgen haben, dass mir meine Kisten in irgendwelchen RZ nach ’nem Update wegbrechen, weil der Upstream meinte, von einer Minorversion zur Nächsten mal eben die Syntax der Configs komplett umbauen zu müssen, und das Tool zum Konvertieren Datensalat hinterlässt. Meine Güte, wieso muss man eigentlich alles, dessen Vorteile einem sich nicht direkt erschließen, oder die für einen selbst nicht wichtig sind, derart niedermachen wollen, anstatt dessen Existenz einfach zur Kenntnis nehmen und weiter seinen Kram nutzen zu können?
:
Bearbeitet durch User
Jack V. schrieb: > der Kram funktioniert bis zum EOL des Releases gleich. Oder er funktioniert auf dieselbe Weise nicht, und dann wird jahrelang kaputte Software ausgeliefert. Siehe xscreensaver, wo der Autor in Bugreports über längst gefixte Bugs regelrecht ertrunken ist. Deswegen hat er eine "Zeitbombe" eingebaut, wo nach ein paar Jahren ein Warndialog aufpoppte und den Benutzer darauf hinwies, daß seine Distro kaputt ist und keine Updates einpflegt.
Sven B. schrieb: > Ich habe eher über den Desktop-Usecase geredet, weil es darum in diesem > Thread ja ging. Da bleibe ich bei meiner Position. Ja, ist auch okay – ich würde kaum einem Desktopuser heute noch ein Debian Stable empfehlen. Ausnahme sind da die User der Gruppe 60+, weil die’s nicht gewohnt sind, dass sich Dinge alle Nase lang ändern, und die entsprechend auch nicht die neusten Features in etwa ihrem LO-Writer brauchen. Wenn Desktop, und Debian, dann Testing – allerdings sollte dazu auch ein gewisses Grundverständnis der Materie da sein, denn Testing hat seinen Namen aus Gründen. Ist allerdings immer noch stabiler, als manches Derivat, wie man so hört …
Nop schrieb: > Oder er funktioniert auf dieselbe Weise nicht, und dann wird jahrelang > kaputte Software ausgeliefert. Siehe xscreensaver, wo der Autor in > Bugreports über längst gefixte Bugs regelrecht ertrunken ist. Wenn ich mich recht erinnere, war der Fix für den betreffenden Bug sehr wohl rückportiert, nur eben der destruktive Code des Upstreams nicht angepasst worden. Insofern …
Jack V. schrieb: > Wenn ich mich recht erinnere, war der Fix für den betreffenden Bug sehr > wohl rückportiert Wie ich schrieb, ist der Autor in User-Bugreports über längst gefixte Bugs abgesoffen, deswegen hat er die "Zeitbombe" ja erst eingebaut, als Reaktion auf diese Zustände in Debian.
Nop schrieb: > Wie ich schrieb, ist der Autor in User-Bugreports über längst gefixte > Bugs abgesoffen, deswegen hat er die "Zeitbombe" ja erst eingebaut, als > Reaktion auf diese Zustände in Debian. Wenn er meint. Ich hätte im Bugtracker drauf hingewiesen, dass Bugreports bitte nur gegen die aktuelle Version gefiled werden sollen – wie’s jeder andere auch macht. Entsprechend ist dann für ’nen ordentlichen Bugreport unter nahezu jeder (entgegen der weit verbreiteten Märchen darüber auch bei etwa Arch) Distribution Selbstbau für ’nen ordentlichen Bugreport angesagt.
:
Bearbeitet durch User
Jack V. schrieb: > Weil Flatpack nunmal ’ne ganz hässliche Krücke ist. Es geht allerdings nicht anders, wenn man alle Distributionen, die es auf dem Markt gibt, versorgen möchte. > Du scheinst immer noch dem Irrtum aufzusitzen, dass die meisten Devs > ihren Kram für andere machen. Ist nicht so. Nein, ich betrachte das ganze aus einem erhöhten Blickwinkel mit dem Ziel, den Marktanteil von Linux oder allgemein Free Software zu erhöhen, weil das allen zu Gute kommt. Mehr Nutzer bedeuten nämlich auch mehr Pfleger + Entwickler, selbst wenn die Maintainer gegenüber den reinen Nutzern nur einen Bruchteil an Zuwachs ausmachen, da nützt aber praktisch jeder einzelne der neu als Maintainer oder Entwickler dazugewonnen werden kann. Und diesen Sachverhalt verstehen einige Devs nicht, die machen halt ihr Ding, weil sie die SW, so wie sie machen, brauchen, nutzen aber selbst wiederum Distributionen und haben dann selbst Mehrarbeit, wenn etwas anderes, dass nicht ihr Projekt ist, aber das sie selber brauchen, nicht läuft. Damit machen sie sich unnötig das Leben schwer. Dabei wäre der Aufwand gering, so ein Flatpack im Buildserver zu berücksichtigen und von diesem regelmäßig automatisiert bauen zu lassen. Das hilft Linux im Gesamten und bringt somit mehr Maintainer und Entwickler für Linux. Langfristig betrachtet müsste dann der obige Einzelgängerentwicklung sich dann nicht mehr um das ein oder andere dritte Softwareproblem, das er selber braucht, kümmern, weil dann vielleicht neu hinzugewonnene Entwickler oder Maintainer sich genau um diese Software kümmern. Es fehlt diesen Einzelgängern also an Verantwortungshaltung gegenüber dem großen ganzen und natürlich kann und darf ich das kritiseren, was nicht bedeutet, dass ich ein Anspruchsrecht hätte, denn das habe ich nie behauptet.
Nop schrieb: > Nano schrieb: > >> Das ist aber nicht der Fall, da in unstable immer reecht zügig die neuen >> Versionen reinkommen. > > Updates von Upstream kommen zum Teil über Jahre nicht an, weil die > Maintainer-Kapazitäten nicht ausreichen. Ich erinnere nur an das Drama > um xscreensaver, und das ist seitdem nicht besser geworden. > > Bei prominenten Programmen geht's ja noch, aber kleinere werden in > Debian oftmals überhaupt nicht mehr aktualisiert. Hier ein Beispiel, > Free42: Ausnahmen von der Regel kann es natürlich immer geben. Im großen und ganzen werden die meisten Pakete aber aktualisiert. > https://packages.debian.org/sid/science/free42-nologo > > Das ist in Sid mit Version 1.4.77. Von wann ist denn die? > > https://thomasokken.com/free42/history.html > > Oh, von 2013. Seitdem ist das Projekt jedes Jahr aktiv weiterentwickelt > worden, aber Debian pflegt Upstream-Updates überhaupt nicht mehr ein. Weil es für dieses Paket keinen aktiven Maintainer gibt, dann neigen die dazu zu verweisen. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959420 Hier hilft nur mehr Manpower und dafür braucht man eine größere Nutzerbasis. Siehe mein Kommentar das ich gerade eben vor diesem geschrieben habe.
Hm. Wenn du also der Meinung bist, es müsste Flatpaks von einer Software geben, deren Entwickler das allerdings nicht so sieht, oder dem eine eher geringe Priorität beimisst, und sich lieber um die Pflege seiner Software kümmert, statt die Hälfte der Zeit für sein Flatpak zu verbraten – warum gehst du nicht einfach hin und erstellst besagtes Flatpak? Und kümmerst dich aber auch anschließend um dessen Pflege? Dann wirst du sehen: der erste Teil ist so einfach, wie du’s dir vorstellst. Der zweite Teil kann, je nach Umfang, wirklich sehr viel Zeit in Anspruch nehmen. Wird dir ja nix ausmachen, wenn du schon selbst der Meinung bist, der Entwickler könne das ja nebenbei so machen? Nano schrieb: > Und diesen Sachverhalt verstehen einige Devs nicht Und du verstehst nicht, dass die allermeisten Projekte unbezahlte Zeit und Leistung sind, welche die Entwickler gerne in ihr Projekt stecken, und das du gerne nutzen darfst – auch, um Flatpaks draus zu bauen, wenn dir so ist, aber dass du ansonsten mal so gar keinen Anspruch auf irgendwas zu haben hast. Sorry, aber diese „/Ich/ finde das anders besser, also müsst ihr mir das gefälligst so machen!!“-Attitüde zum Vomieren.
:
Bearbeitet durch User
Jack V. schrieb: > Meine Güte, wieso muss man eigentlich alles, dessen Vorteile einem sich > nicht direkt erschließen, oder die für einen selbst nicht wichtig sind, > derart niedermachen wollen, anstatt dessen Existenz einfach zur Kenntnis > nehmen und weiter seinen Kram nutzen zu können? Weil es im Fall von Debian für die Upstreams einen Riesenhaufen Ärger bedeutet, wenn ständig unzufriedene User aufschlagen, die nicht von der verbuggten Version updaten können die man vor 2 Jahren mal für 1 Woche released hatte.
Sven B. schrieb: > Ok, aber sehen wir der Sache in's Auge: das betrifft real ziemlich genau > 3 Pakete, den Kernel, Firefox und Thunderbird. > > Und lustigerweise ist Debian genau da aufgefallen, dass ihr Modell > nicht funktioniert, denn geshippt wird zwar KDevelop 5.3.1 von 2018, > aber Firefox 78 von 06/2020. Der natürlich haufenweise neue Features, > Änderungen, Bugs und Inkompatbilitäten hat gegenüber dem, was zum > Release-Zeitpunkt von Debian Buster verfügbar war. Bei Firefox und Thunderbird war das Problem, dass den Debian Leuten schlichtweg die Manpower fehlt Sicherheitslücken in alten Browsern, die ein Großprojekt für sich darstellen, zu fixen. Deswegen nimmt man jetzt die ESR Versionen von Mozilla, was ja nicht falsch sein muss, denn Firefox wird als ESR von den Entwicklern selbst sehr gut gepflegt. Davor hat man mit Iceweasel halt versucht, die Bugfixes rückzuportieren, aber dann irgendwann festgestellt, dass der Aufwand in Angesicht der zu wenigen Entwickler zu groß ist. Vom Prinzip her würde es mit genug Entwicklern aber funktionieren.
Sven B. schrieb: > Weil es im Fall von Debian für die Upstreams einen Riesenhaufen Ärger > bedeutet, wenn ständig unzufriedene User aufschlagen, die nicht von der > verbuggten Version updaten können die man vor 2 Jahren mal für 1 Woche > released hatte. Magst du einen dieser Bugreports verlinken? Ich will den Riesenhaufen Ärger mal begutachten, der sich nicht mit „please use a recent version for reporting bugs, thx“ erledigt haben sollte. Nano schrieb: > Bei Firefox und Thunderbird war das Problem, dass den Debian Leuten > schlichtweg die Manpower fehlt Sicherheitslücken in alten Browsern, die > ein Großprojekt für sich darstellen, zu fixen. Nein, das Problem war, dass die Fixes nicht mehr zurückportiert werden können, weil sich zwischendurch mal wesentliche Teile ändern. Das ging doch sogar so weit, dass viele alte Addons nicht mehr funktionierten und auch nicht angepasst werden konnten, weil API-Funktionen ersatzlos weggefallen sind. Nano schrieb: > Jack V. schrieb: >> Weil Flatpack nunmal ’ne ganz hässliche Krücke ist. > > Es geht allerdings nicht anders, wenn man alle Distributionen, die es > auf dem Markt gibt, versorgen möchte. Natürlich geht’s anders: man stellt die Sourcen zur Verfügung, und lässt die Distributionsleute das in ihre Distributionen einpflegen. Das geht ganz prima, und das Ergebnis sind integrierte Sachen, und kein Haufen redundantes Flickenwerk, das, wenn man sein System konsequent darauf aufbauen würde, mittlere vierstellige Summen alleine für die Systemlaufwerke verschlingen würde.
Jack V. schrieb: > Hm. Wenn du also der Meinung bist, es müsste Flatpaks von einer Software > geben, deren Entwickler das allerdings nicht so sieht, oder dem eine > eher geringe Priorität beimisst, und sich lieber um die Pflege seiner > Software kümmert, statt die Hälfte der Zeit für sein Flatpak zu > verbraten – warum gehst du nicht einfach hin und erstellst besagtes > Flatpak? Weil das nicht offiziell wäre. Siehe oben, das ist genau das was ich in meinem ersten Post kritisierte. Es gibt von den Entwicklern keine Flatpaks, die Flatpaks findet man nicht auf deren Porjektwebseite. Es kann aber durchaus Flatpaks von deren Software geben, nur sind die von wer weiß sonst wem. Und guck dir doch mal an, wie es beim TV Browser damals gelaufen ist. Die Entwickler fanden plötzlich eine TV-Browser Version im Umlauf, die nicht von ihnen war und Malware (oder war's Werbung) enthielt, die ebenso nicht von ihnen war. Will man dem zuvorkommen, dann liefert man ein offiziellen Flatpak Build aus. Außerdem kostet ein Flatpak keine 50 % der Zeit der Entwicklerresourcen. Oder meinst du jetzt, dass wegen Flatpak mehr Leute die aktuellste Version nutzen könnten und die dann den Entwickler mit Bugreports zuerwerfen würden, die er, wenn es kein Flatpak geben würde, erst in vielen Jahren erhalten würde? Ja, so kann man das natürlich auch sehen, aber dann hat man für Jahre verbuggte Software. > Und kümmerst dich aber auch anschließend um dessen Pflege? Dann > wirst du sehen: der erste Teil ist so einfach, wie du’s dir vorstellst. > Der zweite Teil kann, je nach Umfang, wirklich sehr viel Zeit in > Anspruch nehmen. Wird dir ja nix ausmachen, wenn du schon selbst der > Meinung bist, der Entwickler könne das ja nebenbei so machen? Ach und du meinst, ich könnte das für jede Software machen, für die es kein offiziellen Flatpak Build gibt? Also ca. 60000 Softwarepakete? Wieviel Leben würdest du mir dafür schenken oder könntet du mich klonen, damit ich parallel mit vielen Nanos die 60000 Pakete stemmen kann? Du siehst also, diese Probleme können nur die Entwickler alleine lösen. > Nano schrieb: >> Und diesen Sachverhalt verstehen einige Devs nicht > > Und du verstehst nicht, dass die allermeisten Projekte unbezahlte Zeit > und Leistung sind, Irrtum, denn ich habe nie gegenteiliges behauptet. > welche die Entwickler gerne in ihr Projekt stecken, > und das du gerne nutzen darfst – auch, um Flatpaks draus zu bauen, > wenn dir so ist, aber dass du ansonsten mal so gar keinen Anspruch auf > irgendwas zu haben hast. Siehe oben, ich sagte bereits, dass ich keinen Anspruch erhebe. Das ändert aber trotzdem nichts daran, dass ich das kritisieren kann und auch darf. Analog machst du das bei Reichen doch sicher auch, dass sie mit ihrem vielen Geld die Welt verbessern und wenn sie nur so Unternehmen wie Tesla gründen und E-Autos auf den Markt bringen. Denn Eigentum verpflichtet. Der Entwickler ist hier praktisch der Reiche über die Software, da er die Software versteht und in und auswendig kennt, das ist sein Reichtum und mit diesem kommt auch Verantwortung gegenüber der Gesellschaft.
Jack V. schrieb: > Nano schrieb: >> Jack V. schrieb: >>> Weil Flatpack nunmal ’ne ganz hässliche Krücke ist. >> >> Es geht allerdings nicht anders, wenn man alle Distributionen, die es >> auf dem Markt gibt, versorgen möchte. > > Natürlich geht’s anders: man stellt die Sourcen zur Verfügung, und lässt > die Distributionsleute das in ihre Distributionen einpflegen. Du ignorierst jetzt gekonnt, das wir über aktuelle bleeding Edge Versionen sprechen. Und da habe ich dir oben aufgezeigt, warum das bspw. bei Debian nicht funktioniert und dann dem anderen gesagt, dass er hier auf Flatpaks setzen soll. > Das geht > ganz prima, Nein geht nicht. Siehe vorheriger Abschnitt. > und das Ergebnis sind integrierte Sachen, und kein Haufen > redundantes Flickenwerk, das, wenn man sein System konsequent darauf > aufbauen würde, mittlere vierstellige Summen alleine für die > Systemlaufwerke verschlingen würde. [x] Du hast Flatpak nicht verstanden Flatpak nimmt man für ganz wenige, selektiv ausgewählte Software, weil man da bspw. die neuste Version oder ein bestimmtes Feature braucht. Der Rest der anderen Softwae auf dem System kann aber ruhig ein paar Monate alt sein, für die hat man die "alten" Pakete der Distirbution. In meinem Fall würde ich auf meinem Debian stable bspw. nur ein Flatpak nutzen müssen, allerdings gibt's keinen offiziellen Build und dieses Flatpak von sonstwem werde ich ganz sicher nicht nutzen, auch wenn Flatpaks in einer Sanbox laufen.
Nano schrieb: > Weil das nicht offiziell wäre. > > Siehe oben, das ist genau das was ich in meinem ersten Post kritisierte. > Es gibt von den Entwicklern keine Flatpaks, die Flatpaks findet man > nicht auf deren Porjektwebseite. Es kann aber durchaus Flatpaks von > deren Software geben, nur sind die von wer weiß sonst wem. Dann werde Teil des jeweiligen Teams. Nano schrieb: > Will man dem zuvorkommen, dann liefert man ein offiziellen Flatpak Build > aus. … und ein offzielles Snap und ein offizielles AppImage und ein offizielles […]? Nano schrieb: > Außerdem kostet ein Flatpak keine 50 % der Zeit der Entwicklerresourcen. Zunächst nicht […] Nano schrieb: > Du siehst also, diese Probleme können nur die Entwickler alleine lösen. Nein. Und mir ist’s auch lieber, wenn die Entwickler ihren Kram entwickeln, und Flatbloat-Fans sich um eben diese Pakete kümmern. Wie ’ne Distri, nur eben auf Flatpaks aufgebaut. Das würde auch das Problem mit „ist ja nicht offziell“ beheben, denn bei den herkömmlichen Distris läuft’s ja nicht anders: der Upstream gibt die Sourcen, die Distributionsleute bauen die Pakete und ich muss unterm Strich beiden Vertrauen entgegenbringen, oder es mir eben selbst machen. Nano schrieb: > Analog machst du das bei Reichen doch sicher auch, dass sie mit ihrem > vielen Geld die Welt verbessern und wenn sie nur so Unternehmen wie > Tesla gründen und E-Autos auf den Markt bringen. Bitte unterlasse solche Unterstellungen. Mir sind reiche Leute herzlich egal, und ’nen Anspruch stelle ich an die nur genau dann, wenn sie im Gegenzug Ansprüche an mich stellen. Beispielsweise: sie haben den Anspruch, dass ich für sie zu arbeiten hätte – dann habe ich den Anspruch, dass sie dafür zu bezahlen hätten. Passt auch gut ins Thema: jemand hat den Anspruch, dass ich mein Projekt als Flatpak veröffentliche? Dann habe ich den Anspruch, dass er mich dafür entlohnt. Nano schrieb: > Du ignorierst jetzt gekonnt, das wir über aktuelle bleeding Edge > Versionen sprechen. > > Und da habe ich dir oben aufgezeigt, warum das bspw. bei Debian nicht > funktioniert und dann dem anderen gesagt, dass er hier auf Flatpaks > setzen soll. Und du ignorierst, dass es nicht nur Debian Stable gibt, sondern durchaus auch Zweige, Derivate und gar andere Distributionen, die dem Upstream im Schnitt so zwei Wochen hinterherlaufen. Ganz ohne Flatpaks. Zwei Wochen sollten verschmerzbar sein, oder fällt dir ein Feature ein, das du mal unbedingt und sofort haben musstest, sobald der Dev es in ein Release gebracht hat? Nano schrieb: > Flatpak nimmt man für ganz wenige, selektiv ausgewählte Software, weil > man da bspw. die neuste Version oder ein bestimmtes Feature braucht. > Der Rest der anderen Softwae auf dem System kann aber ruhig ein paar > Monate alt sein, für die hat man die "alten" Pakete der Distirbution. Und diese ganz wenige selektiv ausgewählte Software lässt sich nicht bauen, oder woran hängt’s? Nano schrieb: > In meinem Fall würde ich auf meinem Debian stable bspw. nur ein Flatpak > nutzen müssen, allerdings gibt's keinen offiziellen Build und dieses > Flatpak von sonstwem werde ich ganz sicher nicht nutzen, auch wenn > Flatpaks in einer Sanbox laufen. Dann mach’s dir halt selbst? Ist ja kein Aufwand, wie du selbst sagtest?
:
Bearbeitet durch User
Jack V. schrieb: > Ich will den Riesenhaufen > Ärger mal begutachten, der sich nicht mit „please use a recent version > for reporting bugs, thx“ erledigt haben sollte. Natürlich kannst du das hinschreiben, ja. Aber du bist doch als Upstream daran interessiert, dass deine Benutzer eine funktionierende Version deiner Software zur Verfügung haben! Ich will doch, dass das für den, der sich da gerade beklagt, funktioniert. Für den mache ich doch das Projekt. Und Debians Verfahren macht es mir als Upstream quasi unmöglich, diesen Leuten zu helfen.
Sven B. schrieb: > Aber du bist doch als Upstream > daran interessiert, dass deine Benutzer eine funktionierende Version > deiner Software zur Verfügung haben! Ich will doch, dass das für den, > der sich da gerade beklagt, funktioniert. Für den mache ich doch das > Projekt. Und Debians Verfahren macht es mir als Upstream quasi > unmöglich, diesen Leuten zu helfen. Bin ich? Will ich? Ich stelle meinen Kram zur Verfügung und freue mich, wenn’s jemandem nützlich erscheint. Aber dass ich irgendwas will, kann ich nicht sagen. Ich kann und will den Leuten auch nicht vorschreiben, nicht Debian Stable zu nehmen, sondern eine rollende Distribution zu fahren. Und bei Debians Verfahren kommt der Bugreport idealerweise bei Debian selbst an (gibt auch ein Programm dafür, reportbug) – wenn er ohne Umweg beim Upstream eintrudelt, dann heißt dass, dass der betreffende Anwender ziemlich ignorant ist, weil er nämlich gleich zwei deutliche Zeichen ignoriert hat: eben den Debian-Bugtracker und den Hinweis in meinem Bugtracker, bei Problemen doch bitte erstmal mit der aktuellen Version gegenzutesten, bevor der Report erstellt wird.
Jack V. schrieb: > Nano schrieb: >> Weil das nicht offiziell wäre. >> >> Siehe oben, das ist genau das was ich in meinem ersten Post kritisierte. >> Es gibt von den Entwicklern keine Flatpaks, die Flatpaks findet man >> nicht auf deren Porjektwebseite. Es kann aber durchaus Flatpaks von >> deren Software geben, nur sind die von wer weiß sonst wem. > > Dann werde Teil des jeweiligen Teams. Von welchem Projekt soll ich den Teil des Teams werden. Von allen? > … und ein offzielles Snap und ein offizielles AppImage und ein > offizielles […]? Snap ist ne Canonical Only Geschichte. AppImage hat AFAIK keine Sandbox. > > Nano schrieb: >> Du siehst also, diese Probleme können nur die Entwickler alleine lösen. > > Nein. Und mir ist’s auch lieber, wenn die Entwickler ihren Kram > entwickeln, und Flatbloat-Fans sich um eben diese Pakete kümmern. Wie > ’ne Distri, nur eben auf Flatpaks aufgebaut. Das würde auch das Problem > mit „ist ja nicht offziell“ beheben, denn bei den herkömmlichen Distris > läuft’s ja nicht anders: der Upstream gibt die Sourcen, die > Distributionsleute bauen die Pakete und ich muss unterm Strich beiden > Vertrauen entgegenbringen, oder es mir eben selbst machen. Für die Windows Version kriegst du aber ein offizielles Binary von den Entwicklern. > Nano schrieb: >> Du ignorierst jetzt gekonnt, das wir über aktuelle bleeding Edge >> Versionen sprechen. >> >> Und da habe ich dir oben aufgezeigt, warum das bspw. bei Debian nicht >> funktioniert und dann dem anderen gesagt, dass er hier auf Flatpaks >> setzen soll. > > Und du ignorierst, dass es nicht nur Debian Stable gibt, sondern > durchaus auch Zweige, Derivate und gar andere Distributionen, die dem > Upstream im Schnitt so zwei Wochen hinterherlaufen. Ich sprach von allen Distris. Nicht selektiv ausgewählten, die ich dann deiner Meinung nach auswählen soll, im Sinne von muss. Das löst also gar nicht das Problem, sondern verschiebt es nur, weil ich mit einer Rolling Release Distris dann neue Probleme erhalten, die ich mit Debian Stable nicht hätte. Das ist also keine Lösung. > > Nano schrieb: >> Flatpak nimmt man für ganz wenige, selektiv ausgewählte Software, weil >> man da bspw. die neuste Version oder ein bestimmtes Feature braucht. >> Der Rest der anderen Softwae auf dem System kann aber ruhig ein paar >> Monate alt sein, für die hat man die "alten" Pakete der Distirbution. > > Und diese ganz wenige selektiv ausgewählte Software lässt sich nicht > bauen, oder woran hängt’s? Bauen lässt sich das schon. Aber summiere mal die Zeit aller Menschen die das machen sollen zusammen. Da gehen dann ein paar Tausend Jahre drauf. Die Apple Jünger verdanken Steve Jobs übrigens, dass sie viele hundertausende von Jahre Zeit einsparen konnten, weil Steve Jobs seinem Programmierer damals gesagt hat, dass der Bootprozess zu langsam ist und er das schneller machen soll. Der Programmierer hat zwar zuerst rumgemosert, weil sein alter Bootprozess ja funktioniert hat und er nicht die Notwendigkeit sah, dass man das ändern müsse, aber nach Steves Einwand hat er sich halt doch nochmal dran gesetzt. Dadurch konnte er ca. 20-30 s Bootzeit einsparen. Für sich alleine genommen war das nicht viel. Aber Mio Applekunden hat er so jeden Tag 20 bis 30 s eingespart. Zählt man alles zusammen, was da an eingesparter Zeit zusammenkommt, waren das ein paar Mio Jahren und jedes Jahr kommt mehr Zeit dazu, solange irgendwo auf der Welt den alten Rechner gerade irgendeiner nutzt und bootet. Und so verhält sich das auch mit Flatpaks. Wenn die Entwickler offizielle Flatpaks rausbringen würden, dann müßten viele tausend Nutzer nicht selber compilieren. Das spart Zeit und da Compilieren auch Rechenzeit und somit Strom kostet, auch Ressourcen. Aus Klimaschutzgründen würden da ein paar Tonnen eingespartes CO2 rauskommen, da nicht jeder der vielen Mio Nutzer das selber compilieren muss. Betrachtet man die Verweigerungshaltung der Devs Flatpaks auszuliefern, so ist es eigentlich etwas gutes, dass der größte Teil des Marktes noch Windows benutzt. Denn da bekommen die vielen Milliarden Nutzer noch binary Builds und müssen somit nicht alle selber compilieren. Und nein, ich werde jetzt nicht Linux aufgeben, aber das erwähne ich, weil es dir mal zu denken geben sollte das mal aus dem Blickwinkel des großen Ganzen zu betrachten. > Nano schrieb: >> In meinem Fall würde ich auf meinem Debian stable bspw. nur ein Flatpak >> nutzen müssen, allerdings gibt's keinen offiziellen Build und dieses >> Flatpak von sonstwem werde ich ganz sicher nicht nutzen, auch wenn >> Flatpaks in einer Sanbox laufen. > > Dann mach’s dir halt selbst? Ist ja kein Aufwand, wie du selbst sagtest? Ja, mir bleibt hier keine andere Wahl. Aber siehe mein letzter Abschnitt. Jetzt machen das halt ein paar Mio von meinesgleichen.
Hallo zusammen, ich habe nicht den ganzen Kram hier gelesen, da er doch ziemlich schnell ziemlich weit vom Original-Thema abgewandert ist, mkönnte daher was übersehen haben, möchte aber dennoch auch die Ursprungsfrage zurückkommen; ein paar andere hatten das auch schon geäußert, aber hier nochmal ganz deutlich: Warum, um Himmels willen, sollte man wegen des AUSSEHENS die Distribution wechseln wollen? Das Aussehen kann man doch in weiten Grenzen frei wählen, indem man Fenstermanager und Desktops durch- und „Themen“ ausprobiert und im Zweifel individuell Farben und Fensterdekorationen und Mauszeiger oder sonstwas ändert. Man ist doch nicht verpflichtet, mit dem zu leben, was bei der aktuellen Distributions-Version als Vorgabe geliefert wird! Grüße, Christoph
Beitrag #6468674 wurde von einem Moderator gelöscht.
Nano schrieb: > Von welchem Projekt soll ich den Teil des Teams werden. Von allen? Von dem, dessen Software du haben wolltest. Ist ja nur ganz wenig selektierter Kram, wie du schriebst. Nano schrieb: > Für die Windows Version kriegst du aber ein offizielles Binary von den > Entwicklern. Ich kenne nicht viele native Linuxprogramme, für die’s ein offizielles Binary für Windows gibt. Aber wenn, dann ist das die freie Entscheidung der Entwickler. Nix, worauf man irgendeinen Anspruch hätte (im Sinne von: das man fordern könnte – weil du ja oben schriebst, du würdest keinen Anspruch erheben. Aber fordern tust du ja nunmal zweifelsfrei). Nano schrieb: > Ich sprach von allen Distris. > Nicht selektiv ausgewählten, die ich dann deiner Meinung nach auswählen > soll, im Sinne von muss. > Das löst also gar nicht das Problem, sondern verschiebt es nur, weil ich > mit einer Rolling Release Distris dann neue Probleme erhalten, die ich > mit Debian Stable nicht hätte. Warum willst du alle Distris gleichmachen? Es ist gut, dass es verschiedene Ansätze gibt – da kann sich jeder draus nehmen, was ihm am besten passt. Und die Probleme rollender Distributionen – habe ich die nicht genauso, wenn ich statt der Distribution nun meine Software via Flatpak und so rollen lasse, und da gar noch einzelne Komponenten unabhängig voneinander? Nano schrieb: > Betrachtet man die Verweigerungshaltung der Devs Flatpaks auszuliefern, > so ist es eigentlich etwas gutes, dass der größte Teil des Marktes noch > Windows benutzt. Hm. Aus meiner persönlichen Sicht ist das ein Punkt für das Nichtanbieten von Flatpaks. Wenn diese dafür sorgen würden, dass mir auf einmal viele herberts meinen Bugtracker mit „geht nich, dein Mist! Windows ist toller!!k“ beaufschlagen, würde ich den Kram direkt an den Nagel hängen. Nano schrieb: > Ja, mir bleibt hier keine andere Wahl. > Aber siehe mein letzter Abschnitt. > > Jetzt machen das halt ein paar Mio von meinesgleichen. Ja, dann mach halt einmal, und stell’s zur Verfügung. Gibt doch bestimmt ’nen zentralen Platz für so Flatpaks, oder? Mit Reputationssystem und so? Wenn nicht, dann mach halt einen auf. Nimm dir ’ne stabile Distribution als Grundsystem, bau alles, was möglich ist, als Flatpak dafür, such dir Gleichgesinnte und zieh die erste Flatbloat-Distri auf. Das ist ernst gemeint, btw. – ich würde für den Start gar Ressourcen zur Verfügung stellen, wenn du’s ernsthaft angehen würdest. Aber ich würde meine Zeit nicht dafür hergeben, meinen Kram selbst in solchen Paketen zu versenken.
:
Bearbeitet durch User
Ichhalte das mit den Flatpaks für keine gute Idee, weil dann die Anwendungs-Entwickler dafür verantwortlich werden, die benutzten Libraries selber aktuell zu halten. Das absehbare Ergebnis sind Anwendungen voller Sicherheitslücken, bei denen man obendrein keinen Überblick hat, was jetzt wo gestopft ist.
Nop schrieb: > Ichhalte das mit den Flatpaks für keine gute Idee, weil dann die > Anwendungs-Entwickler dafür verantwortlich werden, die benutzten > Libraries selber aktuell zu halten. Das absehbare Ergebnis sind > Anwendungen voller Sicherheitslücken, bei denen man obendrein keinen > Überblick hat, was jetzt wo gestopft ist. RedHat hat vor kurzem angekündigt, dass sie eine Laufzeitumgebung für Flatpak anbieten werden die dann auch gut gepflegt wird. Die kann man dann verwenden. Zusätzliche Libs, die dann nicht darin enthalten sind, wird man wohl aber selber weiterpflegen müssen.
Nano schrieb: >> xfconf-query -c xsettings -p /Gdk/WindowScalingFactor -s 2 >> xfconf-query -c xfwm4 -p /general/theme -s Default-xhdpi > > Nicht dein ernst oder? > > XFCE hat seit Gnome 3 eine durchaus große Nutzerbasis und du willst mir > sagen, dass die bis heute keine Konfigurationsmöglichkeit per GUI haben > um so etwas einzustellen? > > Was noch nicht vorgeschlagen wurde ist übrigens KDE. Wenn ich ein System neu aufsetze, dann gehe ich doch nicht durch die ganzen Menue-Eintragungen. Hier hilft mir ein Skript, das mir alle Einstellungen macht. Warum Stunden spendieren, wenn es reproduzierbar auch in Sekunden geht? Programme und libs werden im naechsten Schritt auch mit apt per Skript installiert. KDE ist so ein Thema. Ich habe den Windowsmanager sehr lange benutzt. SuOS und Solaris(CDE deinstalliert) mit olvwm als Window Manager waren wirklich klasse. "Textedit" war der einzige Editor der Gigabyte Grosse Dateien editieren konnte. Leider gabe es keine 64Bit Version. Irgendwie vermisse ich meine alte Sun Workstation. Da war auch noch Slackware (1993) für eine kurze Zeit auf meinem zu schwachen Rechner. Tja, man wird alt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.