Announcement

Collapse
No announcement yet.

It's Now Even Easier Setting Up Windows Subsystem For Linux On Windows 10

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

  • #31
    Originally posted by tildearrow View Post

    Using GVT-d (and Looking Glass) giving the VM 4GB memory allocated using hugepages, disabled Meltdown/Spectre mitigations and security features. Q35, accel=kvm, CPU host with kvm=off to hide VM presence. 2 cores allocated to VM.
    Slow.

    I tried the Android version of Roblox prior to using the Windows 10 method, with a self-compiled Android-x86 (to remove Google stuff). It didn't work, crashing every time I opened it.
    Maybe something is missing but it crashes on my phone too so I must be doing something wrong... ...maybe time to try again?
    (note that I did not install Roblox through Google Play as I do not have a Google account anymore)
    Maybe try a different VM product like VMware? Maybe looking glass is causing an issue with your setup? I haven't tried GVT-d but I have tried GVT-g before and used the DMA-BUF feature to display the screen directly into the QEMU window. Wasn't great performance and it sometimes was crash prone but was still massively faster than what you're describing.

    Yeah I installed Roblox in Android x86 in QEMU with Play Store. Sadly, a lot of Android games need Google Play Game and Play Services for game save syncing and score keeping. Not sure if Roblox mobile does but I wouldn't be surprised. Worked for me and some other person on Discord who tried it.

    Comment


    • #32
      Originally posted by Xaero_Vincent View Post
      Maybe try a different VM product like VMware? Maybe looking glass is causing an issue with your setup? I haven't tried GVT-d but I have tried GVT-g before and used the DMA-BUF feature to display the screen directly into the QEMU window. Wasn't great performance and it sometimes was crash prone but was still massively faster than what you're describing.
      Doubtfully. GVT-d is like GPU passthrough for the Intel graphics card (since I do not use it).
      I did try GVT-g before, with negative results. I had to tinker with the versions and sometimes Windows would override it with its own driver.
      And when I got it working, it wouldn't last more than 30 minutes (it hangs the system). DMA-BUF does not work because I wasn't using the Intel card for the desktop...

      Comment


      • #33
        Originally posted by Vistaus View Post

        And what if you don't want to use Wayland but something like Arcan? Your proposal takes away freedom.
        Yes, some will says it takes away freedom, but the plus is we have more manpower solving fewer problems. Imagine, we have 100 devs building 1 display server vs 100 devs building 10 different display server.

        Comment


        • #34
          Originally posted by t.s. View Post

          Yes, some will says it takes away freedom, but the plus is we have more manpower solving fewer problems. Imagine, we have 100 devs building 1 display server vs 100 devs building 10 different display server.
          That assumes you can compel those devs to work on the unified project. This is the kind of thing that needs diplomacy, like how KDE and GNOME and other desktops working together on FreeDesktop.org managed to replace KDE's DCOP and GNOME's use of CORBA with a compromise solution both now use... D-Bus.

          Given GNOME's opinion on increasing the proportion of C++ in their codebase, and KDE's opinion on writing everything in C rather than writing C bindings for C++ code, I imagine that, were they to come together on a display server, they'd probably write it in the one language both groups seem to be interested in using more of... Rust.

          (rust-qt-binding-generator is a KDE project and, on the GNOME side, librsvg was rewritten in Rust, there are top-notch GStreamer bindings for Rust (both for using it and for writing sources and sinks), the gtk-rs people are working to produce solid bindings for GObject Introspection interop, and I've noticed a general sense that they are interested in making Rust serve Vala's goals better than Vala.)
          Last edited by ssokolow; 30 October 2020, 04:20 PM.

          Comment


          • #35
            I'm doubly impressed that so far nobody has mentioned EEE other than me, and the fact that a windows related article discussion threat is now talking about wayland.

            Anyways on the name, it's not confusing to me. I read it as Windows' Subsystem for Linux, implying it's a Windows Subsystem, for running Linux, or something like that.

            Comment


            • #36
              Originally posted by BesiegedAce View Post
              Anyways on the name, it's not confusing to me. I read it as Windows' Subsystem for Linux, implying it's a Windows Subsystem, for running Linux, or something like that.
              Fundamentally, it's down to whether you read it as "The product named 'Windows Subsystem', which runs on Linux" or "The product named 'Subsystem for Linux' which runs on Windows".

              It's a classic case of "English grammar can be ambiguous about which words serving an adjectival role bind to a noun more strongly".

              Comment


              • #37
                Originally posted by tildearrow View Post
                Booting up the Windows VM is a pain:
                - It takes like 15 minutes to boot up
                - Pressing Windows key sometimes does not work, and sometimes it takes up to 30 seconds for the Start menu to come up
                - Disk usage is 100% all the freaking time <--- This
                I think you need more RAM (the disk usage to drop from 100% because of swapping) and/or SSD instead of HDD (many times faster disk operations). This also explain the delay between pressing the Start key and Start menu showing.

                PS: If you have very slow computer and don't want to invest in it anymore, I suggest dualboot. With 100% disk usage your VM is not usable for anything anyway and you wouldn't have to split already small RAM into two systems.

                Comment


                • #38
                  Originally posted by ssokolow View Post
                  That assumes you can compel those devs to work on the unified project. This is the kind of thing that needs diplomacy, like how KDE and GNOME and other desktops working together on FreeDesktop.org managed to replace KDE's DCOP and GNOME's use of CORBA with a compromise solution both now use... D-Bus.

                  Given GNOME's opinion on increasing the proportion of C++ in their codebase, and KDE's opinion on writing everything in C rather than writing C bindings for C++ code, I imagine that, were they to come together on a display server, they'd probably write it in the one language both groups seem to be interested in using more of... Rust.

                  (rust-qt-binding-generator is a KDE project and, on the GNOME side, librsvg was rewritten in Rust, there are top-notch GStreamer bindings for Rust (both for using it and for writing sources and sinks), the gtk-rs people are working to produce solid bindings for GObject Introspection interop, and I've noticed a general sense that they are interested in making Rust serve Vala's goals better than Vala.)
                  Naturally. And we need people with good management and governance skill for that. Not an easy task, definitely. All devs should be thinking about how their works will benefit others (future devs --use documentation in EN, common and good programming language that easy to pick up and has good perf, etc; the user..) rather than their ego. Too much example for the contrary: vim vs neovim, GNOME vs KDE, multiple WM, DE, etc..

                  Comment


                  • #39
                    Originally posted by t.s. View Post

                    Naturally. And we need people with good management and governance skill for that. Not an easy task, definitely. All devs should be thinking about how their works will benefit others (future devs --use documentation in EN, common and good programming language that easy to pick up and has good perf, etc; the user..) rather than their ego. Too much example for the contrary: vim vs neovim, GNOME vs KDE, multiple WM, DE, etc..
                    Vim vs. NeoVim I can understand. It's sort of like Mozilla Suite vs. Firefox.

                    The Vim developers value supporting lots of esoteric platforms and all the code to support the quirks of those esoteric platforms and their compilers bogs down development.

                    The NeoVim developers want to make a version of Vim that's targeted at a narrower selection of platforms but iterates on new features more quickly and attracts developers who would find Vim's codebase too demotivating to spend their leisure time on.

                    Supporting two user bases whose maintainership needs are at odds is one of the big valid reasons for a split like that.

                    Comment


                    • #40

                      Originally posted by ssokolow View Post

                      Vim vs. NeoVim I can understand. It's sort of like Mozilla Suite vs. Firefox.

                      The Vim developers value supporting lots of esoteric platforms and all the code to support the quirks of those esoteric platforms and their compilers bogs down development.

                      The NeoVim developers want to make a version of Vim that's targeted at a narrower selection of platforms but iterates on new features more quickly and attracts developers who would find Vim's codebase too demotivating to spend their leisure time on.

                      Supporting two user bases whose maintainership needs are at odds is one of the big valid reasons for a split like that.
                      Yep, it's OK to split if there's too much difference. But don't spread too thin. And IMO, it's always better to consolidate.

                      Comment

                      Working...
                      X