Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem That Built an Industry

ajitem.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: The Problem That Built an Industry

#21

Post by throwup238 »

arrsingh wrote: post #6

Interesting to note right at the start of the article that they sat on a plane next to each other in 1953 but the formal partnership between AA and IBM was not till 1959 - 6 years later! The article makes it look like all this happened magically fast but in reality a reminder that things take time! >> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IB…

> Reminder to myself when my potential customers don't sign the deal 5 minutes after my pitch!

The classic "the decision makers can take longer to buy than you can stay solvent" problem of enterprise sales.

Re: The Problem That Built an Industry

#22

Post by zer00eyz »

01HNNWZ0MV43FF wrote: post #16
zer00eyz wrote: post #15

SABRE, is a reminder that things that are well designed just work. How many banks and ERP's, how many accounting systems are still running COBOL scripts? (A lot). Think about modern web infrastructure and how we deploy... cpu -> hypervisor -> vm -> container -> run time -> library code -> your code Do we really need to stack all these turtles (abstractions) just to get instructions to a CPU? Every one of those layers…

Library code - This is necessary because some things are best done correctly, just once, and then reused. I am not going to write my own date/time handling code. Or crypto. Or image codecs. Run time - This makes development faster. Python, Lua, and Node.js projects can typically test out small changes locally faster than Rust and C++ can recompile. (I say this as a pro Rust user - The link step is so damned slow.) Co…

> Most of it's here for a reason.

Your argument for host os, virtual os, container is the very point im making. Rather than solve for security and installablity, we built more tooling, more layers of abstraction. Each have overhead, security surface and complexity.

Rather than solve Rusts performance (at build time), switch to a language that is faster but has more overhead, more security surface, more complexity.

You have broken down the stack of turtles that we have built to avoid solving the problem, at the base level...

SABRE, what the article is discussing, is the polar opposite of this, it gives us a hint that more layers of abstraction arent always the path to solutions.

Re: The Problem That Built an Industry

#23

Post by alwa »

arrsingh wrote: post #8
StilesCrisis wrote: post #7

"The key insight is [...]. No daemons. No background threads. No connection state persisted in memory between transactions." Closed the tab.

I noticed that too and did roll my eyes as well but I'm glad I kept reading - its actually quite a good article. Maybe the author used an LLM to help do some copy editing but should have probably given it less editorial agency. Either way I'm glad I read it and waiting for the other parts of the series. Really curious how to get access to this airline booking data so I can write my own bot to book my flights and deal…

Same here—I tolerated the linguistic tics, I found enough meat to keep going, but it’s the conclusions that confuse me. And that feels like the intellectually dangerous part with this sort of LLM writing. For example:

> Convergent evolution is real. Every major GDS independently arrived at the same underlying platform. That is not coincidence — it is the market discovering the optimal solution to a specific problem.

I struggle to understand the claim that GDSes “arrived independently” at interoperability standards through “convergent evolution” and market discovery. Isn’t it something closer to a Schelling point, or a network effect, or using the word “platform” to mean “protocol” or “standard”?

Isn’t it like saying “HTML arose from web browsers’ independent, convergent evolution”? Like—I guess, in that if you diverge from the common standard then you lose the cooperative benefits—see IE6. And I guess, in that in the beginning there was Mosaic, and Mosaic spoke HTML, that all who came after might speak HTML too. But that’s not convergent evolution, that’s helping yourself to the cooperative benefits of a standard.

“The market” was highly regulated when the first GDSes were born in the US. Fares, carriers, and schedules were fixed between given points; interlining was a business advantage; the relationships between airlines and with travel agents were well-defined; and so on [0]. IATA extended standards across the world; you didn’t have to do it the IATA way, but you’d be leaving business on the table.

If anything, it seems like direct-booking PSSes (he mentioned Navitaire [1]) demonstrate the opposite of the LLM’s claim. As the market opened up and the business space changed, new and divergent models found purchase, and new software paradigms emerged to describe them. It took a decade or two (and upheaval in the global industry) before the direct-booking LCC world saw value in integrating with legacy GDSes, right?

…the LLM also seems bizarrely impressed that identifiers identify things:

> One PNR, two airlines, the same underlying platform.

> Two tickets, two currencies of denomination, one underlying NUC arithmetic tying them together.

> One 9-character string, sitting in a PNR field, threading across four organisations' financial systems.

[0] https://airandspace.si.edu/stories/editorial/airline-deregul...

[1] https://www.phocuswire.com/Jilted-by-JetBlue-for-Sabre-Navit...

Re: The Problem That Built an Industry

#25

Post by ForOldHack »

bombcar wrote: post #3
paulnpace wrote: post #2

> It...handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years. Eat that, Bitcoin.

