49
Total Pages
28
Linux-Friendly Pages
21
Pages with Bias
42.9%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues (39)

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a subtle Windows bias by mentioning Windows-specific features (such as the Windows certificate store and TPMs being standard on Windows devices) without providing equivalent Linux examples or guidance. Windows tools and patterns are referenced, but Linux alternatives are not discussed, and there are no Linux-specific instructions or examples for certificate or TPM management.
Recommendations:
  • When referencing the Windows certificate store, also mention common Linux certificate storage locations (e.g., /etc/ssl/certs, or using OpenSSL).
  • When discussing TPM support, note that TPMs are also supported on Linux and provide links or examples for Linux TPM tools (such as tpm2-tools or trousers).
  • Include examples or references for certificate installation and management on Linux-based devices, not just Windows.
  • Where software tools are mentioned for certificate installation, provide cross-platform or Linux-specific tool suggestions (e.g., OpenSSL, tpm2-tools, or shell scripts).
  • Explicitly state that the guidance applies to both Windows and Linux devices, and call out any OS-specific differences or considerations.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides only C# code samples and file storage patterns that implicitly assume a Windows or .NET environment, with no mention of Linux-specific considerations, tools, or code examples. There are no references to Linux shell commands, Linux file paths, or cross-platform SDK usage. The use of .NET APIs for file access and environment variables is not explained for Linux users, and there is no guidance on adapting the examples for Linux-based IoT devices.
Recommendations:
  • Provide equivalent code samples in a cross-platform language such as Python or C, or explicitly show how the C#/.NET code can be run on Linux (e.g., using .NET Core on Linux).
  • Include Linux-specific instructions for setting environment variables and file paths (e.g., using $HOME or /var/lib for data directories).
  • Mention and demonstrate how to run the provided code on both Windows and Linux, including any prerequisites (such as installing .NET on Linux).
  • Add shell script (Bash) examples for provisioning and monitoring tasks where appropriate.
  • Clarify that the patterns and APIs used are cross-platform, or provide alternatives for Linux-only environments.
  • Reference Linux-native tools (such as systemd for background work, or Linux logging mechanisms) where relevant.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools Powershell Heavy
Summary:
The documentation demonstrates a clear Windows bias: it assumes a Windows development environment by default, provides detailed steps and tooling instructions for Windows (e.g., Visual Studio, .NET Core SDK, Simulator.exe), and omits or relegates Linux/macOS instructions to external links. There are no explicit Linux or macOS command-line examples, and Windows-specific tools and patterns (like Visual Studio, Simulator.exe, and Windows command prompts) are referenced throughout, often without Linux equivalents or alternatives.
Recommendations:
  • Provide explicit Linux and macOS instructions and examples alongside Windows steps, not just as external links.
  • Include Linux/macOS command-line examples (e.g., using bash, make, gcc, or cross-platform build tools) wherever Windows commands or tools are shown.
  • Mention and demonstrate Linux-compatible TPM simulators and how to run them (e.g., using tpm2-software or other open-source TPM simulators).
  • Offer guidance for installing dependencies and building/running samples on Linux/macOS (e.g., using gcc/clang, CMake, Maven, npm, etc. on those platforms).
  • Avoid assuming Visual Studio or Windows-specific tools are required; clarify when cross-platform alternatives are available.
  • Where possible, use cross-platform language and tools (e.g., 'terminal' instead of 'command prompt', 'editor of your choice' instead of 'Visual Studio').
  • Ensure all code snippets and instructions are tested and validated on Linux/macOS as well as Windows.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation generally aims for cross-platform parity and uses cURL, Bash, and Python, which are available on both Linux and Windows. However, there is a subtle Windows bias in the way platform-specific instructions are ordered and in the explicit recommendation of Git Bash for Windows users, while Linux/WSL users are simply told to use Bash. Windows is mentioned first in several places, and the only Windows-specific tool mentioned is Git Bash, with no mention of native Windows command prompts or PowerShell. There are no PowerShell-specific examples, and Linux is not omitted, but the documentation assumes Windows users need extra tooling (Git Bash) to follow along, which may not be necessary for all users.
