kvnhn

Rebase (squash), I assume

Sheriffs are elected officials, at least in most states.

What does your username mean?

I made a simple web UI[1] for generating images like this. It uses a Go library by Michael Fogleman[2] for all the heavy lifting—hat’s off to him.

For Bézier curves in particular, iteratively constraining the search around initial matches seems key to retaining detail (see the “rep” argument in Fogleman’s work), for example in the eyes of the Vermeer portrait in the OP.

[1] https://github.com/kevin-hanselman/primitive-web-ui

[2] https://github.com/fogleman/primitive

IMO, a key passage that's buried:

"You can ask the agent for advice on ways to improve your application, but be really careful; it loves to “improve” things, and is quick to suggest adding abstraction layers, etc. Every single idea it gives you will seem valid, and most of them will seem like things that you should really consider doing. RESIST THE URGE..."

A thousand times this. LLMs love to over-engineer things. I often wonder how much of this is attributable to the training data...

Dud author here. Happy to hear it's working well for you!

This is a variation on one of my favorite software design principles: Make illegal states unrepresentable. I first learned about it through Scott Wlaschin[1].

[1] https://fsharpforfunandprofit.com/posts/designing-with-types...

IMHO, Poetry is the best we have in the Python dep mgmt space, and it's still endlessly frustrating. It's especially hard to recommend it for newbies looking to get up and running with even a simple ML stack. Check out this thread[1] on the Kafkaesque nightmare that is trying to install PyTorch with Poetry.

[1] https://github.com/python-poetry/poetry/issues/6409

PEP 582 was rejected, FYI.

https://peps.python.org/pep-0582/

I've used DVC in the past and generally liked its approach. That said, I wholeheartedly agree that it's clunky. It does a lot of things implicitly, which can make it hard to reason about. It was also extremely slow for medium-sized datasets (low 10s of GBs).

In response, I created a command-line tool that addresses these issues[0]. To reduce the comparison to an analogy: Dud : DVC :: Flask : Django. I have a longer comparison in the README[1].

[0] https://github.com/kevin-hanselman/dud

[1] https://github.com/kevin-hanselman/dud/blob/main/README.md#m...

You might be referring to me/Dud[0]. If you are, first off, thanks! I'd love to know more about what development progress you are hoping for. Is there a specific set of features that bar you from using Dud? As far as testing, Dud has a large and growing set of unit and integration tests[1] that are run in Github CI. I'll never have the same resources as Iterative/DVC, but my hope is that being open source will attract collaborators. PRs are always welcome ;)

[0] https://github.com/kevin-hanselman/dud

[1] https://github.com/kevin-hanselman/dud/tree/main/integration...

Unfortunately, there's a few things that currently hinder compatibility with DVC caches. First, Dud uses the Blake3 checksum algorithm, and DVC uses md5. This means the content-addressed caches will have completely different file names. Second, directories are committed to DVC differently than they are in Dud. For directories, not only will the committed file names not match (due to point 1), but the contents will not match either. Both of these things could be addressed, but it would take a lot of effort and would likely cost Dud in terms of its two main goals, speed and simplicity. I'm not opposed to this if we can make it work, though.

Dud currently does not support reflinks, but I think adding reflink support would be fairly straight-forward. Just curious: What filesystem and OS are you using for reflinks?

I'd be happy to chat more about this. Feel free to open GitHub issues for these items. I welcome contributions as well. ;)

I very much agree with you about DVC's feature creep. The other issue I have with it is speed. DVC has left me scratching my head at its sluggishness many times. Because of these factors, I've been working on an alternative that focuses on simplicity and speed[0]. My tool is often five to ten times faster than DVC[1]. I'd love to hear what you think.

[0] https://github.com/kevin-hanselman/dud

[1] https://kevin-hanselman.github.io/dud/benchmarks/

I don't know about replacing Make with Docker, but I use the two together to good effect. One of my favorite hacks is adding a 'docker-%' rule in my Makefile to run make commands in a Docker image[1]. It's a bit mind-bending, and there's a few gotchas, but it works surprisingly well for simple rules.

[1] https://github.com/kevin-hanselman/dud/blob/e98de8fcdf7ad564...

A thousand times, yes. I've wanted to write this same article. Thanks for saving me the time!

The industry is going to great lengths to avoid writing configuration in any ubiquitous imperative programming language. We're seeing the proliferation of hyper-specialized, clunky declarative languages with sub-par tooling and package ecosystems. In what world are templates acceptable code? I don't mean to pick on anything specific, but this[0] is the most recent example I've come across, and it's far from the most unreadable examples.

[0] https://github.com/traefik/traefik-helm-chart/blob/master/tr...

Here's an example I whipped up: https://github.com/kevin-hanselman/tailscale-forward-auth

I haven't used it, no. Around the time Git LFS was released, my read from the community was that Git LFS was favored to supersede git-annex, so I focused my time investigating Git LFS. Given that git-annex is still alive and well, I may have discounted it too quickly :) Maybe I'll revisit it in the future. Thanks for sharing!

Dud author here. I'm guessing this was shared after I mentioned it[0] in the comments on this recent post[1].

Thanks, kind stranger, for sharing! I'm happy to answer any questions.

