62

Did anybody still remember coLinux? I remember it is used for SpeedLinux and Portable Ubuntu some years ago.

It's pretty clear what is coLinux doing, running Linux on top of Windows somehow, but can use real linux partition. Meanwhile cygwin is recompiling linux apps to use on Windows.

But WSL? is WSL closer to coLinux or Cygwin?

EDIT 2020/06/16 to add more confusion, there's now WSL2. But from what I understand so far, it is just a virtual machine.

Rinaldo Jonathan
  • 745
  • 1
  • 6
  • 11

2 Answers2

67

WSL would be closer to coLinux than Cygwin.

Keep in mind that Unix, POSIX and Linux are different things.

Cygwin is a POSIX compatibility layer that runs on top of the Win32 subsystem. It has approximately nothing to do with Linux; it can broadly be treated as "just another Unix-like" where porting programs requires recompilation and possibly source modification, and anything that requires non-POSIX Linux-specific features probably won't work.

WSL 1 is designed to be ABI-compatible with Linux proper. It does not use the real Linux kernel, but is compatible such that programs compiled for Linux can run on it without recompilation or translation. WSL is part of the NT kernel, so exists independently of the Win32 subsystem. This is similar to the older SUA, though that was a POSIX (not Linux!) subsystem on top of the NT kernel.

WSL 2, runs a real Linux kernel on a lightweight VM. It promises similar Windows integration as WSL 1 but with a real Linux kernel (so kernel modules, filesystems, etc., should work). It also has proper GUI support (on Windows 10 Build 19044+ or Windows 11) but has reduced I/O performance when accessing Windows filesystems compared to WSL 1.

coLinux runs a real (though modified) Linux kernel. On the Windows side, it exists as a driver that provides memory management and I/O access. Conceptually, it is closest to a virtual machine, though with closer integration between host and "guest". coLinux has not had a release since 2011 and I see no activity on their SourceForge page; it can probably be considered a dead project.

From a program's perspective, both WSL and coLinux look approximately the same as a real Linux kernel running on raw hardware. WSL (currently) has more limitations and quirks, but also has first-party (Microsoft) support and works on x86_64. coLinux and WSL 2 are real Linux kernels, so will behave just like Linux, whereas WSL 1 is a clean-room implementation of the ABI.

Cygwin does not look any closer to Linux than, say, FreeBSD does from the program's perspective.

BE-Code
  • 3
  • 2
