ubuntuusers.de

Was ich absolut nicht verstehe:

Jedes Android-Gerät zeigt doch, wie so was zeitgemäß geht. Eine neu installierte App listet beim ersten Start auf, was sie an Berechtigungen benötigt und wofür, dann kann man diese Berechtigungen einzeln erteilen.

Wieso machen Snaps das nicht? K3B könnte doch auch beim ersten Start sagen: „Ich brauche die Berechtigung, auf optische Laufwerke zuzugreifen“, die dann mit einem Klick erteilt werden kann. Anderes Beispiel: Meine erste Snap-Kollision war ein Thunderbird, der auf einen Mailaccount, der auf einem Veracrypt-Volume lag, nicht mehr zugreifen konnte. Der hätte doch auch einfach fragen können: „Sie haben einen Mailaccount auf einem externen Volume. TB die Berechtigung erteilen, auf externe Volumes zuzugreifen?“

Stattdessen passiert einfach GAR NIX, es fühlt sich an wie kaputt, der Nutzer muss sich schlau lesen und dann im Terminal kryptische Befehle eintippen, von denen er nur hoffen kann, dass es die richtigen sind. So was gibt’s in der Microsoft-Welt seit 30 Jahren nur noch in speziellen Ausnahmefällen, so was gab’s in der Apple-Welt glaubich überhaupt nie. Das will keiner!

Solange Snap in dieser Hinsicht nicht benutzerfreundlich wird, selbst mitdenkt und nötige Berechtigungen vorschlägt und einholt, statt einfach gar nichts zu machen und den Nutzer ratlos stehen zu lassen, sehe ich da schwarz.

--ks

@Kreuzschnabel: Kannste vergessen, das Universum gewinnt immer! 😇

Kreuzschnabel schrieb:

Wieso machen Snaps das nicht? K3B könnte doch auch beim ersten Start sagen: „Ich brauche die Berechtigung, auf optische Laufwerke zuzugreifen“, die dann mit einem Klick erteilt werden kann.

Da müssten dann die Betreuer, die das Snap erstellen, den Quellcode entsprechend abändern.

Die Software an sich kann nicht wissen, wie sie installiert wurde.

Anderes Beispiel: Meine erste Snap-Kollision war ein Thunderbird, der auf einen Mailaccount, der auf einem Veracrypt-Volume lag, nicht mehr zugreifen konnte. Der hätte doch auch einfach fragen können: „Sie haben einen Mailaccount auf einem externen Volume. TB die Berechtigung erteilen, auf externe Volumes zuzugreifen?“

Thunderbird weiß nicht, wo ein Pfad hinführt. Und es ist auch nicht das Problem der Thunderbird-Entwickler, dass das jemand in einer "abgeschotteten" Umgebung installiert. Insofern macht da Snap genau das, was es soll.

Ob die meisten User das so wollen ist eine andere Frage, aber dafür interessiert sich Canonical dank des dort vorhandenen NIH-Syndroms traditionell nicht.

Ich habe die Erwartungen formuliert, die ein heutiger Normalanwender an ein aktuelles System stellt. Wie das technisch gelöst wird, ist ihm schnuppe, aber solange es nicht gelöst wird, wird er das System als nicht benutzbar beiseite schieben.

Ich begreife weiterhin nicht, wieso bei der Entscheidung, Snaps mit all ihren Restriktionen einzuführen, daran nicht gedacht wurde.

So fühlt sich ein aktuelles Ubuntu für einen technisch wenig versierten Nutzer an wie für einen Autofahrer ein Neuwagen, bei dem man erst unter die Haube kriechen, ein paar Schrauben setzen oder Kabel neu verlegen muss, bevor man damit auch nur vom Händler nach Hause fahren kann. Keiner würde so was kaufen, jeder Test würde das Produkt in der Luft zerreißen.

--ks

Kreuzschnabel schrieb:

So was gibt’s in der Microsoft-Welt seit 30 Jahren nur noch in speziellen Ausnahmefällen

Ist das so? Also das mit den speziellen Ausnahmefällen? Dann kommen die aber ziemlich häufig und mit ziemlich alltäglicher Software vor.

Gerade erst gestern wieder mit dem aktuellen von Nextcloud (3.16.1). Der Client (3.16.0) wollte unter Windoof 11 Pro ein Update. Also gemacht. Was passiert? Client (3.16.1) startet nicht mehr. Dem fehlt nun angeblich zum Start die vcomp140.dll. Die ist aber vorhanden. Genau dort wo der Client (3.16.0) die auch schon finden konnte. Also bei https://help.nextcloud.com/ gepostet. Lösungsvorschlag dort: C++ installieren - LOL.

