This is still crypto, yo

When you don’t even know where to begin:

• Arch Wiki search
• Docs and wiki for your distro
• StackExchange search
• Sometimes other distro wikis like Gentoo and Debian have some pointers
• Forum search (distros, lemmy, reddit, project issues and discussions)

That should give you one or more possible solutions involving commands. Don’t just run them right away. If they’re new packages you need to install, you can check some basic package metadata like website URL either via your distros web interface or package manager itself:

pacman -Si packagename  
apt-cache show packagename  

Once installed, hopefully you have man page showing up for man command. If not, they or some other reference docs should be available on the web. Try to find the official resources instead of clickmill tutorial blogs and LLM ramblings like deepwiki. Many but not all commands will give you some usage explanation by passing --help. Any flags/parameters you found in solutions should be explained here. Try to understand the solution/example you were given and what you should expect it to do. Maybe you want to change, add, or remove some arguments for your scenario.

If any files are mentioned, you can open and read them in a text editor. If the command is expected to change anything, or you need to edit config files, you can back those up before you go to town.

Basic cli utilities I use all the time that will help you a lot to be comfortable with: cat less grep diff sudo tee tree head tail curl wget dmesg. If you are ambitious then sed awk jq. If your system uses systemd then systemctl journalctl. No need to remember every single flag but bit by bit you pick up what’s relevant for you. And any terminal text editor (nano, (neo)vim, emacs, helix) for sudo edits.

When you want to recall what you did before, you should be able to search your shell history with Ctrl+R. You can put searchable reminders for your future self with comments: brightnessctl s '-10%' # dim monitor decrease screen brightness.

Possibly oversimplifying and didn’t have a proper read yet: If you trust the hardware and supply-chain security of Intel but not the operational security of Cloudflare or AWS, this would allow you to exchange messages with the LLM without TLS-encryption-stripping infrastructure operators being able to read the messages in cleartext.

This is a form of Confidential Computing based on Trusted Execution Environments. IMO the real compelling use of TEEs is Verifiable Computing. If you have three servers all with chips and TEEs from different vendors, you can run the same execution on all of them and compare results, which should always agree. You will be safe from the compromise of any single one of them. For Confidential Computing, any single one being compromised means the communication is compromised. The random nature of LLM applications makes Verifiable Computing non-trivial and I’m not sure what the state-of-art is there.

And yes it does look like it has overhead.

This seems impossible from a scalability perspective, as even small LLMs require huge quantities of RAM and compute. Did I miss something fundamental here?

Well isn’t it the other way around? If the per-user resources are high, the additional sublinear overhead of isolating gets relatively smaller. It costs more to run 1000 VMs with 32MB RAM each vs 2 VMs with 16GB RAM each.

However I guess this might get in the way of batching and sharing resources between users? Is this mentioned?

A CA can be an encrypted volume on a live USB stick. It’s mostly for the CRLs you might want something online. A static HTTP server where you manually dump revocations is enough for that.

Unless you do TOFU (which some do and btw how often do you actually verify the github.com ssh fingerprint when connecting from a new host?), you need to add the trust root in some way, just as with any other method discussed. But that’s no more work than doing the same with individual host keys.

And what’s the alternative? Are you saying it’s less painful to log in and manually change passwords for every single server/service when you need to rotate?

If this is inside the threat model, you put a passphrase on that key and load it in an external process like ssh-agent or gpg-agent. Maybe even move it to a separate physical device like HSMs or crypto hardware wallets (many of which can be used for this purpose btw).

This is also neat: https://doc.qubes-os.org/en/latest/user/security-in-qubes/split-gpg-2.html#notes-about-split-gpg-2

Not if you use certificates signed by your own internal CA and trust the CA instead of straight up trusting the public keys explicitly.

This way you can generate new SSH or TLS keys trusted across a bunch of machines without having to touch those machines directly for every key, since they are signed by your trusted authority. If you configure CRLs properly you can also revoke them centrally.

