I actually wound up geoblocking the UK based on Ofcom's February 2025 presentation for small services providers--they said that they intended to target "one-man bands" who (e.g.) failed to perform a child risk assessment or age verification, but that a geoblock would be considered compliant. I don't like doing this, but as someone who visits the UK regularly (and has been regularly pushing Ofcom on this matter) I figure better safe than sorry.
I'm glad you have done this and I wish more would follow the same course. The more content that becomes unavailable in the UK, the more people might start to pay attention to the stupidity of the law.
I doubt it, but even from an irrational anger perspective, I hate that these idiots can do idiotic (and worse, counter productive) stuff, and get no comeback on themselves.
>I'm glad you have done this and I wish more would follow the same course. The more content that becomes unavailable in the UK, the more people might start to pay attention to the stupidity of the law.
The law isn't going to be repealed because a bunch of nerds geoblocked their personal blog.
I read that line and thought "so, the solution is code review?". What has to happen to your processes that code review is not only missing, but unironically claimed to be the solution?
I know there are some companies that never did code review, but this is Amazon. They should know better.
Assuming I've found the right process-compose [1], it struck me as having much overlap with the features of systemd. Or at least, I would tend to reach for systemd if I wanted something to run arbitrary processes. Is there something additional/better that process-compose does for you?
What process-compose gives me is a single parent with all of that project's processes as children, and a nice TUI/CLI for scrolling through them to see who is happy/unhappy and interrogating their logs, and when I shut it down all of that project's dependencies shut down. Pretty much the same flow as docker-compose.
It's all self-contained so I can run it on MacOS and it'll behave just the same as on Linux (I don't think systemd does this, could be wrong), and without requiring me to solve the docker/podman/rancher/orbstack problem (these are dependencies that are hard to bundle in nix, so while everything else comes for free, they come at the cost of complicating my readme with a bunch of requests that the user set things up beforehand).
As a bonus, since it's a single parent process, if I decide to invoke it through libfaketime, the time inherited by subprocess so it's consistently faked in the database and the services and in observability tools...
My feeling for systemd is that it's more for system-level stuff and less for project-level dependencies. Like, if I have separate projects which need different versions of postgres, systemd commands aren't going to give me a natural way to keep track of which project's postgres I'm talking about. process-compose, however, will show me logs for the correct postgres (or whatever service) in these cases:
~/src/projA$ process-compose process logs postgres
~/src/projB$ process-compose process logs postgres
This is especially helpful because AI agents tend to be scoped to working directory. So if I have one instance of claude code on each monitor and in each directory, which ever one tries to look at postgres logs will end up looking at the correct postgres's logs without having to even know that there are separate ones running.
Basically, I'm alergic to configuring my system at all. All dependencies besides nix, my text editor, and my shell are project level dependencies. This makes it easy to hop between machines and not really care about how they're set up. Even on production systems, I'd rather just clone the repo `nix run` in that dir (it then launches process compose which makes everything just like it was in my dev environment). I am however not in charge of any production systems, so perhaps I'm a bit out of touch there.
If you want emails from some random internal machine, you can use one of the HPE SMTP servers. There was one for internal email, another for external iirc although I'm not sure there was a difference in practice. Those SMTP servers would do a DNS lookup before accepting the email.
When I set this sort of thing up, I'd get myself a hostname on an internal subdomain. But that was a truly miserable experience. It was a multi-stage form submission on a server I imagine to be the closest possible relation to an actual potato. It was soul-destroyingly slow. Alternatively, you could just pretend your machine was hpe.com - the hostname was valid, even if the IP was totally wrong, and the SMTP server would accept it.
My guess is that there was a bunch of stuff that pre-dated the HP/HPE split and they took the quick and dirty option whenever the old internal domain name got yanked during the changeover. And if your process runs as root, you get root@hpe.com and hope there's something in the subject/body to identify the specific machine.
I can't speak to the Airs, but I went from an Intel Pro to a M3 Pro in a previous job and the battery life improved massively. I used to be able to heat my study by running a linter, but after the switch I remained chilly. I'm now on a M2 and have broadly observed the same.
I'm not sure if you've misunderstood, so apologies if this is old news. US companies may have teams of engineers in various other countries. But they almost always pay local market rate. In much the same way US companies will pay teams in India their local market rate (which is less again).
My last company paid 2-2.5x a UK salary for a US engineer. Perhaps the ratio for a company like Meta is closer, but I doubt it's equal. For startups you may find random roles that have equal pay globally, but they're relatively uncommon.
reply