dotfiles: report Intel VTune rather than installing it

[dotfiles] / README.md

diff --git a/README.md b/README.md
index 421e1fe4b79768abeadeb317a23289af239a0adb..e0ef7448f859dff7eab6d24cfd958452896b292b 100644 (file)
--- a/README.md
+++ b/README.md
@@ -137,6 +137,20 @@ throwaway VM reachable from a Linux host.
   msstore`); it is not installed here because the Store source needs an
   interactive, signed-in session, which the unattended elevated half does not
   have.
+- **Intel VTune Profiler is reported, not installed.** The elevated half prints
+  whether it is on the box, its version, and the path to `vtune.exe`; if it is
+  missing it prints the download page instead (and says so if the CPU is not
+  Intel). Automating the install is not worth it here: the offline installer is a
+  ~750 MB download from a URL carrying a per-release GUID with no "latest"
+  redirect behind it, so every new build would mean editing a hard-coded link,
+  and it is only worth having on Intel silicon since hardware event-based
+  sampling reads Intel PMU counters. It does install unattended if you want it
+  scripted elsewhere:
+
+  ```powershell
+  intel-vtune-<version>_offline.exe -a --silent --cli --eula accept
+  ```
+
 - **Tracing without a UAC prompt.** `xperf` and `wpr` fail for a standard user in
   two different ways, because two different things are missing:
 
@@ -178,8 +192,11 @@ throwaway VM reachable from a Linux host.
   Two consequences worth knowing. A privilege and a group membership are both
   read into the access token **at logon**, so the account must sign out and back
   in for 1 and 2 — any new logon does it, and an `ssh` login into the box is the
-  quick way to check without dropping the desktop. (The ACE in 3 is machine
-  state, read when a session starts, so it applies immediately.) And this only
+  quick way to check without dropping the desktop. The ACE in 3 is machine state
+  instead, and a logon does nothing for it: ETW reads these descriptors into a
+  cache, so it takes a **reboot** — with the ACE written and readable, `xperf -on
+  base` was still denied from a fresh shell on the running system. Plan on both
+  on a first run. And this only
   helps a **non-admin** account: UAC hands an administrator a filtered token
   carrying just five harmless privileges, so an admin's ordinary shell still
   cannot trace however the policy reads. Verify from the target account,