Beiträge von Spaceloop

Hab jetzt weiter rumgetestet und komme so langsam zu einem "Software-Stack":

Coding-System 0.1

1) Zielsprache: Python

Warum Python? Es hat zwar einige Eigenschaften, welche mich persönlich nerven:

- Gliederung durch Einrückungen

- Scriptsprache mit einem Zoo teilweise inkompatibler Laufzeitumgebungen (2.7, 3.11, 3.13...)

Aber es ist ja inzwischen allgegenwärtig. Es wird an Schulen gelehrt, teilweise laufen KI-Sachen damit, und auch viele Tools im Open Source-Umfeld basieren auf Python. Es gilt als nicht allzuschwer zu lernen.

2) Basis: openSUSE Tumbleweed

- Kommt als Rolling Release-Distro

- Ist dennoch extrem stabil und QA-getestet

- Vandalismussicher dank BTRFS und Snapper mit GRUB-Integration. Die einzige Distribution, bei deren Installationen ich bisher noch nichts dauerhaft zerstören konnte.

Ich habe mich zuletzt auch testweise mit den deklarativ konfigurierbaren Distributionen GUIX und NixOS befasst. Davon wollte die Guix-VM in der Virtual Box plötzlich nicht mehr starten. Bei NixOS wollte ich den Channel auf unstable verstellen und habe mich an Tutorials aus dem Netz gehalten. Ich erhalte eine komische Fehlermeldung und komme im Moment auch nicht zurück. Nach etwas Überlegung finde ich es für meinen Zweck fragwürdig, das Entwickel-System sozusagen über ein Script (die Datei configuration.nix) einzurichten und darüber auch festzulegen, welche Software verfügbar ist. Ich denke, der Ansatz ist eher gut wenn man z.B. eine Serverkonfiguration vervielfältigen möchte. Aber für mich bei meinem Einsatzzweck doch eher ungewohnt und sperrig. Dennoch würde ich auf das Projekt zurückgreifen und Nix einfach unter Tumbleweed installieren. So habe ich meine geliebte und v.a. stabile Tumbleweed-Basis und kann mir für Projekte isolierte, reproduzierbare Umgebungen anlegen. Genau das ist ja sinnvoll bei dem Einsatzzweck des Systems.

3) Nutzeroberfläche: Sway

Sway ist eine i3-Weiterentwicklung für Wayland. Ich habe mich zunächst mit Awesome befasst, habe aber festgestellt, dass i3 deutlich beliebter zu sein scheint. Auch die Tatsache, dass mit Sway sehr schnell ein Wayland-Pendant bereit stand, scheint ja für die Beliebtheit des Konzepts zu sprechen. Vielleicht nehme ich irgendwann aber doch eine Awesome-Wayland-Alternative wie SomeWM...?

4) Terminal: Ghostty
https://ghostty.org/

Ein gutes Terminal ist offenbar die Voraussetzung für Editoren wie vim. Wichtig ist beispielsweise die Unterstützung von Farben und Hackerfonts, welche spezielle Symbole enthalten, die beim Coden nützlich sind. Ghostty ist aktuell sehr beliebt, kommt sinnvoll vorkonfiguriert mit vielen notwendigen Dingen bereits integriert. Viele Youtube-Tutorials verwenden es ebenfalls.

Installation: aus den Repos mit zypper

5) Tool: Yazi File Manager
https://yazi-rs.github.io/

Es handelt sich um einen Terminal-Dateimanager, der es einem ermöglicht, rasant via Tastatur durch seine Verzeichnisse und Dateien zu browsen. Muss unbedingt dazu.

Installation: aus den Repos mit zypper

6) Editor/IDE: Neovim
https://neovim.io/

vim ist ein Linux-Editor, den es schon seit Urzeiten gibt und bekannt ist. Er ist ist gut modifizierbar und zu einer guten Entwicklungsumgebung aufbohrbar. Neovim ist die verbreitete aktuelle Inkarnation von vim. (Neo-)vim zu lernen ist ebenfalls ein Ziel. Ebenso ist ein Ziel, Microsoft zu vermeiden (VS Code...)

