stevepeg

> But The Times found that the combination of six-day workweeks and round-the-clock schedules has caused controllers to develop physical and mental health problems. Many avoid seeking professional help because doing so might jeopardize the medical clearances they need to work.

This is happening frequently to pilots and cabin crew as well, all over the world. Regulators have allowed a lot of flex in rostering in recent years, maybe a bit too much.

That’s what it already does though. We get a total fuel figure in the flight deck (FOB) and a figure for how much the engines have used (FU - measures flow in the pylons). Add the two together and if the resulting number isn’t what the flight started with then there’s a leak.

The challenge is knowing where the leak is.

That’s good lateral thinking :)

Given that the aircraft can be landed over max landing weight (needs a maintenance inspection) and is still controllable with total imbalance I’d say that balancing just wasn’t as pressing of a concern.

Also, with that much damage you never really know where else it could be leaking. Leaking fuel into critical spaces of the aircraft could be bad so turning on the fuel crossfeed might add extra issues.

It’s a good idea, some aircraft have quite complex fuel systems though so it would have to account for fuel moving between tanks.

E.g. the A330 has an inner tank in each wing (which itself can be split into two compartments if damaged), an outer tank in each wing and fuel in the horizontal stabiliser which is used for CG control in the cruise. All of that plumbing can leak too. You’d be adding significant weight and complexity implementing leak detection across all that.

Regardless of all of this, the aircraft is still fully controllable even with a total asymmetry (one side empty the other full) so balancing the tanks isn’t a massive priority.

