Beiträge von Spaceloop

Hallo,

ich habe gerade auf einem alten Core2Duo-System mit richtigem Floppylaufwerk ein nerviges Thema mit dem Schreibcache (Tumbleweed).

Und zwar geht es um das Schreiben eines Images (hier Bootdiskette):

tux@linux:~/Downloads> sudo dd bs=512 count=2880 of=/dev/fd0 if=./Windows98_SE.img
2880+0 Datensätze ein
2880+0 Datensätze aus
1474560 Byte (1,5 MB, 1,4 MiB) kopiert, 0,00945428 s, 156 MB/s

Das Image wurde offenbar innerhalb von 0,0094 s mit einer Datenrate von 156 MB/s auf die olle Floppy geschrieben.

Das Laufwerk selbst blieb stumm.

Dann habe ich rumüberlegt, wo der Fehler sein könnte, und angefangen zu recherchieren. Und währenddessen, nach 1-2 Minuten, legt das Floppy-Laufwerk tatsächlich los und schreibt mir das Image! Offenbar ist hier ein Schreibcache aktiviert.

Diesen würde ich für das Floppy aber gern deaktivieren, weil die Zeit bis zum Flush ja länger ist, als es braucht um das Image zu schreiben. Wo kann ich das einstellen?

Ich bin eben beim herumsurfen im Internet über zwei neue Bücher zum Thema openSUSE gestolpert, allerdings auf Englisch.

Das eine ist bei Amazon, offenbar als Print on Demand(?) erhältlich:

OpenSUSE Odyssey: A Traveler's Guide Through This Linux Distro, Taschenbuch – 29. Januar 2025

Englische Ausgabe von Gwendolyn Y. Andersen (Autor)

https://www.amazon.de/OpenSUSE-Odyssey-Travelers-Through-Distro/dp/B0DVGX4VDX

270 Seiten, 21,39 €

----------

Das andere ist ein EBook:

Comprehensive openSUSE Administration (eBook, ePUB)

Definitive Reference for Developers and Engineers - Erscheinungsdatum: 19.06.2025

Richard Johnson

Comprehensive openSUSE Administration (eBook, ePUB)

Comprehensive openSUSE Administration Comprehensive openSUSE Administration is a definitive and meticulously structured guide for Linux professionals, system…

www.buecher.de

266 Seiten, HiTexPress - ebook bei Bücher.de angeblich ohne Kopierschutz, 8,67 €

Hat diese Bücher schon jemand gekauft? Bzw. könnte mal jemand erfahrenes einen Blick in die Leseproben werfen? Sind es tatsächlich von Menschen geschriebene Bücher mit Mehrwert, der über die SUSE/OpenSUSE-Handbuch-PDFs hinausgeht?

Bzgl. der Dinge, die funktionieren müssen bin ich auch gerade noch am Forschen. Ich frage mich, ob es für manche Programme sinnvoll sein könnte, sie ggf. als Flatpak, evtl. sogar aus dem Fedora-Flatpak-Repo, zu beziehen. Oder als AppImage (mit AppImageUpdater). Dann hast du sozusagen eine dynamische und aktuelle Basis, und nach oben hin eine Containerschicht. Welche nicht ganz so von der Basis abhängig ist wie rpms. Allerdings laufen manche Programme nach meinen Erfahrungen nicht vollständig kompatibel: Bei meinen Firefox-Flatpak-Experimenten ist die Sprache immer wieder auf Englisch gesprungen. Musescore hat einen eigenen Auto-Updater, der nicht mit Flatpaks funktioniert (wobei unter Linux eigentlich sowieso sinnlos) usw...

Hilft dir evtl die Pivotfunktion von Sheets aus der KDE Calligra Suite weiter?

Pivot Tables

Zitat von letsfindaway

Cockpit kann momentan

• Netzwerk: VPN, VLAN, ...
• Nutzer: Nutzer und Gruppen verwalten
• Firewall: Ein/Aus, Regeln und Zonen bearbeiten
• AppArmor: nein, wir sind ja jetzt auf SELinux. Hier kann es den enforcing Mode ein- und Ausschalten und die Alarme anzeigen
• Sudo: nein
• Services: ja
• Hostnamen ändern: ja
• und noch einiges mehr. SAMBA hab ich aber nicht gefunden.

Ich frage mich ohnehin folgendes:

Ein wesentlicher Teil des Problems bei Yast scheint ja zu sein, dass niemend mehr die Ruby-Codebasis warten möchte. Gleichzeitig macht KI mit LMMs in der Softwareentwicklung immer mehr Fortschritte.

Claude Code entwickelt Mac-App: Entwickler berichtet über Erfahrungen

Ein erfahrener Mac-Entwickler hat eine komplexe App nahezu komplett von Claude Code erschaffen lassen. Jetzt berichtet er über seine Erfahrungen mit der KI.