Bob
  • 60,938
  • 25
  • 191
  • 216
  • 3
    I do agree that colinux is for now, much better. Its sad that nobody ported it to x86-64. – Rinaldo Jonathan Sep 24 '18 at 01:55
  • 3
    @RinaldoJonathan Personally, I prefer the WSL approach. IMO the coLinux approach is relatively fragile (poorly defined interfaces between the two kernels). In fact, I'd take a full VM over coLinux. But it does depend on what you need. – Bob Sep 24 '18 at 02:01
  • 14
    At the command-line prompt, Cygwin looks closer to Linux than FreeBSD does to Linux, because it provides the GNU user-space commands that are typically available on Linux systems, rather than the FreeBSD commands. – Diomidis Spinellis Apr 09 '19 at 13:51
  • but then, if WSL 2 is just a VM, what's the difference with, lets say running Ubuntu directly in VirtualBox? – Rinaldo Jonathan Jun 16 '20 at 06:10
  • 1
    @RinaldoJonathan The emphasis there is on the integration with Windows. Filesystem access, RAM scaling, socket sharing, etc.. You could probably mimic much of it with a *lot* of manual work with a full-fat VM but it won't ever be as complete. From a user's perspective, usage of WSL2 should feel much like usage of WSL1; you never really notice the hypervisor at all. – Bob Jun 16 '20 at 08:50
  • Can anybody comment in terms of speed. For example, `find / -type f -name '*.c' -exec grep -l smeagol {} \;` or other process-intensive or RAM intensive operations. Who wins here? – daparic Feb 07 '22 at 09:58
  • @eigenfield At this point, coLinux is basically a dead project (last release 2011). WSL and WSL2 both have their ups and downs, but if your files are stored in a Windows NTFS filesystem WSL2 might be slower than WSL1 as its I/O layer (to Windows) has more overhead. Within its internal ext4 filesystem, WSL2 is significantly faster. Cygwin just plain loses: it needs to emulate POSIX APIs on top of Win32 APIs, and there are many ways they're not optimally compatible, e.g. `fork`+`exec` does not map well to `CreateProcess`, which WSL1 gets around by using picoprocesses and WSL2 by a Linux kernel. – Bob Feb 07 '22 at 11:23
  • I tested copying 16GB from drive C to drive D using command `cp -a` on both terminals of WSL and Cygwin. The Cygwin terminal finishes first. And then 5 minutes later, the Ubuntu WSL followed. I would use Cygwin for my command line operations. I don't know what are you talking about in your comment. – daparic Feb 08 '22 at 02:03
  • 1
    @eigenfield You are free to use whichever you wish, based on your own critera. I do need to point out that your 'test' is not representative of any other usage. `cp` by itself is a very simple command and almost purely bottlenecked by I/O. Your earlier example command, `find -exec grep`, performs many `fork`+`exec` and is more likely to be bottlenecked by cygwin translation. The difference is even more apparent if you start running build scripts or compilation workloads. You are also unclear whether you tested against WSL1 or WSL2; the latter has caveats I already mentioned. – Bob Feb 08 '22 at 02:51
  • For some comparative numbers, with a build script workload [we're talking a factor of 4](https://thedrwu.com/posts/shell-perf-2019/). – Bob Feb 08 '22 at 02:58
  • Did more tests with command `time find src -type d -name Release`. The WLS gave 6s and Cygwin 12s. – daparic Feb 08 '22 at 04:02
  • They are all completely different. coLinux used a CVM setup to run the Linux kernel alongside Windows. Docker Desktop originally ran a Docker engine inside a traditional Linux VM. WSL 1 translated a subset of Linux system calls etc into calls into Windows, allowing some Linux software to run under Windows within the subsystem. WSL 2 (used by Docker Desktop now) uses a hypervisor on top of bare metal to run Windows and Linux in lightweight VMs as peers. Cygwin is a straightforward port of Unix utilities to Windows, implementing a POSIX interface. – Marcel Besixdouze Sep 04 '22 at 18:08
6

Great answer by Bob, but I'll just add one clarifying detail on WSL2.

... there's now WSL2. But from what I understand so far, it is just a virtual machine.

WSL2 is more like Docker (and other containerization technologies) than a VM itself. Yes, the WSL2 subsystem (the portion called the "Virtual Machine Platform") is running in a lightweight virtual machine, but we don't have access to the actual VM itself. Instead, that VM is used to run "distributions" (I tend to call them "instances") in their own namespaces.

Each WSL2 instance has a separate:

  • PID namespace
  • Mount namespace
  • IPC namespace
  • UTS namespace
  • WSLg System Distribution (Windows 11 only)

However, they all share the following with the parent WSL2 VM (and thus each other):

  • User namespace
  • Network namespace
  • Cgroup namespace
  • Device tree (other than /dev/pts)
  • CPU/Kernel/Memory/Swap (obviously)
  • /init binary (but not process)

More reading: There's a great chapter in the book Containerization with LXC that explains a lot of the concepts involved here in detail. It's currently a free sample chapter at Packt.

NotTheDr01ds
  • 17,574
  • 4
  • 44
  • 81
  • 1
    The way the WSL kernel accesses machine resources is a different level of the story: it goes through the hypervisor. The API by which the WSL kernel accesses the hypervisor is what they call the "Virtual Machine Platform", or "Hyper-V" depending on your Windows SKU (Microsoft marketing terms, what fun). At that level, the WSL kernel and Windows kernel are peers under the hypervisor. Individual distros are put into containers as you described and from there they share access to the same WSL kernel. – Marcel Besixdouze Sep 04 '22 at 18:23