At the end of the previous post I said that dependsOn only decides the order in which resources are processed. It doesn't check that the resource you depend on is actually in the desired state.

Sometimes that's not enough. You want to say "only touch this machine if it's Windows Server 2025", or "only configure the website if IIS is really installed". That's what the Microsoft.DSC/Assertion resource is for.

Note: this post is part of a bigger series on Microsoft Desired State Configuration.

• Getting started with DSC 3.0 – Part 1: What is DSC and what changed?
• Getting started with DSC 3.0 – Part 2: Managing a Windows service end to end
• Getting started with DSC 3.0 – Part 3: Capturing the current state with dsc config export
• Getting started with DSC 3.0 – Part 4: Configuring IIS with multiple resources and dependsOn
• Getting started with DSC 3.0 – Part 5: Guarding your configuration with Assertion (this post)

What is an assertion?

An assertion is a group resource. It contains a nested configuration document and runs the test operation on every resource inside it. It never changes anything.

• If every nested resource is in the desired state, the assertion passes.
• If one of them isn't, the assertion fails, and DSC doesn't invoke the resources that depend on it.

Only the resources that dependsOn the assertion are affected. The rest of the document runs as usual.

Remark: resources that only implement get, like Microsoft/OSInfo, are a natural fit for assertions. They can read the state but not change it.

A minimal example

Save this as assertion.dsc.yaml:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Demo key
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\Demo
    _exist: true
  dependsOn:
  - "[resourceId('Microsoft.DSC/Assertion', 'Windows only')]"
- name: Windows only
  type: Microsoft.DSC/Assertion
  properties:
    $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
    resources:
    - name: Operating system
      type: Microsoft/OSInfo
      properties:
        family: Windows

Two things to notice:

• The assertion has its own $schema and resources, nested inside properties
• The registry key depends on the assertion with the same resourceId() syntax we used in Part 4, with Microsoft.DSC/Assertion as the type and the instance name

Apply it:

dsc config set --file assertion.dsc.yaml

The operating system is Windows, so the assertion passes and DSC creates the key. 

Check it:

Test-Path HKCU:\Software\Demo

Let it fail

Remove the key first:

Remove-Item HKCU:\Software\Demo

Now change family: Windows to family: Linux in the document and run the same command again:

dsc config set --file assertion.dsc.yaml

The assertion fails, so DSC doesn't invoke the registry resource. Run Test-Path again and the key is not there.

Remark: the registry resource is listed before the assertion in the document. Like we saw in Part 4, the order in the document doesn't matter. The dependency does.

A more realistic case

A common use is applying settings depending on the Windows Server version. The OS version check is the gate:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Baseline tag
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKLM\SOFTWARE\Contoso
    valueName: Baseline
    valueData:
      String: Server2025
  dependsOn:
  - "[resourceId('Microsoft.DSC/Assertion', 'Server 2025 check')]"
- name: Server 2025 check
  type: Microsoft.DSC/Assertion
  properties:
    $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
    resources:
    - name: Server 2025
      type: Microsoft/OSInfo
      properties:
        version: "10.0.26100"

Add one pair like this per OS version and each machine only gets the settings that fit.

Here the version is an exact match. DSC 3.3 added version comparison to Microsoft/OSInfo, so you can assert a constraint instead. 

Remark: this one writes to HKLM, so run it from an elevated terminal.

Back to our previous example

In Part 4, dependsOn made sure IIS was installed before the web resources. But dsc config test on a clean machine could still fail, because the IIS cmdlets weren't there yet.

An assertion that checks the Web Server role fixes that. Add this to the document from Part 4:

- name: IIS is installed
  type: Microsoft.DSC/Assertion
  properties:
    $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
    resources:
    - name: Web server role
      type: PSDesiredStateConfiguration/WindowsFeature
      directives:
        requireAdapter: Microsoft.Adapter/WindowsPowerShell
      properties:
        Name: Web-Server
        Ensure: Present
  dependsOn:
  - "[resourceId('PSDesiredStateConfiguration/WindowsFeature', 'IIS')]"