Installtion: aus den Repos mit zypper

7) Editorkonfiguration: Lazyvim
https://www.lazyvim.org/

Neovim allein ist eine relativ freudlose und sperrige Angelegenheit. Erst mit der richtigen Konfiguration hebt er als Entwicklungsumgebung ab. Stichworte sind Treesitter, LSP und Linter-Plugins. Leider ist die Konfiguration für den Anfang extrem kompliziert. Es scheint eine unübersichtliche Fülle an Plugins zu geben, welche über Lua-Konfigurationsdateien einzurichten sind. Hierzu wurde Lazyvim erfunden. Es ist eine fertige Konfiguration mit Plugins. Herzstück ist ein Pluginverwaltungs-Plugin, worüber man (ähnlich wie in Yast Software) andere kuratierte Plugins finden und nachladen kann. Der Nachteil ist eine gewisse Online- und Projektabhängigkeit. Es scheint mir für den Anfang letztlich aber der für mich einzig gangbare Weg, Neovim aufzubohren. Es gibt auch andere fertige Neovim-Konfigurationen. Aktuell scheint mir Lazyvim aber am beliebtesten, weist eine größere Community auf und wird oft empfohlen.

Es gibt sogar Online ein Buch für den Einstieg:

LazyVim for Ambitious Developers

Installation:

-1- Neovim aus den Repos mit zypper installieren

-2- Das Lazyvim-Projekt bietet in seinen Repos eine Einstiegs-Konfiguration an. Zunächst muss man diese auf ein gesondertes Verzeichnis unter ~/.config clonen, z.B.

git clone https://github.com/LazyVim/starter ~/.config/lazyvim 

-3- Anschließend startet man Neovim, weist aber über eine Umgebungsvariable den Verzeichnisnamen als Appnamen zu, sodass Neovim die soeben geclonte Konfiguration aus dem Verzeichnis gleichen Namens liest, also:

NVIM_APPNAME=lazyvim nvim

Das muss man jetzt immer machen, wenn man mit Neovim die Lazyvim-Konfiguration nutzen möchte.

8.) isolierte Umgebungen: Nix

Gerade bei Python muss man bezüglich der Laufzeitumgebungen etwas aufpassen, da man sie für ein einzelnes Projekt manchmal etwas umkonfigurieren muss. Es gibt inzwischen verschiedenste Lösungen und Ansätze, getrennte virtuelle Umgebungen für einzelne Python-Projekte zu schaffen.

von/für Python:

- virtual environments vom Python-Projekt selbst

- Poetry: https://python-poetry.org/

oder weiter gefasst:

- Distrobox: Minimale Linux-Untercontainer als Laufzeitumgebung

- Deklarative Umgebungsmanager wie nix und guix: https://guix.gnu.org | https://nixos.org/

- Virtuelle Maschinen z.B. Oracle VirtualBox

Ich würde hier erstmal mit Nix starten.

- Poetry ist auf Python limitiert

- Distrobox ist bei mir nicht ganz stabil und ich bin beim testen teilweise über Themen gestolpert, z.B. in Bezug auf eine ungünstige Abstimmung/Vererbung bestimmter Eigenschaften (Nutzerrechte) vom Host auf den Gast...

- VMs /Virtualbox ist sehr schwerfällig

- Nix hat das größere Ökosystem im Vergleich zu Guix und ich habe mich im Zuge meiner NixOS-Experimente damit ansatzweise befasst. Also Nix!

Installation: aus den Repos mit zypper

9) Versionsverwaltung/Git: Codeberg
https://codeberg.org/

Europäischer Datenschutz, heimische Plattform...

So, mal sehen wie weit ich damit komme.

Also ich habe inzwischen folgende Überlegungen:

