Live data from Hacker News

Linux as co-operative Windows process (2017)

colinux.org

41–50 of 97 posts

Re: Linux as co-operative Windows process (2017)

#42
post #40

What a cool and novel concept! Bummed and a little surprised it's the first time I've heard of it. I wish there were a browsable directory index of cool projects such as CoLinux. Reading the description definitely set of bells in my head reminding me of the venerable Cygwin, though CoLinux could comparatively have potentially more capabilities and upsides since there is a fully resident kernel running. CoLinux hasn't…

> what happened?

Probably the fact that it lacked 64-bit support: https://colinux.fandom.com/wiki/FAQ#Q27._Does_coLinux_work_u...

Re: Linux as co-operative Windows process (2017)

#43
post #23
post #12

Earlier quoted context omitted.

WSL1 is actually quite similar afaik. Unfortunately also development stalled here in favour of WSL2. I remember Co-Linux to be a a thing around 2005, but it never stuck with me as I was mostly happy with Cygwin until all the libuv and go (now rust) stuff popped up.

I don't think WSL1 development stalled in as much as Microsoft made the determination that it wasn't a viable path forward. I/O was piss slow and chasing syscalls NT API calls probably wasn't very fun. Microsoft already knew Hyper-V quite well so a VM made sense, they just had to put some automagic management around it.

If anything, WSL1 showed me that MS still has some programming chops lurking around (I mean, obviously, I know they have some truly amazing developers and their research talent is top notch), but that project was technically pretty cool with the pico-processes and syscall translation layer.

But the one thing they would never be able to overcome was CUDA and kernel modules. If you show people "Linux" and they can't build their software, then it might as well be hot garbage.

I use WSL2 daily and far more often than my actual Linux VMs. It's not the fastest, but it did solve a huge chunk of the problems with WSL1. No, it's not native, but I already have 3 monitors, a huge tower, and a Mac Mini M1 on my desk. I didn't need a native box at my fingertips (those go on a rack in the basement, lol).

Re: Linux as co-operative Windows process (2017)

#44
post #16

Wsl2 is a pretty excellent modern alternative imo. I was even able to get nvcc/cuda working in wsl

What do you mean you were even able to make it work? It works out of the box with no configuration.

Can't speak for CUDA specifically, because I don't do anything with LLMs or ML locally, but I did have to rebuild ffmpeg with some some bits built with nvcc (and maybe an nvidia provided library- sorry it's been a while) to get GPU accelerated transcoding going.

But yes, the GPU passthrough layer in WSL2 (or however it's actually implemented) is present by default.

Re: Linux as co-operative Windows process (2017)

#45
post #28

Earlier quoted context omitted.

You're not going to take over NT's control of the MMU et. al. without elevated privileges. To run as a non-admin, you either need a VM that leverages NT's built-in virtualization capabilities (requires admin to enable), a separate personality (requires admin to install), or a Win32 application a la cygwin, which isn't very good.

You could try to use the Win32 debug API in the same way like Linux UML by using ptrace. But it would probably still be much slower because of missing things like PTRACE_SYSCALL. More performant would be a noMMU variant of UML for Windows, supporting only PIE executables, similar to nabla-linux [1]. This is also quite similar to how mssql for Linux works NT kernel+Win32 in a single usermode process (single address sp…

SeDebugPrivilege requires local admin, which would be required to debug a process the user doesn't own. This privilege level is just about the highest one you can obtain in NT.

Re: Linux as co-operative Windows process (2017)

#46
post #28

Earlier quoted context omitted.

You're not going to take over NT's control of the MMU et. al. without elevated privileges. To run as a non-admin, you either need a VM that leverages NT's built-in virtualization capabilities (requires admin to enable), a separate personality (requires admin to install), or a Win32 application a la cygwin, which isn't very good.

The site is down, so I can't see what they're doing with the MMU: that said, most virtual memory management works just fine from normal boring userspace. If wine can do it for running win32 on Linux, this thing can do it for running Linux stuff on win32, which isn't less powerful when it comes to virtual memory management.

The VMM is part of the kernel (or executive), not userspace. App requests memory, VMM assigns pages from RAM, page file, or backing store.

If you wanted to segment yourself and take over anything 'below' the kernel like the MMU, you'd need elevated rights. But that'd be some interesting programming.

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/me...

Re: Linux as co-operative Windows process (2017)

#47

I remember using this decades ago. The user friendliness of Linux combined with the stability of windows. It did beat dual booting though. Worked like a charm.

>>The user friendliness of Linux combined with the stability of windows.

I think you meant: "The user friendliness of Windows combined with the stability of Linux.".

Re: Linux as co-operative Windows process (2017)

#48
post #16

Wsl2 is a pretty excellent modern alternative imo. I was even able to get nvcc/cuda working in wsl

What do you mean you were even able to make it work? It works out of the box with no configuration.

I meant compared to other Linux/Windows coexistence tools I've used in the past where GPU passthrough was a huge challenge

Re: Linux as co-operative Windows process (2017)

#49
post #47

I remember using this decades ago. The user friendliness of Linux combined with the stability of windows. It did beat dual booting though. Worked like a charm.

>>The user friendliness of Linux combined with the stability of windows. I think you meant: "The user friendliness of Windows combined with the stability of Linux .".

My use case for WSL is really what original comment says: I need stability of windows so my graphics drivers won't stop working randomly and user friendliness of linux command line as a developer

Re: Linux as co-operative Windows process (2017)

#50
post #47

I remember using this decades ago. The user friendliness of Linux combined with the stability of windows. It did beat dual booting though. Worked like a charm.

>>The user friendliness of Linux combined with the stability of windows. I think you meant: "The user friendliness of Windows combined with the stability of Linux .".

Given their next sentence is concessive (ends with “though”), I don’t think that was an error.
Post reply on HN