"Why should I change? He's the one who sucks!"

That no talent ass-clown.

I got Claude to make me the exact same graph a few weeks ago! I had hypothesized that we'd see a sharp drop off, instead what I found (as this project also shows) is a rather messy average trend of outages that has been going on for some time.

The graph being all nice before the Microsoft acquisition is a fun narrative, until you realize that some products (like actions, announced on October 16th, 2018) didn't exist and therefore had no outages. Easy to correct for by setting up start dates, but not done here. For the rest that did exist (API requests, Git ops, pages, etc) I figured they could just as easily be explained with GitHub improving their observability.

It feels like they launched actions and it quickly turned out to be an operations and availability nightmare. Since then, they've been firefighting and now the problems have spread to previously stable things like issues and PRs

They rushed to launch Actions because GitLab launched them before.

BTW, GitLab called it "CI/CD" just as a navigation section on their dashboard, and that name spread outside as well, despite being weird. Weird names are easier to remember and associate with specific meaning, instead of generic characterless "Actions".

We added Actions for CI in 2020. A year later realized our entire deploy pipeline just assumed it would be up.

Webhook doesn't fire, nothing errors out, and you find out when someone asks why staging hasn't moved in two days.

The same philosophy would suggest that running some other command immediately following a particular (successful) git command is fine; it is composing relatively simple programs into a greater system. Other than the common security pitfalls of the former, said philosophy has no issue with using (for example) Jenkins instead of Actions.

But GitHub actions is not Git?

Sorry yes, that was my point. GitHub turned git into some dysmorphic DVCS version of c++ on the web. Git is fine. Maybe 10% of people use plain git, it’d all wrapped in shitty web apps. Let git be git, and let ci/cd be ci/cd, the way Linux intended.

However, I don’t work on web apps. Maybe it’s better for the JavaScript folks. I hope to never write a line of js in my lifetime.

I own one of these, it is amazingly well manufactured. Not cheap, but (with the exception of the power button) well made.

Yes, but you can get LLMFit to recommend hardware requirements with `llmfit plan --context <TOKENS> <MODEL>`.

I'm going to guess this is because the image to depth data, while good, is not perfectly accurate and therefore cannot be a shared ground truth between multiple images. At that point what you want is a more traditional structure from motion workflow, which already exists and does a decent job.

I think SideFX was the first to do that with Houdini. It's one of my favourite micro-UX features of high-end graphics software, coming in at a close second to Nuke's use of both linear and non-linear scales for slider values.

Yes, and when working with footage shot with anamorphic lenses one will have to render the footage as non-square pixels, mapped to the square pixels of our screens, to view it at its intended aspect ratio. This process is done either at the beginning (conforming the footage before sending to editorial / VFX) or end (conforming to square pixels as a final step) of the post-production workflow depending on the show.

What a bummer. It seems like what they're asking for here (a written agreement that users will be able to access 3rd party app stores) would be a win win win for Core Devices, Rebble, and users. Core Devices gets to look like a super good guy (ideally driving interest in the product), Rebble gets to look like a huge winner maintaining something for the community (as they are), and users get an open ecosystem.

There's still a chance for a win here, but looks like the door is closing.

Pixar also ships Renderman support for Blender https://rmanwiki-26.pixar.com/space/RFB26

You can see everything in your field of vision, but the area DIRECTLY in the centre has the highest level of detail. This image has high frequency animated details that are not cognisized equally by your entire FOV. The animated bit right in the middle at any given time is where your brain processes the most detail and also where you are looking.

I had to think about it, but are you saying all the stars are animated to rotate, but the amount they move between frames is too small for you to see unless it's in your fovea?

They're just so small that you only see shapeless blur outside your fovea. If you applied an artificial blur filter to the whole screen, you'd also not see any movement anymore because all high-resolution detail is removed. A 3x3 box blur will erase differences between

  X X        X
   X   and  X X
  X X        X

They are tiny and the ones not on your fovea don't register enough "pixels" for your brain to recognise the rotation.

Oh cool so it’s about the frequency?

Spatial frequency, ie. small detailed things, not temporal frequency (in this example).