Schlau ist es vermutlich, das Entwicklungssystem vom Produktivsystem zu trennen. Gerade bei Python scheint es mir sinnvoll zu unterscheiden zwischen einer Nutzung der Python-Bibliotheken durch fertige Programme und herumpfuschen innerhalb von Python beim Programmieren.

Ich hatte erst die Vorstellung, in Virtualbox zu diesem Zweck ein Guix-System aufzusetzen. Da hätte ich mich gleich nebenbei noch mit deklarativ konfigurierbaren Linuxdistributionen befassen können. Allerdings ist die Guix-VM nach einigen Startversuchen plötzlich nicht mehr hochgefahren. Warum? War mir unerklärlich. Insgesamt erschien mir die Lösung dann doch zu fragil.

Anschließend habe ich versucht, mit Distrobox einen Container mit Tumbleweed und grafischer Oberfläche zu erzeugen. Was mir aber nicht geglückt ist. Mit X11 hatte ich immer Rechte-Probleme (xfce). Mit Plasma-Wayland habe ich immerhin kurz eine Startgrafik gesehen. Das Fenster ist dann aber mit Mauscursor auf schwarzem Hintergrund eingefroren.

Also dann doch wieder zurück zu Virtualbox... Wahrscheinlich mit einem ganz banalem Tumbleweed-System, evtl. aber auch NixOS?

Beim Editor habe ich auch weiter recherchiert.

1) Neovim ist im Auslieferungszustand kam brauchbar, aber man kann es beliebig tunen und aufbohren. Es gibt eine Reihe vorgefertigter Konfigurationen. Am verbreitetsten scheint "Lazy Vim" zu sein. Es basiert auf einem Plugin, was eine Reihe weiterer kuratierter Plugins per Klick nachlädt und aktuell hält. Man bekommt die Plugins damit mit überschaubarem Aufwand zum Laufen.

Es ist extrem krass, wieviel Zeit man damit verbringen kann, sein Neovim richtig einzurichten. Man braucht Dinge wie Treesitter, LSP-Server, Code-Verschönerer usw. Ich hoffe, dass ich da mit Lazyvim einen guten Einstieg finde.

Ich wollte mich an diese Anleitung halten:

Sinnvoll ist es offenbar, das meiste direkt aus dem git zu ziehen und dann zu bauen.

Jedenfalls handelt es sich um ein ganz anderes Kaliber als der Freepascal-Editor oder Lazarus...

2) Für grafische Sachen mit tkinter wollte ich dennoch celltoolz IDOL IDE testen, das kann ja dann zusammen auf das virtuelle Entwickel-System.

3) Dann wollte ich noch schauen, dass ich einen eigenen git-Account bekomme. Um MS zu vermeiden, habe ich mir Codeberg ausgeguckt. Ich hoffe, dass das mit Lazyvim zum laufen zu bekommen ist, und dass ich für den Anfang meine ersten Gehversuche auf "Privat" stellen kann (wegen Code-Shaming... )

Lösung:

sudo zypper in crun

Das Paket crun installieren. Es handelt sich offenbar um einen Konflikt, der entsteht, wenn Virtualbox installiert ist. crun ersetzt runc und hat offenbar einige Funktionen mehr, welche den Konflikt umgehen.

Anschließend Container löschen und neu anlegen.

Ich kämpfe gerade mit Distrobox unter Tumbleweed. Ziel ist, einen weiteren Container mit Tumbleweed einzurichten und zu starten.

Bisher habe ich folgendes zustande gebracht:

