A tiny mouse, a hacker.

  • 0 Posts
  • 9 Comments
Joined 9 months ago
cake
Cake day: December 24th, 2023

help-circle



  • I was in similar shoes (my server is running Debian, as it has been for the past two decades), and am going to rebuild it on something else. I chose NixOS, which I recently switched to on my desktop, because it lets me configure the entire system declaratively, even the containers. The major advantage of a declarative configuration is that it will never be out of date.

    My main reason for switching is that I’ve been running the server for a good few years, initially maintained via ansible, but that quickly turned into a hellish bash-in-yaml soup that never quite worked right. So I just made changes directly. And then I forgot why I made a change, or had the same thing copy & pasted all over the place. Today, it’s a colossal mess. With NixOS, I can’t make such a mess, because the entire system is declared in one single place, my configuration.

    Like you, I also planned to use containers for most everything, but… I eventually decided not to. There’s basically two things that I will run in a container: Wallabag (because it’s not so well integrated into NixOS at the moment), and my Mastodon instance (which runs glitch-soc, which is considerably easier to deploy via the official containers). The rest will run natively. I’ll be hardening them via systemd’s built-in stuff, which will give me comparable isolation without the overhead of containers. Running things natively helps a lot with declarative configuration too, a nice bonus.

    For reference, you can find my (work in progress) server configuration here. It might feel a bit overwhelming at first, because it’s written in a literate programming style using org mode & org roam. I found this structure to work great for me, because my configuration is thoroughly documented, both the whys and hows and whats.


  • There’s a very easy solution that lets you rest easy that your instance is how you want it to be: don’t do open registration. Vet the people you invite, and job done. If you want to be even safer, don’t post publicly - followers only. If you require follower approval, you can do some basic checks to see that whoever sends a follow request is someone you’re okay interacting with. This works on the microblogging side of the Fediverse quite well, today.

    What I’m trying to say is that with registrations requiring admin approval gets you 99% of the way there, without needing anything more complex than that.



  • The single best thing I like about Zed is how they unironically put up a video on their homepage where they take a perfectly fine function, and butcher it with irrelevant features using CoPilot, and in the process:

    • Make the function’s name not match what it is actually doing.
    • Hardcode three special cases for no good reason.
    • Write no tests at all.
    • Update the documentation, but make the short version of it misleading, suggesting it accepts all named colors, rather than just three. (The long description clarifies that, so it’s not completely bad.)
    • Show how engineering the prompt to do what they want takes more time than just writing the code in the first place.

    And that’s supposed to be a feature. I wonder how they’d feel if someone sent them a pull request done in a similar manner, resulting in similarly bad code.

    I think I’ll remain firmly in the “if FPS is an important metric in your editor, you’re doing something wrong” camp, and will also steer clear of anything that hypes up the plagiarism parrots as something that’d be a net win.