Windows and Linux co-development

Hah, nice. ^.^;

Sorry, Iā€™ve been busy.

Anyway, I just tried it booting up KDE Neon on a couple machines and it just worked. :persevere:
I tried a couple different settings looking for a way to replicate just a black screen and could never get that.

Though, KDE Neon Guest services werenā€™t as good as a regular Ubuntu box

Eh? It actually does this better than VirtualBox imo. The caveat is that it only works on supported Linux distributions.

Itā€™s called Dynamic Memory - Ballooning on supported distributions.

They actually regret adding the curl and wget aliases. But decided that it would be dangerous to get rid of them at the moment. But at least recognize that it is a problem.

I just used Set-Alias to override curl, but you could also just remove it.

I get you, and Iā€™ll admit that Hyper-V making Windows start as its first ā€œparentā€ VM is kinda of annoying. But, you a nice benefit of sharing resources through a system that is lower level than just Windows itself. Maybe one day when you can run a VM inside of a VM.

At one point I needed to run VirtualBox because of Vagrant. I ended up having two boot records, one with the Hyper-V virtualization enabled and one without. Hereā€™s a good tutorial on how to do that.

Also, I heard that Hyper-V has an Android Emulator now though. I donā€™t know if itā€™s any good.

I had that some time, I always booted into the wrong one.

Also at least Docker4Windows (that one using Hyper-V) was set to use a single GiB of RAM on a system with 8 GiB physical. Even directly after boot, I had to try several times before I was able to start without getting OOM. VBox based docker just works, using a max of 4 GiB, consuming near to nothing after starting docker-machine and only as much as necessary when a container was running. Hyper-V based Docker sits on its single GiB, not releasing the tiniest bit when no containers are running (but not consuming more if they are running). And a single GiB of RAM is far too less for most things.

KDE Neon is Ubuntu. :wink:
Ubuntu 16.04 (it is whatever the most recent LTS version is) specifically.

Ubuntu is not a supported one? :wink:

Eh, I just use mingw-bash.

Yeah I had the same issue, had to figgle with the settings a lot to quit getting that error. It made Hyper-V look very unprofessional.

I know, thatā€™s why I felt it was worth mentioning. I donā€™t know whatā€™s going on to cause such a different experience.

It is and works great for me. :wink:

I donā€™t know how the ballooning driver is started.

But ā€œsupportedā€ is kind of a misnomer. Iā€™m pretty sure it just means that Microsoft is actively supporting that driver.

I just installed Docker for Windows to see whatā€™s up, and ends up that the MobyLinux image is based on Alpine Linux. Which doesnā€™t seem to have a memory ballooning driver/service. Except I see this:

[16:48:17.084][Moby           ][Info   ] hv_vmbus: registering driver hv_balloon

So yeahā€¦ It would seem that it actually does. Why they are set on using a static memory limit beats me. But it is a limit set by Docker for Windows and not anything with Hyper-V.

You can use docker-machine create -d hyperv which uses boot2docker instead of MobyLinux.
Note: Itā€™s a little bit more involved than that, which is why Iā€™m going to recommend using Docker Toolbox.

boot2docker does support dynamic memory, has it enabled, and it works quite well out of the box. But docker-machine requires Administrator privileges to setup any Hyper-V machines and you wonā€™t get GUI powers.

I donā€™t know why the choices made by the Docker for Windows team were made, but it definitely feels like they werenā€™t really thinking about usability as much as they were thinking about being correct. Thatā€™s not what I would have done, but whatever.

Bottom line is that I agree with @NobbZ choice. Use Docker Toolbox unless you want to mess with Windows Containers. Then I would recommend not using the GUI for Linux containers and just creating your own machine via docker-machine.

1 Like

Iā€™d like to chime in with some more contemporary info. Bare in mind this is a mix of facts and opinions. Also, itā€™s huge.


Linux

Laptop scene is tragic and always has been. Even specialized Dell XPS laptops that come pre-installed with special Ubuntu builds have several repeating complaints regularly on Reddit and HN (has been the case for like 2 years now) ā€“ mostly failing to sleep when closing the lid, drivers crashing after reopening the lid, random WiFi stops and restarts, static noises from the speakers, Bluetooth being flaky, font rendering problems with several displays with differing DPIā€¦

