Last time I checked, Posthog self hosted was basically unusable. They have a hobby deployment script which just pulls the latest build from master which varies from “somewhat works” to “completely broken”
Agreed, I tried self-hosting it a couple of month ago and it was impossible. I spent the day on it but the setup process was broken because of a recent change which was made for their cloud offering. Managing both a codebase both adapted to a cloud deployment with a huge amount of users and to a self-hosted way small deployment is very hard and requires a lot of resources. It's hard to justify investing this much time and money in making it work well for a self-hosted setup, and it seems like they stopped doing so.
It's still great to make the code open, but it's not usable anymore for a self-hosted setup.
> We also learned that the tools to do that automation just don't exist. We kept finding new failure modes. When onboarding a new customer we would have to vet their engineering team for Kubernetes experience so that we'd be confident they could help us debug issues in their PostHog deploy. Folks that didn't have infra experience would often be able to get something set up, only to get stuck when something went wrong.
I empathize that this is a sane choice for PostHog to make as a business. But - if you can't deploy and dogfood your changes, are you truly able to maintain a fork with customizations? And if you can't use your own changes, is the software open-source, or source-available?
Perhaps the punchline is that any scalable & performant web analytics platform must necessarily be a distributed system of ingestion and storage services, and that complexity is like oil and water with the classic "you should be able to swap out the dependencies on your systems with ones you fork" open-source ethos.
PostHog had an opportunity to break this trend, to innovate and invest in those automations they correctly said didn't exist - and I was cheering them on. I've been saddened to see them move in the opposite direction.
I think posthog is one of these businesses where the COSS model does not work well.
COSS works well when there is a large distribution advantage of being OSS. This could be bacuse a large portion of users (need to) self-host the solution. This is true for databases, people will always need to self-host dbs (e.g. as part of their docker compose in dev, etc...). These people are also hard core engineers that will 1) talk about the db and 2) contribute to the project. So an OSS db have a large network effects and distribution advantage.
Posthog had a distribution advantage from OSS in their beginnings -- their beachhead was the self-hosting oss community. Now, it does not add much value -- It's unlikely Github adds much for their distribution. So, it does not make sense for them to do much more than just maintain it lightly. In fact, they try to push you from self-hosting by having great free tiers and startup programs.
They want you to buy their hosted service, that's where the convenience is sold. If they give you a one liner script you can paste in or a docker compose that does everything from scratch they cannot sell their hosted services.
So the solution to ”this open source project is really bad at self-hosting” is ”let’s use a 100% proprietary system that does not allow any self-hosting at all”?
Does anyone know of any good firewalls for macOS? The built in firewall is practically unusable, and if client isolation can be bypassed, the local firewall is more important than ever.
I often have a dev server running bound to 0.0.0.0 as it makes debugging easy at home on the LAN, but then if I connect to a public WiFi I want to know that I am secure and the ports are closed. "Block all incoming connections" on macOS has failed me before when I've tested it.
Little Snitch is a user-friendly, software-level blocker, only – use with caution.
Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
I liken the comparison to disk RAIDs: a RAID is not a true backup; LittleSnitch is not a true firewall.
You need isolated hardware for true inbound/outbound protection.
>Just FYI: LittleSnitch pre-resolves DNS entries BEFORE you click `Accept/Deny`, if you care & understand this potential security issue. Your upstream provider still knows whether you denied a query. Easily verifiable with a PiHole (&c).
This also feels like an exfil route? Are DNS queries (no tcp connect) logged/blocked?
When you see the LittleSnitch dialogue (asking to `Accept/Deny`), whatever hostname is there has already been pre-resolved by upstream DNS provider (does not matter which option you select). This software pares well with a PiHole (for easy layperson installs), but even then is insufficient for OP's attack.
I have just today discovered zmx [1] which is like tmux but I always hated the tmux terminal emulation and how it hijacks scrolling, especially on Termius on my phone. It does session persistence but I think without the terminal emulator side of things, so scrolling works normally.
Been testing it today with Claude Code and it seems to work quite well switching between my laptop and phone.
I also hate how tmux uses alt mode and can never remember all the shortcuts, copy paste is a PITA and just today I had to look up how to dump the scrollback buffer to a file. Named sessions without window management makes a lot more sense these days. Similarly, I'm not a fan of all the ANSI escape codes that CC uses to jump the cursor around and rewrite the display to look like a GUI. I prefer a TUI that doesn't mutate rows after writing them, that's what alt mode is for. CC often clears whatever was in the scrollback buffer before you opened it, it hides bracketed paste, and goes crazy sometimes when content overflows the window and I have to resize the terminal or get blasted with a wall of glitching characters--extra annoying if I'm working from a low bandwidth link. I develop my own agent framework and code agent, and while some features aren't as polished as CC, one of my explicit goals is to preserve the traditional CLI feel, like the python REPL (that's what it's based around). I'll give zmx a try tonight :)
I was travelling a lot a couple of days ago across the countryside just outside of Krakow, and people are definitely burning plastics and trash, you can smell it even inside your car in the early hours of the morning.
It's coming from the surrounding areas, not the city itself.
Also one thing to note is that if pollution is bad in general then nearby fires and local sources of pollution will be much more noticeable. At least in my experience it seems to keep the pollution closer to the ground. Like if you are walking around a city with a lot of traffic on a day with bad pollution you will basically smell car exhaust all day whereas on days with low pollution even with the exact same amount of cars it will be much less noticeable.
Suburbs may be fine, but beyond them there's a ring of small towns and villages, and I bet most of the pollution is flowing from them down into the city.
"A high-latency architect who spends his days documenting every time a CDN sneezes while dreaming of a mountain drive through the Balkans with a fresh burek in hand."
Definitely don't recommend going down this path if you're not already familiar with Nix, but if you are, a strategy that I find works really well is to package your software with Nix, then you can run it easily via systemd but also create super lightweight containers using nix-snapshotter[0] so you don't have to "build" container images if you still want the flexibility of containers. You can then run the containers on Docker or Kubernetes without having to build heavy images.
