I use syncthing to sync almost everything across my computer, laptop (occasional usage), server (RAID1), old laptop (powered up once every month or so), and a few other devices (that only get a small subset of my data, though). On the computer, laptop, and server, I have btrfs snapshots (snapper). Overall, this works very well, I always have 4+ copies of my data in 2+ geographical locations.

Probably its part of Flatpak?

TOR exit node IP addresses are well-known. If YouTube wants to, they can just block the TOR network.

The same amount of JXL gives you more image than JPEG? Also, it supports ridiculous resolutions (terapixel).

I took my existing JPEG file, compressed it using JXL, 15% smaller.

Then I decompressed it again into JPEG. The file was bit-for-bit identical to the original file (same hash). Blew my mind!

Directly using JXL is even better of course.

You can check heavens above (adjust your location) to check when it will be visible for you.

Wait a second, it’s going to pass over my house in 5 minutes!

Edit: Shit, clouds!

Edit2: I was able to see it through a few gaps in the cloud cover!

The link is broken, because it is attempting to create a new archive.org snapshot whenever someone clicks on it.

• Original URL
• Working archive.org link

Without UEFI, the boot process is different for each device, requires a custom boot loader, or at least explicit support by the operating system. Is your laptop going to be supported by the distribution you want to use? What about in 5 or 10 years? With UEFI, the boot process is standardized, so it should just work.

I just compared the footage from various points in time. The flap positions for T+00:48:12 (pre-entry) and T+01:05:41 are almost the same, then it rotates about its rotation axis until T+01:05:44, but suddenly it starts to rotate about ANOTHER axis, and at T+01:05:47, its at a completely new angle. I think T+01:05:44 is the point where the flap finally breaks (after touchdown, but before splashdown).

I think we have seen motion as fast as the one at T+01:04:22, but the subsequent bounce is surprisingly strong. I still think that the flap was still under some control at that point.

I heard rumors on reddit that SpaceX deliberately removed a single tile on this flap for testing purposes, but I could not find any reliable confirmation for this. They deliberately removed tiles on the engine skirt, though.

I expect the flap on the opposite side of the ship experienced a similar level of destruction. Well, that depends on whether the damage occurred because of a general loss of structural integrity because of excessive heating, or if specific localized damage on that flap allowed plasma to penetrate the heat shield, resulting in the damage that we observed. So, general structural failure vs. random damage at that location cascading into a hole in the flap.

Anyways, I am pretty sure that the complete loss of control authority on one of the flaps would be catastrophic. But the movement that we observed seemed pretty deliberate and consistent to what we saw during the suborbital test flights. Especially the unfolding of the flap at the T+01:05:42 mark is EXACTLY what we saw during the high-altitude flights, e.g., see SN8 @ T+6:33 or SN9 @ T+6:18. The forward flaps are folded back at first, and then rotate into a position perpendicular to the surface of Starship. The movement (for IFT-4) is precise, consistent with previous flights, and stops abruptly in the correct position.

Are you sure that it cannot be updated? The GitHub readme sounds like updating Tiny11 Core is impossible (and it also lacks Windows Defender), implying that Tiny 11 can in fact be updated.

Then the editor, all extensions, language servers, etc. are all running as root.