Didn't Microsoft agree to never ship a Unix again when they sold Xenix?
Linux is not Unix.
I can't find details of the sale so maybe I'm wrong, but I thought it also applied to clone products.
Microsoft's Linux Kernel
461–470 of 532 posts
Re: Microsoft's Linux Kernel
#462Earlier quoted context omitted.
With great power comes great responsibility, I guess. I agree it would have been nice for Linux to come with a few more sanity checks by default, like maybe a warning flag for rm -rf /* and dd commands...
I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick. You don't even get a basic command prompt to fix something, the default behavior is to lock everything down and forbid access, making it impossible to repair the machine from itself. Windows will reboot a few times and then automatically start in safe mode when this happens, you don't need to extract the drive to…
FWIW, you're using the word "brick" incorrectly. Bricking is when the only fix is to throw the device away and buy a new one, which clearly is not the case here.
Re: Microsoft's Linux Kernel
#463Earlier quoted context omitted.
I'm just more offended that the default behaviour on an extremely popular distro is failed boot = brick. You don't even get a basic command prompt to fix something, the default behavior is to lock everything down and forbid access, making it impossible to repair the machine from itself. Windows will reboot a few times and then automatically start in safe mode when this happens, you don't need to extract the drive to…
FWIW, you're using the word "brick" incorrectly. Bricking is when the only fix is to throw the device away and buy a new one, which clearly is not the case here.
I don't think I am. I've been fixing hardware for years and any device that doesn't switch on is "bricked" - its utility has dropped down to zero, it has turned into a literal brick. Just because you can revive it through some arcane procedure doesn't make it any less bricked to the end user.
Re: Microsoft's Linux Kernel
#464Earlier quoted context omitted.
Do Docker people really think it’s a VM? Or has the meaning of “VM” shifted this past year?
I think the OP is probably referring to the fact that running Docker on Windows and macOS is accomplished by running a Linux VM which the Docker containers run in. Not that Docker containers are VMs.
This is what I meant by this. Most people I know using Docker are not on Linux but on Mac and Windows.
Re: Microsoft's Linux Kernel
#465Earlier quoted context omitted.
FWIW, you're using the word "brick" incorrectly. Bricking is when the only fix is to throw the device away and buy a new one, which clearly is not the case here.
I don't think I am. I've been fixing hardware for years and any device that doesn't switch on is "bricked" - its utility has dropped down to zero, it has turned into a literal brick. Just because you can revive it through some arcane procedure doesn't make it any less bricked to the end user.
Flashing a new OS onto the SD card is not "some arcane procedure" for the RPi's target audience.
Re: Microsoft's Linux Kernel
#466windows is bloated af, even more with this
they need to create their unix variant like macOS or people will continue to migrate to macOS
Re: Microsoft's Linux Kernel
#467Well that is pretty nice. WSL gets that much more exactly like Linux. What I really appreciate about WSL is that you get the accessibility of a bunch of OSS projects and a machine which has legit drivers for all of its component bits. What this means to me is that searching for a "linux laptop" won't be a chore, if it runs the latest Windows it will run Linux. And I can do development on the Linux side while communic…
There are a few annoyances with WSL2. For me the most important are: 1. You can't connect to a port listening on WSL localhost like in WSL1, you have to figure out the WSL IP address and use that. 2. From WSL you can't connect to a Windows TCP port on localhost, you must figure out the Windows IP (cat /etc/resolv.conf) and use that. 3. The WSL remote interpreter on PyCharm is not working anymore. The suggested workar…
A solution to the IP address problem might be to write the IP address to the Linux file system when Linux boots, then read it from Windows as part of your SSH launch.
Re: Microsoft's Linux Kernel
#468Earlier quoted context omitted.
> Linux won on technical merits Arguably. It's hard to say Linux won on technical merits of networking compared to FreeBSD or OpenBSD, or on storage compared to FreeBSD+ZFS, or say that generally when devs chose MacOS X. I suggest Linux won for being: the most popular out of the things which cost $0. BSD lost for not being popular, commercial Unix, Windows and MacOS lost for costing money.
> BSD lost for not being popular People used to say that BSD lost because of the ambiguous copyright status of the early 90s, allowing Linux to glide in unopposed as the "free unix-like os for PCs". https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.... . https://en.wikipedia.org/wiki/Berkeley_Software_Distribution...
While others say the GPL license is what created an ecosystem, whereby the BSD-3 won't create an ecosystem of same quality.
Re: Microsoft's Linux Kernel
#469Well that is pretty nice. WSL gets that much more exactly like Linux. What I really appreciate about WSL is that you get the accessibility of a bunch of OSS projects and a machine which has legit drivers for all of its component bits. What this means to me is that searching for a "linux laptop" won't be a chore, if it runs the latest Windows it will run Linux. And I can do development on the Linux side while communic…
I always thought someone could try one of these driver-reuse techs with Windows drivers. I recently posted two examples elsewhere:
https://www.usenix.org/legacy/events/osdi04/tech/full_papers...
https://os.inf.tu-dresden.de/Studium/KMB/WS2012/06-Drivers.p...
Well, a mix of Windows and Linux drivers where we use Linux whenever it works well enough. Windows when it doesn't. Might also be able to tie that in Windows Embedded to trim as much fat out of the driver VM as possible.
Re: Microsoft's Linux Kernel
#470Earlier quoted context omitted.
"windows process" is misleading, WSL uses a separate "linux subsystem" with its own syscalls, process/thread data structures, etc. It also uses its own file system (albeit with all the state stored in NTFS and affected by filter drivers, which is why its I/O is slow)
They are Windows processes, just as the Win32 subsystem also spawns Windows processes.
Probably best to refer to them as NT processes for the sake of clarity.