LibreOffice, because it is local. If I want to collaborate, I’ll share the file in whatever way is most convenient for the other parties. Since most people I collaborate prefer editing locally, this works out quite well.

If any repository that you use, or are interested in, is hosted on a commercial, for-profit service (even if it has a free tier), back it up. It will, eventually, disappear.

If any of those end up interacting with me, or I otherwise see them on my timeline, they’ll get treated appropriately: reported, blocked, or in extreme cases, served garbage interactions to. Serving garbage to 500+ bots is laughably easy. Every day I have over 5 million requests from various AI scrapers, from thousands of unique IP addresses, and I serve them garbage. It doesn’t make a blip on my tiny VPS: in just the past 24 hours, I served 5.2M requests from AI scrapers, from ~2100 unique IP addresses, using 60Mb memory and a mere 2.5 hours of CPU time. I can do that on a potato.

But first: they have to interact with me. As I am on a single-user instance, chances are, by the time any bot would get to try and spam me, a bigger server already had them reported and blocked (and I periodically review blocks from larger instances I trust, so there’s a good chance I’d block most bots before they have a chance of interacting with me).

This is not a fight bots can win.

Personally, I do not have any automatism to detect LLMs larping as people. But I do review accounts that follow or interact with mine, and if I find any that are bots, I’ll enact counter measures. That may involve reporting them to their server admin (most instances don’t take kindly to such bots), blocking their entire instance, or in extreme cases, start serving them garbage interactions.

None, because they typicially open up a larger attack surface than the system would have without them. It’s been like that for a while now. For references, I’d recommend this article from Ars Technica, who reference some very knowledgeable people (including Chrome’s Security Chief at the time).

There was a time when AV software was useful. We’re a decade past that, the world has changed, software has changed, defenses have changed, and AV software did not keep up.

Thank you. I told this to my entire family. If there was a way to convert laughter to energy, we could power a small city by now.

Considering the amount of CVEs the kernel puts out, I’d argue there’s plenty there that’s broken, and could be fixed by implementing them in a language less broken than C.

I am already doing my part, by serving AI agents an infinite maze of garbage wisdom.

The best part? It requires very little energy to do this. A potato can do it! Thus, AI will always have something to train on, long after we’re gone. Beautiful, isn’t it?

Most GenAI was trained on material they had no right to train on (including plenty of mine). So I’m doing my small part, and serving known AI agents an infinite maze of garbage. They can fuck right off.

Now, if we’re talking about real AI, that isn’t just a server park of disguised markov chains in a trenchcoat, neural networks that weren’t trained on stolen data, that’s a whole different story.

I used to use flake-parts, but I organize my flakes in a very different way (I generate a single, bigass flake.nix out of tiny org files), and found that frameworks like flake-parts and flakelight just get in the way. I suspect they’re useful if you’re working with Nix directly, but… I don’t like Nix (the language), so I do my organization outside of it.

Our twins jumping on my back. Unlike an alarm, I can’t turn them off and go back to sleep.

TLDR: Is it normal to distro hop after being using a distro perfectly for so long?

I have used the same distribution (Debian) for over 20 years when I decided to change distributions and switch to NixOS. Debian was - and still is - a very fine distribution. I just needed something radically different.

So, to answer your question: yes, it is perfectly normal. Two years isn’t even long.

If your goal is to get started with Emacs, and have a lot of things pre-configured, Doom will get you there much faster than starting from scratch. It is opinionated, yes, and configuring it is somewhat different than building from scratch, but I would never recommend starting Emacs from scratch for someone new to it, unless I happen to know they like to suffer.

Yes. It makes configuring Emacs a whole lot simpler than vanilla Emacs.

If you’re new(ish) to Emacs, I would strongly suggest using a kit like Doom Emacs. It sets up some modern defaults, and makes it far, far simpler to set up a good environment for whatever languages you want. And the wonderful thing is that you can keep using Doom!

If they have no desire to maintain/sysadmin their own linux systems, then the best distro to recommend is whatever you can help them with, and possibly even maintain for them.

Case in point, my Wife is a very happy NixOS user, despite knowing absolutely nothing about Linux. Yet, she’s on a distribution that’s as far from being newbie friendly as a distro can possibly be. She’s still happy with it, because I set it up for her, and I maintain it for her, she never has to install, upgrade or configure anything, ever.

NixOS?

algernon ducks and runs, fast

I’m not seeing anything wrong in the samples you provided. That’s pretty much how my own NixOS configuration looks (except mine’s a single monolithic flake.nix generated from Org Roam sources, but… the effect is the same anyway).

I’d say “under no circumstances”. When building for production, you want to build on a stable foundation. LFS isn’t that, it’s an educational tool. It does not result in a maintainable, robust system. It requires tremendous amounts of work to keep it secure and updated: there’s no package manager, no repository you can pull from, no nothing. You have to build an entire distribution on your own. Outside of educational purposes, I’m having trouble to imagine any situation where that might be a good idea.

No, not even embedded. There were always distros targetting embedded systems, LFS was never a good choice there either. It was much more straightforward to strip down - say - Debian for a limited device, than to build something from scratch for it. (I spent a few years building and operating embedded Linux systems at the early 2000s, we built it on a stripped down Debian.)

Invent a time machine. Go back in time. Study.

Failing that, learn from your mistakes, and next time… well… study.