Beiträge von LinKostik

Zitat von El Pollo Diablo

Ok, ein paar Komfortfunktionen aus den anderen Distros hätte ich mir gewünscht (z.B. automatische Sudo Berechtigungen für während der Installation von Debian hinzugefügten User)

Sudo-Berechtigungen erhält der User dann automatisch, wenn Du während der Installation von Debian das Root-Passwort leer lässt. Du musst also selbst abwägen, ob Du einen "vollen" Root-Account benötigst. Insgesamt ist Debian ja eben keine Distri, die sich für Anfänger eignet, wie z. B. ein Linux Mint oder Ubuntu. Aber zum Lernen ist es ohnehin sinnvoll, sich eingehender damit zu befassen. Und dann hast Du - ein bisschen wie auch bei Arch oder Void, nur eben nicht rolling - mit Debian ein System, was auf Deine Bedürfnisse angepasst ist.

Stardenver
Danke für die Anleitung, aber wie man TRIM bei vorhandener LUKS-Verschlüsselung umsetzt, ist mir bekannt, meine Frage war eher, ob nach aktiviertem TRIM durch "allow discards" die LUKS-Verschlüsselung überhaupt noch Sinn macht. Dennoch habe ich mich dafür entschieden, weiterhin auf allen meinen Geräten eine Vollverschlüsselung mit LUKS einzusetzen.

Hier habe ich allerdings eine neue Frage. Da man ja beim Start ohnehin das Entschlüsselungs-Passwort eingibt, mag ein Autologin des Users sinnvoll sein, um das nicht jedes Mal doppelt eingeben zu müssen. Bei Manjaro Xfce würde mich aber dann der Gnome-Keyring nerven, da ich bei jedem Start den Nextcloud Desktop Client mitstarte, dessen Passwort entsprechend im Keyring hinterlegt ist. Damit hier auch nicht immer eine Passwort-Abfrage kommt, muss man das Passwort des Keyrings blank lassen, wenn man Autologin nutzt. Ansonsten würde dieser nämlich einfach beim User-Login mit entsperrt. Hier die Frage: Ist es sinnvoll, doch auf das Autologin bei vorhandener LUKS-FDE zu verzichten, um den Keyring gesichert zu halten, oder ist das unter den Umständen gleichgültig?

Mittlerweile muss ich sagen, dass meine subjektive Einschätzung schnelleren Programmstarts von heute Morgen sich etwas "gelegt" hat. Einen Performance-Gain sehe ich nunmehr eigentlich nur beim Bootvorgang. Hierbei kann ich aber bislang auch nicht sagen, ob das an Manjaro liegt (verschlüsselte /boot ?) und ob sich das bei anderen Distris anders zeigen würde. Andere Distris installiere ich eigentlich derzeit nur in VMs, Manjaro Xfce ist mein Produktivsystem.

Gesetzt dem Falle, irgendeiner würde meine IP missbrauchen, sich in mein Netzwerk hacken (was ich für ziemlich unwahrscheinlich halte) und es dann zu einer Durchsuchung aufgrund falscher Spur käme, würde man auf meinem System ohnehin keine Inhalte finden, die für deutsche Behörden unter normalen Umständen irgendwie von Interesse wären, zumindest gehe ich nicht davon aus. Gleichwohl habe ich beruflich wichtige Daten auf allen Computern, da diese sich mit meiner Nextcloud synchronisieren. Aus der einen Ecke hört man, dass es besser sei, alle Geräte zu verschlüsseln, andere sagen, dass das nur bei Notebooks einen entscheidenden Sicherheitsfaktor ausmache, der so bei Desktops nicht gegeben sei. Notebooks sind bei mir natürlich grundsätzlich vollverschlüsselt. Ich bin etwas am Schwanken. Wie sieht das denn mit dem TRIM der SSD aus im Falle einer Vollverschlüsselung? Ist letztere dann noch sicher, wenn das Kernel-Parameter "allow discards" gesetzt ist, was hierbei für TRIM erforderlich ist, oder ist die Verschlüsselung dann einfach nur noch "besser als nichts"?

