Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft's Linux Kernel

github.com

Post reply on HN
Print view View original

381–390 of 532 posts

Re: Microsoft's Linux Kernel

#381

Post by paranoidrobot »

filmor wrote: post #332
paranoidrobot wrote: post #199

Earlier quoted context omitted.

> What this ignores is that Linux driver support is generally fantastic, works out of the box in a way that desktop architects at MS dream about and is infinitely more current in practice since you go to one place to update all your software, including driver software, something MS hasn't been able to get right in a decade of trying. Generally, yes, it's pretty decent on first go and there's a nice default happy path…

Version compatibility is not an issue for in-kernel drivers, only for the few remaining external ones. On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista, on Linux, once a driver is in the kernel it's continuously adjusted to driver API changes and will keep working. You can still run a current kernel on a 386 if you want to. I…

> On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista,

I think that's a bit of a difference though. Vista came out nearly ~13 years ago, and we're talking things breaking a year or less later.

Heck, for more obscure drivers[1], it seems necessary to recompile for every kernel patch. Perhaps that's the fault of that driver's developer for not following the correct way to build kernel drivers, or there's something unique about this particular device - I don't know.

[1] an example: https://github.com/milesp20/intel_nuc_led

Re: Microsoft's Linux Kernel

#382

Post by acqq »

shigawire wrote: post #371
acqq wrote: post #341

Earlier quoted context omitted.

> rather than trying to fit Linux applications in Windows, they're running in their own world and providing integrations into this world. It is effectively their way to have an "integrated Linux virtual machine" inside of Windows. The WSL1 on Windows was relatively similar (but not enough for me) to Wine on Linux. The WSL2 is in some ways "more integrated" than the typical VM would be, but otherwise still similar to…

I think you can do it all from powershell if you want or there are really only 2 GUI steps. Yesterday I: 1. Enabled the Windows Subsystem for Linux option from the control panel 2. Downloaded Ubuntu from the windows store 3. Open Ubuntu and it worked.

Good. The last time I tried it was like "you just click... and then the problems just start":

https://www.reddit.com/r/bashonubuntuonwindows/comments/7smf...

Regarding the problems between the "different filesystems" it was like:

https://www.reddit.com/r/bashonubuntuonwindows/comments/9dkl...

Which was especially bad: what's the point in having it "there" if you aren't allowed to access the files inside.

Also problems with making a backup of that etc. In that aspects using a real VM (e.g. VirtualBox) the situation was much clearer.

So from my perspective it was both worse than Cygwin and worse (or at least not better) than real VMs... I would really like to read if/how WSL improved.

The similar experience was when I've tried to "just install ssh server". The things I've expected to "just work" didn't. Again at the end I've just used Cygwin.

Re: Microsoft's Linux Kernel

#383

Post by gorio »

goodcanadian wrote: post #363
gorio wrote: post #351

Earlier quoted context omitted.

I don't see how inertia would be the reason if you also believe that it has been good enough for 15 years. I would say desktop Linux simply doesn't offer enough unique value for the effort involved in large scale deployments, unless you are someone like Google. Most things that have improved for users in recent years, like web application, actually favours Windows. Because the primary use case for desktop operating s…

I said I've used it for 15 years not that it would've necessarily been a good choice for a non-technical user that long ago. On the other hand, non-technical users usually require significant IT support on Windows as well. That's where inertia comes in. Linux may not offer a significant value proposition over Windows, so Windows stays. That doesn't necessarily mean Windows offers a significant value proposition over…

> That doesn't necessarily mean Windows offers a significant value proposition over Linux either.

But as far as I know that is this case. That Microsoft's offering is much stronger when it comes to large scale corporate deployments. Unless you want to make the claim that e.g. RedHat's offering is on par or better, which isn't something I have heard in the wild.

Re: Microsoft's Linux Kernel

#384

Post by filmor »

paranoidrobot wrote: post #381
filmor wrote: post #332

Earlier quoted context omitted.

Version compatibility is not an issue for in-kernel drivers, only for the few remaining external ones. On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista, on Linux, once a driver is in the kernel it's continuously adjusted to driver API changes and will keep working. You can still run a current kernel on a 386 if you want to. I…

> On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista, I think that's a bit of a difference though. Vista came out nearly ~13 years ago, and we're talking things breaking a year or less later. Heck, for more obscure drivers[1], it seems necessary to recompile for every kernel patch. Perhaps that's the fault of that driver's deve…

> > On Windows you have this issue much more often if you are trying to use an older device, in particular if it's one that came out before Vista,

> I think that's a bit of a difference though. Vista came out nearly ~13 years ago, and we're talking things breaking a year or less later.

