ImJasonH (u/ImJasonH)

ImJasonH commented on Show HN: Anonymous Age Verification gist.github.com/JWally/bf... · Posted by u/jwally

jwally · a day ago

Fair enough.

Who is putting a lot of trust in the bank?

They're slimy af and would sell their grandma's pii for an extra dollar; but that can't happen here.

Bank doesn't know where you came from or where you're going; since you are the transport layer. Nothing of value for them to learn.

ImJasonH · a day ago

What incentive does a bank have to support this? The site and the user get what they want, and from the bank's perspective they got to freeload on the age verification the bank has performed (though admittedly they already had to anyway)

ImJasonH commented on Uv: Running a script with dependencies docs.astral.sh/uv/guides/... · Posted by u/Bluestein

simonw · a month ago

The "declaring script dependencies" thing is incredibly useful: https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

  # /// script
  # dependencies = [
  #   "requests<3",
  #   "rich",
  # ]
  # ///
  import requests, rich
  # ... script goes here

Save that as script.py and you can use "uv run script.py" to run it with the specified dependencies, magically installed into a temporary virtual environment without you having to think about them at all.

It's an implementation of Python PEP 723: https://peps.python.org/pep-0723/

Claude 4 actually knows about this trick, which means you can ask it to write you a Python script "with inline script dependencies" and it will do the right thing, e.g. https://claude.ai/share/1217b467-d273-40d0-9699-f6a38113f045 - the prompt there was:

  Write a Python script with inline script
  dependencies that uses httpx and click to
  download a large file and show a progress bar

Prior to Claude 4 I had a custom Claude project that included special instructions on how to do this, but that's not necessary any more: https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

ImJasonH · a month ago

This is cool!

This gave me the questionable idea of doing the same sort of thing for Go: https://github.com/imjasonh/gos

(Not necessarily endorsing, I was just curious to see how it would go, and it worked out okay!)

ImJasonH commented on Jeep owners fed up with in-car pop-up ads kbb.com/car-news/jeep-own... · Posted by u/spudlyo

ImJasonH · 6 months ago

> Get More From KBB.com / Simply choose the content you'd like to receive below and we'll send it straight to your inbox.

The irony.

ImJasonH commented on Serverless-registry: A Docker registry backed by Workers and R2 github.com/cloudflare/ser... · Posted by u/tosh

ImJasonH · a year ago

I built a similar PoC using Workers+R2, before Cloudflare released theirs, in case you find it useful: https://github.com/chainguard-dev/crow-registry

We eventually built our own registry in Go running on Cloud Run, which now serves all our images on cgr.dev.

Zero egress fees is really a game changer.

ImJasonH commented on Go Things I Like: slog and clog github.com/ImJasonH/ImJas... · Posted by u/ImJasonH

lcof · a year ago

I wonder if the overhead of using context values is noticeable in the context of logging. I guess you want to reconstruct the logger only when needed, kind of lazily

ImJasonH · a year ago

It might be noticeable at extreme levels, which I've never come anywhere to noticing.

I tend to only use `log := clog.FromContext(ctx)` once at the top of a method, and not `clog.InfoContext(ctx, "...")`, but that's mostly for style reasons and not performance.

ImJasonH commented on MLPerf training tests put Nvidia ahead, Intel close, and Google well behind spectrum.ieee.org/generat... · Posted by u/vissidarte_choi

sillysaurusx · 2 years ago

One bad sign is that Google recently put out a press release that they’ve achieved the largest training job ever run, but they didn’t actually train any models. It was a bandwidth test: https://news.ycombinator.com/item?id=38227836

(Shoutout to DavidSJ who sleuthed this out based on the careful wording of the post.)

This was a big shock to me since MLPerf is the gold standard for performance comparisons. The reason you want to train an actual model on real data is because it gives a precise idea of what you can expect in the field. Google’s 2019 MLPerf results are why I dove in to TPU land and fell in love with TPUs. Nowadays it’s all about language models and giant training runs and there’s not a lot of compute left over for average joes (which I very much was), but rants aren’t productive.

What would be productive is for Google to focus on the basics: focus on MLPerf. It’s the standard benchmark for a reason. I can’t fault them for going where the money is, but it’s still sad to see the sorry state of Google being dead last. I’m still rooting for you, Jax team. I believe in you.

TRC is looking better these days. If you need spare compute or just want to try out TPUs, give them a spin for a month. When I was complaining on Twitter in 2023 about TPUs being deleted after 30 minutes circa 2022, two people stepped in and said that they were happy with their quotas and haven’t observed similar pain points. So maybe they’ve solved the provisioning issues, and they’re starting to treat TRC members as more than third-class citizens again. But, especially in modern times, it’s hard to complain when compute is so scarce; you can do some pretty amazing things with TPUs if you focus on them for a few months. Thank you to the organizers of TRC (Jonathan in particular, their support lead, who is single handedly the most impressive support person I’ve ever seen by a huge margin; and Zak for keeping so many balls in the air while leading the TPU infra).

ImJasonH · 2 years ago

Saving folks a googling: TRC is "TPU Research Cloud" (https://sites.research.google/trc/about/)

ImJasonH commented on Ko: Easy Go Containers ko.build/... · Posted by u/bamazizi

jppittma · 2 years ago

Bazel has this functionality.

https://github.com/bazelbuild/rules_docker#rust_image

ImJasonH · 2 years ago

rules_docker is deprecated in favor of rules_oci, which also has Rust support: https://github.com/bazel-contrib/rules_oci/blob/main/docs/ru...

I think Bazel can be a good fit for larger polyglot organizations that need to manage large codebases in many languages in a uniform way. Basically Google-circa-2010-sized organizations, coincidentally!

For smaller teams, adopting Bazel too early can be a real productivity drain, where you get all of the downsides of its constraints without as many of its benefits. Bazel is overkill for a project of ~10 Go apps, for example. Ko was actually created to help such a project (Knative) migrate off of Bazel's rules_docker to something better, and I think it achieved the goal!

ImJasonH commented on Ko: Easy Go Containers ko.build/... · Posted by u/bamazizi

flimsypremise · 2 years ago

I'll be honest, I just don't think this is a great way to do development in any language:

`ko builds images by executing go build on your local machine`

If you've done any sort of work with service or application development on a team, you will no doubt have encountered issues with relying on local machine build dependencies. Enforcing dependency versions across the team is basically impossible even in cases where the entire team is using the same OS and hardware, so you're going to run into problems where users are building the codebase with different versions of tools and dependencies. This is one of the core problems that containerization was intended to solve, so if you are using containerization in development and not building inside the container, you are missing out on one of the major advantages of the paradigm.

ImJasonH · 2 years ago

I do agree with you in general. However, while containers were being invented to solve this problem, Go was also solving this problem.

For the most part, for the most common simple Go applications, if you build the same code with the same version of Go installed, you'll get the same dependencies and the same artifact.

Building Go applications in containers is not necessary in general, and doing so makes it much more complicated to share a build cache. You can of course do it with enough additions to your Dockerfile, but why bother?

If your developer team and CI environment are all using a similar recent Go, they shouldn't have different behavior using ko together.