Announcement

Collapse
No announcement yet.

Microsoft Aiming For A Linux Development Workflow Around WSL + VS Code Remote

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Microsoft Aiming For A Linux Development Workflow Around WSL + VS Code Remote

    Phoronix: Microsoft Aiming For A Linux Development Workflow Around WSL + VS Code Remote

    Not a particularly new feature itself, but recently Microsoft has begun promoting a workflow for developers of encouraging them to use Windows 10 to do Linux development by leveraging Windows Subsystem for Linux (WSL) and Visual Studio Code Remote...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I guess I'll give it a shot. I'd rather use a VM so I can minimise the impact of antivirus on I/O performance, but WSL makes it easy to get some of the benefits of *nix while still working on parts of the project in Visual Studio (not VSC).

    Comment


    • #3
      I think Microsoft would be better off if they embraced Wine instead. It feels like their operating system is becoming irrelevant for everything than getting the most performance out of video games. Only old developers will be willing to put up with Windows out of habit, and maybe because they like to use Visual Studio for whatever reason.

      Comment


      • #4
        Originally posted by randomizer View Post
        I guess I'll give it a shot. I'd rather use a VM so I can minimise the impact of antivirus on I/O performance, but WSL makes it easy to get some of the benefits of *nix while still working on parts of the project in Visual Studio (not VSC).
        If you really cared about performance, you would run Windows in a virtual machine, as NTFS is ancient, and has awful performance, not to mention how awful NT is at scheduling processes and taking advantage of multi-processor setups.

        Comment


        • #5
          Sounds like a solution that requires additional unnecessary steps when compared to just developing on Linux.

          Comment


          • #6
            Vscode remote is a-mazing. Freeing my laptop of the extra work and running it on another machine is genius.

            Comment


            • #7
              Originally posted by DoMiNeLa10 View Post
              I think Microsoft would be better off if they embraced Wine instead.
              I'm curious... If Microsoft sold and supported a propriety version of Wine (without the hiccups) , would you buy it? If so, how much would you pay?

              Comment


              • #8
                Originally posted by DoMiNeLa10 View Post
                I think Microsoft would be better off if they embraced Wine instead. It feels like their operating system is becoming irrelevant for everything than getting the most performance out of video games. Only old developers will be willing to put up with Windows out of habit, and maybe because they like to use Visual Studio for whatever reason.
                Wine just implements the old Win32 API which is becoming obsolete anyway. Now Microsoft are more about .NET Core and UWP. The games probably use some game engine that abstracts that away, and all use DirectX 11 and 12.

                Comment


                • #9
                  @all: A little off topic ... but what would you recommend for remote developing/debugging in C/C++?
                  E.g. developing a program for a Raspberry Pi running Raspbian.

                  What tools/IDEs do you use? How is your workflow?
                  Do you prefer to cross-compile on the host, or to compile on the target?
                  I once tried Eclipse RSE, but somehow I could not get it working and then I gave up.

                  Any time I try to do some embedded development, I end up with manually cross-compiling on the command line, manually copying around files via SSH, and manually executing/debugging them on the target. This only works because my programs are in the area of "Turn on a few GPIOs", but my approach would not scale to anything reasonably complex, e.g. developing a library.

                  Any hints, tips, or links to tutorials are welcome

                  Comment


                  • #10
                    F*ck you M$.

                    Comment

                    Working...
                    X