| ; Place required files in the same directory as this script: | |
| ; - deviceinstaller64.exe from https://www.amyuni.com/downloads/usbmmidd_v2.zip | |
| ; - TurnOffHotspot.ps1 and TurnOnHotspot.ps1 | |
| #NoTrayIcon | |
| Persistent | |
| OnExit ExitFunc | |
| MonitorLoadedFile := ".MonitorLoaded" | |
| #y:: |
Windows Hotspot allows you to easily create an AP (Access Point) from your existing Wifi card. Many computers such as the ROG Ally have a variant of the MT7922 chipset which supports Wifi 6E and it can be used to create a high bandwidth P2P connection for game and VR streaming. Unfortunately, Windows does not provide much support for configuration of the AP channel and bandwidth. Fortunately, it is possible to change these from some registry entries. Note that you must reboot for the changes to take place.
The location of the registry key is inside HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{4d36e972-e325-11ce-bfc1-08002be10318} and depends on the order the network devices are installed on your computer. For example, it is HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{4d36e972-e325-11ce-bfc1-08002be10318}\0001 on the ROG Ally. Look at the data for value DriverDesc to confirm that you are in the right key.
Sets the preferred channel number. Currently unknown i
TPM (Trusted Platform Module) is as useful for preventing real attackers as the TSA is at preventing real terrorists. The architecture is fundamentally flawed and most existing implementations are completely broken. I thought this argument was settled decades ago[1] when "trusted computing" was introduced mostly as a way to provide DRM and ownership capabilities to organizations. It has largely failed to impact the consumer market when it was introduced back in the early 2000s. However, recently there seems to be a movement by certain parties to reintroduce this failed product back to the market. Microsoft argues that in order to use Windows 11, you need TPM 2.0 compatible hardware because[2]:
The Trusted Platform Module(TPM) requirement ena
| // xcrun clang -O2 -o test test.c | |
| #include <stdio.h> | |
| #include <stdint.h> | |
| #include <stdbool.h> | |
| static inline uint64_t usub64_borrow_1(uint64_t x, uint64_t y, bool *pborrow) | |
| { | |
| unsigned long long b = *pborrow; | |
| x = __builtin_subcll(x, y, b, &b); |
One of the biggest issues with using a self hosted GitHub runner is that actions that require downloading large amounts of data will bottleneck at the network. [actions/cache][1] does not support locally caching objects and artifacts stored on GitHub's servers will require a lot of bandwidth to fetch on every job. We can, however, set up a content proxy using [Squid][2] with SSL bumping to locally cache requests from jobs.
A major challenge is that [actions/cache][1] uses Azure storage APIs which makes HTTP range requests. While Squid supports range requests, it is not good at caching them. There is an option, range_offset_limit none which, according to the [documentation][3]:
A size of 'none' causes Squid to always fetch the object from the beginning so it may cache the result. (2.0 style)
However, after extensive debugging, I discovered that the feature does not work if the client closes the connection. When range_offset_limit is set, Squid will make a full request to the server,
- Proposal: JBX-0001
- Authors: osy
- Status: draft
The ecosystem of iOS [jailbreaks][1] has remained largely unchanged since iOS 1.0 even though the system internals of iOS has undergone several evolutions, enhancing security and enabling new features. iOS jailbreaks traditionally involves neutering a significant portion of the OS's security in order to enable unsigned code execution ("apps") and system modifications ("tweaks"). This allows [malware][2] to target jailbroken users and for misbehaving apps to corrupt data.
| -----BEGIN PGP PUBLIC KEY BLOCK----- | |
| mQINBF/m1LMBEAC7aSdMkcWtog6wrOqak1Adj4f+amaF4FVLRwuRImEn6Jyaw7uj | |
| 4bxFxdWSUtiUZVYQumoea0kBwlQBDcsnCbsIACCCxmKNcjYYICENHZ45VYrOPveq | |
| 1fL9+oZbhoRzQ/LDi/QOzlXbu7H1e2My4Uo2jrjxlyE9sJWthMjv4iwa0g/XJENP | |
| vkgccMCAgzypV5niJUuQP1CAnH6IyIlZVDahmuw/BZaNQWHG46on5P2QZbPtW1vx | |
| FE9EztgI4QwlnHji8tZfUJX9H8BWOC7mi173Zr6Tu4QD/ejUkuGw5WzlOxFUPbnz | |
| vknb1R2/Hx9bENnFlxRpPrXQ5v0b7FhpwW+G3URj5HuQUK2thkCVHz7aO1S260V2 | |
| 81ZnOvDDuBUlehQ079eL/btrP0jfNkEtd8YCSdxqDPBSytnuJriH30M6p9H+7aye | |
| KXC1rMinZUjMeonE4EEbEH7psoxvIpsuqR+fXq6ZXYiO7YoqvWOj/l84jORBuGwQ |
Thanks to the work of @agraf, @KhaosT, @imbushuo, and others, we have Virtualization.framework working on M1 Macs. These [changes][1] have been merged with QEMU v5.2.0 RC3 (will rebase once the final release is out) and integrated with UTM, a brand new QEMU frontend designed in SwiftUI for iOS 14 and macOS 11.
