I use kvm switch and run into this issue.

I am currently on Fedora 41, Gnome. I’ve seen this issue when running Arch on the same hardware without kvm switch to the point that I disabled suspend.

The fix for me is Ctrl-Alt-F1. It simply brings display manager’s login screen. Gnome on Fedora 41 uses gdm.

The rationale here is simple: the display manager should be resetting screen to display login screen.

I switched to XFS.

The most important feature to me is support for file deduction which is supported by XFS through reflink. BTRFS supports reflinks as well.

Snapshot in BTRFS seems like the most desirable feature, but in real life I ended up not using it.

I usually prefer drive mirror setup, but it can give its own headaches.

These days I simply have 2 disks and nightly rsync job copies content of one drive to another. This protects from drive failure.

Rclone job sends most important data to offsite backup.

The biggest loss is missing data checksums, but it is a unique feature of BTRFS that most filesystems manage without.

I don’t have setup to expand partition beyond one drive. It comes with its own headache. I simply use large enough disks.

He was running long installation process from command line and lock warning was probably appropriate.

He was probably supposed to mark downloaded .run file executable. Instead he went to collect errors.

~/projs

I like ~/w or ~/p options

Vscode is installed on windows. Then you install vscode ssh plugin from Microsoft and open ssh connection from vscode to any Linux including WSL hosted Linux.

I am a software developer and work on Kubernetes based project.

I was given a Mac laptop when I joined. It was a few OS releases behind, because corporate IT didn’t support newer versions.

Macs have to run some sort of VM to do docker based development.

VMs are not that great.

When time came, I requested a Windows laptop. I installed Debian on WSL 2. Then got it to run systemd properly and installed Docker on WSL. Then vscode on windows host with remote ssh into WSL.

Vscode ssh integration is probably best least known feature of vscode. However, initial connection setup always requires tweaking to get that best experience.

By the way, official docker setup is through VM on windows. WSL is not a recommended route, but one can get it working.

This setup beats Mac any day for me.

I wish I could run Linux on work laptop, but corporate IT doesn’t know how to deal with it.

My wife complained that Mac got worse at searching samba shares.

Corporate support for Macs is usually worth than on Windows.

It is a very risky move.

Fedora atomic or not is nice.

I got tired of manually installing Arch and was pleased with Fedora the most.

I actually run away from Mac. Mac OS X is long time as not Linux.

WSL is a way better option than whatever VM option is on Mac.

I am happy with WSL as well. I don’t try to get Linux GUI running.

I use vscode remote ssh session. I run docker natively on Linux, not on windows.

The trick is to get DBUS services running in whatever flavor of Linux you install. Don’t try running a full UI session.

The biggest problem I have on Linux is time drift after laptop goes to sleep. it is easy to deal with manually.

Cargo is heavily used.

Your tutorial is the odd one.

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ is a good summary about the issue

Good counter discussion about PGP security

https://www.reddit.com/r/cryptography/comments/10cfslk/exactly_how_strong_is_pgp/

I would argue that latacora could be an attempt to push users into the systems that provide 3rd party service, which by definition of 3rd party service is not secure: WhasApp, Signal.

Only true P2P can be safe. PGP provides ability to send encrypted message using any means necessary: FTP, HTTP, anonymous services, USB sticks, anything.

why encrypting mail in general is bad at https://www.latacora.com/blog/2020/02/19/stop-using-encrypted

The point about email having leaking matadata is 100% spot on.

The argument why Signal is better is very short and not substantiated IMO.

Be aware, that trusted Certificate Authority (CA) configuration applies to ALL certificates issued by CA. Thus, if one elects to trust “actalis” CA, then they trust ALL actalis CA users.

If the process of obtaining certificate was extremely simple, easy and did not involve identity verification steps, then bad actors can take advantage of this process and create identities that your client application will trust.

By itself the bad actor identity is of little concern to anybody, but it can have a significant impact if trusted identity is used in spam filtering, exploits of email client bugs or other hack attempts. Trusted users may be given higher access privilege at the client application level, which may be just enough for hacker to gain required access. For example, client application may be configured to trust all trusted senders with MIME attachments. An unknown trusted user sends malicious Application as file attachment. Accidental double click lunches the application without “are you sure?” prompt. Congratulations, machine is pwned.