Also wieder zurück zu Client (3.16.0) und im Client die Updates deaktiviert, damit der nicht gleich wieder 3.16.1 zieht und installiert.

Edit: und nach jeder Installation eines Nextcloud Clients war erst einmal ein Neustart diese beschissenen Betriebssystem erforderlich.

adelaar schrieb:

Gerade erst gestern wieder mit dem aktuellen von Nextcloud (3.16.1).

Was du beschreibst, klingt für mich wie ein Bug in dieser Version. Es geht mir nicht um Bugs. Es geht mir darum, dass das snap-System (mein Eindruck) von vornherein so konzipiert ist, dass es nur das Notwendigste an Berechtigungen hat und jede darüber hinausgehende Funktionalität vom Benutzer händisch eingerichtet werden muss, und auch dafür findet der Benutzer keine leichte Anleitung, sondern muss sich erst mal Hintergrundwissen anlesen.

Das ist nicht das, was Anwender seit vielen Jahren von einer Anwendungssoftware erwarten. Das Ding soll notwendige Konfigurationen im Dialog selbst vornehmen. Und solange Snap das nicht macht, ist es an seiner Zielgruppe vorbei konzipiert.

Bevor das wieder abschweift, bleiben wir doch beim konkreten Beispiel K3b: Hier könnte doch in snapd hinterlegt sein, dass dieses Paket sinnvollerweise Zugriff auf ein optisches Laufwerk haben sollte, und bei der Installation oder beim ersten Start könnte diese Berechtigung abgefragt und bei Klick auf „Ja“ gesetzt werden. Dazu muss die Anwendung selbst gar nicht wissen, dass sie als Snap installiert ist, solange das Snap-Framework das weiß und den Benutzer fragen kann.

--ks

@Kreuzschnabel

Was deine Kritik an snaps angeht, so bin ich ganz bei dir. Habe diesen Mist ja nicht grundlos aus meinen Xubuntus vollständig entfernt.

Und was K3b angeht: es mag sicherlich auch gute Gründe geben, snaps eben einzupferchen so dass die eben nur in ihrem Confinement laufen und nix außerhalb erreichen können. Dann allerdings sollte man so etwas wie K3b gar nicht erst als snap anbieten. Macht unter diesen Prämissen einfach keinen Sinn.

Was mich an deinem Beitrag mit Bezug auf andere Betriebssysteme gestört hat, war dass es sich für mich wie eine Lobhudelei auf ein OS anhörte, dessen Entwickler es nicht einmal schaffen, dass man eine Simple App aus einer *.msi-Datei weder installieren noch deinstallieren kann, ohne das System neu zu booten. So oft wie ich gestern dieses OS wegen des Bugs neu starten musste, boote ich einen Xubuntu-Desktop nicht in einem Monat. Wozu gibts schließlich hibernate!?

adelaar schrieb:

Also wieder zurück zu Client (3.16.0) und im Client die Updates deaktiviert, damit der nicht gleich wieder 3.16.1 zieht und installiert.

Edit: und nach jeder Installation eines Nextcloud Clients war erst einmal ein Neustart diese beschissenen Betriebssystem erforderlich.

Mit W10 hab ich den NC-Client 3.16.1 installiert und kein Problem damit bisher gehabt. Den Reboot verlangt 'angeblich' der Installer den NC an der Stelle verwendet, so teilten mir das mal Entwickler auf Nachfrage mit. Da gab es vor ein oder zwei Jahren schon mal richtig Ärger. Nach der Installation wurde neu gestartet, egal was der User ausgewählt hatte.

BTW: Und es geht auch ohne Reboot den Agent zu installieren. ☺

Kreuzschnabel schrieb:

Bevor das wieder abschweift, bleiben wir doch beim konkreten Beispiel K3b: Hier könnte doch in snapd hinterlegt sein, dass dieses Paket sinnvollerweise Zugriff auf ein optisches Laufwerk haben sollte, und bei der Installation oder beim ersten Start könnte diese Berechtigung abgefragt und bei Klick auf „Ja“ gesetzt werden. Dazu muss die Anwendung selbst gar nicht wissen, dass sie als Snap installiert ist, solange das Snap-Framework das weiß und den Benutzer fragen kann.

