Also ich würde mal sagen das jede Person irgendwo User ist, egal ob “Beruflich” oder aber auch “zu Hause”.
Auch jemand der programmiert ist auf der einen oder anderen Seite ein User, zumindest bei so etwas wie einem Betriebssystem und Programmen, bei “embedded Systems” welche man beruflich programmiert kann man allerdings darüber diskutieren.
Naja, bei Minimalsystemen am einfachsten über die Kommandozeile YaST aufrufen und nach dem Paket suchen, fällt aber leider in Zukunft weg, das ist das was ich meine, alle anderen Tools benötigen oftmals einen Displayserver.
Ansonsten ein freundliches “zypper in” und den Namen was installiert werden soll, ganz auf die schnelle “zypper in cockpit-packages*” und / oder "zypper in cockpit-packagekit*"sollte funktionieren, ist zwar nicht ganz korrekt weil ich nicht die explizite Version anziehe und einen Wildcard benutze aber die Praxis bei mir hat zumindest immer das aktuelle installiert, man muss halt aufpassen das man wirklich nur das installiert was man möchte, wenn mehrere Pakete vor dem Wildcard den gleichen Namen haben kann das übel enden weil diese mitinstalliert werden.
Na dann viel Spaß mit dem Projekt, in der Praxis wirst du merken das du dich, wenn alles läuft, in erster Linie mit Updates und gegebenenfalls mit den sich daraus notwendigen Änderungen der Konfiguration beschäftigst, glücklicherweise ist das sehr selten der Fall das sich etwas grundlegendes ändert.
Anstatt Wildcards bei der Installation zu verwenden, sollte man einfach eine Paketsuche durchführen und dann das korrekte Paket installieren. Simples Beispiel gefällig? Einfach mal auf den Suchbegriff achten den ich eingebe und was das Resultat ist:
ich@laptopneu:~> zypper search ckpi
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Summary | Type
---+--------------------------+------------------------------------------------------------------------------+-------
| cockpit | Web Console for Linux servers | Paket
| cockpit | Pattern for Cockpit, a web based remote system management interface | Schema
| cockpit-bridge | Cockpit bridge server-side component | Paket
| cockpit-devel | Development files for for Cockpit | Paket
| cockpit-doc | Cockpit deployment and developer guide | Paket
| cockpit-kdump | Cockpit user interface for kernel crash dumping | Paket
| cockpit-machines | Cockpit user interface for virtual machines | Paket
| cockpit-networkmanager | Cockpit user interface for networking, using NetworkManager | Paket
| cockpit-packagekit | Cockpit user interface for packages | Paket
| cockpit-packages | A cockpit module for (un)installing packages | Paket
| cockpit-podman | Cockpit component for Podman containers | Paket
| cockpit-repos | A Cockpit module for managing system repositories | Paket
| cockpit-selinux | Cockpit SELinux package | Paket
| cockpit-storaged | Cockpit user interface for storage, using udisks | Paket
| cockpit-subscriptions | Cockpit module for managing and registering subscriptions | Paket
| cockpit-system | Cockpit admin interface package for configuring and troubleshooting a system | Paket
| cockpit-tukit | Cockpit module for Transactional Update | Paket
| cockpit-ws | Cockpit Web Service | Paket
| cockpit-ws-selinux | SELinux security policy for cockpit-ws | Paket
| microos_cockpit | Webbasierte Remote-Systemverwaltung | Schema
| patterns-cockpit | Pattern for Cockpit, a web based remote system management interface | Paket
| patterns-microos-cockpit | Webbasierte Remote-Systemverwaltung | Paket
ich@laptopneu:~>
Dann kann es auch zu keinen Schreibfehlern kommen, da man im Terminal ganz einfach copy&paste machen kann.
Mit zypper wird immer die aktuellste Version installiert. Nur wenn du eine ältere Version installieren willst (downgrade) musst du explizit die gewünschte Version angeben.
@shundhammer & rawar: Danke für die Info. Ich nutze - gezwungenermaßen (siehe unten) - Wayland. Witzig war, dass man in den Systemeinstellungen auch unter Wayand noch bis vor wenige Wochen den Fensterheber auswählen konnte. Und: Er funktionierte teilweise. Unter anderem funktionierte er bei Yast (es gab noch wenige andere Programme), allerdings auch dort noch eingeschränkt. Es blieb immer der Fensterrand (und natürlich die Titelleiste, was ja Sinn des Fensterhebers war) sichtbar. Ich hatte das hier im Forum übrigens mal als Frage eingestellt, leider kein Foto beigefügt.
Deswegen hatte ich nie geprüft, ob es unter x11 funktioniert, aber auch deswegen, weil x11 seit einiger Zeit bei mir nicht funktioniert - und ich, da x11 ja “tot” ist, auch keine Lust mehr hatte, x11 wieder funktionabel zu machen.
@shundhammer: Mit Myrlyn kann ich mehr als leben, gerade auch mit der Übersicht über die Transaktionen. Bei Yast war es früher ja auch so, dass man - ähnlich wie bei zypper - den genauen Installationsverlauf eines jeden Programms verfolgen konnte. Plötzlich war die Funktion weg. Ich habe für denjenigen, der das wegprogrammiert hatte, extra eine kleine Puppe gebastelt, die ich jeden Abend mit Nadeln durchlöchert hatte !
Schön also, dass jedenfalls das Update aus Yast gerettet und aktualisiert wurde. Danke für die Arbeit und die damit verbundenen Mühen (es fehlt noch die deutsche Übersetzung ; mach’ mal hinne! ).
Ich will zugeben, dass ich noch nicht mal wusste, dass Yast mit Qt6 nicht kann. Na dann: Möge es sterben.
Damit ist alles gesagt. openSUSE hat mit Tumbleweed eine sehr brauchbare Distribution geschaffen, die ratz fatz aktualisiert werden kann. Es kränkelt aber immer noch etwas. Schuld daran sind die vielen unnötigen und teilweise unsinnigen Abhängigkeiten. Fedora ist in dieser Hinsicht Tumbleweed voraus, zum Beispiel plasma6-nm und kf6-kwallet. Letzteres ärgert gerne den Benutzer. Wird es deinstalliert verschwindet auch ersteres:
erlangen:~ # zypper -n rm -D kwalletd6
Reading installed packages...
Resolving package dependencies...
The following 6 packages are going to be REMOVED:
kwalletd6 kwalletd6-lang patterns-kde-kde patterns-kde-kde_plasma plasma6-nm plasma6-nm-lang
The following 2 patterns are going to be REMOVED:
kde kde_plasma
6 packages to remove.
Package install size change:
| 0 B required by packages that will be installed
-11.2 MiB | - 11.2 MiB released by packages that will be removed
Backend: classic_rpmtrans --dry-run
Continue? [y/n/v/...? shows all options] (y): y
erlangen:~ #
Bei fedora42 kann man kwalletd6 deinstallieren und plasma6-nm behalten. Den vielen Diskussionen in diesem Forum entnehme ich, dass es immer gute Gründe gibt, warum etwas nicht funktioniert. Damit vertreibt openSUSE viele Benutzer. Der bescheidene Marktanteil spricht dafür.
Apropos: April Fools’ Day. Bei diesen Umständen sagen sich viele: Das muss ich mir nicht antun. Distribution XXX Beta macht das ohne weiteres.
Jeder ist seines Glückes Schmied (sagt der Volksmund).
Bei einhundert, unter Distrowatch.com gelisteten Distributionen sollte doch jede(r) etwas für sich finden können. Und wenn nicht, gibt es auch noch eine Reihe kommerzieller Anbieter für Betriebssysteme.
Allerdings befürchte ich, dass man, egal welches Betriessystem man letztendlich auswählt, ohne “Mitdenken” und ohne ein gewisses Maß an Eigeninitiative (z.B. lesen von Dokumentation, verwenden einer Internet-Suchmaschine, Systemwartung und -pflege, Datensicherungen, usw.) mit keinem Betriebssystem wirklich glücklich werden wird.
Ich denke wir haben hier einen ganz guten Grundstein welche eine der ältesten und stabilsten Distros ist, sicherlich nicht perfekt, aber was ist perfekt.
Dazu kommt das sie eine der flexibelsten Distros ist, falls es etwas im “Standard” nicht gibt gibt es noch den tollen Buildservice mit vielen anderen Repositories welcher freundlicherweise von vielen anderen Personen, oft auch in der Freizeit, gefüllt wird, es gibt eigentlich nichts was es nicht gibt.
Und wenn es dort wirklich mal nichts gibt kann man zur Not noch z.B. Snap und Flatpak Pakete installieren, ich kenne nur wenige Distros welche so flexibel sind, allerdings teste ich auch nicht explizit alle.
Davon unabhängig kann man natürlich noch ganz spezielle Paketmanager, wie z.B. den Paketmanager von Python, nutzen.
Und wenn das auch nicht das gesuchte hergibt kann man auch noch ein AppImage nehmen, wenn es das denn gibt.
Und ich rede hier noch nicht einmal über die leichte Installation und Integration von Programmen der “Fenstermarke”, gerade für Gamer als letzter “Rettungsanker” gibt es dann z.B. noch ProtonPlus, auch mit Integration in die App der großen “Dampfmarke”.
Leider gibt es, zumindest meines Wissens, nichts um Pakete der “Apfelmarke” zu installieren.
Wenn man sich in andere Distros einarbeiten muss merkt man ganz schnell das nicht alles Gold ist was glänzt, diese Erfahrung muss man aber meistens selbst machen.
Also ich möchte ja nicht über andere Distros diskutieren, aber z.B. plasma6-nm ist unter anderem für die Verwaltung von WLAN’s zuständig und KDE speichert dann z.B. die Zugangsdaten gesichert in kwallet, macht also schon irgendwo Sinn das man beides haben muss.
Also ich finde es schon mal gut, dass Myrlyn, bei expliziter Suche, auch *-devel-Pakete findet, selbst wenn die Option “Options | Show -devel Packages” nicht angehakt ist … ich mein nur, falls das schon jemals jemandem aufgefallen ist
Bei Tumbleweed überwiegen eindeutig die Vorteile. Am bequemsten sind die RPMs. Allerdings hat sich das nicht so weit herumgesprochen. Ich zahle für jAlbum. Die hatten auf ihrer Downloadseite ursprünglich gar kein Repository. Sie haben es erst auf meine Nachfrage hin eingerichtet.
Es ist sinnvoll, dass man beides haben kann. Dass man das eine nicht ohne das andere installieren kann macht mir einigen Ärger und auch Arbeit:
Es gibt auch Benutzer, die ihr eigenes Repository warten, weil immer wieder unnötige Probleme auftauchen, z.B.@SquarePeg79 :
Mit diesem Repository stellt @SquarePeg79 sicher, dass bei von ihm benutzten Programmen die unnötigen Probleme der von openSUSE zur Verfügung gestellten Version umgangen werden.
“Bei Tumbleweed überwiegen eindeutig die Vorteile.”
Finde ich auch das bei Tumbleweed die Vorteile überwiegen, gerade mit “slowroll” hat man einen schönen Mittelweg zwischen neu und nicht evtl. zu viel Arbeit.
“Dass man das eine nicht ohne das andere installieren kann”
Das ist halt eine andere Facette von dem das immer mehr Funktionen und Einstellungen in die GUI’s wandern.
Liegt das evtl. an einer “reinen” KDE Installation und genau diesen Trayapplet?
Wenn ich das richtig sehe gibt es noch ein NetworkManager-applet als GTK+ Tray Applet.
@ karlmistelberger , @ Sauerland
“ihr eigenes Repository warten”
Das hängt nicht unbedingt mit Problemen zusammen, da gibt es auch Sachen welche, warum auch immer es gibt viele Gründe, nicht in den offiziellen Repos sind oder aber auch wenn User bestimmte Versionen oder alte Versionen benötigen, das kann auch eine elegante Möglichkeit sein doch noch Programme zu nutzen welche offiziell nicht mehr weiterentwickelt werden.
Sicherlich sind diese Repos teilweise mit Vorsicht zu genießen weil halt oftmals z.B. librarys darin sind welche auch im Hauptrepository sind, teilweise sind sie aber auch, neben den eigenen Build eine elegante Möglichkeit an Programme und Treiber zu kommen welche nicht oder noch nicht in den offiziellen Repos sind.
Sicherlich kann man sich auch Probleme aufhalsen aber ich habe damals hier z.B. Treiber gefunden welche auf dem “großen Fenstersystem” nicht richtig liefen, noch nicht im offiziellen Build waren, ich in anderen Distris nicht gefunden habe und mich Schlussendlich zum kompletten Umstieg auf openSuse bewogen haben.
Ja, es kann z.B. bei einem Systemupdate fragen geben welche Version man verwenden möchte, erst recht wenn man mit x Zusatzrepos arbeitet, teilweise ist auch etwas “Handupdate” gefragt und es ist mehr Wartungsaufwand ab und zu mal zu schauen ob sich ein Repository “erledigt” hat aber wirkliche Problem hatte ich noch nicht und bei einem seit Jahren laufenden System ist immer etwas Handarbeit gefragt, nicht immer werden “unnütze” Pakete automatisch deinstalliert, erst recht nicht wenn man “kommerzielle Pakete” mit einem “Sideload” nutzen muss, ich kenne kein System wo das nicht der Fall ist.
Immerhin gibt es ja die Möglichkeit nach “verwaisten” oder “nicht nötigen” Paketen zu suchen und etwas aufzuräumen, dazu muss man allerdings schon tiefer im System stecken um sich nicht etwas zu zerschießen.
Ich habe mich aber ehrlicherweise noch nicht damit auseinandergesetzt wie welche Versionen in die offiziellen Repos kommen und auch nicht wie man mit dem Buildservice arbeitet, ich habe immer auf dem Rechner kompiliert.
Aber der Buildservice ist schon eine tolle Sache, nicht zu vergessen das über den Buildservice auch Packages für andere Distris als SuSE, z.B. Debian oder Ubuntu, gebaut werden.
Ja, so sollte es auch sein. Suchst Du aber explizit nach einem “*-devel”-Paket, wird es Dir auch angezeigt, wenn die Option nicht angehakt ist. Also Option abhaken, Suche nach libbtrfs-devel, das Paket wird Dir angezeigt. Das war der Anwendungsfall.
Das empfohlene Repository home:Sauerland:hardware war ganz und gar nicht hilfreich. Ich lerne am liebsten aus den Fehlern anderer. Hier habe ich aus einem eigenen Fehler gelernt. Ich verspreche, dass ich dieses Repository nicht mehr anrühren werde.
!
; mach’ mal hinne! 
).
.