#1 Kaspersky #2 Impossible to schedule #3 Cant update, must re-download

Am I missing something or is this a pile of dark patterns to drive you to a paid product?

Did you actually read the article? The conclusion is exactly what you state. No big deal. It's just a meandering and fun read. YMMV.

I got the sense that he’s speaking of the same people the author of the post is speaking of in the article, not the author himself

> Please call me (order of preference): Xe/xer, They/them or She/her please.

https://github.com/Xe

I don’t want to make more of it than it is, but reader mode cut that part out for me.

Most people who doesn’t run a Mac don’t care much about “models that don't fit into VRAM on macOS.”

this part of the announcement specifically mentions macOS

As long as the source is available, I always take the provided bins as a convenience versus a default negative attitude.

As long as they look like honest people I let everybody enter my home / borrow my car / access my internet banking / ... versus a default negative attitude?

Just a thought as well in my corpo experience: Unfortunately, there are some spaces that distribute solutions as k8s-only... Which sucks. I've noticed this mostly in the data science/engineering world. These are solutions that could be easily served up in a small docker compose env. The complexity/upsell/devops BS is strong.

To add insult to injury, I've seen more than one use IaC cloud tooling as an install script vs a maintainable and idempotent solution. It's all quite sad really.

Kevin Mitnik was famously held for 4 and a half years before his trial. That's where I learned about this shitty practice.

Anyone else rocking the "Free Kevin" bumper sticker back in the day?

This and civil forfeiture stuff always has pissed me off immensely.

I'm not a fan of civil asset forfeiture!! That's only a fraction of what makes me registered libertarian though hah.

Turned off, yes. ...but at the same time, I am violently against greed and psychologically manipulative processes to acquire wealth. YT is insidiously screwing with peoples minds for profit. They can Fuck Off.

I do understand your point but would counter that, if done right, you can revert your last commit. :)

Sadly it's not that simple. For example:

- Run a playbook which asserts the existence of a user

- Playbook fails at a later stage

- Executing an earlier version of the playbook which doesn't have the user assertion won't cause the user to be removed, just ignored. You need a different (assert not-existing) statement to actually remove the user.

In general these things won't be impactful - but they do mean that if you iterate on your deployment playbooks, you will end up with orphaned files/resources scattered around unless you explicitly tidy them up.

IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing.

> IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account - you need tens of servers to make it worthwhile, by which point containers start to look more appealing.

Ansible has a very low learning curve. I cringe with the thought of the time it would take documenting then typing in all the commands to setup my servers manually. That's just not feasible. Ansible provides a sweet spot between traditional "pet" servers and containerisation.

It's not only the number of servers that matters. It's also about being able to create ephemeral staging/developer environments, and easily being able to easily migrate to different VM providers.

> IME using Ansible for small-scale automation is no faster than just running the tasks manually, once development time is taken into account

You aren't wrong here but still the payoff is typically worth it, especially for small scale. "Development time" is one factor but the alternative -- building servers or infrastructure manually -- causes all kinds of problems when individual servers are not consistent.

Curious -- in this scenario, who is doing security, governance, compliance, observability, etc...? You are probably masking a lot of benefits of a mature and competent IT team. ...or you are assuming A LOT of risk allowing velocity-driven software engineering teams to run amok.

My previous employer is or has already transitioned mostly to the cloud. The answer to your question is " the same teams that were doing it before, but with cloud guardrails instead of hacky bespoke solutions ".

AWS IAM is baked into every single product natively. It isn't perfect and their JSON dialect is annoying at times, but having granular RBAC for storage, compute, ops, network in a single language is incredible for security.

And using IaC, you can put guardrails on specific tasks that IT does often. Manual reviews become automated.

It is a ton of conversion and up front work, but there are upsides.

And then of course there is the instant global reliability, where a lot of formerly complicated sysops becomes automated as well

Final thought: other than the hardware abstraction, everything I talked about re: IAM could be done with a local software stack, if it existed.

" the same teams that were doing it before, but with cloud guardrails instead of hacky bespoke solutions "

you do realize that "cloud guardrails" often started out life as "hacky bespoke solutions". you are assuming more business risk than is necessary.

As someone who did it for two years, I know not everything is perfect. But the tooling, monitoring, automation, orchestration, etc. becomes a lot easier when there are 4-5 toolsets vs. dozens.

It's like taking an ops support team that is using perl, java, php, python, bash, ksh running on RHEL5 and HP-UX and getting everyone on RHEL8, terraform and Go.