fyjvd90

I’m just taking the article at face value, they use the word container and say they’re not compatible. So maybe the article could be better, not sure.

I don’t think you’re reading the article, it says:

> Each project has a separate internal representation of a container that is not shared. Because of this you cannot see Podman containers from within Buildah or vice versa.

> Mounts a Podman container. Does not work on a Buildah container.

^ this here is one of the problems, the containers are not compatible is my interpretation.

The tool feature sets overlap with subtle differences according to the article, that blurs the line on what each one is for. They need to pick a direction, if you’re making a build tool and a run time, the the build tool must only build, and the run time must only run, or just make one tool. Intentional and truthful (meaning the words mean only what they say) design limits the chaos that happens in the wild, these tools aren’t doing that. It may seem clear to you, but the article is littlerly about how it’s not clear and how they overlap confusingly. So you’re going to come across a mess at some point due to this mistake, that or they could explain their rationale for the overlap but they don’t.

See the table of the subtle differences, why does podman create images that aren’t compatible for example? Regardless of what Docker does, if you make tools that are for a specific use case why blur the lines?

I think that explanation is a little clearer, however the repos and the article don’t make this clear and the fact that podman also builds images makes it less crisp.

> Some of the commands between the two projects overlap significantly but in some cases have slightly different behaviors. The following table illustrates the commands with some overlap between the projects.

And this makes no sense at all if you’re purposely designing a tool.

I may not fully understand what the tools can do but it seems overly narrow scoped. Also in that Unix philosophy you don’t duplicate functionality that’s slightly incompatible between tools to the point you need paragraphs and tables to explain when to use which one.

In that it adds complexity to have two tools vs one. And in the wild will add risk of mistakes and wasted time due mixups since they overlap and have incompatibilities. I’d rather give a team one tool, the only reason this is two tools is because they were independent projects, but they realy should be one conceptually.

The more seasoned the manager or exec will say at this point that you should always see everyone as having good intentions. It’s of course not true at all, but seems to be one if the mental tools they use to not acknowledge what someone is really doing. I think what it does do in reality is gives the person a way out when they come to their senses without having to admit they went down a selfish dark path. So in that sense it’s practical. Although it can take years with some people too. Personally I just fire them if they report to me or I have sone influence I get them out of the org another way.

It’s also interesting how a democratic Rome voted for becoming an oligarchy.

Yeah PCI or FedRAMP have this 10 char password requirement, which of course no one can remember a 10 char password. So companies just make the password a pattern with some variations, effectively reducing the complexity to a tenth of a random 8 char password and the people who know the pattern leave the company so it’s effectively public. So much for math.

It does, but there’s also what I call stupid security that doesn’t really add any measurable improvement, but does decrease productivity. Users out smart these systems all the time (e.g. forced password changes where you can’t use the last 10 passwords, users just change their password 11 times so they can continue to use a password that’s been configured on their devices. It’s stupid then to force changes like that when there are much better ways like mfa)

Smart security allows users to do what they need to do efficiently and safely.

Not Linux specific but:

Don’t make your security encourage legitimate users to work around it due to pointless friction

OAuth is going to be hard to use if you don’t create an account though, there’s no way for DS to know what scopes to restrict the user to, it sounds like that was the core issue that broke their workflow.

I would also like to know why it takes my HMO (Kaiser) 6 weeks to make lenses, and why their invoices don’t list what products they sold you.

The argument isn’t correct, what does a user do when the download is damaged by an injection? A re-download results in exactly the same tampered with file.