Ooph, so much going on in this thread. I want to contribute my thoughts as I fall somewhere in the middle ground between many of the passionate opinions in this thread and see a couple of different angles. I feel that the friction here isn’t actually about technical architecture but instead a cultural refusal to accept that the computing landscape evolved. (And how)
The romanticized mid-2000s era where a base install fit inside 1 GB of RAM and every configuration lived exclusively as an unadorned text file in /etc worked because Linux was a relatively small, homogeneous clubhouse. The ecosystem wasn’t trying to support hybrid-core processors, multi-DPI Wayland compositing, zero-trust security models, or everyday non-technical users (normies). Expecting modern computing to maintain the aesthetic simplicity of 2005 is fundamentally expecting it to stagnate. Full stop.
On that point, the erosion of simplicity that OP laments isn’t the result of malicious design, it is the natural consequence of Linux moving from a niche hobbyist OS to the baseline infrastructure of global computing. When an operating system expands to serve millions of diverse use cases, standardizing on a single monolithic dependency tree where one package manager arbitrates everything becomes brittle and unmaintainable.
Dismissing modern abstraction layers with “you’re too young to understand how good we had it” is honestly an intellectual surrender. It’s the classic posture of pulling up the ladder and rejecting anything unfamiliar as objectively broken simply because it isn’t how you did things thirty years ago. (get rekt boomers)
The critique regarding bloated footprints is valid on its face, but misattributed. We didn’t end up with higher resource overhead because engineers forgot how to code, we ended up here because hardware became fast and cheap enough that developer velocity took precedence over optimization. Just look at the game industry if you want one of, if not the biggest example. That dynamic, however, is hitting an abrupt wall. With frontier AI workloads siphoning off high-end hardware, rising silicon costs, and geopolitical restrictions forcing regions (like China) to squeeze efficiency out of legacy nodes, hardware abundance is ending. Optimization is becoming a necessity again.
If senior engineers are frustrated by how modern software utilizes system resources, the constructive path forward isn’t whining on forums about the past. It’s mentoring, running workshops, contributing patches, and showing the next generation how to profile memory, streamline cache hits, and handle low-level arithmetic.
A word on containerization and the sandbox. Flatpaks and containers are not developer laziness, they are a response to real-world threats. Now in the era where workstations hold browser sessions, cryptographic keys, and sensitive financial data, running every third-party utility with unfettered access to $HOME and system shared libraries is an untenable security posture. The fragmentation across Flatpak, Snap, and AppImages is painful, but that is the explicit tradeoff of Linux having no dictator above the kernel (and Canonical being… Canonical). Because Linus deliberately limits most of his scope to the kernel, the userland has to hash out standards competitively. It’s messy, but it’s the price of decentralized development.
Similarly, complaining about language-level managers like pip or npm misses their utility. They are rapid-prototyping workflows. The real gap in the ecosystem isn’t their existence, it’s the absence of a streamlined pipeline to graduate quick Python prototypes into production-grade, memory-safe, compiled binaries (like Rust). Maybe we can focus on that bridge as if you build it, surely they will come, right?
As @wertigon noted, tools like systemd, nftables, and modern networking stacks were adopted across the industry because the legacy alternatives failed to solve real concurrency, service supervision, and dependency management problems at scale. Systemd didn’t take over by conspiracy like many try to push, it took over simply because SysVinit scripts were an unmaintainable mess for complex modern systems.
My overall take is this:
Open source has a fundamental rule: if you don’t like the available tools, build a better alternative.
Lording outdated knowledge over newcomers, acting as a gatekeeper of “true Unix philosophy,” and hiding behind contrarian cynicism doesn’t make anyone an elite engineer. It just makes them friction. If the legacy architecture was truly superior, write the replacement daemon, package the minimal userland, and let the code speak for itself. Whining that the modern world moved on without your permission is not engineering… it’s just noise. Lead, follow or GTFO of the way.
