Erode institutions to erode public trust in institutions. You then a) free up budget to spend on your buddies and b) derisk regulation and/or public criticism from these institutions
Ansible works best when you only have Linux/BSD systems to manage, due to its heritage and doing everything through SSH.
If you have other systems to manage, like Windows or VMware ESX etc., it feels like a kludge with the delegation to localhost to get to the plugins.
Also, it can be tricky to use if your Linux systems have different Python interpreter versions because it's not at all straightforward to override the python interpreter used.
Looping constructs and sub-tasks etc. are also awkward to use, and the initial setup for a small automation project might be overwhelming for newcomers.
On the other hand you get a massive community with plugins for almost every conceivable system/OS, so that's definitely a huge plus
For sure not everything, I get a lot of mileage out of using SSM into ec2 hosts which doesn't even have Internet facing addresses
I am thankful that I've never had to manage Windows but I don't believe they're managed as localhost since if nothing else ansible doesn't offer control node execution on Windows
Word of advice: Whatever you use, try to be relatively consistent with commiting your changes. A traversable git history and clean enough state to keep track of what's fresh can be super helpful especially when troubleshooting or coming back after messing around with whatever.
And never commit inline secrets. Find out one of the ways to inject/separate/template secrets that's workable for you to stick with it.
For home use definitively recommend Ansible. I've used/uses both and for a handful of servers/VM and for a single administrator I'd always pick Ansible. Realistically what you want is just a tool that store a configuration in some VCS and an a why to apply that configuration quickly.
Ansible will allow you to do that with just "pip install ansible". Puppet requires you to setup so infrastructure, which you need to way of bootstrapping.
Personally I also find Ansible easier to work with, in the sense that you can more easily do stuff in small increments. Upgrading Ansible is also a lot simpler. Puppet really cool and powerful, but for home stuff or a small business I'm not sure the overhead of managing Puppet itself is worth it.
Puppet is a project to implement. Once it's implemented, it's great. It requires dedicated infrastructure to work properly.
Ansible is much easier to step into slowly if you don't have time to implement a full deployment project before you can use it. You can start without dedicated infrastructure and add later if you want more centralized management.
https://github.com/ansible/awx#readme is also helpful if one needs "runbook" behavior to allow arbitrary audiences to run playbooks without the headache of installing something and dealing with local cred management. Interestingly, it also offers a "callback" system to allow machines to request a playbook upon themselves in cases where ansible-pull isn't appropriate/helpful
Ansible is a little bit easier to get started for a few reason (yaml instead of a DSL, ssh only...) ; it's also mostly tasks running through SSH which may feel a bit more "natural" when you are configuring machines initially.
In terms of idempotency I find it is easier in ansible to mess up something but if you are careful they are on par. I've used mostly ansible over the past few years in various jobs but the first I got in touch with ~10 years ago was puppet and it felt very solid especially for heterogeneous environments (we had different archs and OSes to manage). Also puppet scales very well because it has agents as well as many tools to manage large infrastructures which I tried and were already quite convenient 10 years ago.
TL;DR probably use ansible unless you have a very specific use case.
I am a pretty big proponent of ansible but I have given grave consideration to making a fork that uses Skylark instead of yaml because the "what can I type here?" story is terrible as is. Most of the jinja expressions are already basically python so it seems like a natural fit
That will keep SSH installed, a service running, and the puppet config file managed forever. If you accidentally replace the config file it will be fixed and the service restarted. If you remove the package it will be reinstalled, config file updated, and service started.
Not a fan of ansible, it's more of a "run this playbook", which translates to reinstall and "run this playbook", which in environments that don't reinstall very often can be painful. Since ansible playbooks don't know the current machines state they never know exactly what commands to run.
Generally if you spin up containers or similar short term servers I think ansible is fine. If it's a larger and more complicated environment with longer lived servers I'd use puppet.
Oh, one other think I like about puppet is if you say apply X to all nodes, you can literally not run puppet (it will fail to compile the manifests) if you try to override it. Which security auditors LOVE.
I've repeatedly tried to make Puppet work for "small" installations, be it a single dev laptop, our fleet of default base VMs (before containers were a thing), or home use. You couldn't really do anything without community packages, and their update rate was kinda meh. A lot of churn.
Puppet always seemed to me like a scalable enterprise solution, but you either need a team to keep it in check, or just never update.
I'm not specifically recommending Ansible, but it's what I've been using for a couple years, and I would always recommend that for home use over Puppet.
Disclaimer: I last used Puppet in 2017, but for like 7 years extensively before that and everything I mentioned happened several times.
Second disclaimer: By now I think parametrizing everything is a huge mistake - the real worth is editing the config in one place and having it in SCM. if you only parametrize 2 lines out of a 100 line config file and basically copy it over with 2x `sed` - that's fine.
Ansible looks like a default choose for this use case but for my personal server (running in a VM) I'm planning to migrate away from Ansible and try puppet. I tried to use Ansible for a few years and abandoned it because it was too tedious to maintain configuration in Ansible. Puppet of course also requires time but if feels so much easier, mainly because it has ruby-like DSL (not YAML).
I think that might be a myth? If I tried buying a $0.50 candy bar with a hundred-dollar bill, I think that the cashier might refuse it and I don't think they'd get in trouble for doing so.
I thought the "legal tender" argument only worked in regards to debts to the government, though IANAL.
For the AI un-initiated; is this something you could feasibly run at home? eg on a 4090? (How can I tell how "big" the model is from the github or huggingface page?)
I tried using Hunyuan3D-2 on a 4090 GPU. The Windows install encountered build errors, but it worked better on WSL Ubuntu. I first tried it with CUDA 11.3 but got a build error. Switching to CUDA 12.4 worked better. I ran it with their demo image but it reported that the mesh was too big. I removed the mesh size check and it ran fine on the 4090. It is a bit slow on my i9 14k with 128G of memory.
(I previously tried the stability 3d models: https://stability.ai/stable-3d and this seems similar in quality and speed)
The hunyuan3d-dit-v2-0 model is 4.93 GB. ComfyUI is on their roadmap, might be best to wait for that, although it doesn't look complicated to use in their example code.
That's a shame. We found a significant performance loss with kubevirt and nobody has ever really been able to explain it or make it go away. 15% throughput loss on an open source mq.
reply