Hacker News new | ask | show | jobs
by _qbjt 3567 days ago
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 a different beast - automatic updates, mostly proprietary software and no major customizations other than performance tweaks and what the OS allows. I use it for gaming and media, and it works great. Boot times are very short with SSDs so restarting is not a problem. No compatibility issues, no fussing about with drivers and no need for translation layers like the Windows Subsystem or WINE; just two independent OSs that never let me down.

That said, no hate toward this project. Arch Linux is probably my favorite distro (although I'm on Xubuntu at the moment).

8 comments

This is pretty OT, but I feel like it is worth pointing out:

> Boot times are very short with SSDs so restarting is not a problem.

Personally - this is a question of individual preference, though - I do not mind the OS boot time itself very much (to a degree). Whether the system takes ten seconds or two minutes from reset/power-on to the login screen does not make much of a difference, to me, psychologically. But once I log in, I need to open all of these programs, make sure the windows are in the right place, SSH connections to certain machines are open, etc. I admit I am kind of obsessive-compulsive about this, but this is a far greater (psychological) barrier to rebooting than the OS boot time itself.

I do not use Windows at home, and my work laptop runs Windows 7 (I intend to keep it that way, too), so I have not been able to play with the Linux subsystem on Windows. But if you consider it as an alternative to Cygwin (which I do use), it sound kind of nice. Now if only Windows had a native, builtin X server... ;-)

EDIT: With Cygwin or the Linux subsystem, driver issues are not an issue, of course, because hardware is still managed by the Windows kernel and Windows drivers.

Personally - this is a question of individual preference, though - I do not mind the OS boot time itself very much (to a degree). Whether the system takes ten seconds or two minutes from reset/power-on to the login screen does not make much of a difference, to me, psychologically. But once I log in, I need to open all of these programs, make sure the windows are in the right place, SSH connections to certain machines are open, etc. I admit I am kind of obsessive-compulsive about this, but this is a far greater (psychological) barrier to rebooting than the OS boot time itself.

Hibernation should solve this issue, no? It certainly does on single-OS machines. I practically only shut down my desktop when I want to tweak the hardware and/or BIOS.

It's a little more annoying for dual-OS because there is a 'hibernate' command and a 'reboot' command, but I'm not aware of a 'hibernate-then-reboot' one, so you have to manually hit the power button after hibernating instead.

Hibernation would work but then you have to make sure that the two operating systems don't share any drive (such as a data drive), because writing on a drive mounted by an hibernated system can cause all kind of weird issues.
Boot times do not matter for hardware OSes. For containers and VMs, there is much better use-case for short boot times: on-demand scaling.
I dont care about long boot times either, it's opening chrome and all my terminals that is a pain in the ass.
You can run things like VcXsrv or Xming, then you can pretty much run anything through them, including window managers. When WSL went mainline I had all sorts of fun playing with it, building Servo and VLC and running them in a tiling wm, just because I could. (Not exactly productive time though)
And I can't seem to edit my post, but your comment about it be a Cygwin replacement is spot on. It's definitely replaced the need for it almost entirely.
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 Windows at all. That's only because for the first time Linux isn't this cool kids playground that I'm not invited to.

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

If your laptop was able to boot from USB, perhaps you could place the second disk (the one with Linux) in an external USB 2.0 (better yet 3.0) case. That'd solve the issue...
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.

I would prefer it the other way around: Having a good Windows subsystem in Linux. If however I'm to work on Windows, it's nice to know that I'll finally be able to have access to a functional shell.
I like the approach here; different than WINE. Apparently WinNT was built all along to run applications for different OSs at the same time, like OS/2.

They didn't try to implement all of userspace, just the system calls... a lot less to cover. Very cool project.

