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.
I haven’t thought about it at all but you’re right. It’s surprising how nice it is that I can enter a repo and `jj new main` without needing to remember any context whatsoever.
My post was a pretty naked attempt to showcase how much less convoluted basic operations are in jj vs. git and hopefully drum up some interest. Hopefully someone bites.
It is! I've fully migrated my repos over to `main` at this point so it's rare I have to think about the difference. You could also make an alias to `jj n` or something to make it even easier.
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).
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.
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.
No collision of 2 surfboards is going to loft debris high enough to be in a stable orbit. If the common point of orbit is 500km, all of that debris will de-orbit. The only propellent on those things is krypton, so if they collide it is only going to be mechanical effects on the debris. In my search I have not found a single reputable source claiming starlink could contribute to kessler syndrome, only clickbait articles.
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.
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.
I am not interested that much in interoperability with Git.
But I am afraid of data corruption, crashes, etc.
Also, Pijul used to have severe performance problems in some situations.
I would call it ready for production if it is stable and performant.
Git interoperability can help with that: if you have an on-disk data format that's either compatible with git, or can easily be converted to git, you can keep your backups in git format, and work from them with git if something goes wrong.
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.
In between commits, the `--cache` option is still helpful because it means you can avoid running prettier on a file whose contents have changed since the last commit but not since it was last saved.
That said, formatters should be run in pre commit hooks anyway.
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.
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).
reply