I now use syncthing for the .git directory, excluding HEAD file and a few others, between my few devices and a vps on hetzner.
Most of git is append only immutable blobs - just sharing these between devices just works for me. "users" and authentication is handled by syncthing.
I have pre and post hooks to make sure no device tries to change HEAD of branch owned by another device, just to be safe, be it hasn't been activated once yet.
I read the piece, looks cool, but it merges Dockerfile with docker image?
If instead of using Dockerfile they would have a direct build of the image tar file with something like nix then it would have been easier, though admittedly mildly esoteric
I've given the following exercise to developers in a few workplaces:
What's the complexity of computing the nth fibonacci number? Make a graph of computation time with n=1..300 that visualizes your answer.
There are those that very quickly reply linear but admit they can't get a graph to corroborate, and there are those that very quickly say linear and even produce the graph! (though not correct fibonacci numbers...)
Dask for python satisfies exactly these requirements, just in the python ecosystem. A pattern I have been using at multiple workplaces for the last decade was to start a dask cluster (maybe 10 years ago I would start an ipyparallel cluster) on any node that does computation, then as I needed I would spin new nodes and connect them. This gives dynamic infinite scalability, with almost no overhead or even code debt - the dask interfaces are great even without using distributed computing.
When I wasn't allowed to use containers, I would sneakily add code to other machines to join my dask clusters. I would connect any and all computing devices.
One company pushed us to use databricks and spark, and I never got it - why would we commit to a cluster size before we started a computation?
The innovation is to find traces of a global cosmic-ray event with which to connect the dating of objects in one local area, Greece, where the dendrochronological data is not continuous, with those in far away local areas, for example England/Ireland, where we have continuous dendrochronological data
I get the sentiment, but personally I can easily imagine myself writing an autocompleter that would work fine with select before from. (I don't write much sql so I don't)
Just to clarify, my point is that when we do write sql most of us start by writing the from part, and even if we didn't I can just offer all columns from all tables I know about with some heuristic for their order when autocompleting in the select part.
This is lovely, I didn't know. I guess this is what Kuhn was talking about, we write history in retrospective, sorting it out preferring narrative over fact.
Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage.
Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that?
The major issue with big files is resources: storage, and network bandwidth. But for both of these it is the sum of all object sizes in a repo that matters, not any particular file, so it's weird to be harking on big files being bad design or evil.
This definitely fits with Grothendieck's philosophy: he basically ignored all work in this area, implicitly claiming it was trivial, while some of his closest friends and most famous student made huge strides with actual hard work - not quite things falling into place. In fact, the paper most famously proving the Weil conjectures has as an explicit target the coefficients of a modular form, uses an inspiration from automorphic forms theory, and is infamously Grothendieck's greatest disappointment.
There is rich structure in this area of maths that goes well beyond just sections of some sheaf, or at least this is what Serre, Deligne, Langlands, Mazur, Katz, Hida, Taylor, Wiles and many others seem to think.
First, they can be differential forms, not only functions. Second, there's an important note that we don't look only at things over C. For example, specifically in the context of Fermat's Last Theorem, we need Hida's theory of p-adic families of modular forms. Much of the arithmetic of modular forms comes from the modular curves being algebraic and (almost) defined over the integers.
Actually, AFAIU the TLA+ proof is only for a few small cluster sizes - not for all sizes. And the number of nodes in the painting is definitely above that checked by TLA+...
So 4.6min, i.e. 4:36