Since this simple method should work for many common Linux
commands...
Since this simple method should work for many common Linux
commands...
How many of these do you have to write before it becomes simpler just
to run a Linux system?
PSA: How to add WSL grep to the Windows command-line PATH
This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).
It's a PITA to constantly convert adb examples using grep to findstr.
So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.
I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.
What good is WSL if you can't use it when you need it?
Hence, I came up with this method of calling the WSL grep from Windows.
It may be one of the simplest methods to run any WSL Linux tool directly
from the Windows CMD (or powershell) using a simple wrapper script.
But I've only tested it just now with just grep (not sed, awk, ls, etc.).
Unfortunately, WSL Linux binaries aren't normal Windows executables.
Hence, just adding the WSL Linux binary to Windows PATH
won't make CMD able to execute it. That would be too easy.
But this method just now worked perfectly, for me, on Windows 10.
Here's the sample x-platform adb:android:windows command we want to run.
adb shell pm list packages | grep -i gsf'grep' is not recognized as an internal or external command,
operable program or batch file.
Of course, we've all used CYGWIN and other UNIX binaries in the
past, but I already have WSL so why not use the grep it came with.
First, let's prove WSL 1 is installed and working.
wsl --list --verboseNAME STATE VERSION
* Ubuntu Stopped 1
And, let's prove WSL has a working grep too.
wsl grep --versiongrep (GNU grep) 3.11
Since it's there, let's add a "grep.cmd" to a file in our path:
gvim C:\path-to\grep.cmd@wsl grep %*
Then test from anywhere on the command line:
grep --versiongrep (GNU grep) 3.11
Let's get back to what we were doing, which was testing GSF:
adb shell pm list packages | grep -i gsfpackage:com.google.android.gsf
Voila!
I haven't tested any of the other WSL Linux commands, but from this simple grep test, I would hope that the others (sed, awk, etc.) should work too.
Do they?
On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:
Since this simple method should work for many common Linux
commands...
How many of these do you have to write before it becomes simpler just
to run a Linux system?
Paul wrote:
Isn't there some Rust version of GREP ? That's assuming the package
is available right now.
https://learn.microsoft.com/en-us/windows/core-utils/overview
Of all the various ways to do that, some tools have line ending problems,
and then a "native" routine becomes a better choice.
How that starts out (apparently), is it sniffs $0 when you run it
(its own filename). If it finds "grep.exe" then it knows you want grep.
If the filename was "sed.exe", it knows you want SED. By using hardlinks,
you can have executables with the "right names" for the job, and
then the storage space for the executable is one set of clusters. I have
one program I wrote for myself that works like that. The filename
can be "encode.exe" or "decode.exe" and that decides the function.
Hopefully, for anything line-ending-sensitive, that program will
do it the Windows way.
When I compared the gnuwin32 "gawk" to the WSL2 "gawk",
the gnuwin32 one was Windows endings, the WSL2 one was Linux endings.
When writing scripts in that language, a couple lines must be
added to the BEGIN preamble, to compensate for that.
By running in the Windows environment, you have all your "visible" RAM
to use. That makes scoping out limitations for a run, a little bit easier. >> It looks like my WSL2 right now, is using half of system memory,
and the swap file is 25% of that number.
Hi Paul,
Thanks for bringing up RUST which, um, I had not heard of prior.
<https://daily.dev/posts/microsoft-ships-native-linux-coreutils-for-windows-built-on-rust-ggfo0izh5>
The problem for me is most of the suggested adb commands I find on the net tend to use Linux commands to post process raw output, usually in a pipe.
adb shell top -b -n 1 | head -n 25
adb shell pm list packages -3 | cut -d: -f2
adb shell df -h | awk 'NR==1 || /\/data$/ {print $1, $5, $6}'
adb shell dumpsys battery | grep -E 'status|health|temperature|voltage'
etc.
We could run those Linux commands on the Android device, but it's a PITA.
adb shell 'dumpsys battery | grep level'
Looking up RUST, so that we all benefit, apparently Microsoft released Coreutils for Windows containing a set of Unix-style command-line tools built on the open-source uutils Rust project but not 'grep' or 'find'.
*Microsoft Coreutils for Windows: native Linux command-line tools*
<https://4sysops.com/archives/microsoft-coreutils-for-windows-native-linux-command-line-tools/>
Apparently these core Linux tools are installed on Windows using winget:
winget install Microsoft.CoreutilsFound Coreutils for Windows [Microsoft.Coreutils] Version 2026.6.16
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to,
third-party packages.
Downloading
https://github.com/microsoft/coreutils/releases/download/v2026.6.16/coreutils-2026.6.16-x64.exe
100% 4.87 MB / 4.87 MB
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
Successfully installed
Then we need to add coreutils to the Windows path
setx PATH "%PATH%;C:\Program Files\coreutils"SUCCESS: Specified value was saved.
According to the documents above, these apparently work well:
cat, cp, ls, mv, rm, pwd, sleep, hostname
These only partially work according to the documents:
date, echo, mkdir, rmdir, find
These apparently don't come with the core utils package:
dir, more, expand, kill, chmod, chown, chroot, nuhup, tty, who, timeout,
paste, expand, whoami
I just realized that Microsoft's Coreutils package doesn't give us
grep, sed, cut or awk, so we still need additional Linux-like packages.
Drat.
Nonetheless, I just installed the coreutils, but I haven't tested it yet.
Frank Slootweg wrote:
Don't confuse convoluted methods with what most others are doing.
Hi Frank,
You're so desperate to insult me that you didn't even read what I wrote.
Hence, almost everything you said was factually dead wrong, Frank.
When you grow up, you'll learn to read what I had written to understand it.
The fact you never could complete high school is telling in your posts.
You have no desire to help anyone, Frank.
You're a despicable sadistic wholly unprepossessing ignorant human being.
In your response, if any, please indicate you read & understood the method.
Otherwise, it's obvious that you only have your own disgusting purposes.
On Thu, 8/27/2026 12:45 PM, Maria Sophia wrote:[...]
I just realized that Microsoft's Coreutils package doesn't give us
grep, sed, cut or awk, so we still need additional Linux-like packages.
Drat.
Nonetheless, I just installed the coreutils, but I haven't tested it yet.
The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".
https://gnuwin32.sourceforge.net/packages.html
Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.
Frank Slootweg wrote:
Sorry to rain on your parade, but I fully understood what you
wrote.
Hi Frank,
Given your own personal assessment that you "fully understood" the
clearly stated problem set and just as clearly stated proposed
one-line solution, what exactly is your counter proposal as a
solution to the problem set?
And how is your proposed solution less "convoluted" than a 1-line
bridge?
Paul <nospam@needed.invalid> wrote:
On Thu, 8/27/2026 12:45 PM, Maria Sophia wrote:[...]
I just realized that Microsoft's Coreutils package doesn't give
us grep, sed, cut or awk, so we still need additional Linux-like packages.
Drat. Nonetheless, I just installed the coreutils, but I haven't
tested it yet.
The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".
https://gnuwin32.sourceforge.net/packages.html
Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.
I don't know what the fuss is about. The 'Coreutils for Windows'
page
clearly says that it includes grep (and cut, but indeed not sed or
awk).
<https://learn.microsoft.com/en-us/windows/core-utils/overview>
<https://learn.microsoft.com/en-us/windows/core-utils/commands>
grep is a different part of *uutils* (uutils/grep, not
uutils/coreutils), but *included* in 'Coreutils for Windows'.
Anyway, as mentioned, I prefer Cygwin, which is (modular and) more
complete than both 'Coreutils for Windows' and GnuWin.
[...]
While we've searched for decades to find any useful scripts from you,
I realize you've never been particularly reluctant to criticize my kind-hearted scripts
such as this latest script which I wrote so that
others can run more easily most of the common WSL commands on Windows.
Frank Slootweg wrote:
Sorry to rain on your parade, but I fully understood what you wrote.
Hi Frank,
Given your own personal assessment that you "fully understood" the clearly stated problem set and just as clearly stated proposed one-line solution, what exactly is your counter proposal as a solution to the problem set?
And how is your proposed solution less "convoluted" than a 1-line bridge?
But asking "why not use Linux" is absolutely the wrong question to
ask.
When I'm working at the Windows command line, I don't want to stop
and translate every Unix pipeline I encounter into Windows syntax.
If others wonder why I responded to "Frank Slootweg" the way I did, they first need to know he's a common troll who has infested Usenet for decades.
Lawrence D'Oliveiro wrote:
On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:
Since this simple method should work for many common Linux
commands...
How many of these do you have to write before it becomes simpler just
to run a Linux system?
Hi Lawrence,
Rest assured I've used every operating system out there since the 1960s',
& I have "been there, done that", with dual-boot Linux/Windows long ago.
The record shows I've solved all sorts of cross-platform problems with a dual-boot Ubuntu (where, for example, it reads iOS files better'n Windows).
But asking "why not use Linux" is absolutely the wrong question to ask.
The right question to ask (for the first post of this thread) would be:
Q1: Why did it take an entire line of code to solve the entire problem?
A1: If you can solve the problem with less than a line of code, tell me.
The sheer brilliance of the one-line solution notwithstanding, you actually replied to my second post, which was a script, which I wrote out of the kindness of my heart, to *help others* do what I can do, in a single line!
So the question to ask in the second post to which you replied, might be:
Q2: Can't you reduce the solution to less than a single line of code?
A2: By running that script, it solves the same problem for everyone.
Given that, please bear in mind that the goal was to efficiently solve the common problem that WSL commands are not Windows binaries in the path.
The fact I solved *that* problem in a single line of code, is brilliant. Don't you think?
On Thu, 27 Aug 2026 12:14:45 -0600, Maria Sophia wrote:
When I'm working at the Windows command line, I don't want to stop
and translate every Unix pipeline I encounter into Windows syntax.
Maybe it would be simpler to work at a Linux/Unix command line, then
you could skip this translation step.
Thank you Frank for suggesting we look up if grep resides in
coreutils. Ah. I just tested grep for the first time to see if it's
in coreutils.
Woo hoo!
As Frank noted, grep is there!
C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd
At least in my experience, that implies that a Linux VM can be an
even worse implementation than Cygwin, but for very different
reasons.
All this thread does is suggest a brilliant way to bridge that gap.
Using a single line file, called "grep.cmd" containing @wsl grep %*
I came up with that solution on my own, but if others know of an even
easier, even simpler solution than that one-line file, let us all know!
[end re-insert]such as this latest script which I wrote so that others
can run more easily most of the common WSL commands on Windows.
[snip]
You included a script ? Where ?
Here...
Herbert Kleebauer wrote:If you want to use grep within a batch, you can also write the
For example, we have to arrange for the macro to be installed in each CMD session, which isn't difficult to do, but the @wsl method is in the path.
The goal of this PSA is to bridge Windows with Linux so that common
adb examples found on the Internet can be pasted, verbatim, into the CLI.
If others wonder why I responded to "Frank Slootweg" the way I did, they first need to know he's a common troll who has infested Usenet for decades.
On 8/28/2026 7:13 PM, Maria Sophia wrote:
The goal of this PSA is to bridge Windows with Linux so that common
adb examples found on the Internet can be pasted, verbatim, into the CLI.
I think, the correct solution is, to install Linux in a virtual
machine. On your next PC install Linux as main OS and Windows in
a virtual machine. And then, in any further PC, you only need Linux.
Maria Sophia wrote:
Then we need to add coreutils to the Windows path
setx PATH "%PATH%;C:\Program Files\coreutils"SUCCESS: Specified value was saved.
WARNING!
Drat. That was a mistake!
C:\> echo %PATH%
Reports coreutils, then stuff, the same stuff, and coreutils again
That setx method was the wrong method, but worse, it wasn't even needed!
Since the purpose of this thread is to be a public service announcement to help others run Linux commands like "grep" on the CLI, notethat the setx above duplicated the path, and worse, the winget of coreutils added the coreutils to the BEGINNING of the path, so, the end result was:
a. CoreUtils was in the beginning of the path
b. Then the old path was duplicated
c. And CoreUtils was added to the end of the path
So, the main advice here is to know that CoreUtils takes care of the path.
What comes now in this article is simply how to fix it if you did it.
1. Back up the path
reg export HKCU\Environment "%USERPROFILE%\path-backup.reg" /y
2. De-duplicate the user path but still preserve the original order
powershell -NoProfile -Command "$u=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? {$_}; $m=[Environment]::GetEnvironmentVariable('Path','Machine') -split ';' | ? {$_}; $u=$u | ? {$_ -notin $m} | Select-Object -Unique; [Environment]::SetEnvironmentVariable('Path',($u -join ';'),'User')"
3. Remove the coreutils that was added at the end of the path
powershell -NoProfile -Command "$p=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? { $_ -and $_ -ne 'C:\Program Files\coreutils' }; [Environment]::SetEnvironmentVariable('Path',($p -join ';'),'User')"
4. Check the path
echo %PATH%
In summary, when you install the Microsoft CoreUtils, it appends the coreutils to the path for you so you don't have to do it yourself.
On Fri, 8/28/2026 12:25 PM, Maria Sophia wrote:
Maria Sophia wrote:
This is one of the differences at Apple. Historically, they had
"Inside Macintosh". The format and presentation, is preserved
in TN (Technical Notes). Some of the notes are fantastically good.
I wrote a partition manager once for my Mac disk, and I could
do that using a *single* TN, didn't have to read anything else.
(This was after gparted impressed me by utterly destroying the partition table.)
When they choose to document something, it's not a half hearted
effort on their part. The efforts are usually "better than Wikipedia"
level of technical notes. The way someone might explain a thing
to you in a USENET post. Whereas the Microsoft documentation
is unimaginative "the boss is beating me with a stick to write
this description" flavored documentation, the best kind of
documentation when you really needed charitably written material.
PSA: How to add WSL grep to the Windows command-line PATH
This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).
It's a PITA to constantly convert adb examples using grep to findstr.
So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.
I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.
What good is WSL if you can't use it when you need it?
Maria Sophia, 2026-08-27 04:08:
PSA: How to add WSL grep to the Windows command-line PATH
This is an Android:Windows cross-platform problem that I run into every day because most adb examples we find on the net use grep (not findstr).
It's a PITA to constantly convert adb examples using grep to findstr.
So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.
I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me that I couldn't just call the Ubuntu grep from the Windows command line.
What good is WSL if you can't use it when you need it?
Well - I switched to Linux completely a while ago since I couldn't stand using Windows 11 any longer. I did never regret it. Currently using
Kubuntu 26.04 with KDE 6.6 and I don't miss anything at all.
--
Arno Welzel
https://arnowelzel.de
I should note that not everyone has WSL{1,2} already installed on
Windows.
On Sun, 30 Aug 2026 20:53:25 -0600, Maria Sophia wrote:
I should note that not everyone has WSL{1,2} already installed on
Windows.
Surely all those still trying to do serious development on Windows
will have WSL2 or later.
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
Frank Slootweg wrote:[...]
It's just not the solution you came up with (i.e., Cygwin) as we've been there, and done that, and ditched it, oh, maybe twenty five years ago.
There is nothing wrong with the Cygwin abomination if you already have it running, just as a Linux inside a VM is fine, if it talks to your phone.
Frank Slootweg wrote:
There is nothing wrong with the Cygwin abomination if you already
have it running, just as a Linux inside a VM is fine, if it talks
to your phone.
As I said before, Cygwin is way more complete and flexible than
both
'Coreutils for Windows' and GnuWin. *Because* it's more complete/
powerful than the other two, it encounters more Windows/Unix
differences, which it has to handle. That's not an "abomination",
but the consequence of its power.
BTW, Lawrence just posted a link to this
'How to set up Windows for software development' <https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
which says
"Some other tools for developing in Windows are optional, but
useful:
...
* MSYS2 (MSYS2.MSYS2): A collection of tools for building Windows
binaries using the GCC compiler. Basically, an alternative to the
Visual Studio build stack based on the Cygwin environment."
So much for "the Cygwin abomination"! :-)
And yes, it *also* mentions 'CoreUtils for Windows'.
Hi Frank,
I agree with you.
When I wrote this public service announcement, I was not trying to
turn Windows into a "development environment", as I was merely trying
to get the adb examples on the net to work inside the Windows command
line interface.
C:\> adb shell pm list packages | grep -i gsf
WSL 1 used a translation layer. It intercepted Linux system calls
and translated them on-the-fly into Windows NT kernel system calls.
Lawrence D˜Oliveiro wrote:
Oh, and think of going the other way, implementing a Windows
?personality? on top of Linux: it exists in the form of WINE, and
is working well enough that it is actually stealing market share
from Windows in the gaming market.
Ah, WINE. You bring back bad memories, given I gave up on WINE long
ago ...
Frank Slootweg wrote:
Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.
So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.
I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."
When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM while WSL1 was not inside a VM (the core difference being native vs non-native Linux commands).
Lawrence D˜Oliveiro wrote:
Oh, and think of going the other way, implementing a Windows
?personality on top of Linux: it exists in the form of WINE, and is
working well enough that it is actually stealing market share from
Windows in the gaming market.
Ah, WINE. You bring back bad memories, given I gave up on WINE long ago,
but that's kind of the point, which is it has never been easy to add
another operating system to any operating system, although we all tried.
Maria Sophia, 2026-08-31 17:34:
Frank Slootweg wrote:
Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.
So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.
I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."
When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM >> while WSL1 was not inside a VM (the core difference being native vs
non-native Linux commands).
WSL2 *is* a VM provided by the VM subsystem of Windwos which also
provides Hyper-V and was used for the Android Subsystem which got
removed again.
The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.
Maria Sophia, 2026-08-31 17:34:
Frank Slootweg wrote:
Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.
So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.
I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."
When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM >> while WSL1 was not inside a VM (the core difference being native vs
non-native Linux commands).
WSL2 *is* a VM provided by the VM subsystem of Windwos which also
provides Hyper-V and was used for the Android Subsystem which got
removed again.
The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.
the Windows desktop.
The VirtualBox and VMWare are rooted and display a rectangle which
represents the entire guest OS.
That's a difference in the display part of the hosting software.
On 2026-09-02, Arno Welzel wrote:
Maria Sophia, 2026-08-31 17:34:
The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.
This reads a lot like those threads that arlow guy used to post... it's
not the same OP is it?
It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.
On 2026-09-02 21:51, Dan Purgert wrote:
On 2026-09-02, Arno Welzel wrote:
Maria Sophia, 2026-08-31 17:34:
...
The article writer just confused "no need to start VirtualBox or VMware" >>> with "no VM" - but of course Linux running in WSL is a VM as well.
This reads a lot like those threads that arlow guy used to post... it's
not the same OP is it?
You mean Arlen? Yes, Arlen is Maria.
Richard Kettlewell wrote:
Arno Welzel <usenet@arnowelzel.de> writes:
It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.
That work has evidently been done. The WSL2 display architecture is:
client -> [XWayland ->] Weston -> RDP -> Windows desktop
...with the XWayland part being optional, in the sense that you can run
Wayland clients under Linux and they display in their own independent
window on the Windows desktop.
https://github.com/microsoft/wslg gets into the details.
--
https://www.greenend.org.uk/rjk/
Could it simply be that the main reason Linux GUI apps work differently in
a VM/WSL is mostly likely more about how the graphical systems are
connected and not because Windows inherently can't display Linux windows?
And today, I can find a review from someone you would recognize, who
put Windows Pro on such a machine and benchmarked it and then
produces a "quote-able number" for "how slow WIndows is". After
Anandtech made a splash all those years ago, with an admission their
first benchmarks were wrong, because they had used the wrong Windows
OS.
On Wed, 2 Sep 2026 21:36:56 -0400, Paul wrote:
And today, I can find a review from someone you would recognize, who
put Windows Pro on such a machine and benchmarked it and then
produces a "quote-able number" for "how slow WIndows is". After
Anandtech made a splash all those years ago, with an admission their
first benchmarks were wrong, because they had used the wrong Windows
OS.
I wouldn?t blame them, I would blame Microsoft. That is the most
common (and affordable) OS option it offers that is a bit above the
?Home? edition, naturally that is what people in the real world are
most likely to use. So why shouldn?t it be the version referenced in benchmarks?
There's a couple things about Windows.
1) There is a memory license. I had to deal with that back in
Windows 7, so I could use all the memory in the Test Machine.
Current Windows versions are quite generous on Memory License.
Some of the older OSes, were not generous. Maybe you could buy a
6TB dual socket server motherboard, filled with max RAM, then use
Win11 Pro, and not all your RAM would show up. You could, at the
same time, buy two AMD processors with the "very low core counts"
and then congratulate yourself on not needing Windows
Workstation.
2) Processor groups is a thing. A 96C 192T would have 3*64 groups.
This has something to do with how the scheduler works. If you're
buying big iron, you have to think about these things.
On Wed, 2 Sep 2026 23:18:33 -0400, Paul wrote:
There's a couple things about Windows.
1) There is a memory license. I had to deal with that back in
Windows 7, so I could use all the memory in the Test Machine.
Current Windows versions are quite generous on Memory License.
Some of the older OSes, were not generous. Maybe you could buy a
6TB dual socket server motherboard, filled with max RAM, then use
Win11 Pro, and not all your RAM would show up. You could, at the
same time, buy two AMD processors with the "very low core counts"
and then congratulate yourself on not needing Windows
Workstation.
On Linux, it costs $0 to support entry-level processor/core configurations. And then you have to pay an extra $0 for the next level up, and so on.
And that?s per-seat.
2) Processor groups is a thing. A 96C 192T would have 3*64 groups.
This has something to do with how the scheduler works. If you're
buying big iron, you have to think about these things.
Again, the Linux licensing goes in steps of $0 for each level. I think
a single node can have up to 2048 CPUs, so a million-CPU super will
need quite a few nodes, at $0 a pop.
Arno Welzel <usenet@arnowelzel.de> writes:
It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.
That work has evidently been done. The WSL2 display architecture is:
client -> [XWayland ->] Weston -> RDP -> Windows desktop
...with the XWayland part being optional, in the sense that you can run Wayland clients under Linux and they display in their own independent
window on the Windows desktop.
https://github.com/microsoft/wslg gets into the details.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 10 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 153:52:55 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 85,728 |