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

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:[URL="http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/"]http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/[/URL]

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....

[QUOTE=casevh;432227]

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

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

[QUOTE=paulunderwood;432229]I wonder if one can run Primo under X Window on Win10. :smile:[/QUOTE]

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.

[QUOTE=tServo;432225]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. [/QUOTE]
I prefer to think of it as Eniw.

[QUOTE=Mark Rose;432231]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.[/QUOTE]

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

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.

[QUOTE=bgbeuning;432255]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.[/QUOTE]

Interesting...

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

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

[QUOTE]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.[/QUOTE]

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.

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

[QUOTE=bgbeuning;432255]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.[/QUOTE]

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 [B]a[/B] contained the letter a. The file named [B]A[/B] 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 [B]a[/B] 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.

[QUOTE=paulunderwood;432229]I wonder if one can run Primo under X Window on Win10. :smile:[/QUOTE]

I tried running Primo but was not successful. Primo generated an error that it could not allocate shared memory.

[QUOTE=xilman;432241]I prefer to think of it as Eniw.[/QUOTE]

This is genius, sir. :tu:

[QUOTE=casevh;432291]I tried running Primo but was not successful. Primo generated an error that it could not allocate shared memory.[/QUOTE]

[URL="https://www.msi.umn.edu/~cpsosa/ChemApps/QuaChem/gaussian_tech/support/download/Linux_shared_mem_seg.html"]This link[/URL] might help you set shmmax to whatever Primo says it needs :smile:

[QUOTE=paulunderwood;432296][URL="https://www.msi.umn.edu/~cpsosa/ChemApps/QuaChem/gaussian_tech/support/download/Linux_shared_mem_seg.html"]This link[/URL] might help you set shmmax to whatever Primo says it needs :smile:[/QUOTE]

I get an error of "operation not permitted" when trying to write to either /proc/sys/kernel/shmmax or /proc/sys/kernel/shmall.

There are other inconsistencies. The /dev/shm directory is a symlink to /run/shm but /run/shm does not exist. As expected /dev is a tmpfs (think RAM disk) but /run does not appear to be a tmpfs. I think /run should also be tmpfs.

Hopefully this will get fixed by Microsoft/Canonical.

[QUOTE=VBCurtis;432294]This is genius, sir. :tu:[/QUOTE]I'm pleased to see someone understood it. Some times my humour is just too obscure.

[QUOTE=bgbeuning;432286]The current release is a Beta. The official is due this summer. Maybe it will be fixed by then.



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.[/QUOTE]Anyone else here remember Services For Unix? It used the POSIX subsystem.

Try

cat a A

[QUOTE=bgbeuning;432313]Try

cat a A[/QUOTE]

~/test$ cat a A
a
A

[QUOTE=xilman;432305]Anyone else here remember Services For Unix? It used the POSIX subsystem.[/QUOTE]

I remember that... in all my years, starting with NT 3.51, I think I used the SFU features just once, and now I don't even remember what for. Probably goes back to when I was contracting for a certain telco and there were some legacy integrations to fuss with.