Yep, it's really happening. Sudo is coming to Windows. It's obviously not just a fork of the linux sudo - there's enough that's different about the permissions structure between OS's that just a straight port wouldn't make sense. But the dream of being able to run commands as admin, in the same terminal window - that's the experience we're finally bringing to users.
I've been working on this for the last few months now and I'm pretty excited to talk about it or answer any questions!
My fingers are still starting to shake if I accidentally miss-typed the sudo password 2 times. Even on my own server, where the incident will be reported to myself!
Does the UAC prompt always say "Verified publisher: Microsoft"? Even without controlling stdin, malware at medium integrity could prompt to run a malicious command, and users will only see Microsoft's good name in the popup.
Does this elevate within your own account token (i.e. will not work for non-Administrator users), or does it actually switch user (e.g. to LOCAL SYSTEM)?
Putting Microsoft in the UAC prompt is indeed weird. It should be the info of the target binary. This feature sounds a bit rushed, and it's early preview, maybe they fix it by the final release.
Yea, that's a limitation of UAC at this point, and probably not one we can avoid. The "Show details" dropdown on the dialog does however show the commandline you requested, so at least that's one way of making sure it's the thing you ran
You say that like Microsoft isn't an incredibly deeply dysfunctional company with absurd turf wars and conflicting interests between all the teams. You'd think it should be sufficiently integrated, but it's likely office politics made that impossible. How about be glad we got this at all as a first step, then maybe it will build momentum towards a better integrated solution?
You forgot that because of backcompat this solution will now become the unchangeable standard for years and anything more integrated will be in addition, not a replacement.
And that's OP's fault how? We often have to work with the environment and framework we have, not the one we wish we had where we could just immediately implement the best possible solution.
Maybe for Windows 2025 we can work with the UAC folks to get something like that. I'm still shocked to this day that we managed to ship this at all. One step at a time :)
I wish my fellow posters could get out of their own way long enough to congratulate you! this is a great feature. I'm glad you got it into the build and I can tell you're excited about it. I can't remember the last time. I was excited about a feature that I shipped. maybe I'm just burned out but it's really refreshing to see it's shining through your replies. companies like Microsoft and Google need more engineers like you that actually care about shipping cool shit.
To answer the original question: I've been at MSFT like, 8 years now? And this is probably the third serious attempt my team has made at Sudo for Windows. (I think I heard of a couple other attempts in my tenure as well). After the last attempt, my mantra had always been "this is impossible to actually ship".
It's a tricky feature to ship, cause it is ultimately something that can be used as an escalation of privilege vector. Like, that's the entire idea. And there are a lot of people who (very rightly) get the ick when you say "we want to add this thing which can be used as an EoP to the OS image".
So, it's kinda hard to believe that after four years of thinking it was impossible, we actually managed to get it out the door.
If you can get the suggestion passed on, a simple way to run a process while _dropping_ elevation would be appreciated. Basically the _opposite_ of sudo. There should be a way to _easily_ drop permissions back to the standard desktop user (or lower?), like Linux's setuidgid. There's runas, but apparently that's not sufficient[0]; instead all I'm aware of is scheduled tasks and proxying through explorer, or leaving an unelevated process open and using IPC or other methods to tell if to run something else (none of this is easy in a simple batch file).
The biggest visibility into this issue is software installers, which regularly offer to launch the freshly installed program for the user's convenience...with the same elevated permissions the installer itself uses.
From the diagram on the article I see that sudo is elevated first, then the target program is launched.
Can't you call the target program directly? There must be a way, because explorer.exe is not elevated, and when you right click a program and choose "Run as administrator" you get a pop-up for the target .exe, not for Explorer.
Also the preference should actually describe it better
> Enable Sudo
> Enables the sudo command
If I were a scammer I could make up an acronym or something that sudo means and trick someone into turning this on because the toggle doesn't actually describe what it is so I can just weave my own narrative.
I think they should've named it something else to avoid confusion, especially if it doesn't have the same behavior as unix sudo. If it has different arguments and features, imagine the confusion of unsuspecting users searching how to use sudo in the future.
They've done it with curl: they made an alias to their own program not supporting the same feature set and it inevitably backfired [1]. sudo is a complex program with a lot of different options [2] and as people from MS said here, it's never going to be compatible because of how Windows works differently.
While I understand picking a familiar name, sudo is certainly not the only player, there's also doas. This shows people can adapt to another name and another name would have seemed more appropriate.
edit: whoops, it was already mentioned in this thread [3]
> sudo is certainly not the only player, there's also doas. This shows people can adapt to another name
The fact that doas has far fewer users, and examples everywhere show `sudo xyz` as the way to run xyz as root, shows that people do not adapt to a different name.
Microsoft has been trying, for years, to get developers to use Windows systems. This is another good step towards doing so.
The answer isn't to use a different name; the answer is to actually support most of the sudo interface.
But that said, there's a subset of the sudo interface that would cover the majority of what most people need on a regular basis:
-H (change home directory)
-i (act like a login shell, which may not be meaningful on Windows but could at least be ignored for compatibility)
Using sudo for a Windows program doesn’t seem as bad as using curl as an alias for Invoke-WebRequest. While the real curl can be installed and fully functional on Windows, sudo is intuitively an OS-level program that deals with OS-level access control.
I disagree. Although this "Sudo for Windows" is not a one-to-one port from Linux, it does the same function which is to elevate a unprivileged command. Imagine if they announce "Introducing Dosu for Windows", you won't know what the hell that is without reading at least the first paragraph.
That's an astonishing claim to make without evidence.
cat *.txt
is a pattern I see being used everywhere.
Same goes for sudo. If you're going to claim that a whopping 99% of users don't use the CLI options or /etc/sudoers, you'd need solid proof. Because a simple search shows otherwise:
This Sudo for Windows behaves nothing like the actual sudo. It doesn't even achieve the original's stated purpose.
Also considering that search results for anything involving Windows tends to be riddled with spams and outright scams, this will negatively affect non-Windows users searching for sudo as well.
> "cat *.txt" is a pattern I see being used everywhere.
That's an astonishing claim to make without evidence. I don't see "cat *" being used anywhere. In fact, I've just ran search for usage of "cat" over the repository of shell scripts that are used for the various packaging and deployment tasks in my company (and we have to deploy a lot of stuff, written in different programming languages, and every team packages their stuff into their docker containers in their own way but it's all still documented in this repo) and every single use of cat is either
a) reading data into a variable "VAR=$(cat file_with_data)";
b) writing inline data from script into a file "cat >>$TARGET_FILE <<EOF ... EOF";
c) an entirely reasonable use of cat "cat file | utility_that_accepts_filenames_too", sometimes even "cat file | utility".
None of them take a pattern or more than one file.
UPD: I've ran "cat *\." on the grep.app, and it seems that it's used mostly for bulk log processing; I vaguely recall we moved away from it to using custom reader scripts because the asterisk doesn't expands into the files ordered the way we needed.
The onus isn't on me to disprove that 99% of cat users don't care about concatenation, but here's a non-comprehensive list of projects using cat to concatenate files:
Half of those examples from git don't even invoke cat, another quarter don't concatenate files, and the final quarter use it for preparing test data. Well, I guess the last is a valid use although again, most of those uses could've used printf "$chunk_of_data" >>output instead of writing temporary files all over the temp directory, and I imagine the "git am" test could've been written as "git am patch1 patch2" instead. shrugs I guess it's 80% then.
UPD: And lots of people use "cat file1 >>output; cat file2 >>output" for concatenation anyhow [0]. Apparently shell already can concatenate things well enough, so cat should do one thing and do it we;l: dump a single file contents to stdout /s.
> Half of those examples from git don't even invoke cat
That's because it's a regex search and not relevant to the point at all. What matters is that people use widely advertised features of a popular tool, including sudo and cat. Especially if that feature is the single stated purpose of the tool.
Taking a name of a widely used tool and slapping it on something that doesn't even do what the original was made for isn't a nice thing to do. I don't get why that's controversial to anyone.
> so cat should do one thing
That one thing is con-"cat"-enating files, so to speak. Why should it become something different just to make the name Sudo for Windows appear somehow less misleading?
Also,
rm out.txt
for f in *.log; do cat "$f" >> out.txt; done
> "git am" test could've been written as "git am patch1 patch2" instead
This is off topic, but the Git devs were correct in doing `cat pine patch1 | git am`, since the test in question is
test_expect_success 'am takes patches from a Pine mailbox'
The test requires the mailbox not be split in two, so `git am pine patch1` is out of the question. patch1 is reused across multiple tests, so it makes sense for it to be in separate files. Concatenating is the logical conclusion.
cat patch1 >> pine
git am pine
is possible, but why? It's more code and it mutates the contents of files after initial creation, making the tests as a whole slightly harder to reason about.
PowerShell options are all single dash, tab completable, case insensitive, will match on the shortest unique prefix, and can be aliased with shorter ones like `-EA` is `-ErrorAction, and are consistent because the shell parses them not the cmdlet.
I always laugh when people from the unix side try to shit on powershell when powershells pretty fucking amazing and has a solid UX for just how many things ... work
Either way it’s done it’s an issue. Use a new name and it becomes a training problem, even for the most basic usage. Make it the same name and people expecting certain behaviors might get something slightly different.
At a basic level, I’d wager a vast majority of sudo’s usage is very basic, “run this command as admin”. If it can do that out of the box, it solves for a vast majority of users and they don’t have to learn some kind of new cmdlet to be able to do it.
This can't fully address the concern I raised. Their curl alias addressed the most basic / common usage and it caused issues.
I also can't imagine a different name to cause such a training issue. We are speaking about people who learned using the terminal on Unix and are using it on Windows. They are likely at ease with computers. If they are confused by a name change, I can't imagine how confused they could be at the first difference they encounter. The same name might as well cause more training issues. I'm not convinced.
The situation with curl is different because these are unix utilities you can run on Windows (hence the issue).
Now "sudo" is not a very Windows-y name for this utility but it has the advantage of being self-descriptive by those most likely to use it. It's sudo... for Windows. You don't have to explain it further.
The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.
> The situation with curl is different because these are unix utilities you can run on Windows (hence the issue).
Good point, the unlikeliness to ever run the real sudo on Windows makes it less an issue. Though doesn't remove it completely. You could for instance imagine a bash script (which you can run on Windows, since you can install Bash there) trying to use sudo if present, or something else, and fail because sudo is present but doesn't have the expected features. In shell land, the name of a command is almost an implicit contract.
> The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.
In practice:
- Programs are mostly cross platform so many "commands" can work on different OS. Which makes the command line namespace quite shared between OSes
- I've not seen many clashes. I can certainly remember of one: the Chromium browser and the Chromium B.S.U game. It was unintentional. The "sudo" one is. You can certainly avoid it.
> especially if it doesn't have the same behavior as unix sudo... imagine the confusion of unsuspecting users searching how to use sudo in the future.
It's hard to imagine a company that size would name it so deliberately without realizing it would cause confusion in search engine results and such.
A good faith assumption would be they wanted to make Windows more familiar to users of both but it also means that Windows will get mentioned in more Linux results over time to disambiguate it.
This really goes to show that no matter how legitimate a viewpoint (Microsoft is into EEE), there are always people looking to pretty unintelligently bandwagon.
Yes, we know. Internet Explorer, yada yada. Beyond the ridiculousness of the notion of sudo specifically being a target for MS, the notion that MS, or any company of its size, is THAT single-minded, is absurd.
Does it have a policy editor comparable to the /etc/sudoers file? Sudo is interesting not because it just allows to assume admin privileges for a moment; it allows to give access in a finely-grained manner, and not exclusively admin access.
Just scrolling through the documentation [1] gives some idea. Examples in the end may surprise the reader with the variety of capabilities.
This sudo for Windows doesn't either because it's not sudo. Looking at the docs, it's not even remotely compatible either. The choice of name here is unfortunate.
Nitpick: it’s not “Sudo for Linux”, it’s just “sudo” and runs on a wide variety of operating systems aside from Linux. It actually predates Linux by around a decade.
I have noticed that runas is mentioned as an already existing sudo alternative, but as far as I know, runas asks you for the administrator's password. sudo asks the own user password. This is how you give a non administrator user the right to use some application/tool without revealing the admin's password.
You're right, but on my work environment I have two accounts - "me" and "me with elevated permissions". (I don't say "admin" because there's still a bunch of stuff I can't do, like run netsh). I assumed that was the normal pattern in Windows-land?
It is something of the normal pattern, it always seems like companies love it. It always seems like UAC with extra steps to me. It's not that much more secure than taking UAC as-is and dialing up the security settings on UAC prompts to require a password every time. It's often amusing to me that everywhere I've seen require "secondary accounts" for admin permissions has dialed down the overall security settings of UAC below the defaults.
Hacker accesses some legacy application that verifies the user's credentials against LDAP. Maybe it's payroll or something. Hacker logs passwords until someone who happens to be a org-wide local admin (or worse yet DA) wants their paystub. Hacker now has admin privileges.
(Also, if UAC settings are turned down, that might mean the UAC prompt isn't on the secure desktop, and any malware can thus trivially elevate itself if your everyday account is an admin... etc.)
Right, I don't think runas has a "sudo-mode" in terms of "let the user elevate their own permissions for specific tools even if they don't have an elevated account to elevate to", but runas is so low level and has so many weird combinations of arguments that maybe there is a buried similar way to that, I can't say for sure.
But the base "sudo" case where you have an account that supports UAC elevation (you are your own administrator) runas definitely supports as the CLI way to invoke UAC prompts for your own account, not just other administrator accounts. (Using the /trustlevel flag accordingly, as I recall.)
My question is more why they couldn't add this functionality into runas, rather than making a new tool that doesn't even do what its name says it does :)
It only explains what is different between sudo and runas. It doesn't really explain why they couldn't just improve runas and add those missing features instead of creating a new command. As it stands now you seem to need both sudo and runas to cover all reasonable use cases.
Backwards compatibility and changing the security dynamic of existing scripts. I'm sure it is probably possible to achieve using runas, but my guess is that it would greatly delay adding this functionality, as they would have to cover all concerns for which runas is used.
I really hope that sudo is going to allow one to capture the output of the thing running in sudo and handle errors better. I recently wrote an installer script in PowerShell and had to go through severe contortions to support privilege elevations for only a minimal part of the script. I needed to use start with runas to relaunch the same script with different options to continue the installation process and there's not much in the way of proper error handling either.
I think there can be harm done when a re-implementation, especially a heavily divergent one, takes the name of an existing program. There's a reason OpenBSD introduced "doas" instead of calling their new thing "sudo".
Reminds me of when PowerShell decided to have "wget" and "curl" cmdlets that didn't have any of the advanced features of the originals. Naively it sounds helpful. But it introduces confusion.
Nice to see the author here! I have to say: I really like whats going on in Windows world from a developer perspective in the recent years. I am a hardcore Linux fanboy for decades but I have to admit that PowerShell, WSL, vscode, Windows Terminal and the recent open source strategy sounds very appealing to me. This is something MS/Win does much better in recent days compared to, for instance, Apple/Mac OS.
I would love to see a tighter integration of winget into Windows. I recently used a fresh MS Windows Server 2023 installation and had a bad day to even get winget installed.
I really hope that the current strategy does not turn out as somewhere between "embrace" and "extend"...
Only problem is Powershell's commands are abysmally slow in comparison to chaining together Linux terminal commands that are written in C.
Powershell is a super neat language though.... especially if the Microsoft team that manages it would work more with the team that does more for SMEs and not just DevOps. The overwhelming majority of windows users doing regular business work have to deal with crufty stuff like VBA or over engineered stuff like C#. I was really hopeful for Powershell, but it seems like it's almost entirely to serve IT administrators or software developers. I wish that very capable team would do things like add a fairly simple GUI DSL or form designer with the tool. I know it can hook into WinForms, but that's a lot of effort and requires more C# background. There are probably millions of business analysts that would love to build little simple GUI apps without investing weeks of effort. The current approach is to just use Python, but that has it's own bag of problems for those that can do a little coding, but aren't full time developers. It just seems weird that Microsoft never invested in a language for SMEs that would integrate well with the OS and Microsoft apps and tooling.
Powershell is a terrible "language". It's fine for sysadmins to do sysadmin work but why would you want to subject business analysts to that level of unix shell inspired weirdness. Microsoft already has VB.NET which would serve that market much better.
At least it doesn't let you do this (as far as I can tell) so it seems slightly better in that aspect:
value="1 -o 1"
if [ $value -eq 10 ]; then
echo "Value is exactly 10."
fi
The syntax is terrible, though – if these operators are not actually options for a command, which is the context where the leading dash makes some kind of sense, why make them look like that?
Also, why does the documentation[0] talk about statements returning values? I've never seen the terminology used that way before. Usually expressions evaluate to a value and statements can consist of an single expression.
They didn't need to copy any awful shell syntax. We have decades of programming language development but Powershell cribs from oldest and most cobbled together environment. Give up on the old syntax for IO redirection and piping.
I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many. It's still all objects and methods underneath but you can't auto-complete anything.
> "Give up on the old syntax for IO redirection and piping."
Handwaving away decades of muscle memory and expectations for > and | seems bad, but those are the easy cases, and you've avoided dealing with the operators which are not symbols and the case sensitive/insensitive variants of common operators. What do you suggest for syntax instead which handles all, or most, of the cases PowerShell handles?
We have had "decades of programming language development" but I'm not aware of any which do what PowerShell does. I haven't spent any time on OilShell or NuShell or other Unix-shell-modernised systems, but Python syntax and behaviour does not make for a good shell, nor do any other programming-language-with-REPL that I've used. What language are you thinking of which makes a good compromise of both shell and pipeline and programming language, which would also work in the Windows world where things aren't text (PowerShell design priority)?
> "I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many."
On a computer system where many thousands of things are possible, specifying what to do by command line is going to require typing one thing for every option you need to specify. Whether that's in the command name, in the command options, in the arguments to the options, or externalised in some ENV variable or /sys/ namespace or some /proc/ data source or some /etc or .dotfile config option, or hiding in some JSON structure, it's only shuffling the complexity around. At least with many commands they are organised into modules, searchable, and can have associated help.
> "you can't auto-complete anything."
*date*<tab> cycles through all commands with 'date' in their name. Cmdlets and binaries and functions.
hyper-v\*failover*<tab> cycles through all cmdlets in the Hyper-V module which have 'failover' in their name.
Get-Command -Noun VHD searches for commands with VHD as the noun part of Verb-Noun.
Get-Command -Parameter VlanId searches for commands which take -VlanId as a parameter (e.g. Hyper-V\Set-VMNetworkAdapterVlan).
Thanks! I think the team we're on has a very clear focus on making developers happy. Like, we're all ourselves, developers, so a lot of it is very self-serving. Anything we can do to make our own lives better is probably going to be a good thing for a lot of other developers too.
I use WSL2 a lot because my current employer is a "Microsoft" shop (despite all the code being deployed in Linux containers).
For us developers, the changes in Windows to support WSL2 weren't really an enhancement of Windows, it's now just a really complicated way to run Ubuntu. As in, Windows 11 is the biggest Linux bootloader in history.
sudo for Windows...can't even see a use for it any more.
Windows change is welcoming, yet still not quality. As stated by someone below, sudo is https://www.sudo.ws/. Microsoft should give it a proper distinctive name lie wsudo or psudo. Little thinks like is compounds the issues with Windows / Microsoft.
Even continually sticking to old design patterns causes issues in development and deployment. Big name companies do not trust applications running on hosted Windows because of their current business practices. Microsoft does not even have a means to provided ease of deployment for air-gap system. This is the only way some big business will let products hosted on Windows to be in their facilities.
Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.
Localization translation text standard still does not allow for containing singular and plural in the same key. Translations should be easily to update so the client can improve wording on the fly. Microsoft still recommends using resx and compiling a DLL.
Is that really what companies have to do to "trust Windows"? From my experience, it's rather driven from the need to look compliant. Thus, managers without in-depth knowledge decide to buy "endpoint security solutions", the more the merrier, deploy them to your machine, and that brings things down to a crawl.
Why to a crawl? Well, I've witnessed multiple antivirus products go bezerk on your dev folder if you compile C++. Turning them off for this folder increased performance by a factor, which is what's typically done and completely subverts the purpose of these products.
Also, I witnessed a certain product with a bird of prey that would run for hours and then just crash on a directory with a few million files.
This combination of sub-par quality of "security" products and performative deployment of endpoint security is a bane, at least for me as an enterprise software developer. I don't see Microsoft being primarily at fault there.
Most businesses that use Windows and/or Microsoft products do no go through all of that. The main benefit of using Microsoft is all of the integration between development products and DevOps. Most of the solutions for security are not provided by Microsoft, and often are looking to check off boxes to make auditors feel better, without actually enhancing anything. I've had to create some bizarre workarounds just to get past auditors, and in the end the solution was no more secure than doing nothing at all.
>Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.
This is a big issue for me. I'm stuck using Windows for work, and it runs like an absolute dog even on good hardware.
I'd love to see winget with a command structure that makes sense. Currently if I want to install python via winget, I have to run `winget install -e --id Python.Python.3.11`. -e? --id? What are these for? Why do I have to memorize them? Almost every other package manager just does something like `packagemanager install python`, and then you can supply args for versions if you like.
Also winget does not have python 3.12 which was released 4 months ago.
But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?
> But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?
Those sites give you the command line exact match (-e) --id as a safety precaution so that you install exactly what you were looking at on that website and not a fake or similarly named but different installer or a different version than what you expected.
The complicated way is optional, you are using two different options: -e and --id. The CLI's default is actually sloppier when you don't use those two options in that way.
It seems easily discoverable from `winget --help` to me. But I tend to use `winget search` rather than websites, so maybe I'm just more familiar with it.
I've been using the 'sudo' that scoop offers for a while, and it has always done exactly what I wanted and completely removed the hassle of having to open a new cmd/powershell with 'run as administrator'.
Plus it means I don't have to leave the comfort of Tabby.
Honestly, the hardest part will be porting the Settings app changes to the Windows 10 styles. `sudo.exe` itself doesn't really depend on any OS platform changes, and if it did, we'd have a _very_ compelling case to bring those features with us downlevel.
I'm not even sure Win11 is on my company roadmap, much less anything cutting edge like an insiders release. Windows 10 Enterprise compatibility is pretty much required for widespread adoption of Sudo for Windows.
Windows 10 is EOl next year. I would bet your company has plans to move to 11 at some point in the near future. I work with customers daily to help to move to 11
Apparently, because you can't seriously be asking that question. You've clearly never worked in any kind of customer support position, because businesses and individuals need all kinds of help with a transition like that.
>Apparently, because you can't seriously be asking that question.
YEs I was asking seriously. You still haven't explained what those challenges could be. All you do is mock people for their genuine questions without providing any actual answers/information to back up your vage statements.
>You've clearly never worked in any kind of customer support position
Then if that's clear for you I haven't never done that, why would you not understand I was being serious? Why are you being disingenuous here? Or you just enjoy being a troll?
> because businesses and individuals need all kinds of help with a transition like that.
Mate, 12 year-olds in my developing country can run Windows 11 updates/installs for you, including installing pirated licenses and cracks for you if you pay them 5 bucks.
What could be so complicated that the internal IT of a company can't figure out the transition from Windows 10 to 11 that they need to pay outside help for that? Especially that backwards compatibility is one of Microsoft's fortes to make life easier for admins and convince companies to stay in their ecosystem.
Many small and medium companies don't have any internal IT. Maybe the original parent commentor works for an MSP / outsourced IT services provider / as an IT consultant.
> "What could be so complicated that"
Windows 11 has hardware requirements that Windows 10 didn't, their equipment may need to be reviewed/audited or refreshed - planned, budgetted, quoted, ordered, received, checked, configured, user data migrated over for dozens of devices. Business customers need to buy Windows Pro not Windows Home - and need enough IT experience to know that, non-technical companies may have bought some Windows 11, had problems, and needed to call someone for help. A company might have some internal IT who could do it, but are busy with other projects and don't have time to plan and execute an upgrade. Windows 11 comes with new Group Policy templates which need importing to a Windows domain and configuring - and may need reviewing or auditing for regulatory compliance to see what needs setting up and the parent commentor is some kind of compliance person helping with paperwork instead of a technical person. A company might take an upgrade to Windows 11 as a time to change other things like a move to Microsoft Cloud Services (OneDrive, Microsoft account for login) and each user needs to be given a new laptop and have all their settings moved over. A company might have specialist software from vendors who aren't very progressive - e.g. optician's software which manages retina scanning cameras - and needs lots of time consuming hand holding with the vendor support line before the vendor will agree to the move, even if it would in principle work fine. Regardless of technical issues, the upgrade could take an hour or two per machine, over dozens or hundreds of machines, that's either a big interruption which needs planning (staged rollout for different departments, say) or needs some automated way to deploy it which needs setting up, testing, and checking on, and may just hire some temporary contractors for more people to do that. There may be users who could do it, but won't because it isn't their job, or aren't allowed to by their manager or union so it isn't their responsibility if it goes wrong.
Does this mean that I can run PSWindowsUpdate in a remote PowerShell session? If so, this is going to save me a lot of time. Also, AD management tools never work vie Enter-PSSession. Will stuff like that work as well?
It seems interesting to me that Windows integrates more and more elements of Unix.
Linux is open source and free, Apple develop an OS that sells specific hardware, and historically Windows has sold the software for generic hardware. Windows is unlikely to become a better Linux than Linux. Where is Microsoft's new business model going?
Historically Office was a money maker, but Office online is a shambles and many users interact with Office via this interface - I see Office slowly dying in favour of open source options. I see Windows licenses being sold less and less in the future. Microsoft Lens is essentially buried at this point. There are the Surface laptops/tablets which are good but not special. Dedicated games console hardware will likely become less attractive as they slowly become glorified desktop PCs.
I don't see Microsoft with big user shares in the software or hardware industries? There were a few good purchases such as Minecraft, GitHub (+), etc [1]. Is there something I'm missing?
"Microsoft revenue was $198 billion in 2022, up $30.2bn (+18%) from a year earlier. When we do a breakdown by product streams, the largest source of Microsoft’s revenue was Office, with $44.9 billion (23% of the total). Just behind in the second place was Azure with $44bn of revenue (22% of total)." - https://www.kamilfranek.com/microsoft-revenue-breakdown/
Office alone increasing by $5Bn revenue in a year, increasing by $24Bn in ~3 years, being the largest chunk of revenue of the most valuable market-cap company on the planet, that's what counts as "slowly dying"??
i guess id say thanks for all your hard work, but i dont use windows.
exactly how is 'sudo for windows' different than the existing model in windows 10 where privilege elevation is a popup window and you click through it? arguably the current model is just sudo with nopasswd.
how do you reconcile the idea that your effort --without principled reform of the windows security model at a fundamental level-- is just cargo-culting a more successful projects security model?
'Start-Process powershell -Verb runAs' is the same or different than this?
Thanks for caring about security and trying to make things better. its hard, thankless and frustrating (and thats just the windows part ;))
Isn't running commands as admin, in the same terminal window, already possible via the use of runas.exe? Granted I haven't daily driven Windows in years but IIRC that does the job albeit with clunkier syntax.
runas doesn't support "same terminal window", it always has launched a new window.
It's possible this sudo could have been implement as yet more clunky flags to runas, but it seems like making it a separate tool has benefits: off by default, whereas runas is a nearly always-on required built-in; more importantly a nicer less clunky syntax.
Yes terrible move which will lead to much confusion and consternation in the future.
But honestly I'm most amazed by the fact that there wasn't previously a way to run commands with elevated permissions in Windows. How did people work like that? Just run everything in an admin terminal super unsafely?
As a self-identified linux engineer who, despite tremendous efforts to avoid it, has somehow managed to still spend about half my career having to care about windows in some way... the answer to "how do you do [thing] on windows sanely?" is generally "it is simply done insanely instead."
Am I biased? Haha yes, I have a signed copy of Free Software, Free Society. But also I have spent years caring about products that do need to work on windows. And my professional take is "there is always a way to do it, but it is very seldom pretty." (And my take for linux is "there is always a way to do it, often more than one, and at least one of them is going to be pretty, but which one is the pretty one will depend greatly on who you are and what you're doing").
There is runas to run as a different user. And if you want to run as the same user but elevated, there has been third-party software like gsudo [1]. But yeah, the recommended way to do it was to just open an elevated terminal, run the one admin command you need there and close it again. Not a huge deal if all you want to do is run a choco install command or something; and generally you don't switch so much back-and-forth between needing admin and not needing it.
You have to think about what terminal you need before opening it. I rarely need an admin terminal. That software is often installed by downloading and double click helps as that cuts out the command line. Devops is tricky though! You sometimes have to spawn other processes to get the elevated permissions.
I guess the reason it strikes me as strange is, on linux the usage of `sudo` helps you understand which operations might be dangerous in a fine-grained way
So like if you are executing a series of commands, the one requiring admin privileges tends to be one you might want to be more careful about (i.e. altering system configs, or doing a potentially insecure operation)
So if you are running everything in an admin terminal, it seems like you wouldn't have that extra check to remind you to be extra mindful of a particular operation, since everything you do in that terminal is in the same bucket
I think generally people rather treat everything they do in the admin terminal as dangerous, and do everything else in another terminal or in the GUI. The typical windows admin experience happens on a GUI, even when remoting in, so the idea of using multiple windows for multiple things is more natural than in the SSH experience typical in the linux world
Another commenter in a different thread mentioned wsudo could be a better name and I was thinking the same.
It doesn't really bother me personally either way, but I understand peoples' concern. I didn't mind the wget and curl aliases. I find myself autopilot typing 'ls' in PS quite often and I'm glad they aliased it to 'dir'.
As a regular Windows, Linux (via WSL), and macOS user, I'm not confused by the curl/wget alias in Powershell, and I appreciate it. I understand from context that it's not actually curl and has different options. It's much easier than remembering whatever Invoke-HyperText-Transfer-Protocol-Request -Url incantation that's native to Powershell.
I already use https://github.com/lukesampson/psutils which has a sudo.ps1, which I install via scoop (I know that's a mouthful, but I just install scoop and run `scoop install sudo`). I used it from powershell literally just before I opened this article (after copy-pasting a password, I copy some random text laying around in the browser, like "com", then run `sudo restart-service -name 'cbdhsvc*'` to clear the clipboard history -- does not clear the current value). There is a UAC prompt, but it's perfectly adequate for interactive work.
Same here, and if you look at the output of whoami /priv you'll find that using luke's sudo provides exactly the same priviledge escalation as 'run as administrator' does
Not sure if this is the same thing, but this definitely should have shipped with the very first implementation of "oh, sure, you're an Administrator, but not really, since we're ignoring that bit" a.k.a. User Account Control.
That would have saved about a metric ton of misguided "here's how to turn off UAC" tutorials, but, ehm, yeah, anything to inject some life into the moribund Windows Insiders Program (the one where https://blogs.windows.com/windows-insider/ proudly headlines "What’s coming for the Windows Insider Program in 2023"), right?
gsudo is great! It's got a lot of features for power users, it's got a great community, and I can't recommend it highly enough. There's room here for us to be better together - Sudo for Windows can cover a number of in-box scenarios, with OS-side support for things like GPO, event logging, etc. But then for power users who need access to some of the wilder features of gsudo (running as TrustedInstaller?), that's always available too.
I would love it if I, as a lifelong Windows fanboy, could offer anything but a snarky reply to the author of a new OS feature. Yet, good luck with that and don't look at the headstones of those who came before you is all I can muster.
> If you’re looking for additional functionality that Sudo for Windows does not provide, check out Gerardo Grignoli’s gsudo which has a number of additional features and configuration options.
When I was at Microsoft we did not use to consider UAC as a security boundary, since there were ways to bypass it. (I used to work on windows kernel security). I wonder how security team let this feature get shipped. Or perhaps now they consider UAC as a security boundary.
It's evident that you haven't used PowerShell. Almost all commands in PowerShell have short aliases. For instance, instead of typing 'Get-ChildItem', you can simply use 'gci', which stands for the first letters of each word. Unlike Bash and other shells, where you must learn various Domain-Specific Languages (DSLs) to handle XML, JSON, YAML, etc., PowerShell allows you to use its native language to work with any data type. This is because PowerShell operates on objects rather than plain text. Therefore, PowerShell is significantly more advanced than other shells.
Yes. But if you Program, you do NOT want to use the aliases as they make your program hard to maintain over time. Little equivalent to banning short options and preferring long options in shell scripts. It makes the intent much clearer and your future you will thank you 6 months after the script was written when you have a bug to squash away...
Yep, aliases help. Also, verbs are standardized. That example was a bit hyperbolic.
Most of my work is in Linux nowadays, but for me, jq, yq, and other text manipulation software and shell features in bash/zsh will always take a back seat to using the standard commands that ship with PowerShell. I wince every time I see a co-worker using a pipeline full of parse-and-pray greps and awks that is fancy af and amazing, but also, maybe not as nice or consistent as working with objects.
I will say though, you might say "PowerShell is more convenient in many scenarios," not that it's more advanced.
Yeah I tend to use both. For some more involved scripting sometimes the verbose command proper names are nice as it reads better, but the short names are nice when hacking
We've actually done that for a few years on the Terminal repo. It's great for things like megathreads / scenarios / epics. For example, I can tell you off the top of my head that microsoft/terminal#8888 is for "quake mode", and #4000 is the extensions thread.
We even used to have a bot that would auto-camp anything that was a multiple of 1000 or 1111 :D
I guess this is a thing on Windows now. However at the moment, it seems to be a very insecure thing. But hey it's early days... I predict they'll eventually get it right 125 patch Tuesdays from now.
Happy to have the feedback! Most of those I've already fixed internally, there's just a 3-4 week delay between me checking in, and it flowing to Insiders.
For the other few things I missed: Very happy for the feedback! I've filed bugs and those'll be the first things I look at come Monday morning.
Sad that it's Windows 11 only. I can't upgrade. I have a normal, recent PC that I dual boot with Linux, and Microsoft wants me to keep Windows 10 in that constellation. Upgrading is prevented by a silly if statement, and there's nothing I can do. It's the first time a software vendor actively doesn't want me to to have their latest software, but it is what it is.
Unless there's official documentation that this is officially supported, hacks like these can stop working at any moment. For an unimportant machine, sure, use whatever third-party tool to bypass the installer you want. For a production machine, I don't think that's wise.
Here's hoping that "Windows 12" will be just a Window manager + Desktop running on Linux, with all existing bugs meticulously replicated to maintain backwards compatibility with Windows 95/7/8/10/11.
Stop dreaming. Won't happen. Windows is a purely additive effort. WSL is what happened, and when it couldn't do some things they built WSL2.
As another commenter pointed out regarding the integration of this new "sudo" and UAC prompts, it will probably be done in a new, separate, different tool, because this new, freshly released "sudo" will now have to remain bug-for-bug compatible for the next four decades.
To be fair that would still make windows instantly so much better if you could actually run a less weird desktop environment AND run all the vendor locked software.
If that ever happens, it'll bring Microsoft dependencies to the Linux ecosystem. In not sure that's a good thing anymore with the endless enshittification going on in Windows. Just imagine the poor distro maintainers constantly battling to disable spyware, ads, nag screens, and unwanted configuration changes caused by Microsoft packages. I feel sorry for them just by thinking about it.
> runas allows you to run programs as other users, including but not limited to as administrator. This funtionality is on the roadmap for the sudo command, but does not yet exist.
Initially I thought ur concern is crazy as hell, because who would implement it in such a painful way?
But then I read
>When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation:
LOL
But it seems like there are other ways to use it without this dialog
>In this configuration, sudo.exe will launch a new elevated console window and run the command in that window. The new window will be launched with the same working directory as the current window. The new window will also be launched with the same environment variables as the current window. This configuration has a similar flow to the runas command.
There's no way that second use case doesn't show a UAC prompt.
The whole point of the split token / UAC elevation is to avoid elevation without user interaction. Imagine malware stuck as standard user just running itself like:
Opening another terminal is one thing this new sudo can do. It's also possible to configure it to run the sudo'd command inline in the current window (mentioned in the linked blog post); there are security tradeoffs to consider.
Seems like a horribly convoluted way to manage permissions. Also I have never heard anyone suggest you shouldn't use a local admin account. That's the exact problem UAC was meant to solve.
Having used an unprivileged Windows account, all I can say is no thanks. It's a huge burden if you do anything even slightly more complex than Facebook and email.
As a blanket policy at work, all programmers are admins, everyone else is not. Except when someone is doing a task that requires elevation every five minutes. I'm the only admin on site and it's an unbelievable waste of my time to sit next to someone so I can put in my password every time they click a box. We make those users admins because there's simply no other way to manage it.
Nobody does what you describe. When someone has a genuine need for local admin access, they are given two accounts - an unprivileged account to log in with, and a privileged account to enter into UAC when needed. It would indeed be an unbelievable waste of time to make your IT staff sit next to users to enter admin credentials, which is why nobody does it.
And for the record, "don't log in with a local admin account" is a very commonly recommended best practice for Windows environments. It's unusual that you've never encountered it.
"Nobody does what you describe" is a very... broad statement. I can tell you that "all devs are local admins" is indeed a very popular policy, and has been the case everywhere I worked in the past, oh, 20 years or so - including Microsoft itself.
Counterpoint: I've never heard anyone do what you describe. Therefore no one does it, even though you've just described to me who does.
What exactly is the threat in using a local admin account? I can't think of anything you could do that wouldn't show a UAC prompt. The entire point and purpose of UAC was to prevent malicious elevation without the user's knowledge. I'm really not sure what you accomplish by adding a password to UAC prompt the user wouldn't have read either way. The end result is the same.
> Also I have never heard anyone suggest you shouldn't use a local admin account.
Only every security audit under the sun. If you work for a sufficiently large organization subject to industrial or governmental regulation, or even carry particular insurance policies, third party audits will flag these practices as liabilities, because its boilerplate recommendation for how a managed windows environment is deployed.
You may work for a large organization where you get local windows admin. Exceptions can be made if a good story can be told about compensating systemic and detective controls that sufficiently mitigate the risk.
However I promise you that someone in that organization closer to security strategy and compliance gets grief over the posture at least annually. Those people shelter you from worrying more about it.
So Microsoft implicitly admits DOS sucks and creates a PowerShell prompt.
Then Microsoft doubles down and introduces a better prompt called WSL - the Windows Subsystem for Linux because the Windows command prompt still sucks... and this is just a Ubuntu VM in Windows.
And now they implement Sudo?
Microsoft hasn't learned the first lesson of holes - when you find yourself in one, stop digging.
This doesn't make any sense. PowerShell and WSL serve entirely different purposes. PowerShell is bash-but-better for Windows. WSL is a developer-oriented way of running Linux/Unix software on Windows.
This is a really good illustration for why I hate using Microsoft products. They don't commit to one vision long-term. They build a bunch of competing visions, and all feel half-assed. From a user's perspective this means that if I want to perform some task I likely either have a clunky experience, or worse, I end up having to use multiple similar tools to do it.
Reducing WSL, which can virtualize multiple Linux in parallel, including Linux GUI programs, use GPU and run Docker at near-native speed, to a mere prompt seems dishonest.
I wish they committed to implementing more of the POSIX standard instead. They only ever implemented an initial version, and then added tiny parts of it in incompatible ways.
Opening a terminal in admin window which means any commands you put in that windows will always have admin privilege, no matter what.
What does Sudo is to only provide the root/admin privileges for specific inputted command. Once it is done, it goes back to user privileges. This way, the terminal window didn't need to end the session to go back to user privileges.
"Admin"'s identity is the resource you're asking permissions to use. If don't want identities, are you going to manually authorize every file that needs to be interacted with? For a recursive delete of thousands of files?
Sudo also allows you to control which commands can be elevated to admin.
It also lets you elevate to admin without knowing the admin password, you elevate with your normal account password. Effectively, some commands can execute as admin, but the user generally cannot.
So you can allow limited administration without giving everything away.
Good thing they're keeping the admin terminal too so you can just keep using that.
Personally I think it's way more likely the admin command is the one off like installing something, changing a setting and then everything else before and between it are user commands that don't need to be in admin space most of the time.
> Just that you can run a single command as admin?
I mean, that's sudo's whole thing! [1] You can live your day to day terminal life without the risk of borking things too badly, then when you occasionally need to elevate to higher privileges you can do it easily for that specific command.
[1] Technically not the whole thing obviously, but it's a very common use case.
> This looks like one of those KPI fulfilling projects
It actually wasn't. This has been one of the top community requests for the Windows Command Line for years. Literally, for like, the entire 8 years I've been here, we've been talking about if there was a way to do Sudo for Windows.
This was done because it makes developers happy, plain and simple. If that's a KPI, then that's the one we're optimizing for.
There are several ways to do sudo for Windows already, to the extent this program does sudo for Windows.
In other words, you're not actually solving the reason people are asking you for sudo for Windows. How do I configure my sudoers policy to allow someone to run a specific application (and only that application) through sudo? THAT is the magic of sudo. Sudo is not just "use your own password for root" like you seem to think it is.
I live by a one step at a time philosophy. It's better to make some incremental progress here, now, and open the door for future progress in this space too. Just like the Terminal - what we're putting out here in the first versions is just the first thing we feel comfortable with people using. We've got lots of ideas for more things to add, just, one step at a time :)
I don't know why people are so negative on this project. I already know about gsudo and yet I was still happy to see an official solution! Even if it were to never evolve, not having to pull a third-party executable in is always nice.
I'd say waking up today to all this... negativity? was kinda a bummer. We've been working hard on something that people (myself included) have been asking for _for years_.
Like, obviously, it's not perfect out of the gate. That's fine! It was a haul enough to ship this in any form. Now that it's out there, we can make more and more improvements. One step at a time.
Sometimes, I just need a break from the internet I guess.
Because it isn't sudo. It's a marketing effort stealing the name of sudo for a completely different technology that is only tangentially related to sudo.
> You can choose to connect the elevated process to the current console window with the disableInput and normal configuration options. This is not supported with runas.
I also thought that using current environment vars you have set/changed in the terminal is an extra benefit, but that's not listed, so it's not?
That requires you to open an new terminal window. You've never been working in a standard terminal, tried to run a command that requires elevation, and been annoyed that you have to open a new window losing your command history?
Or forgot to Run As and opened a non-elevated terminal by accident?
I believe the new window is to prevent SHATTER attacks (https://en.m.wikipedia.org/wiki/Shatter_attack), to ensure that a higher privileged process has a higher privileged Window. Is that not a concern anymore with this new sudo, or is there some other mitigation involved not?
EDIT: from the linked wiki page, "By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there."
"In this configuration, Sudo for Windows will open a new elevated console window and run the command in that window. This is the default configuration option when sudo is enabled"
In these configurations, sudo.exe will launch a new elevated process, an elevated sudo.exe process, and the original unelevated sudo.exe will establish an RPC connection with the new elevated process. In other words, information is passed from the unelevated sudo instance to the elevated one.
Yep, that's basically the entire diagram. The information that's passed is basically just the commandline, env vars, and a handle to the console of the unelevated sudo's console. Once it's got a handle to the console, the elevated sudo can spawn the target app attached to the original console, rather than a new one. Simple as that!
In all honesty, I have the same reservations. If you look at the authz schemes between the different flavors of operating systems you see that the 'set-uid' concept is comparatively ancient, battle hardened and based on well understood mechanisms.
This new functionality in Windows looks complicated. There's an architectural picture that involves:
* Multiple processes
* Windows RPC (On the basis of RPC? DCOM?)
* Handle inheritance
* Process integrity(?)
* Token privileges(?)
When UAC was introduced, there was a slew of bugs in the underlying RPC mechanism. I wonder if it will be the same. Can't wait to take a look at this in the debugger :)
I also wonder if MSRC will consider this a "security boundary". Based on the fact that the text references process integrity(UAC), and that _is not_ a security boundary, I'm going to guess not. That means that this could potentially introduce bugs, but MSRC will not be handing out bounties to fix things. Which means that any bugs people find are less likely to be reported, and more likely to find their way into ransomware down the line.
While this looks more secure than the original, I don't think modern operating systems should be investing resources into making privilege escalation easier for users to do. Considering UAC already exists it's not like the additon of sudo is much worse to include so overall it may be better, but I feel investing resources to get rid of the need of users needing to elevate things would be time better spent.
One of the most important aspects of ‘sudo’ is that it takes the password of the user who started it, not the admin password. Will this ‘sudo’ work like that, or does it need the user to know an administrator password? If it needs an admin password, it shouldn’t be called ‘sudo’ (it would be an analog of ‘su’)
I strongly doubt they would ever do something that drastic. It offers few benefits and many roadblocks. It would be a monstrous amount of work, would throw into question many existing security-related certifications, break Microsoft's love of backwards-compatibility, etc.
Also known as, you don't know technically anything about Windows.
There is a very big difference between supporting UNIX, and Linux kernel syscalls ABI on top of pico processes, the technology from Drawbridge kernel taken out from Microsoft Research, which incidentally is also used to port MS SQL Server into GNU/Linux.
As for the rest I could provide examples of how the BSDs and Solaris failed in similar attempts to clone Linux syscalls table, despite being UNIX, before Microsoft's attempt, but who cares?
> As for the rest I could provide examples of how the BSDs and Solaris failed in similar attempts to clone Linux syscalls table, despite being UNIX, before Microsoft's attempt, but who cares?
the BSD approach is still supported and part of FreeBSD, so presumably someone cares about that
Why not just keep the existing kernel running with a small team? Drivers and backwards compatibility are critical to many of Microsoft's enterprise customers.
Now that isn't necessarily true for Windows running in the cloud. Drivers don't matter as much there.
I don’t disagree. How I think it will happen: Backwards compatibility will start to stray at Microsoft (their last bastion), leading to WINE becoming the go to tool for backwards compat support. Microsoft will create a linux variant or maybe just a DE and the rest will be history (just as Libre Office has begun to supersede MS Office). It is a matter of will and time that C-Suite will want to eliminate labor around Windows to maximize profits as it becomes more and more hardened in it’s feature set. Why maintain when you can utilize FOSS?
In what business segment is Libre Office superseding MS Office? Furthermore, NT supports "personalities". Why bother with a full Linux kernel when they could adopt the personality a la SUA?
There are security implications for running elevated processes connected to unelevated console/terminal windows. "New window" mode avoids those security concerns. A secure-by-default posture seemed prudent.
Interesting. I've been pretty happy with all the Unix-related updates they've put out lately. WSL has been a godsend and the new terminal and powershell have worked a treat. Glad they seem to be continuing with it.
My theory is that Microsoft is working on eventually moving Windows over to the Linux kernel, and all these things they are doing are setting the stage and preparing for an easier transition.
This comment reminds me of the GIF of Michael Scott screaming 'NO GOD PLEASE NO'[1].
It also tells me that anyone who makes this comment has limited exposure to comparative kernel development. I've always said it, I'll say it now, and I'll say it in the future: the NT kernel is by far the best part of Windows, and it is in many ways superior to the Linux kernel. Furthermore, Windows ships with an absolute metric ton of very nice userspace technologies that either a) don't exist on Linux, or b) are rubbish to use on Linux.
I don't understand why people want everything to converge on the Linux kernel and its userspace. I like open-source as much as everyone else, but 'let's make ALL the things GNU/Linux!' just leads to lack of competition and therefore stagnation and no innovation.
I have a better wish: Microsoft should open-source core Windows technologies, and eventually, the NT kernel itself. Then, it could maintain its official Microsoft® Windows™ distribution with support contracts, while allowing developers to compile and modify WindowsOpen. Something like what it currently does with VS Code.
Those folks fail to understand that if that ever happens, it will be a macOS UNIX like experience, or Android/Linux, or ChromeOS/Linux, not a Stalmman's GNU/Linux one.
As I said on the other post, I strongly doubt that. It offers few benefits and many roadblocks. It would be a monstrous amount of work, would throw into question many existing security-related certifications, break Microsoft's love of backwards-compatibility, etc.
All MS is trying to do is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.
> the least painful way to develop for Windows on Windows is to just use Linux
Eh? Even as a joke, I don't get it.
1. Download Visual Studio 2022 Community Edition
2. Select and install the workloads you need
3. Fire up any boilerplate from the Welcome menu
4. Press the green play button
Sure, it's no `pacman -S base-devel && g++ main.cpp && ./a.out`, but it's not as bad as everyone puts it.
It is a GUI-first operating system, and if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.
> All MS is trying to do [with WSL] is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.
> if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.
I said "least painful", not impossible. The scenario you describe here would be very painful.
> The scenario you describe here would be very painful
On the contrary, it couldn't be easier. Visual Studio comes with a Windows XP platform toolset[1] that is a one-click install.
Compare, on the other hand, how ridiculously hard it is to develop targeting older glibc on a newer glibc host. There's no way around it except to use a Docker container (which IMO is equivalent to using a sledgehammer on a tiny nail).
I have been continually disappointed that Microsoft has not released a seamless Windows virtualization system. WindowsX would run the new, redesigned APIs, but all of the legacy could run inside a sandboxed system to give the world the required decades to finally transition.
This! I won't buy a Windows OS to run stuff because rebooting is annoying and I end up rarely ever actually dual booting. But I'd pay good money for a Windows Classic library on Linux.
It’s basically what Apple did when moving from OS 9 to OS X. Old applications would load up in Classic, allowing users to start using the new system, while developers had time to update their apps.
It's also far easier to port an old Windows application to run on modern Windows, or write a program on modern Windows targeting old Windows, than it is to do any of this on Linux.
Unlikely. Windows is all about compatibility and that includes all the weird things accumulated in windows over the decades. There is not a real incentive to change this. Think of all the gamers, custom hardware like ATMs and commercial terminals that run on Windows. That’s a huge market.
Old windows software often runs better or only with Wine instead of recent windows versions. So if they want to keep their 'compatibility' long term, they have no choice but to to include (or worse, fork) wine.
It depends. I would argue getting an old scanner or printer running with no current driver is definitely much easier on Linux as well. I am not into Windows enough to have any other examples :)
Windows should just run Linux. For apps that really need the Windows OS, use something akin to macOS parallels. I really like WSL of course, but would prefer an inverted paradigm.
The Windows kernel has a lot of features that Linux lacks. Dropping all those features would make a lot of people very angry, especially admins in big corporations.
sudo on windows has a different risk profile given the malware ecosystem and lack of educated/ trained users.
95% of linux users are developers who understand risk -- though are prone to mistakes
99% of windows users are casual consumers .
Let's keep this functionality narrowly accessible : restricted to developer mode and very formal consent. I suggest disabling it if it's unused for a few days
Looking at that page, it looks like syncthing chooses to not provide a Windows service. That is where 100% of the complexity is coming from. If they did provide a Windows service, then it would be as simple as opening the service manager, and setting the startup type from "manual" to "automatic".
It's not fair to blame Windows for the developers of an app not using its features. Similarly, if syncthing didn't bother to create a unit file on Linux, your example would no longer be a simple one liner. That wouldn't be systemd's fault though.
runas doesn’t pass current directory, or environment (at least the last time I used runas on Windows 10). I vaguely recall that runas has a kinda low limit on command line length, too ( I’m possibly misremembering that one).
This adds a factor of enshittification for NT, NT doesn't need 88 line PowerShell scripts, this "sudo for Windows" thing makes Windows seem like a teenager's high school project. Windows NT already has runas, let NT be NT and let POSIX have sudo/doas. Previously Microsoft hired the best of the best operating systems engineers in the USA who were from Digital and they proved to be people capable of making an operating system able to scale from MIPS to PowerPC/DEC Alpha/IA-32/amd64/Itanium with any combination of hardware and peripherics, now they're allowing random people to push 88 line scripts and calling it a day. Very few people in this world deserve the privilege of touching any Windows NT code and even more few people deserve the possibility of pushing things to the build lab of Windows NT 10/11 builds
Thanks? But sudo
* isn't a 88 line PowerShell script, it's a 1800 LOC Rust binary
* isn't a NT kernel feature, it's a usermode executable
* was made by (in my opinion) a perfectly decent engineer. That may be thinking too highly of myself though.
I see you are one of the heads of sudo for Windows, now based on your comment I see sudo for Windows with non-so unhopeful eyes. The comment about 88 lines PS code is about sudo.ps1 on the repo, thanks for clarifying. I'd like if more consideration is taken over sudo for Windows, as the MSDN docs relate: sudo at the moment has a clear distinction with runas and you must be the one who chooses what's best, I can infere the intention is not replacing runas, but then there's two ways to the same goal and each one with its differences. It's a similar situation than it was with WMIC and WMI for PS, being this case as a longer-standing approach, WMIC is deprecated but you can still use it if you want, however WMI for PS has the same functionality as WMIC and still offering benefits over WMIC, ultimately WMIC will be removed from future Windows releases. I'd be less confusing if this route is planned for runas and sudo
The new command is named “sudo” because customer feedback and because MUSCLE MEMORY:
I hear you! We thought about some of the options you’re calling out here. A lot of customers voiced having the muscle memory of doing similar flows on various operating systems was more important to them and that’s where we landed. I totally understand your perspective and I do really appreciate the feedback. I’m always trying to learn from people like you so I can help to build things that will make your life better.
This is good, but runas already exists. Its interface is shit. Improve it to make it not shit please. Don't hijack the name of an existing command unless you're going to re-implement its interface 100% compatibly.
This is like when PowerShell hijacked curl all over again...
Technically, powershell has a built-in alias of "rm" to the remove-item command. And Windows will happily accept / as the path separator. So you could do "sudo rm /" and it would be a legit command.
If everyone thinks this is so great (just judging by the number of times it's appeared in the HN top 30), why don't they just run linux, instead of some sh!t immitation?
Everyone knows, if you can C colon, your running a M$ product...
Not GP but Windows-primary as well. Linux desktop has improved a lot over the years, I quite like KDE Neon, but lack of any viable RDP alternative is a deal-breaker for me (I've tried all the alternatives, they're not there). I've never been a consoles-only guy, even though I grew up with DOS. I also rely on RDP to separate work and home machines.
Windows also stable and performs well, ie no silly kludges needed like oom-killer.
I usually stay a bit behind the curve, roughly keeping with the old "don't upgrade until service pack 2 is released" adage. Just installed Windows 11 on my work machine, running Windows 10 at home.
I run Windows 11. It has first-class support for Linux, with WSL, and the Windows Environment has first-class support for NVIDA graphics, popular productivity and entertainment software. It's reliable, stable, and performs well, with commercial support and scheduled major and minor updates. It's consistant. I can develop software for Windows 11 and be sure that everyone else with Windows 11 can run it.
I've heard this as well, but I run windows 11 for work, and can confirm the file manager has no ads in it (I don't know if there are alternative versions of Windows 11 that do, but it definitely isn't true as a blanket statement)
I've been working on this for the last few months now and I'm pretty excited to talk about it or answer any questions!