This is super interesting, as I maintain a 1M commits / 10GB size repo at work, and I'm researching ways to have it cloned by the users faster. Basically for now I do a very similar thing manually, storing a "seed" repo in S3 and having a custom script to fetch from S3 instead of doing `git clone`. (It's faster than cloning from GitHub, as apart from not having to enumerate millions of objects, S3 doesn't throttle the download, while GH seem to throttle at 16MiB/s.)
Semi-related: I always wondered but never got time to dig into what exactly are the contents of the exchange between server and client; I sometimes notice that when creating a new branch off
main (still talking the 1M commits repo), with just one new tiny commit, the amount of data the client sends is way bigger than I expected (tens of MBs). I always assumed the client somehow established with the server that it has a certain sha, and only uploads missing commit, but it seems it's not exactly the case when creating a new branch.
I started learning prolog just a few months ago, when I stumbled upon https://linusakesson.net/dialog/ which is a spin on prolog optimized for writing interactive fiction.
I terms of Prolog implementations I played a bit with https://www.scryer.pl but it still feels rough around the edges.
SWI-Prolog is the most popular and most batteries included Prolog: https://www.swi-prolog.org
With its libraries and documentation it is a very practical language. What surprised me is, that you can easily produce amazingly small stand-alone binaries.
I sell custom jewelry on Etsy and my Shopify website (lulimjewelry.com). I have a background in 3d printing and through that I realized that the sweet spot for 3d printed products is something that is small, high value, and custom. The jewelry industry fits this perfectly, and has already seen a large uptake in 3d printer adoption.
I built a pipeline using fabric.js, flask, and blender that lets me take my customer's customizations (fingerprints, signatures, other engravings) and place them on a ring. I ultimately generate a STL file that I send over to my casting house in LA. They 3d print the STL in wax, and then cast that wax mould with precious metals using the traditional casting process.
It's a fun side business as I get to tinker with new technologies (recently working on integrating a LLM into the ring design process). I have decent profits (enough to pay my mom and sister to help with customer support and shipping), so the workload I take on myself is relatively small.
https://bauble.studio/ is a lisp-based procedural 3D art playground that I hacked together a while ago. It's fun to play with, but it's a very limiting tool: you can do a lot to compose signed distance functions, but there's no way to control the rendering or do anything "custom" that the tool doesn't explicitly allow.
So lately I've been working on a "v2" that exposes a full superset of GLSL, so you can write arbitrary shaders -- even foregoing SDFs altogether -- in a high-level lisp language. The core "default" raymarcher is still there, but you can choose to ignore it and implement, say, volumetric rendering, while still using the provided SDF combinators if you want.
The new implementation is much more general and flexible, and it now supports things like 2D extrusions, mesh export for 3D printing, user-defined procedural noise functions... anything you can do in Shadertoy, you can now do in Bauble. One upcoming feature that I'm very excited about is custom uniforms and embedding in other webpages -- so you can write a blog post with interactive 3D visualizations, for example.
The Braille Institute has a a big interest in helping people with low vision and a few years ago commissioned a highly legible font Atkinson Hyperlegible https://brailleinstitute.org/freefont
They did a lot of work making sure it was easy to read by working with actual people.
We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.
Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.
The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. We’re aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1.
EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets.
We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we’d be happy to consider them.
Semi-related: I always wondered but never got time to dig into what exactly are the contents of the exchange between server and client; I sometimes notice that when creating a new branch off main (still talking the 1M commits repo), with just one new tiny commit, the amount of data the client sends is way bigger than I expected (tens of MBs). I always assumed the client somehow established with the server that it has a certain sha, and only uploads missing commit, but it seems it's not exactly the case when creating a new branch.