Erfahrungen eines Linux unerfahrenen Gamers - Ein Tagebuchthread

[andy_m4]

Einerseits wegen dieser Verzeichnisverdrehung mit dem @-Kram

Etwas als Verdrehung zu bezeichnen, weißt darauf hin, das es hier um ne reine subjektive Sympathie-Antipathie-Argumentation geht und nicht, was objektiv in einem bestimmten Szenario besser oder schlechter ist.
An erstem bin ich weniger interessiert, weil solche Diskussionen nicht zielführend sind.

und vor allem weil man Snapshots eben nicht als Snapshots kopieren kann

Kommt natürlich drauf an, wie Snapshots implementiert sind.
Bei Btrfs weiß ich es nicht im Detail, aber bei ZFS kann ich das sehr wohl.
Möglicherweise richtet sich Deine Kritik auch explizit gegen Btrfs-Snapshots und nicht gegen Snapshots im Allgemeinen?! Das solltest Du vielleicht mal klar stellen.

Und hätte natürlich erst recht nicht die freie Wahl des Dateisystems.

Kommt halt darauf an, was man wofür und wie einsetzt. Snapshots sind in erster Linie ja dafür gedacht innerhalb ihres nativen Dateisystems benutzt zu werden. Dort haben sie halt ihre Stärken die sie dann auch voll ausspielen, wenn man sie entsprechend einsetzt.
Wenn Du was anderes machen willst, passen sie dann logischerweise nicht mehr so gut. Das spricht aber eben nicht gegen Snapshots im Allgemeinen, sondern gegen ihre Verwendung zu einem bestimmten Anwendungszweck.
Hatte ich aber eigentlich schon erklärt.

Solange ich einen großen Vorteil davon habe, ist es nicht unnütz.

Mag ja alles sein. Nur bringt es wenig es allein zu behaupten. :-)

Gerade erst heute habe ich mein Produktivsystem und zwei meiner Testinstallationen nach Tests bzgl. des D-Bus-Problems im KVM-Thread auf die Art wieder zurückgesetzt.

Gerade zum testen und herumspielen in VMs sind doch Snapshots ideal. Deshalb adaptiert ja verschiedenste VM-Software gerne das Snapshot-Prinzip.

Das hatte ich schon genannt, aber darauf bist du nicht eingegangen.

Auf was? Das mit der Dateisystemunabhängigkeit? Darauf bin ich doch eingegangen?!

 

[Caramon2]

@andy_m4 : Anstatt alles aus dem Zusammenhang zu reißen und den Rest zu ignorieren, solltest du besser versuchen es zu verstehen, um eine vernünftige Diskussion zu ermöglichen.

Ich finde deine Art ermüdend und werde nicht mehr darauf eingehen.

 

[Grimba]

Nun ja, mir geht es nun mal auf den Zwirn, wenn an Geschenken wie Linux rumgenörgelt wird.

Darf ich fragen, warum du das dann an mich richtest? Das Geschenk "Linux" stammt übrigens von Linus Torvalds und nicht von Mark Shuttleworth, bzw. Canonical/Ubuntu. Du weißt schon, das Thema worum es eigentlich ging? Ubuntu ist Teil meines Alltags seit Version 6.06. In der Uni, daheim, heutzutage nicht mehr auf privaten PCs aber im Job. Ich habe die ganzen Kontroversen, die es darum gab, alle miterlebt.

Dass einige ihrer Entscheidungen nicht gerade geschickt waren, sieht man alleine daran, wieviele davon sie selbst später wieder zurückgenommen haben, allen voran sicherlich Myr und Unity, oder die Geschichte mit der eingebauten Amazon Suche, es gab so einiges... Und derzeit erhitzt halt Snap die Gemüter. Und natürlich ist das alles etwas over the top, aber das ist halt irgendwo die Natur der Linux Community. Die kann sich ganz besonders gut über Dinge aufregen. Das muss nicht zwingend rational sein. Und wenn du der Platzhirsch bist, hast du eh reingeschissen. Es fängt schon an, wenn jemand entfernte Kritik an der eigenen Lieblingsdistribution übt, oder darüber erzählt, die er selbst nichtmal vollständig teilt. Dann geht's den ersten schon total auf den Zwirn... merkste ne?

 

[rgbs]

Einfach weniger Emotionen in die Thematik reinstecken, dann kommt man auch mit weniger Ausrufezeichen aus.

Darf ich fragen, warum du das dann an mich richtest?

Ich ging davon aus, dass Du obiges an mich gerichtet hattest, da ich hinter mein "Eben" in meinem Beitrag weiter oben mehrere Ausrufezeichen gesetzt hatte.

Das Geschenk "Linux" stammt übrigens von Linus Torvalds

