Fundamentally, if the nozzle temperatures can't possibly withstand what they are extruding without eroding, we can either:
- balance an exothermic reaction (self-propagating high-temperature synthesis) to occur just after leaving the nozzle
- externally apply the heat with laser or plasma arc etc
The limit of externally applying heating is when the heat flux has to be so high that some material vaporizes and pops. An exothermic reaction within the material overcomes this limitation.
The other alternative is like current state of the art 3d printing ceramics - you either replace some high percentage of the filament with clay and fire it as a post processing step and it burns off the plastic, or print a clay/water slurry directly and fire it after drying.
But I don't think we'd end up with the basalt being very filamentous.
If the binder that gives you something printable at low temperature doesn't integrate into the final result through chemical reaction, you are almost assuredly going to get a high porosity mess where the binder had to vaporize out.
If instead the binder and precursor can melt, react, and expand into a solid that precipitates out because of a super high melting point, the expansion will ensure that you get a fully dense part that can be machined back down.
Yep. Even just sharing code with any license is valuable. Much I have learned from reading an implementation of code I have never run even once. Solutions to tough problems are an under-recognized form of generosity.
This is a point where the lack of alignment between the free beer crowd and those they depend on is all too clear. The free beer enthusiast cannot imagine benefiting from anything other than a finished work. They are concerned about the efficient use of scarce development bandwidth without consciousness of why it is scarce or that it is not theirs to direct. They view solutions without a hot package cache as a form of waste, oblivious to how such solutions expedite the development of all other tools they depend on, commercial or free.
It's rather as if a passive inbox with no notifications and where deleting implies lower prioritization of similar messages would be quite handy. Everything in that is Email except email has no concept of "hot".
Emacs took a wrong fork in its own metaphor. At length, being able to take code and libraries between production and the editor would be a game changer. While Elisp has design features that make sense, in the tradeoffs, I think it lost to every other lisp with a general purpose programming ecosystem.
I have a hope for the Common Lisp based Lem. All we need is to coordinate enough signal for potential users to feel it's the right time for their actions. Go star Lem https://github.com/lem-project/lem
I feel the same way about org mode. Nice. Can I use it on a team? Get real. I'd like more embedded data functionality in markdown. It's not XML, and that's good. Org is just weird. AFAIK it's still trying to figure out inline data embedding, so the embedding isn't even that strong. Doing something like exporting with a CSS class around a specific word probably uses some awkward literal syntax instead.
There are consequences to the monastic culture around Emacs. It's really good at holding itself in place. If you don't buy that tradeoff, you need to keep shopping.
Unrelated to the article, a lot of my millennials could see web and then mobile coming, focused on web & mobile, and as a result just weren't really participating in C and C++ development. We used terminal applications leftover from peak GNU.
When Rust came along and presented a career opportunity, terminal apps was a great way to get into it and filled a gap in a lot of people's skill sets. Even when building GUI apps in Rust, your first entry point is a CLI usually.
We took our UX thinking from web & mobile and remixed it with Rust and new ideas came out. Turns out "If it aint broke don't fix it" for two decades can build up a lot of evolutionary pressure.
The rotation already exacerbates the flow into that engine. Change in flow geometry gets more smoke in its way when it's already eating turbulent air.
We don't know if it just had a disruption or a full-blown stall, but give the way it made it to takeoff speed and then just gave out, stall seems likely.
There are two fire detection loops for each engine.[1] Even if both fails (because they get shredded as you say it) the system will report an engine fire if the two loops fail within 5s of each other. (Or FIRE DET (1,2,3,or APU) FAIL, if they got shredded with more than 5s in between without any fire indications in between.)
The detection logic is implemented directly below the cockpit. So that unlikely to have shredded at the same time. But even if the detection logic would have died that would also result in a fire alarm. (as we learned from the March 31, 2002 Charlotte incident.)[2]
I don't know what the MD-11 would have had, again I didn't work on it. But the systems used for other aircraft would have reported an alarm based on what I saw in the video, at least they were designed to do that. The LRU receiving the sensor inputs wouldn't typically be in the wing and would be able to continue reporting the alarm condition even if the sensors fail. In fact, the lack of current from the sensor (for the systems I worked on) would have been enough to trigger the alarm if the sensor were completely eliminated.
There is a dead zone between rejection and successful take-off speeds. We see it hit too often.
I think pilot training is playing a factor. A normal rotation kills too much energy. One engine can climb when you have some airspeed and get clean, but if you lose too much energy on rotation, the inefficiency of the AoA for the rest of the short flight means that engine can no longer buy you any up. I've seen too many single-engine planes going down while trying to pitch up the whole way down.
So, less aggressive single-engine rotations and energy absorbers at the ends of runways that can't get longer. This seems like the kind of thing where we do it because it removes a significant cause of people dying.
Another crash video shows the aircraft clearly descending before colliding with anything. It manages to go up a bit, so it's fast enough to get airborne. The normal looking rotation kills too much energy. The plane is then too inefficient to maintain speed. AoA goes up while energy goes down. Power available goes negative and then it's over.
Rotation does increase drag, but you need to rotate in order to achieve the necessary angle of attack. The only way to reduce the rotation angle is by going faster than the normal rotation speed for the given weight and airfield density altitude, but doing so is out of the question in this scenario.
There might be other kinds of damage where the quicker altitude gain of a normal rotation is crucial for survival.
I'm skeptical whether pilots can realistically make this kind of decision, given that they have no more than a few seconds to make it, and in cases such as this based on very incomplete information about the state of their aircraft.
Increased thrust requirements for airliners that force planes to hit an increased v1 (or whatever it's called) sooner on the runway to allow for more time to reject takeoff.
> It manages to go up a bit, so it's fast enough to get airborne. The normal looking rotation kills too much energy.
Yes, it did get airborne for a few seconds but from the video below, it looks like the left wing was damaged by the fire and could not provide enough lift, then the right wing rolled the plane to the left causing the crash.
> looks like the left wing was damaged by the fire
The wings and aerodynamics don't really care if air or air with combustion are flowing around them.
Roll is a consequence of the loss of control due to low speed and the yaw of the good engines. Speed up, rudder works, plane might maintain positive climb.
For skin, a few seconds might be significant. For the spars, not nearly enough time to matter. It's also not at cruise speed slamming into a downdraft or anything. This is about a 1G loading. Negligible for a while. While the fire looks cool, there's a lot of free stream mixing in and the temps won't really get that high beyond the cowling.
More likely is the hydraulics on that side burst, leading to a loss of pressure keeping the control surfaces deployed. If that lead to the leading-edge slats retracting (like they did in AA 191) you'd get a massive loss of lift on that side. The structural parts of the wing didn't have time to melt, but the fire certainly could damage all the internal control materials.
Right after the nano maintainer got bullied out by the FSF, I noticed two bindings got their defaults changed. They never change. I almost feel like it was graffiti, a flex against the old maintainer, a retribution for not doing whatever the FSF wanted.
Since forever, GNU readline programs and nano had identical bindings. I'm fast moving around the CLI because I'm fast at nano. Emacs has the same defaults. What sane organization only abandons their own defaults and prioritizes that work after pushing the existing maintainer out (or irritating them enough to accomplish this)?
Seems GP got somewhere confused as well. From `man nano`:
Since version 8.0, to be newcomer friendly, ^F starts a forward
search, ^B starts a backward search, M-F searches the next occurrence
forward, and M-B searches the next occurrence backward. If you want
those keystrokes to do what they did before version 8.0, add the fol‐
lowing lines at the end of your nanorc file:
bind ^F forward main
bind ^B back main
bind M-F formatter main
bind M-B linter main
M-F/B have not defaulted to nextword/prevword, or at least haven't within the last 10y since have those binds in the earliest version of nanorc in my .config git repo.
- balance an exothermic reaction (self-propagating high-temperature synthesis) to occur just after leaving the nozzle
- externally apply the heat with laser or plasma arc etc
The limit of externally applying heating is when the heat flux has to be so high that some material vaporizes and pops. An exothermic reaction within the material overcomes this limitation.