Under VirtualBox my development environment can match my production environment almost completely. There's no awkward "but here's how you do it in Windows/OSX" that mostly works but often doesn't in some subtle way. I haven't tried Windows 10 yet but this setup has worked very well under Windows 7 and 8.1 so I expect it will be fine under 10 since it's just an evolution. I've used this setup in OSX and Windows and it goes more smoothly in Windows.

One of the keys to it is that you use SMB to mount your VM disk as a local drive to the host, so you get the benefit of any Windows editor.

Two years ago I was using VMware in W7, but ended up dual booting Linux since the lag was so annoying.

Basically you run a server in your Linux VM that Atom/Nuclide (running in Windows) connects to, and it lets you edit files in the VM as if your project folder were local. For those who like a GUI, I think it's worth looking at to save yourself the hassle of VirtualBox guest tools, etc. that never seem to work reliably. And frankly, I've never been particularly happy with the performance of a virtualized Linux GUI, though most of that blame goes to Ubuntu and its apparently impossible to get rid of (in some locations) fading animations.

Anyway, neat tool, worth checking out. You set up a VM to match whatever you'll be deploying to and then work on files in the VM from an editor in Windows. When it works smoothly it's really cool.

>> I love my command line and linux like commands and tools. - Homebrew - Bash scripts - Docker (Windows 10 currently not supported) - Vagrant

I switched from OSX to Windows last year. I thought I'd miss stuff, but you don't.

There are package managers like chocolatey to replace homebrew.

I use Cmder as my terminal and it works a lot like Mac's terminal. It was probably the key app that made my transition easy.

I use Vagrant on Windows and it works fine.

Can't say much about bash scripts or Docker though, since I rarely run those locally.

On Linux I just install build-essentials and everything works fine. On Windows I had to install a specific version of VS and fiddle around with the path to get things running. But maybe there is something like the build-essentials package in chocolatey?

The terminal command history also feels strange. But I like cls more than clear, haha :D

Yes, that is a legitimate source of pain, but thankfully that's usually a once-and-you're-done problem (for me at least).

When I switched to Windows as my full-time platform, I found Scott Hanselman's Developer's Tool list immensely helpful with my transition.

http://www.hanselman.com/blog/ScottHanselmans2014UltimateDev...

The only difficulty is that msys doesn't support parallel make, so builds are fairly slow, but my program's small and I do most of my development on Linux, so I don't care.

(As an additional bonus --- gcc supports C99!)

If it's C++, I did learn cmake, and now I use the same script for Ubuntu and for Win7/VS2008 and Win8.1/VS2012, and so far I just don't care about compilation issues anymore. Sadly the VS site only has VS2015 now.

But yes, the first time you have to check the VS version and add all the proper env vars for the cmake scripts to find the libraries.

But anyway, it is much better than when I used mingw and made makefiles by hand.

I lurk on a few sci.comp mailing lists, and the number and nature of problems that the Windows people have with compiling is crazy compared to Linux where the OS actually has a package manager and stuff Just Works.

As for cmake, I don't think it's any better than (gnu)make. I've seen big projects with complex buildsystems (eg. PETSc from Argonne) switch to cmake and then switch back again to make quite quickly. A frequent "problem" with make, I think, is that people learn just enough about makefiles to compile HelloWorld.cpp and then use that knowledge for everything.

For BLAS, it has a

    find_package ( BLAS )

https://cmake.org/cmake/help/v3.0/module/FindBLAS.html

https://cmake.org/cmake/help/v3.0/module/FindCUDA.html

I haven't used C11 or Fortran95, only C++11, and I had to add a cmake script for it, you can find it as CheckCXXCompilerFlag somewhere in the web.

I have to use Visual Studio instead of mingw because I'm using some winSDK libs, and VS has no (gnu)make, and what VS offers for the command line is not cross-platform, making it a poor investment of my time to learn about it.

After climbing just a section of the the steep cmake learning curve, I have deleted the solution and project files from my repository, and now I use cmake to compile and run the project in the command line with both VS2008 in Win7 (the PC) and VS2012 in Win8.1 (the laptop), without any path dependency. Previously the solution files depended on both my username and the path, and just moving the folder was cumbersome and required a lot of fiddling with those files.

Another thing I really like is the concept of an out of source build, and that's very easy to set up and use with cmake.

I now can write

    git clone somewhere:my_project.git
    cd my_project
    mkdir build && cd build
    cmake -DCMAKE_INSTALL_PREFIX:PATH=../install ..
    cmake --build . --target install && cmake --build . --target run

Not really - there are some big differences to keep in mind.

If your shared folders have symlinks, they won't work within the VM unless you're using Virtualbox's native shared folders, which is dog slow.

