Peppermint OS is a Debian variant with XFCE desktop. Haven't used it myself, but I do generally like XFCE desktops on Debian variants; I used Xubuntu for quite a while few years ago.
I do like using Synaptic for package management. It makes it easy to find interesting programs to try, and install them. (If additional packages need to be installed, it will tell you, and ask you if that is okay.) To find something, you can press Ctrl+F, type in the word(s) you're looking for, and select whether those words should be in the name only (rarely) or name and description (typical). You mark which packages you want to install, then click on the Apply button to actually download and install those packages.
In the Settings menu in Synaptic, there is a Repositories entry. This is a direct interface to the Debian package manager repository list (apt sources; /etc/apt/sources.list and files in /etc/apt/sources.list.d/). You basically list there the repositories you trust. A repository is a repository: a site set up to provide a set of packages. There are both official ones (and with Debian, with lots of official mirrors, at least one in almost every country, which can speed up downloads a lot), as well as experimental and personal ones (often called PPAs, Personal Package Archives, from Ubuntu, which itself is a derivative of Debian).
As Peppermint OS is a Debian derivative, you should prefer the default Peppermint OS repositories. However, you should be able to install any Debian package (for the same Debian release as the Peppermint OS release you use; currently Debian 11, "Bullseye"), and use any Debian package repository (that provides packages for that Debian release). It is highly likely, but not exactly guaranteed, that applications provided by Ubuntu PPAs, will also work fine.
You usually also have a separate update manager, which occasionally checks if any of the packages you have installed have newer versions in any of your repositories. I don't know which one Peppermint OS uses, and it doesn't really matter: just don't leave Synaptic open when you don't need it, because having one open will block all other ways of updating or installing software, including on the command line.
If you cannot find synaptic in the menus, it probably isn't installed. You can install it by running
sudo apt install synapticon the command line. It will ask your password, because as an user, you do not have the privilege of modifying the system configuration.
sudo is a command that grants you superuser privileges, if you can have them. (It can also do other stuff.)
Do not download packages off the internet. Use your package manager / Synaptic. Do not download source trees and compile them yourself, because that is almost always wasted effort. (The exception is if you need or want to try out bleeding-edge features being developed right now.) Do not trust installers, that say "download this, and then run this to install it on your machine", unless you're absolutely sure about it; and then only if the installation instructions do not use "sudo" or "su" and the installer does not ask for your password.
(When installing e.g. Arduino development environment, or something like the Teensyduino add-on for Teensy development, you may need to provide your password for the installer to install what are called "udev rules". These are rule files that allow specific users or groups direct access to for example USB devices, and are needed for the firmware uploaders to work. So, there are exceptions to the above; just consider the source, and make up your mind, instead of going at it blindly. A bit of extra suspiciousness in the era of Internet is warranted.)
Though fail2ban should not be seen as a security measure if used for a SSH server.
Correct. I think it of more as a "oh shut up already" measure, occasionally checking the fail2ban log to see how intense the SSH scripting attacks happen to be; like weather.
This does not mean I claim Linux is impervious to viruses and attacks, because it isn't; I only mean that Linux users do not need dedicated antivirus software to protect themselves. They do need to be careful and consider their actions as the user and administrator of their own machine.
In particular, by default, files that you save are not executable. (Any guide that tells you to run a
chmod command of any sort must explain exactly why that command is run, and what kind of security implications that has. Any "guide" that tells you to run
chmod 0777 anything is an invitation to disaster, and not something you should ever follow.)
This means that if you say save an image attachment you received via email, and double-click it, and it really is something else like an executable, the user interface should just try to open the file in an appropriate viewer or editor, or prompt you which program to try to open it in; and never try to execute it instead.
This alone, even if considered a nuisance by some users, stops a lot of worms.
Viruses that infect a Linux user by piggybacking on something (say, exploiting a bug in a viewer or editor), are also either limited to the privileges of the current user (and unable to modify system binaries, only files the user owns), or need to also exploit local privilege escalation flaws. Without privilege escalation, running on the user privileges alone, a virus cannot modify the firewall settings, or replicate itself into the system.
On Linux desktops, viruses are very rare, for many reasons. Perhaps the biggest one is that only a tiny fraction of all desktops run Linux, and those that do run Linux, run on wildly differing Linux distributions, making them vary too much to offer an interesting target. (Linux servers are much more often targeted.)
Instead of antivirus programs that try to detect viruses and worms, Linux users are currently better off keeping their systems up to date with respect to security updates, and especially adopt safer practices wrt. files and attachments of dubious origin. Instead of downloading an installer from who knows where, you use package manager, which uses known "trusted" package repositories. (But those repositories can be compromised, though; even Debian has been. They're usually detected very quickly, though.)
Home
Help
Search
Login
Register