Von wem das stammt ist mir schei*ß egal, ich sehe es als Geschenk an.

Gruß
R.G.

 

[sedot]

Ich kann das nicht abschätzen, da ich nicht im Thema bin. Es heißt manches soll eingestellt werden, da wäre es kein gute Idee, jetzt noch drauf zu setzen. Besser abwarten bis es sich beruhigt hat.

Ein zentraler Ort mit aktuellen Informationen ist hier zu finden; https://news.opensuse.org/
Selbstverständlich finden Diskussionen der Community auch auf anderen Plattformen statt, das offizielle Forum ist hier zu finden.
Wirklich aufregende Änderungen gibt es keine, afaik, bzw. sind diese schon seit längerer Zeit bekannt. YaST wird ersetzt, SELinux ist neu als Vorgabe (kann geändert werden), die Diskussion zu einem neuen Namen des Projektes findet schon länger statt. Mehr ist mir jetzt nicht bekannt.
Der Vollständigkeit halber, wie z.B. Tumbleweed konfiguriert wird steht Usern völlig frei, imo sind die Vorgaben schon ziemlich gut gewählt und sinnvoll, bei sehr eigenwilligen Konfigurationen steigt vermutlich die Wahrscheinlichkeit, dass es Grenzen gibt Hilfe durch die Community zu bekommen und mehr Eigeninitiative nötig ist.

 

[Deinorius]

Und seit das Problem mit dem langsameren Starten behoben wurde, sehe ich auch keinen Nachteil bei Snaps.

Du vergisst den wichtigsten Nachteil überhaupt. lsblk wird von snaps zugemüllt!

 

[rgbs]

Und wo siehst Du da ein Problem ?

Gruß
R.G.

 

[Deinorius]

Ich habe es jetzt eindeutiger gemacht.

 

[rgbs]

Alles klar!

Gruß
R.G.

 

[BeBur]

Jetzt haben Anwendungsentwickler noch mehr Paketformate zu unterstützen statt weniger.

Der Vorteil besteht darin, dass Flatpak und Co. Distributionsunabhängig funktionieren. Aber ja, komplett lösen sie das Problem nicht und können es im Zweifelsfall auch vergrößersn. Jetzt meckern Menschen nicht nur darüber, wenn es kein deb/rpm gibt, sondern auch wenn es kein snap/flatpak/... gibt .

Das Sandboxing braucht man aber höchstens für sicherheitskritische Anwendungen.

Im Gegenteil finde ich ist das ein Feature das längst überfällig ist und nur deshalb nicht existiert, weil man es nachträglich kaum ins Betriebssystem einbauen kann. Smartphones haben das ja alle, weil das von Anfang an so gebaut wurde. Windows und Linux beide nicht, sollten es aber haben. Eigentlich finde ich es krass, dass jede Applikation auf jegliche Dateien des Nutzers zugreifen kann. Das ist im Regelfall nicht notwendig und sollte nur nach Expliziter Erlaubnis möglich sein.

 

[Grimba]

Es kommt ja noch bei der Debatte erschwerend hinzu, dass die Containerformate, die gerne in einen Topf geschmissen und dann verglichen werden, sich eigentlich gar nicht wirklich vergleichen lassen, da sie unterschiedliche Probleme lösen, bzw. deshalb im Funktionsumfang extrem unterschiedlich sind, und untereinander immer wieder Funktionsbereiche haben, die gar nicht alle abdecken, also nicht gleichwertig sind. Rein auf technischer Basis kann man diese Debatte also gar nicht wirklich so führen, wie sie leider oft geführt wird.

 

[Deinorius]

Jetzt haben Anwendungsentwickler noch mehr Paketformate zu unterstützen statt weniger.

Prinzipiell haben sie die Wahl, gewisse Paketformate zu ignorieren oder gar zu boykottieren. Bestes Beispiel ist bottles, offizielle Unterstützung gibt es nur flatpak. Ich glaube, hier gibt es keine Ausnahme. Die sind von Anfrage so genervt, dass ihre Gegenmaßnahmen zunehmen. Ich kann es verstehen, obwohl ich kein Programmierer bin.
OBS wird offiziell auch nur als flatpak und als ubuntu Version (.deb, nicht snap IIRC) unterstützt.
Würden diverse maintainer die Software nicht auch noch von sich auch etwas anpassen, wäre die Arbeit der Entwickler etwas einfacher.
Eine distro-unabhängige Software-Verbreitung inkl. der Möglichkeit, dafür bezahlen zu können, ist notwendig und ich sehe derzeit nur flatpak im Vorteil. Allein schon durch das Steam Deck.

 

[GrillSgt]

[IMG]https://www.computerbase.de/forum/attachments/the-hitchhikers-guide-to-the-galaxy-the-computer-1892452125-jpg.1613971/[/IMG]

