> Several defence analysts point out that although the KC-46 is the standard tanker of the USAF, it has suffered technical problems and delays that have slowed its competitiveness abroad, to the benefit of the A330 MRTT, which has already been adopted by many NATO and non-NATO allies. In this sense, the Italian choice is seen more as an industrial victory for Airbus than as an American “political defeat”.
The political factor surely played a role here, but this bit at the end of the article also sheds light on Boeing's decline, which predates the current US administration.
While politics acted as a catalyst, Boeing was ultimately defeated by its own undoing.
Having doors flying off one of your planes and engine failure causing part of the cowling to bust a window and sucking a passenger out of another is definitely not a bit of politics. Nevermind the bullshit 737Max nonsense. At this point, I'd imagine any Boeing orders left are only in place because Airbus can't keep up. Politics didn't need to come within 10 miles of this decision. It's just the free cherry on top.
The engine that failed on the Southwest flight was a CFM International CFM56, which has also been used on multiple Airbus planes including the A320. The engine itself as well as the containment mechanism that’s supposed to prevent this kind of situation were the responsibility of CFM and had nothing to do with Boeing. This could just as easily have happened on an A320.
This example only serves to highlight how popular narratives take hold and get reinforced by laypeople.
Boeing absolutely deserves to be raked through the coals over MCAS, over their deteriorating engineering culture, and over regulatory capture. But blame them for the things they actually carry responsibility for.
> The engine itself as well as the containment mechanism that’s supposed to prevent this kind of situation were the responsibility of CFM and had nothing to do with Boeing.
NTSB seems to think it’s Boeing’s responsibility to redesign the cowl to prevent this.
If you read your own link, they also think it’s the engine manufacturer’s (CFM’s) responsibility to work with Boeing to redesign the cowl, and recommend that the European Aviation Safety Agency require engine manufacturers to work collaboratively with airplane manufacturers for such cowl design in the future.
My "interpretation of it" is explicitly in the document.
"Therefore, the NTSB recommends that the FAA require Boeing to determine the critical fan blade impact location(s) on the CFM56-7B engine fan case and redesign the fan cowl structure on all Boeing 737NG-series airplanes to ensure the structural integrity of the fan cowl after an FBO event. The NTSB also recommends that, once the actions requested in Safety Recommendation A-19-17 are completed, the FAA require Boeing to install the redesigned fan cowl structure on new-production 737NG-series airplanes. The NTSB further recommends that, once the actions requested in Safety Recommendation A-19-17 are completed, the FAA require operators of Boeing 737NG-series airplanes to retrofit their airplanes with the redesigned fan cowl structure."
Is your position that somewhere in this 193 page document, the NTSB buried a line that says "just kidding, Boeing is faultless here"?
It's not a question about fault. Boeing is responsible for the final integration of their aircraft, so naturally any orders to fix the engines would be given to them.
The engine is built by CFM, and it's CFM who will have to actually design the required fix. Boeing doesn't have the skills for that because the complexity of a modern turbofan is more similar to a microchip than the rest of the airplane. They certainly cost more than the rest of the airplane put together!
The public loves fire-and-brimstone responses to safety issues but the honest truth is that sometimes airplanes crash for stupid reasons and vaporizing all of the accumulated experience a company has following a crash is not going to make things safer.
Even with MCAS, even with the doors falling off, Boeing aircraft are incredibly safe because the US has spent nearly a century working with the company to improve things. This is a tricky thing to get right, because the FAA and NTSB have to unilaterally decide on a system that will make airplanes safe while also keeping them affordable enough to be flown.
> The engine is built by CFM, and it's CFM who will have to actually design the required fix. Boeing doesn't have the skills for that because the complexity of a modern turbofan is more similar to a microchip than the rest of the airplane.
From what I can tell, Boeing designed the existing cowl and NTSB says they need to redesign it. The complexity of the jet engine itself doesn’t seem particularly relevant because the cowl isn’t needed to make the engine function. It’s needed to catch shrapnel if the engine fails and flies apart.
> The public loves fire-and-brimstone responses to safety issues but the honest truth is that sometimes airplanes crash for stupid reasons and vaporizing all of the accumulated experience a company has following a crash is not going to make things safer.
No idea why you are saying this in response to my comment. All I said is the NTSB wrote that Boeing needs to redesign the cowl and you seem to think I said Boeing needs to be liquidated.
If we're stringing random facts together to try and make a point, Airbus was found guilty two days ago of manslaughter in the 2009 Air France crash that fell into the ocean.
I think it's fair to call out the parent comment for things that are not exactly caused by Boeing (eg: the engine failure), but I also think it's important to look at the why.
In the case you're referring too, the focus was on poor training and failure to follow up on earlier incidents. It's not the same as designing a system based around a single sensor that is known to fail or forgetting to bolt a door.
> It's not the same as designing a system based around a single sensor that is known to fail
Right, they designed the their system with two sensors, and if they disagree, the system gives misleading indications to the pilots! That’s so much better!
My understanding is that the Airbus equivalent (they don't really have the same thing) uses 3 pitot tubes/angle of attack sensors, not 2. More importantly, Airbus pilots know about the system, while Boeing only told airliners about MCAS after the Lion Air crash.
I'm not a pilot and I don't know that much about planes, but I've read/watched enough about crashes to know that these sensors fail way too often. To rely on only one already sounds like a bad idea, but it's irresponsible not to tell pilots and train them on how to deal with the new "feature".
Airbus aircraft are normally fly-by-wire and a system like MCAS would just be folded into the envelope protection that Airbus does. It's already very easy to cross-train from once Airbus to the next because FBW is used to give them all similar handling characteristics.
That wasn't possible in the 737 MAX because the airplane is an older design with hydraulically connected control services, so a separate system had to be added to force the nose down using the trim.
If you actually read into the case it's more complicated than just it's Airbus fault. It was caused by one of the confused pilots input. Why they were confused is a complicated story.
That particular failure mode would have been impossible in most other planes including all Boeings. 1. Pretty much only Airbus doesn’t have linked controls 2. Pretty much just airbus changes what the controls allow you to do (the “law” as they call it) without input from the pilot.
No other airliner make on earth could have suffered that accident. It would have been extremely obvious what the issue was, and how to solve it on any other aircraft I can think of. This was like a car crash caused by the computer changing how the steering wheel worked mid drive.
I still have no idea how Airbus didn’t catch more flack for that design.
And yet, that design did not stop the pilot from stalling the plane as that was the cause of the crash, the design actually helped the pilot stall the plane without even knowing it. The argument isn't that computers shouldn't play a role in flight controls (indeed some military aircraft are unflyable without a computer in the loop), its that the interface - which is completely unique among all other airliners and commercial passenger planes - is so non-intuitive that it allowed something to happen that would not have been possible.
If you go full stick back in any other airliner, the other pilot will know it immediately, and can physically correct the input. Other planes have stall prevention and awareness in the form of stick shakers and stick pushers that give the pilot physical feedback, and in the case of a pusher makes the pilot physically fight against the safe action (in the case of the MAX, trim adjustment - a roundabout way of stick pushing - was implemented in an exceptionally stupid way that made it overpower the pilots)
Incidents that are over five years old have minimal impact in terms of current competition between Boing and Airbus.
The airbus A320 family is associated with 1,490 fatalities, there’s just a vast number of flights daily so tiny risks add up. Companies buying new aircraft care far more about maintenance to fuel efficiency than a few rare incidents due to already corrected issues.
Can you shed a bit more light on this? I can't find any evidence that there are that many fatalities related to that plane, at least related to its operations in flight. Seems like there are few or if my quick look shows even zero fatalities related to it flying. You wrote "associated" but can you define what you mean by that? During manufacturing, maintenance and other non-flight-related incidents?
> Having doors flying off one of your planes (…) definitely not a bit of politics.
It’s a checkmate of the American system. Boeing delegated construction in parts of the country that needed jobs (=politics), who then botched the job and didn’t get sanctioned because it was bad optics to accuse those providers (2013 airframes). More recent events are also a checkmate of the ultrafinanciarization practices, a checkmate of the consultancy / provider / controller model, and a failure of corruption (the FAA/Boeing dinners inherited from the Macdonnell management) in a context where USA rips at the seams (industrial failure, no-one can be trusted as trustworthy) and tries to renew its ideology (apogee with the Trump elections).
That is a fair bit of politics that made Boeing fail.
Yeah - the mass casualties with regards to Max, changed things a lot. Boeing used to be about enginering; that quality dropped indeed decades ago. Not sure why or how.
> Following the 1997 merger with McDonnell Douglas, Boeing’s robust culture eroded. Subsequent safety issues with the Boeing 737 have put the company under international scrutiny and underscored the profound impact of a weakened corporate culture. As Forbes aptly put it, “Boeing’s current travails about safety issues with the 737 MAX 9 can arguably be traced to the company’s weak corporate culture.”
The best and understated part about it is that the culture change was pushed from Boeing side, and at least some people from McD side of the merger were pushing internal memos warning about actions pushed by Boeing-lifer CEO exemplified in then ongoing 7X7 program (future 787)
No, majority of Boeing orders to foreign countries use USA backed loans or is a significant part of pushing US interests in the world.
The message here, and it’s granted if you’re not aviation, finance or political aware is Italy keeping their aviation sector EU based being In the EU themselves and most likely getting tremendously better financing.
While the Boeing incidents you mentioned are unfortunate and a true consequence of engineering culture eroding at Boeing, it does not dispel the true safety of aviation in general nor the high success of the 737 Max.
Yes, but the decline of Boeing also imo demonstrates relentless American short-term-ism. Gutting the engineering side of the company, optimizing to avoid testing a new plane model (the 737 Max debacle) and so-forth is very characteristic of America today.
> "Yep. The only people I've heard saying that generated code is fine are those who don't read it."
I review every line of code I generate with AI. I mainly use an MR-based approach:
1) Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. Usually at least one of them is on the right track, and it is better to ditch a solution that went in the wrong direction than to try to fix it.
2) Review the explanation and diff of the proposed changes line by line, file by file. If I find minor deviations from what I asked, or violations of the codebase architecture/conventions, I write comments in the diff and/or global comments, and ask again for 3x adjusted solutions.
3) Usually, by this point, the solution is ready for me to merge locally and either run local tests or do some manual fine-tuning.
4) Finally, I generate unit tests. I leave them to this stage because I can repeat the same process with the sole intent of generating case-specific unit tests. This way, I can generate/review tests against the final version of the implementation.
This has been working very well for me since our repos are reasonably organized and have a well-defined architecture. In the technical spec, I include the major architectural requirements and code conventions, and I also add a catch-all like "follow the codebase's existing conventions and style", which works reasonably well.
This simple process has enabled me to deliver most minor/medium tasks and bug fixes really quickly while maintaining control over the changes and without lowering the quality bar. For larger and more challenging tasks, I find myself "driving the wheel" (i.e. coding by hand) more often, and using AI code generation in a much more scoped and specific way. So that becomes a different process altogether.
Hilarious to see the insecure AI doomers downvote personal experience comments like this because they don’t fit with their “AI is useless garbage” takes. I used to respect engineers as a class, because I thought we were more rational. Turns out we’re just as likely to be driven by fear and insecurity as anyone else.
I love Docker Compose. It is simple to use, easy to organize and manage, and very robust. Also, our company does not need to "scale" production aggressively. Our production load is very predictable, so Docker Compose fits like a glove.
We have been using it for more than five years now. Before that, we had a legacy deployment model, and I do not remember a single major issue related to Docker Compose.
We use it for both staging and production environments. The same Docker image validated in staging is deployed to production. Never fails!
There is a theory which states that if ever anyone discovers exactly what Kubernetes is for and how it works, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
It's simple to use only for toy use cases, that's why nobody uses it. The article everyone in this thread seems to like only goes as far as 'I pushed to git so it must be ok' which is laughable and I'm not even DevOps.
What happens if it errored on deployment or after that? you wanna write custom (bash? :D) hooks for that? What about upgrading your 'very vertically scalable' box? What if it doesn't come up after the upgrade? your downtime is suddenly hours, oops.
The k8s denial is strong and now rivals frontend frameworks denial. Never fails to amuse.
Fair points, and yes, failed deploys need to be handled explicitly.
In our case, the answer is not "hope and bash". We deploy versioned images, use health checks, monitor the result, and keep rollback simple: redeploy the previous known-good image/config. Host upgrades are also treated as maintenance events, with backups and a recovery path, not as something Compose magically solves.
But I think there is an opposite mistake too: assuming every production system should be operated like a high-scale tech company.
Many production workloads are boring, predictable, and business-critical. They do not need aggressive autoscaling, multi-node orchestration, or constant traffic-spike handling. They need reliable deploys, backups, monitoring, health checks, and a clear rollback path.
That is where Compose can be a good fit: simple operational model, understood failure modes, low moving parts.
Kubernetes becomes much more compelling when you actually need automated failover, rolling deploys, autoscaling, multi-node scheduling, and stronger deployment primitives.
Not needing Kubernetes is not necessarily denial, it is just choosing the complexity budget that matches the problem.
Definitely not a one-size-fits-all choice, but Kubernetes can be so easy and there are so many benefits that get you from one small app to a medium sized business that it seems like a no-brainer for someone starting out. Spinning up k3s is pretty minimal overhead, but right away you can handle storage and backups very easily, automatic certs for all your apps with cert-manager is pretty much a one-and-done, traffic management for external and internal tools is easy, and even logins for websites is just an annotation in a yaml file. You can spin up and try out any software you want without spending time configuring it or setting up additional servers- and when you do need more hardware, it's one command on a virtual server, and just about as easy with physical hardware.
2-3 miniPCs, cloudflare, tailscale, and k3s can save (possibly tens of) thousands on SaaS products, and would probably scale you to a company of dozens AND host your product.
>2-3 miniPCs, cloudflare, tailscale, and k3s can save (possibly tens of) thousands on SaaS products, and would probably scale you to a company of dozens AND host your product.
Get a few Beelink SER5 or SER9's, install Nextcloud to cover the files, document editing, communications (to save on Microsoft 365). Then you can have Gitea (and gitea actions) for your source code and building (skipping github enterprise), Harbor to host and scan your containers, frappe for HR, etc. Pretty much anything you pay enterprise rates for, you can self-host a version that will get your company from 1 to 100s with minimal extra work. If it's not on https://github.com/awesome-selfhosted/awesome-selfhosted, you can probably vibe code it in a couple hours.
I just started to run a k3s cluster with an almost enterprise grade software factory and a few (light) production workloads on a single cheap minipc.
The concept totally works but I would worry about using a beelink in a business context where I had to support it.
For up to low hundreds of users I think you're better off just with 1 vertically scalable box for all the officey / web server workloads.
You mitigate the hardware failure stuff with a vendor contract where you can get someone on-site and overnight you parts, and by keeping things super boring. Volume replication is not boring, avoid at all costs. NAS or SAN if you have to but all disks in the main box for as long as you can.
For 20 person SME maybe a 2-bay Synology or similar, for a heavier company a low end 2U with hardware support. Proxmox under the OS for reduced worry snapshots, rollback, backup etc. Proxmox is there for operational flexibility, resist the temptation to create a network of VMs, you just need 1 CT or VM with all the workload inside it.
For container workloads on 1 host Portainer works as well as k8s IMHO, it gives you the key property you want - you can IaC everything declaratively with terraform + compose over an API.
Caveat that if CI gets heavy you might need to scale that out but you can keep it stateless.
I checked your page. Wanted to ask, are you using longhorn with k3s for replicated volumes? How beefy a box do you need for that (CPU/MEM/Disk speed)?
I have several VMs in clouds with similar k3s architecture as yours and am wondering if there are any benefits to installing longhorn vs sticking to logical (postgres, mimir, whateveritis) replication instead.
I think people are using different meanings of “production environment.”
I agree with gear54us and upvoted their comment, but I also understand what the author of the root comment is saying.
I have also delivered systems using Docker Compose that are actually running in production. The point I want to make is that people may define “production” differently depending on the number of active users, operational requirements, and risk level.
To me, this debate feels similar to the broader monolith vs. microservices debate.
Not necessarily. When you get to those numbers you're seeing dozens of teams with their own silos and deployment methods. So they might be responsible for the core business that's running 30 nodes and serving 100MM users a day, or they might be working on some internal portal or a WordPress site.
When I mentioned that, it was for a company that got acquired by a bigger company. I can't give specifics with revenue / profits but it is a 10+ year old online SAAS business and all of their web apps are being served by Docker Compose with a non-trivial amount of direct customer facing traffic.
Lots of data, caching, web apps, background workers and lots of various API integrations. No fancy React front-end, no fancy crazy system architectures. Just a typical LAMP stack but running in Docker Compose, cranking away serving value to customers with very good uptime and a very low cloud cost relative to revenue. With that said, a managed database was involved but all of the web traffic was served by apps running through Docker Compose with a simple git push model of deployment that handled thousands of deployments over the years without much fuss.
That as well as different definitions of scale. I've done small bits of consulting work for a research company for the past four years, deploying and managing Kubernetes clusters for them as well as helping get some of the main applications up on it. This is all internal tooling, though. Their customer-facing sites are just Drupal instances running on bare EC2.
Internally, though, they wanted to self-host a chat server, Apache airflow, Overleaf for collaborative editing of research proposals, three separate Git servers, a container registry, many other things, all with extremely strict multi-tenancy isolation requirements for storage and networking because they're handling customer data and their own customers audit them for it. That was a hell of a lot easier to do with Kubernetes than trying to figure out some giant universe of barely related technologies with vastly different APIs, having to buy specialized appliances for network and storage that probably also need their own control plane software hosted somewhere else.
But if you just look at "scale" as number of http requests a particular URL gets per some unit of time, the customer-facing sites have far greater scale. If you're trying to attribute revenue, beats me. They wouldn't sell anything without the customer-facing sites, but they wouldn't have anything to sell without the internal tooling. Solo web devs get into this tunnel vision view of ops because, to them, often the web site is the product. That's not the case for most businesses.
And, of course, they'd probably just use someone else's SaaS for tooling. But if you're in a heavily regulated space where that isn't possible and you have to self-host most of your business systems, then what?
The post receive hook provides you real-time feedback as it runs in the terminal where you did the git push. If something broke during the deployment you'd get notified by looking at the output. If it's running in CI, you'd see a CI failure and get notified using whatever existing mechanisms you have in place to get notified of deployment pipeline failures.
Zero downtime server upgrades are easy. You could make a new server, ensure it's working in private and then adjust DNS or your floating IP address to point to the new server when you're happy. I've done this pattern hundreds of times over the years for doing system upgrades without interruption and safely. The only requirement is your servers are stateless but that's a good pattern in general.
Define production. Docker compose is fine for running a small internal service in production for dozens of users (i.e. not for developing said service, but for using it). I would assume it isn't fine to run a hyperscaler (but I wouldn't know). Those are extremes, and there are going to be a ton of situations in between.
I can't personally speak to what the limit of docker compose is, as I have only worked on the lower end of this: self hosting for personal use and for small internal services serving maybe 20 users.
From my personal experience if deployment strategy is thought through then Docker running through Compose can handle few hundreds of thousand of users per day without an issue and probably could handle more with proper hardware upgrades.
Most people/apps only need the toy cases... If you're writing an internalized tool for a company that will only have a handful of users, then doing much more than compose for deployments is a violation of KISS and YAGNI.
Are you really going to try to get 4+ 9's of uptime for a small, one-off app? Do you really need to use a cloud distributed data store that only slows things down for no real gains in practice? Do you really think the cloud services are never down, and you're willing to spend a f*ck-ton of money to create a distributed app when historically an Access DB or VB6 app would have done the job?
I've moved applications deployed via compose pretty easily... compose down -t 30 then literally sftp the application to a backup location then to the new server which only needs the Docker Engine community stack installed.. then compose up -d ... tada! In terms of deployment, you can use github action runners if you want, or anything else... you can even do it by hand pretty easily.
My full name, phone number, and address were leaked by TAP Air Portugal about five years ago, along with the details of my parents who were on the same booking. Since then, my dad has been targeted by those types of scams where a fraudster impersonates me to ask for money.
I never received a notification from TAP; I only found out a year later through my Google One security feature. I certainly didn't get an apology—much less a free travel ticket!
If the scam success rate is 0.1%, and it takes days to comb a phone book and put together a list of potential relationships and takes a human 10 minutes per phone call, the economics of scamming works out a lot less profitable than importing a data leak and emailing or robocalling everyone in the list.
I do use an email alias everywhere. But I don't believe you can do the same with phone numbers. I tried using my twilio rented number and there is a way systems use to figure out if that is a real number for a person or a VoIP one. Though it is sometimes successful in use for signups and hence spam reduction.
Could set up 6 digit long extensions and only ever issue a few hundred of them in total.
Guess wrong 3x and goodbye.
Can also set some/most/all to go to voicemail so they can get in touch with you, but not really.
Or blackhole the invalid extensions to /dev/null voicemail but then you run the risk of legit misdials and you never get some important message.
The real vs “fake” number issue could be worked around by having your cell phone provider forward all calls to your VoIP number. It’s baked into gsm, don’t need a phone after initial setup: https://www.geckobeach.com/cellular/secrets/gsmcodes.php
That TAP data was leaked on a tor hidden service, in multiple files, and download was extremely slow on the days following the leak. One of the files was much smaller, and my friend had the bad luck to have his data in that one.
His phone was spammed so incessantly he had to change his number almost immediately.
I'm dissatisfied about the TAP leak as well! I was affected, and like you, didn't even receive a notification - nevermind compensation for having leaked my personal data to the dark web enabling all sorts of shenanigans that make my personal life difficult.
About 2 million portuguese there. Basically all active portuguese adults that have enough financial conditions to travel by airplane.
It was a fantastic leak, based from an excel file asked by a marketing department which forgot it inside a shared folder on the hacked (private) server. There was far more info there than just that, also included the details of employees and more interesting if they were on medical leave.
Curiously enough many of those employees were family members from politicians and well-known people. Some of those in long term sick leave were receiving a monthly salary while conducting live shows on festivals during the summer.
Nothing happened on the news. They all went silent about this case.
One trick I like to use is to role play the other side's perspective with the AI, putting myself in their's shoes. It give's me clarity about what I might be missing out in a dispute/discussion, and insight about reaffirmations AI might be feeding other parties.
That's an interesting take. I'm likely on the same side of the split as you, since I'm very much motivated by the new possibilities agentic coding tools open when used responsibly.
Back in February, I also wrote a piece on the recurring mourning/sense of grief we are seeing for 'craftsmanship' coding:
Makes sense. You just reminded me of the article "Why Can’t Programmers... Program?" [1].
Before gen AI, I used to give candidates at my company a quick one-hour remote screening test with a couple of random "FizzBuzz"-style questions. I would usually paraphrase the question so a simple Google search would not immediately surface the answer, and 80% of candidates failed at coding a working solution, which was very much in line with the article. Post gen AI, that test effectively dropped to a 0% failure rate, so we changed our selection process.
Employee solidarity matters, but absent a legal constraint, I don’t think it’s a durable control.
If this remains primarily a political/corporate bargaining question, the equilibrium is unstable: some actors will resist, some will comply, and capital will flow toward whoever captures the demand.
In that world, the likely endgame is not "the industry says no," but organizational restructuring (or new entrants) built to serve the market anyway.
If we as a society want a real boundary here, it probably has to be set at the policy/law level, not left to voluntary corporate red lines.
One thing worth pointing out is that by the time Yoon Suk Yeol declared martial law on December 3, 2024, he was already one of the most unpopular presidents in South Korean history. After that his ratings declined even further. This makes for a much smoother enforcement of the law to make him accountable for his actions.
That’s fair at the “adopt AI at scale / restructure orgs” level. Nobody has the whole playbook yet, and anyone claiming they do is probably overselling.
But I’d separate that from the programmer-level reality: a lot is already figured out in the small. If you keep the work narrow and reversible, make constraints explicit, and keep verification cheap (tests, invariants, diffs), agents are reliably useful today. The uncertainty is less “does this work?” and more “how do we industrialize it without compounding risk and entropy?”
I use agents all the time but I keep my feet on the ground. The thing is doing that you do not get the radical explosion in productivity that influencers want you think they are getting.
The political factor surely played a role here, but this bit at the end of the article also sheds light on Boeing's decline, which predates the current US administration.
While politics acted as a catalyst, Boeing was ultimately defeated by its own undoing.