Beiträge von Hidalgo

Zitat von Sauerland

Hier in Leap 16.0 läuft:

Code

linux64:/home/stephan # systemctl status network.service
● wicked.service - wicked managed network interfaces
     Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled; preset: disabled)

In Leap 15.6 läuft:

Code

laptop:/home/stephan # systemctl status network.service 
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: disabled)

Kann man einfach mit systemd umstellen.

Ja - hat auch keiner etwas anderes behauptet.

Aber ich will hier im Forum auch gar keine "Korinthenkackerei" betreiben - nur helfen falls es mir möglich ist.

Zitat von Sauerland

Was hat der Netzwerkmanager mit Yast zu tun?

Der Netzwerkmanager wurde noch nie mit Yast eingerichtet, das konnte man grafisch immer über ein Applet machen.

Ich hatte mit Yast den Networkmanager auf wicked umgestellt, weil der ersterer nach einem Update nicht mehr funktionierte.

Später dann wieder mit yast umgestellt auf den networkmanager. Somit erlaubte ich mir diesen Weg - den es ja nicht mehr gibt - dennoch zu nennen.

Selbstverständlich konnte man mit yast das netzwerk konfigurieren - grafisch - mit Yast eben. So what?

Die Systembasis unter Leap 16 ist grundlegend verändert. Deshalb sind Sprache und Tastaturlayout zunächst us-englisch. War bei mir auch so.

Deshalb folgendes durchführen fürs Tastaturlayout:

localectl set-x11-keymap de

Und für die Systemsprache:

localectl set-locale LANG=de_DE.UTF-8

Wegen des Netzwerkes würde ich versuchen:

systemctl enable --now NetworkManager

Eine GUI für den Networkmanager wegen des Fehlens von Yast gibt es nicht mehr, aber du kannst in der Konsole

nmtui

eingeben und "edit a connection" auswählen. Die ipv4 Konfiguration sollte auf "automatic" stehen.

Viel Erfolg!

Ja - deinen Weg bin ich auch zwei-dreimal erfolgreich gegangen, aber in Leap 16 wurde das veraltete mkinitrd-Skript endgültig entfernt (notwendige grundlegende Änderungen).

Um das Boot-System in einer chroot-Umgebung zu reparieren, ersetzt du einfach mkinitrd durch den Befehl

dracut -f

Nicht vergessen für Grub2 die Konfigurationsdatei neu zu generieren - müsste dann alles so klappen:

# 1. Mounten des Root-Dateisystems (hier als Beispiel /dev/sda1)
mount /dev/sda1 /mnt

# 2. System-Verzeichnisse binden (inkl. /run für moderne Tools wichtig)
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

# 3. In das installierte System wechseln
chroot /mnt

# 4. Falls UEFI genutzt wird: EFI-Partition mounten (wichtig für grub2-install)
# mount /dev/sdaX /boot/efi  # Falls nötig; siehe 'fstab' oder 'lsblk'

# 5. Initramfs neu erstellen (Ersatz für mkinitrd)
dracut -f

Zitat von muck

Ich bin seit Suse 6.0 dabei und es war immer so, das die .0 Versionen nie das gelbe vom Ei waren. Erst die x .1, .2 .... Versionen waren ok.

Ist jetzt mit 16(.0) auch wieder so.

Jeder macht halt' unterschiedliche Erfahrungen - die Hardware unterscheidet sich ja auch unter den Usern.

Ist man gegenüber Nuller - Versionen negativ voreingestellt, werden dortige Fehler vielleicht eher höher bewertet?

Bestätigen kann ich obige Erfahrung jedenfalls von meiner Seite - auch aktuell - nicht.

Bisher nutzte ich kein Wayland, sondern X11. Allerdings jetzt bei Leap 16 bin ich von Stabilität und Geschwindigkeit unter Wayland vollauf zufrieden. Das meine alte Mühle sogar effizienter läuft, ist jedenfalls keine Selbsttäuschung, denn Wayland soll der effizientere und auch sicherere Nachfolger von X11 sein, der die Display-Server-Funktionalität mit dem Fenstermanager (Compositor) zusammenfasst, was zu besserer Leistung und weniger Komplexität führt, auch wenn X11 über das Kompatibilitätsprotokoll Xwayland weiterhin für ältere Anwendungen bereitsteht. Bei spezifischer Hardware (wie alten Nvidia-Karten) oder bestimmten älteren Programmen kann das aber noch Probleme bereiten. Diese Probleme können bei einer Nuller Version aber auch 1er oder 2er Version abgestellt werden. Fazit (mein Fazit): Leap 16 ist eine für erforderlich gewordene tiefgreifende Umstellungen (betrifft ja auch pipewire, meine meine DAW unter Linux ist bequemst zu managen, kein "jack" mehr nötig) hervorragende Arbeit.

Ist aber alles nur meine einzelne Meinung,

bleibt alle gesund beim Feuerwerk morgen!

Gruß...

Dann bin ich solange mit "Susi" unterwegs, wie du Dirk. Deine Bedenken wegen des Wegfalls von Yast teilte ich auch, aber dieses Alleinstellungsmerkmal von SuSE ist eben auch nicht wenig aufwendig in Gestaltung und Programmierung sowie der jeweils erforderlichen Anpassungsarbeit. Die Beliebtheit von SuSE ist trotz dieses grafisch bequemen Tools - was wohl besonders Windows Umsteiger ansprechen sollte - niedriger oder nicht höher als in den Distributionen, wo es Yast oder was Ähnliches nicht gibt. Die Leute kommen dort also ohne Yast klar bzw. vermissen es in den meisten Fällen gar nicht. Yast konnte viel, aber eben nicht alles abdecken, was man über die Konsole erreicht. Yast selbst erzeugte allerdings - wenn auch selten - selbst mal Fehler, wenn das anschließende sysconfig wegen mangelnder Anpassung Änderungen nicht übernahm. Das sei nur der Vollständigkeit halber erwähnt.

