sudo makes sense as a name, but it is worth noting that it hurts the original projects.
Famously, the curl project receives tonnes of issues and support requests from people who run `curl` in PowerShell, not knowing it is an alias meant for convenience instead of the actual curl command[1].
Sudo for windows is already relatively old and doesn't seem to have been adopted much, but my prediction is that adoption would mean people would complain on forums that commands they found on the internet don't work. "Why wouldnt it? I have sudo?". Then people will have to explain to them that "No you do not have sudo, you have the windows version of sudo, which is not real sudo" and it will confuse.
When it comes to tools, I strongly believe naming things similarly to concepts the user already knows is a disservice to the user. This isn't UX for your mom and pop, it is a tool to perform a job, and learners get confused when suddenly the same thing isn't actually the same thing at all. It is mislearning, and I would argue almost anyone who does mentoring has seen this in action.
It doesn't though. There is no concept of a singular superuser like there is on UNIX. On Windows you have Administrator, but that is a role that can be assigned to any user.
And Administrators do not have full power, that would be the SYSTEM user. Which you cannot switch to with Sudo for Windows however - but you can with the runas tool, which has been around for decades.
But they all have the same UID, and are technically "the same user", even if you foolishly confer disparate usernames and passwords on them. When the system reverse-maps their UID it will display "root" because there is, ultimately, only one superuser on Unix.
The situation is the same for any userid and any groupid. If you try creating three ordinary users with a UID of 3005, they will be, essentially, the same user. There is no way at the system level to differentiate them, after they have authenticated. Because their files and processes are owned by the same UID.
This sharing of UIDs is generally discouraged and quite undesirable. It makes systems administration a real mess.
There is an old practice of having an alternative `toor` user with UID=0, with a different shell and password, in case someone screws the primary `root` account. https://en.wikipedia.org/wiki/Toor_(Unix)
If you try and set up "separate users" with "separate $HOME" that map to the same UID, all those "users" will "own" all those same files, and all processes started by one another. They would be able to kill processes, delete/modify/add files, impersonate one another. Because they are the same user.
You would be unable to enforce quotas or privacy for any of them. Whatever they did on the system would be indistinguishable, because their process UIDs would be identical. Any files they created would be owned the same. Sure, set them up with unique lists of GIDs; it really doesn't matter in the end.
I have no idea what you mean "User is user", but you are right: UID is not the same as a username. The username exists only in the passwd(5) database, and not in the kernel, like at all. The kernel has no idea what usernames are, and that's why they're irrelevant to user administration.
Niggle: "su" from "sudo" is for substitute/switch user in the su command, not "super" at all. By default the user being switched to in su is root/uid:0.
There's no such thing as "Super User" in context usage.
> Famously, the curl project receives tonnes of issues and support requests from people who run `curl` in PowerShell, not knowing it is an alias meant for convenience instead of the actual curl command[1].
Well, that explains a lot of the issues I was running into a few weeks ago...
The curl alias in powershell is not compatible so it is an inconvenience. Must be one of the worst decisions to make it into windows, which is saying a lot.
The worst part is that Windows does ship cURL as a binary at `C:\Windows\System32\curl.exe` (may be dependent on some optional feature, dunno). Nowadays it does invoke this for me on my system, but I don't remember if I did something for this to be the case.
Most of the aliases are for convenience when working in an interactive shell, which will generally be dealing with more basic functions of a command. For scripting it is best practice to use the full commandlet names.
There is more than one sudo implementation though and the configuration can be already different. Also I don't think you accidentally forget whether you are in a POSIX or a CMD shell.
This feels like a very dishonest take because the problem being discussed is clearly beginners being confused. How does your solution scale to the problem at hand?
Of course it doesn't help if a beginner doesn't understand why their curl command fails. I wrote this half in jest, because everytime PowerShell comes up, people like to Bash it for its stupid aliases on Windows. Yes these aliases are really stupid, but if you are using PS on Linux, it's not an issue and if you are on Windows, you just remove those aliases and continue living your life.
Some examples from this discussion:
> The curl alias in powershell is not compatible so it is an inconvenience.
> *nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink.
> Only the old powershell.exe builtin to Windows has these aliases and it’s worse today because curl.exe is builtin and the curl alias takes priority when you run just curl.
> It's wget for Windows all over again
> Ah yes, the 'curl' alias in powershell, vs the 'curl.exe' binary that uses the traditional options.
It seems like this adds much tighter integration between the caller and callee processes used named pipes and RPC communication, such as being able to share input/output streams within the same terminal session, which is a significant value add compared to runas.exe.
I, for one, have had to explain to Juniors multiple times that WSL isn't Linux, and why it's no replacement for Linux. Happens almost every time they try to do anything more advanced than a WSL hello world, and it inevitably fails.
I still let them try, because it beats me having to check "is wsl good now", and they learn much better from personal experience than someone more senior who uses arch btw just telling them "don't use windows"
Interesting, I've been using it with zero issues (including performance) for several years now. Compiled stuff, ran scientific calculations, trained neural nets with GPU passthrough, even switched over a workload from an old Red hat box to WSL Alma.
Only weirdness has been systemd can sometimes be quirky, and GUI stuff can be glitchy (which doesn't affect me much, because 99% of what I do is in the terminal)
So, anecdotally it is perfectly adequate for workloads beyond a Hello World. What issues are you running into?
/mnt/c etc from within WSL, and access to Linux FS paths are effectively a plan-9 file share service... Beyond this, if you use Docker Desktop (or similar) with volumes on the host OS (Windows or Mac) it's a weird FS sync between the host and container environment)... if you do volumes in WSL2 inside a Linux/WSL environjment it works fine (normally).
Permissions between Windows and Unix are always (generally) a mismatch, as is the nature of OS differences.
WSL1 is not Linux because it is mapping system calls from the Linux kernel ABI to NT. That sounds like what you're describing. WSL2 is a Microsoft distro running in a VM that integrates into Windows.
I use WSL2 every day and it has some annoying quirks with how their Wayland implementation behaves with DWM, but otherwise it's just a Linux environment.
WSL2 isn't exactly a distro. there's CBL-Mariner, which is a distro used for utility/plumbing, but it's pretty hidden internally. WSL2 is mostly:
1) a lightly-patched Linux kernel
2) a bunch of esoteric bridge stuff, namely:
2A) 9P for mounting the Windows filesystem on Linux and vice-versa,
2B) a Wayland server implemented via RDP(?!)
2C) Hyper-V NICs, dynamic memory and other VM integrations.
2D) even weirder esoterica like whatever magic lets CUDA work (and... directx? for reasons??)
but there's no canonical (pun intended) userspace. there are many Linux distros available; adapting a distro is usually pretty easy. for example, NixOS-WSL is lightweight and works quite well.
philosophically, WSL2 is a VM, but it's not an emulator, if that makes sense. there's a kind of convergence between OS and VM that's been going on for a decade and WSL2 has been riding that wave.
(disclaimer: I work for MS but not on Windows or WSL. I just think the arch is neat.)
$ uname -a
Linux MYPC 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Dunno, looks pretty Linux to me.
(WSL1 did suck badly because it combined the limitations of NT - slow file ops and process spawn - with the limitations of a compatibility layer. WSL2 is good enough for compatibility testing work on e.g. dotnet)
It's still running with windows as a host, and I've been met with friction and weird quirks in the interaction between them every time I have tried to use it myself, or watched someone else do so.
As someone who develops for both Windows and Linux I find WSL to be very useful. Much better than my previous method of dual booting Linux and Windows. I've yet to run into a problem that I needed to boot into native Linux for.
WSLv2 is indeed Linux... kernel and all... it's running in effectively a transparent VM with some utilities to aid in auto-mounting windows drives for access. WSLv1 used a translation layer (akin to WINE) to translate linux calls to windows calls. but WSL2 is indeed Linux.
>> Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.[0]
Between that quote and "You can't fix stupid" I always choose the one about circus.
*nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink. It didn't even mattered what 99.999% of the scripts which utilized that call were the simple 'get file' and nothing more.
I think Powershell and .net coming to linux is very welcome because I can keep hosting stuff with what I believe is a saner platform, and Windows developers can still keep using the platform they prefer. It's a win-win.
IMO .net is much better than Java, at least it was 10 years ago. So it's not like I don't understand them.
CLR is better on the polyglot approach, although Microsoft nowadays behaves as if C means C# and not Common, and ironically JVM seems to have a more vivid guest languages ecosystem nowadays. Any of Scala, Clojure, Kotlin, Groovy, seem to enjoy more activity than F#, VB or C++/CLI.
There are plus on the JVM side that Microsoft will probably never care for.
- A single vendor implementation, Microsoft no longer cares about ECMA
- Following from being a single vendor, there aren't multiple GC, JIT and AOT approaches to chose from
- Some of those implementations explore having most of the stack bootstraped instead of still being based on C and C++.
- One of them being a compiler development framework, whereas Microsoft killed theirs (Project Phoenix)
- Others offer real time GC, and embedded deployments in high critical computing environments, although less than 20 years ago, there are still three main vendors in this area
- A mobile OS, after Microsoft botched theirs when it was around 10% market share in Europe already, and now they don't have a platform for younger generations
Note that Java, .NET and C++ are my main toolbox tools, thus it isn't hating one over the other.
I just don't like the verbosity of Powershell myself... For that matter, I've trended towards using TypeScript (via Deno) for my user scripts that need more than basic shell interactions. I can reference any repository modules directly, use a shebang in the top of the script with self/executable, and no install step.
For that matter, deno in a shebang for an extensionless file now detects as a TypeScript file properly in VS Code. win-win-win. While being portable with a relatively small executable surface (deon executable only).
> I think Powershell and .net coming to linux is very welcome
It was!
I specifically talk here about a subset of people who was very ignorant but became very angry because... well, they are probably still write it as M$ so there is no point continue.
> *nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink
The curl and wget aliases don’t exist on the PowerShell 7 version which is the cross platform one. Only the old powershell.exe builtin to Windows has these aliases and it’s worse today because curl.exe is builtin and the curl alias takes priority when you run just curl.
It's "Windows PowerShell" which would be forever v5.1 and "PowerShell" is v7+.
(we don't talk about "PowerShell Core")
> builtin and the curl alias takes priority when you run just curl
Yes, but again if somebody didn't bother to read the docs, read the output (it's very evident when you have some PS error vs. everything else - and people STILL don't bother to try to understand) and start bitching on the forums... see my previous comment.
And by the way: it was established quite early what the use of an aliases in the written code should be frowned upon, exactly for the reason what the aliases aren't stable and could be local. Aliases are the quick way when you are slapping something interactively in the CLI.
So wget/curl were added for the benefit of those *nix fanboys who needed something better than cmd.exe on Windows so they could start using PS faster and later adopt to a proper ways but instead of reading the docs they only rose the stink.
I spent some time years ago going through a PowerShell course by the guys who wrote it. They explained their thought process and it actually made a lot of sense. Descriptive verb-noun naming to makes scripts readable, with aliases to make things quick and easy in the shell.
It’s easier to understand than names like grep, which require the user know ed and decades old history to figure out that it means global regular expression print. Without any *nix history, Select-String with an alias of sls, can make more intuitive sense and be easier to remember. The alias is also faster to type.
That sounds like PowersHell is similar to Esperanto - systematic and regular, but otherwise awkward and just doesn't have the staying power of a real, organically-developed language.
There's no need to "understand" "names like grep"; you learn it as a language like any other. If you aren't thinking of "grepping" (or cd'ing, ls'ing, fsck'ing, etc.) naturally and are always trying to translate the words into English (or some other language), you're doing it wrong.
That would imply it is written for PowerShell specifically ([1]), and would come with several expectations (like returning PSObject objects, and other good practices).
I keep waiting for Microsoft to give up on maintaining their own kernel and moving to Linux. Kind of like what they did with the browser engine, and building atop Chrome.
It's not sudo for Windows, it's a pile of rust which, if you figure out how to assemble it, presumably turns into some Microsoft interpretation of sudo which, judging by all the open issues, might be an attempt at grep that went wrong somewhere.
If you want a proper sudo for Windows, use gerardog's excellent gsudo, https://github.com/gerardog/gsudo. Among other things it comes with prebuilt binaries and installers.
Unless this is improved greatly from the last time I used it is pointless, any command you would use it for instead requires you to right click, open as administrator a command prompt to get the expected result
https://m.majorgeeks.com/files/details/nsudo.html
Been using it to run my cleanup or uninstaller utilities as SYSTEM/TRUSTED INSTALLER, so stubborn in use files that are not easily deletable not even with lockhunter or unlock file utilities that ultimately fallback to delete on next reboot.
> Everything about permissions and the command line experience is different between Windows and Linux. ... certain elements of the traditional sudo experience are not present in Sudo for Windows, and vice versa. Scripts and documentation that are written for sudo may not be able to be used directly with Sudo for Windows without some modification.
Then why is it named `sudo`? Just to create confusion?
Also, something like sudo is clearly not possible on modern Windows, because Microsoft thinks it owns your computer and won't allow Admins to do certain things.
Yeah, I’m aware of that. But this windows-sudo is sudo in name only anyway, so it seemed funny they’d copy a term that’s just about to go out of fashion.
Not really. It's not the same program at all. They just took the name for an inexplicable reason. They even had to make a paragraph disclaimer stating it isn't and never will be the same program.
The runas command doesn’t elevate just runs as another user. This is a console executable that drives UAC and also provides a way to capture the stdout/stderr elevated process which isn’t natively possible today without your own wrapper.
sudo makes sense as a name, but it is worth noting that it hurts the original projects.
Famously, the curl project receives tonnes of issues and support requests from people who run `curl` in PowerShell, not knowing it is an alias meant for convenience instead of the actual curl command[1].
Sudo for windows is already relatively old and doesn't seem to have been adopted much, but my prediction is that adoption would mean people would complain on forums that commands they found on the internet don't work. "Why wouldnt it? I have sudo?". Then people will have to explain to them that "No you do not have sudo, you have the windows version of sudo, which is not real sudo" and it will confuse.
When it comes to tools, I strongly believe naming things similarly to concepts the user already knows is a disservice to the user. This isn't UX for your mom and pop, it is a tool to perform a job, and learners get confused when suddenly the same thing isn't actually the same thing at all. It is mislearning, and I would argue almost anyone who does mentoring has seen this in action.
[1]: https://daniel.haxx.se/blog/2016/08/19/removing-the-powershe...
> sudo makes sense as a name
It doesn't though. There is no concept of a singular superuser like there is on UNIX. On Windows you have Administrator, but that is a role that can be assigned to any user.
And Administrators do not have full power, that would be the SYSTEM user. Which you cannot switch to with Sudo for Windows however - but you can with the runas tool, which has been around for decades.
Minor nitpick, but there's not necessarily a single super user in UNIX. You can create multiple users with uid=0 and they all will be super users.
But they all have the same UID, and are technically "the same user", even if you foolishly confer disparate usernames and passwords on them. When the system reverse-maps their UID it will display "root" because there is, ultimately, only one superuser on Unix.
The situation is the same for any userid and any groupid. If you try creating three ordinary users with a UID of 3005, they will be, essentially, the same user. There is no way at the system level to differentiate them, after they have authenticated. Because their files and processes are owned by the same UID.
This sharing of UIDs is generally discouraged and quite undesirable. It makes systems administration a real mess.
There is an old practice of having an alternative `toor` user with UID=0, with a different shell and password, in case someone screws the primary `root` account. https://en.wikipedia.org/wiki/Toor_(Unix)
See sibling reply. The uid is what defines the user, the name is just a convenient alias.
Not really. You can have separate users with separate $HOME, separate passwords, separate groups, separate everything.
User is user. Uid is uid. It's not the same. Uid is used for file permissions, that's true.
If you try and set up "separate users" with "separate $HOME" that map to the same UID, all those "users" will "own" all those same files, and all processes started by one another. They would be able to kill processes, delete/modify/add files, impersonate one another. Because they are the same user.
You would be unable to enforce quotas or privacy for any of them. Whatever they did on the system would be indistinguishable, because their process UIDs would be identical. Any files they created would be owned the same. Sure, set them up with unique lists of GIDs; it really doesn't matter in the end.
I have no idea what you mean "User is user", but you are right: UID is not the same as a username. The username exists only in the passwd(5) database, and not in the kernel, like at all. The kernel has no idea what usernames are, and that's why they're irrelevant to user administration.
Niggle: "su" from "sudo" is for substitute/switch user in the su command, not "super" at all. By default the user being switched to in su is root/uid:0.
There's no such thing as "Super User" in context usage.
The historical and original meaning was superuser do and superuser is absolutely a thing in UNIX.
See here from the guy who invented it:
https://hackaday.com/2014/05/28/interview-inventing-the-unix...
and here
https://www.youtube.com/watch?v=LaAwl3HN5ds (from around 4:30 minutes... "do a superuser thing")
Also the "su" command originally stood for "superuser":
https://web.archive.org/web/20220317213155/https://www.bell-... (UNIX manual from 1971)
"su allows one to become the super—user, who has all sorts of marvelous powers"
Hopefully these aliases will be renamed to "Copilot-Sudo" and "Copilot-Curl" soon enough.
Uh clearly you don't PowerShell enough. It should be `Invoke-CopilotSudo`
Maybe `wudo`? Windows Sudo!
If sudo stands for “superuser do”, and on Windows they call this user an “Administrator”. It stands to reason they should call it `audo`.
Though this would be confusing, as people would pronounce it like “adieu”, which would make it sound like an alias for `logoff`.
> It stands to reason they should call it `audo`.
"Administrator" doesn't contain a "u". `addo`/`ado` both would make more sense and flows better off the tongue.
And once the initial install of something was complete, you'd then be able to run it with no further ado :D
SuperUser DO
Administrator User DO
Or 'mudo', Microsoft sudo.
With the added benefit of having appropriate meaning in some slavic languages.
How about ms-sudo/mssudo and ms-curl/mscurl
I like the name MS-DOS. MicroSoft DO Superuser
> Famously, the curl project receives tonnes of issues and support requests from people who run `curl` in PowerShell, not knowing it is an alias meant for convenience instead of the actual curl command[1].
Well, that explains a lot of the issues I was running into a few weeks ago...
The curl alias in powershell is not compatible so it is an inconvenience. Must be one of the worst decisions to make it into windows, which is saying a lot.
The worst part is that Windows does ship cURL as a binary at `C:\Windows\System32\curl.exe` (may be dependent on some optional feature, dunno). Nowadays it does invoke this for me on my system, but I don't remember if I did something for this to be the case.
Most of the aliases are for convenience when working in an interactive shell, which will generally be dealing with more basic functions of a command. For scripting it is best practice to use the full commandlet names.
Browsers let me copy-paste curl commands from developer tools. These don’t work with windows «curl».
I know a few flags of curl too. These also don’t generally work with «curl».
So type “curl.exe” instead of “curl” or remove the alias in PowerShell.
I just avoid windows whenever I can.
There is more than one sudo implementation though and the configuration can be already different. Also I don't think you accidentally forget whether you are in a POSIX or a CMD shell.
If you're on Windows, run this once:
Now please stop whining about these stupid aliases.This feels like a very dishonest take because the problem being discussed is clearly beginners being confused. How does your solution scale to the problem at hand?
Of course it doesn't help if a beginner doesn't understand why their curl command fails. I wrote this half in jest, because everytime PowerShell comes up, people like to Bash it for its stupid aliases on Windows. Yes these aliases are really stupid, but if you are using PS on Linux, it's not an issue and if you are on Windows, you just remove those aliases and continue living your life.
Some examples from this discussion:
> The curl alias in powershell is not compatible so it is an inconvenience.
> *nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink.
> Only the old powershell.exe builtin to Windows has these aliases and it’s worse today because curl.exe is builtin and the curl alias takes priority when you run just curl.
> It's wget for Windows all over again
> Ah yes, the 'curl' alias in powershell, vs the 'curl.exe' binary that uses the traditional options.
And thus, I mostly use git's msys bash in my work Windows machine(s).
> Sudo for windows is already relatively old and doesn't seem to have been adopted much,...
Because probably this was pushed due to meet some OKRs ("made an impact").
It adds nothing over runas, other than being a known name to folks educated in UNIX.
Which is hardly of any benefit, given that Windows is not UNIX.
It seems like this adds much tighter integration between the caller and callee processes used named pipes and RPC communication, such as being able to share input/output streams within the same terminal session, which is a significant value add compared to runas.exe.
Indeed. This is the "Embrace" stage.
I, for one, have had to explain to Juniors multiple times that WSL isn't Linux, and why it's no replacement for Linux. Happens almost every time they try to do anything more advanced than a WSL hello world, and it inevitably fails.
I still let them try, because it beats me having to check "is wsl good now", and they learn much better from personal experience than someone more senior who uses arch btw just telling them "don't use windows"
Interesting, I've been using it with zero issues (including performance) for several years now. Compiled stuff, ran scientific calculations, trained neural nets with GPU passthrough, even switched over a workload from an old Red hat box to WSL Alma.
Only weirdness has been systemd can sometimes be quirky, and GUI stuff can be glitchy (which doesn't affect me much, because 99% of what I do is in the terminal)
So, anecdotally it is perfectly adequate for workloads beyond a Hello World. What issues are you running into?
Mostly its related to filesystem and permissions. Interface between windows and Linux, and mismatch in how the two work.
Compute etc is fine!
Yeah its best to avoid using the windows filesystem for anything else but a source of cp -r
/mnt/c etc from within WSL, and access to Linux FS paths are effectively a plan-9 file share service... Beyond this, if you use Docker Desktop (or similar) with volumes on the host OS (Windows or Mac) it's a weird FS sync between the host and container environment)... if you do volumes in WSL2 inside a Linux/WSL environjment it works fine (normally).
Permissions between Windows and Unix are always (generally) a mismatch, as is the nature of OS differences.
Hardly any different from mounting UNIX filesystems that don't obey exactly the same semantics.
WSL1 is not Linux because it is mapping system calls from the Linux kernel ABI to NT. That sounds like what you're describing. WSL2 is a Microsoft distro running in a VM that integrates into Windows.
I use WSL2 every day and it has some annoying quirks with how their Wayland implementation behaves with DWM, but otherwise it's just a Linux environment.
WSL2 isn't exactly a distro. there's CBL-Mariner, which is a distro used for utility/plumbing, but it's pretty hidden internally. WSL2 is mostly:
1) a lightly-patched Linux kernel
2) a bunch of esoteric bridge stuff, namely:
2A) 9P for mounting the Windows filesystem on Linux and vice-versa,
2B) a Wayland server implemented via RDP(?!)
2C) Hyper-V NICs, dynamic memory and other VM integrations.
2D) even weirder esoterica like whatever magic lets CUDA work (and... directx? for reasons??)
but there's no canonical (pun intended) userspace. there are many Linux distros available; adapting a distro is usually pretty easy. for example, NixOS-WSL is lightweight and works quite well.
philosophically, WSL2 is a VM, but it's not an emulator, if that makes sense. there's a kind of convergence between OS and VM that's been going on for a decade and WSL2 has been riding that wave.
(disclaimer: I work for MS but not on Windows or WSL. I just think the arch is neat.)
$ uname -a Linux MYPC 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Dunno, looks pretty Linux to me.
(WSL1 did suck badly because it combined the limitations of NT - slow file ops and process spawn - with the limitations of a compatibility layer. WSL2 is good enough for compatibility testing work on e.g. dotnet)
It's still running with windows as a host, and I've been met with friction and weird quirks in the interaction between them every time I have tried to use it myself, or watched someone else do so.
WSL 2.0 is literally a Linux VM running on top of Hyper-V, hardly any different of running a VM on a cloud vendor.
Nowadays WSL implies version 2.0, who is still using the half done implementation of WSL 1.0?
Or using Virtual Box, VMWare Workstation, QEMU,...
As someone who develops for both Windows and Linux I find WSL to be very useful. Much better than my previous method of dual booting Linux and Windows. I've yet to run into a problem that I needed to boot into native Linux for.
WSLv2 is indeed Linux... kernel and all... it's running in effectively a transparent VM with some utilities to aid in auto-mounting windows drives for access. WSLv1 used a translation layer (akin to WINE) to translate linux calls to windows calls. but WSL2 is indeed Linux.
Actually, WSL is pretty good for development. Of course, I wouldn't use WSL to run server software.
wsl2 is literally just a linux vm isn't it?
Yep, running on Hyper-V.
>> Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.[0]
Between that quote and "You can't fix stupid" I always choose the one about circus.
*nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink. It didn't even mattered what 99.999% of the scripts which utilized that call were the simple 'get file' and nothing more.
[0] https://en.wikiquote.org/wiki/Rick_Cook#The_Wizardry_Compile...
I think Powershell and .net coming to linux is very welcome because I can keep hosting stuff with what I believe is a saner platform, and Windows developers can still keep using the platform they prefer. It's a win-win.
IMO .net is much better than Java, at least it was 10 years ago. So it's not like I don't understand them.
C# better than Java the language, yes.
CLR is better on the polyglot approach, although Microsoft nowadays behaves as if C means C# and not Common, and ironically JVM seems to have a more vivid guest languages ecosystem nowadays. Any of Scala, Clojure, Kotlin, Groovy, seem to enjoy more activity than F#, VB or C++/CLI.
There are plus on the JVM side that Microsoft will probably never care for.
- A single vendor implementation, Microsoft no longer cares about ECMA
- Following from being a single vendor, there aren't multiple GC, JIT and AOT approaches to chose from
- Some of those implementations explore having most of the stack bootstraped instead of still being based on C and C++.
- One of them being a compiler development framework, whereas Microsoft killed theirs (Project Phoenix)
- Others offer real time GC, and embedded deployments in high critical computing environments, although less than 20 years ago, there are still three main vendors in this area
- A mobile OS, after Microsoft botched theirs when it was around 10% market share in Europe already, and now they don't have a platform for younger generations
Note that Java, .NET and C++ are my main toolbox tools, thus it isn't hating one over the other.
I just don't like the verbosity of Powershell myself... For that matter, I've trended towards using TypeScript (via Deno) for my user scripts that need more than basic shell interactions. I can reference any repository modules directly, use a shebang in the top of the script with self/executable, and no install step.
For that matter, deno in a shebang for an extensionless file now detects as a TypeScript file properly in VS Code. win-win-win. While being portable with a relatively small executable surface (deon executable only).
> I think Powershell and .net coming to linux is very welcome
It was!
I specifically talk here about a subset of people who was very ignorant but became very angry because... well, they are probably still write it as M$ so there is no point continue.
> *nix fanboys were totes fine with wget and ls being an aliases in PowerShell for years but when they found out what PS is coming to Linux they made a biggest stink
The curl and wget aliases don’t exist on the PowerShell 7 version which is the cross platform one. Only the old powershell.exe builtin to Windows has these aliases and it’s worse today because curl.exe is builtin and the curl alias takes priority when you run just curl.
Thanks, I'm with PS since v1.0.
> Only the old powershell.exe builtin to Windows
It's "Windows PowerShell" which would be forever v5.1 and "PowerShell" is v7+.
(we don't talk about "PowerShell Core")
> builtin and the curl alias takes priority when you run just curl
Yes, but again if somebody didn't bother to read the docs, read the output (it's very evident when you have some PS error vs. everything else - and people STILL don't bother to try to understand) and start bitching on the forums... see my previous comment.
And by the way: it was established quite early what the use of an aliases in the written code should be frowned upon, exactly for the reason what the aliases aren't stable and could be local. Aliases are the quick way when you are slapping something interactively in the CLI.
So wget/curl were added for the benefit of those *nix fanboys who needed something better than cmd.exe on Windows so they could start using PS faster and later adopt to a proper ways but instead of reading the docs they only rose the stink.
We had https://github.com/gerardog/gsudo long before this came out.
The hallmark of every successful Rust project: existence of a popular, equivalent software package not written in Rust.
That fact appears to be mentioned in the docs for this sudo, as well as mentioning gsudo has more features
(2024) At the time (587 points, 423 comments) https://news.ycombinator.com/item?id=39305452
Do you want to allow the following program from an unknown publisher to make changes to this computer?
Program Name: Sudo.exe
Publisher: Unknown
File Origin: Downloaded from the Internet
I was going to try to repro this, but it seems you can't actually download it and it's now a builtin? https://learn.microsoft.com/en-us/windows/advanced-settings/...
sudo sudo.exe
"Yes"
I'm surprised they didn't call it Run-AsAdministrator or some other awkward Microsoft-ism.
Maybe because that exists already? (and is actually more useful)
https://learn.microsoft.com/en-us/previous-versions/windows/...
I spent some time years ago going through a PowerShell course by the guys who wrote it. They explained their thought process and it actually made a lot of sense. Descriptive verb-noun naming to makes scripts readable, with aliases to make things quick and easy in the shell.
It’s easier to understand than names like grep, which require the user know ed and decades old history to figure out that it means global regular expression print. Without any *nix history, Select-String with an alias of sls, can make more intuitive sense and be easier to remember. The alias is also faster to type.
That sounds like PowersHell is similar to Esperanto - systematic and regular, but otherwise awkward and just doesn't have the staying power of a real, organically-developed language.
There's no need to "understand" "names like grep"; you learn it as a language like any other. If you aren't thinking of "grepping" (or cd'ing, ls'ing, fsck'ing, etc.) naturally and are always trying to translate the words into English (or some other language), you're doing it wrong.
That would imply it is written for PowerShell specifically ([1]), and would come with several expectations (like returning PSObject objects, and other good practices).
[1]: https://learn.microsoft.com/en-us/powershell/scripting/devel...
That would imply it is written in PowerShell. https://learn.microsoft.com/en-us/powershell/scripting/devel...
I strangely cannot flag my own posts. Can you delete that comment (and this comment you’re currently reading), since it’s a duplicate?
That would be consistent, which is not something Microsoft is capable of.
Lipstick on a pig, Windows is turning into a botched version of linux.
Windows always has been a Unix alter-ego since DOS 2.x which had started to accept '/' characters as directory separators, or maybe even before that.
I'm still betting on Microsoft buying Canonical one day and releasing their own distro.
I keep waiting for Microsoft to give up on maintaining their own kernel and moving to Linux. Kind of like what they did with the browser engine, and building atop Chrome.
Why would they ever do that though? Breaking backwards compatibility and losing all their work on the NT kernel for no gain?
It's not sudo for Windows, it's a pile of rust which, if you figure out how to assemble it, presumably turns into some Microsoft interpretation of sudo which, judging by all the open issues, might be an attempt at grep that went wrong somewhere.
If you want a proper sudo for Windows, use gerardog's excellent gsudo, https://github.com/gerardog/gsudo. Among other things it comes with prebuilt binaries and installers.
Unless this is improved greatly from the last time I used it is pointless, any command you would use it for instead requires you to right click, open as administrator a command prompt to get the expected result
https://m.majorgeeks.com/files/details/nsudo.html Been using it to run my cleanup or uninstaller utilities as SYSTEM/TRUSTED INSTALLER, so stubborn in use files that are not easily deletable not even with lockhunter or unlock file utilities that ultimately fallback to delete on next reboot.
With nsudo its fizz
> Everything about permissions and the command line experience is different between Windows and Linux. ... certain elements of the traditional sudo experience are not present in Sudo for Windows, and vice versa. Scripts and documentation that are written for sudo may not be able to be used directly with Sudo for Windows without some modification.
Then why is it named `sudo`? Just to create confusion?
Also, something like sudo is clearly not possible on modern Windows, because Microsoft thinks it owns your computer and won't allow Admins to do certain things.
It's wget for Windows all over again, just like with wget there's absolutely zero arguments shared between the two that do the same thing.
Ah yes, the 'curl' alias in powershell, vs the 'curl.exe' binary that uses the traditional options. Always have to remember that trap on windows.
Funny that this pops up when Linux at the same time is moving on to something better than sudo.
Are you referring to sudo-rs or something different? because sudo-rs is just a reimplementation of sudo.
No; I'm referring to run0. See, for example: https://edu4rdshl.dev/posts/new-year-new-sudo-using-systemd-...
Oh okay. That’s very specific to using setUID vs an alternative. Both have no real equivalent on windows to begin with.
Yeah, I’m aware of that. But this windows-sudo is sudo in name only anyway, so it seemed funny they’d copy a term that’s just about to go out of fashion.
The embracing continues
Not really. It's not the same program at all. They just took the name for an inexplicable reason. They even had to make a paragraph disclaimer stating it isn't and never will be the same program.
What's wrong with good old runas command?
The runas command doesn’t elevate just runs as another user. This is a console executable that drives UAC and also provides a way to capture the stdout/stderr elevated process which isn’t natively possible today without your own wrapper.
Sandwich https://xkcd.com/149/
sudon't
[dead]