geeko@linux:~> distrobox create -i registry.opensuse.org/opensuse/tumbleweed:latest -n tumbleweed -I
Trying to pull registry.opensuse.org/opensuse/tumbleweed:latest...
Getting image source signatures
Copying blob 28117a4f4342 done   | 
Error: unable to copy from source docker://registry.opensuse.org/opensuse/tumbleweed:latest: copying system image from manifest list: writing blob: adding layer with blob "sha256:28117a4f43421e6eae1cecbb250965b3f29c5ff1f9e24d0c00b61dd36943bdd1"/""/"sha256:5019bdde08a4c842c1345f644cb6bcefe6cb2c9bb05fdec4ec0ec5bfc8f74554": unpacking failed (error: exit status 1; output: potentially insufficient UIDs or GIDs available in user namespace (requested 0:15 for /etc/shadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/shadow: invalid argument)

geeko@linux:~> sudo usermod --add-subuids 10000-75535 $(whoami)
[sudo] Passwort für root: 
geeko@linux:~> sudo usermod --add-subgids 10000-75535 $(whoami)
geeko@linux:~> sudo echo "$(whoami):10000:65536" >> /etc/subuid
bash: /etc/subuid: Keine Berechtigung
geeko@linux:~> su
Passwort: 
linux:/home/geeko # echo "$(whoami):10000:65536" >> /etc/subuid
linux:/home/geeko # echo "$(whoami):10000:65536" >> /etc/subgid
linux:/home/geeko # exit
exit

geeko@linux:~> distrobox create -i registry.opensuse.org/opensuse/tumbleweed:latest -n tumbleweed -I
Trying to pull registry.opensuse.org/opensuse/tumbleweed:latest...
Getting image source signatures
Copying blob 28117a4f4342 done   | 
Error: unable to copy from source docker://registry.opensuse.org/opensuse/tumbleweed:latest: copying system image from manifest list: writing blob: adding layer with blob "sha256:28117a4f43421e6eae1cecbb250965b3f29c5ff1f9e24d0c00b61dd36943bdd1"/""/"sha256:5019bdde08a4c842c1345f644cb6bcefe6cb2c9bb05fdec4ec0ec5bfc8f74554": unpacking failed (error: exit status 1; output: potentially insufficient UIDs or GIDs available in user namespace (requested 0:15 for /etc/shadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/shadow: invalid argument)
geeko@linux:~> podman system migrate

geeko@linux:~> distrobox rm tumbleweed
Removing container...
tumbleweed
Removing exported binaries...


geeko@linux:~> distrobox create -i registry.opensuse.org/opensuse/tumbleweed:latest -n tw-entwicklerbox -I
Creating 'tw-entwicklerbox' using image registry.opensuse.org/opensuse/tumbleweed:latest         [ OK ]
Distrobox 'tw-entwicklerbox' successfully created.
To enter, run:

distrobox enter tw-entwicklerbox

geeko@linux:~> distrobox enter tw-entwicklerbox
Error: unable to start container "e7165996c4fcfb48ea602e24883f89aecd0f131ff3b500696fb9923d771aff1a": runc: runc create failed: unable to start container process: error during container init: error mounting "/dev/vboxusb/001/003" to rootfs at "/dev/vboxusb/001/003": create mountpoint for /dev/vboxusb/001/003 mount: lookup mountpoint target: securejoin.OpenInRoot /dev/vboxusb/001/003: openat2 /dev/vboxusb/001/003: permission denied: OCI permission denied

Wie setze ich diese OCI permission? Irgendwo habe ich auch recherchiert, dass Apparmor etwas damit zu tun haben könnte.

Habe mal herumrecherchiert.

Ich werde folgendes Projekt mal weiter beobachten und bei Gelegenheit testen:

celltoolz IDOL IDE

Scheint so eine Art Delphi/Lazarus für Python zu sein.

Zitat

IDOL is what IDLE could have been — a full Python IDE with professional-grade tools (Designer, LSP, git, terminal, split editor) and a built-in learning platform designed to grow with you. Beginner-friendly without being beginner-limited. Pure Python, no Electron, no dependencies beyond pip.

Runs natively on Windows, macOS, and Linux from a single codebase.

vim oder neovim stelle ich dann erstmal hintenan.

Hallo,

