I’m planning the same.
I’m planning the same.
Let’s not defederate from every corporate player. Some of them can probably respect reasonable rules of civility.
But fuck Meta. We already know how this plays out.
We know there’s a huge wave of hatred and misinformation incoming. We’ve seen it on their other platforms.
Yeah. I’ll switch to an instance that is defederated from Threads, if mine doesn’t.
I left Meta’s other properties to avoid state sponsored hate speech. I won’t use a platform that gives hate speech a platform.
I don’t need to wait to know if Meta will do that. I already know.
I feel seen.
Your mother really can open and print a Markdown file now. It has come that far.
But I totally agree with your core point. The gulf between “most environments” and “everywhere” is still a big deal.
That said, for those who hate creating PDF files, I know of a great pure text format that converts very nicely to PDF.
Great points.
I generate my resume from Markdown, but I use a special CSS file I created so that the final PDF has the layout I want. Which is not a trick must Markdown editors can do yet.
Most environments will correctly format a Markdown document without any trouble now if sending it to a co-editor.
If it needs to be tamper resistant, it’s easily converted to PDF.
What’s not especially easy, today, is adding advanced styling (like a watermark) to Markdown, since Markdown itself has no provision for it. I accomplish that through a connected CSS file, but that’s a bit of an advanced move.
Good point. Markdown is easily turned into PDF for that use case.
Markdown is gaining traction. There’s lots of tools that will edit and display Markdown consistently, and without a dedicated tool, it’s just a very readable text file.
And, most importantly for today, it’s easy to generate a PDF file from, haha.
I feel like that violin is probably written in C. Or maybe Go. Has anyone made this yet? I might have my next weekend project
The compromise I’ve landed on is that I host my own DNS mx records, and point them to a paid enterprise mail provider.
This gets me the advantages of a paid provider while keeping my actual email address fully mine, to take wherever I want.
I did still have to learn a bunch of DNS rules in order to send all the correct “I’m not an evil spammer” headers and DNS records. But following a one page tutorial worked for me.
Edit: A disadvantage of my approach is that I’m still at the mercy of my email provider if I want to export my message history, and for the privacy of my message history.
I have had some pretty obnoxious recurring reboots on my Pi4 when I don’t add a heat sink and fan.
Sometimes the obvious solution is the way to go.
Your idea sounds good to go ahead and publish your pubkey(s) to fully public URL you control and can memorize.
Then you can stash or memorize the curl command needed to grab it (them) and authorize something to it (them).
A lot of more complicated solutions are just fancy ways to safely move private keys around.
For my private keys, I prefer to generate a new one for each use case, and throw them out when I’m done with them. That way I don’t need a solution to move, share or store them.
Edit: Full disclosure - I do also use Ansible to deploy my public keys.
I was probably running some weird little Python web CGI dice roller or some such. I spent a lot of time teaching myself the HTTP stack the unnecessarily hard way, lol.
Yeah. Probably Apache. Can’t remember what that I was doing, but it almost certainly ran on Apache, and I almost certainly spent 90% of my energy configuring Apache.
They bean that the beans weren’t serious discussion…beans.
Nice.
I’ve had acceptable outcomes on LibreComputer boxes running Armbian. I’ve had terrible luck with anything except the core Armbian image, but for a lot of stuff, Armbian on Libre gets the job done during the chip shortage.
This is terrific. Thank you for starting this discussion.
I don’t think we can or should wait for individual users to make these decisions. Server admins are the ones who understand the risks and so should make this call. Guidance for server admins based on past experience (cough XMPP!) should be quite welcome.
I might refine the bit about altered API versions to really focus on the real problem: proprietary extensions. We probably want to leave the door open to try out additions to the spec that come with detailed RFCs.
But we know from XMPP that proprietary extensions are a huge problem.