Skip Navigation

Posts
1
Comments
435
Joined
3 yr. ago

  • I think ActivityPub is closer to the right answer than ATProto, and ActivityPub's issues (though many, as the author notes) are more manageable in the long run. I think the article makes a good analysis of the fundamental differences, but is a bit glib in referring to Piefed's topics and discussion merging as a "joyful mess". It's not a mess at all. It's making order out of the chaos, and it's the right way to build on top of ActivityPub into something that is actually fluid enough for users to actually use.

    Mailing lists were built on top of federated email in much the same way, and they formed enduring, resilient, well-structured communities, some that continue to this day (the LKML being perhaps the most notorious)

    I think ATProto makes creating enduring communities too difficult, and BlackSky illustrates that perfectly. The author's criticism of ActivityPub, on the other hand, seems to be that it makes creating communities too easy, and this results in a "mess". I disagree, I think the mess is a necessary and inevitable part of having community. Communities are messy. They fracture and schism, they rejoin and reshape themselves. That's normal. It is the responsibility of the software to make sense of the mess and make it presentable, and with ActivityPub, that is not only possible, it is happening. Piefed is the present example. I expect there will be more examples, and a wider variety of them, as the ecosystem continues to develop.

    I think the biggest thing that ActivityPub still needs is better portability, for both users and communities, to allow moving servers more seamlessly. The "Personal Data Server" of Bluesky is not a bad concept, although I don't love their implementation. I think ActivityPub can find a way to handle portability even better, but it doesn't seem like it's been a priority, and that's fine. But it will need to happen eventually.

  • Split DNS typically refers to splitting the DNS results of a single, existing DNS server depending on who asks it, which is not what you want here, because that same server would be serving both external clients and internal ones and would need to differentiate between them.

    You want an internal DNS server JUST for your own LAN, and its full-time job is very simple: to have all your local machines pointed at it for DNS, then it will either pretend it's authoritative and return the proper local IPs for whatever name you ask it for that's supposed to be on the local network, OR it forwards any other requests it doesn't consider itself "authoritative" for onwards to your Adguard or other DNS provider to get a real authoritative external IP in response.

    The very simplest option for a bare-bones, basic DNS server that will do what you need is dnsmasq. Here is the default sample config for reference. Simply leave all "dhcp" related settings in the config commented out and you'll probably also want to set:

    • no-hosts (won't use the /etc/hosts file)
    • resolv-file (an /etc/resolv.conf style file that tells it what actual nameservers to use for all other queries)
    • and either address=/sub.domain.tld/192.168.1.1 (for the subdomain and everything under it)
    • or host-record=sub.domain.tld,192.168.1.1 for only that specific subdomain exactly

    Then change all your local DNS servers to point at dnsmasq's IP address (you typically would do this at whatever device is handing out IPs on your network with DHCP, for example the router)

    I think that's pretty much it.

  • To me, it makes sense for things that are simple to review, have clear, binary acceptance criteria, and little to no meaningful attack surface or dangerous failure modes. If you are trying to make an AI develop a bulletproof filesystem device driver or network stack you're a fucking maniac and should be pilloried in the town square. If you want to throw an AI-generated github actions build script at me that's perfectly fine and once I've reviewed it thoroughly it doesn't bother me one bit if it's AI-generated.

  • well obviously, all this proves is that copper wires are just as bad as wet mud. Every audiophile knows you need gold oxygen nitrogen purified wires blessed by a voodoo witch doctor.

  • The purpose of the health check is to allow docker itself to talk to whatever service is running on the container to make sure it's always responding happily, connected to everything it needs to be connected to for proper operation, and is not overloaded or stuck somehow.

    Docker does this by pretending to be a web browser, and going to the specified "health check URL". The key thing I think you're missing here is that the health check URL is supposed to be a URL that, ideally, runs on your container and does some meaningful checks on the health of your service, or at the very least, proves that when you connect to it, it is able to serve up a working static page or login page or something (which doesn't actually prove it's working completely, but is often good enough)

    Now, you're probably wondering why this isn't automatic, and the answer is because there's no standard "health check URL" that fits all services. Not all services even respond to URLs at all, and the ones that do may have different URLs for their health checks, they may need different hostnames to be used, etc.

    By setting health check URL to example.com, basically what you're doing is constantly testing whether the real-world website https://example.com/ way over there somewhere is working, and as long as it is, docker assumes your container is fine. Which it might be, or it might not be, it has no idea and you have no idea, because it's not even attempting to connect to the container at all, it's going to the URL you specified, which is way out there on the internet somewhere, and this effectively does nothing useful for you.

    It's understandable why you probably thought this made sense, that it was testing network connectivity or something, but that is not the purpose of the health check URL, and if you don't have a meaningful URL to check, you can probably just omit or disable the healthcheck in this case. Docker only uses it to decide if it needs to restart the container or alert you of the failure.

  • I'm glad Linux is not limited by issues like this. Because when it is, you can just change the window manager, or the desktop environment, or the whole damn X server if you want. Freedom of choice is wild like that. I'm done with proprietary OS. RIP.

  • Seems pretty good, using the latest version of ollama (downloaded the default Q4 from ollama) and then popped it into Codex with this config.toml:

     
        
    model = "qwen3-coder-next:Q4_K_M"
    model_provider = "ollama"
    model_reasoning_effort = "medium"
    
    [model_providers.ollama]
    name = "Ollama"
    base_url = "http://localhost:11434/v1"
    
    [analytics]
    enabled = false
    
      

    Works well in Codex CLI and VScode Codex IDE plugin. Did not work well with Kilo Code or Roo plugins unfortunately (but I have yet to find much that does).

    I am not an expert, this may not be the best way, I don't know... just sharing my experience for the other non-experts out there.

  • I deal with kubernetes daily for my job and it manages to melt my brain at least a few times a week. It's not bad... it's actually great... it's just... a lot. Like, a lot a lot.

    For what it's worth, I do not use it at home, because I prefer to be getting paid when my brain is melting.

  • He's still alive right now, it can't take that long to build a guillotine, what exactly are we we waiting for?

  • Before you even start, consider adopting an 'infrastructure as code' approach. It will make your life a lot easier in the future.

    Start with any actual code: If you have any existing source code, get it under git version control immediately, then prioritize getting it into a git hub like forgejo to make your life easier in the future. Make a git repository for your infrastructure documentation, and record (and comment/document too if you're feeling ambitious) every command you run in a txt file or an md file or a script, and do that as religiously as you can while you're setting up all this self-hosted stuff. You may want to dig it up later to try and remember exactly what you did or in case stuff goes wrong and you need to back off and try again. It might seem pointless now, but a year from now, you'll thank me.

    Especially prioritize getting your git stuff moved into a self-hosted forgejo if any of your stuff is hosted on the microsoft technoplague called github.

  • I ran Matrix for like a year, and pretty much hated every minute. It was fragile, complicated, and incredibly, bafflingly resource intensive. Matrix is an overengineered nightmare in my opinion, and it seems to be quickly distancing itself from self-hosters while pursuing enterprise usage. Neat technology, horrible implementation, misguided company.

    XMPP is a breath of fresh air in comparison. Just like we still use email everywhere (even for authentication nowadays, fun!), XMPP is not obsolete simply because it's older. It's a solid foundation, plenty extensible, and does almost everything I can imagine needing to do without unnecessary complexity.

    Matrix's bridges are its killer feature, and it's nice... when it works. But it's simply not worth the headache of dealing with Matrix, in my opinion.

  • If the polls are rigged, does that imply that most Israelis don't support the genocide? So ... you think you've got a majority of people who don't support the genocide and with that majority you plan to do ... nothing? Just gonna ... let the minority do what they want?

    There's a word for that, the word is "support". You might not think you're supporting it, but if you're not doing something to fight it, then yes, you are supporting it. Get to work. Nobody ever promised that doing the right thing has to be easy.

  • We are so, so, so thoroughly cooked. I can't even.

  • Lots of enabling in your comment.

    People like you, with no control over the big decisions. Just like Palestinians can’t control Hamas, Russians can’t control Putin, US citizens can’t control Trump, and so on.

    If people can't control their own governments, who can? Who should? Other people's governments? Is that how you think it's supposed to work? That's why Israel is obliterating Gaza? Because Gaza can't get rid of Hamas themselves so Israel is going to do it for them? Do you think that is justified and the right way to do things? Is it Canada's job to rescue the US? Is it Europe's responsibility to stop Russia?

    Are Iranians responsible for the Iranian regime? Yes, they are, that's why they're fucking protesting and dying in the streets right now. Resist, fight back, don't comply, undermine your illegitimate government until they can be toppled.

    Take responsibility. I am responsible for the actions of my government and my country. And so are you. You will be held responsible. And you should be. Other countries are not responsible for fixing your shit. You are. Fix it. Figure out how. Stop acting like it's somebody else's problem and you are just a humble peasant. Humble peasants can start revolutions. Lazy citizens who are happy with the status quo while pretending they don't agree with it do not start revolutions. Which one are you?

  • I don’t want the free petition websites online getting my personal network’s info and sharing or selling it, hence the interest in self hosting.

    So either you're creating a petition with a size of exactly "1" or you're asking other people to trust YOU with their personal info instead, or you're asking for a federated solution (extremely difficult to establish a verifiable web of trust framework, and STILL shares your "personal network's info" whenever it federates or validates its data to dozens of other servers).

    None of these scenarios are viable for creating a petition that anyone is going to take seriously (to the extent that anyone takes petitions seriously at all)

  • fail2ban mainly, but also things like scaling login delays (some sort of option often built into the software you're running, but just as often not configured by default), or if you're feeling particularly paranoid account locking after too many failures, and in general just not using default, predictable, common usernames or weak passwords, and honestly it's even helped a bit by having slow hardware and throttled network bandwidth.

    The goal is to make it so that someone can't run a script that sends 100 million login attempts per second for common or stolen usernames and passwords and your server just helpfully tries them all and obediently tells them none of those worked... until one of them does.

    Not only does this encourage them to TRY sending 100 million login attempts per second because your server isn't refusing it, which is a huge waste of bandwidth and resources, it also makes it really likely that they're eventually going to guess one right.

  • That's the problem, When you're running too many services as it is, you will be staring at a terminal at home sooner or later. Maybe you've gotten lucky and haven't been ravaged by the cruel gods of fate yet, but it absolutely happens, and eventually it will happen to you. When you're relying on family notifications and disaster response, you don't get to choose when that happens, and sometimes you'll have to spend a LONG time staring at a terminal at home. And when it happens often enough, or badly enough, you end up not just staring at the terminal at home, but also thinking about the terminal at home, and losing sleep over it, and that's just not a great way to live your self-hosting life. I've been there.

    Making the investment in repeatable, reproducible, maintainable infrastructure now means you get to decide WHEN you're staring at a terminal, and for exactly how long. Even when you don't make it through as much progress as you wanted to, you can just close it down without any stress, get back to your life and continue from where you left off next time. You can't do that, at least not without some significant consequences when your server got hacked and is sending spam or your entire server is refusing to boot and you need the files on it.

    You may still have to hit the terminal sometimes when you don't choose to, but it's going to be less often, and less complex when you do. That's when the investment pays off, and your return on investment is the goal of having ultimately less time spent at the terminal at home, and that payoff is especially rewarding if you're good at prioritizing the time you do choose to spend on the terminal at home, to find low-value moments to effectively repurpose for this hobby, and save the actually valuable times of your life from ever having to be used for emergency maintenance.

  • Removed Deleted

    It's WTF o'clock

    Jump
  • "Please fill out and sign this credit card application form to prove that you are human."