Permissions are also messed up if your VM is on an NTFS HDD - all files and all folders will basically be 755/777 within the VM.

There are plenty more tradeoffs.

I used Windows a little while ago, and I couldn't do any work without firing up a VM. I missed my environment, but if I did everything in a virtual machine, I could accomplish what I needed.

Eventually I gave up. I was actually doing my development in linux and windows was just acting as a VM host. It's almost comical that I ever said I did development in Windows.

Most of the apps I use are cross platform GUI apps like Sublime, Evernote, SourceTree, etc.

What advantages does this provide over the Windows 10 terminal? Windows 10 fixed all of my biggest gripes with cmd.exe

After using Mac for such a long time, it's nice to not have to recondition yourself to having to use backslashes or using commands like `dir` instead of `ls`.

- The console host application on Windows 10 finally doesn't suck. Resizeable, copy-paste supported, word wrap text selection, etc.

- It seems like they're trying to make their dev tools use a lot less "black box magic", the kind that that's wonderful when it works right and impossible to debug when it goes wrong. At an ASP.NET workshop recently, Scott Hanselman went to great pains to emphasize that everything he was doing in the VS GUI could also be done from the command line.

- Nuget keeps improving. It's still not a replacement for apt or even Homebrew, but they're listening to feedback and making the changes people request. I feel like in another year or so it could be a real contender.

Edit: Formatting

- Drivers are a pain in the ass for Android devices on Windows. You always need to install one when you first connect a device.

- The linux like commands are awesome on OsX and not something I can give up easily.

- Some very important tools are OsX only : ColorSnapper2, Sketch, Zeplin (it does have a webapp though)

PowerShell = bash, Chocolatey = homebrew, Windows Server Containers = docker, Hyper-V+powershell = vagrant, DSC = ansible etc etc.

I don't use Windows 10 for reference though. Still on 8.1 until they fix a few things and release a version-matched server platform.

While a great fan of PowerShell in theory, in practice it seems to be extremely cumbersome. Sort of the opposite of bash and other Unix shells, which suck in theory and are very useful/convenient/powerful in practice.

The whole design of PS is meant to make it so you can "guess" the names of cmdlets you've never used before. Everything is Verb-Noun, Get-Service, New-Service, Restart-Service, Stop-Service, etc.

Discoverability is valued over succinctness.

A recent example, looking for errors in windows logs:

    Get-Childitem "C:\Windows\" -recurse -Include *.log ` | Select-String "Error" -ErrorAction SilentlyContinue ` | Group-Object filename | Sort-Object count -descending

    grep -r Error /var/log/ | sort

I love what Powershell can do, but gods do I hate typing it.

The equivalent to the UNIX line above in Powershell is:

      ls "C:\app\*.log" -R  | sls "Error" | sort       

The only big difference between PS and UNIX in an actual analogous example is that the PS version of grep gets files fed in one by one and processes them, whereas UNIX's grep processes files itself.

PS - The above Powershell code may not work in 2.0 (2009). You'll need 3.0 (2012) or higher.

By the way, your example is precisely 12 characters longer than mine and still multiple times shorter than the equivalent PS, so if your goal was to somehow disprove PowerShell's annoying verboseness rather than snark at me, you failed.

Then check your examples before you post them to make a specific point. It is a point of fact that calling those two things "analogous" is incorrect, and your offense doesn't change that fact.

You also specifically said "I can think of" implying that you created the examples rather than that you got them from an "internal wiki." The fact that you said you thought of the UNIX example gives me solid ground to describe the created example as disingenuous.

I cannot help it if you're being misleading about how your got your examples.

> By the way, your example is precisely 12 characters longer than mine and still multiple times shorter than the equivalent PS, so if your goal was to somehow disprove PowerShell's annoying verboseness rather than snark at me, you failed.

My point was your examples were poorly constructed and misleading. I proved my point I believe. The difference between my accurate example of PS and your inaccurate example are night and day.

I'll leave it up to the reader to decide if PS's syntax is more to their liking. I just think they should start off with accurate information so they can form an accurate determination themselves.

In other words I won't get drawn into comparing my PS example with your UNIX example. I just want both examples to be truly analogous of one another.

I think you didn't realize, but what Someone1234 has there is the equivalent PS, not UNIX shell.

    (iwr "http://Slashdot.org").Links | select href

    lynx -dump -listonly http://Slashdot.org

    curl http://slashdot.org/ | grep -o "href=[\"'][^\"']*" | sed -e "s/href=\"//"

    curl http://slashdot.org/ | hxpipe 2> /dev/null | grep Ahref | sed -e "s/Ahref CDATA //"

