This repo is for the DSC v3 project
github.com
github.com
What worries me is that Microsoft is pushing DSC as an alternative to Group Policy but this is like saying C# is an alternative to Excel. Sure, technically you can sum up tabular data with both but the user experience is not even remotely the same.
Everything I have found in the past related to DSC boiled down to “you can write your own things using this baroque nonstandard system” which doesn’t appeal to me. I’d rather write a script or tick a checkbox in a GPO. The in between space occupied by DSC doesn’t feel like a good fit for anyone.
Worse, DSC was always a half-baked solution made by a tiny team. This new version seems extra underfunded. There’s no documentation to speak of! I can’t even find what operating systems they support, for example.
I want declarative state configuration as a concept, but I don’t think PowerShell DSC can deliver this. The industry has moved on to container images, scale set images, and monolithic executables as produced by dotnet and go.
You know you need it when you have a document that details all the steps in setting up windows itself and a couple of common softwares. Then someone ham fists something every once in a while and causes confusion for everyone.
1. I'm loosely following the development for DSC (v3 or v2-tooling) and never have I heard Steve Lee, Michael Greene or Michael Lombardi advocate DSC as an alternative to GPOs.
2. How do you get to the conclusion that DSC is a non-standard system. What's your point of reference with that statement? I am not aware of any standard out there, but I'd love to be educated. I have the same question about the baroque-statement. Yes, DSC is old, but so are Chef and Puppet.
3. Why do you say DSC is half-baked? It was never intended to be an Alternative to Chef and Puppet, if that is what you're comparing it to. It's intended as a foundation for tools like Chef and Puppet.
3a. You want declarative state as a concept and that is exactly what DSC delivers.
4. The industry has not moved on to container images. These are two separate "movements" and there still is very much a need for bare-metal services. And this is still very prevalent with Microsoft services like AD, Exchange, SharePoint, SQL, or other Software like Veeam, ... I don't understand once more what your point of reference is with this statement.
The only part where I agree is that DSC is underfunded. That is factually true with v2, where in fact it wasn't funded at all for a decade. I believe DSC v3 is backed by Microsoft with a small budget, but it still isn't clear to me what the end goal is.
I think it is a good decision to remove the need to compile into MOF, which simplifies a lot of the process. At the same time I wonder why they would remove the LCM, which complicates the entire process of having state re+applied to a machine when it deviates locally.
And then of course, DSC v3 still doesn't do much if there's no tooling around it. Azure has configuration management based on DSC, but it is a pain to learn and to configure in my experience. I really, really wish Microsoft would have a holistic approach, but my impression is that they don't and just fiddle around individual components, without a clear picture of the desired end result.
So what's the point of PowerShell if most new CLI tools from Microsoft aren't PS modules and can't take advantage of the .NET object model, even on Windows (see also winget)? Why is DSCv3 under the powershell organisation if it's just a regular Rust CLI?
I can only speculate, but since there is no more LCM, a binary was needed to properly run DSCv3 on your machine.
I can only speculate, but since there is no more LCM, a binary was needed to properly run DSCv3 on your machine.
But that's still damning: If Microsoft themselves are building their PS modules as ConvertTo/From-Json wrappers for native CLIs (or being shipped at all, like winget's PS module), instead of shipping C# cmdlets and a domain model for .NET, then PowerShell is superfluous and we should be dropping it, even on Windows, for a JSON-aware shell or a more common shell with tools like jq.
https://youtube.com/watch?v=lyiyzYPeh8s
Other talk recordings and content are available at https://psconf.eu/recordings/videos-2024/
NB. DSC v3 hasn’t shipped yet (well it’s open source but y’know, no official releases yet, it’s in preview).
I’ve visited about 15 links and found some go code[1] that doesn’t really make it clear.
It’s like Terraform, but for Windows workstations?
1. https://powershell.github.io/DSC-Samples/tutorials/first-res...
> Non-PowerShell resources define their schemas with JSON files, not MOF files.
> Configuration documents are defined in JSON or YAML files, not PowerShell script files.
Will have to look at this properly next week, but each of those is promising!
https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
Disclosure, I'm working on https://github.com/purpleidea/mgmt/ so I think I have some reason to comment about this kind of tooling.
The previous iteration got killed right when it could have started gaining traction due to Microsoft's shift to "cross platform" and PowerShell Core.
The previous iteration of the Local Configuration Manager for Linux was written Python while the Windows version was a distinct codebase entirely.
But even regardless of that I have zero confidence that Microsoft can break into this space and that the Windows culture would shift in this direction. The mentality is just not there with the typical (majority of) admins.
The only thing I've heard is if stuff along the lines of if your using puppet in 2024 your doing it wrong, but not sure what the alternative is?
Anything else mature and worth trying?
Although I guess you mean individual machine config not operations in general!
Otherwise the classics (Ansible/Puppet/Chef/Saltstack) seem to still hold their positions somewhat.
(I don't count Terraform/Pulumi/OpenTofu in this category)