Proves the point that if one isn't reaching for Cloudflare performance levels, maybe that JIT in "pick your lang" is already more than adequate for the work being done, no need for RIIR.
Which is kind of lost in the days that everyone wants to be the next unicorn.
Flighty is very pretty, but I’m not giving up FlightAware anytime soon.
I travel a lot, and frequently encounter flight delays. It’s mind boggling difficult to find out where my plane is when it’s delayed via Flighty. This and a few other things, FlightAware gets right.
I feel like Flighty is for rare leisure traveler and FlightAware is for weekly business and/or pilot traveler.
I’ve honestly had better luck with iOS built in flight tracker than Flighty itself.
Flighty is in a weird place because I'm a rare/leisure traveller and wow Flighty nowhere near reasonably priced for that market.
I used it in free mode when I was on iOS, but it would be ~£10 per trip for something that would improve my life less than a coffee at the airport.
In my opinion they need to aggressively cut costly features (like weather data), and if they have different international data feeds, perhaps do region locked pricing. I don't fly to the US much, so let me buy a Europe and Asia subscription and skip the US costs. Or vice-versa. It would have needed to be ~£10 a year at most.
I’m a touring lighting designer, I fly anywhere from 20-120 times a year. Every fellow LD I know uses Flighty, any time i get delayed flighty tells me before the airline does.
I especially love that it usually tells me or warns me about a delay before I leave the lounge, so i get to spend some more time relaxing. That and of course the amazing data in your flighty passport!
The promise is that it informs you quickly about flight delays, flight cancellations and gate changes. In my limited experience, it didn’t work satisfactorily for a flight delay of a few hours. It could not provide any reliable updates.
It’s a nice app and service, but I wouldn’t trust all those reviews that are like “I knew before the aircraft pilot knew”. It has its own limitations.
I don’t see any value in knowing before the pilot knows. I’ve mostly flown American the past few years and with their app I get updates about delays and gate changes on my phone just fine. I suppose there might be some advantage to getting the notification a bit earlier, but I doubt that they can reliably give information faster than the airline itself.
I think I figured it out - if you can figure out a cancellation before everyone else you can get to the counter and get on another flight before everyone.
I've had once cancellation in my life so I see why the need hasn't presented itself very loudly.
Yeah, the most notable "use", not necessarily "value", is when the airline is still prevaricating over the delay, you're approaching boarding time and you can see from ADS-B that the inbound aircraft hasn't even begun initial descent.
Last year Flighty literally saved me from an overnight delay because it notified me the incoming aircraft was still on the ground at the previous airport. I was able to snag the last couple seats on a later scheduled flight which actually departed. My original flight ended up getting canceled.
As airline crew, I stay in the lounge (employee lounge, not bar lounge) when I know I'm not going anywhere on time.
Flighty gets heavy use from US airline employees. We're frequently in the airport with a brief break before flying the next flight. Usually, this next flight will be on an aircraft that hasn't arrive to the airport yet. Most of us will find a quiet place to relax for awhile and it's really irritating to pack stuff back up and walk to the gate just to find out there's no plane.
Another scenario is you arrive to an airport and need to switch aircraft. The "turn" time might be scheduled for 45 min. It's really nice to know as you walk off the aircraft that "Hey, it's actually delayed. Now I have 2 hours." I'll go grab a bite to eat or catch up with family back home etc.
My particular airline will show you what the next inbound aircraft is and it's flight number and ETA but it's a "fetch" experience. You open the app, wait for a refresh, click like 4 times to navigate to the right page, get the tactical information. Flighty keeps it on the lock screen. Just lift your phone and it's there.
We're constantly asking our employer to emulate Flighty. Tech isn't their strong suit though.
Sounds like you identified a business opportunity for Flighty - license the functionality or just sell app access to the entire airline, at least for employees.
I fly around 6x/yr but I still found it useful enough to get the lifetime plan. I suppose if I only flew once per year I wouldn't have gotten it, but I don't mind paying ~$10/flight (probably even lower by now, and who knows what it will drop to by the time Flighty stops working, hopefully more like ~$1/flight). A typical trip might cost in the range of ~thousands of dollars so $10 to reduce my stress levels when there is a delay is worth it in my book.
For example... if there's a delay and so because you found out sooner you can stay home an extra hour instead of sitting at the airport I would pay $10 for that.
One question for clarity: why don’t you see an opportunity to sell AI or other technology into this space again? Is it just because incumbents already have it locked up and it’s cheap?
The reason I ask is that this feels like one of those moments in history similar to mobile. PlanGrid succeeded because tradespeople suddenly had iPhones and iPads in the field, which made it possible to digitize blueprints and collaborate in real time.
Put differently, what could be the new “PlanGrid” for your industry - that AI makes possible now, the way mobile once did for construction?
Pest control is about 60% consolidated, and I don't want to pick the fight of convincing the top 5-6 to buy more SaaS or AI. Realistically they're looking to Salesforce for leadership there.
I see today's consolidation as fragile though, and it's not locked in forever. I'm better at building a competitor where I have full influence of the customer and worker experience, and I have the patience to see it through.
Part of shaping my thinking here is 1) knowing what I'm good at, much better than I did before, and 2) in my previous company we built a heavy equipment telematics platform which was used on about 1/3 of the UK's infrastructure projects. JCB (an equipment OEM with their own bad version of what we were doing) threw the kitchen sink at field sales and account management, and they had reach into all the sites across the country. It was an eye opener and good lesson about go to market for enterprise sales in traditional industries.
For those, like me, who find the prompt itself of interest …
> A full transcript of the original conversation with GPT-5.4 Pro can be found here [0] and GPT-5.4 Pro’s write-up from the end of that transcript can be found here [1].
I wonder what was in that solutions file they provided. According to the prompt it’s a solution template but I want to know the contents.
Another thing I want to know is how the user keeps updating the LLM with the token usage. I didn’t know they could process additional context midtask like that.
Every major high-throughput database now runs as microservices, not sure why people still act like things just grind to a halt when the network is involved.
Since when were payment networks latency sensitive? It’s usually 2 or more seconds to even get a payment up on the card terminal from the merchant POST system, then 2-5 seconds more from card presentation to getting approval back.
> Since when were payment networks latency sensitive?
Since the advent of e-commerce, POS-networking and fraud detection systems in 1990's-2000's.
User-facing and authorisation path are highly latency sensitive. It includes tap-to-pay, online checkout, issuer authorisation, fraud decisioning, and instant payment confirmation – even moreso for EFT payments.
> […] 2-5 seconds more from card presentation to getting approval back.
This is the mid-1990's level QoS when smaller merchants connected the acquirer bank via a modem connection, and larger ones via ISDN.
Today, payments are nearly instant in most cases, with longer than one-second card payment flows falling into the exceptions territory or inadequate condition of the payment infrastructure.
yeah, if the card is an EMV chip card, and might also have a SVA so everything is handled between the terminal and card, it can be blazingly fast.
In EU they use of offline PIN was used massively before PSD2 and contactless, that made the terminal request during the time it took for validating the transaction online, and basically as soon as the PIN was ok'ed by the card that confirmed the transaction. That gave a perception of speed.
Now it's basically online PIN mostly or contactless, but that means you perceive a "wait for an ok", that you had before but was masked by the PIN capture and check on device/card.
So we went a bit backwards for cards, but wallets like ApplePay went a bit forward. You win some you lose some I guess
It's not simple though. In that 140ms the network is checking fraud rules, validating the card, checking available credit, applying rewards logic, and routing across multiple parties. The actual subtract-one-number-from-another takes microseconds. The rest is trust verification across organizational boundaries — which is the hard part of any payment system.
At best it’s checking available credit. All the other stuff is done after the fact. The idea that any banking transaction involves “subtracting one number from another” is so wrong it’s barely worth engaging with.
>Since when were payment networks latency sensitive?
Apple Pay is extremely fast from my experience (at least the web version). There is a high percentage of market loss if payments take long or fail. Im sure there must be a graph for where it plateaus with diminishing returns when it comes to speed but faster payments definitely help with sales.
> Maybe Amex being a closed-loop network helps with latency?
Yes, this is a huge deal. VisaNet and friends have to wait on the actual bank cores in order to perform online authorization. Amex can guarantee end to end latency.
Doesn't matter if you have 500 microservices if only one or two take part in card authorization (as it should be if microservices were architected correctly).
There's ton of logic on non-critical path that can be extracted to other microservices and called asynchronously - settlements, refunds, rewards, all management and reporting functionalities - to name just a few.
If you're designing a car, then the CEO/Founder might want the ability to add falcon wings to it at any point, and that's pretty reasonable. If you're designing a trustworthy encyclopedia, knowing that the CEO/Founder might wish to alter arbitrary facts to his whim is really not very reasonable. Is it his company? Sure. Do you want to make low-quality information artifacts? That's a judgement call.
Sounds pretty crazy to me, bud. I keep landing on 'servitude with extra steps'. Owner should have better things to do/people to bother, I should have space. Boundaries, etc. Yeah yeah, I'll never make a bazillion dollars. I'll know freedom.
Even an executive assistant, which I would never apply for, has off hours.
Tangentially related: I haven’t seen DragonflyBSD talked about on HN in a long while but wasn’t it a split from FreeBSD to be built entirely around message passing as the core construct.
And with the tiny team working on it, it has remarkable performance.
This thread has more comments (28+)
reply