Dev vs. Ops

Linux as a platform is the equivalent of asking random volunteers to build a city, not telling them exactly how you want it built, and then hiring contractors to take what has been built and make it work for the majority of people. It's organized chaos.

I think the author is wrong that you need to enforce specific ways of doing everything, or that we need to even think about standards. The only thing you really need to enforce is a culture, which becomes an unofficial, de facto standard. I think Windows is a good example of this. Windows doesn't force you to do everything its way - it's just way, way more convenient. Linux makes it too convenient to do something different, so everyone does.

I think the solution for a distribution is the following:

  1. remove all unnecessary software
  2. remove all methods to easily install new software automatically
     (reserve that function only for updating existing software)
  3. make all base software follow a set of guidelines which are incredibly
     convenient to adapt and follow by new applications

The result would be a culture of convenience that would enable more compatibility by simply making it easier for everyone to do the same thing. My apologies if the author proposed this very thing; it was too long and I didn't read it all.

I hate to be so callous about this but this article is really just a dev shitting on ops people because they either don't understand or are intentionally omitting the reason why sysadmins are put between devs and production.

> Linux distribution developer tells application and system developers that packaging is a solved problem, as long as everyone uses the same OS, distribution, tools, and becomes a distro packager.

There is no such thing as Linux. There is Redhat Enterprise Linux, Ubuntu Linux, OpenSUSE Linux, Debian Linux, ArchLinux, etc.. These are systems with a loose set of tools in common but differ to the point of absurdity in organization, structure, availabile software, and capabilities.

Supporting multiple distributions should be viewed as supporting multiple platforms. You can either port your software or bundle all your dependencies, all the way down to libc if you want.

> making sure that the overall OS fits into a fairly specific view of how computer systems should work

Which is another name for 'software is incredibly complex and conventions are needed if you want to stay sane'.

Quick, where do web applications go? /srv/myapp, /opt/myapp, /usr/share/webapps/myapp, /usr/share/myapp, /var/www/myapp, /var/myapp/, /myapp, /usr/local/myapp? If you answered all of this above you've used 3rd party software on a Linux system. Where do you think the logs for all those locations wind up?

Packaging is the art of beating software into submission so that it can actually be managed, secured, audited, and monitored.

> You're still supposed to go ask your sysadmin for an application to be available, and you’re still supposed to give your application to the sysadmin so that they can deploy it — with or without modifications.

This is PaaS which isn't mandatory but highly suggested when dealing with teams of developers. You write the code until it works, we deal with making that new library you want that was released two weeks ago work, deal with the licensing of your APIs, libraries, drivers, and tooling, and integrating it into your CI/CD pipeline. You just write the code.

> to convince the developers of...

Because that's not how it works, we take your source distribution model, pip, bundle, npm (i.e upstream) and turn them into packages. There's no convincing to do because they're not in conflict.

> The issue is not the 'managed by somebody' part; the issue is the inevitable intermediary between an application developer and an application user.

This is what it's really about. Devs don't understand what ops people actually do and just see them as a team that slows them down and tells them no a lot.

> developers are heavily based on the concept of a core set of OS services; a parallel installable blocks of system dependencies shipped and retired by the OS vendor

Otherwise known as a the packages your distribution ships.

> How did foo get into the repository?

Because a distribution vendor thought your software was useful, packaged it for distribution, and put it in their repository. At this point it is NO LONGER your software or your responsibility. The vendor has adopted this package and committed ensuring that it works and is maintained. People with problems should (and do) complain to them rather than you.

> How can you host a repository, if you can’t, or don’t want to host it on somebody else’s infrastructure?

https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

You make a repository and host it on your infrastructure. I promise it will be the easiest web service you've ever configured.

> What happens when you have to deal with a bajillion, slightly conflicting, ever changing policies?

Depends, if you're distributing it yourself then you treat it like cross platform work. If distributions are packaging them for you, then you sit back and let them do it. If your IT dept is deploying your software then you let them handle it.

> How do you keep your work up to date for everyone, and every combination?

You push an update (i.e copy a file) to your repository, then people download and install it. Again, if you're opting for either distro maintainers or IT dept you just publish your code and let them deal with it.

> What happens if you cannot give out the keys to your application to everyone, even if the application itself may be free software?

You distribute the software (myapp) and (myapp-license or myapp-api-keys) in a separate package and mark the keys as a dependency.

> Scalability is the problem; too many intermediaries, too many gatekeepers.

There aren't any gatekeepers. There are people are doing work for you. You are totally in control. You (or your org) can opt to have some of that work done for you. You can't pretend that it doesn't need to be done at all.