Many Linux devs are purists, donā€™t care about media and donā€™t mind these complaints much ā€“ however many younger devs come from MacBooks or Windows desktop machines and are unable to tolerate the problems. Iā€™ve read about such painful transitions just 2 days ago on HNā€¦ things sadly havenā€™t improved at all. Even the highly acclaimed Librem laptops suffer from several pretty blatant UX and hardware issues like those pointed above.

If you want to develop on Linux, better get a desktop PC or use one of the very few laptops that are known to have zero issues with Linux ā€“ mostly Thinkpads. Some people report no issues while using some of Lenovoā€™s Yoga laptops and 2-in-1 devices as well. The Yoga machines are pretty cute and relatively strong laptops, I will give them that.

TL;DR: do a very detailed research if you want to use Linux on a laptop. There are very few laptops that come without issues. For desktop machines however you can practically install Linux on everything and use it very efficiently.


Windows 10

Avoid WSL. It works but it comes with a baggage of WTF issues and is significantly slower than a native Windows installation of Elixir. WSL however gives you the advantage of being able to compile any C bindings without an effort. Admittedly, the WTF issues I read about a year ago are being addressed one by one and things are improving in terms of stability and Linux feature parity. 50/50 though, depends what you need.

Using a native Elixir installation: well, good luck if any of your dependencies need to compile a native library! Outside of that I had no problems, Elixir is very fast on Windows 10. I never felt it being slower compared to a MacBook or native Linux.

As for general usability, I might get some flak for this opinion but Windows is just fine. Itā€™s not as polished or beautiful as macOS but it remains very usable and robust. Only had 1 blue screen for 3 years of usage and it was related to a random failure in the RAM that never happened again. Also, while DPI management on multiple monitors is sometimes aggravating ā€“ namely tiny text on the laptop screen if you use higher DPI to get the most of your external 4k monitor ā€“ for the most multi-monitor setups Windows 10 is absolutely viable.

TL;DR: Avoid Windows 10 if you need to compile native libraries for your work often. While installing and using Visual Studioā€™s compiler stack takes no more than an hour (10 minutes for me), you will inevitably fall victim to WTF compiler errors at some point. While using gcc under the MINGW sub-platform might work better, I had problems with it in the past as well.


macOS

Another not very popular opinion, it seems: Macs are very close to the ideal programming machines if you are prepared to delve into XCodeā€™s peculiarities; however those are much less than Visual Studioā€™s WTFs. Getting to know XCodeā€™s environment is mostly a one-time investment and then you can compile whatever with barely any issues. (There are always exceptions but Iā€™ve coded in 7 programming languages on my MBP 2015 and they had all sorts of native bindings and never had problems compiling whatever they needed. Not saying there are no problems at all with macOSā€™ compilation stack. Iā€™ve heard about a good number of them ā€“ but for most of programming I donā€™t think you can expect issues unless you do very exotic things.)

MacBooks work flawlessly for me, and I have two. Save for the once-a-year lockups or random screen corruptions that get fixed by a reboot (or fix themselves a minute later), they are perfect. Image quality and text legibility are unparalleled. My eyes are less tired after reading on my 15" MBP compared to my gaming 35" monitor that works on 144Hz. Go figure but apparently Apple knows how to do displays.

Many bemoan the ā€œlack of package managerā€ which is only true if you count Apple-provided ones (which are zero except for the App Store); brew however is alive and well, and works just fine. Never had it install faulty software on both of my MacBooks.

Big drawback however might be that if you want to work on a desk for hours on end and preserve image quality and text legibility you should pay the hefty price for an external Apple-certified monitorā€¦ I found it hard to work more than 4 hours on a 15" laptop screen, sadly. Even with the superior displays of the MacBooks that are easier on the eyes, I get tired quicker overall if I stare at the smaller screen for longer periods of timeā€¦ :frowning:

TL;DR: In my opinion macOS is the best candidate for a laptop programming machine right now. There is some time investment to make sure things compile without a hitch but I found it small and non-distracting, and never had to actually fight the OS (unlike Windows where I have been putting whole weekends without result).


Closing thoughts

If you will work on a desk in a company office or home office, you better work on a desktop machine. You will have access to bigger displays and can buy whatever mouse and keyboard you fancy ā€“ these 3 factors are very important when you spend a lot of time working stationary! So in this regard using Linux or Windows 10 with Linux VMs is just fine ā€“ I spend 2/3 of my work on my Win10 PC with Linux VMs and never had an issue. Recently ditched Debian for Manjaro and was never happier with a Linux distro. A Windows 10 laptop I can only 50% recommend; many work just fine but many also donā€™t. Battery life is inferior to MacBooks; average battery life is 4 hours (which is admittedly not a problem for many; Dell XPS and Lenovo Yoga have been known to be close to MacBooks battery life btw).

