Windows 10 SP1 will have UBUNTU developer support !!!!

[tServo]

It's NOT exactly Linux and Windows 10 running together, but enough of Linux to make developing & compiling programs on one machine a real possibility! Think of it as MinGW or Cygwin built into Windows 10. Linux compilers, bash shell, languages, and utilities only a mouse click away. It could help maintaining a code base for multiple systems easier.
Unfortunately, I suspect Cuda testing would not be possible because of driver issues, but at least you might be able to do the compiles.
I have a Microsoft Surface running Win 10 I don't use much and will try to get the preview going over the next week or so as time permits.

Instructions and info:http://www.zdnet.com/article/ubuntu-...on-windows-10/

[casevh]

I installed it last night and took a quick look. It think it will be very useful to develop code that runs on both platforms. For developers, the most significant difference is that it uses the *nix convention that a C language "long" is 64-bits in length.

And if you install an X windows server in Windows 10, you can actually run some GUI applications....

[paulunderwood]

Originally Posted by casevh

And if you install an X windows server in Windows 10, you can actually run some GUI applications....

I wonder if one can run Primo under X Window on Win10.

[Mark Rose]

Originally Posted by paulunderwood

I wonder if one can run Primo under X Window on Win10.

Not quite.

Basically, what MS has done is an implementation of the Linux API -- the kernel calls accessible from user space. It doesn't include access to the hardware which Xorg needs. You could, however, run a virtual frame buffer using the vncserver command, and then run a Windows VNC client to connect to it.

[xilman]

Originally Posted by tServo

It's NOT exactly Linux and Windows 10 running together, but enough of Linux to make developing & compiling programs on one machine a real possibility! Think of it as MinGW or Cygwin built into Windows 10.

I prefer to think of it as Eniw.

[casevh]

Originally Posted by Mark Rose

Not quite.

Basically, what MS has done is an implementation of the Linux API -- the kernel calls accessible from user space. It doesn't include access to the hardware which Xorg needs. You could, however, run a virtual frame buffer using the vncserver command, and then run a Windows VNC client to connect to it.

I have run an X server on Windows (tested both Xming and MobaXterm) and then remotely displayed the application on the X server. I was able to get scite (a text editor) and gimp (graphics manipulation) to run. I haven't tried running an entire desktop environment. I'm not confident that it will work, especially any modern desktop that relies on systemd.

Many other applications are available. I've installed, but not yet tested, gmp-ecm and pari-gp. I'll test Primo later.

casevh

[bgbeuning]

The file-system is still case insensitive. So code may compile with gcc
under the Linux subsystem of Windows but then not compile on native Linux.

[chalsall]

Originally Posted by bgbeuning

The file-system is still case insensitive. So code may compile with gcc under the Linux subsystem of Windows but then not compile on native Linux.

Interesting...

If you run the command: "ls -la /usr/lib/" in that environment what do you see?

[bgbeuning]

The current release is a Beta. The official is due this summer. Maybe it will be fixed by then.

NTFS supports two slightly different modes of operation that can be selected by the subsystem of the application interacting with NTFS. The first is fully case sensitive and demands that file names supplied by the application match the names stored on disk including case if the file on disk is to be selected. The second mode of operation is case preserving but not case sensitive. This means that applications can select files on the disk even if the supplied name differs in case from the name stored on the disk. Note that both modes preserve the case used to create the files. The difference in behavior noted here applies only when an application needs to locate an existing file. POSIX takes advantage of the full case sensitive mode, while MS-DOS, WOW, and Win32 subsystems use the case insensitive mode.

The POSIX subsystem has been around since Windows NT (but I have never figured out how to use it). Maybe they need to make the Linux subsystem use the same mode as POSIX.

[retina]

So how does the case insensitive file selector work for two files named the same but only differ in case?

[casevh]

Originally Posted by bgbeuning

The file-system is still case insensitive. So code may compile with gcc
under the Linux subsystem of Windows but then not compile on native Linux.

I tried a simple test on Preview Build 14328 that was released today. From the bash shell, the commands:

echo "a" > a
echo "A" > A

created two separate files. The file named a contained the letter a. The file named A contained the letter A.

From the Windows command prompt, the commands:

echo a > a
echo A > A

created a single file. The resulting file was named a and contained the letter A.

At least with this test, it does appear that the Linux subsystem is case-sensitive. I don't know if this is a sufficient test.