You make it sound like Mozilla is pushing back for no reason. They have pretty valid security and privacy concerns.
4,280 karma · joined December 1, 2011
Precisely. As somebody with extensive experience porting cross-platform applications to run on Windows, it smells more to me like "everybody involved in this is actually quite ignorant about Windows," instead of (what I am assuming is the intended) "look at this crazy shit we had to do because Windows sucks."
Yup, you nailed it!
> To make a long story that I don’t fully understand short, you need to have buffers that are pinned in memory and aren’t touched as long as the operation is in progress.
I don't understand why this is so confusing.
> I doubt that Microsoft is really rushing to make it so that you can’t run Javascript on Windows anymore.
Nah, but don't be surprised if suddenly a bunch of apps receive compatibility shims.
Unfortunately for him, another email he sent out not five minutes before was proudly boasting about record profits.
(I remember that the best way to run the original release of Warcraft II was to set its shortcut to "DOS mode," where Windows would exit to DOS, run the game, and then restart Windows once the game exited)
The explosion of mobile.
False. You haven’t been paying attention.
iOS is not the entire ecosystem. Blink dominates everywhere else.
There were a few things going on with that issue you mentioned; one of them is the way the wrapper library was written, the other was with some stuff in the GUI client that was happening on a background goroutine but shouldn't have been. That should be fixed in the current stable release.
As for the Windows client in general, it is going to be receiving a lot of love over the next few months!
I was one of those cases. After years of repeatedly being told I was going to be sent to live at my mother’s house (not an appealing prospect at the time, I assure you), my father finally threw me out. Then he immediately started phoning anybody who would listen, crying to them that I “left him” just like my mother did.
https://dblohm7.ca/blog/2016/01/11/bugs-from-hell-injected-t...
https://dblohm7.ca/blog/2016/01/11/bugs-from-hell-injected-t...
One could just as easily argue similarly with respect to Unix and needing to loop over write watching for EINTR et al.
It's not a flaw at all, when you understand what is going on. Part of the issue is that in 2022 so many developers come from Linux backgrounds that they assume that the Linux way of doing things is the "normal" or "correct" way.
The NT kernel does not overcommit, and thus does not have an OOM killer. If the kernel cannot commit pages, the system call fails. That's it. No process terminations.
Firefox would crash because (even on Windows) it uses a customized version of jemalloc that is configured to be infallible by default. If jemalloc requests pages and those pages cannot be committed, the heap allocation will fail, and thus Firefox will self-terminate. That's simply a policy decision on Firefox's part.
Going back to Windows: suppose that the commit request failed because the swap file was full. Assuming that Windows was configured to automatically resize the swap file, the OS will then grow the swap file. That's why pausing for a bit and then retrying the VM allocation works: the swap file was grown, and now the pages can be committed.
> Maybe Mozilla didn't understand Windows's memory management strategy until now.
That is part of it. A lot of FLOSS engineers come from a Linux background and tend to assume that the Linux way of doing things is the "normal" way. While I was there I had to explain to more than one developer that Windows doesn't have an OOM killer because the NT kernel doesn't overcommit.
Most of the Tailscale client’s functionality is implemented as a daemon called tailscaled which is in the OSS repo.
It’s the GUI front ends for Windows, MacOS and iOS that are not.