Secure boot is a good thing. It's a security feature. You want it on whenever possible, unless it's a huge trouble (like if you have to start manually signing your own keys and adding them to the bios).

Edit: added the word manually

Linux supports secure boot so if a distro supports it it's worth using it.

Linux can use a key signed by Microsoft in a preboot loader and then itself perform its own key authentications for all other processes and software (a shim), forming a secure chain from the BIOS up during boot. You dont have to play with creating your own keys.

So if your OS supports secure boot it is worth using it for added security at boot. Its far from perfect in this set up (as there are plenty of windows OS that also have permission to boot) but it is better than a free for all without it even if the risk is very low.

You can go further an generate your own keys and use secure boot and TPM together to lock down the system further but you dont have to to get some benefits from secure boot.

Its not doing nothing. Linux uses a Microsoft provided key for initial BIOS authentication and then has its own tree of keys that it uses for security. So it does have the benefits of locking out malicious code/processes even in a default set up.

Using your own secure boot and TPM keys is certainly more secure, but it doesnt follow that secure boot with the default set up is doing nothing to help secure your system at boot.

If your linux OS supports secure boot then it does help improve security.

The differing opinions on it are often because it can cause issues in some set ups andninna default set up and its only a marginal security gainninnthebdefault set up.

It will add a layer of security at boot by preventing 3rd party unauthenticated processes / software from running and creates a secure boot chain from your BIOS up to the OS. But the default set up also means other authenticated OSes like Windows can be run, so its not as secure as it could be.

To really secure it you could create your own keys and then only your OS could boot. But as a linux newbie thats likely way more than you need and there iare risks of you fuck up.

So your choice is really just the default set up being on or off. On is a bit more secure but of you experience any issues then turn it off and don't sorry about it.

Debian has a good page on it and how their set up works:

wiki.debian.org/SecureBoot

Edit: Ubuntu is derived from Debian and then Mint from Ubuntu, but they may have their own differing approachsnto secure boot.

As always, the answer is "depends". It shouldn't hurt unless you're dual-booting windows (they used it last her as a weapon in their "mess up grub" game), but, Imo, it's worth the trouble if:

• your data is also encrypted -- otherwise one just removes the HDD/SSD and reads what they need;
• you provision your own keys -- to not depend on Microsoft signing shims for you;
• you delete the already provisioned keys -- Microsoft signed a few vulnerable things, like one kaspersky's (iirc) live CD with grub not locked down, so one can boot up literally anything anyway;
• you lock down grub or whatever bootloader you're using -- otherwise you become that vulnerable live cd;
• you password lock the uefi -- otherwise one can simply disable the secureboot;
• your vendor's implementation isn't terribly buggy -- iirc, some MSI laptops would just ignore all the discrepancies.

So, a lot of ifs, and a necessity to store the uefi password somewhere safe, as those may be a pita to reset.

As for standalone stuff -- idk, it might protect you from malware injecting itself into the bootloader or something, but given there's likely no chain of trust (I.e. the bootloader doesn't check what it bootloads), it can move in on some later step.

Simply: Do the protections against someone taking your computer and installing a malicious program before u, or a program that has attained root on your machine and installs itself before/as your OS, matter enough to you to justify the increased risk of being locked out of your machine and the effort to set it up and understand it.

If you don't understand and don't want to, then my advice would be to leave it off. Its simple, and the likelihood it saves you is probably very miniscule.

Well if you use a Linux distribution, you generally get your software from some central package repository. That's driven by maintainers who look at the software, the updates... They patch the software, make sure it runs smoothly on your system and is tied into other things... They'll also have a look at security vulnerabilities and security in general.

Other than that, there isn't much really "stopping" people from writing malware. We have tons of it. Fake VLC versions, copycats on the iPhone appstore... MS Windows is full of advertisements and features that send data "home". They introduce features which border on being malware all the time.. We have trojans, viruses etc. It's all out there.

Generally, it's a good idea to think before executing random code from the internet. Is it from a trustworthy source? Are other people using a piece of software and they'd have noticed if it deleted all files?

Usually, we have more good people than bad. And people need some motivation. It's unlikely someone invests 10 years of their life to develop a shiny and polished office suite, just so they can run some malware somewhere. There are easier ways to accomplish that. So it generally doesn't happen that way. It's theoretically possible, though.

And in the old way is: Windows, Android etc are way more popular. If someone wants to do something malicious, they likely don't target the 1-2% using a different operating system. They are going to write malware for a more popular operating system. And on the server, where Linux dominates the market, admins execute less random code. They'll know they want MariaDB and where to get it. So it's harder to do an attack this way.

And if I imagine being the attacker... What would be a reason to include malware in a FOSS project? Just to wreck havock and mess with people? That sounds like a 16 yo with too much time on their hands. But we have very few of those in the free software community. So that's a bit unlikely... If someone wants a botnet, there might be easier ways to do it. And for a targeted attack, you wouldn't hide your malware in a random project... So I generally don't see many reasons for someone to combine malware with useful FOSS software.

🙁){ :|:& };:

If it’s open source, then the source code of the malware is also open. Generally, binary blobs aren’t included in open source programs, and when they are with no good explanation, it raises a lot of suspicions.

Closed source is where malware can readily be hidden, which is why there is tons of malware hidden in Windows and Android apps.

As others have pointed out, the extensions are likely not (officially) compatible with the new version of GNOME yet. Which extensions are you having trouble with?

There are a couple of extensions that are available for installation through dnf for which Fedora takes care of making them compatible at the same time at which they make available a new version of GNOME. Caffeine and Dash To Panel are two examples. For a full-ish list, try dnf search gnome-shell-extension.

Alternatively you can also try manually editing the extension's metadata to "make it compatible". Your mileage may vary with this approach, but it worked fine for Net Speed Simplified, for example.

This is why – if you want to keep your extensions – you wait with upgrading to a new Gnome version until your extensions support it...

AFAIK there is no stable extension API, leading to breakage with every version upgrade

Disclaimer, I'm not in front of my computer to check, but it looks like its /etc/netplan/

netplan.readthedocs.io/en/stab…

I don’t even know css

Blinds all of us

yeah, I use Thunderbird, but it bothers me how slow it feels and the frequent little UI bugs with unread flags not updating and the delay of messages to show up in the unified inbox.

It's nice that Betterbird has a system tray (I can't believe how a standalone desktop app for emails neglects this, like TB does), but it still inherits a lot of the problems TB has.

Personally, I use mu4e (part of the mu software) to read, organise, compose and send emails. It uses a text-based interface, and runs from within the GNU EMacs editor. Emails are stored locally in the Maildir format.

• It is actively maintained and open source, and not controlled by a company
• Apart from xapian and EMacs, chances are that you have the dependencies already installed
• Mails can be composed in HTML format, but this may take a few extra tweaks. (I do not do this myself.)
• Emails have to be stored in the Maildir format to be indexed using mu and viewed with mu4e
• Neither POP nor IMAP are directly supported. To fetch or sync emails from/with an external server, external applications can be called, like mbsync (for IMAP), offlineimap (same), or fetchmail in unison with a locally running postfix MTA (for POP)

I am not sure if I can recommend this solution, as it can be a bit technical compared with other email clients. For me, it is entirely worth it, though.

Evolution.

I have used Thunderbird a lot, but finally decided to go back to Evolution 2 years ago.

It’s trivial. Use Linux Mint or Debian, enable non-free repositories if required, and that’s pretty much it.

I’ve never had issues with Nvidia drivers. Your mileage may vary.