Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arch Linux adapted for Windows Subsystem for Linux

github.com

Post reply on HN
Print view View original

151–160 of 163 posts

Re: Arch Linux adapted for Windows Subsystem for Linux

#151

Post by alfalfasprout »

teekert wrote: post #120

Main advantage I see above Ubuntu would be the Arch User Repo (AUR) which contains almost all software you can think of. Although that can change when Snap picks up speed. Snapd is also available under Arch though. Moreover, Arch will be much more current in general.

aur is amazing. For a desktop distro, it's what makes Arch one of the best choices IMO. Want ? You can compile from source and get something your package manager can track. Not to mention never needing to reinstall for a new version.

I love RHEL/CentOS dearly for servers, but needing to write a complex spec file and deal with the rpmbuild system just to get an RPM for a library is a pain. You end up with /usr/local full of stuff that's hard to update.

Re: Arch Linux adapted for Windows Subsystem for Linux

#152

Post by ajoy39 »

zamalek wrote: post #103
jcrites wrote: post #50

Earlier quoted context omitted.

It would be nice to be able to develop "native" Linux software right from within Windows where I'm doing other things. I can see the appeal. That's why Microsoft built the Linux subsystem, I suppose.

I tried dual booting Linux back in high school, never got anywhere because I never selected it at boot. Virtual Machines changed that - I was able to play around with Linux without having to worry about a power cycle. Now I can play around Tensor flow (in theory) and not have to worry about the crummy GPU support in nearly all hypervisors. I've reached the point where I'd love to have Linux on my work machine, no Win…

my first semester of college back in 2010 I, for reasons I cannot explained, decided that I would keep my windows and linux installs on totally separate hard drives. With a laptop. With one drive bay. You never appreciate how quick rebooting into linux is until you spend 4 months physically swapping a hard drive every time you want to switch which OS you're using.

I was not a smart freshman

Re: Arch Linux adapted for Windows Subsystem for Linux

#153

Post by int_19h »

flukus wrote: post #96
int_19h wrote: post #90

Earlier quoted context omitted.

It's not truly contained , though. There is no security boundary between the host and the guest there - WSL can access your entire filesystem, for example (subject to usual ACL checks, of course). The reverse is also true, by the way - WSL portion of filesystem can be observed directly from Win32 (cd %USERPROFILE%\AppData\Local\lxss and look around, but don't touch - there's some magical pixie dust there that's easy…

Can't you make whole drives available to a true VM in the same way?

You can, but in a VM, you still have two different and separate filesystems, and then some mechanism to provide a window into one from another (custom FS driver mounted in a directory, SMB share etc). In WSL, there is only one filesystem.

And it's not just filesystems. We're also talking about potentially shared file descriptors/handles (where appropriate), access to processes in both directions etc.

So from user's perspective, I would argue that it's actually more similar to Wine. Even if the implementation is more low-level (syscall emulation vs userspace API emulation).

Re: Arch Linux adapted for Windows Subsystem for Linux

#154

Post by ackalker »

robotdad wrote: post #97
timgws wrote: post #78

Earlier quoted context omitted.

have you seen the VS GDB Debugger extension? https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcin...

Actually we have something better than that now. Check out http://aka.ms/vslinux

Much better than that, actually: http://visualgdb.com/

This one has been around a bit longer, too, and despite its name is now much more than just a pretty face for GDB but rather a full cross-platform development environment which has IntelliSense everywhere, handles the installation of toolchains and BSPs for embedded targets, building kernel modules (with VisualKernel addon), etc.

Re: Arch Linux adapted for Windows Subsystem for Linux

#156

Post by prirun »

If WSL were truly Linux compatible, then why would anyone need to adapt Linux software to run under it?

This is the first step: embrace. The next step: extend. Apparently it's already happening, as people scurry to adapt shit so that it works with WSL. Next you'll have companies requesting that all Linux software be "adapted" to work under WSL, and if it isn't, they won't buy it.

Once this happens, Microsoft can proceed to step 3: Extinguish. How? Easy - by adding incompatible shit to WSL. If companies succeed in forcing Linux software vendors to provide a WSL-specific version, they will have to be compatible with these WSL extension. Voila - now they are supporting a new Microsoft platform that Microsoft controls.

Back before many of you were born, Microsoft killed entire product categories and companies by providing free versions of Office when it was first introduced, and making it compatible with competitors' file formats. Is it free now? Hell no, it's their main source of revenue!

Can they repeat the same hat trick with Linux? Who knows, but they damn sure are gonna try. Anyone who thinks "Microsoft loves Linux" needs to take a history lesson. The only Linux Microsoft would love would have a dead penguin for a logo.

Re: Arch Linux adapted for Windows Subsystem for Linux

#157

Post by virtuallynathan »

beefsack wrote: post #33
virtuallynathan wrote: post #14

Earlier quoted context omitted.

I do this, works great. Get >95% of native perf out of my GTX1070.

You need to run separate GPUs to achieve this though don't you?

I run Fedora 24 with no GUI, so I only have the one GPU. Technically my motherboard has a crappy GPU I could use.

Re: Arch Linux adapted for Windows Subsystem for Linux

#158

Post by virtuallynathan »

colemickens wrote: post #61
icecreammatt wrote: post #36

Earlier quoted context omitted.

You can run your host OS using the integrated graphics and assign the dedicated card to the Windows VM

I'm having a hard time finding any information about that. Anything you can point me to? Ideally, I'd like to use 2x1080 (sli) with Windows KVM guest and then use the integrated graphics for Linux host.

SLI is hard/maybe impossible with GPU pass-through. Let me know if you get it to work!

Re: Arch Linux adapted for Windows Subsystem for Linux

#159

Post by virtuallynathan »

unexistance wrote: post #73
colemickens wrote: post #61

Earlier quoted context omitted.

I'm having a hard time finding any information about that. Anything you can point me to? Ideally, I'd like to use 2x1080 (sli) with Windows KVM guest and then use the integrated graphics for Linux host.

google keyword : GPU passthrough https://www.reddit.com/r/pcmasterrace/comments/3lno0t/gpu_pa...

There's a ton of guides, I found it useful to read a bunch of them and mentally prepare for the kind of stuff I should be doing.

Re: Arch Linux adapted for Windows Subsystem for Linux

#160

Post by j4_james »

jcrites wrote: post #50
_qbjt wrote: post #43

Maybe I'm in the minority but I prefer keeping my GNU/Linux and Windows installations separate, with each OS on its own drive. My Linux setup is secure, free of proprietary software and under my full control. When I run tcpdump, I'm met with a clean log where every packet is one I recognize. I get to use my favorite window manager (awesomewm) and I don't have to worry about forced updates. My Windows install is quite…

It would be nice to be able to develop "native" Linux software right from within Windows where I'm doing other things. I can see the appeal. That's why Microsoft built the Linux subsystem, I suppose.

The real benefit is not just being able to develop Linux software, but the ability to work on cross-platform code. I do most of my coding and debugging in Visual Studio, but when I want to test the changes on Linux I now simply alt-tab to the bash shell which I have open in the appropriate directory, rebuild the changes with make, and then run the updated executable.

That's not necessarily doable for everyone, but for me that workflow is so much simpler than it would be with dual booting or a separate Linux VM.

Post reply on HN