[0] https://news.ycombinator.com/item?id=31008992

[1] https://news.ycombinator.com/item?id=31006003

This is by no means a perfect match for your requirements, but I'll share a CLI tool I built, called Dud[0]. At the least it may spur some ideas.

Dud is meant to be a companion to SCM (e.g. Git) for large files. I was turned off of Git LFS after a couple failed attempts at using it for data science work. DVC[1] is an improvement in many ways, but it has some rough edges and serious performance issues[2].

With Dud I focused on speed and simplicity. To your three points above:

1) Dud can comfortably track datasets in the 100s of GBs. In practice, the bottleneck is your disk I/O speed.

2) Dud checks out binaries as links by default, so it's super fast to switch between commits.

3) Dud includes a means to build data pipelines -- think Makefiles with less footguns. Dud can detect when outputs are up to date and skip executing a pipeline stage.

I hope this helps, and I'd be happy to chat about it.

[0] https://github.com/kevin-hanselman/dud

[1] https://dvc.org

[2] https://github.com/kevin-hanselman/dud#concrete-differences-...

Thanks for sharing your experience. It's non-trivial and surprising behavior like this that drove me to build a custom system[0] myself.

When I started researching version control tools for large files, I remember feeling like git-annex and Git LFS were awkwardly bolted onto Git; Git simply wasn't designed for large files. Then I found DVC[1], and its approach rang true for me. However, after using DVC for a year or so, I grew tired of its many puzzling behaviors (most of which are outlined in the README at [0]). In the end, I built the tool I wanted for the job -- one that is exceptionally simple and fast.

[0] https://github.com/kevin-hanselman/dud

[1] https://dvc.org/

Maybe not precisely what you want, but I built a CLI tool[1] that's like a simplified and decoupled Git-LFS. It tracks large files in a content-addressed directory, and then you track the references to that store in source control. Data compression isn't a top priority for my tool; it uses immutable symlinks, not archives.

[1] https://github.com/kevin-hanselman/dud

I highly recommend the book Kubernetes In Action by Lukša [1]. It's a fantastic walkthrough of the whole containerized stack -- from Docker containers through the Kubernetes API and some info on Kubernetes internals towards the end. This is one of those rare books that takes an intimidating topic (k8s) and makes it all make perfect sense. It's heavily examples-driven with lots of annotated code and diagrams. The first edition uses both minikube and GKE.

[1] https://www.manning.com/books/kubernetes-in-action-second-ed...

Thanks for sharing this. It's very hard to lend credence to this series after reading this follow-up. Quoting from the link:

"There are certainly many reasons to hate Go, from the unusual syntax to the half-arsed way they decided to implement the programming model. On the other hand you can go all fanboy over how cool Go is because it makes it so simple to write microservices. (No, it doesn’t. It really, really doesn’t if you want to do it properly.)

If you jumped on either of these bandwagons, I would recommend getting off as soon as possible. Neither of these approaches are very professional and are telling signs of inexperience in software development."

There is an upsetting level of hypocrisy in patronizing your readers for consuming the clickbait-titled articles _you authored_.

I agree that decoupling from Git has its benefits, and I've built a tool[1] that seems to meet some of your needs above. The idea is to save binary data in a separate content-addressed store and have Git track references to specific files in said store. If you check it out, I'd be happy to hear what you think!

[1] https://github.com/kevin-hanselman/dud

I've been working on Dud[1] to help solve this problem. Coincidentally I released v0.2.0 today.

The core idea is to version large files/directories in a content-addressed store, and to track the content addresses (i.e. checksums) in source control (e.g. Git) for historical traceability.

For a practical example of how Dud works, check out the Getting Started page[2].

[1] https://github.com/kevin-hanselman/dud

[2] https://kevin-hanselman.github.io/dud/getting_started/

For those complaining that the study is bogus or exaggerated, here's a more believable anecdote with a similar implication, recounted by the Freakonomics authors:

What the Bagel Man Saw (2004): https://news.ycombinator.com/item?id=28327228

Can't agree more with this. I too am a (neo)vim + tmux dev, and I made the same progression in shells. Fish just works out of the box. I actually stopped using autojump (see Better CD in the article) because Fish's context-aware auto-completion is that good.

Cross-compiling will become possible. For years we've told people "sorry, distutils wasn't really made for cross-compiling, let us know if you have any luck". As a result we've completely ignored users on some exotic platforms, and also spent a lot of time fighting with different CI systems to do native builds.

As a user (not a developer) of SciPy, this is the big win. My "exotic platform" is embedded Linux distributions via Buildroot[1]. This opens the door to many downstream libraries becoming available as well, such as pandas and scikit-learn.

[1] https://buildroot.org/

This looks very cool! Content addressed storage is an incredibly powerful concept, and weaving it into a programming language is a compelling idea.

Question for the devs: How does one deploy Unison code? After my first glance through the docs I don't have a clear picture.

Dud author here. I built Dud because I love DVC[1], but I wanted something faster and simpler. As I write in the README: If DVC is Django, Dud aims to be Flask. Dud is much faster, it has a smaller feature set, and it is distributed as a single executable.

I'd be happy to answer questions and hear your feedback.

[1] https://dvc.org