Live data from Hacker News

Microsoft's Linux Kernel

github.com

281–290 of 532 posts

Re: Microsoft's Linux Kernel

#281
post #172

Earlier quoted context omitted.

> 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 on…

Accessing Windows' NTFS volume from WSL2 Linux is (and will always be) even slower. I have no doubt they've could've substantially improved file access, but management pulled the plug. WSL1 was basically just a proof of concept, afterall. Also, don't forget that Windows and NTFS has never been known for performance. Expecting file access to be as fast as ext4 from a Linux kernel was just the wrong set of expectations…

[deleted]

Re: Microsoft's Linux Kernel

#282
post #27
post #6

My 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…

problem is the kernel is sitting on top of a binary blob, and that manipulates the access to the real machine. we shouldnt be so worried about the kernel, we should be concerned about what the binary between the kernel and the hardware is doing/notdoing , and what degree of control do we have over that layer.

As far as I know the binary blob is packed with anti-user features such as ads and mandatory telemetry.

It's not very sane to run anything on Windows.

Re: Microsoft's Linux Kernel

#283
post #172

Earlier quoted context omitted.

> 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 on…

Accessing Windows' NTFS volume from WSL2 Linux is (and will always be) even slower. I have no doubt they've could've substantially improved file access, but management pulled the plug. WSL1 was basically just a proof of concept, afterall. Also, don't forget that Windows and NTFS has never been known for performance. Expecting file access to be as fast as ext4 from a Linux kernel was just the wrong set of expectations…

WSL2 does use 9P, here is the BUILD session about it.

"The new Windows subsystem for Linux architecture: a deep dive - BRK3068"

https://www.youtube.com/watch?v=lwhMThePdIo

Re: Microsoft's Linux Kernel

#284
post #122

Earlier quoted context omitted.

Why would MSFT throw away decades of development that have gone into the NT kernel? NT is an advanced and, to my eye, very elegant kernel. Win32 is much less so, but NT isn't Win32.

Because sunk costs and it may make sense to offload their kernel development efforts to focus on what makes them money.

Windows makes them plenty of money, billions of it.

Re: Microsoft's Linux Kernel

#285
post #268

Earlier quoted context omitted.

> classic example are laptops that dynamically switch between discrete and integrated graphics YMMV, but as far as I know that's more or less a solved problem by default (for X anyway) with DRI3. This particular complaint echoes folks (I was one) who booted Ubuntu desktop a decade ago and couldn't get wifi to work, and proceeded to complain about shoddy driver support (to present day, clearly), using only that single…

I'm not sure how the bubble you live in came to be but for ordinary desktop/laptop hardware that is as false as can be. And there is a very simple reason for that. All desktop PCs and laptops are sold with windows, if no support exist the hardware as a whole will not exist. Meanwhile in linux land I still can't use my three monitors because displayport MST doesn't work with the open source AMD driver. Support has exi…

It is not false. Complaining about obscure gpu driver feature not working in Linux kind of proves the parent's point. Most usual hardware works out of the box on Linux now, except for the nvidia cards, but even that can be made to work with their binary driver. If the AMD driver does not support some obscure feature, that is on AMD. They work on it, complain there, but naturally some things have higher priority than driving multiple monitors from a single port.

Re: Microsoft's Linux Kernel

#288
post #268

Earlier quoted context omitted.

I'm not sure how the bubble you live in came to be but for ordinary desktop/laptop hardware that is as false as can be. And there is a very simple reason for that. All desktop PCs and laptops are sold with windows, if no support exist the hardware as a whole will not exist. Meanwhile in linux land I still can't use my three monitors because displayport MST doesn't work with the open source AMD driver. Support has exi…

It is not false. Complaining about obscure gpu driver feature not working in Linux kind of proves the parent's point. Most usual hardware works out of the box on Linux now, except for the nvidia cards, but even that can be made to work with their binary driver. If the AMD driver does not support some obscure feature, that is on AMD. They work on it, complain there, but naturally some things have higher priority than…

I'm not blaming linux for manufacturer not supporting linux well enough. But I'm stating drivers are an immense issue for linux - regardless of who is to blame.

Maybe I shouldn't have started with an "obscure" example. Maybe that the driver crashes if displays are awakened from sleep? Mind you - only waking the screens from sleep, not the entire system (that doesn't work either, but I don't know which driver that is to blame for that yet).

Or that ubuntu LTS are just incapable of turning off most machines I've installed it on? (machines that did exist for a while when the LTS version came out).

Re: Microsoft's Linux Kernel

#289
post #238
post #226

Earlier quoted context omitted.

Drivers are far from the biggest problem for Linux adoption. The biggest problems are: + Network Effects + Brand recognition in the general public + Indifference to FOSS principles + Resistance to change

One more: OEMs like Dell and HP aren't allowed (by Microsoft) to sell PCs that dual-boot between Windows and something else, such as GNU/Linux so the only people that get to try Linux are those that have it pre-installed as the only OS, or those willing and able to install it themselves. Source: read about it somewhere or other; main topic was the history of BeOS.

This (the OEM deals) is really by far the biggest problem that Linux has on the desktop.

Microsoft still plays dirty and has done that for a long time.

Re: Microsoft's Linux Kernel

#290
post #6

My 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…

I had to laugh when I read about this "Ubuntu install process" - Is there really still people on earth who can screw that up? :-D
Post reply on HN