www.heise.de

Vielleicht kann man ja in 1-2 Jahren die fehlenden Yast-Teile (Sudo, Samba...) Claude Code vorsetzen und die KI darum bitten, das in Cockpit einzufrickeln...

Eine Migration auf Tumbleweed kommt nicht in Frage?

openSUSE:Migrate Leap to Tumbleweed - openSUSE Wiki

Zitat

OpenSUSE Leap 16.0 uses x86-64-v2 for compatibility with old hardware. Legacy boot is also supported. Packages from SUSE SLE 16 will be available with "Backported" repos with not yet known characteristics (v2 or v3?).

OpenSUSE Tumbleweed stays with x86-64 a.k.a. x86-64-v1.

von: https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels

((Ansonsten könnte man Tumbleweed per Extra-Paket auch auf v2 heben.))

--> Grundsätzlich läuft Tumbleweed erst mal auf v1 weiter. Im Normalfall sollte das also funktionieren, es sei denn

-das System hat eine lahme oder keine Internetverbindung (dann macht es mindestens keinen Spaß, wenn es nicht sinnlos ist...)

-du benutzt z.B. zwingend den Auto-Updater in der Tray-Leiste

-du bist aus irgendwelchen anderen Gründen auf hohe Versionsstabilität angewiesen.

Ich glaube, Yast einzustampfen ist eine Sparmaßnahme von CEO van Leuwen. Er kommt von RedHat, und dort hat man was vergleichbares bisher auch nicht gebraucht. Hauptzielgruppe von Yast sind auch hauptsächlich Desktopnutzer der open-Variante, also nichts, womit man Geld verdienen könnte.

Yast bündelt zudem in der GUI verschiedene Dinge, die es auch woanders gibt. Teilweise (z.B. Drucker) gibt es störende Überlappungen mit den Tools der Desktop-Umgebungen bzw. Subsysteme.

Oder Einzelprogramme.

Partitionierer ->GParted

Dateisystemschnappschuss --> BTRFS Assistant, Timeshift

Bootloader -> GRUB Customizer, GRUB-Editor

Software heisst jetzt Myrlyn...

Drucker --> gibts von CUPS...

Datum Zeit --> macht die Uhr in der Taskleiste

Ich frage mich, ob es sinnvoll sein könnte, bei Leap 16 ein "FrankenYAST"-Paketschema anzubieten, welches derartige Programme installiert und im Programm-Menü noch einmal sinnvoll in einer Gruppe einrichtet.

Allerdings: Zum Bereich Netzwerk/Nutzer/Firewall/AppArmor/Sudo fallen mir so schnell keine GUI-Ersatzprogramme ein. Ich erinnere mich an eine Diskussion in einem anderem Forum, wo jemand eine GUI zu SAMBA haben wollte und ihm am Ende dann der Umstieg zu openSUSE mit Yast geraten wurde.

Cockpit kann doch aber Systemd?

Hallo,

letzte Woche hatte ich mal wieder einen Paketkonflikt unter Tumbleweed beim duppen. Ein upzudatendes Paket von Packman wollte dieselbe .so-Bibliothek installieren wie eines aus den openSUSE-Repos. Im Sinne einer Systemkonsistenz hab ich mich dann erstmal für Lösung 1) entschieden - Deinstallation von Pikabackup. Vor einigen Wochen habe ich das Notensatzprogramm Musescore aus dem gleichen Grund von der Platte befördert.

1) Ist euch das in letzter Zeit auch öfters passiert?

2) Wie kann man das am besten verhindern?

Im Moment schwebt mir ein Ansatz vor, die Nutzung von Packman zu minimieren und die Programm-rpms von Packman irgendwie zu ersetzen. D.h.

Level 1: openSUSE-Basis-Repos: Alles, was bei der Installation mitkommt und das Umfeld. D.h. Office, Internet. Email, Desktopumgebung und Programme mit Bezug zur Desktopumgebung (KMail, etc)

Level 2: Packman: wird minimiert. Alles im Umfeld von opi codecs und Multimedia - VLC, Kodi...

Level 3: Darüber hinausgehende Anwendungsprogramme, insbesondere diejenigen, die in Richtung Special Interest gehen - wie Musescore

--> Tja wie am besten ersetzen

Ich sehe zwei Möglichkeiten:

a) unter http://download.opensuse.org/repositories/ Special-Interest-Repos einbinden?

Vorteil: rpms , d.h. schlank und klassisch installiert

Nachteil: evtl. bräuchte ich nur ein oder zwei rpms aus manchen Repos. Lohnt sich das, dafür die Repoliste unübersichtlich zu verlängern?

Frage: wie stabil sind repos wie /multimedia:/apps/ im Vergleich zu Packman? Wie häufig sind da Konflikte im Vergleich?

b) Die Special-Interest-Programme über Flatpaks abdecken?

