> Even if fossil LNG is used, it releases less CO2 per unit energy.
However released methane has a significantly worse greenhouse effect than CO2 (80x over 20 years, 28 over 100, 8 over 500 — this decreases because methane has an atmospheric lifetime of 12 years and decays to CO2). So leakage in the LNG chain is a massive problem.
Yes, it sounds like the repetition of a mangled version of the SR71 stories. Burning 45 tonnes of fuel on the runway would be completely insane.
Checking various links on taxiing burn yields about 2 tonnes which is a lot more realistic and reasonable (a previous HN comment indicates the 767 burns about a tonne taxiing: https://news.ycombinator.com/item?id=24283386 concorde burning twice that sounds fair)
This seems incredibly inefficient. Is there a future for hybrid aircraft, which would feature both traditional turbofans and large batteries for energy storage?
Batteries would eliminate the need for an APU and power the aircraft during taxi, allowing the engines to be started just before actual takeoff, and shut down immediately after landing.
Either the batteries could power wheel motors directly during taxi, or the aircraft could mix turbofans with e-fans (which could also allow energy recovery during descent and help power the aircraft during cruise, reducing fuel consumption further).
Very inefficient but good for safety: if an engine is failing, you hopefully might discover that while taxiing rather than when you are in the death zone 25 meters up in the air.
Not an expert, but intuition suggests this probably isn’t true.
If an engine is going to fail spontaneously it’s almost certainly going to happen at high thrust, not while at idle or very low thrust values during taxi.
> This seems incredibly inefficient. Is there a future for hybrid aircraft, which would feature both traditional turbofans and large batteries for energy storage?
I would assume the extra weight would make it not really worth the added cost and complexity.
Honestly it sounds like the "right" way to do it would be electric ground vehicles pulling the planes into position, as with tugboats in water. Plane never need carry batteries into the sky and saves a literal ton of fuel.
IIRC towing to and from the runway has two major issues:
- standard towing tractors are really slow when towing, nowhere near taxiing speed, so you need a fleet of heavier duty "fast tow", possibly dedicated (depending on price)
- more traffic around the runway, which creates more airport complexity
Taxibot does exist tho, and is certified, and used in a few airports. Though I think it's only hybrid not electric.
Bigger issue is that the engines need to be idled for a while anyway to get up to proper temps, etc. you don’t want to start the engines and jam them into full takeoff thrust 5 seconds later.
True, the engines need to be warmed up and the hydraulics need to be pressurised, but given e.g. airbus recommends single engine taxi without APU (SETWA) warming up the engines probably doesn't take that long in the grand scheme of things. Definitely not the 15~25mn of taxi. From the sources I can find, "normal" warmup takes 2~5mn depending how long ago the engine was shut down, unless outside temps are exceptionally low, and you can do that while reaching the end of your taxi.
The software in modern engines wouldn’t let you do that anyway. The engine startup process can be quite long - several minutes in a 737 MAX - while the engine’s ECU brings things to proper temperatures etc.
But with e-taxi, the startup cycle could be performed while taxiing, potentially saving airlines time on pushback as well as fuel/maintenance cost savings.
Electric taxiing (on APU) has been in development for over a decade, but it's mostly intended for single aisles (the shorter the flight the more the taxi overhead), and the relatively low fuel prices has led to these projects mostly dying off: L3 shuttered their effort in 2013, Honeywell and Safran's EGTS joint venture was dissolved in 2016, and wheeltug... apparently still lives (with no support from either boeing or airbus), though it was initially supposed to enter service in 2018.
Airlines would also significantly reduce engine operating hours, reducing engine wear and thus maintenance costs. I’ve been on flights out of Heathrow that seem to spend almost as much time taxiing as they do in the air (due to weather or ATC delays or whatever), so for short-haul operations this seems really significant.
Local air quality is also a concern for airports: the air in the neighbourhoods around Heathrow often stinks of jet exhaust, sometimes you can smell it from miles away. Presumably, much of those emissions come from taxiing aircraft.
I think they've looked at that kind of thing but not found if practical so far. One innovation has been airbus jets taxiing with just one engine which cuts fuel use a lot as it mostly goes to just spinning the engines.
The historical P-strings are just a pointer, with the length at the head of the buffer. Hence length-prefixed strings, and their limitation to 255 bytes (only one byte was reserved for the length, you can still see this in the most base string of freepascal: https://www.freepascal.org/docs-html/ref/refsu9.html).
{length, pointer}
or
{length, capacity, pointer}
is struct / record strings, and what pretty much every modern language does (possibly with optimisations e.g. SSO23 is basically a p-string when inline, but can move out of line into a full record string).
Postgres does the same thing, however AFAIK postgres does not use a fixed-size string which happens to have inline string data: text is always variable, and stored inline up to 127 bytes (after compression).
These are different because the inline segment is fixed-size, and always exposes a 4 bytes prefix inline even when the buffer is stored out of line.
> The transient string is particularly brilliant. Ive worked with some low level networking code in c, and being able to create a string containing the "payload" by pointing directly to an offset in the raw circular packet buffer is very clean. (the alternative is juggling offsets, or doing excessive memcpy)
It's not anything special? That's just `string_view` (C++17). Java also used to do that as an optimisation (but because it was implicit and not trivial to notice it caused difficult do diagnose memory leaks, IIRC it was introduced in Java 1.4 and removed in 1.7).
I don't believe I stated or even hinted otherwise?
> This format can handle "string views" with the same logic as "normal strings" without relying on interfaces or inheritance overhead.
"owned" and "borrowed" strings have different lifecycles and if you can't differentiate them easily it's very easy to misuse a borrowed string into an UAF (or as Java did into a memory leak). That is bad.
And because callees usually know whether they need a borrowed string, and they're essentially free, the utility of making them implicit is close to nil.
Which is why people have generally stopped doing that, and kept borrowed strings as a separate type. Without relying on interfaces or inheritance.
> it's clever.
The wrong type thereof. It's clever in the same way java 1.4's shared substring were clever, with worse consequences.
You're getting into pedantics about specific languages and their implementation. I never made a statement about C++ or java. I work in primarily in c99 myself.
> the utility of making them implicit is close to nil.
> Without relying on interfaces or inheritance.
Implement a function that takes three strings without 3! permutations of that function either explicitly or implicitly created.
C++ strings are not "optimized so". C++ strings (generally) do SSO (up to 23 bytes depending on implementation), these also do SSO but only 8 bytes (to a total of 12), the first 4 bytes are always stored inline for fast lookup even when the rest of the string is on the heap (in which case they're duplicated), and the strings are limited to 4GB (32 bits length). IIRC they also have a bunch of other limitations (e.g. they're not really extensible, by design).
Which is why they're "everywhere"... in databases, especially columnar storage.
Yes. Sorry. That was not 100% correct. Still, your words (my emphasis)
>C++ strings are not "optimized so". C++ strings (generally) do SSO (up to 23 bytes depending on implementation), these also do SSO but only 8 bytes (to a total of 12)
That is what I meant. I would (like you did) call it SSO still.
reply