Windows and Linux co-development

All of them, when you’re creating a new file.

Ah, I have everything default to \n only then. ^.^
I’d not doubt that there are .gitattribute plugins for things like atom or so that can auto-detect though, or at the very least it would be so easy to make one. That is a useful idea, hmm…

Cross-compilers work within WSL.

You can’t expect Microsoft to know about every command that every OSS project has ever written. Two independent groups, neither of which heard of the other, picked the same three-letter command name. It actually happens a lot (Google’s Chromium conflicts with a game called Chromium, Rust the language conflicts with a game called Rust, multiple branches of mathematics want to claim Omega).

OTOH, overriding wget and curl was a horrible, and deliberate, choice of action.

Bash overrides time without providing the whole scope of functionality, so it’s not like it’s unprecedented. I just would’ve hoped people would learn better by now.

The problem is that dropping a * -text into your gitattributes file doesn’t tell it to use Unix line endings. It tells it to not change them, whatever it may be. If I’m creating a .reg file for Windows, I want my text editor to use Windows line endings, and if I’m creating or editing an HL7 message, I want the lines to be terminated by a lone “\r”.

Does mix use cross-compilers?

These are the ones I am referencing, plus iex. They are entirely not functionally equivalent in any form other than the absolute basics. Even the command args are different.

That is for the purpose of getting more accurate timing data, which is what it’s purpose is. If you really need the default then just do env time <blah> (Remember that env <cmd> always uses the systems command, not a shell built-in).

.gitattributes can specify those. text=auto means use the system default (when pulling/pushing), which also works fine for an editor default as well. :slight_smile:

PowerShell iex, unlike PowerShell wget and curl, is not an attempted replacement for Elixir iex. PowerShell iex is short for Invoke-Expression. The fact that they share a name is a coincidence.

Then it should be IEX, not iex. :wink:

PowerShell commands are case-insensitive. Also, that would be IEx, with mixed case.

Ah true, it should be IEx.

It’s not case sensitive? Wtf? That is a good reason not to use it right there…

1 Like

And PowerShell has a built-in called start. I used the .bat suffix to distinguish Invoke-Expression from Interactive Elixir, but this works too:

start iex --werl

Executables are case-insensitive under Windows. Given a choice, I’d rather have the PowerShell builtins also be case insensitive than have exes and builtins disagree.

Also, having executables on your system with names that differ only in case is a serious system configuration smell.

Oooo, useful, I’ll give that a try next time I need. Thanks! :slight_smile:

Not under Windows, but rather under the filesystems it includes by default. A custom filesystem does not need such a limitation as case-insensitivity.

Executables sure, but not commands. I’ve made a LOT of functions and aliases and such in my shell that differ from an executable via just their case so that I can have special functionality without needing to replace the existing functionality. :slight_smile:

This is also why it is a wtf that powershell has case-insensitive ‘commands’. o.O?!

False. Case-insensitive semantics are provided by the Win32 subsystem on top of whatever native filesystem you’re using. With the right API calls, I can do this:

some file, SOME FILE, and Some File in the same folder

NTFS is capable of a lot. It’s the Win32 subsystem that limits you.

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.


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.


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!


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:

function Invoke-CmdScript {
    [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!