HOWEVER, if you really really want to use a laptop, donā€™t settle for anything else but a MacBook Pro. If the display size is a not a problem for you, at least invest in a good laptop stand and external keyboard and mouse ā€“ makes the longer work sessions much better when you are on a desk. If you donā€™t use an external display, most MBPs can go 6 to 8 hours on battery depending on load.

Donā€™t think for a second that Windows 10 or Linux experience on laptops is optimal. I and many others have tried and tried and then tried some more for years on end ā€“ things are barely improving.

In conclusion: donā€™t make compromises with your work machine. You might think laptop speakers that produce static noise arenā€™t a problem now but 2 short weeks down the road you will think otherwise.

Sorry for huge post, hope that helps someone. And always take these with a grain of salt. I cite things that are widely regarded as true in rather big communities, however many people still get by just fine with Linux or Windows laptops. Do your own research!

3 Likes

I agree with your analysis. Here are my comments:

Linux (Ubuntu) on Windows 10 (Dell XPS 15, well equipped) is not reliable. As you say, it has some small and some bigger issues. The biggest is that time I closed it an put it in my bag, only to find out an hour later that it was still running and about to set my entire bag on fire due to the heat buildup. With a lot of effort, you can get almost everything in Ubuntu working as it should, including dual bootā€¦ with the occasional (inconsistent) exceptions. But those exceptions are often very unpleasant.

Windows just doesnā€™t have as nice an interface for normal use (lack of quick look, lack of Preview, lack of tabbed Explorer, lack of multi-column Explorer views, inconsistently ungodly slow scrolling in Explorer, Acrobat, etc.). It also doesnā€™t have a good/fast terminal. Powershell is not terrible, but it doesnā€™t compare to Mac Terminal. WSL is a large band-aid, but itā€™s really worth getting your Windows environment to be able to compile Elixir modules (like comeonin) and forgetting about WSL. Iā€™ll add how I did that at the bottom of this post. Docker, once you get Hyper-V and various settings working correctly, is a nice option for some cases (such as setting up a database, webserver, etc.) VirtualBox with a guest Linux VM is ok, but itā€™s laggy to use with a UI. For ā€œheadlessā€ servers, itā€™s ok. Oh, and it doesnā€™t like having Hyper-V enabled, so you can pick Docker or VirtualBox.

Mac (MacOS) just is the best laptop environment for doing Elixir and other Linux-like development. Unfortunately, the current MacBook Pro is not better than the previous model (pre-function-key-removal, pre-butterfly-keyboard). Hopefully Apple will deal with these issues at the possible release of a new MBP at the end of this year. Also, inexplicably, while games run much better/faster on Windows, I find that Adobe apps (Illustrator and Premiere) run much smoother and faster on my older MBP than on my newer, ā€œfasterā€ XPS.


Hereā€™s how I got my Powershell to build Elixir modules. This is from different sources of info, including SO and Github.

Install Visual Studio Community of the latest release version. Then find where it keeps vcvars64.bat. Youā€™ll need this path.

Add the following to your Powershell profile file. If that file doesnā€™t exist, create it here:
C:\Users\myusernamehere\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

function Invoke-CmdScript {
  param(
    [String] $scriptName
  )
  $cmdLine = """$scriptName"" $args & set"
  & $Env:SystemRoot\system32\cmd.exe /c $cmdLine |
  select-string '^([^=]*)=(.*)$' | foreach-object {
    $varName = $_.Matches[0].Groups[1].Value
    $varValue = $_.Matches[0].Groups[2].Value
    set-item Env:$varName $varValue
  }
}

Invoke-CmdScript "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"

This function makes the variables set by the vcvars script visible to the calling shell (the Powershell you opened). This makes nmake and other build tools visible.

1 Like

That is sadly true. I bought a slightly used MBP 15" 2015 from a former colleague at the start of 2018 and have been very happy with it. Every single MBP after 2015 has been a disappointment, be it for the removal of the MagSafe charger, the godawful touch bar, the very subpar keyboard, or no upgrade to 32GB RAM.

Sure, they finally added the 32GB RAM variant several days ago butā€¦ butterfly keyboard and touch bar for the high-end models! Yeahā€¦ Iā€™ll skip.

Reference in this forum: 32 GB MacBook Pros are out!