dimatura

Only tangentially related but many many years ago, I spent a good chunk of a summer internship at synopsys fixing gcc warnings in one of their products. The codebase was huge, with many parts of it more than a decade old at that point. I learned a lot about obscure corners of C. These days a frontier model could do that job in a few days (or maybe just one day if the build and testing process has been sped up - it took several hours on a dedicated cluster back then).

Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.

I designed and deployed several custom CNN-based AI models to ipad hosts around 2018-2020. It was a finicky process - CoreML didn't give you much control (or even feedback) on what parts of your model would run on the CPU, GPU, or ANE - but you could usually tell right away when they didn't, just based on big latency differences. Performance to power (and size) ratio was pretty good and I was impressed at the time, despite being generally not really happy about working with the apple ecosystem. I would've preferred something Android (or Linux)-based but there wasn't really anything comparable out there back then. (SBCs like the Jetson would've worked, but we would've had to figure out how to add an interface for human operators which would've been a big lift compared to just using off the shelf hardware).

It's not such a big deal compared to pip for a typical python package, but a couple of use cases where the speed is a nice feature are tool running with uvx and inline dependencies in scripts - you'll still see something is installed the first time you run the tool/script, but usually it's fast enough to not notice.

One could also make a comparison to another popular tool, conda, which is glacially slow, but that would arguably be unfair since conda does things uv doesn't.

More generally, it's still a nice thing, though. It's just a little less friction. Even a few seconds slower can nudge you towards different behavior

I've had similar thoughts in regards to generative AI applied to the arts. Taste is subjective, but if you ask 100 random people to rank an AI-generated techno or country track versus one created by an "average" human creator (including amateurs), the AI would probably do pretty well. But if now anyone can create a competent, generic song in a well-known genre, then that sound becomes a lot less interesting, human-made or not. Of course, it turns out a lot of people don't care and will listen to whatever, but I suspect that for those who do, there'll be a higher percentage seeking something weird and new.

Yeah, I've been using this for a long time, works fine.

I remember similar observations for an earlier use case in computer vision, loop closure and place recognition for visual SLAM algorithms. In this case the goal was to find a needle (or needles) in a big haystack of visual descriptors (in some sense, proto-embeddings for small image patches or in some cases, whole images). Several approaches used hierarchical data structures for the NN search such as k-mean trees. But linear search - especially with binary descriptors, also became popular as a fast and simple alternative.

I agree with everything you're saying, but if you consider that this is a single-person company, the "hardware is as hard as you make it" statement makes sense. He saw a need, found out that it would be feasible to make a product to fill that need with very simple hardware, and chose to make the product. If solving the problem would've required hardware outside beyond their budget or skill level to make then presumably they wouldn't have pursued the whole project. Which I guess is sort of the point, but of course the title of the blog post doesn't really convey that.

I think "hardware is as hard as you make it" would've been a better title. The author made the smart decision of keeping things very simple on the hardware side, and that happened to be possible for the kind of product he wanted to make.

Interestingly I've heard a very similar story and sentiment about hardware vs software from another single-person maker (also a software engineer by trade) of a hardware product, also in the music space. And this one was comparatively a more complex product on the hardware side, and did face some supply challenges during covid and tariffs, forcing at least one redesign and price raise. But in both cases, I'd say they made smart choices about keeping the hardware simple. By not pushing the envelope on that front they gave themselves the freedom to invest a lot of time and effort into the software. But not every hardware product is like that (which the author also does acknowledge).

Yeah, I think a lot of the "hardness" of hardware is of a different flavor than software. The author mentions how many lines of code are in the software, but that really is more of a symptom of something that makes software "easier": you have way more flexibility to iterate, and try new things, at a relatively low risk and cost, even if it's embedded software (at least for non-critical applications). Hardware is just more unforgiving. There's no cheap way out of the kind of scenarios you mention.

They are simpler and can be read by more devices, especially legacy devices that are still pretty widely deployed. Other than that, not much to say in their favor. They have lower data density compared to 2D codes such as QR or datamatrix. Many linear barcode symbologies have weak or nonexistent error correction capability. But often you don't need that extra data, and the cost of changing processes and equipment to upgrade to a new barcode format is seen as not worth it.

Very cool work - refreshing to see a of different approach. I learned about Kuramoto oscillators many years ago from a book called Sync, by Steven Strogatz, which I highly recommend.

There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that did not use git but I didn't get the chance to try it. I've also tried oxen and it wasn't bad at first, but soon ran into some weird issues with the repo state which I didn't really try to debug. It is clear to me at this point, given my experience with all these systems -- none of which I've been 100% happy with -- that "git for data" is a nontrivial problem.

Of course it can. Is it good at it? I guess we'll find out, for sure people will try (I might if I get some spare time). At a glance some of the tech used resembles that of xethub (of which I was a user, until they got acquired by huggingface), which was marketed towards AI/ML/data science (to version control data/models/etc).