Comment by zer00eyz
14 hours ago
> 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.
If you poke it a little you will eventually get Java exceptions. Because the AI article is lying. It is not 60 year old code running on unchanged bare metal. Things got reimplemented over time.
Nowhere does TFA claim that SABRE or Amadeus or other similar systems are using 60 year old code.
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.
while we can learn from the past, we probably shouldn't look at it through sunglasses that are rose-tinted ;)
---
sabre, the company that owns and builds the current version of the system SABRE used by major companies today, uses all of those things the parent and you mentioned
> Google Cloud-native infrastructure that is scalable and secure. Microservice-enabled architecture that supports modularity. API-first approach for an open platform. [0]
> We rebuilt Sabre from the ground up: cloud-native technology, AI baked into the foundation, one goal in mind. Your success. [1]
yeah ... it's 'ai powered' now.
[0]: https://www.sabre.com/resources/viewpoints/offer-order-strat... (skip to the 'different by design' heading)
[1]: https://www.sabre.com/about/
---
> Do we really need to stack all these turtles (abstractions) just to get instructions to a CPU?
no. but those abstractions are there for things like scaling, reliability, redundancy, flexibility, ... and a bunch of other things not related to solely getting some instructions to a CPU. the number of turtles has increased because customers have more requirements for software today than they used to have in the 1960s.
sometimes we need the simplest solution with fewest dependencies. sometimes we need lots of turtles... it really depends on the problem in front of us.