Was sollte das bitte in Snapd? Jeder Ersteller eines Snaps, das über den Snap-Store angeboten wird (da kann im Prinzip jeder alles ungeprüft hochladen, das ist also nichts als völlig ungeprüfte Fremdquellen, die bereits mehrfach dort veröffentlichten Programme, die ganz nebenbei noch Crypto-Mining für deren Ersteller im Hintergrund laufen ließen, sind da schöne Beispiele) kann da vorab einstellen, welche Berechtigungen das Programm braucht. Wenn der Snap-Ersteller von "KDE" (denn das Snap kommt nicht von Canonical) meint, dass k3b keinen Zugriff auf ein optisches Laufwerk braucht, dann gibt er das eben auch so an.

Soll jetzt der Maintainer von snapd täglich prüfen, ob da irgendjemand irgendein Snap hochgeladen hat, bei dem die vorgegebenen Berechtigungen murks sind?

Kreuzschnabel schrieb:

... Wieso machen Snaps das nicht? K3B ..., sehe ich da schwarz.

Berechtigte Frage ... bitte kontaktiere den verified publisher:

• https://snapcraft.io/publisher/kde

• also: https://kde.org/support/

Das feedback würde mich auch interessieren ... Danke!

adelaar schrieb:

Lösungsvorschlag dort: C++ installieren - LOL.

Soso. Wird eine existente DLL nicht gefunden, (re)registriert man diese mit regsvr32, also mit Boardmitteln. Es geht auch nicht um C++, sondern schlicht und ergreifend vcredist, das man selbstverständlich installiert haben muß, wenn Software darauf aufsetzt. Das sind 13.3 MiB x86 und 24.5 MiB x64.

von.wert schrieb:

adelaar schrieb:

Lösungsvorschlag dort: C++ installieren - LOL.

Soso. Wird eine existente DLL nicht gefunden, (re)registriert man diese mit regsvr32, also mit Boardmitteln. Es geht auch nicht um C++, sondern schlicht und ergreifend vcredist, das man selbstverständlich installiert haben muß, wenn Software darauf aufsetzt. Das sind 13.3 MiB x86 und 24.5 MiB x64.

Das kann man mittels Winetricks auf Linux sehr bequem erledigen, wenn unter Wine irgendwelche Windows Spielchen diese DLLs und die Registrierung in der Registry brauchen. 😎
Ein GUI-Werkezug gibt es auch, nennt sich q4wine.

Möglicherweise könnte der Weg so ähnlich bei Snaps von übermotivierten Dritten gestaltet werden, mit Werkzeugen, die Snap Schnittstellen, wie Interfaces, Slots und Plugs N00b-verwaltbar machen. Womöglich sogar mit GUI. Ich schätze aber mal, dass das Universum trotzdem gewinnt. 😇

von.wert schrieb:

Danke für deine erhellenden Informationen. Ich habe letztmalig Windows 7 vor 12 oder 13 Jahren genutzt. Erst seit weniger als einem Monat habe ich nun wieder Windows 11 installiert. Da fehlt mir vieles an Wissen zu Windows.

Soso. Wird eine existente DLL nicht gefunden, (re)registriert man diese mit regsvr32, also mit Boardmitteln.

Ich denke nicht, dass das die Lösung ist, denn der NC-Client 3.16.0 findet die dll ja, nur eben nicht der NC-Client 3.16.1. Den NC-Client 3.16.0 hab ich ja nun wieder laufen, zumindest als Übergangslösung.

Es geht auch nicht um C++, sondern schlicht und ergreifend vcredist, das man selbstverständlich installiert haben muß, wenn Software darauf aufsetzt.

Das werde ich mal versuchen, kann ja nicht schaden. Der Lösungsvorschlag aus https://help.nextcloud.com lautete jedoch einfach nur:

Installing C++ fixed it for me, and still working after a reboot

Das liest sich für mich wie "mit Kanonen auf Spatzen schießen".

Nachtrag und Dank an von.wert: die Installation von vcredist war die Lösung. Daher vielen Dank für den Tipp.

Kurze Zwischenfrage: Ich habe mir snapcraft.io nur mal kurz angeschaut und wollte fragen ob dort auch eine Art Build-Farm dahinter geklemmt ist, die dann ähnlich wie der "OpenBuildService" von SUSE dann quasi die neuen snaps dann kompiliert und "paketiert".

Also in dem Sinne, dass man das snap ggf. auch mit den Rechenleistungen auf den Servern von Canonical kompilieren und danach kann? Ich verstehe die Idee des "AppStores" seitens Canonical schon aber muss man ggf. die Snaps zu Hause bauen und dann hochladen?

https://snapcraft.io/docs/snapcraft

Snapcraft builds, packages and publishes snaps. It’s available for Ubuntu, many other Linux distributions, and macOS, and runs from the command line.