Linux Subsystem Files To Become Accessible via Windows File Explorer (zdnet.com)
One of Windows Subsystem for Linux's more annoying tricks is it's hard to get at your Linux files from Windows. From a report: Oh, you can do it, but you take a real chance of ruining the files. To quote Microsoft, "DO NOT, under ANY circumstances, access, create, and/or modify files in your distro's filesystem using Windows apps, tools, scripts, consoles, etc." In the forthcoming Windows 10 April 2019 Update, aka Windows 10 19H1, this Linux file problem will finally be fixed. According to Craig Loewen, a Microsoft programming manger working on Windows Subsystem for Linux (WSL), "The next Windows update is coming soon and we're bringing exciting new updates to WSL with it! These include accessing the Linux file system from Windows, and improvements to how you manage and configure your distros in the command line."
I could access Windows files on Linux just fine. Some OSs are behind the times I guess.
uses a lot more RAM though.
I teach computer science at a state school. And some students laptop can not quite run VMs, for a bunch a reasons (that range from shitty hardware, to not enough memory, and through the virtualization bit got disabled in the BIOS because the constructor wanted to sell a more expensive laptop for developpers).
I had used WSL for the class. And that was a complete catastrophe. The filesystem interaction were just not working right. I am guessing it is because students went editting the file through the file explorer. But we were getting the strangest bugs.
So I have told students to absolutely use the VM and we are working around the few cases of laptops that are not quite good enough. And the clas goes fine so far.
If MS can deliver a working WSL, I may consider using it again.
Notice that all of these changes to windows are 1 way: They all provide windows access into the linux sub-systems, not the other way around... This is not an accident, and it is not in your best interests
Do not use MS products unless you want to continue your guaranteed lock in as their cash cow. You are the product, you are for sale, but you will not see a dime of the profit.
I wish I had a good sig, but all the good ones are copyrighted
If you haven't tried it recently, you can think of it as a lighter-weight and more complete version of WSL.
For Ctrl+c for copy, you should blame Xerox P.A.R.C., not Microsoft. Actually, microsoft follows convention. In the GUI ctrl+c is for copy, while Ctrl+c in comand line is interrupt, just like in *nix. So, no "deliberate incompatibility"
About c:\folder\subfolder, you should ask the CP/M guys. You see, they used the / for parameter passing, so when MSoft decided to support folders in MS-DOS 2.0 onwards, the character was already in use. Actually, if memory serves well, there was an obscure command in early MS-DOS to change the path separator to / . Since no one used it, it was retired without much fanfare. So no "deliberate incompatibility here". As a matter of fact, at that time MSoft was selling a unix (called Xenix) and, if anything, they wanted MS-DOS and Xenix to converge, that's why they included the aforementioned obscure command.
About the line endings, as some other comentator indicated, using CR+LF together meant that you could copy a plain text file to the printer directly without further conversion. And also, dos (and windows latter), mac and *nix all had differnt ways of skinning that particular cat. And do not even ask about the complications of line separation in VMS, you will not believe it!!!. So, no "deliberte incompatibility" here.
If you want examples of deliberate incompatibility, better check your history books for things like running Windows 3.x on DR-DOS, or running lotus 123 on early versions of Windows, that sort of thing, but, the three examples you choose, don't quite cut it.
*** Suerte a todos y Feliz dia!
Why did Microsoft make "Ctrl-c" the keyboard shortcut for copy? Because ctrl-c on unix hard exits programs.
For Mac compatibility. The correct Windows shortcut for copy is ctrl-insert, paste is shift-insert and cut is shift-del. Try them, they still work fine, even in most Linux programs.
The slash vs backslash comes from copying CPM where slash was used for parameters and there were no subdirectories. In this day, all programs should support both slash and backslash as directory separators
MS line ending are actually more correct, a CR (carriage return) to bring the cursor to the beginning of the line and a LF (linefeed) to do a linefeed. Trying to save bytes resulted in using a linefeed as a line ending. Apple was closer where the CR as a line ending was much like a typewriter. BTW, back in the '60's, the ASCII standard was decided.to have both as EOL chars rather then a dedicated one.
The : goes back to PDP 8 where devices ended with a : such as CON: before you ask.
https://en.wikipedia.org/wiki/Inverted_totalitarianism
Many linux users do care. Those that use Linux at home (or used it at a previous job, or learned it in the university), and would like to use linux at work, but their company policy forbids it. Also, may, many, windows users care about it too...
There are a bunch of reasons to use this WSL thing. But before we get to those reasons, let's clarify something. If someone is already happyly using Linux, WSL will not make them go back to Windows. WSL is targeted to people who must use windows, or want to use Windows, for most of their tasks. After all, if most of your SW was in linux, and your company allowed you to run linux, you would be running Linux on the bare metal, and would be dualbooting windows (for gaming), and running windows in a VM from the raw partition (for other SW) like I do on my MAC (with macOS instead of linux, but you get the idea).
Many of the reasons for WSL were articulated elsewere in the thread, but I'll recap and add some of my own:
1.) Reiterating, for whatever reason you must run Windows (company policy, most of your SW is in Windows, you are more familiar with windows, etc), yet you need some specific linux things for whatever reason*.
2.) Your machine can not run a VMM because:
2.a) Your machine is low on resources to run a VM. Not unheard of in corporate, even for technical people.
2.b) Your processor does not support VM acceleration, which leads you to low performance, which leads you to 1.a).
2.c) The manufacturer of said machine disabled HW VM Acceleration in the BIOS/UEFI, which again leads to 1.a)
2.d) Your company's policy does not allow you to run the VM SW, or the company policy disables the VM acceleration in the firmware (or both).
3.) You do not know or care to learn how to set up a VMM (Virtual Machine Monitor, ex. WMware Player, VirtualBox, etc). *
4.) You do not know how or do not want the hassle to create the VM and install a distro from scratch. Nor the pain of configuring USB passthroughs, shared folders, shared clipboards and whathaveyou. *
5.) You do not want to learn the ins and outs of alternatives like Cygwin* (or you are forbiden to run it as per company policy)
Now, what are the advantages of using WSL:
i.) Is right there on windows, so all previous 5 points are solved in one fell swoop.
ii.) If you want to do some shell script or use some SW (say, ssh) that for whatever reason is easier for you on *nix than on powershell, is right there.
iii.) If there is a piece of SW that you need to use that is linux only (say, as some poster indicated, toolchains for enbeded SW development), is right there.
iv.) All pheripherals are integrated. So no USB/PCI passthough, or weird interactions because of the VM drivers, or GuestAdditions to install.
v.) Performance is better than in a VM, for both the Windows side and the Linux side.
vi.) If you are a windows user who wants to learn or experiment with the comand line side of linux, is a good place to start.
vii.) If there is some linux thing you need to test, perhaps you can test it here.
viii.) If there is something you need to develop, and your IDE runs here, you can develop it here.
JM2C YMMV
* Believe it or not, some very smart and technically inclined people do not like to endlessly fiddle with computers as an end to itself, for them the computer is a tool to do a job, and the idea is to do the job through the path of less ressistance.
I used to fiddle a lot in my young age, CP/M, Apple DOS, C64, MS-DOS, Windows, OS/2, FreeBSD, Linux, and in my Sysadmin days, Solaris, HP-UX, Linux, Windows, Sinix, VMS to name a few. But, nowadays I value other things in my life. My confort included. The liberty to fiddle when I want to , instead of being forced to fiddle because something goes wrong. So macOS it is, with VMs for windows, Khali, Tails and #!++ and Bootcamp for games... Nice GUI on the outside, commercial SW aplenty (word, excel, and powerpoint are very usefull when interacting with corporate clients), BSD-ish guts, well integrated HW/OS/Kexts. The only thing to complain about is the price of the combo, but that is why I worked hard, to be able to afford some luxuries. (Before you ask, android cellphone, no tablet).
*** Suerte a todos y Feliz dia!
Sorry to be pedantic... IIRC, DOS file I/O primitives would accept either '\' or '/' as a path separator. COMMAND.COM was the issue; it would always interpret '/' as the beginning of a command-line option. If you were writing a command-line utility, it could employ "C:\path\to\my\file" or "C:/path/to/my/file". Actually, I think you could pass "C:/path\to/my\file" and that would still work. Yes, there was an internal variable inside DOS that recorded the option character; I think it was "SWITCHAR", and you could alter it in your environment (e.g. AUTOEXEC.BAT). Setting "SWITCHAR=-" meant that COMMAND.COM options now begin with '-', like UN*X. This took effect on the command-line, and inside .BAT files. But now your .BAT files are incompatible with everybody else's system...
Oh, yeah. I think CP/M copied the "/option" convention from DEC's RSTS.
Switchchar was the eviroment variable for DR-DOS. In MS-DOS the procedure was different, but the idea was the same. Do not feel bad though. I can't remember how it was done in DOS either, It has been a looong time.
*** Suerte a todos y Feliz dia!