jsmeaton

Then all of the OG engineers left (I hope Nick Craver is doing well, his blog posts were incredible), an investment company took over, and whatever good will and vibe that was left melted away.

I’ll still occasionally find a good answer there. But it has zero future of making answers available for future good questions.

They took the fun away.

I have a pretty basic setup with tailscale setup on an Apple TV behind a bunch of UniFi devices and occasionally tunnelled traffic is incredibly slow.

Wondering if it’s worth setting this up on my Plex server which is behind fewer devices and has a lot of unused network and cpu.

Perhaps referencing this behaviour where preference files can no longer be symlinks?

> Mackup does not work correctly in macOS Sonoma and all later versions, since it does not support symlinked files for preferences.

> The next step in Python packaging

The headline is the confusing bit I think - "oh no, another tool already?"

IMO you should lean into stating this is going to be a paid product (answering how you plan to make money and become sustainable), and highlight that this will help solve private packaging problems.

I'm excited by this announcement by the way. Setting up scalable private python registries is a huge pain. Looking forward to it!

To be clear, I really like the model of riverqueue and will keep going at a leisurely pace since this is a personal time interest at the moment. I’m sick of celery and believe a service is a better model for background tasks than a language-specific tool.

If you guys were to build http ingestion and http targets I’d try and deploy it right away.

I’ve been occasionally hacking away at a proof of concept built on riverqueue but have eased off for a while due to performance issues obvious with non-partitioned tables and just general laziness.

https://github.com/jarshwah/dispatchr if curious but it doesn’t actually work yet.

Uv takes the position that since it’s so fast to install dependencies and create environments, you don’t maintain a global venv.

  uvx ruff file.py

Otherwise you can:

  uv run —-with package file.py

https://docs.astral.sh/uv/guides/scripts/#running-a-script-w...

If you’re not fully confident and think an experiment is worth while, lead with that, and provide assurances there are mitigations in place or a decision is easy to back out of. That’s still doing the work.

If you want an easy decision, you need to do the work. Not expect others to get into all the detail you did. There’s still room for those decisions - they’re just not as quick/easy.

"Make it as easy as possible for them to say yes"

Don't dump 14 paragraphs in front of someone expecting them to get onto the same level that you've been after many hours of studying a problem. If you're confident in your approach (and you should be, if you want an easy yes!), then be succinct, briefly describe the problem and why your solution is correct. Optionally link to a document that has more information if a reader wants to go deeper. Make sure you've already gained "approval" from your other team mates or product owners.

"We're going to solve X by doing Y. Team are all onboard. Proposal document is at [link] if you want the detail. Going to begin on Tuesday unless there's any more feedback we need to address."

Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.

  - Maturin doesn't support the graal interpreter, so no Py03 packages
  - uv doesn't seem to run, as `fork` and `execve` are missing from the os package?
  - Graal seems to have a huge number of patches to popular libraries so that they'll run, most seem to be of the form that patch c files to add additional IFDEFs

It's impressive what it does seem to support though, and probably worth looking at if you have a smaller scale project.

Then Astral came out with uv which aims to be a frontend into a collection of their own tools similar to cargo.

Armin and Astral agreed for Astral to take over Rye some time during uv development with (I assume) the goal for uv to fully replace Rye.

Use uv. As of 0.3.0 it covers most of rye now anyway. Especially if you’re writing projects and not consumable libs/apps (I haven’t used uv for anything other than package management so far).

Bucketing some of those gaps as “probably useful but not to me right now” is also great. It shows a purpose to focus on what matters right now, with a hint to return to when it does pop up again later.

Lots of folks I work with and respect sometimes get trapped in the weeds having to understand every little thing. It’s good to be curious, but sometimes filing it away for later and shipping is more important now.

Redis labs effectively became the defacto owner of the project later down the line when Antirez joined them. They inherited the project then tried to capture all of the value.

This isn’t a case of the original maintainers trying to sustain the project. It’s a hostile takeover that’s backfiring significantly. They brought Microsoft onboard as a partner hoping that would get them through the mess. Turns out that wasn’t enough.

Open source services are in a weird spot. They spend tonnes of money developing it and big providers are able to cannibalise as soon as something becomes popular at very little cost to themselves.

I think we do need something between fully free and fully closed where cloud providers pay some kind of licensing. It’s a problem worth solving.

But I feel no such sympathy for Redis nee Labs. It was never their project. They took over stewardship and then effectively stole the project for themselves. They’re not even the dominant contributor to the core product.

“Redis will continue to support its vast partner ecosystem – including managed service providers and system integrators – with exclusive access to all future releases, updates, and features developed and delivered by Redis through its Partner Program. There is no change for existing Redis Enterprise customers.”

I wonder how exclusive this actually is. Did Microsoft pay a boat load of money to freeze out Amazon?

On one hand I could see why Microsoft would back the original project, since they likely don’t want Amazon owning a replacement (elasticsearch). But I’m not sure how they plan to honour the new licensing?

Lot's of people feel like this. I usually come at it a different way - we're trying to estimate effort to see if we want to attempt building it in the first place. Assisting with the cost-benefit question if you will. That's the first reason.

It can also be extremely beneficial to the team, particularly when working with less experienced folks. You can farm out a lot of the work and parallelise the task.

I suspect Jacob didn't do much of this breakdown when implementing his streak app, which is why he recurses in an illustrative way.