jsmeaton

Stackoverflow started failing when Jeff left. While he had a big hand in the whole mantra of being more of a Wiki than just Q&A, I feel his sense of community wouldn’t have let it get so bad.

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.

Is there a way to determine if a particular connection is falling back to DERP today?

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.

Guess where we host nexus..

https://github.com/lra/mackup?tab=readme-ov-file#warning

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.

Astral folks that are around - there seems to be a bit of confusion in the product page that the blog post makes a little more clear.

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!

I've been wondering where the commercial service would come in and this sounds like just the right product that aligns with what you're already doing and serves a real need. Setting up scalable private registries for python is awful.

Do you have an example of this?

What issues are you having with uvx? It replaces tools like pipx that set up implicit venvs to run specific tools. Works great for me.

Perceived only at this stage, though the kind of volume we’re looking at is 10s to 100s of millions of jobs per day. https://github.com/riverqueue/river/issues/746 talks about some of the same things you mention.

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.

Cloudtasks are excellent and I’ve been wanting something similar for years.

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.

The “hello Bluey” at the end gets me every time.

I used to have the same setup - a global tools venv with some useful dependencies.

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...

Agree. Rounding most of the advice to providing an executive summary is about right.

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.

I often give similar advice to colleagues that ask me for pointers on getting their recommendations approved.

"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.

They’re being attacked both for refusing to work with gangs or for working with a rival gang.

What I was hoping to be able to do was run our existing cpython project on graal to try and benefit from whatever speedups the jvm (or, if possible, compiling to a native module) would provide, rather than build with the jvm specifically in mind from the get go.

Appreciate the further details, thanks! This is a huge undertaking, good luck, and I'll be checking back in here and there.

Tried to use graalvm (interpreter) to run a fairly large project at my $dayjob$ and ran into a few issues right away.

  - 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.

Rye was started by Armin as a collection of existing tools (mostly) with a frontend similar to cargo.

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).

This is what jumped out to me reading this article too - unashamedly admitting to having gaps in knowledge that some others might take for granted.

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.

You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.

Once. Never again.

It doesn’t work with psycopg or many other libraries that use c extensions. That’s the main reason.

Even better, if your testing framework supports it, mark the test as expecting failure in your regression commit, then remove the xfail in the commit that fixes the bug.

No, which is why I think there has been less support for the (previous) OSS company than some other projects.

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.

In this case that’s true and why I said I don’t think it applies here. Typically it does though.

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.

I’m usually pretty ambivalent when a company decides to move to a license like BUSL. Sure it’s not “free” - but practically it only affects the likes of AWS from freeloading while making extraordinary profits. Especially true when a given company started the project. I understand why some hold strong feelings on the principles of OSS. My perspective is we’ll have fewer nice things if we allow the likes of AWS to cannibalise successful services.

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.

Ahh - side deal licensing.

“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?

Fully on board, but no mention if they’ll be releasing the source used to run Redis on Azure. Do they have an exemption? A separate license?

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?

feels like busy work just so management can “see” progress

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.