SoylentNews is people
SoylentNews
from the files-are-great-but-just-wait-until-they-include-rasps dept.
Microsoft Brings Linux Files to Windows 10 with New Update:
Windows 10 build 19603, which is now available for download in the Fast ring, includes File Explorer integration in the Windows Subsystem for Linux, or WSL.
In other words, if you have already installed WSL on your device, a new Linux drive will show up in File Explorer, letting you browse files normally.
Support for accessing Linux files that you work with in WSL isn't new in Windows 10, as such capabilities have previously been enabled in an older release. In fact, even production devices can do this starting with Windows 10 version 1903, which was released in the spring of 2019.
[...] "We've had the ability to access your Linux files since Windows 1903, but now you can easily get to them from your left-hand navigation pane in File Explorer. Selecting the Linux icon will show you a view of all your distros, and selecting those will place you in the Linux root file system for that distro," Microsoft explains.
(Score: 3, Informative) by RamiK on Friday April 10 2020, @01:00AM (2 children)
Because WSL1 was a NTKERNEL service(/daemon) that implemented linux syscalls, a virtual file system and an elf runtime loader to execute linux userland software not too unlike WINE. So, it was a Windows Subsystem for (executing userland) Linux (software).
WSL2 btw is a VM with some integration features on the Windows host side like this virtual file system mount as well as some optimizations on the linux client kernel and user land side. However, it's still a Windows (virtualization) Subsystem for (executing) Linux (kernel and userland).
YYMM is a fairly reasonable naming convention.
compiling...
(Score: 5, Funny) by jb on Friday April 10 2020, @06:25AM (1 child)
Spoken like almost every cobol programmer before about 1990.
(Score: 4, Interesting) by canopic jug on Friday April 10 2020, @02:38PM
It's easy to say now. These days disk storage is more or less free. Though as late as the 1980s disks, even with the advent of hard drives that could fit on the desk and could be used without hearing protection, storage was not only very limited in capacity but also very, very expensive. Recording dates as YYMMDD instead of YYYYMMDD saved both a noticeable amount of expensive space AND reduced retrieval time by a discernable amount. On top of that, management then as now didn't either know or care anything about computers or plan more than a few months ahead. We all know how that story played out.
Years later, people worked hard to make up for those shortcomings and retrofitted the old programs culminating in a rush peaking right before the Y2K rollover. However, we can't use the same delayed approach to the 2038 problem with 32-bit time. It is not feasible to change the operating system or kernel on most embedded systems and many have been scheduled long lifecycles. So some embedded systems which have been deployed recently, still with 32-bit time, are very likely to be in use when the time rolls over according to their planned lifecycle. Because most will not be patchable and all of them wil be very hard to replace even with months of planning and coordination, the time is now to produce all new embedded 32-bit microcontroller systems with 64-bit time. It's getting very late in that regard.
Money is not free speech. Elections should not be auctions.