Yeah, easy. But AFAIK, unfortunately Wine could not just reimplement the Windows Kernel interface, since Windows DLLs are subject to copyright (so you need permission to redistribute them, guess by whom?), and lots of them are needed for a "working" system. That's why they set out to also create a full set of compatible DLLs for each subsystem instead - a monumental task involving reverse-engineering [often poorly documented] stuff, and reimplementing the thing [possibly without infringing any patents]...

BTW Wine is approaching release 2.0. Hooray for Wine!

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.

Embrace, extend, extinguish.

Although I'm guessing a few devs are in the boat with "all company PCs must be windows." Gives them an out no?

No this is not that. The idea is some frameworks/platforms have become nix first, ex. Ruby, Python to an extent Java etc. OCaml to only name some. Windows Subsytem for Linux is about bringing these nix first developer plats to Windows and help developers like me to remain on Windows.
This is precisely the strategy of 'Embrace, Extend, Extinguish'.

Step 1: Embrace new technology ( like Ruby, Python, Java etc ) that run on other ecosystems

Step 2: Add extensions to the technology that only works in Microsoft ecosystem. For example, add new functionality to Ruby for Windows that only work on Windows

Step 3: As more and more people develop software that uses these features, more people will have to switch to Microsoft ecosystem to continue using those pieces of software. This is not a voluntary switching based on the merit of the software ( as the same software could have been developed without those extensions ). The switching is often mandated by management decree, customer requests or market concerns.

The danger of this strategy is the cost for people outside the Microsoft ecosystem.

a) Bad pieces of technology becomes successful, merely because it came from Microsoft. Everyone is forced to use it.

b) People are locked into Microsoft platforms. This causes all the usual problems associated with lack of freedom : harder to experiment, keep the costs down for companies etc

Some people say Microsoft has changed their ways and they have since repented, but most people are still suspicious. Once bitten, twice shy.

So what do you call it when Google adds great UX, advanced sorting and searching etc. to email, and then slowly starts making it harder to send email to Gmail accounts from non-Gmail accounts? (All in the name of eliminating spam, of course.)

Or when Facebook Messenger supports XMPP up until the point where their user base is big enough and they don't have to care about interop anymore?

Welcome to Software Business 101, everyone plays nice with the standards/alternatives/competition until they don't have to anymore. I never understood why Microsoft gets extra flak for this in 2016 - maybe they were particularly good at it 20 years ago, but every big player will play hardball if they get a chance.

The answer is to avoid single vendor lock-in under all circumstances, but Microsoft is hardly on a trajectory to become the single vendor for Ruby or any other Linux-first tech at the moment (ha!).

Microsoft are still doing it. The company that I work for didn't just pay for Office subscriptions because we wanted Office for Mac (and I didn't want to get it on subscription either, but the pricing strategy is designed to penalize you if you don't). We actually have access to three different Office-like products already (iWork, LibreOffice, Google Apps). None of them can yet 100% support Microsoft's "standard" file formats.
s/Software Business 101/Business 101/

FIFY

And that is why I prefer to be a developer instead of a manager.

IMO everyone should get flak for these kind of monopoly building business practices.

Companies with this behaviour regarding my work tools lower my personal life quality.

It might be Software Business 101 now, but when enough executives note that it makes you hated after a number of years, the course content might change...

(For example, what makes me vary about this case is: I expect the Linux subsystem under Windows to start working worse and worse, sometime in the future.)

It may be that Microsoft is doing their usual embrace and extend, perhaps the extinguish part is not possible these days.

This is an interesting effect there, that due to WSL, there will be less perceived need to support windows for development tools. However, isn't WSL aimed mainly at developers? Regular users won't be turning it on. So if you're developing the next dropbox with clients written in Ruby, you'll still need a ruby and gems that run on Windows. i.e. to support end users, we'll still need dev tools that run on Windows. edit: Server-based stuff not so much, and server-based stuff is the main thing these days, to put it clumsily.

