Fixes #21347: Rename "DSC" and "classic" agent to "Linux" et "Windows" in documentation

src/reference/modules/administration/pages/relayd.adoc

@@ -30,7 +30,7 @@ Relayd operates on different data directories:
 * `/var/rudder/inventories` (on on simple relays): to forward inventories to upstream relay or root server. On root server, the webapp monitors this folder directly.
 * `/var/rudder/reports`: to forward reports to upstream relay, or, on root server, to parse and insert reports into the database.
 * `/var/rudder/shared-files/`: files shared between nodes
-* `/var/rudder/configuration-repository/shared-files` (read-only): global shared files for Windows agents (Unix agent uses policy download protocol).
+* `/var/rudder/configuration-repository/shared-files` (read-only): global shared files for Windows agents (Linux agent uses policy download protocol).
 
 == API
 

src/reference/modules/installation/pages/agent/windows.adoc

@@ -12,9 +12,9 @@ Windows agents are only available with a subscription and can be downloaded on h
 
 On `Windows Server 2008R2` and `Windows Server 2012` you may need to check the requirements sections before installing the agent.
 Desktop versions are not officially supported but should be mostly compatible as long as the requirements listed in the dedicated section are filled.
-The agent is currently distributed via an `.exe` installer which both support graphical and cli based installs.
+The agent is currently distributed via an `.exe` installer which both support graphical and cli based installations.
 
-The policy server configuration can be defined before installtion by writing its hostname or IP in the file:
+The policy server configuration can be defined before installation by writing its hostname or IP in the file:
 
 ----
 C:\Program Files\Rudder\etc\policy-server.conf
@@ -47,7 +47,7 @@ Several options can be passed via the CLI to the installer:
 * `/?`: Open a graphical help page for the installer
 * `/POLICYSERVER`: If not empty, will override at install time the value of the `policyserver.conf`.
 * `/SCHEDULEDTASKUSER`: If not empty, will use the given user to run the Rudder scheduled tasks, responsible for the agent execution.
-* `/SCHEDULEDTASKPASSWORD`: Only neeed if `/SCHEDULEDTASKUSER` is used, password of the target user (required to define the scheduled task).
+* `/SCHEDULEDTASKPASSWORD`: Only need if `/SCHEDULEDTASKUSER` is used, password of the target user (required to define the scheduled task).
 
 The `SCHEDULEDTASK*` options are only available through the CLI, and when used, the agent will not try to modify the defined task afterward without manual intervention.
 The scheduled tasks can be manually modified using the rudder command `rudder agent check-scheduled-tasks`.
@@ -65,7 +65,7 @@ Plase note that older desktop versions (`Windows 7 and 8`), you will need to ins
 Set-WSManQuickConfig DSC
 ----
 
-Moreover, the Windows DSC agent comes without digital signature, you need to allow the unsigned source code execution on the Windows node.
+Moreover, the Windows agent comes without digital signature, you need to allow the unsigned source code execution on the Windows node.
 In some environment, this policy change can lead to security issues, please read the dedicated Microsoft Windows https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.2&viewFallbackFrom=powershell-6[documentation].
 This can be done in powershell by executing the following command:
 

src/reference/modules/reference/pages/_partials/glossary/port-443-nodes.adoc

@@ -1,4 +1,4 @@
 Port 443, TCP, for nodes::
 
 WebDAV/HTTPS communication port, used to send inventory and fetch the id of the Rudder Server.
-Powershell DSC agent communication port, used to fetch policy and shared files from the policy server on Windows
+Powershell Windows agent communication port, used to fetch policy and shared files from the policy server on Windows

src/reference/modules/usage/pages/advanced_node_management.adoc

@@ -316,15 +316,15 @@ in the standard Rudder inventory information.
 As of Rudder 4.3.0, you can get more information about a node thanks to
 `inventory hooks`. These information will be available as standard *node properties*.
 
-Starting from 6.0.3, the inventory extension is also available on DSC based agents.
+Starting from 6.0.3, the inventory extension is also available on Windows based agents.
 
 
 === Overview
 
 On the node, you create `inventory hooks` executable and place them in `/var/rudder/hooks.d`.
 These binaries are executed in the alphanumerical order, only if executable, and their output is checked to
 ensure that it is proper JSON.
-On DSC based agents, they must be powershell scripts and be located under `C:\Program Files\Rudder\hooks.d`.
+On Windows based agents, they must be powershell scripts and be located under `C:\Program Files\Rudder\hooks.d`.
 
 For example, one hook can output:
 

src/reference/modules/usage/pages/variables.adoc

@@ -234,11 +234,11 @@ image::view-property-inheritance.png[Viewing property overrides]
 |name=datacenter, value="Paris"
 |name=datacenter, value={"dns": "1.1.1.1"}
 
-|Classic (Unix) technique
+|Linux technique
 |`${node.properties[datacenter]}`
 |`${node.properties[datacenter][dns]}`
 
-|DSC technique
+|Windows technique
 |`$($node.properties.datacenter)`
 |`$($node.properties.datacenter.dns)`
 
@@ -273,11 +273,11 @@ node property which may have been overridden.
 |name=datacenter, value="Paris"
 |name=datacenter, value={"dns": "1.1.1.1"}
 
-|Classic (Unix) technique
+|Linux technique
 |`${rudder.parameters[datacenter]}`
 |`${rudder.parameters[datacenter][dns]}`
 
