aeschli
commented
1 year ago but now DISABLES WSL & Docker containers network capability permanently
What does that mean? You can no longer access the internet from inside WSL?
Closed KonanTheLibrarian closed 1 year ago
aeschli
commented
1 year ago but now DISABLES WSL & Docker containers network capability permanently
What does that mean? You can no longer access the internet from inside WSL?
aeschli
commented
1 year ago No clear what the issue is. Too much text. Please file a new issue. Keep the description short. Focus on steps to reproduce, what do you see, what do you expect. Add screenshot.
KonanTheLibrarian
commented
1 year ago Please do not close this until you have everything able to restart and be working OFFLINE from boot up.
VSCODE is very good at trying to restart your last sessions, even sessions attached to auto restarted Docker containers.
That is great work, must be hard to do as there are about 15 VSCODE session use cases instances to recover!
Right now it "almost" automatically restarting sessions, but fails without the Ethernet or WiFi which telegraphs MALWARE and is also fatally unsustainably reliant on the Internet, so in a crisis (EVEN A MINOR CRISIS) it will never work again! That bad!
Therefore being diligent please ensure that on bootup WITHOUT Internet ALL VSCODE last sessions, even with attachments to containers and projects are fully restored to when you last rebooted, including each of these VSCODE instances OFFLINE:-
VSCODE with CPP project (Windows build project only not WSL),
VSCODE with WSL2 (Ubuntu 22.04.02) on /home/dudeUser Terminal and VSCODE Explorer (left hand icons) feature showing all files for that user and able to open those files in the VSCODE editor.
VSCODE with WSL2 but spawned by doing this inside the WSL terminal (previous instance terminal): $ cd ~/myCppProject # any project with a cmake or Makefile $ code . # ie code space dot that Spawns an NEW VSCODE instance project AND plugins!
VSCODE attached to Linux Container (any Linux) WITH and WITHOUT Docker Desktop. Without DD is most important!
Similarly but a VSCODE container project code . project ...
Note that several plugins are needed just to make it work, don't fool yourself to think NO plugins. You need Docker plugins and the most popular "C++ intelisense" etc. (THAT EVERYBODY USES millions of downloads). NOTE also for containers you have to install the plugins AGAIN because those are not automatically installed as the parent VSCODE instance has them but the child container do not.
Harsh words on closing bugs without linking them to related bugs! When you pushed "VSCODE insiders" to "release" you carried with you a mountain of "closed" bugs. So if the bugs are "closed" they must be fixed, right? GENIUS! I see dozens of the SAME bugs repeated over and over and all being closed WITH NO BUG FIX PUT IN PLACE, genius then it fixed itself?
Developers need to understand network connections from inside WSL2 Terminals and Docker container terminals with or without VPNs and with or without common firewall settings and SMART error messages are needed not "Zombie_Terse_Error messages". One common VPN is Global Protect; common as in there are thousands of developers either learning or seriously developing and forced to use GlobalProtect.
All, staff at all levels having zero toxic Trojan Horse agendas, is now all current and new projects will last.
Why? How do you "vet" plugins and "vet" developers or "vet" AI? Well you find out their intentions and that is now easy.
Malware created by gov agencies is easy to find by AI, easy to hijack by AI and easy to repurpose in reverse.
Bugs will be found and fixed by AI test suites will be written by AI.
Run away if you find that toxic influence in a project, it will be exposed, but not by people!
WSL Environment (similar used by millions of people)
VSCODE 1.78.2 but also to VSCODE 1.78.1
VPN: Global Protect version 6.1.0-58 (important used by millions)
OS Name Microsoft Windows 10 Enterprise Version 10.0.19045 Build 19045 System Model Latitude 5420 Processor 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 1690 Mhz, 4 Core(s), 8 Logical Processor(s)
Running VSCODE instances:
TESTING?
Reproduce BUG you must start clean: Uninstall Docker Desktop See WSL2 without Docker Desktop VSCODE and WSL and remove ALL giant .vhdx and .vhdl files under Windows 10. Reinstall all.
Code of conduct: Yes removed 78 cuss words. I apologise in advance for being harsh, I am altogether grateful for the time and effort developers put in over the past 10+ years have contributed to VSCODE and WSL even unpaid. Code is a test of honesty; it even enforces honesty; as one lie politically motivated cascades into a mountain of bugs making political code physically obvious and unsustainable. For that reason coding erases political "opinion" and replaces it with raw facts and truth; indeed engineering is the same - respect truth else the bugs take over!
Existing issues, yes about 15 million complaints about loss of Network under WSL which under VSCODE 1.78.2 now today ALSO affects its attached containers which previously were not frozen out of the network ie 10x WORSE!
VSCODE Insiders test NO!!! The insiders Network issues are far WORSE BY FAR hence VSCODE 1.78.2 is therefore WORSE than VSCODE 1.78.1 and WORSE than VSCODE 1.78.0 too.
Does this issue occur when all extensions are disabled?: Yes
Observations and Steps to Reproduce:
Connecting to WSL “Stating Linux Subsystem” via Green [><] button WITHOUT Ethernet now works (VSCODE 1.78.2), but now DISABLES WSL & Docker containers network capability permanently (but not any other Windows applications). Starting containers (from previously created images) from WSL attached to VSCODE works, but you can’t attach to those containers with a VSCODE instance for that docker container! NO JOKE! VSCODE REFUSES to attach to that VSCODE started container instance until the Ethernet cable is reattached (on retry)! Connecting the Ethernet cable allows the Container to be attached to a new instance of VSCODE, but it too NOW has NO internet which is different from previous VSCODE versions where Docker containers instances ALWAYS connect to the internet (with the Ethernet cable reattached) even when WSL Network got broken. So 1.78.2 it is not just worse but “Fragility Matrix” fully dependent on the network @~~@'*** fire worse.
This is not to do with Docker Desktop as it’s bugs are monsters. Docker runs with WSL2 without Docker Desktop faster and without crashing . See WSL2 without Docker Desktop Microsoft previously had Run without Docker Desktop advice on a web page but deleted it which is &^(^)&()@ BAD!
VSCODE 1.78.1. (previous version) is different: When starting WSL2 via the bottom left VSCODE green [<>] button: “Connect to WSL” (after reboot). WSL and Terminal ONLY recovers previous session and starts if you are connected the internet first in VSCODE 1.78.1. VSCODE 1.78.1 outputs a bug log but VSCODE 1.78.2 DOES NOT.
VSCODE 1.78.2 (NEW version) now starts WSL but then NEVER can connect to the internet when Ethernet is reconnected. Neither can containers. This new version BREAKS ALL NETWORK CONNECTIONS (normal windows apps do connect proof it is WSL). To recover you have to actually REBOOT the pc to fix it and connect the the Ethernet cable and Global Protect VPN before your start VSCODE. If VSCODE starts without a network ALL VSCODE attached instances to WSL and containers will have broken networks.
9+ Reasons to WSL2 Network disaster:
VSCODE WSL has a network mechanism that is &)( broken not just in code but all the way back fully &)(& design and concept destroying WSL and CONTAINERS NETWORKS! The network problems existed in VSCODE insiders and you released them now to everybody unfixed even when users already ALREADY reported network breakages! AHHHH!
Test teams are testing whilst connected to the internet so introduce FATAL FRAGILITY, FATALLY DEPENDENT ON SOME KIND OF UNAUTHRISED REMOTE CONNECTION. This applies to plugins too, which a few are spyware as you do not vet them as safe (like browser add-ons/plugins are checked). So the risk is enormous.
Test teams are FAILING to test common VPN use cases with ethernet connecting and disconnecting and reconnecting. This includes Sufe shark and Global Protect VPNs. (Version given above).
You think that not asking permission to connect to remote server and connecting when such connections are not expected is honest, and respectful? YOU ARE WRONG! NOT ASKING PERMISSION & INTRODUCING MASSIVE RISK IS OFF THE SCALE BAD! See risk analysis below. This applies to plugins too, which a few are spyware as you do not vet them as safe (like browser add-ons/plugins are checked). So the risk is enormous (again).
Bug log was previously output to the screen now NOTHING in VSCODE 1.78.2 so the blind are leading the blind.
Failure to test without Docker Desktop. Docker Desktop is fragile BUG monster and now considered spyware so people are shy of it, meaning you must ALSO test use cases WITHOUT Docker Desktop. I repeat: Microsoft had a webpage "run WSL without Docker Desktop", but that got deleted. So the joke is on you. VSCODE 1.78.1 tried to install Docker Desktop pretending it was docker this version VSCODE 1.78.2 seems not to do that.
Introducing dependencies on ONLY STABLE Ethernet or WiFi is waiting for disaster hence risk analysis below. The dependence on another remote machine that you do not control is unacceptable and miopic! (This applies also to plugins).
Trusting plugins without certification and many plugins are malware. Disaster waiting to happen.
Risk analysis
0) WSL is just like Windows, security is not built-in from the get-go, instead it is patched with patches upon patches that clearly interact and rip apart. WSL2 is therefor wide open, so it's not the end user application at risk but the actual developers environment with the source code exposed. We already saw how the "experimental features" in Docker Desktop settings dump enormous 50GB multi layer Docker tar files when crashing OR for analysing them for risk (ironically). There is no excuse.
1) Even if connected to a reliable internet, what if the remote server was down? WSL or Plugins also must NEVER demand "remote".
2) There is no such thing as reliable internet, wifi, Ethernet and you are dependent on that?
WSL or Plugins also must NEVER demand "remote". We are not an X-Box that is addicted to the internet and can't play without it.
3) RECENT EVENTS ONE OF WORLDS MOST POPULOUS CITIES When people at home or in offices or whole cities, whole counties, whole states or whole nations lose internet, WSL2 development via VSCODE stops dead. Disasters or wars shut everything down the same hour they happen, this just happened in Pakistan 5 days ago affecting millions of people. Users assume no remote connections or remote monitoring so how has this BUG been introduced especially when telemetry is turned off? (This applies also to plugins).
4) Because of bugs with Docker Desktop destroying VSCODE and WSL usability and losing ALL work data, users now often run without Docker Desktop and instead use just Docker with VSCODE/WSL2.
It is obvious that Docker Desktop offers no value that does not already exist and loses sync with both WSL and Docker, this can’t be fixed because the BUG is in the design.
5) Your worst risk is indeed your plugins. Your plugins are a security risk that sometimes demands remote connections making VSCODE WSL and Docker have fully broken security. WIDE OPEN TO ABUSE.
VSCODE and WSL is not an X-Box that is addicted to the internet and can't run without it.