[–] 1 point 1 month ago (1 child)

Unlike immutable distributions that lock you out of the native package manager

Direct pacman use is blocked. /usr/bin/pacman is a wrapper around pacman-real

Regardless, I do support attempts to make an immutable and declarative Arch distro. An an ostree implementation on Arch is an interesting experiment. You might want to check out Darch which boots from container images.

  • source
  • [–] 8 points 1 month ago* (last edited 1 month ago) (1 child)

    Look if you want to do the 1900s millionaire philantropic bullshit, you just make a nice ornate public space and put your name on it. You don't build a monolithic museum to "your legacy". That's the sort of thing a villain with a Walt Disney mustache would do. Even he would have some taste and not build an obilesk that looks like the missingno Pokémon.

  • source
  • [–] [S] 6 points 1 month ago

    Its a common courtesy that if you publish something on the AUR, then you actually think people would use it and you plan to maintain it. You don't bother pushing some half baked afterthought to the AUR. Leave it on github. Otherwise you're just squatting a perfectly good AUR package name.

  • source
  • parent
  • context
  • [–] [S] 10 points 1 month ago

    People are publishing their slop projects as if they intend on maintaining them, but they clearly aren’t capable or willing to actually maintain them.

    This is my #1 problem with it. Just put it on github and call it a day. Don't act like its production ready at all. The #2 issue is namespace pollution.

  • source
  • parent
  • context
  •  

    Just an example, one of many. Check the upstream. Four months old. Two contributors: some human and an orange asshole. Human has no other repositories, so I guess the asshole is the more trustworthy one.

    I'm assuming this is just some vibe coded bullshit where someone just said yes to everything Claude asked. I'd read the code to confirm it's not malicious but this person has already wasted enough of my time already.

    Anyway AUR is not going to survive the Eternal Sloptober.

     

    At the heart of the NetNut residential proxy service was the Popa botnet, an engineered stealth communications layer. By embedding deceptive software development kits into inexpensive, off-brand Android-based smart TVs, streaming media boxes and unofficial apps like the SmartTube client, NetNut hijacked ordinary home electronics.

    When consumers plugged in these devices, their home internet connections were quietly rented out as residential proxy exit nodes. This allowed malicious traffic to route through legitimate domestic IP addresses, effectively bypassing standard data center blocks and security filters.

    AFAIK the only thing illegal about this is they didn't bother with TOS agreements.

     

    The goal is to share an http service privately on my tailnet but with an HTTPs connection. It seems others have spent lots of time figuring out and never sharing their solutions. I just got a setup to work satisfactorily so I'll share it. Criticism is welcome. First a few notes:

    • I'm using headscale on a VPS behind Caddy.
    • Official tailscale allegedly can do this out of the box with tailscale serve or tailscale cert.
    • Headscale supports tailscale serve but not with https. Maybe if I removed caddy and let headscale to https directly it would. I haven't tested that yet.
    • Yes I know https over wireguard is redundant. This effort is not only to make Firefox shut up but to make some clients that demand https work.

    I also have deliberately avoided the "Private CA" because installing the cert of every client on my tailnet sounds like a nightmare. If someone can prove me wrong there, please share.

    The context

    1. I have a VPS and a public domain with DNS A and AAAA records that point all sub domains *.mydomain.net to that VPS.
    2. The VPS runs caddy and headscale and is on the tailnet itself.
    3. Caddy route the hs subdomain to headscale.
    4. I have numerous devices on my tailnet, many running different http services but only some of them I want public.
    5. I can publicly expose a service with https by simply adding an entry to caddy like so,
    publicservice.mydomain.net {
        reverse_proxy privatehost:8080
    }
    

    Restart caddy and that's it.

    The solution

    First, I used sub domains of the public domain instead of headscales base domain. eg Use *.ts.mydomain.net instead of ts.net. I made a *.ts.mydomain.net A record pointing to my servers public IP. Caddy will automatically fetch https certificates for any *.mydomain.net domains automatically. It cannot for a domain not routed to it. (DNS01 authentication might circumvent this but I haven't tested that yet).

    Second, I restrict caddy to only accept tailscale connections by using the bind directive. Otherwise it will accept and route public traffic. A caddy entry for a private service would look like this,

    privateservice.ts.mydomain.net {
        bind 100.64.0.1 [fd7a:115c:a1e0::1]
        reverse_proxy privatehost:8081
    }
    

    The IP addresses come from the output of tailscale ip on the caddy/headscale machine.

    Now privateservice.ts.mydomain.net routes to the caddy server with https but it gets a default blank 200 response from caddy because its coming from the machine's public IP instead of the tailnet.

    The last step is to configure headscale's DNS to route private services to the headscale server on its its tailscale IP instead of the public IP.

    # /etc/headscale/config.yaml
    # ...
    dns:
      magic_dns: true
      # base_domain is irrelevant
      nameservers:
        global: [ whatever ]
        split:
            # required to override the public dns records
            ts.mydomain.net: 100.100.100.100
      extra_records:
         - type: "A"
           name: "privateservice.mydomain.net"
           value: "100.64.0.1"
         - type: "AAAA"
           name: "privateservice.mydomain.net"
           value: "fd7a:115c:a1e0::1"
         # repeat for each service, always the same IPs
    

    You can have base_domain be whatever or make it ts.mydomain.net if you want to be consistent and aren't worried about collisions with your extra records.

    I tried using wildcard DNS records in headscale and it didn't work. It felt like it completely broke DNS without any clear warnings or errors. Idk if that's a bug or what. DNS just timed out internally

    Limitations

    All internal HTTPS traffic is routed through my VPS instead of directly peer to peer, which is a real bummer for internal latency. I think the only way around that is to give each internal host their own caddy server, have the DNS records point directly to them, but then use a private CA and all the hassle that's worth. Maybe DNS01 challenges will work...

    Also while I have no public records indicating what private subdomains I have beyond *.ts.mydomain.net for DNS, I do have them for my TLS certificates... somewhere. I'm not super concerned about that though. I think only a private CA will hide those.

    CPU barely detected (programming.dev)
     

    I recently swapped motherboards between two builds. One went well but the other is being very finicky with detecting the CPU. Right now its laying on its side like a beached whale with the left side panel open. The heatsink is simply sitting on the CPU, no mounts, no fans. Sometimes I can strap the heatsink down, stand up the box, and close the case, but never with the fans on. Its like that's too much weight and some connection is broken. Is anyone familiar with this problem?

    I had this issue previously with a different motherboard and fixed it by using a stock heatsink. But this is a fairly simple CoolerMaster 212. Its not massive. I feel like its a problem with the board or the socket.

    More details: when uninstalled the old motherboard in this build, it had the same CM212 heatsink in it. When I removed that heatsink the CPU (Ryzen 5700) came out with it to my horror. Neither that CPU or that motherboard are in this build though. But that CPU was supposed it be. It did have bent pins and I did try to install it before discovering the bent pins. After straightening them the CPU still didn't work so i switched to an old Ryzen 1600, which is currently being finicky. Maybe I damaged the motherboard socket?

    view more: next ›