Dev vs. Ops (2017)

I upvoted this, because the discussion is worth having.

However I couldn't be in more disagreement, even more than when I started reading it.

Yeah, it's definitely easy to convince ourselves that getting the latest and greatest is important or that availability of software trumps all else.

But do you know why I have 20year old rolling release installations of linux still running? Because there is quality control.

The reason that in 2004 I could reinstall Windows XP and all my drivers inside 25 minutes was because I had done it so freaking often. Windows of today is not significantly better, it's basically a CPU fighting pit of software that seeks to add their own special updaters and their own special UI subsystems and their own special tracking hardcoded with their own distributed libraries and eventually full of all kinds of disgusting nasty security holes.

I mean, it's less bad than all that, but Linux is usually a single command and the whole system is upgraded, with a QA approved, security patched and moderately vetted version of all the software you have selected. With no special jails or layers of indirection and linked to your system in a way that is at least moderately optimised for the intended design goal of the distro.

We should be aware of what we trade away when we decide that package managers don't work; because frankly linux users used to lord it all over windows and OSX users that they were the only ones with a hard won and working package manager for the whole OS.

For sure though: if I have to choose between running a docker container to run the hip and trendy version of `nc` or not having that software available... Then I choose not having that software available, because frankly speaking: those gatekeepers serve a purpose.

The admins and distribution maintainers in this article are really a proxy for all stakeholders beyond a developer who's doing the minimum to get a feature into production.

But, the requirements the tooling and workflows were built for didn't lend themselves to use in development, preventing evolution into tools that work well for more use cases.

I started rebuilding and deploying .debs with custom patches for production 15 years ago. For some projects .rpms or .debs are the only way we distribute builds that go beyond individual developer workstations. It's an absolute luxury on projects that are amenable to workflow. But I've never been a distro maintainer. So I both feel limitations of the tool, and simultaneously don't feel like I have a good grasp on leveraging those those tools as well as I could.

I suggest a different point of view: modern "way to distribute software" are BAD response to a problem that should not exists in the first place.

For instance we all know "the dependency hell", but we also know the stockpile of wasted resources to deploy essentially an entire OS minus the kernel and few surrounding just to deploy a small app and the issue such model have with gazillion of built-in vulnerabilities because the small chat client dev do not have upgraded OpenSSL simply because for him is just marginal. We know the idea of "separation" and the normal failure because we need integration, resulting in pushing data outside the desktop or punching holes here and there in a Babel's alike tower of CRAP.

Essentially BOTH model does not work.

So? Well... In the classical systems there was no OS - userland - application software. Just a single application where various actor develop different aspects, including the end users, since they were "end users programming environments" and "programming" was just a simple and easy interaction with "the system" (the single fully-integrated app). Those systems have had their own set of issues, but they have offered MUCH MORE with much less hell than newer systems. Yes, much more. Yes, an old Alto offer TODAY much MORE than a modern system to the end user.

Both "modern" systems, those with the classical "Unix approach" (GNU/Linux classic package management) and those with "Windows approach" (modern package management systems like snap and co) are the result of the need to sell software as a product before, as a service thereafter. They do not have solved the issues of pioneering BUT they have added much new issues.