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.
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.
- 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.
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.
This is patently false. Tons of Enterprise orgs use Alpine for security concerns, ease of administration, and size. I guess all those prod microservices existence is "insane".
To use an eGPU, a Mac with an Intel processor is required.
People have previously mentioned that for Apple Silicon based macOS, since the "GPU" is effectively part of the cpu they've gone with a shared memory model (for the OS).
If you try plugging in an external gpu to an Apple Silicon mac, it would need to understand "separate graphics memory". That's how macOS runs for x86 arch, but it's not the memory model used by Apple Silicon arch. Thus, failure.
That's my understanding of things from half remembered readings anyway. :)
Exactly why I'm perplexed when people are able to install USB drivers for MacBook Air's to be able to drive 2 displays one over DP & the other over USB somehow after a driver software is installed
There's a product called DisplayLink that's used with certain USB monitors and USB docks. It compresses the video displayed on the screen in a userland daemon.
It requires Synaptic's software and it does work as a solution for devices that don't have enough I/O capacity to support multiple DisplayPort screens.
Even if Apple did implement more eGPU support, their relationship with Nvidia has soured so badly that I don't expect their drivers to ever work with macOS. AMD cards may work because Apple has used their GPUs before, but even on their new ARM chips Apple has decided to forego support for AMD GPUs.
Being a corp slog nearly my entire life, it's good to stay open to all opinions. With that I say, that I have encountered piles of fraud with organizations in my career. They would buy a couple licenses of RHEL when their fleet was really CentOS and they would just lie on support calls. I think this is what Red Hat was getting at with all the "freeloader" nonsense. Tone deaf, yes. Wrong, not totally.
...continuing to be fair, Red Hat support has literally been the best I have ever used in my career. Hands down. I know I sound like a shill but I'm not. Just a reg ol' engineer. I've since moved on, like most, to cloud and past RHEL but it has it's uses. Cattle not pets for cloud!
Regarding the "freeloaders" comment, Mike McGrath made a follow-up post on LinkedIn that includes the following:
> Finally, I wanted to say something about the term "freeloaders" I've seen many use it. This is a mostly internal term we have at Red Hat, it looks like at some point it slipped out in the public. So what does it mean? A freeloader is when a large enterprise business has 20 RHEL licenses, 150,000 community rebuild systems, and sometimes hundreds of user accounts and hundreds of kbase searches per month. It's not the enthusiasts, it's not the hackers and coders, it's not the academics, and it's not the people that use rebuilders because they can't afford it. We really try not to use the term, but when we do, it's about the large companies that can afford to pay but don't.