Correct, but a LOT of developers today write code that eventually runs on Linux in the cloud. With WSL, such developers using Windows will not leave for OS X/Linux
Hmm, perhaps it's really a move against OS X. If you actually run Linux you're probably committed.
If Microsoft can extinguish Linux by adding some subsystems to Windows, I'll eat my hat.
MS is seeing that it can't extinguish Linux, as well as the iPhone or iOS system. It has to adapt to it. Making it easier to develop on a Linux subsystem makes people stay on Windows, which still has stuff like Photoshop that blows away Linux alternatives. Plus of course MS Office, for which LibreOffice is a real alternative, but in some environments it's not.
>Maybe I'm in the minority but I prefer keeping my GNU/Linux and Windows installations separate

I'm excited because everyone at my company doesn't develop on linux because "we know visual studio" and "setting up a build environment will take too much time".

With the linux subsystem for windows, we have the ability to push them to slowly start developing new systems on linux. So I'm super happy about it.

> Maybe I'm in the minority but I prefer keeping my GNU/Linux and Windows installations separate, with each OS on its own drive.

That's essentially how the windows subsystem works. It might not technically be a VM, but practically it is.

Don't know why you were downvoted without explanation, because that's my understanding how this new feature works. Just like the Posix subsystem before it, completely cut off from the Win32 subsystem. So, yeah, it feels like it would be like a VM to me.
> Don't know why you were downvoted without explanation

If past conversations on reddit are anything to go by it's because a lot of people don't want to recognize that WSL is essentially a VM. Docker too for that matter.

WSL is definitely not a Virtual Machine, unless you're saying that WINE is also a VM, in which case you have a very broad definition of VM that's different from most other people.

The way WSL is implemented is actually really interesting. Linux syscalls are translated by an NT kernel driver and some other shims handle the NTFS->POSIX transition on the filesystem side.

> WSL is definitely not a Virtual Machine, unless you're saying that WINE is also a VM, in which case you have a very broad definition of VM that's different from most other people.

Wine runs on the host OS, WSL runs apps from linux image. This image is self contained, just like a VM.

Aside from that, I said it's practically a VM. There might be some different technical stuff going on underneath, but for a user there is very little difference between WSL and a VM.

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 to disturb and break things from the Linux side of things).

> Wine runs on the host OS, WSL runs apps from linux image. This image is self contained, just like a VM.

Actually (it's been a long time since I last used Wine though, so I might remember incorrectly), Wine is "self contained" as well and there's a "C: drive" directory structure with notepad.exe etc. too, just like the WSL system.

The main point is that it does not run a linux kernel.
AFAIK its more like Wine than a VM.
Yeah there seems to be some magic going on behind the scenes. I'm not a huge fan of magic in this case. Though it's just Beta now still right? I like having VMs on my local machine that I can snapshot. I would prefer if MSFT bolstered their Hyper-V performance for GUI apps as I found them sort of slow both to RDP/VNC into remotely and also locally.

Would be cool if the Windows Linux subsystem can work like Parallels for OSX that can be blended into the general OS but also snapshots taken and if the user wants, bring the Linux environment in it's own window.

The point here is, it's not how we feel as a desktop user, it's more interesting to think about what new technical solutions can be created because of this.
> Maybe I'm in the minority but I prefer keeping my GNU/Linux and Windows installations separate, with each OS on its own drive.

Consider full disk encryption on the GNU/Linux drive as well, since Windows can still access the disk.

I don't think that will help. After all Windows can patch the bootloader to cache the encryption password too. Even secure boot won't protect you since Microsoft has the signing keys.
If you're not using secure boot* and an encrypted Linux partition you are not secure.

(*Or a boot loader on a separate USB drive which is never plugged in while running Windows)

I don't think that will help. Windows can patch the bootloader to cache the encryption password. Since Microsoft controls the secure boot signing keys, they can sign the patched bootloader too, so even secure boot cannot protect you. Having the bootloader on a USB drive is probably a good idea though.