Recommendations:
  • Alternate the order of platform mentions (sometimes Linux/WSL first, sometimes Windows) to avoid always putting Windows first.
  • Explicitly mention that Bash is available natively on Linux and WSL, and that Windows users can use Git Bash, WSL, or other Bash environments (such as Cygwin or Windows Terminal with WSL).
  • Consider providing a brief note for Windows users who may prefer PowerShell or Command Prompt, clarifying that the examples use Bash syntax and recommending Bash-compatible environments for all platforms.
  • Where possible, avoid assuming Windows users require extra tooling; clarify that Bash is the required shell environment, and list options for obtaining it on Windows.
  • Ensure that any references to tools or environments are balanced; if Git Bash is mentioned for Windows, mention native Bash for Linux/WSL with equal prominence.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias in several areas: Windows-based tools and workflows (Visual Studio, PowerShell, Windows command prompt) are presented as defaults or with more detailed instructions, while Linux alternatives are either referenced externally, presented after Windows, or lack parity in detail. Some sections (notably for C/C#) assume a Windows environment and only briefly mention Linux, often redirecting to external documentation. Windows-specific tools (e.g., Visual Studio, PowerShell) are emphasized, and Linux instructions are sometimes missing or less detailed.
Recommendations:
  • Provide Linux and macOS instructions alongside Windows in all language pivots, not just as external references.
  • Avoid language such as 'This tutorial is oriented toward a Windows-based workstation' or, if necessary, ensure equivalent Linux/macOS guidance is present in the same document.
  • For C/C++ development, include explicit Linux build instructions (e.g., using gcc/clang, make, or CMake on Linux) within the main flow, not just as a link.
  • For device key derivation, ensure Linux and macOS examples are as prominent and detailed as Windows/PowerShell ones.
  • Where Windows tools (Visual Studio, PowerShell) are mentioned, provide direct Linux/macOS alternatives (e.g., GCC/Clang, shell scripts) in the same section.
  • Use neutral language in prerequisites and setup steps (e.g., 'On your development machine' instead of 'on your Windows-based machine'), and clarify cross-platform compatibility.
  • Ensure all code samples and command-line instructions are provided for both Windows (cmd/PowerShell) and Linux/macOS (bash/zsh), with clear tabbed or side-by-side presentation.
  • Where possible, avoid requiring Windows-only tools for cross-platform SDKs, or provide equivalent open-source alternatives.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a clear Windows bias: instructions and examples are consistently written for Windows environments, with explicit references to Windows tools (Visual Studio, CMD, Git Bash, etc.) and Windows-specific workflows. Linux and macOS alternatives are either mentioned as afterthoughts or deferred to external documentation, and there are no concrete, step-by-step Linux shell examples. Environment setup, build, and run instructions are all Windows-centric, and the use of Windows command prompts and tools is pervasive.
Recommendations:
  • Provide parallel Linux (and macOS) instructions alongside Windows steps, including shell commands (bash) for cloning, building, and running samples.
  • List Linux prerequisites (e.g., gcc, make, cmake, mono/dotnet, openjdk, python3, pip, etc.) explicitly in the prerequisites section, not just as a link to external documentation.
  • For each programming language, include Linux-specific build and run commands (e.g., using make/gcc for C, dotnet on Linux, npm/node, python3, mvn/java) and clarify any differences in environment variable syntax (export vs set).
  • When referencing tools like Visual Studio, also mention and provide instructions for Linux alternatives (e.g., gcc/g++, VS Code, CLion, etc.).
  • Avoid phrases like 'on your Windows-based machine' unless the instructions are truly Windows-only; otherwise, use neutral language or provide both OS options.
  • Include screenshots or terminal output from Linux environments where possible, not just Windows.
  • If certain steps are only possible on Windows, clearly state this and provide workarounds or alternatives for Linux/macOS users.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools Powershell Heavy
Summary:
The documentation demonstrates a clear Windows bias: it is explicitly written for a Windows environment, with Windows-specific tools (Visual Studio, Windows command prompt, Git Bash for Windows, winpty), and Windows instructions always presented first or exclusively. Linux and macOS are only referenced as alternatives, often via links to external SDK documentation, and not given equal, inline treatment. In many sections, only Windows command-line examples are shown, or the Linux equivalents are relegated to secondary tabs or notes. Some steps (e.g., opening Visual Studio, using Windows command prompt) have no direct Linux equivalent described, and the overall workflow assumes a Windows user.
Recommendations:
  • Provide Linux (and macOS) instructions and examples inline, not just as links or secondary tabs. For each step, show both Windows and Linux commands side-by-side.
  • Avoid assuming the use of Windows-specific tools (e.g., Visual Studio) as the default; instead, offer cross-platform alternatives (e.g., GCC/Clang, VS Code, or JetBrains IDEs).
  • Where Git Bash or winpty is used for Windows, clarify the native Linux equivalent (plain Bash, no winpty needed).
  • For environment setup, give equal detail for Linux (package managers, build tools, etc.), not just refer to SDK docs.
  • In all code and command examples, present both Windows and Linux syntax, and avoid Windows-only command prompt instructions.
  • Consider restructuring the quickstart to have parallel sections for Windows and Linux/macOS, or use clear pivots/tabs for each OS, ensuring parity in depth and clarity.

Page-Level Analysis

Windows First Powershell Heavy
Summary:
The documentation provides example code for generating derived device keys using Azure CLI, Windows PowerShell, Linux (openssl), and C#. However, in the tabbed example section, the Windows/PowerShell example is presented before the Linux example, and the PowerShell script is more detailed and user-friendly compared to the Linux/openssl example. There is a slight 'windows_first' ordering and a more comprehensive PowerShell example, which may indicate a subtle Windows bias.
Recommendations:
  • Alternate the order of Windows and Linux examples in tabbed sections, or present Linux examples first in some cases to balance exposure.
  • Ensure that Linux/bash examples are as detailed and user-friendly as the PowerShell examples, including clear variable assignments and output formatting.
  • Where possible, provide cross-platform scripts (e.g., Python) that work equally well on Windows and Linux.
  • Explicitly state that all methods are equally supported and tested on both Windows and Linux platforms.
  • Consider including a table summarizing all available methods (CLI, PowerShell, Bash, C#, etc.) with platform compatibility.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates subtle Windows bias by referencing Windows-specific features (such as the Windows certificate store) and highlighting TPM support as standard on Windows devices. There are no explicit Linux or cross-platform examples, nor are Linux equivalents (e.g., Linux certificate stores, TPM support on Linux) mentioned. The only OS-specific references are to Windows, and no command-line or tooling examples are provided for Linux environments.
Recommendations:
  • When mentioning the Windows certificate store, also mention Linux equivalents such as /etc/ssl/certs, PKCS#11 modules, or common Linux certificate management practices.
  • Note that TPM support is available on many Linux distributions, and reference relevant Linux TPM tools (e.g., tpm2-tools) and libraries.
  • Provide examples or references for certificate installation and management on both Windows and Linux platforms.
  • When discussing device manufacturing and provisioning, include OS-agnostic language or explicitly address both Windows and Linux workflows.
  • If mentioning software tools for certificate installation or quality checks, suggest or link to cross-platform or Linux-compatible tools.
  • Consider adding a section or callout that addresses cross-platform considerations and best practices for both Windows and Linux device manufacturers.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides a conceptual overview of TPM attestation with Azure DPS but does not include any concrete examples or tooling references for either Windows or Linux. However, it mentions that the steps for taking ownership of a TPM vary by manufacturer, tools, and operating system, but does not provide any examples or guidance for Linux users, nor does it mention any Linux-specific tools or commands. This omission may leave Linux users at a disadvantage compared to Windows users, especially since TPM management is often platform-specific.
Recommendations:
  • Add explicit examples for both Windows and Linux on how to take ownership of a TPM, including references to common tools (e.g., Windows TPM Management Console, Linux tpm2-tools).
  • Mention popular Linux TPM utilities such as tpm2-tools and provide sample commands for reading EK_pub or taking ownership.
  • Include links to official documentation or guides for TPM management on both Windows and Linux platforms.
  • Ensure that any future procedural or code examples are provided for both operating systems to maintain parity.

Page-Level Analysis

Windows First Powershell Heavy
Summary:
The documentation references both PowerShell (Windows) and Bash (Linux) scripts for certificate operations, but PowerShell is mentioned first, and there is a slight emphasis on Windows tooling. There are no explicit, step-by-step Linux command examples, and the mention of PowerShell before Bash may subtly prioritize Windows users. However, Linux is acknowledged and supported via Bash scripts.
Recommendations:
  • Alternate the order of mentioning PowerShell and Bash scripts, or mention Bash first in some sections to avoid Windows-first bias.
  • Provide explicit, step-by-step Linux (Bash/OpenSSL) command examples alongside any Windows/PowerShell examples.
  • Clarify that all steps and tools are equally supported on Linux and Windows, and highlight any platform-specific prerequisites (e.g., OpenSSL installation).
  • Consider adding a dedicated section or callout for Linux users to ensure parity and visibility.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates mild Windows bias by consistently mentioning Windows and Windows-specific tools (notably Git Bash) before Linux equivalents, and by providing more detailed instructions for Windows users regarding prerequisites and environment setup. However, all command-line examples use cross-platform tools (cURL, Python, Bash), and Linux/WSL usage is acknowledged throughout. There are no PowerShell-only examples or missing Linux examples.
Recommendations:
  • When listing environments, alternate the order or mention Linux/WSL first in some sections to avoid always prioritizing Windows.
  • Provide equal detail for Linux/WSL setup as is given for Windows (e.g., mention that Bash is the default shell on most Linux distributions, and clarify how to install required tools on Linux).
  • Clarify that Git Bash is only needed on Windows, and that native Bash is available on Linux/WSL, to avoid implying that Git Bash is a universal requirement.
  • Where possible, include explicit Linux package installation commands for prerequisites (e.g., how to install Python, curl, openssl on Ubuntu/Debian/CentOS).
  • Consider a table or section summarizing environment setup for both Windows and Linux/WSL, making parity and differences clear.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools Powershell Heavy
Summary:
The documentation page exhibits a strong Windows bias. It consistently assumes a Windows development environment, especially in the C and C# sections, with prerequisites and instructions focused on Windows-only tools (e.g., Visual Studio, .NET Core on Windows, Simulator.exe). Linux and macOS alternatives are only briefly referenced via external links, and there are no inline, step-by-step instructions or examples for those platforms. The use of Windows command prompts and references to Windows-specific executables further reinforce this bias. There is also a lack of parity in providing Linux/macOS-specific build and run instructions, and troubleshooting tips are Windows-centric.
Recommendations:
  • Provide explicit, inline instructions for Linux and macOS environments for each supported language, not just links to external SDK docs.
  • Include Linux/macOS equivalents for all Windows-specific tools (e.g., suggest GCC/Clang and CMake for C, Mono or .NET Core for C#, and how to run the TPM simulator on non-Windows platforms).
  • Show examples of building and running the TPM simulator and SDK samples on Linux/macOS, including terminal commands and any required dependencies.
  • Avoid assuming Visual Studio or Windows command prompts as the default; offer cross-platform alternatives (e.g., VS Code, JetBrains Rider, or CLI-based workflows).
  • List prerequisites for all major platforms in the main documentation, not just in external links.
  • Where troubleshooting is discussed, include common issues and solutions for Linux/macOS users.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page provides instructions primarily through the Azure portal and mentions Azure CLI and PowerShell for managing enrollments when public network access is disabled. However, it does not provide any explicit Linux-specific examples or mention Linux tools, and PowerShell is mentioned alongside Azure CLI without clarifying cross-platform support. There are no command-line examples shown, and the documentation implicitly assumes familiarity with Windows-centric tools and workflows.
Recommendations:
  • Explicitly mention that Azure CLI is cross-platform and provide example commands for both Windows (PowerShell/CMD) and Linux (Bash).
  • Include sample CLI commands for managing enrollments and network access, demonstrating usage in both Windows and Linux shells.
  • Clarify that PowerShell Core is available on Linux if PowerShell examples are provided, or prioritize Azure CLI examples since it is cross-platform.
  • Add a section or note highlighting Linux compatibility and any platform-specific considerations.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias in several ways: Windows is explicitly referenced as the development environment in multiple places, with instructions such as 'Open a Windows command prompt' and references to Windows-based machines. While some steps mention that they work on both Windows and Linux, the article consistently uses Windows as the example environment, and Linux-specific instructions or clarifications are missing or minimal. Some tooling and scripting examples (such as using Git Bash or sed) are presented, but the overall flow and sample commands are Windows-centric, and Linux users are left to infer how to adapt steps. There are also references to Windows tools and patterns (e.g., registry for secrets, Windows command prompt), and Linux equivalents are not given or are only mentioned as an afterthought.
Recommendations:
  • Provide explicit Linux and macOS instructions and command-line examples alongside Windows ones, especially for steps like creating projects, running commands, and editing files.
  • Avoid phrases like 'Open a Windows command prompt'—instead, use neutral language such as 'Open a terminal' and specify differences in sub-sections if needed.
  • When referencing tools (e.g., storing secrets in the registry), mention Linux/macOS equivalents (such as environment variables or configuration files).
  • Ensure that all code and command-line snippets are provided in both Windows (cmd/PowerShell) and Linux/macOS (bash/sh) formats where syntax differs.
  • For certificate creation and manipulation, provide clear instructions for both Windows and Linux users, including any OS-specific prerequisites or tool usage.
  • Where screenshots or UI steps are shown, clarify any OS-specific differences or note that the portal experience is OS-agnostic.
  • Review all references to 'Windows-based machine' and replace with 'development machine' or similar neutral terms, specifying OS only where necessary.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a mild Windows bias by consistently mentioning Windows (and Git Bash) before Linux/WSL in instructions, and by focusing on Windows-specific tooling (Git Bash, winpty) for running commands on Windows. While Linux/WSL is supported and examples are provided, Windows environments and workarounds are prioritized or described first, and the documentation assumes the use of Git Bash rather than native Windows terminals or PowerShell.
Recommendations:
  • Alternate the order of platform instructions so that Linux/WSL is sometimes presented first, or present both platforms equally (e.g., side-by-side tabs).
  • Explicitly mention native Windows terminal or PowerShell as alternatives to Git Bash, or provide PowerShell-native command examples where appropriate.
  • Clarify that 'winpty' is only required for Git Bash, and suggest native alternatives for users running in other Windows shells.
  • Ensure that all prerequisite and command instructions are equally detailed for both Linux and Windows, and avoid assuming that Windows users will always use Git Bash.
  • Consider adding a table or section summarizing all supported environments and the recommended shell/tools for each, to avoid implicit prioritization.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation consistently assumes or prioritizes Windows as the development environment, especially in the C# and Java sections. Instructions such as 'Open a Windows command prompt' are given without Linux equivalents, and there is no mention of Linux-specific steps or terminal usage. While some commands (like dotnet and npm) are cross-platform, the narrative and explicit instructions are Windows-centric. There are no PowerShell-specific commands, but the use of 'Windows command prompt' and lack of Linux terminal references indicate a Windows-first bias. Linux users are left to infer how to adapt the steps.
Recommendations:
  • Explicitly state that all steps are cross-platform where applicable, and provide parallel instructions for Linux (e.g., 'Open a terminal window' instead of 'Open a Windows command prompt').
  • Where commands differ between Windows and Linux (such as path separators or shell commands), provide both versions or use cross-platform syntax.
  • Include screenshots or notes for Linux environments, especially when referencing file paths or environment variables.
  • Avoid language that assumes Windows as the default (e.g., 'on your Windows-based machine'); instead, use 'on your development machine' and clarify OS-specific differences as needed.
  • For Java and C# sections, mention that the SDKs and tools work on Linux and provide any necessary installation or usage notes for Linux users.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a clear Windows bias. It repeatedly refers to 'your Windows machine' and assumes a Windows-based development environment by default. Instructions and examples are consistently given for Windows first, with Linux or macOS alternatives only mentioned as afterthoughts or via external links. Tooling and workflow references (e.g., Visual Studio, Visual Studio Command Prompt, .cmd scripts, use of 'set' for environment variables, and Windows-style paths) are Windows-centric. There is a lack of explicit, in-place Linux command examples (e.g., for environment variables, building, or running samples), and Linux users are often redirected to other documentation rather than being served directly in the main flow.
Recommendations:
  • Provide parallel Linux/macOS instructions and examples alongside Windows instructions, not just as external links or afterthoughts.
  • Include Linux/macOS-specific commands for setting environment variables (e.g., 'export' instead of 'set'), running builds, and executing samples.
  • Mention cross-platform tools (e.g., VS Code, gcc/clang, make) as alternatives to Windows-only tools like Visual Studio.
  • Use neutral language such as 'your development machine' instead of 'your Windows machine' unless the step is truly Windows-specific.
  • Show file paths and command-line examples in both Windows and Unix formats where appropriate.
  • Where possible, avoid referencing Windows-only shells (e.g., 'command prompt', 'Git CMD') as the default; instead, mention Bash or terminal generically.
  • Ensure that all code and workflow steps are validated and documented for Linux/macOS environments, not just Windows.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias, with Windows tools and workflows (Visual Studio, PowerShell, Windows command prompt) presented as the default or primary approach. Linux alternatives are mentioned but often as secondary, less detailed, or referenced externally. Some programming language setup instructions are Windows-centric, and Linux-specific guidance is sometimes relegated to links or brief notes. PowerShell and Windows command prompt are used for examples, while Linux equivalents are less prominent or missing in some sections.
Recommendations:
  • Present Linux and Windows instructions in parallel, giving equal prominence to both platforms in all sections.
  • For each command-line example (e.g., cloning repos, setting environment variables), provide both Windows (cmd/PowerShell) and Linux (bash) syntax side by side.
  • In the prerequisites and setup sections, explicitly list Linux (and macOS, if supported) requirements and installation steps, not just as links but with inline instructions.
  • Avoid language like 'This tutorial is oriented toward a Windows-based workstation'—instead, state that the tutorial supports both Windows and Linux, and structure content accordingly.
  • For programming language pivots, ensure Linux build/run instructions are as detailed as Windows ones (e.g., for C, include gcc/make/CMake on Linux, not just Visual Studio).
  • Where PowerShell is used for key derivation, provide a bash/openssl equivalent with equal detail and explanation.
  • Ensure all screenshots and UI walkthroughs are platform-neutral or provide Linux equivalents where applicable.
  • Review all sections for implicit Windows assumptions (e.g., file paths, tool names) and provide cross-platform alternatives.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a strong Windows bias. All code and command-line examples are presented using Windows tools (cmd, Visual Studio, Windows command prompt), with explicit instructions for Windows environments. Linux and macOS users are repeatedly referred to external SDK documentation, rather than being provided with equivalent, inline instructions or examples. Windows-specific tools (Visual Studio, certmgr.msc, .pfx files, etc.) are mentioned and used exclusively or before any mention of cross-platform or Linux alternatives. In several sections, only Windows command-line syntax is shown, and Linux equivalents are omitted.
Recommendations:
  • For each programming language, provide explicit, step-by-step Linux (and macOS, if possible) instructions and examples alongside the Windows ones, rather than referring users to external SDK documentation.
  • Include Linux/macOS command-line equivalents (e.g., bash, sh) for all git, build, and environment variable commands, not just Windows cmd.
  • When referencing tools like Visual Studio or certmgr.msc, also mention and provide instructions for common Linux alternatives (e.g., gcc/clang, OpenSSL, update-ca-certificates, etc.).
  • For certificate management, show how to import certificates into Linux trust stores (e.g., using update-ca-certificates or manual copying to /usr/local/share/ca-certificates) as well as Windows certificate store.
  • For .NET, Node.js, Python, and Java, provide sample commands for running and building on Linux (e.g., dotnet, npm, python, mvn) and note any OS-specific differences.
  • Where environment variables are set (e.g., set VAR=val in cmd), also show the export VAR=val syntax for bash.
  • Add a 'Platform differences' or 'Linux/macOS instructions' callout in each major section, especially where Windows-specific steps are described.
  • Ensure all file paths and command syntax are shown in both Windows (\) and Unix (/) formats.

Page-Level Analysis

Windows First
Summary:
The documentation provides both Bash (Linux/macOS) and Azure PowerShell (Windows) examples for verifying the results, but the Bash example is presented first. There are no exclusive references to Windows tools or patterns, and Linux examples are not missing. No evidence of PowerShell-heavy bias or exclusive use of Windows tools was found.
Recommendations:
  • Maintain parity by continuing to provide both Bash and PowerShell examples for all command-line steps.
  • Explicitly mention that Bash commands work on Linux and macOS, and that PowerShell is for Windows, to help users choose the right tab.
  • Consider including a note about using the Azure CLI in Windows environments (e.g., via WSL or native CLI) to further support cross-platform users.
  • Ensure that any referenced scripts or code samples are tested on both Linux and Windows environments.

Page-Level Analysis

Windows First Powershell Heavy
Summary:
The documentation provides cross-platform examples for generating derived device keys (Azure CLI, Windows/PowerShell, Linux/openssl, C#), but the Windows/PowerShell example is presented before the Linux/openssl example. Additionally, the Windows/PowerShell example is more detailed and uses native Windows tools, which may give the impression of a slight preference for Windows environments.
Recommendations:
  • Present Linux and Windows examples in parallel or alternate their order in different sections to avoid always listing Windows first.
  • Ensure that Linux examples are as detailed and accessible as their Windows counterparts.
  • Explicitly state at the beginning of the example section that all major platforms are supported and that equivalent tooling is available.
  • Consider including a Bash example for macOS, or clarify that the Linux example applies to macOS as well.
  • Where possible, provide platform-agnostic code (e.g., Python) to further improve parity.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a subtle Windows bias by referencing Windows-specific features and tools before or instead of their Linux equivalents. For example, the Windows certificate store is mentioned as a storage location for certificates, but no Linux alternatives (such as OpenSSL, PKCS#11, or Linux certificate stores) are discussed. TPM support is highlighted as being standard on Windows devices, with no mention of Linux TPM support or tooling. There are no concrete examples or guidance for Linux-based manufacturing environments, and no Linux command-line or tool references are provided.
Recommendations:
  • When mentioning certificate storage, include Linux equivalents such as OpenSSL, PKCS#11 modules, or Linux system certificate stores alongside the Windows certificate store.
  • When discussing TPM integration, note that Linux has robust TPM 2.0 support (e.g., tpm2-tools, tpm2-tss) and provide links or references to relevant Linux documentation.
  • Provide example workflows or tool recommendations for both Windows and Linux environments, especially for certificate installation and TPM management.
  • Avoid phrasing that implies Windows is the default or only supported platform (e.g., 'TPMs are included as standard hardware on many Windows devices') and instead acknowledge cross-platform support.
  • Add Linux-specific guidance or examples wherever Windows-specific tools or features are mentioned.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides a conceptual overview of TPM attestation with Azure DPS but does not include any platform-specific examples or instructions. However, it references 'the set of TPM tools being used, and the device operating system' without giving concrete examples for either Windows or Linux. There is a lack of practical guidance or examples for Linux users, which may leave them underserved compared to Windows users if other documentation pages provide Windows-specific instructions.
Recommendations:
  • Add explicit examples or references for both Windows and Linux TPM tooling (e.g., tpm2-tools for Linux, Windows built-in TPM management tools).
  • Include sample commands or workflows for taking ownership of a TPM and extracting EK_pub/SRK_pub on both Windows (e.g., using PowerShell or TPM.msc) and Linux (e.g., using tpm2_getpubek, tpm2_createprimary, etc.).
  • Provide links to platform-specific TPM documentation or guides for both operating systems.
  • Ensure that any future updates or related articles maintain parity by presenting Linux and Windows instructions side-by-side.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias throughout. Windows-specific tools (Visual Studio, PowerShell) are mentioned before or instead of Linux equivalents, and setup instructions often assume a Windows environment. While some Linux alternatives are referenced, they are often secondary or require following external links. Several code and command examples default to Windows command prompts or tools, with Linux instructions either missing, less detailed, or presented after Windows instructions.
Recommendations:
  • Present Linux and Windows instructions in parallel, giving equal prominence to both platforms.
  • For each prerequisite or setup step, provide explicit Linux (and macOS, if relevant) instructions alongside Windows instructions, rather than referring users to external documentation.
  • When mentioning tools like Visual Studio, also mention common Linux IDEs or build systems (e.g., GCC, Clang, VS Code) and provide equivalent setup steps.
  • For command-line examples, show both Windows (cmd/PowerShell) and Linux (bash) commands side by side, using tabbed or clearly separated sections.
  • Avoid language that frames Windows as the default or primary environment (e.g., 'This tutorial is oriented toward a Windows-based workstation'), or balance it with an explicit statement of Linux parity.
  • Ensure all code samples and build/run instructions are fully documented for both Windows and Linux, including environment variable setup, build commands, and troubleshooting tips.
  • Where possible, use cross-platform tools (e.g., Azure CLI, Git Bash, VS Code) and highlight their use to minimize OS-specific dependencies.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides command-line examples exclusively using the Azure CLI, which is cross-platform, and does not mention or show any Windows-specific tools (such as PowerShell or CMD), nor does it reference Windows-only patterns. However, it also does not provide any Linux- or macOS-specific examples, shell syntax, or notes about platform-specific considerations. Thus, while not overtly Windows-biased, the documentation lacks explicit Linux parity in examples or guidance.
Recommendations:
  • Explicitly state that the Azure CLI commands work on Windows, Linux, and macOS, to reassure non-Windows users.
  • Where relevant, provide example shell commands using both Bash (for Linux/macOS) and PowerShell (for Windows), especially if there are differences in quoting, environment variables, or command syntax.
  • Mention any platform-specific prerequisites or considerations (e.g., installation instructions for Azure CLI on Linux).
  • Add a note or section clarifying that the documented procedures are cross-platform, and link to official Azure CLI installation guides for all supported operating systems.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation generally aims for cross-platform parity by using cURL, Bash, and Python examples, and explicitly mentions both Linux and Windows environments. However, there is a subtle Windows bias: Windows is mentioned first in environment setup instructions, and Windows-specific tooling (Git Bash) is emphasized for Windows users, with no mention of native Windows command prompts or PowerShell. There are no PowerShell-specific examples, but the guidance for Windows users is to use Git Bash, a third-party tool, rather than native Windows shells. Linux/WSL users are simply told to use Bash, which is native. There are no missing Linux examples or exclusive use of Windows tools, but the documentation does not mention or provide parity for native Windows shells (e.g., Command Prompt or PowerShell), which could be seen as a gap.
Recommendations:
  • Explicitly provide instructions or notes for users who may want to use native Windows shells (Command Prompt or PowerShell), or clarify why Git Bash is preferred.
  • Where possible, include PowerShell or Command Prompt equivalents for Bash/cURL commands, or link to documentation that explains how to run these commands in those environments.
  • Consider mentioning Linux/WSL first in environment setup sections, or alternate the order to avoid the appearance of Windows-first bias.
  • If recommending third-party tools (like Git Bash) for Windows, provide similar recommendations for Linux users if any non-native tools are required, or clarify that Bash is native on Linux.
  • Add a brief section explaining cross-platform considerations, including any limitations or differences when running commands on Windows vs. Linux.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation page references both Azure CLI and PowerShell when discussing connectivity issues and firewall rules, but does not mention or provide examples for Linux-native tools or workflows. PowerShell is called out alongside Azure CLI, which can be used on both Windows and Linux, but the explicit mention of PowerShell (a Windows-first tool) without mentioning Bash or other Linux shells suggests a Windows-centric bias. There are no Linux-specific examples or references to Linux firewall tools (e.g., iptables, ufw), and the guidance assumes familiarity with Windows tools and patterns.
Recommendations:
  • Include explicit references to Linux-native tools and workflows (e.g., Bash, iptables, ufw) alongside PowerShell and Azure CLI.
  • When mentioning PowerShell, also mention Bash or other common Linux shells to ensure parity.
  • Provide example commands for both Windows (PowerShell) and Linux (Bash) environments when discussing firewall configuration or automation.
  • Clarify that Azure CLI is cross-platform and provide usage examples in both Windows and Linux contexts.
  • Avoid listing PowerShell before Linux alternatives unless there is a clear reason to do so.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page provides instructions primarily through the Azure portal UI and mentions PowerShell as a management option, but does not provide any command-line examples for either Windows (PowerShell) or Linux (Bash/CLI). However, when discussing alternatives to the portal, it lists 'Azure CLI, PowerShell, or service APIs', with PowerShell mentioned before Linux-native tools. There are no explicit Linux/Bash examples or references to Linux-specific tools, which may make Linux users feel less directly supported.
Recommendations:
  • Provide explicit command-line examples for both Azure CLI (cross-platform) and PowerShell when mentioning alternatives to the portal.
  • When listing management options, mention Azure CLI before or alongside PowerShell to emphasize cross-platform parity.
  • Include sample commands for common tasks (such as enabling/disabling public network access) using both Azure CLI and PowerShell.
  • Clarify that Azure CLI commands work on Linux, macOS, and Windows, and provide installation links for each platform.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a mild Windows bias by consistently mentioning Windows and its tools (specifically Git Bash and winpty) before Linux/WSL equivalents, and by providing Windows-specific instructions and caveats (such as the need for an extra slash in certificate subjects and the use of winpty for openssl). While Linux/WSL instructions are present and parity is generally maintained, Windows is prioritized in ordering and tool recommendations.
Recommendations:
  • Alternate the order in which Windows and Linux/WSL instructions are presented, or present Linux first in some sections to balance perceived priority.
  • When introducing prerequisites and command-line environments, mention Bash on Linux/WSL first, then Git Bash for Windows, to avoid defaulting to Windows-centric language.
  • Clarify that winpty and the extra slash in certificate subjects are only needed for Git Bash on Windows, and consider grouping these as footnotes or callouts rather than leading the main instructions.
  • Where possible, provide a unified command example and only note platform-specific differences as exceptions, rather than separate primary/secondary tabs.
  • Explicitly state that all examples are cross-platform unless otherwise noted, and highlight any differences in a neutral, non-prioritized way.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a clear Windows bias. It assumes a Windows development environment by default, provides detailed instructions and tooling references (e.g., Visual Studio, .exe simulators, Windows-specific command prompts) primarily for Windows, and often omits or relegates Linux/macOS instructions to external links. Many code/build/run steps reference Windows tools or paths, and Linux equivalents are not provided inline or are only referenced indirectly.
Recommendations:
  • Provide explicit, inline instructions for Linux and macOS environments alongside Windows steps, not just as external links.
  • Include Linux/macOS equivalents for all Windows-specific tools (e.g., Visual Studio alternatives, .exe simulator alternatives, command-line instructions using bash/zsh).
  • When referencing command prompts, include bash/zsh examples and clarify which commands are cross-platform.
  • Ensure that all code samples and build instructions are tested and documented for Linux/macOS, including any required dependencies or environment setup.
  • Avoid assuming the use of Windows-only features or tools (e.g., .exe files, Visual Studio) without providing alternatives.
  • Where possible, use platform-agnostic language and tooling, or clearly indicate platform-specific requirements in each section.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a clear Windows bias. It repeatedly refers to 'your Windows machine' and assumes a Windows development environment by default. Instructions and examples prioritize Windows tools (Visual Studio, CMD, Git Bash, etc.), and environment setup steps are Windows-centric. Linux and macOS are only mentioned as alternatives, often with links out to other documentation rather than inline parity. Command-line instructions use Windows syntax (cmd, set) and do not provide Linux equivalents (bash, export, etc.). Visual Studio is emphasized for C/C++ development, with only a brief mention of Linux/macOS alternatives. There are no explicit Linux/macOS command examples or screenshots, and the initial framing and prerequisites are Windows-first.
Recommendations:
  • Provide parallel Linux/macOS instructions and examples alongside Windows ones, including shell commands (e.g., use both 'set' and 'export' for environment variables).
  • Include explicit instructions for installing prerequisites (e.g., compilers, SDKs) on Linux/macOS, not just links to external setup guides.
  • Offer build and run instructions for Linux/macOS environments (e.g., using gcc/clang, make, or cmake with Unix Makefiles, and running from bash/zsh).
  • Add Linux/macOS screenshots where appropriate, or clarify when steps are identical across platforms.
  • Avoid language that assumes Windows as the default (e.g., 'on your Windows machine'); instead, use neutral phrasing or mention all supported OSes.
  • For Visual Studio-specific steps, provide equivalent instructions for common Linux IDEs (e.g., VS Code, CLion) or command-line workflows.
  • Ensure all code snippets and commands are cross-platform, or provide platform-specific tabs/pivots.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation repeatedly assumes or prioritizes Windows as the development environment, particularly in the .NET and Java sections. Instructions such as 'Open a Windows command prompt' are given, and there are no explicit Linux or cross-platform command-line instructions, even though the SDKs and tools are available for Linux. There is a lack of Linux-specific guidance or parity in setup and execution steps, and Windows terminology is used by default.
Recommendations:
  • Provide explicit Linux (and macOS) instructions alongside Windows for all command-line steps, including terminal commands and environment setup.
  • Replace phrases like 'Open a Windows command prompt' with 'Open a terminal window' or provide both Windows and Linux/macOS alternatives.
  • Where commands differ (e.g., path separators, shell syntax), show both Windows (cmd) and Linux/macOS (bash/sh) examples.
  • Clarify that the SDKs and samples work cross-platform, and ensure that all prerequisites and steps are validated on Linux.
  • For Java and .NET, include Linux-specific notes for installing dependencies and running samples, such as using apt, yum, or Homebrew.
  • Avoid assuming the user is on Windows unless the SDK or tool is truly Windows-only.

Page-Level Analysis

Bash First Windows Shell Note
Summary:
The documentation primarily uses Bash syntax for variable assignment and command examples, with a note indicating that users on Windows CMD or PowerShell should adapt the commands. However, no explicit Windows CMD or PowerShell examples are provided, and Bash is presented as the default environment. There is no exclusive use of Windows tools or patterns, but Linux/Bash is favored in the examples.
Recommendations:
  • Provide equivalent command examples for Windows CMD and PowerShell alongside the Bash examples, especially for variable assignment and usage.
  • Include a table or section summarizing syntax differences for key commands (e.g., variable assignment, echoing variables) across Bash, CMD, and PowerShell.
  • Explicitly mention that the Azure CLI works cross-platform and link to official guidance on using it in different shells.
  • Consider alternating the order of examples or providing tabs for Bash, CMD, and PowerShell to ensure parity and clarity for all users.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation exhibits a Windows bias by consistently referencing Windows environments first or exclusively, especially in prerequisites and sample instructions. Several steps explicitly instruct users to use a Windows command prompt, and some certificate creation links and instructions default to Windows-specific tabs or tools. There are missing or unclear instructions for Linux users, particularly regarding command-line environments and tool usage. While some sections mention Linux compatibility, practical Linux-specific guidance is lacking.
Recommendations:
  • For all command-line instructions (e.g., creating projects, running samples), provide both Windows (cmd/PowerShell) and Linux/macOS (bash/sh) equivalents, or clarify when commands are cross-platform.
  • In prerequisites, avoid specifying 'Windows-based machine' unless truly required. Instead, list requirements for both Windows and Linux/macOS, and clarify when steps differ.
  • When linking to certificate creation tutorials, ensure that both Windows and Linux tabs are referenced or provide a neutral link, not just the Windows tab.
  • In sample creation steps, avoid phrases like 'Open a Windows command prompt.' Instead, use 'Open a terminal window' and specify differences if necessary.
  • For Java and Node.js sections, clarify that the samples can be run on Linux/macOS as well, and provide any necessary adjustments (e.g., path syntax, shell commands).
  • Where Git Bash or similar tools are referenced, explain their relevance for both Windows and Linux users, and suggest native alternatives for Linux.
  • Add explicit Linux/macOS examples for certificate manipulation (e.g., using openssl, sed, etc.), and clarify any OS-specific nuances.
  • Review all screenshots and UI instructions to ensure they are not Windows-specific, or provide Linux/macOS equivalents where the Azure portal UI differs.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a 'Windows-first' bias by exclusively referencing the Azure portal UI for configuration steps and mentioning PowerShell as a management option before the Azure CLI. There are no explicit Linux-specific instructions or CLI examples, and all screenshots and step-by-step guides are based on the Azure portal, which is platform-agnostic but often more familiar to Windows users. Additionally, there are no command-line examples (neither PowerShell nor Bash/CLI), and Linux tooling or workflows are not discussed.
Recommendations:
  • Add explicit Azure CLI (bash) examples for all configuration steps, especially for setting up private endpoints and managing enrollments.
  • When listing management options, mention Azure CLI before or alongside PowerShell to avoid Windows-first ordering.
  • Include at least one example using Linux-native tools or workflows (e.g., bash scripts, curl, jq) for interacting with DPS and private endpoints.
  • Provide screenshots or terminal output from cross-platform tools (CLI) in addition to or instead of Azure portal UI.
  • Clarify that all instructions are cross-platform where possible, and highlight any steps that are platform-specific.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation exhibits a Windows bias by prioritizing Windows-specific tools (Visual Studio), providing detailed instructions for Windows environments first, and only referencing Linux or macOS alternatives via external links. PowerShell and Windows command prompt examples are given alongside Bash, but the development environment setup and simulation steps are heavily oriented toward Windows/Visual Studio, with Linux instructions deferred or omitted.
Recommendations:
  • Provide step-by-step instructions for setting up the development environment and building/running the Azure IoT C SDK on Linux (e.g., using gcc, make, cmake, and VS Code or other editors).
  • Include Linux/macOS command-line examples (e.g., bash, sh) alongside Windows/PowerShell/cmd examples throughout the tutorial, not just for environment variable setup.
  • Offer explicit guidance for running and debugging the simulated device sample on Linux, including how to build and execute the sample without Visual Studio.
  • Reference Linux prerequisites (e.g., gcc, make, cmake, git) directly in the prerequisites section, not only via external links.
  • Where UI steps are described (e.g., Azure Portal), note any differences for Linux users if applicable, or confirm parity.
  • Ensure that all critical steps (such as building, running, and troubleshooting the sample) are fully documented for both Windows and Linux users within the main tutorial, not just in linked resources.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation exhibits a strong Windows bias: instructions and examples are consistently presented for Windows first, often exclusively referencing Windows tools (e.g., Visual Studio, Windows command prompt, Git Bash on Windows). Linux and macOS users are repeatedly referred out to SDK documentation or alternate tutorials, and step-by-step parity is lacking. Even when Linux commands are shown, they are secondary to Windows, and the overall workflow assumes a Windows-centric development environment.
Recommendations:
  • Provide full, step-by-step instructions for Linux (and macOS) alongside Windows in each section, not just links to external SDK setup guides.
  • Present Linux and Windows instructions in parallel (e.g., using tabs or clear subsections), ensuring equal prominence and completeness.
  • Include Linux-native toolchain examples (e.g., gcc, make, standard Bash) rather than focusing on Visual Studio and Windows command prompt.
  • Avoid assuming the use of Git Bash on Windows as a substitute for a real Linux shell; provide native Linux shell instructions.
  • Ensure all code samples, environment variable setups, and build/run instructions are fully documented for Linux, not just Windows.
  • Where Windows-specific tools are mentioned (e.g., Visual Studio), provide Linux equivalents (e.g., VS Code, CLion, or command-line tools) with equal detail.
  • Consider adding a Linux/macOS quickstart page or a unified cross-platform quickstart with clear pivots for each OS.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a strong Windows bias throughout. Prerequisites, environment setup, and all code execution instructions are presented for Windows first, with explicit references to Windows tools (Visual Studio, Windows command prompt, certmgr.msc, .NET SDK for Windows, etc.). Linux and macOS users are repeatedly directed to external SDK documentation rather than being provided with in-page, step-by-step instructions or examples. All shell commands for device provisioning, SDK setup, and certificate management are shown using Windows command prompt or Git Bash on Windows, with only brief notes about differences for Linux (e.g., subject name slashes in OpenSSL). There are no full Linux-native or macOS-native walkthroughs, and Windows-specific tools and patterns (e.g., certificate store, Visual Studio solution files) are assumed as defaults.
Recommendations:
  • For each programming language section, provide in-page, step-by-step instructions for Linux and macOS environments, not just links to SDK docs.
  • Include Linux/macOS command-line examples (bash, zsh, etc.) for cloning, building, and running SDKs, alongside Windows examples.
  • When referencing tools like Visual Studio, also mention and give instructions for common Linux/macOS IDEs or build systems (e.g., gcc, clang, make, cmake, VS Code).
  • For certificate management, provide Linux-native instructions (e.g., using update-ca-certificates, trust, or manual copying to /etc/ssl/certs) alongside Windows certmgr.msc steps.
  • Ensure all OpenSSL commands and file path examples are shown in both Windows and Linux/macOS formats.
  • Avoid assuming the use of Windows command prompt or Git Bash; clarify which shell is being used and provide alternatives.
  • Where environment variables are set, show both Windows (set VAR=val) and Linux/macOS (export VAR=val) syntax.
  • Summarize any platform-specific differences in a dedicated section or table for quick reference.