Beiträge von Spaceloop

    Ich blicke noch nicht 100% durch, was Allow Vendor Change und {releasever} betrifft...


    Das sind aktuell meine Repos.


    Das folgende sind die Urls:


    Wie gehe ich damit um? Anpassungsbedarf würde ich gemäß Anleitung bei

    Code
    http://download.opensuse.org/distribution/leap/15.3/repo/oss/
    https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/
    https://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-15-SP3/standard/

    sehen.



    Endergebnis sollte so aussehen?

    Code
    http://download.opensuse.org/distribution/leap/$releasever/repo/oss/
    https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
    https://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-15-SP4/standard/

    So, ich habe jetzt ./esets_gil als su ausgeführt. Es erscheint ein Uninstall-Assistent, welcher zumindest das Tray-Programm löscht. Der Service bleibt irgendwie noch bestehen und wird durch den Uninstaller nicht angetastet, aber da half

    Code
    systemctl stop esets

    sowie

    Code
    systemctl disable esets

    Anschließend bin ich dann noch in den unter

    Code
    systemctl cat esets

    angezeigten Pfad, und habe die Service-Datei gelöscht. Den Trick habe ich in einem Reddit ergoogelt.


    Dort wurde auch empfohlen, die Aktion mit


    Code
    systemctl daemon-reload
    systemctl reset-failed


    abzuschließen. Anschließend Neustart, und ESET scheint weg zu sein...

    Hallo,


    ich habe das folgende Problem:


    Wenn ich meinen PC hochfahre, mich in Leap 15.3 (KDE) einlogge und ein Flatpak-Programm mit 3D-Grafik starten möchte, bricht der Start ab. In der Konsole erscheinen Fehlermeldungen.


    Ich muss mich erst ausloggen und dann wieder einloggen, und dann funktioniert es plötzlich, auch in X11. Betroffene Programme sind Libre TrainSIm und Sweethome3D.


    Woran kann dieses Verhalten liegen?

    Hallo,


    ich mache mir gerade Gedanken, wie ich ESET NOD32 Antivirus deinstallieren kann, nachdem die Lizenz abgelaufen ist.


    Problem: Anders als bei Leap 15.2 war eine Installation mit dem mitgelieferten Installer nicht möglich, bzw. benötigte Nacharbeit.


    LEAP 15.3 ESET Nod32 Linux


    Ich bin mir sicher, bei der Installation nach dieser Anleitung vorgegangen zu sein, kannte mich aber damals noch nicht so gut aus... :/


    Ich verstehe das so, dass der ESET-Installer den Dienst unter /opt/eset/esets/etc/systemd/esets.service

    gepackt hat, aber Leap 15.3 ihn, anders als 15.2, unter /etc/systemd/system/ erwartet. Hing das mit der Angleichung an SLE zusammen?


    --> D.h., ich muss zusätzlich auch manuell unter letzterem gucken, dass dort die Dienste beseitigt sind...?


    Ansonsten bietet ESET noch ein Script an unter

    Zitat

    Method 2: Terminal command

    1. Open a Terminal window by clicking ApplicationsAccessories Terminal.
    2. Type the following command and press the Enter key on your keyboard. cd /opt/eset/esets/bin   
    3. Type the following command to run the uninstaller script: sudo ./esets_gil

    Das werde ich dann ausführen und es ggf. auf Pfadangaben untersuchen.


    Fällt euch sonst noch etwas ein, um nach ESET-Resten zu suchen? Wo könnte ein Virenscanner noch seine Spuren hinterlassen haben?


    Ich will ESET so weit es geht beseitigen, bevor ich auf Leap 15.4 upgrade.

    Bei Desktops mit festem Standort habe ich es bisher immer vermieden, einen USB-Stick oder PCIe-Adapter zu verbauen. Stattdessen habe ich immer Wlan-Accesspoints gekauft, die sich "umgedreht" als Client konfigurieren lassen und diese mit dem LAN-Port des Computers verbunden. In dem Modus können sie sich an andere APs wie den Router, Fritzbox, usw als Client anhängen und bieten über den RJ-Port sozusagen Zugang zum W-LAN.


    Vorteile:

    -grundsätzliche Plattformunabhängigkeit: man braucht nur einen Browser, um auf die Konfigurationsoberfläche zu gelangen

    -man kann am Schreibtisch ein kleines Netz aufmachen und auch andere Geräte (Drucker, Scanner usw. ) darüber anbinden, sodass diese netzwerkweit verfügbar sind

    -mehr Flexibilität beim Antennenstandort

    -man hat einen Accesspoint, den man auch für andere Zwecke verwenden könnte.


    Nachteile:

    -Zusätzlicher Verbraucher mit eigenen Netzteil

    -W-LAN-Daten wie Signalstärke nicht direkt auf dem Desktop ablesbar

    -weitere IP benötigt

    -zusätzlicher Hop und damit evtl. erhöhter Ping

    Ich habe es soweit gebracht, dass ich meine Kone XTD unter Leap 15.3 konfigurieren kann.


    Das Einstell-Tool befindet sich in den offiziellen openSUSE-Repos. Ich habe unter Yast Software nach "roccat" gesucht. Als Ergebnis bekommt man zahlreiche Roccat-Pakete angeboten. Aus dem Namen des Pakets und dem Namen eurer Maus ergibt sich das auszuwählende Paket. Bei mir roccat-konextd.


    Dieses installieren. Leider kann man so noch nicht loslegen. Es werden Fehler-Hinweise kommen, dass das Tool auf bestimmte Devices und Konfigurationsdateien nicht zugreifen konnte. Auch ein Ausführen als su wird scheitern; auch GTK wird im su-Modus meckern...


    Die Seite vom Treiber-Projekt unter Sourceforge

    Chapter 1. General

    gibt den Hinweis:


    Alle User, welche die Maus einstellen können sollen, bitte der Gruppe "roccat" hinzufügen!


    D.h. für den aktuellen User:

    Code
    sudo usermod -a -G roccat $USER

    Wichtig auch der Hinweis, sich danach aus- und einzuloggen und die Maus neu einzustecken, bzw. einfach das System neu zu starten, weil das Tool erst dann funktioniert.


    Eigentlich trivial, aber vielleicht hilft das ja jemandem weiter. :)

    Was ist denn dann für eine abgedrehte Diskussion?


    Bevor man Lubuntu 16.x empfiehlt oder Suse 12.3 in Erwägung zieht, würde ich eher zu Tumbleweed x32 raten. Selbst wenn es irgendwann nicht mehr unterstützt werden sollte, wird der letzte Stand deutlich neuer sein als Lubuntu 16.x oder Suse 12.3... Solange 32-Bit als Target gegeben ist, und das ist stand heute der Fall, bekommt man immer aktuelle Pakete.


    Generell ist 32 Bit überall eher auf dem Rückzug. AFAIK gab es solche Diskussionen auch bei Mageia, aber ohne Ergebnis. D.h. es könnte prinzipiell bei sehr vielen größeren Distributionen 32 Bit plötzlich abgekündigt werden. Eigentlich hat openSUse mit seinen Build-Tools gute Voraussetzungen, eine derart etablierte Architektur weiter anzubieten. Allerdings weiss ich auch nicht 100%, wie hoch der Aufwand wirklich ist... Aber ob es wirklich aufwändiger ist als PowerPC, und seltener im Einsatz ist...?

    Es wird mit der IT-Welt aus meiner Sicht eben immer mehr wie beim Auto. Du kaufst ein Massenprodukt, und kannst als End-User einen gewissen Hauptnutzen daraus ziehen. Was das Auto unter der Haube so treibt, musst du nicht zwingend wissen. Du musst nur wissen, wie du es fährst. Du musst nicht wissen, wie du eins baust...


    Letztenendes ist das genau auch das Geschäftsmodell der SUSE AG. Sie basteln Lego-mäßig aus Open-Source-Teilen ein Betriebssystem, garantieren, dass es auf zertifizierter Hardware auch läuft und leisten Support. Der Kunde muss sich um Einzelheiten nicht mehr kümmern. Er kann das Endprodukt für seine Szenarien einsetzen.


    Und dennoch ist all dies kein Geheimwissen, da im Falle von Linux ja alle Open Source ist.


    Ein mögliches Gegenstück zu Führerschein, Fahrsicherheitstraining und Flottenmanagement im KFz-Bereich könnten z.B. die diversen LPIC-Kurse sein. Einen Rabattgutschein vom Linux Professional Institute befindet sich z.B. in den DVD-Boxen, es ist in der Suse-Welt alles andere als unbekannt. Man bekommt bei LPIC ein offizielles Zertifikat, was man der Bewerbungsmappe anhängen kann... Quasi wirklich ein Equivalent zum Führerschein. Mit dem Essentials-Kurs existiert sogar eine Art Gegenstück zum Rollerführerschein... ;)

    Wer einen "realen Lehrer" braucht, hierfür gibt es auch Anbieter wie B1 Systems, ebenfalls recht SUSE-Affin...


    Beim Aufbau von Linux-Distributionen wird es schon schwieriger. Es entspricht sozusagen einem Maschinenbaustudium beim Auto. Hier würde ich das Linux-from-scratch-Projekt als Einstieg empfehlen.


    Welcome to Linux From Scratch!


    Was die individuelle Kritik des TE betrifft: Zunächst habe auch ich festgestellt, dass grundsätzlich, wenn es mal knirscht, es oft daran liegt, dass man ein proprietäres Produkt eines externen Herstellers einsetzen möchte. Das geht ja schon mit NVidia-Treibern los, wobei diese unter Leap eigentlich ganz gut laufen. Softmaker bietet für sein Office ein eigenes Repo an, wobei hier in der Vergangenheit bzgl. 32/64-Bit-Paketen mit Umbenennungen gearbeitet wurde. Unsauber, funktioniert aber trotzdem stabil. Moneyplex, ebenfalls ein openSUSE-Sponsor, arbeitet mit einem Windows-ähnlichen Installer und internem Update-System, ohne das Paketsystem zu nutzen. Kann auch mit Leben, Paketsystem wäre aber komfortabler.


    --> Bei kommerzieller Closed-Software gleicht die Frage der Integration in die Linux-Philosophie oft einer Wundertüte. Der Hersteller kann gleichwohl eine funktionierende Lösung anbieten oder es vermasseln...


    VM-Ware habe ich nicht getestet. Ist aber letztenendes die gleiche Kategorie (proprietär). Auf der Webseite wird openSUSE /SLE als unterstütztes System geführt. Wenn es nicht out-of-the Box läuft, wäre die Kritik IMHO an VMWare Inc. zu richten. Wenn man sich für VMWare entscheidet, oder es gar kauft wegen dem Versprechen, dass es unter *Suse* läuft, sollte der Hersteller auch dafür Sorge tragen, dass man das Produkt ohne viel Aufhebens eben mit einem *Suse* nutzen kann. Ansonsten könnte man sich auch überlegen. ob man nicht mit einer QEMU-Basis besser fährt... Ich sehe da jetzt wie gesagt kein Versäumnis bei openSuse.



    (Suse könnte hier höchstens mit einem Logo-Programm ähnlich MS bei Windows Abhilfe schaffen. z.B. gab es ab Vista AFAIK das Windows-Logo für Software nur mit msi-Installer und das Programm durfte nicht mehr Konfigurationsdaten ins Programmverzeichnis schreiben...)


    Generell ist aber das schöne an der Linux-Welt, dass man nicht Entscheidungen seiner Distribution hilflos ausgeliefert ist, sondern diese eben notfalls auch wechseln kann. Wenn eine Architekturentscheidung absolut nicht ins Konzept passt und etwas woanders deutlich mehr den eigenen Bedürfnissen entsprechend umgesetzt wurde, muss man nur die Downloadzeit für das jeweilige ISO investieren und kann eine andere Distribution auf Herz und Nieren testen.

    Klar, die einfachste Unterscheidung ist zwischen dem klassischen Leap und dem Rolling Release Tumbleweed.



    Allerdings habe ich heute mit openSUSE-Installationen auf einem Wechseldatenträger herumgespielt und festgestellt, dass dies nur der Anfang ist.


    1) Es gibt noch MicroOS, welches perspektivisch Leap ablösen soll, inzwischen als Micro Leap bezeichnet wird und stark auf Container setzt. Derzeit wohl nur mit GNOME und KDE als Alpha/Beta-Desktops.


    2) Dann habe ich heute noch die Rolle "Transaktionaler Server" entdeckt, was die Systemnutzung wiederum grundlegend anders macht. Hier ist ein Read-Only-Dateisystem die Grundlage (Persistant OS) und es ist wohl möglich im Hintergrund automatisch zu updaten? Man kann sich offenbar jede verfügbare Desktop-Umgebung auf einen transkaktionalen Server dazuinstallieren?


    Nach meinem Verständnis komme ich auf folgende Matrix:

    Klassischer Unterbau
    Persistent (Transaktionaler Server)
    Leap (klassisch, auslaufend), Longtime, Paket-Fokus
    Tumbleweed (Rolling Release), Paket-Fokus
    Micro Leap /ALP (MicroOS), Container-Fokus
    Zukunft?


    Der Trend in den letzten Jahren scheint zu Containern und Persistenz zu gehen. Ich könnte mir vorstellen, dass ein Leap-Nachfolger diese Technologien vereinigt.


    Aber wo kann ein normaler Anwender profitieren? Ich suche ja noch eine gute Lösung für weniger erfahrene Anwender, welche sicherstellt, dass regelmäßig Updates gefahren werden, auch wenn sich der Anwender warum auch immer "nicht traut".


    Naheliegend wäre evtl. eine transaktionaler-Server-Installation von Tumbleweed mit KDE oder XFCE?


    Allerdings besteht eine solche Installation darauf, Paketinstzalltionen wie Paketupdates mit transactional-update statt zypper und packagekit durchzuführen... Die Yast Softwareverwaltung wird zwar mitinstalliert, funktioniert aber nicht. KDE Discover habe ich nicht getestet, vermute aber ein ähnliches Resultat.


    und wie sich transactional-update zu tumbleweed-cli verhält, müsste ich auch noch erforschen....


    Eine Möglichkeit für ein System für weniger erfahrene Anwender: Ein Tumbleweed-Persistent-Kernsystem mit den wichtigsten Anwendungen (Browser, Office, Email usw.) über transactional-update aufsetzen und für eigene Apps auf Flathub verweisen? Allerdings wird es dann wieder so sein, dass die Flatpaks nicht upgedatet werden... Bzw. braucht das Update einen manuellen Eingriff und läuft nicht im Hintergrund...



    Wie ist das eigentlich mit transactional-update.timer und rebootmgr.service auf einem Desktop, der täglich von 8-17 Uhr genutzt wird? Angenommen, die Dienste sind so eingestellt, dass das System nachts um 3 die Updates holt und neu startet... Der PC ist aber ausgeschaltet. Wird das dann nachgeholt, wenn der PC wieder startet?