mir kam gerade die Idee, meine grundlegenden Programmierkenntnisse (Pascal) evtl. mal systematisch zu erweitern.

Die erste Hürde wäre die Entwicklungsumgebung. Die wichtigsten Tools sind in der Pascal-/Delphi-Welt ja seit Urzeiten integriert. Und ich habe aufgrund der hobbymäßigen Beschäftigung mich nie mit Git befasst.

Meine Gedanken:

- Python ist mittlerweile der Universalkleber in der IT-Welt, eine Befassung damit sollte nicht schaden

- Alle erzählen immer von vim und Emacs als wichtigste Unix-Editoren. Könnte man bei der Gelegenheit ja gleich mitlernen...? Vim scheint etwas "einfacher" zu sein als Emacs. Mittlerweile schwören sehr viele aber auch auf die Neovim-Variante. VisualStudio ist mir auch ein Begriff und es ist für Linux verfügbar, aber MS wollte ich in dem Zusammenhang vermeiden...

- tja und dann eben Git dazu.

Erstes Ziel wäre die Einrichtung einer Umgebung zum Coden. Also: 1. Installieren des Editors, 2. schauen, ob man Syntax-Highlighting hinbekommt mit irgendwelchen Erweiterungen, 3. Ein Hallo-Welt schreiben, 4. Hochladen in github.

...und das ganze schlau verzahnen, sodass man dabei wenig Tipparbeit hat und die wichtigen Schritte irgendwie gescriptet sind (zum Testen des Codes, git push usw.). Also nicht manuell zeilenlange handgetippte Pfade zu Dateien an irgendwelche Tools übergeben... Dabei lernen, wie man seine Sourcen organisiert usw.

Bin ich da auf dem richtigen Weg? Kennt ihr gute Tutorials? Würdet ihr bei Python und Neovim mitgehen, oder gibt es da bessere Vorschläge?

...Generell neigen die Franzosen, auch auf Grund ihrer zentralistischen Tradition dazu, schnell etwas Top Down zu implementieren. In D bauen wir eher langsam von unten auf. Es wird der Deutschland-Cloud-Stack spezifiziert, plötzlich erscheint ein ZenDis auf der Bildfläche und eine Landesregierung führt Linux-Clients ein. Ich glaube, dass das zwar länger dauert, aber am Ende doch nachhaltiger wirkt. Man beachte die ganzen subventionierten französischen Konzerne. EDF, weil man Atommacht sein will. Oder im IT-Bereich die desaströse Entwicklung von Atos in den letzten Jahren.

Zitat von matbhm

Und auch Collabora hat nicht ursprünglich einen wesentlichen Beitrag zu LibreOffice erbracht, sondern Entwickler, die dann irgendwann für Collabora arbeiteten und von denen bezahlt werden.

So ein wenig sieht es bei Collabora so aus, dass man schleichend LibreOffice übernommen hatte, um daraus ein kommerzielles Produkt, mit dem man Geld verdienen kann, zu machen. Für geschäftliche Anwendung mag das ja noch angehen, aber auch bei Privatnutzung? Und selbst bei Verkauf zur geschäftlichen Nutzung dürfte dann jedenfalls das deutsche Stiftungsmodell mit den steuerrechtlichen Vorteilen "tot" sein.

Das sehe ich auch so. Einerseits ist es zwar irgendwie auch verständlich, dass man Geld für die Arbeit haben will. Andererseits besteht das Modell mit der gemeinnützigen Stiftung seit den frühen 10er Jahren mit den bekannten Vorgaben. Es wurde ursprünglich mal genau so aufgesetzt, um die Unabhängigkeit gegenüber kommerziellen Anbietern zu sichern. Gelernt hatte man aus den Erfahrungen mit Oracle und OpenOffice. Die These einer schleichenden Übernahme mit zunehmenden Erfolg "hintenrum" ist daher nicht ganz von der Hand zu weisen.