Guten Morgen, Stardenver
danke erstmal für Deine Antwort! Ich habe einfach mal testweise einen Desktop-PC ohne LUKS installiert und ich muss im Nachhinein einen gefühlt sehr deutlichen Zugewinn an Performance feststellen. Das Booten geht mit Manjaro Linux (Xfce) ohne LUKS erheblich schneller, gefühlt habe ich auch den Eindruck, dass Anwendungen, insb. der Firefox, schneller starten. Das ist möglicherweise aber eher subjektiv. Was ich auch für nicht ganz unerheblich halte, ist die TRIM-Funktion bei SSDs, die bei vorhandener LUKS-Verschlüsselung standardmäßig deaktiviert ist - eben aus Sicherheitsgründen. Hier stellt sich dann die Frage, ob eine Einrichtung von LUKS sinnvoll ist, wenn man ohnehin wieder einen Teil von dessen Sicherheitsmechanismen quasi aushebeln muss (allow discards), um Langlebigkeit und Performance der SSD so gut wie möglich sicherzustellen. Davon, dass ich meine SSD verkaufen werde, gehe ich derzeit nicht aus. Es ist scheinbar eine Frage von Kompromissen, und gar nicht so ohne weiteres zu beantworten. Was nutzt Du denn?

Hallo zusammen,

was meint ihr, macht es Sinn, auch auf einem stationären Desktop-PC eine Vollverschlüsselung mittels LUKS einzusetzen? Ich habe bisher alle meine Rechner mit LUKS verschlüsselt, vor allem bei meinen Notebooks erachte ich das als wichtig, weil ich sie mitnehmen muss, wenn ich unterwegs bin. Da ist ein entsprechendes Sicherheitskonzept schon alleine für den Diebstahlsfall sinnvoll.

Meine beiden Desktop-Rechner werden hingegen nicht an andere Orte mitgenommen und es gibt auch keinen Zugriff durch Fremde, eben nur durch meine Familie. Aus Gewohnheit und zusätzlichen Sicherheitsbedenken habe ich jedoch auch hier die LUKS-Verschlüsselung eingerichtet. Da ich aber bei meinen Desktop-PCs Wert auf Performance lege, frage ich mich, ob es überhaupt Sinn macht, hier eine Vollverschlüsselung zu verwenden. Einbruchsgefahr sehe ich bei mir zu Hause auch nicht wirklich, jedoch sind Daten auf meinem Computer, die u. a. beruflich sehr wichtig sind. Ein Großteil davon wird außerdem mit einer selbst aufgesetzten Nextcloud-Instanz auf einem Raspberry Pi 4B synchronisiert. Was meint ihr, LUKS-Verschlüsselung am Desktop, ja oder nein? Wie handhabt ihr das?

Herzliche Grüße

Epson EcoTank ET-15000, funktioniert problemlos. Es gibt extra Linux-Treiber auf der Herstellerseite, für Arch-basierte Distris ist er im AUR unter dem Namen epson-inkjet-printer-escpr2 zu finden.

Meine Familie und ich setzen hauptsächlich auf Manjaro (Xfce) als Produktivsystem, es funktioniert reibungslos. Nebenbei setze ich noch EndeavourOS und reines Arch als Coding- und Bastel-Systeme ein. Auch diese laufen anständig. Hin und wieder probiere ich auch andere Distros aus, aber den Arch-Unterbau habe ich mittlerweile am liebsten. Wenn man einigermaßen weiß, was man tut (siehe AUR etc.) dann ist auch ein Ach-basierendes OS stabil einsetzbar.

Ich kann mir nicht vorstellen, dass Flatpak Hauptwerkzeug für die Softwarepaketierung in Manjaro würde, das stieße in der Community sicherlich auf großen Widerstand. Und so, wie ich Manjaro bisher erlebt habe, wird die Community durchaus gehört. Gerade die bequeme Softwareveraltung mittels pacman in Kombination mit dem AUR war bei mir ein Argument für Manjaro und andere Arch-Derivate wie EndeavourOS. Manjaros Pamac tut da sein Übriges, um auch Anfängern den Umgang damit zu ermöglichen.
Beim AUR sehe ich gegenüber Flatpak den Vorteil, dass das System nicht allzu sehr aufgebläht wird, die Pakete werden ja anhand der PKGBUILDs auf dem eigenen System kompiliert, was noch einmal mehr ein Garant für gute Lauffähigkeit sein kann (nicht zwingend muss, aber kann). Wie gesagt bläht die Verwendung vieler Flatpaks das System doch recht stark auf, bedenken wir hier, dass bei einer Verwendung von Flatpak als Haupt-Paketiersystem dies noch exponentiell gesteigert würde.
Obwohl ich Linux Mint sehr schätze als hervorragendes "Anfänger-Lnux" oder als OS, das "einfach läuft", empfinde ich schon den Ubuntu-Unterbau als recht "fett", manchmal sogar träge gegenüber einem Arch-Unterbau. Wenn jetzt Manjaro vordergründig auf Flatpak setzen würde, wäre es noch viel fetter, und das wäre einfach schade. Wie man ein Arch-basiertes OS fett kriegen kann, zeigt Garuda Linux in seiner KDE Drangonized-Edition m. E. einigermaßen eindrucksvoll... Das brauche ich bei Manjaro nicht wirklich. Und da bin ich sicherlich nicht der Einzige.
Manjaro befindet sich gerade auf einem recht guten Weg, ein System zu werden, dass auch Linux-Neulinge abholen kann. Einigen meiner Kunden und Freunde, denen ich Manjaro installiert habe, gefällt das besser als Mint, obgleich sie auch das mochten. Es wurde ihnen allerdings durch PPAs zu träge mit der Zeit und es war auch irgendwo nervig für sie, alle halbe Jahre neu zu installieren, oder über das Terminal auf eine neue Hauptversion hochzuziehen, z. B. von Mint 19 auf 20. Das ist bei Manjaro bequemer - und ja, ich bin mir auch der Nachteile eines RR bewusst, aber diese werden durch Timeshift in Kombination mit BTRFS und autosnap ohnehin gering gehalten, wenn überhaupt mal etwas auftritt. Man sollte das Gewonnene nicht durch Ballast verspielen, auch wenn Flatpaks durchaus auch eine praktische Lösung sein können. Aber als Generalformat taugt das m. E. nicht.

