> The percent propellant has huge implications on the ease of fabrication and robustness in achieving the engineering design (and cost). If a vehicle is less than 10% propellant, it is typically made from billets of steel. Changes to its structure are readily done without engineering analysis; you simple weld on another hunk of steel to reinforce the frame according to what your intuition might say. I can easily overload my ¾ ton pickup by a factor of two. It might be moving slowly but it is hauling the load.
> Once the vehicles become airborne, the engineering becomes more serious. Light weight structures made of aluminum, magnesium, titanium, epoxy-graphite composites are the norm. To alter the structure takes significant engineering; one does not simply weld on another chunk to your airframe if you want to live (or drill a hole through some convenient section). These vehicles cannot operate far from their designed limits; overloading an airplane by a factor of two results in disaster. Even though these vehicles are 30 to 40% propellant (60 to 70% structure and payload), there is room for engineering to comfortably operate thus there is a robust, safe, and cost effective aviation industry.
> Rockets at 85% propellant and 15% structure and payload are on the extreme edge of our engineering ability to even fabricate (and to pay for!). They require constant engineering to keep flying. The seemingly smallest modifications require monumental analysis and testing of prototypes in vacuum chambers, shaker tables, and sometimes test launches in desert regions. Typical margins in structural design are 40%. Often, testing and analysis are only taken to 10% above the designed limit. For a Space Shuttle launch, 3 g’s are the designed limit of acceleration. The stack has been certified (meaning tested to the point that we know it will keep working) to 3.3 g’s. This operation has a 10% envelope for error. Imagine driving your car at 60 mph and then drifting to 66 mph, only to have your car self-destruct. This is life riding rockets, compliments of the rocket equation.
Interesting post. I'd never thought of it that way. Not consciously anyway.
Might that make an air-launched system more reliable? Even if it's less efficient, the TCO would be lower using a winged system for the initial phases of launch.
Several air launch systems have been tried, with limited but non-zero commercial success. The altitude and speed you get from the plane is very small compared to the total work the rocket needs to do, so the benefit in terms of "the rocket can be smaller" is minimal. The main benefit in practice has been launching from ~wherever you like, since regular fixed launch sites usually have strict limits about the direction you have to fly to avoid people. But the economics of reusability are pushing rockets to get bigger, and no air launch system can fly anything nearly as big as a Falcon 9, much less a Starship + Super Heavy. Other scattered problems:
- Hanging under-wing is a totally different set of forces than standing vertically, especially for a big rocket with thin walls. You're more like a bridge than a tower, or rather like a bridge one moment and then a tower the next. You need reinforcement for that, which makes the vehicle heavier.
- Modern reusable rockets do quick "load and go" filling to keep their propellant as cold and dense as possible. You can't do that if you need to fuel on the ground and then hang off an airplane for ~an hour while it climbs.
It wouldn’t help much, sadly. Getting to orbit is about speed, not height — you need 27000 kph to get to orbit, and having an air launched platform would shave off 1k kph off it at most, perhaps 5k with some insane hypersonic engineering.
Main advantage of air launch is that you can better match your target inclination or perhaps even orbit timing - just drop the rocket at the right time in the right direction over the ocean. With a fixed launch site you always need to adjust for some difference of your point of origin versus the orbit you want to achieve.
Sure but the main disadvantage that you need another highly complex vehicle. Best case its a existing commercial platform like Virgin Orbit, but then you are limited by the size. Or you design another whole vehicle that more complex then the rocket itself.
And even then you need to have all the infrastructure flying and integrated rather as nice static pad.
You are also putting human in bigger danger unless you want to have another autonomous highly complex vehicle.
The benefits are simply better addressed by having 2-3 launch pads.
cubesat + small rocket. Orbital mechanics require a burn at a later time in the orbit, to avoid coming back to say hello again to Mr. Trebuchet (Ignoring Earth's rotation)
It helps a bit more than you imply, though: if you can launch from a higher altitude, you have less atmosphere to plow through. That lets you use more of your propellant to speed up instead of to push air out of the way.
You've just got the problem of building a fixed wing aircraft which can carry your rocket full of explosive propellant, successfully release it pointing in the right direction and then get the hell out of the way....
That isn’t very helpful considering rocket launches only spend a few seconds in atmosphere mostly going vertically to get above the majority as quickly as possible .
There are some companies working on that and / or there have been some experiments with it, but there's two factors there; the one is of course how much weight an aircraft can carry. The other one is the altitude and / or angle; a big plane goes to about 10 kilometers (maybe more, idk), but that's a 'flat' flight, ideally you launch while angled upwards and that's a bit more involved.
But that's how a lot of the X projects were / are done.
There’s actually been commercial launch services using air launch - Virgin Orbit, which went bankrupt, and Northrop Grumman’s (acquired as part of Orbital ATK) Pegasus, which hasn’t launched since 2021 and has one launch planned in 2026.
To add to this excellent explanation:
Rockets have a fundamental problem. They need to go absurdly fast. If you have a rocket that can reach speed X, to go faster than X you need to reach X but also have fuel left over. However to get that fuel to speed X, you need even more fuel. This is the tyranny of the rocket equation.
Roughly put, the rocket equation is: change in speed = (engine efficiency) * log(mass of the rocket with fuel / mass of the rocket without fuel). So there's limited parameters to play with:
- The speed you need to reach is fixed.
- You can change the weight of the payload. Payload (eg, satellite) designers try to make things as light as possible, rocket designers try to give as much capacity as possible, and everyone prays they can meet in the middle.
- You want as little propellant as possible for cost and practicality, but mostly the other parameters fix how much you need. If the other parameters aren't good enough, you can easily get results like needing a rocket the size of Central Park. [1]
- You can make the engine more efficient. This means running it hotter with higher pressure, pushing the limits of material science. [2]
- You can make the non-payload static parts of the rocket lighter. This means removing structural integrity. It also means making the lightest parts to complete hard tasks like being a valve for cryogenically cooled, literally the smallest element, hydrogen.
Both the engine and non-payload static mass are essentially asking the question "How far can I push this without it breaking". Get your answer to that question even slightly wrong on any of the thousands parts in a rocket, and suddenly all of the fuel that you're using to go in one direction fast decide that you should instead go in every direction fast.
[2] Or not using chemical propulsion. However things like ion engines don't have enough thrust to get through the atmosphere and into orbit, and things like nuclear propulsion spew fallout everywhere.
Nuclear rockets aren't suitable to get orbit, they are too heavy. Also, nuclear rockets can separate the reactor and the propellant, called close cycle. I think the solid core reactors that are feasible send propellant through reactor but all of the fuel is encased.
I don't know anything about this particular launch, but one reason static fires sometimes load more fuel than you'd think is that the hold-down clamps aren't rated for the total thrust of the vehicle. Launch thrust is usually 1.2-1.6x the launch weight (if it's <1x you will not go to space today), so after subtracting gravity you've got 0.2-0.6x the weight acting upwards on the clamps. But rockets are mostly fuel by weight, so if you static fire it nearly empty, then that gravity term goes to ~zero, and the clamps have to hold the full 1.2-1.6x. You could overbuild them to handle that -- which isn't the end of the world, because they don't need to fly -- but it can be easier to just add extra fuel and detank it afterwards.
I don't know if it'd be a factor for BO, but doesn't the ignition sequence sometimes use gravity feed to begin with, before the turbo pumps kick in, with the height of the fuel tanks meaning that full tanks add a few atm of pressure. Therefore, a test without full tanks isn't exactly replicating the normal ignition sequencing conditions.
You've got two large tanks making up the bulk of the stage's structure - one for oxidizer, one for fuel. They have large diameter pipes that feed propellant to the engines. You can't mix the ballast with either the oxidizer or fuel, and you can't feed the engines from anywhere but the propellant tanks...
If you are writing an integration test for some new and potentially bug-ridden code then you might opt to mock, say, the database connection.
Doing so risks having to write so much database logic — with all the potential for getting that code buggy as well — that it’s often better to avoid the mock and test the entire system, end-to-end.
The vehicle is designed to hold all that fuel, plus whatever payload it carries on top, but it's not designed to have heavy loads attached to it in any other way. Rockets are so intensely optimized for weight that sometimes they're barely strong enough to stand upright if you fuel them the wrong way: https://www.youtube.com/watch?v=imkdz63agHY.
That's a great video! Thank you for sharing it. A rocket is more like a soda can than a building but it's hard to relate when you see such a massive object!
You can see a similar effect after the explosion at the end of last week's Starship test flight. If you look at where the flames are coming out after the first fireball clears, it kind of pancakes under its own weight there: https://www.youtube.com/live/Zi2SU98BAD8?t=5735s
Oh huh. You really can. I didn't pick up on that the first few hundred times I watched it. That's really cool. It kind of splats down into a 2-d rectangle.
It's been said that the most amazing engineering of the whole Shuttle program was the external fuel tank (and there is one with the static display of Endeavour here at the California Science Center in LA).
Bear in mind that a lot of what's happening to the tiles now is deliberate experiments to see how much weight they can shave off and how many failed tiles they can survive. Given that the vehicle is routinely surviving reentry at this point, it doesn't seem "hard" to make the tiles more robust by paying for it with added weight. The question is whether they'll have enough weight budget to pay for it? But at this point...probably? Not my area ofc.
Human rating is irrelevant to what they want to do, it is only a NASA rating - if NASA wants to ride they will have to come up with a rationale but private astronauts can fly on it.
Scott Manley pointed out that it seemed to flip in the wrong direction, with one of the grid fins passing through the plume and inducing a roll. Will be interesting to hear more about that.
Some weird nils don't compare equal to other nils. It's surprisingly easy to construct the weird kind by accident, because the conversion is automatic and invisible.
Nope! But basically, expect anything that resolves usernames, or host names, to be done in the userspace by NSS.
Sun engineers Thomas Maslen and Sanjay Dani were the first to design and implement
the Name Service Switch. They fulfilled Solaris requirements with the nsswitch.conf
file specification and the implementation choice to load database access modules as
dynamically loaded libraries, which Sun was also the first to introduce.
Sun engineers' original design of the configuration file and runtime loading of name
service back-end libraries has withstood the test of time as operating systems have
evolved and new name services are introduced. Over the years, programmers ported the
NSS configuration file with nearly identical implementations to many other operating
systems including FreeBSD, NetBSD, Linux, HP-UX, IRIX and AIX.[citation needed] More
than two decades after the NSS was invented, GNU libc implements it almost identically.
musl has its own approach to this, it's called nscd
It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call.
I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow these to be handled in a more complex way (thus allowing YellowPages, LDAP, or whatever you can imagine).
Obviously, if you tie the ability to handle those things to your filesystem layout, either by loading dynamic libraries from whatever is /usr/lib, or by reading /etc/whatever.conf, or even providing a whole virtual mount à la /proc, chroot'ing gives you both with the ability to override the system-wide policy for yourself (pretty reasonable for DNS lookups, kinda dubious for username lookups) and the opportunity to accidentally pwn yourself.
Frankly, sometimes I feel that on Linux, root should be restricted to executing/loading only a whitelist of executables/shared objects, identified by hash of the contents, not the file paths. But then again, you'll need a allow_for_root(1) utility to maintain this whitelist, and people absolutely will call it in their setup scripts in all kinds of dubious manner.
What alternative solution do you actually propose here?
To clarify, the kernel doesn't (well, it gets complicated with things like NFSv4 but let's just ignore that since it doesn't really make or break my point) know anything about users or groups. It _only_ has the ability to manage some integers on a per-process basis and tie those into integers attached to files.
Assuming for now that we want to keep this like that, if you want to tie names to those numbers, you have to have some kind of database. If not by reading a config file, or by running some random code, or by some virtual file system (unless I misunderstood ?), what other options do you have?
Unix sockets have the same issue. There are abstract namespace sockets, but these don't exactly help solve the core problem, since now changing the network namespace can get you in the same trouble. This also covers any other kind of socket.
Even if the kernel did have the capacity to maintain this information, something would need to load it or back it, and that something could fall afoul of similar bugs.
> root should be restricted to executing/loading only a whitelist of executables/shared objects
It should already be possible to achieve this with IMA I believe?
> But then again, you'll need a allow_for_root(1) utility to maintain this whitelist, and people absolutely will call it in their setup scripts in all kinds of dubious manner.
You'd just keep the signing keys off the machine and either sign things off the host or sign them with presence detection and an HSM.
> What alternative solution do you actually propose here?
I don't, I am just saying that if you do things like e.g. user/group name resolution outside of the kernel, then they will be done in the userspace (duh) with all of the implications (crossing the trust boundaries, and philosophical discussion on what "the system [database/service/X]" even is, etc) that come with it. Doing it in the kernel has other implications, like how Windows does its SID lookups.
> what other options do you have?
Depends on whether or not you want to have the user namespaces, and how you want things across the namespace boundaries to interact. If you want to have /etc/passwd (or a more complex apparatus) of the core system to always be in effect, with no ability to override it with e.g. chroot(2) — then you can do it, with some help from the kernel side but that's both the silly idea in itself, and the kernel folks would never agree to add a do_rpc_with_global_secured_system_service(2) to the kernel anyway.
> Even if the kernel did have the capacity to maintain this information, something would need to load it or back it
During the system startup, a daemon is launched that registers itself as a "global, secured system service" providing the "resolve user/group names" functionality with the kernel. Now everyone can interact with it with the do_rpc_with_global_secured_system_service() syscall (the kernel passes the request to this specific process and routes the replies back), and there is no way to override this interaction; this service is a global singleton. I could spend pages on writing why this is a stupid idea, and I'm sure you know them as well — but it's doable, just not in the spirit of Linux at all.
P.S. A tangent, but I am always amused when people explain that execve(2) can't do PATH lookup for its first argument because the kernel doesn't have access to the process's environment variables. Of course it has, it's the third parameter! Linux just doesn't do any name resolution in the kernel, period, there is glibc for that.
I mean, regardless of how you set this up, at some point you're going to want to namespace things. The core problem here is that chrooting creates an imperfect namespace boundary (it's not really even intended as that).
Maybe we're agreeing, I'm not quite sure. But rather than having a separate concept of mapping IDs to names, you really want a unified concept of both, so that when you namespace it, you can't namespace half of it by accident.
Moreover, you want to ideally make it impossible to only namespace it and not anything which is affected by it. e.g. the filesystem where permissions are governed by user and group IDs.
The way this is currently done is with UID/GID mapping, which unless it is a 1:1 mapping to the current user, has to be done with privileges. But this restriction is a hint that the abstraction is bad.
Really what you'd want is to have the ability to also include the concept of "file owner" in the umbrella of "user namespace", so that you can have a setup where files can have arbitrary attributes settable by a user to specify that they're owned by "root" inside the namespace but by <you> outside it.
I'd say the problem is a fundamental design issue at multiple levels of the stack, exacerbated by the need to maintain backwards compatibility.
Plan9 solves this entire problem (albeit with its own trade-offs) by unifying all abstractions in the filesystem (but nothing, of course, stops you from unifying things via some IPC/RPC/whatever protocol, the filesystem in Plan 9 is just a mount of a 9P fileserver).
You literally can't get into a situation like the one described here.
> async/await introduced entirely new categories of bugs that threads don’t have. O’Connor documents a class of async Rust deadlocks he calls “futurelocks”
I didn't coin that term, the Oxide folks did: https://rfd.shared.oxide.computer/rfd/0609. I want to emphasize that I don't think futurelocks represent a "fundamental mistake" or anything like that in Rust's async model. Instead, I believe they can be fixed reliably with a combination of some new lint rules and some replacement helper functions and macros that play nicely with the lints. The one part of async Rust that I think will need somewhat painful changes is Stream/AsyncIterator (https://github.com/rust-lang/rust/issues/79024#issuecomment-...), but those aren't yet stable, so hopefully some transition pain is tolerable there.
> The pattern scales poorly beyond small examples. In a real application with dozens of async calls, determining which operations are independent and can be parallelized requires the programmer to manually analyze dependencies and restructure the code accordingly.
I think Rust is in an interesting position here. On the one hand, running things concurrently absolutely does take deliberate effort on the programmer's part. (As it does with threads or goroutines.) But on the other hand, we have the borrow checker and its strict aliasing rules watching our back when we do choose to put in that effort. Writing any sort of Rust program comes with cognitive overhead to keep the aliasing and mutation details straight. But since we pay that overhead either way (for better or worse), the additional complexity of making things parallel or concurrent is actually a lot less.
> At the function level, adding a single i/o call to a previously synchronous function changes its signature, its return type, and its calling convention. Every caller must be updated, and their callers must be updated.
This is part of the original function coloring story in JS ("you can only call a red function from within another red function") that I think gets over-applied to other languages. You absolutely can call an async function from a regular function in Rust, by spinning up a runtime and using `block_on` or similar. You can also call a regular function from an async function by using `spawn_blocking` or similar. It's not wonderful style to cross back and forth across that boundary all the time, and it's not free either. (Tokio can also get mad at you if you nest runtimes within one another on the same thread.) But in general you don't need to refactor your whole codebase the first time you run into a mismatch here.
I question the choice of the phrase "to the Moon". I get it, it's technically true, but ~100% of normal people hear that and assume it means boots on the ground. Every single time it gets mentioned, it's immediately followed by a clarification that disappoints the audience. This isn't the sort of marketing choice that a self-confident program makes.
Even the next one isn't landing on the moon. It is still a test flight. Good that they are testing things obviously, but it is hard to get excited about testing...
the apollo program had 5 crewed flights, two of which went to the moon without landing.
after 50 years of not going there, it is exciting that something is happening.
i don't actually care about landing on the moon. i care about what is being tested and learned from these flights, whether they do land on the moon or not.
the moonlanding better be a test for base building for example and not just collecting samples. we can do that with robots already.
Dont forget 4/1 Elon tweeted he was putting a doge coin on the moon. When that does happen in 2027 or 2028 its going to actually explode in price for the hype
I wouldn't read too much into pre-1.0 versions. Folks take SemVer pretty seriously, and that makes some folks reluctant to declare v1.0 even when a crate has been in use and "mostly stable" for years. There can also be compatibility issues with a 1.0 bump if a crate's types are common in public APIs, e.g. the `libc` crate. I'm a big fan of the curated list of crates at blessed.rs, or honestly just looking at download numbers. (Obviously not a perfect system.)
IME, a 1.0 version is usually when a project starts taking backwards compatibility seriously. A pre-1.0 library may be plenty stable enough in terms of bugs, but being pre-1.0 means they’re likely going to change their mind on the API contract at some point.
That is the major problem for me… I don’t actually mind that much if a library has bugs… those can always be fixed. But when a library does a total 180 on the API contract, or removes things, or just changes their mind on what the abstraction should be (often it feels like they’re just feng shui’ing things), that’s a major problem. And it’s what people mean when they say “immaturity”: if I build on top of this, is it all going to break horribly at some point in the future when the author changes their mind?
People often say “just don’t update then”, but that’s (a) a sure fire way to accumulate tech debt in your codebase (because some day may come when you must update), and (b) you’re no longer getting what could be critical updates to the library.
> The percent propellant has huge implications on the ease of fabrication and robustness in achieving the engineering design (and cost). If a vehicle is less than 10% propellant, it is typically made from billets of steel. Changes to its structure are readily done without engineering analysis; you simple weld on another hunk of steel to reinforce the frame according to what your intuition might say. I can easily overload my ¾ ton pickup by a factor of two. It might be moving slowly but it is hauling the load.
> Once the vehicles become airborne, the engineering becomes more serious. Light weight structures made of aluminum, magnesium, titanium, epoxy-graphite composites are the norm. To alter the structure takes significant engineering; one does not simply weld on another chunk to your airframe if you want to live (or drill a hole through some convenient section). These vehicles cannot operate far from their designed limits; overloading an airplane by a factor of two results in disaster. Even though these vehicles are 30 to 40% propellant (60 to 70% structure and payload), there is room for engineering to comfortably operate thus there is a robust, safe, and cost effective aviation industry.
> Rockets at 85% propellant and 15% structure and payload are on the extreme edge of our engineering ability to even fabricate (and to pay for!). They require constant engineering to keep flying. The seemingly smallest modifications require monumental analysis and testing of prototypes in vacuum chambers, shaker tables, and sometimes test launches in desert regions. Typical margins in structural design are 40%. Often, testing and analysis are only taken to 10% above the designed limit. For a Space Shuttle launch, 3 g’s are the designed limit of acceleration. The stack has been certified (meaning tested to the point that we know it will keep working) to 3.3 g’s. This operation has a 10% envelope for error. Imagine driving your car at 60 mph and then drifting to 66 mph, only to have your car self-destruct. This is life riding rockets, compliments of the rocket equation.