awesome-windows-privacy VS pylance-release

The issue is that it's the way Microsoft conduct business at all. The default should be opt-in not hard to find opt-outs for every patch.

I would say no, there is no way to make it more tolerable unless you run something like shutup10 or https://github.com/TemporalAgent7/awesome-windows-privacy but then again if you care that much you should simply just run Linux because in reality there is no real good solution since spyware is baked right into the product.

You don't even indicate which download link you used, it was "earlier this week" so nobody can try and reproduce it, and you don't even say what it was detected as? Plus you linked to a site that has a whole article talking about them getting regularly flagged for false-positives due to the sensitive settings they're changing within Windows.

Like what is it you expect to happen here? Plus why are you using this sketchy looking tool instead of one of the many scripts available[0] or Open Source tools[1] that do the same thing while making the source code readily readable?

I don't personally endorse any of this stuff, in fact I recommend against it. A lot of these scripts disable or remove security features and break functionality that has nothing to do with privacy. Plus users that use this stuff are self-selecting as the exact kind of users without the technical knowledge to know what they're doing, why, or how to undo it (or else they'd just make the changes "by hand"). Breaking Windows Update is a common symptom of this stuff (e.g. install -> rollback -> install -> rollback, loop), and they won't know how to fix it then just blame Microsoft.

I guess my point is: You try to get sketchy things, from sketchy sites, and it gets flagged thusly, it is working as intended. If you're here to complain that Microsoft pointed your gun away from your own foot, well too bad? Better luck next time, guess?

[0] https://github.com/TemporalAgent7/awesome-windows-privacy#po...

[1] https://github.com/TemporalAgent7/awesome-windows-privacy#os...

Appx packages are not where the bloat is. These are "store" / UWP apps which are generally sandboxed / very restricted in API access - so they take up disk space but not much else after you close them.

Sure, if your goal is to save a bit of disk space, this will help; but I suspect when most people think about "bloat" they think of things that slow down their computer (things that actively consume memory / cpu / network).

In my experience, that bloat is mostly services and scheduled tasks. I started collecting scripts / documentation on debloating with a primary focus on restoring privacy here: https://github.com/TemporalAgent7/awesome-windows-privacy (it's not very maintained but maybe someone finds something useful there)

I keep a list of (mostly) open source tools, scripts, etc. for debloating Windows 10/11: https://github.com/TemporalAgent7/awesome-windows-privacy

This thing is not on the list, because it's obviously extremely sketchy (in addition to it being illegal / piracy / etc. the actual "functionality" of removing Windows Update and Windows Defender is bonkers).

There are a lot of open source scripts and tools on GitHub for accomplishing the same goal (in various state of being out-of-date, abandoned, etc.); I started collecting the ones that appear somewhat active here: https://github.com/TemporalAgent7/awesome-windows-privacy

I plan on going through them to weed out duplicates. You shouldn't trust any of those blindly, but definitely read through the code; I'm particularly interested in coming up with a list of services and scheduled tasks that can be safely disabled without impacting any of the applications and services I'm using (I want Windows Update, OneDrive, Office, Defender, Store and store apps, MS Account login and Xbox Gaming for example, which most tools want to disable).

One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release

While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.

It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.

(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)

Anyone know how can we fix this issue if we build the vscode locally

Do any of these issue tickets explain the behaviour you're seeing? https://github.com/microsoft/pylance-release/issues/4341, https://github.com/microsoft/pylance-release/issues/4071

Maybe they "are the same thing" in terms of behavior (I don't know), but "A uses B" doesn't mean that "A is B".

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

There's this one: https://github.com/microsoft/pylance-release/issues/4174 (rules don't apply properly, and ovverrides don't work even after being set, this is especially for the more generic ones like )

The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close it down on a whim.

Does anyone know where the open xlang reimplementation of MIDL went[3], by the way? (Unlike 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs.)

[1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there

[2] https://github.com/microsoft/pylance-release/issues

[3] https://github.com/microsoft/xlang/pull/529