-|DSC technique
+|Windows technique
 |`$($rudder.parameters.datacenter)`
 |`$($rudder.parameters.datacenter.dns)`
 
@@ -332,11 +332,11 @@ These variables are expanded at policy generation and their values are based on
 |name=hostname, value="Paris"
 |name=os, value={"name": "Debian"}
 
-|Classic (Unix) technique
+|Linux technique
 |`${node.inventory[hostname]}`
 |`${node.inventory[os][name]}`
 
-|DSC technique
+|Windows technique
 |`$($node.inventory.hostname)`
 |`$($node.inventory.os.name)`
 
@@ -464,7 +464,7 @@ Information about a node's policy server:
 ====
 
 These variables are not available on Windows nodes, but
-only on with the classic Linux/AIX agent.
+only on with the Linux/AIX agent.
 
 ====
 
@@ -478,11 +478,11 @@ NOTE: These properties are evaluated on the node at run time.
 |name=host, value="host.local.name"
 |No JSON like values: name=ipv4[eth0], value=192.168.41.2
 
-|Classic (Unix) technique
+|Linux technique
 |`${sys.host}`
 |`${sys.ipv4[eth0]}`
 
-|DSC technique
+|Windows technique
 |N/A
 |N/A
 
@@ -633,9 +633,9 @@ The resulting properties will be:
 
 Agents can define variables:
 
-* For the classic (Unix) agent, https://docs.cfengine.com/docs/3.15/reference-special-variables-sys.html[CFEngine system variable] are available.
+* For the Linux agent, https://docs.cfengine.com/docs/3.15/reference-special-variables-sys.html[CFEngine system variable] are available.
 
-* For the DSC agent, no specific variables are provided.
+* For the Windows agent, no specific variables are provided.
 
 ==== Variable defined from techniques and generic methods
 
@@ -646,15 +646,15 @@ Rudder also provides techniques similar to generic methods that allow to define
 In most case, it's easier to use generic methods as they allow to:
 
 * group several variable definitions in the same place
-* encapsulate variable definition definition and usage in the technique, avoiding dependencies between directives (which should be avoided as much as possible).
+* encapsulate variable definition and usage in the technique, avoiding dependencies between directives (which should be avoided as much as possible).
 
 We present afterward a subset of interesting cases, but there is others that you can check out in https://docs.rudder.io/reference/current/reference/generic_methods.html#_variable[generic method documentation].
 
 ====== Variable override by order of rules and directives
 
 Variables defined with following generic methods or corresponding techniques can be overridden by other variables with same name defined in other rules or directives.
 
-The exact ordering and rules are explain in the https://docs.rudder.io/reference/current/usage/advanced_configuration_management.html#_sorting_directives_based_on_the_same_technique[ordering directive] chapter.
+The exact ordering and rules are explained in the https://docs.rudder.io/reference/current/usage/advanced_configuration_management.html#_sorting_directives_based_on_the_same_technique[ordering directive] chapter.
 
 It is not recommended to rely on this mechanism as dependencies between directives are not
 easily visualizable.
@@ -742,7 +742,7 @@ There's little use defining variables if you don't use them. In this section, we
 - variable in templates are a special cases of previous case: they are expanded on node, during agent run. But their syntax and usage are directed by the template engine, `mustache` or `jinja2` in Rudder;
 - on the other hand, variables in directives parameters are likely only configuration data defined elsewhere and used to parameterized a technique used as a configuration template. Variables in directive are generally expanded during policy generation in the policy server, and most errors can be caught at that time.
 
-The next paragraph will detail specificities of each cases.
+The next paragraph will detail specificities of each case.
 
 === Technique
 
@@ -855,15 +855,15 @@ Group conditions are defined only if the node is in the given group (available i
 In the same spirit that some variables are defined by default when the agent runs, a set of condition is defined based on the environment execution context.
 These conditions cover mainly information about the system (os, etc) and information about time.
 
-These conditions are different on each agent, and of course on each run depending of the context. You can see which one are defined by executing the following command on your node:
+These conditions are different on each agent, and of course on each run depending on the context. You can see which one are defined by executing the following command on your node:
 
 ----
 
 rudder agent info -v
 
 ----
 
-On classic (Unix) agent, you can also start a run with some defined condition with the command:
+On Linux agent, you can also start a run with some defined condition with the command:
 
 ----
 
@@ -918,7 +918,7 @@ Note the second number indicates up to what minute the interval extends and does
 | `Lcycle_0`, `Lcycle_1`, `Lcycle_2` and `GMT_Lcycle_0`, `GMT_Lcycle_1`, `GMT_Lcycle_2` (the year number modulo 3, used in long term resource memory).
 |===
 
-Classic (Unix) agent (non exhaustive list)
+Linux agent (non exhaustive list)
 
 [cols="2", options="header"]
 |===
@@ -942,7 +942,7 @@ Classic (Unix) agent (non exhaustive list)
 
 |===
 
-DSC agent
+Windows agent
 
 [cols="2", options="header"]
 |===
@@ -957,7 +957,7 @@ DSC agent
 
 |===
 
-NOTE: In DSC agent, classes are defined in https://github.com/Normation/rudder-agent-windows/blob/master/packaging/Files/share/initial-policy/resources/environment.ps1[that source file].
+NOTE: In Windows agent, classes are defined in https://github.com/Normation/rudder-agent-windows/blob/master/packaging/Files/share/initial-policy/resources/environment.ps1[that source file].
 
 ===== Condition classes from code