£800/day is low, but not unheard of especially if you use freelancers/small boutiques, but £2k/days is more than I've seen for most things in the UK.

I think it could well be right that they're hoping for the (likely impossible) blink from the EU, but between that, the heavy political toll a US trade deal would require (it would have a big impact on the UK farming community+possibly other areas) and the expanding spat with China, it's really not shaping up to be a good period, economically speaking.

Instead they explicitly rejected that opportunity and carried onwards...

If they've believed UK Government rhetoric about how Brexit will be a smooth process that will enhance the UK's trading opportunities, this may come as a surprise.

There are (IMO) a reasonable number of UK citizens and businesses who haven't grasped the likely consequences of what's happening on 1/1/21

You can also explicitly add namespaces to manifests, which help avoid applying to the wrong namespace.

One of the harder parts of vulnerability scanning is building and maintaining the plugin database. Nessus, which is one of the older and better known VA tools has 10's of thousands of plugins...

There are other, open source, vulnerability scanning tools available as well like OpenVAS https://www.openvas.org/

And in the US and many other countries gambling is regulated, so that the games have certain parameters and the risks are known, can't see that being applied to pyramid schemes.

It doesn't seem likely to be in the interests of most governments to actively encourage straight Ponzi schemes as when the people at the bottom of the pyramid lose their money, they may end up requiring state assistance, transferring the risk to taxpayers.

In addition to the well-known integration points (Container Runtime/Network/Storage Interfaces), there's things like the lack of a good built-in user authentication mechanism with Kubernetes, which means you pretty much always need some external authentication service for your clusters.

That's not too bad if your on one of the big managed providers (GKE/AKS/EKS) but can get complex for people who want to deploy on-prem.

Uber has burned through many billions of investor cash. To show a reasonable return on that cash it would need to generate not just profit, but a lot of it.

Whether it can do that in markets like taxi's and food delivery is a quite debatable point as competitors will continue to spring up quickly especially when Uber tries to put the prices up enough to generate the kind of profts needed at their scale.

In some markets that is justified. Those where significant infrastructure is needed to compete. For example Amazon's network of warehouses and datacentres would be hard for a competitor to replicate at scale.

For other markets, that's not justified. For example Uber, a small scale competitor can operate with some taxi's and an app. They won't have all of Uber's capabilities for sure, but they can compete in a locality.

With rootless podman they use slirp4netns and all get the same IP, with rootful podman or Docker a bridge network is established so that containers that aren't in the same pod can communicate with each other.

What is it about their approach that you feel is superior?

Podman has long running processes as well, there's a podman process that'll run once you've launched at least one containner, and a conmon for each container (equivalent to containerd-shim)

Packaged directly... it is by RH and SUSE, don't think by debian/ubuntu. At least for ubuntu, 20.04 packages Docker 19.03 just fine.

From a complexity perspective, you're adding more places for things to break. Instead of (say) running your apps in containers with Docker, you add pods, services and ingress as layers, which is more places for things to go wrong.

If it's experience deploying applications into containerized environments, then micro-k8s and k3s seem like reasonable choices, you don't really care about the setup of the underlying components, just that they present the k8s API.

If you're looking for experience of managing k8s clusters, then either the distribution you're looking to run in prod. or something like kubeadm are perhaps a better option. kubeadm is very "vanilla" in terms of how it's deployed so it's quite representative of production (on-prem) deployments, perhaps unlike k3s which makes changes to how k8s works.

If you're looking to quickly test things in k8s, I'd recommend kind as the easiest way to stand up and remove clusters quickly.

And if you're looking for something to run your home services long term, I would recommend not using Kubernetes :) (unless you have a really complex home network which might justify adding k8s to the mix)

In the organizations I've seen with mainframes, what happened was a panoply of supporting systems sprung up where new requirements existed as everyone was afraid of making significant changes to the mainframe environment.

I'm not surprised at the mainframe's lack of success at all, the barriers to entry are extreme, meaning there's an inevitable lack of activity.

I've worked in environments which had mainframes deployed and even as an employee it was inordinately difficult to get any access to them.

Combine that with IBM's "enterprise" sales process and it's not a mystery that they lost the fight to attract newer systems...

Re-writing that, is going to be a nightmare, as you've got no spec. to work from and mistakes may not show up immediately (think monthly or annual payment processes)

It's a very high risk endevour with little immediate reward for the team doing it. If it goes perfectly, no-one notices, if it goes badly it could seriously impact your whole company.

When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...