Dang, they aren't catching the booster this time, but I guess V3 is practically a new vehicle and validating the next Starship launch is probably too critical to risk damage to the launch site for now.
They're already highly confident that if they have sufficient control over the booster trajectory they can execute the chopstick catch, so they don't particularly need to demonstrate that part more. Executing a pseudo-landing at sea lets them validate their booster flight controls perfectly fine without risking the launch tower and associated hardware. They can also do stuff like stretch the trajectory and control mechanisms to their limits to see how much they can handle, and not too big a deal if something goes wrong. Presumably any actual landings will be well within the known safe limits on all parameters.
I bet this first booster also has a lot of minor weird things associated with shaking out the manufacturing process, and they don't entirely mind testing to destruction the first one to get rid of it permanently and use the ones coming from a more proven manufacturing process for important work.
The booster catch is a useful trick but when the focus is just getting SS3 into orbit without incident, you can drop a few of the boosters in the ocean with the intent to fix at a later point.
Oh hey, you're right! Somehow I read "water landing" and interpreted it as landing on one of the barges (ocisly or jrti) any clue why that isn't the case? Is super heavy just too big for the barges maybe?
They won't use barges because the booster has no landing legs (to save weight), and because the booster is massive compared to Falcon 9. Also Starship is meant for rapid reusability, and it can take days to return a barge to port and unload the booster. Getting barge landings to work would be a distraction from the goal of Starship, and SpaceX already has Falcon 9 for current payloads.
And they won't attempt a catch with the first V3 booster because it's not worth the risk. They can build a new booster every couple of months. It takes much longer to build the launch/catch tower, and they don't have any spare towers yet. A catastrophe during a booster/ship catch would set them back a year, so they'll only attempt a catch if they're confident it will succeed.
So 200-280 tons. A standard barge can support 1500-3000 tons of cargo. Even with the added weight of a catch tower and a healthy factor of safety thrust isn't gonna sink the barge. Far more likely the major hurdle would be stability issues with how tall it is.
It's not 280 tons... it's a falling object with kinetic energy so that rocket thrust is going to be very problematic for that boat especially if it' hitting unevenly.
That and there's no way for it to stand without a catch tower.
Hypothetically, what's the effect of that much thrust close to a water surface?
I.e. if they cut a hole in the middle of a barge and it was burning at touchdown "against" the ocean
I imagine water doesn't have the kinetic problems that chunks of concrete do, but also that's a LOT of energy for even water, so maybe there'd be steam issues?
In Zulip, if a thread meanders with messages about a tangent, the authors/mods can choose to move those messages to a new thread (and IIRC messages with links between the two threads are created so it's easy to jump back and forth for any missing context)
If you're laying a communications cable, you should just do fiber. It can carry any type of traffic at high data rates, and you can upgrade the speed over time by just replacing the optics at the ends rather than having to replace the whole cable. Fiber plans are only expensive if your service level is expensive, or if you have to pay to get the line run to your building
Yeah, as far as I know the only way to be sure is by putting the parent process into a cgroup. Then to kill all of the child processes you have to freeze the cgroup, enumerate the pids, send sigterm/sigkill to all of them, before unfreezing again.
Yeah, this is going to decimate your battery life. It's great to have in an emergency, don't get me wrong, but I'd probably leave data off otherwise when out remote.
I looked around last week to see if they are on the market yet, and found that Philips already seems to have helium-free MRIs for sale. I'm not sure if they just sealed it better or switched to REBCO.
My understanding is that most of the experiments for NMR with REBCO at this point are geared towards high field NMR (like 30T) whereas medical NMR field strength is down around 1-3T.
I don’t know what the cost delta is between LTS and HTS magnets, but I imagine the much broader applicability of HTS will bring manufacturing costs way down with economies of scale.
In the interim, people are still trying to figure out effective ways to joint the HTS sections.
The Linux kernel doesn't have a stable ABI. Thus, if a kernel function signature changes, or a subsystem gets refactored, etc, drivers get updated as part of the process. If the drivers lived outside the kernel tree, they would have to be updated separately by their own maintainers. That's less efficient and prone to breakage, so generally driver modules are merged into the kernel tree. Often they can even share code with other hardware devices!
Not sure what you mean by "userland" drivers here, but support for kernel modules written in rust is actively being developed. It's already being used for kernel drivers like the Asahi Linux GPU driver for M1 Macs.
But you can write userspace drivers in any language, as long as that language has basic file I/O and mmap() support. There's nothing special about using Rust for userspace drivers.
You're right - for whatever reason I had convinced myself YBCO had issues with both high current and high field. It's just high current - anything outside of a single grain has low current density.
Doing some more research to help make up for my spreading of incorrect info, I did stumble across this - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5472374/ - it seems like it's a variety of factors that make most HST not really commercially viable for MRI machines at current.