Früher wurde selbiges über Debian und / oder Slackware behauptet

 

[xpad.c]

Ich frage mich an dieser Stelle, ob in diesem Thread mittlerweile die Antwort auf die endgültige Frage nach dem Leben, dem Universum und dem ganzen Rest zu finden ist, nachdem er die 42. Seite erreicht hat.

Ja, ist sie, Du hast sie selbst gepostet.
Sie lautet, natürlich, "42".
Das Problem ist, dass leider niemand die Frage kennt...

xpad.c

 

[Caramon2]

SUSE war schon 2008 bei meinen ersten Versuchen mit Linux durchgefallen *) und auch als ich mich vor ca. 2 Jahren informiert habe, habe ich nichts gelesen, das meine Meinung geändert hätte, sondern sie wurde eher bestätigt (ohne das genauer definieren zu können: es geht mir einfach irgendwie gegen den "Strich"), aber da dort momentan sowieso einiges im Umbruch ist, wäre es jetzt sowieso nicht sehr empfehlenswert.

Offenbar muss ich meine Meinung revidieren:

Im hier geposteten Video macht es auch mich einen ziemlich guten Eindruck, so dass ich mir Slowroll holen werde, wenn das ISO von diesem Monat erscheint.

Nachtrag: Ich vermute stark, dass jedes ISO dem Stand eines der besser geprüften größeren Updates (s. u.) entspricht.

Slowroll wird zwar noch als "experimentell" gekennzeichnet, aber da es praktisch ein bewährtes Tumbleweed ist, mit etwas verzögerten Updates, damit diese besser getestet werden können, gibt es dabei nicht wirklich neues, sondern es ist nur ein angepasstes Timing.

Ich halte das jedenfalls für eine sehr gute Strategie: Bugfixes und Sicherheitspatches werden weiter sofort durchgereicht und für alles andere gibt es offenbar monatlich, besser geprüftes größeres Update. *) - Ich hoffe, ich muss das später nicht auch revidieren.

*) Ähnlich wie bei den Ubuntu-LTS-Versionen - bis auf dass es dort nur alle zwei Jahre das "größere" Update gibt und es einem Kulturschock gleicht, weil die Versionssprünge eben riesig sind.

 

[Photon]

Der Vorteil besteht darin, dass Flatpak und Co. Distributionsunabhängig funktionieren. Aber ja, komplett lösen sie das Problem nicht und können es im Zweifelsfall auch vergrößersn. Jetzt meckern Menschen nicht nur darüber, wenn es kein deb/rpm gibt, sondern auch wenn es kein snap/flatpak/... gibt .

Ich denke nicht, dass diese Art von Paketen jemals die "normalen" Paketverwaltungen ablösen werden. Die Idee der Paketverwaltung ist doch, dass Pakete Abhängigkeiten haben, die wiederum durch anderen Pakete geliefert werden. Wenn jedes Programm all seine Abhängigkeiten mitbringt, so wie Installer bei Windows das tun, dann liegen am Ende viele Abhängigkeiten mehrfach auf der Platte. Nehmen wir zum Beispiel Python oder GTK. Jedes Python-Modul müsste Python mitbringen, weil es ohne nicht verwendet werden kann, wenn ich also 10 Python-Module brauche, habe ich zehn Kopien von Python auf dem System. Oder ich habe für jedes der 20 GTK-Programme eine Kopie von GTK auf der Platte. Solange man nur 2-3 Flatpaks oder AppImages nutzt, fällt das nicht ins Gewicht, aber wenn man die distributionsabhängigen Paketverwaltungen abschaffen und durch so eine Art von "Komplettpaketen" ersetzen möchte, entsteht eine Dopplung von Daten, die das Konzept völlig ad absurdum führt.

Im Gegenteil finde ich ist das ein Feature das längst überfällig ist und nur deshalb nicht existiert, weil man es nachträglich kaum ins Betriebssystem einbauen kann. Smartphones haben das ja alle, weil das von Anfang an so gebaut wurde. Windows und Linux beide nicht, sollten es aber haben. Eigentlich finde ich es krass, dass jede Applikation auf jegliche Dateien des Nutzers zugreifen kann. Das ist im Regelfall nicht notwendig und sollte nur nach Expliziter Erlaubnis möglich sein.