And let the web resources depend on the assertion. For the application pool:

  dependsOn:
  - "[resourceId('Microsoft.DSC/Assertion', 'IIS is installed')]"

Give the website and the web application the same dependency, next to the ones they already have.

The flow is now: install IIS, check that IIS is installed, and only then configure the pool, the site and the application. If the check fails, DSC doesn't touch them.

Things to keep in mind

• An assertion only gates the resources that depend on it
• It never changes anything. If you want DSC to fix something, that's a normal resource
• The assertion itself must be a top-level instance. A resource inside a group can only depend on its neighbors in the same group, so the IIS install and the assertion stay at the top

We are not there yet. In our next and probably last post about DSC, we'll add AI into the mix. 

Gunnar Dalsnes wondered how ud0 and ud1 could have parameters if they were undefined? “Does it mean they were not completely undefined, just undocumented and not completely implemented?”

The opcodes ud0 and ud1 have no definition, but that’s not the same as being architecturally an “undefined instruction”. They live in a purgatory where they were not assigned a meaning, but were also not officially declared to be meaningless.

Originally, these byte sequences went through the instruction decoder and happened to slip through a few cracks before somebody finally noticed, “Wait a second, I don’t know how to execute this.”

You can see this when you look at the instructions that are encoded as 00001111 11111xxx, as of the Pentium III.

The byte sequences 0F FB and 0F FF had yet to be assigned a meaning. You can see how the instruction decoder could take a shortcut and say, “Well, all the instructions in this range, or at least all the ones that I care about, take an mm registers and an mm/m64 operand, so I’ll just save myself some transistors and decode all of them with two parameters (mm, mm/m64).” And then after decoding, it would use bit 3 to decide whether to set up the arithmetic unit for an add or subtract, and it would use bits 0 and 1 to decide how to subdivide the bits into saturating units.

And if you gave it a 0F FF, it would be only in that last step that the decoder would realize “Oh dear, I don’t know what to do with a bit combination of 11. I’ll raise an invalid opcode instruction.”

The invalid opcode instruction got raised after the operands were parsed.

You can see the trouble that 0F FF created when those empty slots started to get filled in by the SSE instructions.

the natural place to put the PADDQ instruction is 0F FF, but people had already been using 0F FF with the expectation that it raises an illegal instruction exception. Making it a valid instruction would break those programs, so Intel had to move PADDQ to the rather awkward location 0F D4.

Bonus chatter: Undefined instructions with parameters are actually not uncommon. For example, on AArch64, there is a range of 65,536 instructions set aside as permanently undefined, so the udf instruction takes a 16-bit immediate to specify which invalid opcode you want. The PDP-10 reserved opcode 000 as a permanently illegal instruction, and it carries a register and a memory address as parameters. (Because all PDP-10 instructions carry a register and a memory address as parameters.)

There are also so-called “unofficial opcodes” which are instructions that are not part of the instruction set architecture, but for which people reverse-engineered a consistent behavior and began to rely on it. (The 6502 processor is well-known in nerd circles for having undergone this type of analysis.) The 0F FF is one of these “unofficial opcodes” that was popular enough that Intel felt pressure to maintain backward compatibility with it, even though it was never architecturally documented or supported.

Bonus bonus chatter: It appears that the mnemonic ud1 was introduced by the nasm assembler:

* Added the following new instructions: SYSENTER, SYSEXIT, FXSAVE,
  FXRSTOR, UD1, UD2 (the latter two are two opcodes that Intel
  guarantee will never be used; one of them is documented as UD2 in
  Intel documentation, the other one just as "Undefined Opcode" --
  calling it UD1 seemed to make sense.)

It seems obvious that ud1 is also the name that Intel gave internally to that legacy instruction. Otherwise, there would be no need to call the new one ud2!

The post How can undefined opcodes <CODE>ud0</CODE> and <CODE>ud1</CODE> have parameters? How undefined were they? appeared first on The Old New Thing.