50,000 transactions a second is a bunch for humans. It’s nothing for even an ancient CPU - let alone our modern marvels that make a Cray 1 cry. The key is an extremely well-thought and tested design.

It was mostly written in COBOL. This is how I got into XENIX/UNIX. A machine went down that was a training machine: It required XENIX on a PC, because it ran on RM/COBOL on XENIX, because all the screens, and the encoding, already written were in COBOL. RM/COBOL had an ancient compatibility, but the code was extremely simple, having been ironed out many decades earlier. ( I got it in 1985, but all the creation dates were 1982. The original files must have been from the mid 1960s. I pointed this out, and someone called me on it. I found a training manual from 1966, and the screens were exactly The same, except of course for the 3270 status line.

It was fast on an 4.77Mhz IBM PC, and much faster on a 10Mhz V20.

50,000 transactions was pretty standard for a IBM Mainframe, now? The z/ Series is still about the same, but it scales up to 32 processors. ( excuse me, billions. per day )

Re: The Problem That Built an Industry

#26

Post by ForOldHack »

zer00eyz wrote: post #22
01HNNWZ0MV43FF wrote: post #16

Earlier quoted context omitted.

Library code - This is necessary because some things are best done correctly, just once, and then reused. I am not going to write my own date/time handling code. Or crypto. Or image codecs. Run time - This makes development faster. Python, Lua, and Node.js projects can typically test out small changes locally faster than Rust and C++ can recompile. (I say this as a pro Rust user - The link step is so damned slow.) Co…

> Most of it's here for a reason. Your argument for host os, virtual os, container is the very point im making. Rather than solve for security and installablity, we built more tooling, more layers of abstraction. Each have overhead, security surface and complexity. Rather than solve Rusts performance (at build time), switch to a language that is faster but has more overhead, more security surface, more complexity. Yo…

There are shops, I know of that run a java emulator of a GE Mainframe running... Multics. Someone told me that, and I was floored. Multics.

Re: The Problem That Built an Industry

#27

Post by andai »

>TPF is not modern. It would fail every architectural review a contemporary engineering team would apply to it. It also handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years.

What kind of review would it fail? Sounds like it's pretty well designed to me.

Re: The Problem That Built an Industry

#28

Post by bombcar »

ForOldHack wrote: post #25
bombcar wrote: post #3

Earlier quoted context omitted.

50,000 transactions a second is a bunch for humans. It’s nothing for even an ancient CPU - let alone our modern marvels that make a Cray 1 cry. The key is an extremely well-thought and tested design.

It was mostly written in COBOL. This is how I got into XENIX/UNIX. A machine went down that was a training machine: It required XENIX on a PC, because it ran on RM/COBOL on XENIX, because all the screens, and the encoding, already written were in COBOL. RM/COBOL had an ancient compatibility, but the code was extremely simple, having been ironed out many decades earlier. ( I got it in 1985, but all the creation dates…

And there are people who think virtualization was invented on the 386 :)

Re: The Problem That Built an Industry

#29

Post by andersmurphy »

arter45 wrote: post #20
andersmurphy wrote: post #17

Earlier quoted context omitted.

I mean you can easily do 100K TPS on a M1 with sqlite and a dynamic language. With sub 100ms latency. People don't do it because it's not fashionable (the cool kids are all on AWS with hundreds of containers, hosting thousands micro services, because that's web scale).

Well, transactions in this context are business transactions, which may involve 1 or N remote calls. Imagine checks against no fly lists, fraud detection, flight delay and so on. Speed of light is also another concern. So it’s not as simple as doing 35k TPS on a local SQL database. But yes, you don’t always need cool technologies.

True, but a lot of those checks will be against a local snapshots of the data.

> But yes, you don’t always need cool technologies.

That's kinda the irony mainframes are incredibly cool piece's of tech, just not fashionable. They have insane consistency guarantee at the instruction level. Hot swapping features etc. Features you'd struggle to replicate with the dumpster fire that is modern microservice based cloud computing.

Re: The Problem That Built an Industry

#30

Post by uxhacker »

ForOldHack wrote: post #25
bombcar wrote: post #3

Earlier quoted context omitted.

50,000 transactions a second is a bunch for humans. It’s nothing for even an ancient CPU - let alone our modern marvels that make a Cray 1 cry. The key is an extremely well-thought and tested design.

It was mostly written in COBOL. This is how I got into XENIX/UNIX. A machine went down that was a training machine: It required XENIX on a PC, because it ran on RM/COBOL on XENIX, because all the screens, and the encoding, already written were in COBOL. RM/COBOL had an ancient compatibility, but the code was extremely simple, having been ironed out many decades earlier. ( I got it in 1985, but all the creation dates…

Most of the systems used for GDS’s were in fact written in Assembler. I know as I have worked with a number of the systems. This is one, but not the only reason the different systems have remained on TPF machines.
Post reply on HN