Zitat von nicoletta

Ich weiß nicht genau wie es mit den Versionen bei Mint ist, jedoch unter Ubuntu macht das keinen Unterschied. Will ich nur LTS Versionen (Beispiel 20.04) bekomme ich 2 Jahre jeweils alle 6 Monate eine Pointversion (20.04.1 - bis derzeit aktuell 20.04.2) angeboten bis zur nächsten LTS-Version (22.04). Nun kann ich entscheiden ob ich ein Upgrade will, oder weiterhin Pointversionen (20.04.4 ...5 ....6...) für meine aktuelle LTS nutzen möchte.

Genau darauf bezieht sich ja der zugrundeliegende Punkt, auf den ich hinaus will. Prinzipiell ist es bei Linux Mint ja so, dass sich ein Versionsupgrade über die grafische Aktualisierungsverwaltung nur von Point Release zu Point Release durchführen lässt, also seinerzeit etwa von Version 19.0 auf 19.1 usw. bis 19.3 respektive von Version 20.0 auf die aktuelle 20.2. Das funktioniert, indem man in der Aktualisierungsverwaltung nach Einspielen aller angezeigten Updates oben im Menü auf "Bearbeiten" und "System auf Version X.X aktualisieren" klickt. Das läuft allermeistens unkompliziert und schnell. Möchte man jetzt aber bspw. von Version 19.3 auf Version 20.0 aktualisieren, um dann mittels o. g. Option auf 20.2 zu upgraden, so sind einige manuelle Eingaben im Terminal erforderlich, um dieses Upgrade mittels mintupgrade durchzuführen, nebst Wartung der PPAs etc.
Einem Anfänger, oder jemandem, der einfach nur ein System haben will, das einfach nur läuft, wäre das m. E. kaum zuzumuten. Für mich bedeutet das bei meinen Kunden auch einen entsprechenden Wartungsaufwand, der für mich keine Dauerlösung sein kann. Daher wäre es doch sinnvoll, wenn sich ein solches Distributionsupgrade über die Point Releases hinweg einfach genauso über die Aktualisierungsverwaltung durchführen ließe, wie ein Upgrade innerhalb eines Release-Zyklus. Die technische Umsetzung wäre sicherlich recht unproblematisch und man würde die Update-Politik von Mint nicht verletzen. Es hätte m. E. keine wirklichen Nachteile.

Vielen Dank erstmal für Eure Antworten, offensichtlich scheint das Thema ja durchaus von Interesse zu sein....

Zitat von Sojan

Es wird argumentiert, dass LTS-Versionen besonders sorgfältig abgestimmt sind und dadurch sehr stabil und sicher laufen. Der Preis sind mit der Zeit aber völlig veralterte Programme. Um dieses Problem zu umschiffen, hantieren viele mit Snap, Flatpak und PPA herum und gefährden ihr System damit mehr als es ein Rolling Release je könnte.

Na ja, hab mich vielleicht etwas undeutlich ausgedrückt zum Schluss. Mit meinem Upgrade-Ansatz meine ich ja kein Anheben des Ubuntu-Unterbaus auf Nicht-LTS-Versionen, sondern durchaus könnte man dabei innerhalb der LTS-Zyklen bleiben, also das Grundprinzip der Upgrade-Politik von Mint beibehalten - nur, dass man eben auch den Upgrade-Prozess von einem Versionszyklus in den nächsten genauso automatisieren könnte, wie das Upgrade innerhalb eines Versionszyklus. Es würde doch viel Arbeit ersparen und sicherlich auch ein in sich konsistenteres Distributions-Upgrade ermöglichen als das Gefrickel mit dem Terminal. Für nicht allzu Wenige besteht darin ein Grund, von Mint auf Distris wie Manjaro zu wechseln. Wobei die o. g. Idee ja nicht bezweckt, Mint zu einem Rolling Release zu machen.