Aber Menschen sind unterschiedlich. Ich hätte nicht gedacht, das Yast mir nach dem Wegfall "keine Schmerzen" bereitet - ging aber davon aus und zögerte deshalb mit dem Upgrade von Leap 15.6 auf 16. Dann stellte ich fest, ich vermisse Yast gar nicht.

Würde ich es aber vermissen, dann kann ich ja die Karten neu mischen! Zum jammern habe ich keinen Grund, weil mir "Suse" ja seit dreissig Jahren sehr gute Dienste für umsonst erwiesen hat. Ich habe keine Zeit und Lust dazu, ein aktuell angepasstes Yast zu programmieren. Von Anderen habe ich nichts zu verlangen, denn OPenSuSe ist nach wie vor umsonst - was mir zu genügen hat. Keine Distribution drängt sich auf. Yast war stets nur optional - nun hat sich die Welt eben weitergedreht, was mir durchaus verständlich ist.

Prüfe doch mal dem Tool pavucontrol, ob unter dem Reiter „Konfiguration“ das richtige Profil für deine Soundkarte (z.B. „Analog Stereo Output“) ausgewählt ist, auch wenn dort „nicht verfügbar“ steht.

Falls das nicht hilft - gar nicht so selten wird beim ersten Start die Sound-Hardware nicht richtig initialisiert. Gehe versuchsweise in ein Terminal und gebe dort mal ein:

sudo udevadm trigger

Unter Linux arbeitet man zum Einkreisen von Problemen i.d.R. im Terminal. Mit obigem Befehl wird das System angewiesen, die Hardware Datenbank neu zu laden.

Stimmen die Voraussetzungen nicht, hilft auch pavcontrol nicht, weil dieses Programm für die Einstellbarkeit der Sound-Hardware ja auf funktionierende Treiber angewiesen ist.

Hilft auch das nicht, dann bitte einmal die Nutzerdienste neu laden. Das geht so im Terminal:

systemctl --user restart pipewire wireplumber pipewire-pulse

Nach Ausführung und aufgedrehten Lautsprechern ist ein kleiner Knacks bei Erfolg zu vernehmen.

Bei dieser Gelegenheit: Keine Angst vor dem Terminal. Da gewöhnt man sich als schnell dran und wenn das System stabil läuft, hat man in der Regel damit nichts mehr zu tun!

Zitat von Scytale

>snip>

Das heißt in Fachkreisen: Du hast solange gute IT Security, bis etwas passiert ist. Aber dass so lange nichts passiert ist, macht den Incident ja nicht weg.

Hat auch niemand behauptet. Würde ja auch keinen Sinn machen, weil das ganze Leben ein Risiko ist - nicht nur die Nutzung der IT Welt, als Teilbereich menschlichen Lebens.

So ist eben nicht auszuschließen, dass ausgerechnet dort eingebrochen wird, wo vermeintlich die höchstmögliche Sicherheit umgesetzt ist.

Eigentlich hat Alero es längst auf den Punkt gebracht in # 32!

Bei Packman vertraue ich der Community. Funktioniert seit ca. 1995 bei mir. Da werde ich also nichts umstellen - hat sich ja ausgezahlt.

Bei offiziellen Repos bürgen die Distributoren für Sicherheit. Aber die sind eh' eingebunden - was auch sonst.

Nur: Das Böse ist immer und überall. Eine Firma hat weniger Augen, evtl genervte Mitarbeiter, als "freie Verfechter einer Ideologie, die auch praktisch funktioniert" (Linuxer).

Was Flatpak angeht - warum nicht? Allerdings gilt hier, dass die meisten Flatpaks von Flathub kommen. Hier verlassen sich Nutzer tatsächlich oft auf eine zentrale Instanz statt auf die Maintainer ihrer spezifischen Distribution.Flatpak kompensiert dieses "fremde Vertrauen" durch technische Barrieren: Anwendungen laufen in einer Sandbox. Selbst wenn ein Paket kompromittiert wäre, hat es theoretisch keinen Zugriff auf Ihre restlichen Daten, sofern die Berechtigungen nicht zu weit gefasst sind.Das Risiko: Die Sicherheit kann "aufgeweicht" werden, wenn Flatpaks mit zu vielen Berechtigungen (z.B. Zugriff auf das gesamte Dateisystem) ausgeliefert werden oder wenn Sicherheitslücken in der Sandbox selbst existieren.Als es noch gar kein Flatpak gab, stellte Linux das erste funktionierende 64-Bit Betriebssystem vor. Packman war immer dabei, damit dieses tat, was es sollte.Man kann immer weiter theoretisieren, aber es bleibt dabei: Der Mensch ist und bleibt der größte "Schwachkopf". Wo aber die Mehrzahl Vernünftiger in die "Open-Source Eingeweide" schauen kann, ist man wegen der Transparenz die maximale menschlich-mögliche Sicherheit.Das fällt mir zu diesem Thema als Pragmatiker, bzw. Praktiker, bzw. praktischer Theoretiker ... oder besser theoretischer Pragmatiker ... oder auch theoretischer Theoretiker usw. ein.

Rufst du die Datenbank normalerweise über eine Verknüpfung der Benutzeroberfläche auf?

Wenn ja, dann lösche diese, erstelle eine neue und versuche es nochmal.