If you've worked with PowerShell DSC before, you probably remember writing a Configuration block, generating a MOF file and hoping the Local Configuration Manager did what you expected. DSC 3.0 throws most of that away and provides a more modern incarnation of infrastructure-as-code. Let me explain what it is, and what makes 3.0 different. What is DSC? Desired State Configuration is a declarative way to manage a system. You describe what the system should look like, not how to get there. DSC figures out the rest. It is kind of the first incarnation of Infrastructure as Code. Three concepts are enough to understand DSC: Configuration document: a file that describes the desired state Resource: the piece that knows how to read and change one specific thing (a registry key, a service, a package, ...) Operations: what you can do with a resource: get , test , set and export So the question becomes: if the concepts stays the same, what changed in 3.0?...
Agents write most of my code these days. That leaves me with this question: what do I do with all this free time? I considered learning a new framework, but that sounds suspiciously like work. Luckily, the VS Code team has a better idea. They gave me something to take care of. What is the VS Code pet? The pet is an interactive character that sits above the chat input box. It reacts to chat activity and to whatever you do to it. So while the agent works, the pet watches. Before, I was the only one staring at the progress indicator while pretending to supervise. Now I have company. Remark: The pet is marked as experimental, so it might change or be removed. Don't get too attached. (I got attached within five minutes.) Adopting your pet Type /vscode-pet in the chat input to show or hide it. In the new-session view of the Agents window, you can also right-click outside the input box and select Pet (/vscode-pet) . Show or hide. That's the entire commitment. As fa...