4 ms·

There are frustrations on Linux, but there's also a lot of development where its Windows or macOS that gives "death by a thousand cuts" so there are definitely

There are frustrations on Linux, but there's also a lot of development where its Windows or macOS that gives "death by a thousand cuts" so there are definitely reasons for you to pick that over Windows or macOS - even with WSL2. Having to forward hardware over HyperV can give a lot of headaches. Windows machines infected by corporate also have crippling I/O speeds. I have a fun example at a customer where even running a Linux VM on the same machine will give 10x compile speed, and something like 100x git operation speeds than the same operations on the host... If you need it in a corporate setting, Lenovo ships both Fedora and Ubuntu on their thinkpads, with certified hardware support. Someone running Gentoo or Arch Linux are sure to burn many hours on the machine itself which they may or may not enjoy, but you don't have to go that route. It's not too hard to be on well-supported hardware either - people pick from a handful of laptops to run macOS, so it doesn't seem to unreasonable to also pick the machine for Linux. Think of it as being somewhere in between macOS "runs here only" and Windows "well it came with it" when it comes to having to select your machine.

int_19h 2y ago
These days, Windows is trying to solve the dev I/O scenario by having a separate "developer optimized" partition: https://learn.microsoft.com/en-us/windows/dev-drive/ https://learn.microsoft.com/en-us/windows/dev-drive/
- arghwhat 2y ago
  Thanks for the link. What an amusing band-aid. It's weird that they're mixing ReFS into it, as NTFS is not at all the problem. It feels like they're either using this as a random opportunity to air ReFS again, or as a decoy to make it sound like the dev partition is a fancy special filesystem optimization, rather than the more likely reality of it being duct tape on their weird VFS layer, likely doing away with stuff like in-line Windows Defender I/O interception as all the usage warnings and corp group policy references would suggest to be the case...
  - sedatk 2y ago
    What’s weird about Microsoft’s VFS layer?
    - arghwhat 2y ago
      The primary peculiarity and cause of issues is the Microsoft "filter driver" concept that allows I/O to be intercepted for a variety of purposes. A primary use-case for this is Just-in-Time anti-virus scanning, both for Windows Defender and third party products, which makes tasks that involve many small I/O operations (like compiling sources, using git, dealing with training sets or unzipping something with many files) very slow.
  - WorldMaker 2y ago
    Yes, the major benefit of Dev Drive is that the default filter driver stack is minimized from OS drive defaults, including Defender's and other AV's realtime drivers. NTFS itself wasn't the problem. Microsoft seems to acknowledge that the filter drivers in the wild are a part of the problem, and a partition opt-out is useful. (Of course all those warnings about corp group policy also point out that Enterprises are given the ability with group policy to force turn on a lot of those filter drivers for Dev Drive partitions, because Microsoft loves giving Corporations ways to shoot their own feet in Group Policy. What would Group Policy even be if it wasn't just Footgun as a Service?) It does seem like this is some sort of "trojan horse" (but not in a bad way) play for ReFS. But I'm not sure it is for sinister reasons: Encouraging Developers to use ReFS for their main development partition is a good way to encourage lots of free app compatibility testing on top of ReFS and suss out the minor bugs in applications that assume all Windows runs solely on NTFS. It seems like a play to increase reliance on the VFS layer and its abstractions and further get away from code assuming NTFS specifics.

int_19h 2y ago

These days, Windows is trying to solve the dev I/O scenario by having a separate "developer optimized" partition: https://learn.microsoft.com/en-us/windows/dev-drive/ https://learn.microsoft.com/en-us/windows/dev-drive/

arghwhat 2y ago
Thanks for the link. What an amusing band-aid. It's weird that they're mixing ReFS into it, as NTFS is not at all the problem. It feels like they're either using this as a random opportunity to air ReFS again, or as a decoy to make it sound like the dev partition is a fancy special filesystem optimization, rather than the more likely reality of it being duct tape on their weird VFS layer, likely doing away with stuff like in-line Windows Defender I/O interception as all the usage warnings and corp group policy references would suggest to be the case...
- sedatk 2y ago
  What’s weird about Microsoft’s VFS layer?
  - arghwhat 2y ago
    The primary peculiarity and cause of issues is the Microsoft "filter driver" concept that allows I/O to be intercepted for a variety of purposes. A primary use-case for this is Just-in-Time anti-virus scanning, both for Windows Defender and third party products, which makes tasks that involve many small I/O operations (like compiling sources, using git, dealing with training sets or unzipping something with many files) very slow.
- WorldMaker 2y ago
  Yes, the major benefit of Dev Drive is that the default filter driver stack is minimized from OS drive defaults, including Defender's and other AV's realtime drivers. NTFS itself wasn't the problem. Microsoft seems to acknowledge that the filter drivers in the wild are a part of the problem, and a partition opt-out is useful. (Of course all those warnings about corp group policy also point out that Enterprises are given the ability with group policy to force turn on a lot of those filter drivers for Dev Drive partitions, because Microsoft loves giving Corporations ways to shoot their own feet in Group Policy. What would Group Policy even be if it wasn't just Footgun as a Service?) It does seem like this is some sort of "trojan horse" (but not in a bad way) play for ReFS. But I'm not sure it is for sinister reasons: Encouraging Developers to use ReFS for their main development partition is a good way to encourage lots of free app compatibility testing on top of ReFS and suss out the minor bugs in applications that assume all Windows runs solely on NTFS. It seems like a play to increase reliance on the VFS layer and its abstractions and further get away from code assuming NTFS specifics.