Part two of ten. Most of the surprises people hit with AI at work trace back to this one chapter. A model reads in tokens, holds only so many at once, and charges for each one.

1. What is a token?

A token is the unit of text a model reads and writes. It can be a whole word, part of a word, a chunk of a number or a punctuation mark. For common English text, a rough rule is about four characters per token.

Why it matters. Tokens are how models are measured and billed. Context limits, prices and speed are all counted in tokens. Code and SQL use more tokens than you’d guess, because a name like SalesOrderDetailID splits into several pieces.

Watch out. The four-characters rule is a rough guide for English. Other languages, numbers and code can run much higher. When the number matters, use the vendor’s own token counter.

2. Why does AI struggle to count letters?

Because a token isn’t a word. A short, common word is usually one token, while a long or rare word splits into several. The model sees a few tokens, not ten letters, which is why it can miscount the letters in strawberry.

Why it matters. The same blind spot shows up in data work. Character counts, string lengths and exact spelling checks are weak spots. Let SQL or a script do the counting, and let the model explain the result.

The follow-up. “Why does it get simple arithmetic wrong sometimes?” Numbers are split into tokens too, and the model predicts digits rather than calculating them.

3. What is a context window?

The most text a model can consider at once, measured in tokens. It holds the instructions, the conversation so far, any files you attached and the answer being written. Anything outside the window doesn’t exist for the model.

What the interviewer wants. That on most models the answer counts against the same window. A long input can leave too little room for the reply.

Watch out. Window sizes change with every model release, so don’t memorise a number. Say how you’d find it: the model’s documentation lists it.

4. Why does AI lose track of a long file?

Fitting in the window doesn’t mean every detail gets used. Models can miss details in the middle of a long input, even when all of it fits. If the file doesn’t fit at all, the tool cuts, summarises or picks parts, and it doesn’t always say which.

Why it matters. This is how you get a fix that uses a variable the AI never saw declared. It’s also how a summary skips the clause on page 40.

Watch out. “Use a tool with a bigger window” is half an answer. A bigger window holds more, and it doesn’t decide what matters. Send the part that matters plus the definitions it depends on.

5. What do temperature and top-p do?

Both control how the model picks the next token. Temperature sets how adventurous the choice is. Top-p keeps only the likeliest options whose chances add up to a set share, such as 90 percent.

Why it matters. For SQL, summaries and data extraction, you want low temperature and repeatable answers. For brainstorming names or test data, a higher setting gives more variety.

What the interviewer wants. That you match the setting to the job, and that you don’t promise identical output. Even at zero temperature, many services don’t guarantee the same answer twice.

Five minutes, any AI assistant

Ask for the same query twice. First with nothing:

Write a SQL query for our top customers.

Then in a fresh chat, with the window filled properly:

Write a SQL query for SQL Server. Table: Sales.Orders (CustomerID, OrderDate, Amount). Return the 10 customers with the highest total Amount in 2024, with their totals.

Count the guesses in the first answer: table names, column names, the date range and what “top” even means. That gap is the whole lesson about context, and it took you a minute.

Why this is worth a book

Chapter 2 has ten questions. It also covers system prompts, what happens when a conversation outgrows the window, zero-shot against few-shot prompting, prompt caching and why longer prompts cost more.

The Senior question in that chapter is the one worth rehearsing: how would you give a model a large schema or codebase without blowing the window?

100 AI Interview Questions and Answers for Data Professionals has 184 key terms alongside the hundred questions. It’s in Kindle (also on Amazon.in), paperback and audiobook.

Part three is about the square on the grid where the money goes: wrong, and sounding sure.

Out of the window is not out of scope, it is out of mind.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Tokens and the Context Window: Out of the Window, Out of Mind

You don't need a massive GPU cluster to learn how modern frontier AI works. In our new video on the freeCodeCamp.org YouTube channel, you will build, pre-train, and fine-tune a working 25-million parameter language model directly on your laptop or standard CPU.

