Just noticed the contributors as showing "∞ contributors" :D
On Firefox for Android I have ∞ tabs open :)
Microsoft's Linux Kernel
151–160 of 532 posts
Re: Microsoft's Linux Kernel
#152Embrace... Extend...
socialize the development, privatize the profits?
Re: Microsoft's Linux Kernel
#153Earlier quoted context omitted.
I'm nervous about WSL 2. I use WSL at home quite a bit and I'm on the Fast Insider ring. My PC hasnt been able to boot Win10 for over a year with virtualization support enabled in my BIOS. No errors or anything, just hangs at boot. Ive left feedback in the hub, but crickets. Don't know what the problem is. It used to work, but at some point an update broke it. Not bleeding edge hardware, either. About a 4 to 5 year o…
Why is op getting downvoted? This is a legitimate issue he’s facing on a specific hardware configuration
This is a total aside, but I really don't understand voting on comments. I've no idea what it could mean - levels of agreement, interest, offensiveness (or scores of other possibilities)? It seems entirely meaningless, therefore pointless, to me.
Re: Microsoft's Linux Kernel
#154Earlier quoted context omitted.
> What people need on drivers? USB (and with usb-c), hdmi, bluetooth (maybe?) Do you honestly think there is a single USB-C driver that covers literally everything that can connect over USB? And anything with an HDMI port uses the same driver!?
No, but I suspect the array of devices is more narrow than suspected? I think that nail the software (app + dev experience) is a bigger challenge and priority than worry about the (external) hardware. P.D: One thin I forget to articulate is the possibility to leverage linux as a bridge for drivers (possible)? so the new OS ship a smallish linux just for get compatibility.
Then you're just making a Linux distribution, or something like Android I suppose. You may as well say extending Chromium would solve the web monoculture issue. That isn't how it works.
> I think that nail the software (app + dev experience) is a bigger challenge and priority than worry about the (external) hardware.
You are ludicrously wrong. Using the Linux kernel as an example, because drivers are in-tree, as of 4.19 (late 2018): https://raw.githubusercontent.com/udoprog/kernelstats/master...
As you can see, drivers are the vast majority of the kernel. And Linux's hardware support is often called out as a reason people use Windows or MacOS!
Re: Microsoft's Linux Kernel
#155Earlier quoted context omitted.
This will make windows more linuxy than macos. So for all that just want a local nix enviroment for dev (and to most these means linux), Microsoft has actually beat Apple at this.
... except that (a) WSLv2's kernel will be running in a VM, and (b) macOS's kernel is much more like Linux's -- fork/exec, networking, filesystem, memory, TTY. I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.
NT supports interfaces for supporting a fork model efficiently, it's just not well documented. In fact, you can write an efficient, Windows-native POSIX environment entirely from user space using existing APIs: https://midipix.org/
The only thing that NT really lacks is a Unix-style TTY subsystem. The interplay in Unix between TTYs, process control, and signals is complex and deep, and none of it lends itself toward abstractions--it's all quintessentially Unix. For almost everything else, NT provides interfaces that can be used to efficiently implement Unix semantics.
Microsoft isn't interested in supporting a modern POSIX environment natively as that would merely accelerate the migration of the software ecosystem away from Windows APIs. IMO, it's why they killed WSL1. WSL1 was de facto a modern, native Unix personality on NT. They may not have managed 100% Linux compatibility, but they could've simply relabeled it Windix or something, used a small team to round things out, and received UNIX V7 certification in a jiffy.
WSL is about managing the shift toward a Linux-based cloud world, capturing as much of that business as they can without unnecessarily risking their existing footprint. WSL2 neatly allows them to maintain Windows API lock-in while also providing substantial value for those needing to develop Linux-based software. WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
Re: Microsoft's Linux Kernel
#156My brain threw an exception when I read this title. Awesome that this is a reality though. Now that we have a Linux kernels running and accessible on both Windows and Chromebooks I feel like we can finally say: 2019 actually is the year of Linux on the desktop. It's not a meme anymore, it's finally just a true statement. Edit: To those questioning if this really counts as Linux on the Desktop. Yes, I understand what…
Well, technically yes, but…talk about moving the goalposts! Almost like swapping the goalposts.
Yep, except in this case is just one goalpost and everyone wins. Now we can enjoy using software as MS Office and userland from Linux distros in the same machine seamlessly.
Re: Microsoft's Linux Kernel
#157I'm sure that I'll have a nightmare tonight where I'm stuck in a Scooby Doo episode, and they unmask the ntoskrnl.exe binary to reveal this Linux kernel underneath....
Re: Microsoft's Linux Kernel
#158I wish Microsoft would release their own linux-based OS with a compatibility layer to let me run Windows apps. I'm not overly impressed with the direction Apple is going but I really enjoy a *nix-native environment too much to go back to vanilla Windows. It would change the math a lot for me if it was full-blown linux under the hood.
This is probably an unpopular opinion but.. there is a lot of value in having multiple competing kernels. In the same vein as browser engines, any monoculture is a bad idea. Not to mention there's been a lot of good work done on the NT kernel itself. Under the hood it's pretty advanced, even with all the user-space cruft on top.
We don't need NT to have competing kernels. All of the following have their own kernels:
+ FreeBSD
+ OpenBSD
+ NetBSD
+ DragonFlyBSD
+ Minix
+ Haiku
+ Redox
+ Plan 9
+ SeL4
+ Fuchsia
Re: Microsoft's Linux Kernel
#159Earlier quoted context omitted.
do you know if there's hardware pass through for gpu? ie can you do cuda stuff in wsl2?
On Twitter, the team has said [1] it won’t be supported at launch but that this will make it easier to add that support in the future. [1]: https://twitter.com/tara_msft/status/1125888319974400000?s=2...
I really hope this results in PCIe passthrough on Hyper-V becoming reasonable, it was an absolute nightmare to try to configure and I could never get it to work more than a single VM boot.
Re: Microsoft's Linux Kernel
#160Earlier quoted context omitted.
... except that (a) WSLv2's kernel will be running in a VM, and (b) macOS's kernel is much more like Linux's -- fork/exec, networking, filesystem, memory, TTY. I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.
NT supports interfaces for supporting a fork model efficiently, it's just not well documented. In fact, you can write an efficient, Windows-native POSIX environment entirely from user space using existing APIs: https://midipix.org/ The only thing that NT really lacks is a Unix-style TTY subsystem. The interplay in Unix between TTYs, process control, and signals is complex and deep, and none of it lends itself toward…
> They may not have managed 100% Linux compatibility, but they could've simply relabeled it Windix or something
My take on it was that they were never able to implement all the syscalls (WSL just couldn’t reliably run some production server software), and filesystem calls were horribly slow (try npm install on a reasonably large JS project if you have any doubt).
You may be right — but I’d still like to dream that one day Microsoft will release a true Linux (or OpenSolaris, BSD, or whatever!) OS of their own, which their Office apps will fully support. That’ll be the day I weigh another option besides macOS.