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

[gilboa]

That's because you run everything on super high-end 512GB RAM 128TB drive all-Xeon systems, and use solid state dri-

I believe I was _very_ clear when I said: "And my VM hosts range from a low-end i5 laptop with 8GB RAM up to multi-node oVirt clusters with TB of RAM..."
Heck, up until a couple of months ago, I had Acer Chromebook - converted to Fedora - with a low end dual core "Pentium", 6GB RAM and 64GB SSD that had a Windows 7 VM on it (which ran reasonably well).

- Gilboa

[tildearrow]

Ugh? Amy I missing anything?
I've got around 20 Windows VMs ranging from Windows XP (used for security testing) up to Windows 2K16, running on 6 different hosts (3 pure KVM, 3 ovirt) and neither of them showing anything close to what you are experiencing.
And my VM hosts range from a low-end i5 laptop with 8GB RAM up to multi-node oVirt clusters with TB of RAM...

- Gilboa

That's because you run everything on super high-end 512GB RAM 128TB drive all-Xeon systems, and use solid state dri-



Never mind... I just found out what was causing the slowdown...

It appears that after a while, the image becomes fragmented, and therefore Windows slows down greatly (this is a 30GB file and I am about to run out of disk space).

After running e4defrag, the performance improved greatly...

[gilboa]

- 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

Ugh? Amy I missing anything?
I've got around 20 Windows VMs ranging from Windows XP (used for security testing) up to Windows 2K16, running on 6 different hosts (3 pure KVM, 3 ovirt) and neither of them showing anything close to what you are experiencing.
And my VM hosts range from a low-end i5 laptop with 8GB RAM up to multi-node oVirt clusters with TB of RAM...

- Gilboa

[torsionbar28]

Yes, but can you run WSL on a Xeon Phi? With Xe graphics?

[t.s.]

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.

[ssokolow]

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.

[t.s.]

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..

[Ladis]

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.

[ssokolow]

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".

[BesiegedAce]

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.