Seh ich ein, das ist schon nice to have. Allerdings löst das meiner Meinung nach ein Problem, das unter Linux so gut wie nicht existiert. Das Problem ist doch, dass Software-Hersteller Daten abgreifen und diese dann verkaufen, ohne dass der Nutzer das mitbekommt. Wenn man also die Taschenlampe-App installiert und die dann Zugriff auf die Standortdaten und die Kontakte haben möchte, dann weiß man, dass das eine Datensammelmaschine ist. Da ist es natürlich gut, dass eine entsprechende Abfrage kommt und man rechtzeitig die Reißleine ziehen und der App den Zugriff auf die Daten verweigern und sie wieder runterschmeißen kann. Unter Linux ist aber der überwiegende Großteil der Software offen. Eine Software, die Daten sammelt und nach Hause schickt, wird schnell als solche entlarvt und das Desaster auf diese Art verhindert. Deshalb ist das Sandboxing auf einem offenen System meiner Meinung nach kaum relevant. Und da man für das Sandboxing einen Preis zahlen muss (die ganzen Nachteile, die ich in meinem vorherigen Post aufgeführt habe), finde ich den Deal nicht wirklich gut.

 

[sedot]

@Photon
Bitte beschäftige dich mit grundlegenden Prinzipien und der Funktionsweise von flatpaks.
https://docs.flatpak.org/en/latest/introduction.html

Das Problem ist doch, dass Software-Hersteller Daten abgreifen und diese dann verkaufen, ohne dass der Nutzer das mitbekommt.

Ja, das ist ein Problem. Es gibt noch einige mehr, wenn Software beliebig auf alle Daten zugreifen kann.

Unter Linux ist aber der überwiegende Großteil der Software offen. Eine Software, die Daten sammelt und nach Hause schickt, wird schnell als solche entlarvt und das Desaster auf diese Art verhindert.

Und wer prüft regelmäßig Software auf gewünschte und unerwünschte Funktion? Nur weil es „offen“ ist, ist längst nicht „automatisch“ gesichert, dass Software im vorgesehenen (oder erwarteten) Rahmen funktioniert. Es gibt auch bei Open Source Software regelmäßig Sicherheitslücken.

Und da man für das Sandboxing einen Preis zahlen muss (die ganzen Nachteile, die ich in meinem vorherigen Post aufgeführt habe), finde ich den Deal nicht wirklich gut.

Ja, gut, ist deine Perspektive. Ich finds schon super wenn nicht jedes beliebige Programm Zugriff auf „alles“ hat.

 

[Photon]

Bitte beschäftige dich mit grundlegenden Prinzipien und der Funktionsweise von flatpaks.
https://docs.flatpak.org/en/latest/introduction.html

Dort lese ich:

"Bundling: this allows application developers to ship almost anydependency or library as part of their applications, giving them completecontrol over their applications."

Und auch:

"Maintained platforms: Flatpak runtimes contain a collectionof common dependencies for the applications to use, easingapplication development and maintenance."

Klingt für mich genau nach dem beschriebenen Problem der Datendopplung. Oder was genau sollte ich auf der verlinkten Seite finden?

Ja, das ist ein Problem. Es gibt noch einige mehr, wenn Software beliebig auf alle Daten zugreifen kann.

Welche weiteren Probleme gibt es denn im Linux-Ökosystem mit dem status quo, also dem fehlenden Sandboxing?

Und wer prüft regelmäßig Software auf gewünschte und unerwünschte Funktion? Nur weil es „offen“ ist, ist längst nicht „automatisch“ gesichert, dass Software im vorgesehenen (oder erwarteten) Rahmen funktioniert. Es gibt auch bei Open Source Software regelmäßig Sicherheitslücken.

Sicherheitslücken gibt es immer und überall. Aber Apps, die zielgerichtet Benutzerdaten abgreifen, kenne ich in der Linux-Welt keine.

Ja, gut, ist deine Perspektive. Ich finds schon super wenn nicht jedes beliebige Programm Zugriff auf „alles“ hat.

Ich lege ja auch nur meine Perspektive dar und beanspruche nicht die absolute Wahrheit zu verkünden. Ich versuche meine Perspektive auch zu begründen. Du versuchst das im Prinzip auch, aber stellenweise kann ich dir nicht ganz folgen, weil du Andeutungen machst und sie nicht weiter ausführst. Also gerne mehr Details.

 

[sedot]

Klingt für mich genau nach dem beschrieben Problem der Datendopplung. Oder was genau sollte ich auf der verlinkten Seite finden?

Es gibt keine Datendopplung, wenn das OS die Daten nicht hat und/oder sich flatpaks Abhängigkeiten teilen.

Sicherheitslücken gibt es immer und überall.

Weshalb es clever ist bestehende Angriffsvektoren zu verringern, flatpaks sind eine Option.

 

[Photon]

Es gibt keine Datendopplung, wenn das OS die Daten nicht hat und/oder sich flatpaks Abhängigkeiten teilen.

Darüber konnte ich auf der von dir verlinkten Seite nichts finden. Wie funktioniert das genau? Gibt es dann quasi eine gemeinsame Sandbox für alle Flatpaks, die installiert sind?