The problem is that the data has to go somewhere. If you don't have the compute power locally, you have to send it to a server you control. At a point, this starts to break down because your attention to detail isn't sufficient to protect other operators. I think there are some happier mediums, but I wouldn't be as strident as saying there is no risk even if this is stored locally.
I thought I was strange for feeling this when I brought my US-raised kids back to Northern Ireland this spring. Some would have been visible from my childhood home had they been built earlier. It made me think that maybe these people can get something right for the future.
If they have to touch and go, how long would it take until they get the plane around for another approach? In fact, you might not get as far as that touch and go and have to go around. You need some margin for all of these eventualities. The likelihood is low that these happen, but they have to be accounted for.
Sure, but the flight was a lot longer than planed. How much extra do we need. They declared an emergency, and thus put themselves at the front of the line. They had 6 more minutes to do that touch and go around if that happened, and since they were already in a low fuel emergency they get priority and so there is enough time to do that if they needed. (edit - as others have noted, 6 minutes with high error bars, so they could have only had 30 seconds left which is not enough)
They landed safely, that is what is important. There is great cost to have extra fuel on board, you need enough, but it doesn't look to me like more was needed. Unless an investigation determines that this emergency would happen often on that route - even then it seems like they should have been told to land in France or someplace long before they got to their intended destination to discover landing was impossible.
Correct, article says they landed with 220kg which is around 6 minutes of average fuel burn over an entire flight - bit less at cruise, a hell of a lot more at takeoff/climb.
So I don't think 220kg is enough to do a go-around in a 737 (well, a go-around would've been initiated with a bit more than 220kg in the tank - they burned some taxing to the gate - but you get my point.) I've read around 2,300kg for takeoff and climb on a normal flight in a 737-8. A go-around is going to use close to that, it's a full power takeoff but a much shorter climb phase up to whatever procedure is set for the airport and then what ATC tells you.
I just flew 172s but even with those little things we were told, your reserve is never to be used.
These people came very, very close to a disaster. Fortunately they had as much luck left as they did fuel.
Isn’t a 737-8 the max 8 variant? It uses newer dual CFM LEAP-1B engines. How does it compare? I can’t really find the data. The spec you’re referring to is for the older 737-800.
It suggests an overall savings of ~14% over the 737-800 but doesn’t look at specific takeoff/climb comparison.
I wasn’t posting the LLM output as a source of truth. I was just using it to question the uncited value. And I still really don’t know the answer. If you’ve got another data source I’d love to get it.
Why do people keep insisting on pasting LLM output to HN when every time it happens, it gets downvoted to oblivion? The community clearly doesn't want it. If we wanted to know a computer program's opinion about something, we could ask it ourselves.
I was using it to question that exact stated fuel consumption number without a citation. For hard data (like fuel consumption) getting a value from an LLM isn’t absurd.
If not absurd, it's very poor form. You should never use LLM as input for a discussion, nobody wants to hear that. Use it to search for authoritative sources.
It’s fine if you post an actual citation that you might have found through the LLM. Just posting AI slop is worse than useless, though, and also unpleasantly dystopian.
That’s the point? I wasn’t suggesting it was correct. Just that the value is wildly different from their own non-cited number. The next stage was to get a citation from an actual datasheet. Their reasoning was nothing beyond “I’ve read”
That could be. We just don't know right now, but your intuition may well be correct, even if there is a single root cause there could very well be multiple contributory causes.
They are not a failure of the original plan, they are a mandatory component of the original plan that if everything is nominal never gets executed. Every pilot on approach is ready for one or even more go-arounds and they happen quite frequently for a variety of reasons.
They happen a few hundred times per day at ~100 k flights.
How much extra do you need? Enough that a pilot/crew doing their job properly will never run out of fuel and crash.
So yes they will do an "investigation". It's not a criminal investigation. It's to understand the circumstances, the choices, the procedures, and the execution that ended with a plane dangerously close to running out of fuel.
This will determine if there were mistakes made, or the reserve formula needs to be adjusted, or both.
Don't tell me about cost, just stop. Let MAGA-Air accept some plane deaths to have cheap fares.
Could have, but pilots practice no fuel landings all the time (in simulators). If they can get to ground that is "level enough" nobody dies. It is not something you ever want to see in the real world (and in the real world people often do die when it happens), but it isn't automating people die.
I don't think that's all that true for airliners. Pilots definitely practice for engine-out scenarios during all levels of training up to the airlines, but the ability of a plane the size of a 737 to safely land on anything but a runway is...limited. And if you're low, slow, and trying to go around, that's not a lot of time to glide to ground that is "level enough".
Pilots are ultimately responsible for the aircraft, that's pretty much set in stone but if ATC would tell them to divert they would unless there already was an emergency.
Well clearly that number should depend on distance to next airport and how much fuel is onboard. It isn't sensible to have a set number when other parameters change.
It's far from all they can do, but it seems like they are focused on some important and achievable goals. These then feed into adoption which will bring other investment because Servo will be viable for more use cases. I see this investment more at the level of basic science research.
Which VC is going to be interested in implementing accessibility in this situation? The Sovereign Tech Fund is an organization that values this. It's too long term and uncertain of a project for most entrepreneurs to be involved in too.
I don't think anyone desires fragmentation. It's just the reality of the space. People were exploring options but didn't have support from the key stakeholders who were the browser makers (IE was at its peak) and Google. Firefox and WHATWG advanced some of the ideas in time.
People always mention RDF when the semantic web comes up. It's really important to understand where W3C was in the early-2000s and that RDF was driven by those with an academic bent. No one working with microformats was interested in anything beyond the RDF basics because they were too impractical for use by web devs. Part of this was complexity (OWL, anyone?), but the main part was browser and tool support.
> People always mention RDF when the semantic web comes up.
There's nothing wrong with RDF itself, the modern plain-text and JSON serializations are very simple and elegant. Even things like OWL are being reworked now with efforts like SHACL and ShEx (see e.g. https://arxiv.org/abs/2108.06096 for a description of how these relate to the more logical/formal, OWL-centered point of view).
If you go back to the time when they were invented, many semantic elements, like article or footer, didn't exist in HTML. People tried to find conventions and efforts like microformats were an attempt to standardize those when the best solution (updating the HTML standard) was difficult. In terms of timing, it's worth looking at the arc of Firefox, WHATWG, the advent of Safari and Chrome, and table use for layout.
Google was a driver in practice. Accessibility and better web experiences were important to those involved. The reality was that people interested in this area were at the bleeding edge. Many people still held onto tables for site layout and Flash was still a default option for some in the period when microformats emerged.
ARIA and accessibility microformats were separate from the ones the fediverse was excited about (and thus the GP was talking about)—things like hCard for identifying people, places, and things. Accessibility is useful to many people, but hCard et al. were probably never really useful to anybody other than Google. Still, many of us back then were obsessive-compulsive about using them in the hope that one day computers would better be able to understand authoritative information about identities and relationships between identities. I still have microdata on my personal web page.
You would think that this is an odd question. It's such an odd question if grant a degree of anonymity. I've seen a similar type of question, as it relates to affordances for parents in the workplace, like no on-call for a time when a newborn is on the scene. I don't know if this is just happening because people are feeling unfairly impacted when folks on teams become parents, but I'm always bracing for these comments now.
imo people asking those questions have no empathy, or they are just dumb. :)
You don’t _want_ a sleep deprived new parent on-call. A sleep deprived person is not who you want responding to an emergency, so of course others should pick up the slack temporarily. That’s what being a TEAM is all about. Kind of like playing a sport?
Now if the team is tiny the on-call impact will be a much bigger deal, and i sympathize, but in that case i’d blame management for having poor redundancy / contingency plans, NOT my colleague.
And for some reason there’s always some snarky person who chimes in with a comment like “but they chose to become parents!” A tale as old as time… so did our own parents! They chose. But i’m a human being that has empathy and i’m grateful to those who helped pick up the slack during their stressful newborn phase.
Slack has been acquired. It's the same with all of these big tech companies. There is a period after acquisition where things appear to stay the same. The reality is that the real work is now happening. Operations are being studied to understand how to fold the acquisition into the parent company.
The shadow IT model isn't the dominant one in the space where Salesforce play. They used that to a degree too when they were small, but they now lean towards enterprise sales. Shadow IT is sold as a risk by them. Want something secure, safe, and compliant? Work with us because we'll sign up to these things contractually (even if delivery is questionable.)
This means that a slack salesperson has to choose between targeting a department and pissing off IT versus working on a company-level deal. This changes behavior significantly. It also changes lots of the economic expectations. Previously, these little deals here and there could add up. On top, you might get credit from driving engagement. Now you carry a much larger quota where engagement is important in practice, but not in how sales is executed.
This drives the behavior you see here. Someone is reevaluating each of the current deals with this new lens. In practice, they can maximize revenue with these bullying tactics. Many times, in the enterprise space, it's better for a customer to be cut off, or give up, even if this is temporary. The intention is for the customer to return and agree to different terms even if the financials are adjusted to something more favorable.
>> On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way.
Going back to culture, who makes up the Typescript community? While C# devs are attracted to it there are many multiples more devs coming from a JavaScript background. This has a big impact on how the culture developed.
Taking a step back. C# devs often need to do frontend work. They could go with what the industry has settled on, React, or go another way. The bulk go with react and some perhaps lament still have to switch their brain to another mode for that work. Frontend is obviously more fragmented, but the scale prevents C# devs from influencing patterns to the extent that they do on the backend.
I'd argue similar for Java devs when it comes to frontend. In the case of Blazor, I think C# patterns are a much smaller factor in decision-making. In fact, lots of C# adherents would default to React given it's the industry standard.
>> That is an attack on self-custody. If you hold Bitcoin you now have an elevated risk of being picked up in some dragnet and suffering random consequences in unrelated parts of the financial system for reasons that you don't understand.
This is based on the idea that there is some exception from previous rules and regulations. Before Bitcoin existed, lots of these rules were formulated. Now Bitcoin is on the scene and has evolved best practices for self-custody that ignore everything that went before. Bitcoin becoming more popular and integrated means that the rules from US financial system will start to be applied.
There is no surprise in this. If more effort was put into mitigating the concerns of the US financial system (or others) then things like this wouldn't happen. However, the truth is that the philosophies are incompatible so it's just a war of attrition that will unsurprisingly result in conformance to US financial regulation.