Edit: Das Problem, was Du ansprichst, insb. mit den PPAs, lieber Sojan, war ein Grund, warum ich mich entschloss, vorwiegend Manjaro einzusetzen. Einen "rollenden Kompromiss" irgendwo zwischen Arch und einem LTS-ähnlichen Stable-System bekommt Manjaro mittlerweile sehr solide hin (wobei ich sagen muss, dass auch Arch selbst bei mir sehr gut läuft, aber ab und an muss man hier doch manuell nachhelfen). Flatpak macht ja in sich eigentlich kaum Probleme, zumal es sich um ein Software-Container-Prinzip handelt, gerade eben um Probleme mit Abhängigkeiten zu umgehen. Letzteres kann bei PPAs zu einem sehr großen Problem werden, habe ich selbst schon erlebt. Dennoch mag ich Mint nach wie vor gut leiden, und insbesondere für Anfänger, die ein System haben wollen, das einfach nur läuft, ist es gut geeignet. Daher eben auch meine Upgrade-Idee.

Hallo zusammen,
ich bin erst seit recht kurzer Zeit in diesem Forum angemeldet und das ist mein erster Beitrag hier... . Erst einmal vielen Dank an Jean und alle Beteiligten für das Projekt "Linux Guides", das hilft, auch Einsteigern Linux zugänglicher zu machen.
Nun, ich möchte mich jetzt nicht mit einer Frage an die Community wenden, sondern mal eine Idee einwerfen: Im Rahmen meiner beruflichen Tätigkeit arbeite ich zu einem überwiegenden Anteil mit Linux, meine Haupt-Distributionen sind Manjaro und Arch, habe aber auch schon diverse andere Distris benutzt, darunter Linux Mint. Letzteres läuft bei mir noch auf einem meiner Produktiv-Systeme.
Mint hat mir vor einigen Jahren einen unkomplizierten und produktiven Vollumstieg von Windows auf Linux ermöglicht, meine Familie und viele meiner Freunde und Kunden nutzen seither ebenfalls Linux. Als Einstiegs-System in die Linux-Welt habe ich bislang meistens Linux Mint mit Cinnamon DE empfohlen und für andere installiert. In der letzten Zeit häufen sich aber Rückmeldungen an mich, dass man gerne ein "unkomplizierteres" Distributions-Upgrade von Linux Mint 19.x auf 20.x hätte. Den Upgrade-Pfad via Terminal zu benutzen, ist an sich zwar nicht wirklich schwierig und wird auch auf der Mint-Website zum Release immer beschrieben, aber einige Anfänger fühlen sich damit überfordert und halten fast eine Neuinstallation für weniger kompliziert. Diese wollen sie aber nicht durchführen, man möchte nicht jedes Mal das System neu einrichten und auf die eigenen Bedürfnisse neu anpassen müssen. Diejenigen, die das betrifft, ziehen mittlerweile Manjaro vor, hier ist es unkompliziert, das System aktuell zu halten und eine Neuinstallation oder manuelles Upgrade-Gefrickel entfallen, insofern das System konsistent bleibt. Größere Fehler, die Systemausfälle nach sich ziehen, bleiben auch bei Manjaro mittlerweile allermeistens aus. Natürlich sind mir die Unterschiede zwischen einem Point Release und einem Rolling Release-Modell inkl. Vor- und Nachteile bekannt, aber:

Könnte man nicht in die Mint-Aktualisierungsverwaltung einen Button integrieren, der nicht nur das Upgrade innerhalb eines Versionszyklus (z. B. 20 auf 20.1 oder 20.2) ermöglicht, sondern optional auch zwischen den Zyklen wie 19.x auf 20.x, also mit Anheben des Ubuntu-Unterbaus etc.? (natürlich mit entsprechenden Hinweisen u. a.) Ähnliches kennen wir ja bereits von Fedora oder auch aus den Nicht-LTS-Zyklen von Ubuntu. Es ist relativ aufwändig für mich, jedes Mal bei einem Major-Release von Mint diverse Computer von Kunden, Freunden usw. manuell auf die aktuelle Version hochziehen zu müssen. Ich stelle mir das als möglichen Kompromiss vor für diejenigen, die bei Mint bleiben möchten aber nicht etwa alle halbe Jahre neu installieren möchten bei Systemen, die eigentlich zufriedenstellend laufen.

Entschuldigt den allzu langen Post. :roll:

Herzliche Grüße

Kostja