The problem is easily mitigated by not importing root CA for easy CAs.

What I take issue with actalis, is that they don’t just sign your private key but you actually get the private key from them. It then depends on how much you trust the issuer.

By definition, that key can no longer be considered “private”.

It is very important to emphasize that the key in this model is not “private” anymore. Thus, all the communication using this key is not secure anymore.

Private key is the one generated by hardware owned by the user and immediately secured with strong password. Ideally, private key does not leave the hardware that generated it. Thus, every device shall have its own private key.

In less restricted model, private key gets copied by the user to other hardware using media like USB stick or P2P communication model that does not use cloud services.

Yes, it exists.

S/MIME requires the receiving side to have its own certificate or, to be more correct, a private key represented by the certificate. The recipient’s certificate needs to be known to the sender. The sender’s certificate needs to be known by the recipient. That’s why S/MIME is not used. It requires configuration on both sides, before it can be used.

Most people don’t know how to obtain certificate and configure email client with it or don’t bother to obtain certificate even if they know. The same problem exists if PGP is used, even if it is a bit different.

I will cover S/MIME and PGP because of similarities.

S/MIME or certificate based solution is supported by many clients, so it is easier on end user than PGP. S/MIME is part of the specification, that’s why good email clients have built-in support. S/MIME problems are all around certificate management: how to obtain certificate (free or not), how to import certificate, how to trust certificate, how to import trusted root of the certificate.

It is easier to manage keys for free in PGP. PGP has no protocol level support in email clients, so it requires additional handling of underlying content. In effect PGP encrypted messages are injected into text message or sent as email attachments. In both cases PGP content has to be handled by external application (PGP encrypted text or image) or email client specific plug-in.

The technology is very old for both cases. It has not caught on due to friction of key management for both technologies. PGP has additional problem of content handling.

S/MIME is perfect if you want to communicate with family or friends as you can ensure everyone in your circle has their own private key. Even in this narrow case, I guarantee you will experience some friction to get this through.

Organizations can have it easier as they can issue certificates to their users. But then problem of trusted certificate authority comes into play, if they use their authority (every email client or OS running this email client has to import new Trusted Certificate Root, that is hard at ORG level and it gets worse when they have to tell their outside contacts how to work with them). If they use well known authority, they avoid Trusted Cert Root problem, but they have to pay for every user certificate.

So, you can see how there’s friction in S/MIME solution. IMO, S/MIME is a good solution, but friction made it unrealistic in major use cases.

At this point I recommend Delta Chat. I am not involved with it. I just like what I see. It is uses PGP technology. In the end it is looks like a modern P2P chat application with all the expected Chat functionality, but it is actually an email client sending PGP encrypted messages over email. Delta chat solved private key creation using built-in key generation. Public key exchange is solved via key exchange protocol. The problem of content attachment is solved by the application itself. Take a look at articles about it https://delta.chat/en/references

Signal vs Delta Chat. Signal metadata exposes your contacts and probably your time of contact. With Delta Chat you get the same level of meta data exposure: your contact and time of contact are in the open, because underlying protocol is email.

S/MIME protections. S/MIME keeps the same metadata in the open: contact and time of contact. That’s because S/MIME protects the payload (message body), not the email protocol headers.

I might be a bit off on how PGP or S/MIME is passed around at SMTP headers level, but overall meaning shall stay the same.

There are no shades of grey in encrypted communications.

Your messages are either plain text or not to 3rd party.

Sometimes it appears to be encrypted, but there loopholes that make it possible to significantly reduce decryption costs. It is plain text to those who put the loopholes, like specially crafted constants in the algorithm.

Signal runs a service. Even if its source code is open source there’s no guarantee that that’s the code running on the server.

I don’t know the protocol, but I am concerned of man in the middle and how safe it is from man in the middle. In this case signal servers must be considered to be man in the middle.

The only system to trust is peer to peer with proven track record of sending encrypted data over public channels.

That’s PGP and Delta Chat utilizing PGP.