Frontier labs train massive systems with billions of parameters, but the core architecture, math, and workflows are fundamentally identical. Scaling the architecture down to 25 million parameters with a compact byte-level vocabulary strips away expensive cloud compute costs and lets training loops run locally on your CPU in seconds. This rapid iteration allows you to directly observe how changes to data curricula, loss functions, and reward designs alter model behavior in real time.

Here are some things covered in the course:

• Modern LLM Architecture
  Learn how cutting-edge techniques work under the hood, including hybrid linear/sparse attention, Mixture of Experts (MoE), tied embedding weights, and multimodal image patch inputs.

• Pre-Training from Zero
  Watch the model start from generating random characters and learn Python syntax and structure step-by-step using cross-entropy loss.

• Post-Training with Reinforcement Learning (RL)
  Build a lightweight RL loop where the model writes code, runs against automated unit tests, and receives rewards—boosting its task success rate from 0% up to passing the majority of evaluations.

• How AI Researchers Actually Work
  Learn how to think like a modern researcher by forming testable hypotheses, tweaking temperatures and reward structures, and checking for real statistical significance across multiple seeds.

Watch the full tutorial for free on the freeCodeCamp.org YouTube channel (1-hour watch).

DevOps engineers are increasingly relying on powerful tools to streamline their workflows. Two such critical tools that have become indispensable are the Integrated Development Environment (IDE) and the Command-Line Interface (CLI). While each serves unique purposes, understanding their complementary roles in a DevOps setting is crucial for efficient software development and deployment.

The Dual Roles of IDEs and CLIs

Based on content from IBM Technology

Let’s dive into how IDEs and CLIs serve different needs but often intersect in the modern DevOps workflow. An IDE is primarily your go-to environment for writing and understanding code. It provides features that help you visualize your codebase, refactor it for better readability, and debug with ease. An IDE excels at giving developers a comprehensive view of their projects, enhancing comprehension and speed.

On the flip side, a CLI is your powerhouse for operating systems. It allows for automation of tasks using scripts, management of complex pipelines, and control of cloud deployments. Whether it’s executing test suites or managing configurations with tools like Ansible, the CLI is the choice for operations that require scriptability and remote execution capabilities.

The Core Challenge: Context Switching

Despite their benefits, working with both an IDE and a CLI involves frequent context switching, which can become a productivity bottleneck. Developers often find themselves toggling between coding, running tests, deploying builds, and managing cloud resources. Each transfer requires carrying context manually, such as remembering why a change was made or which environment needs updates next.

As Cedric Clyburn and Legare Kerrison discuss, modern development requires seamless coordination not just in coding but across repositories, tests, build pipelines, deployments, and cloud management. The friction lies not in the tools themselves but in maintaining workflow coherence across diverse environments and tasks.

Achieving Synergy: IDEs and CLIs Working in Harmony

Smoothing out the context transitions between IDEs and CLIs could substantially alleviate workflow friction. An ideal integrated system would allow:

• Multi-step Execution: Handling complex sequences of tasks routinely performed in software development.
• Coordinated Execution: Employing AI agents to perform continuous, asynchronous tasks without manual intervention.
• Automated Validation: Instantly checking and verifying changes to minimize human error and enhance reliability.
• Shell and Remote Access: Enabling comprehensive management of systems beyond local machines.

As AI development tools continue to evolve, there is a huge opportunity to address context overload by integrating these steps more fluidly. This isn’t merely about generating and writing code efficiently, but about bridging those contextual gaps that currently demand human intervention.

Conclusion: Navigating the Future of DevOps

In conclusion, the journey of a DevOps engineer involves leveraging both IDEs for code comprehension and CLIs for system execution. While current workflows demand a balance between these tools, the real focus should be on enhancing cross-tool compatibility to reduce context overload. Innovation in this area could redefine productivity metrics in DevOps, enabling engineers to focus more on creative problem-solving and less on routine handovers.

