underrun's comments

hard disagree. i use monospace fonts with ligatures for programming. primarily i get things like -> rendered as a full arrow or == connected or ... as an actual ellipsis. it's subtle but it's nice.

I've also seen nice use of ligature for markdown formatting.

the idea that ligatures shouldn't be used with monospace fonts would also break monospace in multiple languages as some languages require ligatures to display single characters correctly.

What if computing machines were the distributed system?

but i really want 3d vim.

...no seriously. i may have a problem...

from the article: "Being able to debug any past production code is a huge step up..."

this is pretty epic. but it also means you need to keep track of what version of your code ran every past workflow because you need to run it the exact same way when you replay it, right? Is there an easy way to track in workflow metadata or something which version of a worker (commit sha or something) ran a workflow?

also i love the beginning section about history. It would be awesome if every article I read about some new technology started with a reference to how whatever-it-is really grew out of PARC or bell labs or some research paper written pre-1980.

this is a bit dense but i hope this meta-study results in some focused research on foot ware like vibram five fingers. there are some inferences one could make from this review, and despite the closer-to-barefoot aspect of some shoes, any constraints and added protection from the ground are going to have an impact on how we walk and it would cool explore and optimize the balance between protection for the foot and taking full advantage of its anatomical function.

much more in depth approach to designing for simplicity with examples of why alternatives aren't as good:

https://zguide.zeromq.org/docs/chapter6/#Designing-for-Innov...

Do you mean the construct of probabilistic speculation applies in multirepo because you may end up with a hot spot repo that receives a high volume of commits at once?

Or do you mean that multirepo could also benefit from the construct of probabilistic speculation by ordering commits across multiple repos such that you are maximizing the number of repos that have changed before you build and minimising the number of commits applied to single repos?

Or both :-)

thanks for the link - looking forward to watching.

Currently, I'm not convinced that you need to track and apply commits across dependencies and dependent systems atomically/transactionally to have a sane build environment even at scale, but you definitely get that part free with monorepo.

Any links to docs or presentations that address that specific issue would be very welcome :-)

sorry, "this" is rather ambiguous.

You are totally correct that to achieve the same performance, correctness, and overall master level "green"ness in a multirepo system you would have to either define or detect dependencies and dependent repos, build the entire affected chain, and test the result. That part is much easier in monorepo.

What I was referring to with "this" is that Uber's method of detecting potential conflicts. In multirepo land it would be a "conflict" if two people commit to the same repo. In multirepo, therefore, detecting potential conflict is trivial.

If Bob commits to repo A and Sally commits to repo B, their commits can't result in a merge conflict. Well, unless the repos are circularly dependent - which would be bad :-) don't do that. Of course, monorepo makes that situation impossible so there's an advantage for monorepo.

It seems like whether you have mono- or multi- the problems solved by one choice will leave other problems the build system has to solve that it wouldn't have to solve if the other option were chosen.

Different work would be required in multirepo but it would be work to solve the problems that monorepo solves just by virtue of it being a monorepo.

Adrian Colyer dug into this a little further on the morning paper:

https://blog.acolyer.org/2019/04/18/keeping-master-green-at-...

His analysis indicates that what uber does as part of its build pipeline is to break up the monorepo into "targets" and for each target create something like a merkle tree (which is basically what git uses to represent commits) and use that information to detect potential conflicts (for multiple commits that would change the same target).

what it sounds like to me is that they end up simulating multirepo to enable tests to run on a batch of most likely independent commits in their build system. For multirepo users this is explicit in that this comes for free :-)

which is super interesting to me as it seems to indicate that an optimizing CI/CD systems requires dealing with all the same issues whether it's mono- or multi- repo, and problems solved by your layout result in a different set of problems that need to be resolved in your build system.

The advantages of advancing technology and building smaller safer reactors would go a long way to avoiding such disasters. Because things can go wrong is not a reason to stop research into making them better and safer. The real way to keep ahead of this is not to extend the life span of existing reactors but to build aggressively in order to take older ones offline as newer smaller safer reactors are ready.

And keep doing that.