Windows Subsystem for Linux gets enterprise friendly and plans a settings interface The Windows Subsystem for Linux is due to receive a user interface for settings as well as management enhancements to make the platform more attractive to enterprise administrators. While die-hard Linux fans are unlikely to be averse to editing the odd config file or two in order to tweak a configuration, having to dive into …
Correct, it means "admins who don't know Windows", and can't cope with a structured config file (e.g. .ini, .conf) or even the Windows Registry.
A generic structured file editor might be handy.
Oh wait, I've got one - it's Notepad++. It doesn't tell me the available options, but a default/sample config file should include all the options, suitably #commented out
No competent UNIX sysadmin needs anything even remotely like the endless maze of pointy, clicky tools that are available to administrate Windows. They're been screwing around with that crap for decades now and each time they tweak it, my idea of where to look for the right place to change various Windows settings gets more and more confused.
Maybe this is why systemd has such a painful command line interface. It's all part of the master plan to shift everything to Windows control panel style interfaces and finally extinguish the UNIX idea of having one tool that is really good at the one thing it does and making the system easy to use and administrate with a bunch of those simple, memorable tools. Once they do that, they can deprecate the WSL and enter the extinguish phase.
You do know that the Windows registry can be accessed as file system, and items therein can be accessed as text files, right?
As well as a .NET objects that can be piped to other programs:
------------------------------------------------------------------------------------
PS HKLM:\SYSTEM\ControlSet001\Control\> ls -R 'HKLM:\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\'
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03
Name Property
---- --------
48210BFFFF3640AF00 DeviceDesc : @oem120.inf,%e15f2_3nc.devicedesc%;Intel(R) Ethernet Controller (3) I225-LM
LocationInformation : @System32\drivers\pci.sys,#65536;PCI bus %1, device %2, function %3;(88,0,0)
Capabilities : 16
UINumber : 13
Address : 0
ContainerID : {00000000-0000-0000-ffff-ffffffffffff}
HardwareID : {PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03, PCI\VEN_8086&DEV_15F2&SUBSYS_30038086, PCI\VEN_8086&DEV_15F2&CC_020000
, PCI\VEN_8086&DEV_15F2&CC_0200
}
CompatibleIDs : {PCI\VEN_8086&DEV_15F2&REV_03, PCI\VEN_8086&DEV_15F2, PCI\VEN_8086&CC_020000, PCI\VEN_8086&CC_0200...}
ConfigFlags : 0
ClassGUID : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver : {4d36e972-e325-11ce-bfc1-08002be10318}\0006
Service : e2fexpress
Mfg : @oem120.inf,%intel%;Intel
FriendlyName : Intel(R) Ethernet Controller (3) I225-LM
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\48210BFFFF3640AF00
Name Property
---- --------
Device Parameters InstanceIndex : 1
Hive: HKEY_LOCAL_MACHINE\system\CurrentControlSet\Enum\PCI\VEN_8086&DEV_15F2&SUBSYS_30038086&REV_03\48210BFFFF3640AF00\Device Parameters
> You do know that the Windows registry can be accessed as file system, and items therein can be accessed as text files, right?
No, I genuinely had no idea as I don't do much in WSL, so thank-you for mentioning it. Have an icon -->
> No, I genuinely had no idea as I don't do much in WSL, so thank-you for mentioning it. Have an icon -->
But but but text config files are only of use on the obsolete Linex OS :) I have noticed at least one WSL article in the Linux Mags. Which I suspect is the real purpose of WSL, to capture mindshare (purr of evil).
• Does anyone recall the “User Friendly” comic strip featuring “The Boss” and a Clippy being in permanent rageaholic mode?
It's not editing a .wslconfig file that's the problem, I dare say that anyone brave (or foolhardy) enough to embark on that journey knows how to launch a text editor.
The problem is knowing if editing said text file will make any difference. Will this setting be applied or silently ignored? You can't trust anything found on Google unless you know what build number you have. Has it been deprecated? Better check the GitHub page. Will the setting be maintained in any future versions of WSL? No idea, as Microsoft doesn't make any mention of API stability anywhere I've found.
Microsoft's implementation and future direction of WSL isn't planned, it's evolved.
Don't forget the artificial constraints between the Win10 and Win11 versions.
First you find the experimental setting, then you find it's migrated to release status (so the config needs editing to shift it to the proper section), then you find it only works on the 'right' version of Windows for no reason other than 'because'.
The problem is knowing if editing said text file will make any difference. Will this setting be applied or silently ignored? You can't trust anything found on Google unless you know what build number you have. Has it been deprecated?
This isn't different from any other software either, be it for Windows or Linux.
New versions of many software usually bring new settings and may deprecate old ones, so you can't just trust that stackoverflow / serverfault / reddit article from five years ago to actually work in your version unless you also check the docs carefully.
...the problem is knowing where this file is. After numerous searches, I finally found where it should be: C:\Users\<username>\ (using the info here: https://learn.microsoft.com/en-us/windows/wsl/wsl-config). But on my system, the file doesn't exist. At least knowing where it should be, it would be easy to create it.
While I'm stuck on a works WIndows machine WSL is a godsend for me. Most of the dev stuff I do on it is way easier to do (just sudo apt to install tools) and generally it's 2 to 5 times faster than using Windows itself. The thought of them letting Defender stick it's podgy fingers into WSL sounds like the whole WSL system will end up going as slow and sucking as much as Windows (sad face)
Trouble is what does this reallly mean.
I’ve worked with systems where the GUI configuration can import and export a config file, but doesn’t actually use the config file. Hence to make manual changes you have to export, change, import, redistribute. Obviously, problems arise because the system you are configuring has been updated and includes new settings, not yet supported by the GUI…
1. If GUI was such a good way to configure a system, why hasn't Redmond embraced it for Windows properly? I refer readers to MS's own advice: to cure their cock-up in a recent update, one needed to use command-line tools to fix the partition table. Before you try to convince the world your approach is solid, prove the concept works well in the OS you own entirely, folks
2. I'll put money on human-readable, file based configs being swapped out for a registry-style behemoth once a GUI becomes the only interface. After all, if you have an impenetrable admin layer applying the changes, the settings themselves can vanish into a custom database-style format because they no longer need to be read 'by hand'. This will keep Pottering in wet dreams for years!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