In this pursuit, as AI continues to empower these tools, engineers might finally strike that long-sought balance, rendering the complex dance between IDEs and CLIs an orchestrated masterpiece.

The first time I saw how the Amazon hiring system worked from the inside, I remember thinking two things: First, this is a serious company. They are treating hiring as a real leadership mechanism, not an HR workflow. Second, holy crap, this is still mostly humans guessing about humans.

Both things were true.

That is the tension at the center of hiring. The stakes are enormous, and the evidence is weak.

A bad strategy can be fixed. A missed date can be recovered. The process can be repaired. But a bad hire joins, and they consume management energy, screw up the culture, lower standards, and create drag where everyone routes around them.

Excellence in organizations starts and ends with hiring. Hiring has a disproportionate impact on a company’s culture. But the truth is not that hiring matters; everyone says hiring matters.

The truth is that most ways we determine whether to hire someone are full of noise, subjectivity, and bias. I say most, because there’s at least one mechanism that has been proven to result in excellent hires: well-run internship programs. Unfortunately, few organizations can pay every potential employee to participate in a six-month probation period before offering a full-time position.

Hiring is a high-consequence prediction about future performance made from incomplete, biased, and subjective evidence.

Signal to Noise Ratio

In many fields, the ratio of signal (good data) to noise (bad data) is critical for making decisions. A radio transmission with too much noise (e.g., static) and not enough signal makes what’s transmitted indecipherable. Often the noise comes from levels of indirection, or proxies.

SNR is a good mental model for thinking about hiring. A leader’s job is to squelch the noise and amplify the signal.

• A resume is a proxy.
• An interview is a proxy.
• A take-home exercise is a proxy.
• A reference is a proxy.
• A credential is a proxy.
• Years of experience are a proxy.

There is some signal in these proxies, but as proxies, they are rife with noise. The real signal is what it will be like to have this person working inside your organization six months from now. Unfortunately, we do not get to observe that during an interview loop. We get fragments, potential lies, and impressions.

Becoming excellent at hiring means becoming excellent at making the signals better.

Steve Yegge, who was a Bar Raiser at Amazon and later a technical leader at Google, recently wrote a piece called The Last Technical Interview. I do not agree with everything in it, but I agree with a lot of the diagnosis. His gist is this: most interview systems collect too little signal, then treat the resulting opinions with too much confidence. Yep.

He tells a story from Google where a hiring committee reviewed anonymized interview packets as a calibration exercise. The committee rejected many of them. The reveal was that they had rejected their own packets from when they interviewed at Google!

That should make every interviewer squirm.

The lesson is not that hiring is hopeless. The lesson is that interviewer confidence is not evidence. A strong opinion about a candidate is useful only when it is attached to specific observations. With no observation, there is no signal, and with no signal, there is no decision. No soup for you.

Get the Bias Out

Most forms of interviews are full of bias. Bias does not require bad intent. That is why it is so dangerous.

Good people can be biased. Smart people can be biased. Right-minded people who sincerely care about fairness can be biased. In fact, the most dangerous bias often comes from people who believe they are being objective.

Interviewers like candidates who remind them of themselves. They like familiar schools, familiar hobbies, familiar vocabulary, familiar communication styles, familiar jokes, and familiar ways of solving problems. They reward polish. They overvalue confidence. They confuse fluency with understanding. They mistake comfort for fit.

Then they call it judgment.

Leaders hiring other leaders must minimize bias and enable real judgment based on objective measures. Great leaders focus on making subjectivity inspectable. Behavioral questions are one way to do that, because they ask for what a candidate actually did instead of what they think or would do. I wrote about why in Interviews are better with Behavioral Questions, and the questions I use, with example hire and no-hire answers, are in my Behavioral Interview Question Bank app.

Like most aspects of leadership, becoming excellent at hiring is about mastering skills: crafting job descriptions (and onboarding docs), running the funnel, interviewing, running loops, running debriefs, closing candidates, onboarding new hires, and building hiring systems.