---> eine große, distributionsübergreifende zusätzliche Softwarequelle. Allerdings recht klobig und umständlich.

Bevor ich da jetzt größere Umbauten vornehme und nach 2 Monaten mich vom Regen in der Traufe finde: was wäre euer bevorzugter Weg?

Offenbar wird mehr und mehr erkannt, dass es langfristig auch durchaus Nachteile haben könnte, sich zu sehr an einen bestimmten marktführenden Hersteller zu binden.

Indirekt profitiert über mehrere Ecken evtl. sogar openSUSE von diesem Landesauftrag. Der Macher hinter openTalk ist Peer Heinlein - deutsche OSS-Koryphäe, ebenfalls Chef von Mailbox.org, langjähriger openSUSE-Freund und Projektsponsor. Und er wird übermorgen um 11:30 einen Vortrag zu seinem verwandtem openCloud-Projekt auf der openSUSE Conference in Nürnberg halten:

Zitat von Spaceloop

Also ich hätte gern sowas wie Snapshots mit GRUB oder verschiedene rpmostrees PLUS Waydroid in offiziellen Repos. Soweit ich weiss, bietet das normale Fedora standardmäßig keine Snapshots. Ich möchte aber auch nicht ewig manuelle Tutorials durcharbeiten, die dann obendrein noch an irgendeiner Stelle veraltet sind.

Im Moment denke ich über Debian nach, und zwar installiert in der SpiralLinux-Variante, mit Gnome, wahrscheinlich auf Testing umgestellt.

https://spirallinux.github.io/

In SpiralLinux hat sich bei mir das Problem entwickelt, dass es sich irgendwie frühzeitig auf die Debian 13-Basis geupdatet hat und dann der Bootprozess beim Versuch, den gdm Display Manager zu starten, hängen geblieben ist. Ich muss aber auch sagen, dass ich das anklickbare Quellen-Konzept von Spirallinux mit Debian Testing, Fasttrack staging, Backports, ... sehr verwirrend finde und vielleicht der Fehler auch hier zu suchen ist (wobei das Projekt ja mit einer einfachen Bedienbarkeit wirbt...).

Fedora Silverblue hatte sich ja bei mir selbst zerlegt, sodass es sich nicht auf die 42 updaten lässt. Hier hatte ich damals bei der Installation ja die Hoffnung, dass das nicht passieren würde. Zudem finde ich es durch die OSTree-Basis extrem nervig, zu warten... Änderungen am Basissystem zu konfigurieren dauert durch das ganze Ein- und Auschecken extrem lang. Man wartet beim Warten, gewissermaßen...

Garuda habe ich gar nicht mehr getestet. Ein Arch-Derivat, zwar mit Snapper, aber mit Warnung, es parallel zu Windows zu installieren. Das hat mich dann doch abgeschreckt. Ich habe dann schon die nächste Bastelei befürchtet.

Ich habe jetzt Tumbleweed auf das Gerät installiert. Der Weg, Waydroid über das Community-Repo unter Zuhilfenahme des auf der Projektseite verlinkte Tutorial zu installieren, funktioniert übrigens offenbar nicht mehr seit der Umstellung auf SELinux. Ich habe beschlossen, erstmal darauf zu verzichten. Unter Silverblue war Waydroid bereits eher selten im Einsatz, hinkte dadurch bei Updates hinterher. Und gerade die Gnome-Softwaresammlung, aber auch Firefox oder Kodi unterstützen auch so schon recht gut Touch unter nativem Linux. Zudem hat Tumbleweed den Digitizer viel besser erkannt. Es warnt zwar, dass eine ID nicht passt - aber der Treiber läuft besser als unter Spiral und Silverblue. Es wird erstmals unter Linux sogar der China-Stift als solcher erkannt.

Das ist es, was mich aktuell bei OpenSuse hält. Nach meinen Erfahrungen eine sehr gute Hardwarerkennung und wenig unvorhersehbares Nerv-Verhalten, generell eine stabile Basis die in den allermeisten Fällen wie geplant reagiert. Bei Experimenten mit anderen Distributionen hatte ich bis vor kurzem zum Teil noch Probleme wie booten in einen schwarzen Bildschirm. Und auch mein Spiral-Erlebnis hat mich wieder mental zurückgebracht in eine mindestens 10 Jahre dauernde Findungsphase, in der ich immer wieder versucht habe, auf Linux zu wechseln. Und in der dann immer irgendwie zuviel nicht geklappt hat--und ich am Ende nach mehreren vergeblichen Reparaturversuchen zu Windows zurück gekehrt war.

Opensuse ist bei mir bisher immer durchgestartet, und wenn ich das System dann (regelmäßig selbst) kaputtgefrickelt hatte, war der in GRUB integrierte Snapper zu Stelle.

Ich hoffe, dass diese Qualität auch in Zukunft bei OpenSuse erhalten bleibt.