Ja, klar; aber vielleicht hat der Benutzer ja einen anderen Default-Browser als Firefox. xdg-open funktioniert auch mit Chromium oder Opera oder was auch immer im Desktop konfiguriert ist. 
2 Likes
Einen spezifischen Browser im Desktop File vorgeben ist eine sehr schlechte Idee. So etwas sollte immer Anwendungs (Browser) neutral angelegt werden.
1 Like
Die Lizenzkosten werden der wohl nicht pro Rechner bezahlt, mit einer Lizenz können wohl mehrere Rechner betrieben werden beim SLED !
Ich glaube eine SLED Lizenz kann für 10 rechner benutzt werden .
Warum glauben, wenn man auf der Homepage von SUSE und in den Subscription Terms die korrekten Bedingungen nachlesen kann. Die Lizenz gilt immer nur für einen Rechner bei SLED.
1 Like
Brauchst ja nicht nutzen.
Und ich hatte das in ein paar Minuten erledigt.
Was himgegen meiner Meinung nach in leap16 seit anbeginn fehlt.
1 Like
Dass JA ist schon klar .
Ich nutze seit über 5 Jahren Tumbleweed, update das einmal alle 4 Wochen. Es gab ein Problem, aber das ist so lange her, dass ich vergessen habe, was es war. Allerdings auf gut kompatibler Intel/Intel Hardware. Dann wollte ich auf slowroll, habe das opensuse-migration tool mit zypper installiert. Lief alles toll bis zum ersten Update: Problem mit X/Plasma. Zurückmigriert nach tumbleweed und alles lief wieder gut. Tumbleweed hat auch noch Yast. Ich empfehle allerdings das System mit dem tumbleweed script zu verwalten (zypper install tumbleweed-cli). Das kann easy rollback etc.
1 Like
Wie wäre es mit LMDE7, Linux Mint Debian Edition?
Mint habe ich noch nicht ausprobiert. Nach meinen Informationen ist die KDE Unterstützung da ja auch eher dürftig bis nicht vorhanden. Daher kommt es auch nicht in Frage.
1 Like
In der Theorie vielleicht. In der Praxis scheint mir Slowroll eher mehr Probleme als Tumbleweed zu machen. Hatte es vor längerem mal in der VM probiert und irgendwann gab es Probleme beim Update. Habe jetzt nochmal Tumbleweed, Slowroll und Kubuntu (Entwicklerversion 26.04) installiert. Und welches macht gerade als einziges Probleme beim Update? Leider Slowroll. Kann Python 3.13 Pakete nicht installieren, mit der Meldung:
Installation von libpython3_13-1_0-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.
Genau auf solche Dinge habe ich eher weniger Lust. Schade, von der Idee her würde mir Slowroll gefallen, aber es scheint ihm die nötige Aufmerksamkeit zu fehlen. Wer weiß ob es jemals aus dem Beta Stadium raus kommt.
1 Like
Bitte immer die komplette Eingabezeile incl. der kompletten Ausgabe posten.
Denn es könnte ja auch an einem Server in der Arktis liegen, das dieser ein Problem hat…
1 Like
Stimmt natürlich:
zypper up
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Die folgenden 6 Paketaktualisierungen werden NICHT installiert:
gegl-0_4 gegl-0_4-lang libgegl-0_4-0 virtualbox-kmp-default xdg-desktop-portal-kde6 xdg-desktop-portal-kde6-lang
Die folgenden 6 Pakete werden aktualisiert:
libpython3_13-1_0-x86-64-v3 python313-base python313-base-x86-64-v3 python313-curses python313-dbm python313-x86-64-v3
6 Pakete werden aktualisiert.
Größe des Pakets zum Herunterladen:
| 14,0 MiB Gesamtpaketgröße
0 B | - 14,0 MiB bereits im Cache
Änderung der Installationsgröße des Pakets:
| 49,0 MiB erforderlich für Pakete, die installiert werden sollen
970,0 KiB | - 48,0 MiB freigegeben von Paketen, die entfernt werden sollen
Backend: classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
Im Cache libpython3_13-1_0-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (1/6), 2,0 MiB
Im Cache python313-base-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (2/6), 9,1 MiB
Im Cache python313-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (3/6), 435,0 KiB
Im Cache python313-dbm-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (4/6), 414,9 KiB
Im Cache python313-curses-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (5/6), 443,8 KiB
Im Cache python313-base-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64.rpm (6/6), 1,6 MiB
Überprüfung auf Dateikonflikte läuft: ....................................................................................................................................[fertig]
warning: rpmpkg: detected non-zero blob, trying auto repair
error: libpython3_13-1_0-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64: install failed
error: libpython3_13-1_0-x86-64-v3-3.13.9-3.1.x86_64: erase skipped
(1/6) Installieren: libpython3_13-1_0-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64 ........................................................................................[Fehler]
Installation von libpython3_13-1_0-x86-64-v3-3.13.11-1.0.2.1.sr20251204.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.
Abbrechen, wiederholen, ignorieren? [a/w/i] (a):
Irgendwie das RPM Paket defekt?
1 Like
Das ist ein Basisfehler der auf jeder Distribution auftreten kann und auch tut. Deine Paketdatenbank ist inkonsitent. Das hat nix mit Slowroll zu tun.
Einfach
sudo rpm --rebuilddb
Zur Not noch ein
sudo zypper clean -all
hinterher.
Und dann Slowroll gescheit mittels sudo zypper dup upgraden (so wie dokumentiert). Genauso wie auch Tumbleweed (ebenfalls dokumentiert).
2 Likes
Danke. Hat funktioniert.
Eigentlich hätte ich allerdings erwartet, dass die Aktualisierung mittels Discover funktioniert. Diese hatte schon mit dem Fehler nicht funktioniert.
Mittels zypper direkt war nur der zweite Versuch.
Ja ich kann mich erinnern dass ich schon mal eine inkonsistenten RPM Datenbank hatte. Die Regel ist es allerdings nicht. Keine Ahnung wie es dazu kam, wüsste nicht irgendetwas besonderes bzgl. Installation von Paketen / Updates gemacht zu haben.
1 Like
Discover würde ich nie zum Updaten benutzen, das kann sogar bei Leap Probleme bereiten.
zypper up funktioniert bei Slowroll/Tumbleweed auch vorübergehend aber irgendwann hat sich so viel angestaut, das der User eingreifen muss.
Besser ist bei Tumbleweed von vornherein immer zypper dup zu benutzen, da kann es aber auch mal Probleme zwischen Packman und openSUSE geben.
Die rpm Datenbank hat ab und an Probleme aber nach einem rebuilddb funktioniert das sofort wieder.
Den Eindruck habe ich auch. Tumbleweed auf dem Unaussprechlichen Host wird täglich aktualisiert und höchstens alle Jahre einmal geht was schief. Gestern fror der Bildschirm ein:
erlangen:~ # journalctl -q -g BUG:
Jan 10 07:19:41 erlangen kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [systemd-logind:1001]
Jan 10 07:20:09 erlangen kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 53s! [systemd-logind:1001]
Jan 10 07:20:37 erlangen kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 79s! [systemd-logind:1001]
Jan 10 07:21:05 erlangen kernel: watchdog: BUG: soft lockup - CPU#0 stuck for 105s! [systemd-logind:1001]
Jan 10 11:58:01 erlangen kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [watch_displays:1969]
Jan 10 11:58:29 erlangen kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 53s! [watch_displays:1969]
Jan 10 11:58:58 erlangen kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 79s! [watch_displays:1969]
erlangen:~ #
Der 6.18.2-1.1 war nicht zu gebrauchen. Ich bootete einfach den 6.18.1-1.1. Heute ist der 6.18.3-1.1 da und der läuft wieder.
Dann schau’ dir mal an, was das wirklich heißt:
Support für SLES-15 SP3 ist gerade mal Ende 2025 ausgelaufen. Das ist im Juni 2021 herausgekommen, basierend auf SLES-15 GA vom Juni 2018 (!).
Seit SLES-15 SP3 sind noch SP4, SP5, SP6, SP7 herausgekommen; jedes Jahr ein Service-Pack. SLES-15 SP7 LTSS (vom 31.10.2025) wird noch bis 31.07.2034 (!) supported; ebenso basierend auf dem jetzt schon steinalten SLES-15 von 6/2018.
Falls du das Know-How und die Lust hast, derartige Antiquitäten noch die nächsten 8 Jahre zu supporten, kann ich dir nur empfehlen, dich zu bewerben. Bis dahin sind der alte Compiler (GCC-7) und binärkompatible Bibliotheken, das alte X11, das alte Qt, der alte YaST2 zu supporten; denn genau das ist es, was die Geschäftskunden bezahlen.
Sie wollen ein stabiles System, für das sie ihre eigene Software bauen können und die Software von Drittanbietern laufen lassen können, auch wenn diese Drittanbieter in der Zwischenzeit nicht mehr existieren.
Da sind 2000,- CHF nicht zuviel; das ist Schmerzensgeld für die Entwickler. Da sind immer wieder Security-Fixes auf diese alten Versionen zurückzuportieren, die in neueren Versionen offensichtlich wurden. Der Kernel von anno dazumal muß mit der aktuellen Hardware laufen, zumindest für zertifizierte Server-Hardware im 19"-Rack in Rechenzentren.
Ein normaler Benutzer braucht all das nicht; Geschäftskunden schon.
1 Like
Die preise für SUSE LINUX Enterprise DESKTOP (SLED) sind billiger als die Preise für SUSE LINUX Enterprise SERVER (SLES) .
Der Preis für SUSE LINUX Enterprise DESKTOP (SLED) ist 140 EURO fürs Jahresabo oder 390 EURO fürs Dreijahresabo !
Der Jahresabopreis für SUSE LINUX Enterprise SERVER (SLES) ist bedeutend teuerer als SLED mit Kaufpreisen über 900 EURO und mehr aufwärts, dass ist aber ein anderes SUSE LINUX-produkt .
Für privatpersonen Nutzer sind die Kostenlosen OpenSUSE LINUX Softwareprodukte und dass billigere SUSE LINUX Enterprise DESKTOP (SLED) Abo-Softwareprodukt viel besser geeignete, weil diese bessere Multimedia-Fährigkeiten haben als die SLES-produkte !
Abgesehen davon sind auch die Kaufpreise vom MICROSOFT für WINDOWS SERVER 2025 sogar Viel mehr Teuerer als die preise von SUSE LINUX SERVER-produkten .
WINDOWS SERVER 2025 kostet sogar viel mehr so viel wie ein Volkswagen Automobil 25000 Euro ab den ersten WINDOWS SERVER-Computerssystem, für weitere Windows Server 2025 Systeme sind die Kosten dann 5000 Euro bis 25000 Euro je nach dem welche Sverver-Hardware benutzt wird dagegen sind die Kaufpreise von SUSE Serverprodukten noch billig im zu MICROSOFT .
Ausserdem gibt es beim Microsoft immer wieder Überlegungen auch dass ganz normale Desktop-PC Windows 11, Windows 12 zukünftig als Monatliche Abo-Software bezahlen zulassen jeden Monat einen Kaufpreis der Vergleichbar ist zum des SLED-Jahresabos.
Jeden Monat Geld-Betrag bezahlen bei MICROSOFT, für den man bei SUSE SLED ein ganzes Jahr bekommt. Wohlgemerkt für nur einem Monat anstatt ein ganzes Jahr.
200 EURO für einen 1 Monat MS WINDOWS oder 200 EURO für ein Jahr SUSE SLED oder 0 EURO für OpenSUSE .
Die kostenlosen OpenSUSE Softwareprodukte sind viel besser für Multimedia-Nutzungen und private Anwendungen auslegt sowohl Lokal als Web/Online als die SLED, SLES-pridukte oder die zukünftigen MS Windows-produkte .
Kostenlose OpenSUSE LINUX für Privatanwender für 0 EURO !
Günstiges Jahresabo von SUSE LINUX Enterprise DESKTOP (SLED) für wenige Hundert Euro für ein ganzes Jahr oder Mehrere Jahre für Unternehmen und Privatanwender anstatt Monatliche Abo .
selbst dass Teuer erscheinendene SUSE LINUX Enterprise SERVER (SLES) Softwareabo für UNTERNEHMEN und Behörden ist billiger Vergleich zu MICROSOFT Serverprodukten .
Also gibt es NICHT gar KEINE Überteuerte Abzocke bei SUSE LINUX und Open SUSE LINUX im Vergleich zu anderen Softwareanbietern .
@ SVENUNGLAUBE
Bitte nicht Äpfeln mit Birnen vergleichen. SLES, SLED und RHEL, sollten mit dem ähnlichen Angebot “Ubuntu Pro” von Canonical verglichen werden.
https://ubuntu.com/pro/subscribe
https://ubuntu.com/about/release-cycle
Für Familien bis 5 PC ist das Angebot “Ubuntu Pro” von Canonical kostenlos.
RHEL: RedHat Enterprise Linux
1 Like