Auf der anderen Seite war den Entwicklern bei Collabora aber auch schon seit Jahren bewusst, dass es in der LO-Codebasis größere technische Schulden gibt, wie z.B. eine Abhängigkeit von Java. Auch wollten sie schon lange die etwas altbackene Oberfläche mit gefühlt 50 kleinen Symbolen in der Werkzeugleiste entschlacken. Hier gab es aber immer Gegendruck aus der Community, was die Entwickler wohl ziemlich frustriert hat. Die TDF hing einerseits als gemeinsamer Prellbock zwischendrin. Andererseits hat sie teilweise auch unglücklich agiert. Jetzt kann man sich entscheiden, welcher Variante man glaubt. a) Die TDF hat mit ihrem unkooperativen Gebaren und Agieren die eigentlich motivierten Entwickler vertrieben. oder b) Das Verhalten der TDF war lediglich ein Aufhänger für Collabora, sich nach all den über die Jahre gemachten Erfahrungen in der Office-Entwicklung aus LibreOffice rauszuziehen und ihr eigenes kommerzielles Ding aufzuziehen (und möglichst viele User+Entwickler mitzunehmen).

Am Ende war keiner Hinter den Kulissen dabei. Ob das eine gute Entscheidung (und für wen) war, wird die Zeit zeigen.

Übrigens gibt es ein ähnliches Problem gerade auch bei den Freunden von Manjaro.

Die Manjaro-Krise 2026: Ein Schiff das schon lange sinkt - ein ausführlicher Kommentar

Das Manjaro 2.0 Manifest ist das sichtbare Ergebnis jahrelanger Führungsfehler, Machtmissbrauch und technischer Vernachlässigung und stellt das Projekt vor…

gnulinux.ch

Dort geht es um eine Aufgabenverteilung zwischen dem Hauptentwickler Philipp Müller und seiner Manjaro GmbH & Co. KG und der Entwicklerbasis, welche eine e.V.-Struktur (wie bei KDE) fordert.

Wenn man sich so überlegt, was in den letzten 12 Monaten so alles passiert ist:

- Moneyplex krepiert nach über 20 Jahren

- Yast weg, Leap neu

- LibreOffice und die TDF in unsicheren Gewässern

- Onlyoffice-Streit

- Manjaro zerlegt sich gerade selbst

...und AVM heißt jetzt Fritz!...

Joah, reicht erstmal...

EDIT:

Achja und zum Thema Franzosen...

Zitat von andalusia

hallo Muck

vielen Dank für deine Antwort - und den Input. Danke - das ist auf alle Fälle ein toller Zug - die Franzosen - die sind mutig (und machen uns hier m.E. auch echt was vor)..

da müssen wir höllisch aufpassen, dass sie nicht wieder "Franzosen-Dinge" machen...

Ein franzöischer Thinktank hat die Idee eines "EU-Linux" entwickelt...

Sovereign OS "EU Linux" - Abilian Innovation Lab

Demnach ist mit der Pleite von Mandrake/Mandriva die Chance auf Souveränität verloren gegangen. Es gibt seitdem angeblich kein Linux mehr aus der EU, und keine Souveränität.... Daher sollte die EU ordentlich Kohle in die Hand nehmen (ein Großteil vom deutschen Steuerzahler stammend...) und ein EU-Linux neu von Grundauf entwickeln, evtl. basierend auf Debian-Basis. Das wird dann EU-weit ausgerollt und wir haben Souveränität gewonnen, so offenbar die Vorstellung....

Wahrscheinlich am besten noch mit Firmen- oder Organisationssitz in Paris, wo das EU-Geld dann landet...

Also im Prinzip FCAS /Rafale reloaded. Ein gemeinsames EU-Projekt, wo am Ende Geld und Know How zu 95% jenseits des Rheins landen. Ich würde unseren Nasen in Berlin durchaus zutrauen, dass sie im Namen der deutsch-französischen Freundschaft darauf auch noch eingehen... Egal was es in D oder auch IRL noch so an etablierten Anbietern gibt...