A320/330/340/350 driver here (can't get away from Airbus apparently).

Nope, there is no system to confirm a leak apart from a camera around the tail if you're lucky enough to have one, my previous airline had a flight where an engine leak was detected this way. Think about it, how would you design such a system? So this falls on the crew.

The procedure to determine if you have a leak is pretty much the same across types: add the fuel on board (FOB) to the fuel used (FU) and make sure that the number you get is the same as what you started the flight with. If it's less by some margin then you probably have a leak. You can confirm further by looking at tank quantities (but they take time to reduce depending on the size of the hole). If you get an engine or pylon leak then you might also see increased fuel flow on that engine. If the leak is elsewhere in the system then you might notice a smell. If you can't work it out then the procedure (at least on Airbus types) usually involves turning an engine off to see if the leak stops (yep, really).

As for the ECAM "open fuel transfer valves" message, I don't know for sure on the 380 but all the other Airbus types I've flown have something like:

.IF NO FUEL LEAK

FUEL IMBALANCE....MONITOR

So it doesn't really instruct you to open the transfer valves but leads you into the fuel imbalance procedure if you think you need it. The very first line of the fuel imbalance procedure says something like "Don't apply this procedure if fuel leak is suspected".

Geez, it's a programming language not a spouse! You can just, you know, use another one if it doesn't work out.

Airline pilot here: passing another aircraft opposite direction on the same lateral track with only 1000ft of vertical separation is about as normal as it gets. I’d say that it has occurred on almost all of the flights in my career so far. In certain areas of poor ATC coverage we sometimes use SLOP (strategic lateral offset procedures) to add a bit more margin for a height error.

Edit: fun fact, you can actually hear the passing jet from the flight deck just after it has passed, a slight whoosh can be heard. Depending on conditions you can also feel a brief bump when crossing their wake (since the wake descends).

You should try having to read several hundred of them before a long-haul duty! Good luck trying to find the runway closure notam buried among the 400 reports of a crane within curvature-of-the-earth viewing range of an airport, or the 300 reports of birds that were once seen near, or somewhere near the runway.

Too hilarious not to share: https://fixingnotams.org/wp-content/uploads/2019/11/Field-Gu...

It won't auto-level the wings for you in an airbus, however unless you're in an unusual configuration in alternate or direct laws (requiring a significant series of failures), the bank angle is limited by the aircraft anyway (whether you're on AP or not). For reference, in my 10 years of operating Airbus aircraft I have seen alternate law just once, we train it in the sim regularly but it's not a common occurrence.

Pressing ALT is taught as the correct thing when you're not completely sure what to do but for a fully unusual attitude (e.g. really nose-high or nose-low, or an acute bank angle) then currently the procedure is to handle it manually. To be honest, to get a large aircraft into that situation requires a pilot to screw it up badly in the first place, the AP won't get you there (well it might but hasn't happened yet).

A couple of years ago most airlines started training a more verbose method of recovery (disengage, push/pull, roll, thrust, stabilise - is the mantra) in response to studies conducted by Boeing and Airbus. Before airlines I used to compete in and teach advanced aerobatics so I'm not completely happy with that procedure (e.g. why push/pull first if you have huge bank on, only going to make things worse) but it's what the industry is pushing right now.

Overall though I think the bigger issues with pilot error are not things like unusual attitudes, yes they do happen from time to time but far more incidents occur from unstable approaches and silly inputs during takeoff. Hence why most changes in regulation right now are in those areas.

Good question, I ask myself the same thing every time I come to this site :)

I'm also a programmer in my spare time, I started coding long before I was a pilot. Sometimes I do consulting work and I also have a startup. Flying jobs generally give enough spare time to do these things in a limited way.

Human airline pilot here, a lot of comments about the reliability of automation for takeoff, landing and some emergency scenarios but the proposed regulation is a little more specific. They're trying to allow one pilot at the controls in the cruise phase of flight, this will allow airlines to alter [read: reduce] the pay for the resting second pilot.

What I think the regulators and manufacturers are missing has less to do with the what-if scenario of an incapacitated pilot and more to do with what happens when pilots get bored. Sitting in a cockpit for my 7+hr shift at night over the Pacific is made safer by the fact that I can have a conversation with the other pilot to keep my mind somewhat alert. Take that away and the mind gets dull, complacent and prone to error.

I'm all for more automation as long as there's a measurable benefit to safety. If getting rid of all human pilots leads to a reduction in lives lost per unit of time then it's worth it. Sure there will be major accidents that a human could have prevented, but there will be accidents prevented by the machine too. The crossover point matters.

I think the GP comment you're replying to nailed the reason why:

> I take a contrarian opinion on this, the price of a flight in the US outside of major hubs is egregious. Especially during peak times or holidays.

Highly-engineered tubes that fly 10km above the ground at very high speeds, have absolutely amazing reliability and long-term safety, and can navigate all over the world are, unsurprisingly, very expensive. But people still want to hop in one and pay less than a train ticket.

Human airline pilot here, I'm not sure where you're getting this from:

> Many private planes with modern avionics now have an auto-level button on the AP that very reliably recovers from a dive or other unusual attitudes. Airlines typically don't and it's clear that the simple (and very easy to program) button could have saved many lives.

Every modern jet since the early 90s has this. In every family of Airbus you can press the 'ALT' push-button or pull on the V/S knob. Both will level off the aircraft immediately (with slightly different follow-on characteristics).

Edit: to add more context, this works in unusual situations like dives and high-nose attitudes as well. The only difference is the inertia of a modern jet means the leveling off takes a bit longer.

No worries, here's my opinion (lots of lang-war stuff, so note "opinion"):

I would say that it depends on your comfort with async code in Rust since much of the web ecosystem is built that way.

If you're comfortable writing async Rust then go for it, the guard rails are there. People complain (especially here) but it's fine. Our entire web backend and our scheduler applications are overwhelmingly async. We have not hit the weird stuff you read about with lifetimes even once.

However, it does expect you to know how it works. You need to understand what the async runtime does otherwise it will add friction. If you're not yet proficient with this part of Rust then you will benefit from having an "expert" on the team as you say, since they can guide the rest.

Our team were all experienced in Rust already when hired so we didn't hit this. If you're uncomfortable then simply choose the language your team already knows. That's the pragmatic choice.

No disagreement here. My post is a praise of Rust, not "everyone must use Rust!". These languages and tools are also great!

(edit) added 'tools'

I would say that curiosity about languages in general is one item that you should look for in candidates. Not the only one of course but curious people do tend to learn and adapt well.

For an analogy, I wouldn't hire a pilot that isn't interested in other planes than what's on their license. What if I want to operate some new models?

Unless I'm looking for someone for a truly specialised role, I would avoid people that stick to only one thing for their entire careers.

Author here: lots of usual language-war type comments here. Just thought I'd add my own little bit of water (hopefully).

In my post notice that aside from my personal background with programming I didn't go into detail about memory safety, which seems to be what many are debating. Frankly, it's not even one of my top reasons for praising the language. If I had to pick three these are what I'd choose:

1. Strong features for describing real-world issues in software. Here I'm talking about things like tagged unions (enums). They let you describe so much very cleanly. Use a match expression on it and you can be sure you've handled it pretty well. These lead into the stdlib's Result and Option types which extend what I said further.

2. Excellent performance without any fancy language stuff like annotating lifetimes. Using the Iterator trait you can chain up a really nice operation FP-style and get ridiculous performance. It takes fewer lines than idiomatic Python.

3. Excellent tooling. Cargo is easily the best package manager I've used (yet, someone show me better!). When doing async work the tracing crate is great, it automatically handles all the entry and exit points of the state machine that gets generated. You can also use tools like tokio-console on it, or export via opentelemetry.

Author here: didn't expect this to get on the front page, some kind of life goal achieved I guess.

Here's a link to our Show HN from a week ago: https://news.ycombinator.com/item?id=31630604

It's good to hear that media literacy is being taught like that in high schools. Education on the topic is the best sure-fire solution in the long term.

We really like AllSides but where I think our product differs is that we say that sides don't really matter if you get to see everything reported on the story from all publishers.

If you go to an article from the right in our app, we'll inject content from the left (and everyone else) in-context when you tap on a highlighted piece of text. And vice-versa, if you go to an article from the left, you'll also see reporting from the right (and everyone else). You don't have to go looking for the other articles.

A clever news reader will go out and read several articles from different viewpoints on a particular story, but the idea here is that it shouldn't be a manual process when technology can present it to you conveniently.

Cool idea regarding duplicate detection, but it would have to be from a neutral perspective and not point at the left/right as that will only widen divides further. Maybe a list showing all the details that appeared in a story ordered by the number of articles that covered each.

It's almost ready! It works together with a browser extension which adds the highlights and extra information to articles so we're in the process of tweaking that interaction.

We decided to release the mobile app first since almost 70% of people reading news online do it on their phones.

Skepticism welcomed, it's a crazy space so the more of that the better!

We differ by giving the reader the tools to form a better opinion for themselves rather than telling them what's wrong and making ourselves some oracle or source of truth. We think that's where so many of these attempts go wrong.

Our highlights show related details that were found in other articles, but were not covered in the article being read. We show all of the sources of these so the user never has to take our word for it, they can go there and see. This part uses an ML model trained on the MNLI and SNLI datasets. I'm happy to share all the details of the graph and training method privately if you send us an email.

We do also highlight some passages of text for being potentially misleading but this uses no ML whatsoever. We suggest missing sources of data ("according to our sources"), missing reference ("a recent study suggests" - with no reference or link), and scare quotes. We make sure that the item is verifiable by the text the user is actually looking at. We do not attempt to cover subjective items like hyperbole, slippery slope fallacy, etc. Each of these items is presented as a suggestion intended to make the reader pause for a second.

Your last question is hard to answer since I'm not sure what assurances anyone could give apart from "we promise", I'll do my best though. We're a startup of 6 people who all care deeply about the quality of news. If we fail to cover an article you should call us out on it and find out why then share that with everyone.

Right now there are a number of technical reasons why that might happen such as the insane mess of HTML some publishers use, it can be hard to parse.

Hi everyone, I’m Steve, one of the team working on The Daily Edit.

We’ve built a news aggregator which shows you every detail that has been reported on a story regardless of which article, or which publisher, you choose to visit. Readers can choose whichever angle they like and they’ll still see everything that’s been reported, from all sides. They don’t have to visit several articles to do this, it all happens in one place.

We’ve put some examples of what it all does on Twitter: @dailyeditapp. If you find more great examples please share them with us!

How did we get here?

Myself, Craig and Mich work(ed) as pilots for an airline out of Hong Kong. Over our careers we’ve seen that all of the current issues with the news happen everywhere around the world and, like everyone, we’re tired of it. During COVID our flying rosters were reduced significantly so we had a bit more free time than usual. We used this time to have a go at building something that can help fix this mess.

Initially we made a tool that highlights questionable pieces of text like logical fallacies and such. We tried this out with some friends and kept getting the same feedback. Nobody really cared that much about the text, they all said the real manipulation happens through omission.

For a while we discussed how to do this without falling into the fact-checker trap. Fact-checkers are great but every time they show an error a new group emerges from the mist to spend the rest of their lives arguing against it.

Eventually we realised that if we could aggregate deeper than just the articles, go right into the text itself and pull out details, then we could make this work. We got a small proof-of-concept up and running, put together a team and got to work building the real thing.

We hope you like it! It’s early and there will be bugs, but we’ll squash those! We have a lot more stuff coming over the next few months including a web app and browser extension. If there are particular things you think would be awesome to have, we’d love to hear it!.

If you have any feedback at all feel free to email us at feedback !at! dailyedit.com

Send me an email at jobs [at] dailyedit [dotcom]

We're a Rust shop doing something interesting with NLP and web.