I'm not sure how robust your hxpipe example is against those.

But since you asked, hxpipe assumes that href on a non anchor tag is an error and should be represented as an Ahref... which isn't too bad an assumption to make, tbf. The other situations is dealt with (text content, javascript).

But really, taking the above into consideration, the might in powershell comes not from the terms used, in my opinion, but how it works on things. With grep for example, you're parsing a file. If say, you wanted to filter on that more, you'd be using awk to pick out parts of the text.

In Powershell, everything's an object. Everything's already an object, you don't need to pick the file apart to isolate the date, you just filter on the date object. It's got a data type.

That makes it really powerful, in my opinion.

(Example largely pulled from "Windows Powershell in Action". I really like this book, as it goes into detail to describe /why/ things are they way they are in PowerShell, because he wrote it. =) https://www.manning.com/books/windows-powershell-in-action-s...

Not really, as everything is given an unreadable alias anyway, and many are given multiple aliases: Copy-Item -> copy,cp,cpi. So there are just more names to learn.

Personally, I never use them. I saw them more as a help for people coming over from bash.

For the thing to become usable, you have to do personal configuration, meaning your system will be unusable to anyone else and theirs will be unusable to you.

Back to the drawing board...

Cumbersome. To create my own cmdlet that does the cool stuff Powershell can do (as far as piping) my choices are a terrible language like ps1 or .NET.

On Unix I can use pretty much whatever I want because the shell isn't tied to a specific runtime.

If you want, your PS commandlets can return strings as well, so it's not like every part of your pipeline has to be in PS either.

Get-Content = gc or cat

for example

In contrast, I was a desktop (laptop) Linux user until a year or so ago, and found my skills almost entirely transferable to OS X.

The biggest aid was finding a terminal emulator that worked like Mac's Terminal.

Also you can still run EMET on Windows.

I feel like I know how to reduce the attack surface a bit more easily on linux client systems. Most OEM Windows installations are pretty bad, so I would want to install Windows myself, sans crapware, and with unneeded built in services, apps and hooks and so on removed. If the bootloader was locked, I'm not sure whether I could reinstall the Windows OS of my choosing. Maybe these products have less crap on them though, since the OS image comes directly from Microsoft.

I didn't mean to refer to situations other than personal clients used by me, and I don't really have an opinion about this in general, except maybe: It depends... :)

Maybe. Have they fixed UAC not being security boundary [1] if you are on a default administrator account? It's hard to take them seriously when most software for most users still runs effectively under 'root'.

[1] http://www.pretentiousname.com/misc/win7_uac_whitelist2.html

Can you elaborate on this or provide some sources?

We, as users, have no way of verifying what BitLocker does, if it has backdoors, etc.

BitLocker is secure in that it keeps out the attackers. If it keeps out the NSA is a different story (one that is much harder to determine).

So far I have mixed feelings about tablets. I like the "tablet" part but not the "it is cryptographically sercured from doing anything that might upset a government, corporation, or business model" part.

Obviously nobody outside of Microsoft will know if that remains true with the Surface Pro 4.

    On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
    ...
    B.If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
    ...
    Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

The closest thing I found is https://msdn.microsoft.com/en-us/library/windows/hardware/dn... which isn't really a spec, but does say:

    For most PCs, you can disable Secure Boot through the PC’s firmware (BIOS) menus. For logo-certified Windows RT 8.1 and Windows RT PCs, Secure Boot is required to be configured so that it cannot be disabled.

"The precise final specs are not available yet, so all this is somewhat subject to change, but right now, Microsoft says that the switch to allow Secure Boot to be turned off is now optional. Hardware can be Designed for Windows 10 and can offer no way to opt out of the Secure Boot lock down." http://arstechnica.com/information-technology/2015/03/window...

it is a painful install process, but that should change completely with ubuntu 15.10

I have a powershell console open on Win10 just as often as I have the terminal open on OS X. It's just a different dialect of command line than what some folks are used to

Microsoft explicitly has made Windows10 Docker compatible.

One notable thing from the blog side was significant issues with RoR, but otherwise I think there's a lot of good.

VMs are 100% the way to go, but I am consistently frustrated by incompatibility, especially with the nodejs ecosystem. Windows users are a huge minority so tools are rarely built with a non *Nix environment in mind.

I prefer this over OS X on Apple hardware because I can get the exact Unix experience that I want without having to fight with Apple about who is in control of the machine. Perhaps more importantly, I get the desktop experience that I love, which is Windows.

One good reason is window managers , with windows 10 window manager I get almost perfect tiling window manager functionality , but with tabs ?

Didn't know about super putty - switching today.