Bis 15.6 war Leap für mich durchaus zu gebrauchen.

Aktueller Stand:

Nachdem ich dem Repo-System immer kryptischere Fehlermeldungen entlockt habe, habe ich davon ausgehend recherchiert.

Ein beherztes

 # zypper rm openSUSE-repos-Leap*

hat dazu geführt, dass diese unberechenbare Repo-Management-Automatik endlich verschwand und ich wieder die Kontrolle über meine Repo-Konfiguration übernehmen konnte.

Anschließend habe ich, wie im Wiki empfohlen, nur noch die drei Leap-Repos oss, non-oss und h264 aktiviert. Und dann das Migration-Tool gestartet, was aber jedes mal mit irgendeinem Zypper-Fehler abgeschmiert ist.

Dann habe ich halt, klassisch in der Strg-Alt-F4-Konsole ein

su
# zypper --releasever 16.0 dup

durchgeführt.

Meine Installation ist schon mehrere Jahre alt. Beim duppen habe ich dann schon sorgenvoll festgestellt, dass sehr viele liebgewonnene Pakete und Software ersatzlos deinstalliert wurde. Die reduzierte Paketauswahl bei Leap 16 wurde ja bereits im Vorfeld angekündigt. Tja, und nach der Installation, beim ersten Start, lande ich dann statt in KDE auf einem schwarzen Bildschirm mit Mauscursor. Bei 10 Jahre alter Intel-Onboardgrafik, die bisher immer in allen möglichen Konstellationen gelaufen ist und kein Hexenwerk darstellen sollte.

Jetzt hatte ich die Faxen dicke...

Wenigstens hat snapper rollback zuverlässig funktioniert. Bin dann wieder auf Leap 15.6 zurück und habe anschließend die Anleitung zum Wechsel der Installation zu Tumbleweed durchgearbeitet. Auf anderen Systemen habe ich es bisher eher als Notlösung genommen, aufgrund des Supports älterer CPUs. Dabei hat es stets erstaunlich gut und stabil funktioniert. Nun ist es also zum Daily Driver auf dem Hauptsystem aufgestiegen. Startete sofort - das meiste noch da, Yast noch da, Oxygen-Theme in KDE noch da. System sieht aus, funktioniert und fühlt sich nach meinen bisherigen Eindrücken an wie gehabt... Ein paar Sachen wie Plasma sind etwas anders, da eben brandneu.

Fazit:

- gemanagte Repos (openSUSE-repos-Leap-Paket) für mich unbrauchbar, verwirrend und zeitraubend

- openSUSE-migration-tool: dito

- Leap 16: unbrauchbar, da es nicht startet und außerdem zu wenige Pakete hat

Bin mal gespannt, wie sich Tumbleweed langfristig auf dem Hauptsystem schlägt. Auf meinen anderen Tumbleweed-Systemen war es wie gesagt unproblematisch. Es "rollt sehr stabil" und wenn man alle paar Tage bis Wochen duppt, hat man wahrscheinlich insgesamt sogar weniger Ärger als unter Leap - wo jedes Jahr ein Rumgehampel mit der Vorbereitung der Repos für den feierlichen dup-Prozess ansteht.

Sollte das Tumbleweed sich in ein paar Monaten oder Jahren selbst unrettbar zerlegen, würde ich vielleicht noch mal in Erwägung ziehen, ein Leap 16.1 oder 16.2 zu installieren. Ansonsten sehe ich in diesem Zweig für mich aktuell keinen Sinn. Leap 16 ist durch sein wählerisches Verhalten in Bezug auf Hardware und die eingeschränkte Paketauswahl aktuell so flexibel wie ein Amboss. Mir kommt es beinahe vor, als hätte SUSE das "alte" Leap gekillt und eigentlich handelt es sich bei dem Produkt um ein an die Community ausgelagertes SLED 16...