Ubuntu-Alternativen (Linux) gesucht

Debian? Wobei: Wenn Ubuntu schon nicht so recht will ;-)

PC schrieb:
> Das einzige, was mir nicht ganz gefiel, war der Look.

never touch a running system.

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...

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.

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.

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!

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...

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.