Thats two hundred years and would cover the end of Plantagenet reign and the Tudor era.

Henry VIII reign happened during that period, at the beginning of your time period everyone would be catholic and at the end Queen Mary of Scotts was executed because the idea of a Catholic on the throne was unthinkable.

The UK is littered with castles and estates, normally they focus on specific historic events which happened at that location.

Python’s public API changes subtly, so minor changes in Python version can lead to massive changes in the version of dependencies you use.

A few years ago we developed a script to update Cassandra on Python 2.7.Y. Production environment used Python 2.7.X (it was 5 patch releases earlier).

This completely changed the cassandra library version. We had to go back 15 patch releases which annoying resulting in a breaking change in the Cassandra libraries API and wouldn’t work on the dev environments Python.

Python 3 hasn’t solved this, 2 years ago I was asked to look at a number of Machine Learning projects running in docker. Upgrading Python from 3.4 to 3.8 had a huge effect on dependencies and figuring out the right combination was a huge pain.

This is a solved problem in Java, Node.js has the same weakness but their changes to language spec are additive so old code runs on new releases (just not the inverse). Ruby has exactly the same issues as Python

SpaceX are launching 26-52 satellites at a time and have sustained 3 launches a week for most of the year.

The satellites are in a Low Earth Orbit, without constant thrust, atmospheric drag will force them to re enter earths atmosphere within a few months. This means they aren’t adding to junk in space.

Unlike Nasa, ULA, Arriannespace, RoscosMos, etc… SpaceX have always performed 2nd Stage Deorbit burns, so they aren’t adding to Space junk by launching either.

The Low Earth Orbit is to ensure low latency and the need for constant thrust means the satellites have a short life expectancy by design. That is why SpaceX fought to keep the satellites as cheap as possible (e.g. $250k)

First stage booster reuse and fairing reuse means the majority of the launch cost is the second stage ($15 million).

The whole lot is privately funded

SpaceX have funded it privately. It apparently started operating at a profit this year.

@ergoplato I didn’t suggest that.

Personally I don’t think its ego. I think you have two issues.

The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.

Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won’t go down well.

The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven’t needed to do or understand.

A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.

I normally deploy it first as a test before a few other functions to automate various service management requirements.

Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc…) is due to that function.

For me this little function is a test, if the team don’t care I will work to integrate various bits. If they freak out, I’ll revert decide if it is worth walking them through the process or walk away.

One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.

The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.

This is compounded by the issue that most C/C++ build systems don’t really include dependency management.

Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few “root” distributions everything branches from.

That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.

That is a considerable amount of learning in a subject most aren’t interested in.

The real question is why don’t package maintainers upstream a packaging solution?

Engineering is tradeoffs.

A command shell is focused on file operations and starting/stopping applications. So it makes it easy to do those things.

You can use scripting languages (e.g. Node.js/Python) to do everything bash does but they are for general purpose computing and so what and how you perform a task becomes more complicated.

This is why its important to know multiple languages, since each one will make specific tasks easier and a community forms around them as a result.

If I want to mess with the file system/configuration I will use Bash, if I want to build a website I will use Typescript, if I want to train a machine learning model I will use Python, if I am data engineering I will use Java, etc .

You’ve just moved the packaging problem from distributions to app developers.

The reason you have issues is historically app developers weren’t interested in packaging their application so distributions would figure it out.

If app developers want to package deb, rpm, etc… packages it would also solve the problem.

Nice out of date dependencies with those lovely security vulnerabilities!