3 ms·

Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex sys

by NavinF 4y ago

Indeed it is better for many use cases, but they seemed to have stopped taking feature requests for WSL1 a couple of years ago when I asked for the adjtimex syscall to set system time: https://github.com/microsoft/WSL/issues/6310 https://github.com/microsoft/WSL/issues/6310 > I presume this is wontfix for WSL1? > Yes WSL2 won't help your use-case presently. A feature requestion along the lines of "hardware clock passthrough" could be submitted under a different cover. It’s likely the feature freeze started even earlier and I just never noticed. Also see WSLg (GUI), which only works on WSL 2. I think it’s clear that WSL1 is in maintenance mode.

Dylan16807 4y ago
I more or less give WSLg a pass because it's very complex and inherently requires WSL2 to run the internals. It would be nice if you could connect WSL1 programs to it at some point, but they only just got it working at all. For other issues, well, I'm willing to believe it either way, but I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2.
- NavinF 4y ago
  > they only just got it working at all WSLg was launched over a year ago > I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2 They made it clear that this syscall will not be implemented at all in WSL1. With WSL2 on the other hand, they are willing. That’s what a feature freeze looks like.
  - Dylan16807 4y ago
    Saying to make a new ticket isn't exactly saying they're willing, though. The "fixed in wsl2" tag would be more damning but it's not on many newer issues and looking at a few it didn't seem like it was generally used as a resolution, I think? I found one issue directly saying they weren't dismissing it because they're done with WSL1 but because it's a minor TCP difference that the code should be less fragile about.

by NavinF 4y ago

Dylan16807 4y ago

I more or less give WSLg a pass because it's very complex and inherently requires WSL2 to run the internals. It would be nice if you could connect WSL1 programs to it at some point, but they only just got it working at all. For other issues, well, I'm willing to believe it either way, but I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2.

NavinF 4y ago
> they only just got it working at all WSLg was launched over a year ago > I think the last couple comments on your example link make it clear that this feature doesn't really exist on WSL1 or WSL2 They made it clear that this syscall will not be implemented at all in WSL1. With WSL2 on the other hand, they are willing. That’s what a feature freeze looks like.
- Dylan16807 4y ago
  Saying to make a new ticket isn't exactly saying they're willing, though. The "fixed in wsl2" tag would be more damning but it's not on many newer issues and looking at a few it didn't seem like it was generally used as a resolution, I think? I found one issue directly saying they weren't dismissing it because they're done with WSL1 but because it's a minor TCP difference that the code should be less fragile about.