hooper

It's interesting that even clear advantages like `jj undo` are hard to communicate because of this.

Jujutsu has "first class conflicts", but it's different from Pijul's "theory of patches". As far as I know, the other big stuff like "working copy is a commit" and the "operation log" (which allows for `jj undo`, safe concurrency, etc) is not present in Pijul. The approaches to Git interop are very different.

This immediately played in my head when I read the headline.

One thing I really appreciate is that you can run `jj new master` at _any_ time to drop what you're doing and start a new change. The way jj handles the working copy, conflicts, and visible heads means there's just no need to think about uncommitted changes, unfinished conflict resolution, detached head, etc.. So many things that would get in your way just can't happen.

Part of this that hasn't been mentioned is that the mirror is thicker than you might expect. The observatory's website says 12.5 inches (though it will vary somewhat across the curved surface).

If you're trying to do it all in software, you can get pretty far with a function to draw a solid colored triangle, a function to rotate 3d points using sin and cos, and some loops. Then the other pieces like lighting and texture mapping can be added pretty incrementally (depending on how obsessed you are with optimization).

There are lots of interesting pages about this. Here's a contemporary one that comes to mind: https://www.modeemi.fi/drdoom/3dica/3dica.htm

An easy way to get your pixel color array on screen is SDL2: https://www.libsdl.org/

The image from a single curved mirror or lens will have distortions that can be reduced by adding additional curved mirrors/lenses. It's also harder to make and use large diameter lenses than mirrors. Each lens has two surfaces that need to be aligned without the possibility of post-fabrication calibration. Weight and sagging are a bigger problem for lenses. Mirrors can be thinner, partially hollow, and can have mechanical support behind them without blocking light. There are further considerations that might favor mirrors, like material cost and reaction to temperature changes. If nothing else, bending the light path back and forth with mirrors means the telescope can be shorter, easier to point, and will fit in a smaller building.

The largest exclusively lens based ("refractor") telescopes got up to about 1 meter diameter before the trade offs caused a shift to mirrors for larger apertures. Even so, it's common to have lenses near the focal plane of a mirror based ("reflector") telescope to improve the image. Vera Rubin is like that, including a 1.5 meter lens (among others) near the sensor.

The sensor doesn't actually form a blind spot in the image, because it is severely out of focus. Obstructions do affect the pattern of light a star forms on the sensor, but it's all relative, and no mirror or lens can produce perfect images.

The sun is about 400,000x the brightness of the moon, with about the same apparent size. So I think the full moon's brightness concentrated 100,000x would be almost that bad. However, having the sun in your field of view momentarily doesn't blind you (disclaimer: don't stare at the sun until it blinds you; that will blind you ("solar retinopathy")).

There are a couple of other factors. Supernova "light curves" only reach their maximum gradually over several days. Also, your eye doesn't focus an arbitrarily small light source to an arbitrarily small spot on the retina. Instead it's something like an "airy disk". At some point, the relationship between apparent size and the size of the (blurred, "diffraction limited") image on the retina is appreciably non-linear. I think it matters in this case, because Betelgeuse is a lot smaller than the eye's "resolution" of about 1/60th degree. So its light is concentrated that much less (squared). In a supernova, the "size" of the star increases over time, though maybe not enough to matter, even for Betelgeuse.

The debris orbits from an initial collision don't have to be stable to allow a chain reaction that produces debris in more stable orbits. Debris from even a single low altitude collision/disintegration could collide/disintegrate later at a higher altitude, producing debris with a higher periapsis than any of the original bodies.

There are many factors in whether this matters practically, so I'm not passing judgement on that. None of this is specific to Starlink.

Debris orbits like anything else. Regardless of the orbits of the colliding objects, the orbit of any debris is only really constrained to intersect the point of collision. For some debris, the point of collision could be the lowest point in its new orbit, meaning it could take longer to reenter and could collide with other stuff higher up until then. On the other extreme, some debris could essentially fall straight down to earth immediately.

If considering a trip to this area, be sure to read about McDonald Observatory's star parties and especially the special viewing nights. It's one of the best places to look through a very large telescope in a very dark place. Even looking around from the mountain top, or just the parking lot, is a special experience.

I get the feeling that depends on who you ask at this point, but there has apparently been some recent development of the hosting platform (https://nest.pijul.com/). I don't know if it can have as good of a Git interoperability story as, say, jj.

One of the ideas behind Pijul is that implicit vs explicit diffs does make an important difference sometimes: https://pijul.org/manual/why_pijul.html

If your files are under version control, you already have a generic change detection mechanism that can give you a shorter list of changed files that need to be checked for formatting. For example, you can run code formatters in pre-commit hooks. Mercurial's "fix" extension rewrites commits using formatting fixes that can be focused on changed line ranges. Of course, the purpose of this --cache feature is still valid for other situations.

I think it's more to maintain pressure in the tank, in cases where the remaining fuel doesn't vaporize sufficiently on its own (autogenous pressurization). Otherwise, I guess atmospheric pressure or compressive force from the engines/payload could crush the tank. In the case of Starship, the fuel is moved by turbo pumps, which are integrated with the engine, and are powered by burning some of the fuel (there's a diagram of this at https://en.wikipedia.org/wiki/SpaceX_Raptor).

I've heard of using a gas driven plunger in fuel tanks, but I can't remember the name of the vehicle that did this. Starship uses small "header tanks" that have a similar effect. Weight and reliability are big priorities in this kind of system.

No. If you look at the map you'll see that there's an equally sized coverage gap at each pole. I don't know if any reliable source has stated whether they will put any satellites in orbits that can cover the poles, but I imagine it's a pretty low priority commercially.

There is already some polar coverage from the Iridium network, which uses orbits with higher inclination.

The data on this map makes it look like they're going for pretty uniform coverage already. Is there a source for the early orbital planes having a specific purpose? The earth rotates underneath each plane, and the times of day it will be available to any given ground path change over the course of a year.

It does seem pretty convenient that the inclination they've chosen lines the satellites up nearly in a straight path from New York to London, but I imagine this would be relevant to many transatlantic communications.