I'm not. I'm talking about the fact that drivers for devices older than me that have been merged into the kernel keep on working today while on Windows for some subsystems (like graphics or sound) you can't expect things to work after "just" 15 years. I admit that this is a long time, it's still a huge difference.

And yes, on Linux you are expected to recompile drivers for every new kernel version, that's intentional (https://github.com/torvalds/linux/blob/master/Documentation/...). Since the driver API is reasonably stable, the code doesn't need to be adjusted for every version, and if the driver has landed in the kernel, this is done while changing the API.

Re: Microsoft's Linux Kernel

#385

Post by ndarwincorn »

dingu wrote: post #250
ndarwincorn wrote: post #173

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…

> YMMV, but as far as I know that's more or less a solved problem by default (for X anyway) with DRI3. https://wiki.archlinux.org/index.php/NVIDIA_Optimus LOL. What a bunch of crap.

If you're gonna reference the wiki, cite the right article[1].

Under the 'GPU Offloading' heading (the feature most folks want in dual discrete/integrated laptops):

> Note: This setting is no longer necessary when using the default intel/modesetting driver from the official repos, as they have DRI3 enabled by default and will therefore automatically make these assignments. Explicitly setting them again does no harm, though.

I had to do nothing out of the box to have a working PRIME setup on my work laptop over a year ago, and I'd never used a laptop with discrete graphics prior. My only driver issue was with DisplayLink (proprietary), where I had to pin xorg because it wasn't compatible with 1.19.

[1] https://wiki.archlinux.org/index.php/PRIME

Re: Microsoft's Linux Kernel

#386

Post by ndarwincorn »

jeremyjh wrote: post #188
ndarwincorn wrote: post #173

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…

The last time I was shopping for a laptop (a year ago), Arch's wiki said it was all broken for the models that interested me. Here's an example, if you have better information maybe update the wiki. https://wiki.archlinux.org/index.php/Dell_XPS_15_9570#Graphi...

I'm not updating the wiki for a device I don't own, or plan on owning.

Especially when the relevant part of the wiki is correct.[1]

[1]https://wiki.archlinux.org/index.php/PRIME#PRIME_GPU_offload...

Re: Microsoft's Linux Kernel

#387

Post by ndarwincorn »

Osiris wrote: post #241
ndarwincorn wrote: post #173

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 spent a lot of time trying to get dynamic switching working and after countless hours I gave up. Optimus is definitely not a "solved problem", unless you know some method I didn't find in my dozens of hours of googling how to get it to work on a system76 laptop (Linux preinstalled) and a 2012 MacBook.

The "solved problem" is using the kernel implementation of muxless hybrid graphics (PRIME), not Nvidia's proprietary one (Optimus).

Re: Microsoft's Linux Kernel

#388

Post by brighter2morrow »

TeMPOraL wrote: post #311
Keyframe wrote: post #303

Earlier quoted context omitted.

Oh well, if YOU spend 80% of your workday on a PC then it must be true for everyone.

So does every office worker.

Most office workers could get away with a Chromebook, I'm surprised this hasn't caught on in offices yet.

Re: Microsoft's Linux Kernel

#389

Post by TeMPOraL »

brighter2morrow wrote: post #388
TeMPOraL wrote: post #311

Earlier quoted context omitted.

So does every office worker.

Most office workers could get away with a Chromebook, I'm surprised this hasn't caught on in offices yet.

Might be different in the US given popularity of Apple software, but in the rest of the world, Microsoft Office suite is a fundamental tool in almost every office. I don't think it'll run on a Chromebook.

(And I mean the desktop version. O365 is dumbed down half-way to Google's Office Suite level - which is cool for an occasional document or spreadsheet, but is lacking both features and efficiency for professional use.)

Re: Microsoft's Linux Kernel

#390

Post by pjmlp »

scarface74 wrote: post #380
pjmlp wrote: post #275

Earlier quoted context omitted.

iOS doesn't use Linux and on Android userspace doesn't actually see it. https://developer.android.com/ndk/guides/stable_apis So it is meaningless.

True for iOS that it isn’t based on Linux. But iOS is based on MacOS and MacOS is real certified Unix.

None of them have anything to do with Linux, given that I was replying about "Linux desktop" here.

Second, iOS being based on UNIX hardly matters, no one is doing shell scripts and writing UNIX daemons on it.

Thirdly, no one was talking about macOS on that comment,.

Finally, even if you want to bring macOS into the picture, while macOS is a proper UNIX, what matters for Apple community developers lives in C++, Objective-C and Swift libraries, hardly POSIX related.

Post reply on HN