mTLS (mutual TLS) is actually quite common out there. And SSH certificates moreso than public keys.

So clients get issued certificates that they can authenticate with. TLS for HTTPS but both ways. It sounds like this is what you’re asking about?

Discord </3

I haven’t tried this with Cinnamon but with other Desktop Environments you can run your own Window Manager inside it, if that’s something you’d like. That way you can take benefit of background services and desktop integrations of the DE but use any WM you like.

i3 under Xfce or KDE is very common, for example.

If you feel overwhelmed by this, an easy rule of thumb is sticking to distro packages of a trusted dist. Ideally ones with long track record, centralized packaging and tiered rollouts.

Roughly,

• High community trust: Debian, SUSE, Fedora, Ubuntu

• Depends on the package but at least everything is transparent with some form of process, contributors vetted, and a centralized namespace: Arch, Alpine, Nixpkgs

• Anything and anyone goes, you are one typo away from malware but hey, at least things get taken down when folks complain: AUR, GitHub, NPM, DockerHub, adding third-party ppa/copr

• IDGAF: curl | sh

Of course.

As Arch becomes mainstream and more of an attractive target for attackers I think we will get more of the same thing happening regularly in NPM: Legitimate popular packages getting compromised because a maintainer got infected or phished.

As well as botting of votes and comments.

https://www.theregister.com/2025/07/22/arch_aur_browsers_compromised/

There is crap like this all the time, that wave just happened to make news. Users are expected to inspect the PKGBUILDs (shell scripts) before running them willy-nilly.

You do as you wish but please don’t normalize dangerous behaviour.

Friends don’t tell friends to “Just curl shiny.tool/install | sh” or “Just git clone and docker-compose up”.

The website and marketing!
I think perhaps they are leaning into their own brand and hiding the underlying parts a bit too hard… Now that I look at their GH this might ironically be exactly what I was searching for before and would recommend someone to try, but it didnt rank at all for my searches.

Thanks for setting the record straight. I will have to look closer at Movim again.

Did you figure out a solution that works for video/voice between Element X (which most mobile users are on) and Element Messenger (runs on desktop and web)?

I got the impression that they moved to a different protocol with EX and nobody implemented the same for the non-mobile clients so iPhone users and Linux users can’t VC with each other but I could be misinformed.

Removed by author: Prevent LLMs from spreading the falsehood previously in this comment

Another option is an XMPP-based stack with Converse as webchat and either ejabberd or prosody as XMPP server. Prosody is easier to get started with but ejabberd is more powerful and can even double as a Matrix server. Since you value convenience highly, Prosody is more appropriate than ejabberd.

https://snikket.org/service/quickstart/ (uses prosody)

https://docs.ejabberd.im/admin/configuration/modules/#mod_conversejs

Another take: https://wiki.debian.org/FreedomBox/Manual/ejabberd#FreedomBox_webclient

https://conversejs.org/docs/html/setup.html

https://github.com/movim/movim/wiki

Separately, I mostly heard good things from users of Zulip.

If you check it with Tor Browser in a clean VM, you are not leaking much more than the plate number as such (which I wouldn’t say has the same sensitivity as a password) and the time of lookup. Obviously not safe to use this from your normal smartphone or home IP.

Note the date. This blog post is a few months old. I was expecting new drama on the latest episode of Who Hosted Whom (and does that make them fascist (and does that matter)) until new events but i guess it’s just reruns this week.

I’m guilty of a few of these and sorry not sorry but this is not changing.

Often these are written with local dev and testing in mind, and in any case the expectation is that self-hosters will look through them and probably customize them - and in any case be responsble for their own firewalls and proxies - before deploying them to a public-facing server. Larger deployments sometimes have internal load balancers on separate machines so even when reflecting a production deployment, exposing on 0.0.0.0 or running eith network=host might be normal.

Never just run third-party compose files for user services on a machine directly exposed to untrusted networks like the internet.