Every time I've watched a landing, the video feed is janky. One might speculate that they don't want to live-stream an embarrassing failure but that seems a bit odd when it would be more embarrassing to have an explosion during launch, losing the payload.
Edit: vvvv that sounds quite reasonable, you'd think they'd do something like throw a buoy 100m away to house the actual satellite link and just do wifi from the barge to the buoy.
Keeping video feed going during the landing is way, way, way, way, way, way down the priority list. The video gets recorded, so they don't need this for analysis. It's purely a promotional thing, which is fun, but saving five seconds of the stream (even if it's an important five seconds) is only worth so much effort.
You're underestimating the shock waves those engines produce. During launches you see camera footage from miles away shaking as the engines go to full power.
Of course there are solutions, but they're all expensive, and SpaceX has better things to spend money on. It's not like the footage doesn't exist - we're just not getting it live.
I was playing safe, although i believe it does/will. I don't think they have publicly released prices for reuse and as such i thought it was a little too broad to state as fact.
People speculated that SpaceX might do something interesting with the second stage, but it's just speculation. The last time it was rumored something interesting was done with the second stage -- a test of longer-duration operations on the NROL-76 mission -- nothing was said before or after.
That'd be the fairing, the 'nosecone' that covers the payload during launch. It wasn't shown in the webcast because it has a low probability of success (they've made several attempts so far with varying degrees of accuracy and damage) and because there's no live feed from the fairing as it descends.
The aim is to get it to land in a predetermined spot in the ocean with steerable parafoils, then eventually to stick a 'bouncy castle' at that spot to soften the landing.
Yep — Pathfinder and the Mars Exploration Rovers (Spirit & Opportunity) both used airbags. NASA has since switched to the 'sky crane' method for Curiosity and the fortcoming Mars 2020 rover, lowering higher-mass payloads to the ground without contaminating the surface with rocket exhaust (as with Phoenix and the Vikings).
They've been working on fairing recovery for some time but they likely won't provide coverage until they've got all the parts sorted and can do it successfully.
This was apparently a very light payload, so there was lots of room for experimentation - attempts at recovering the fairings, and further speculation at playing with the second stage, and just playing with tolerances and approach angles given sunk cost of the extra launch power. Us fans don't always get to see or hear about those early experiments though.
CMake helps a good bit, ccache goes further, and ninja helps a bit too. But none of them can help templated header-only libraries with complex interdependencies. It gets particularly bad when the developer #includes a convenience header to bring in _everything_ in the library instead of just what they need.
Agreed. Good use of PImpl when you have large external header-only libraries is also generally recommended to keep the dependency graph nicer.
Also from what I've seen, large header-only codebases tend to be external and thus generally don't change that much, so if you can limit your own internal dependency tree ccache can still save you.
I've seen tens of thousands of lines of code compile in 30 minutes.
I've seen a hundred thousand lines of code compile in 2 minutes.
It really depends on how the project is laid out. If you're using lots of header-only libraries and try to compile monolithically (like soooooo many C++ applications do these days), you're going to have a bad (compile) time.
They usually do incremental builds. And a lot of work goes into reproducible builds so that incremental builds can be trusted. But even clean builds are typically minutes of wall-clock time. Not hours.
Of course part of the trick is that work has been distributed across a cluster, so a lot longer was spent compiling than that...
I've worked on code that took that long to compile, and the cause of the problem was usually bad recursive makefiles doing work over and over again.
At the other extreme I've also worked at Google and have seen insanely complex C++ code bases compile in 30 seconds flat.
Multiple hour build times usually show that nobody smart enough had the interest and authority to solve the problem properly. It doesn't generally mean that your project is awesome. It certainly isn't something that I would brag about.
OK, that's great for google, but "complex" doesn't necessarily mean much. Do you think the linux kernel devs are slouches? The gcc devs? Both of those projects take hours to compile on reasonable hardware, and that's not for lack of trying.
Also, sometimes it's not about code, it's about digital assets, which is going to be IO bound. I've worked on projects that took a full working day to do a clean compile and others where it was necessary to do binary integrations instead of code because the overall build time would otherwise be measured in days or weeks.
Same here. Still watch recorded in cases I missed live webcast although much less exciting. I hope ride up there within the next 20 years, hopefully sooner.
This is just so amazing. Just looks so effortless. Completely magical what they have accomplished in so little time. Thank you, Elon, for being so incredibly brave and persistent in your mission(s).
58 comments
[ 3.6 ms ] story [ 117 ms ] threadEdit: vvvv that sounds quite reasonable, you'd think they'd do something like throw a buoy 100m away to house the actual satellite link and just do wifi from the barge to the buoy.
Bouys bounce around a lot - the drone ships have special station-keeping thrusters to stay in place.
Of course there are solutions, but they're all expensive, and SpaceX has better things to spend money on. It's not like the footage doesn't exist - we're just not getting it live.
Aren't we getting close to being safe to assume that this is actually true? They've already re-used a number of boosters. (:
(sorry for the pedantry)
The aim is to get it to land in a predetermined spot in the ocean with steerable parafoils, then eventually to stick a 'bouncy castle' at that spot to soften the landing.
Your CMake makes incremental builds safe, and the ccache saves you when switching between branches.
Also from what I've seen, large header-only codebases tend to be external and thus generally don't change that much, so if you can limit your own internal dependency tree ccache can still save you.
I've seen tens of thousands of lines of code compile in 30 minutes.
I've seen a hundred thousand lines of code compile in 2 minutes.
It really depends on how the project is laid out. If you're using lots of header-only libraries and try to compile monolithically (like soooooo many C++ applications do these days), you're going to have a bad (compile) time.
Of course part of the trick is that work has been distributed across a cluster, so a lot longer was spent compiling than that...
At the other extreme I've also worked at Google and have seen insanely complex C++ code bases compile in 30 seconds flat.
Multiple hour build times usually show that nobody smart enough had the interest and authority to solve the problem properly. It doesn't generally mean that your project is awesome. It certainly isn't something that I would brag about.
Also, sometimes it's not about code, it's about digital assets, which is going to be IO bound. I've worked on projects that took a full working day to do a clean compile and others where it was necessary to do binary integrations instead of code because the overall build time would otherwise be measured in days or weeks.
They can make it to 20.
.
Which is why it's beautiful, despite the less than brilliant connection :)
Like passenger planes leaving airports, I'll never not find this amazing.