5 ms·

All excellent points but Windows is a very widely used platform (perhaps the most widely used, by some metrics) and it’s actually quite nice for development. It

by trzy 4y ago

All excellent points but Windows is a very widely used platform (perhaps the most widely used, by some metrics) and it’s actually quite nice for development. It’s hard to take tools seriously that don’t work on it. Unpopular opinion but I think the Unix approach of lots of little tools with arcane configuration files all blaming each other sucks. I get why it exists, why it became popular, and why it remains popular in some scenarios, but I don’t feel beholden to it.

yamtaddle 4y ago
Right—in some sense it's not really Windows' fault that something like Git is barely-portable and relies on a rube-goldberg-machine pile of scripts and binaries in several languages with the result that it has to ship half a unix environment to work somewhere that's very non-unix, or that open-source software in general treats Windows the way web developers treat Firefox. OTOH, in practice, if you're using a lot of open source tools and have developers working on every single halfway-plausible OS except windows, things are probably pretty OK, but then you throw Windows in the mix and suddenly the time you spend supporting your builds & tools shoots way up. That makes it feel like it's Windows' fault.
- cma 4y ago
  Android is an even bigger pain, suddenly you have to call Java code just to map memory and can't even have a simple C api for something as low level as that.
  - yamtaddle 4y ago
    As a development and/or build environment? Never used it that way, myself. Agree that as a build target, and as far as its various first-party developer-facing features and libraries and SDKs and such go, it's got weirdly-many rough edges and half-baked-but-heavily-promoted junk for such a major platform.
- hactually 4y ago
  Git is written in C. It hasn't been a "rube-goldberg-machine pile of scripts and binaries in several languages" for a long time (almost a decade).
  - howinteresting 4y ago
    Has git rebase --interactive been rewritten in C yet or is it still a bunch of Perl?
    - yrro 4y ago
      $ file -L /usr/lib/git-core/git-rebase /usr/lib/git-core/git-rebase: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=95d963a593ffeeb306e8525aacce02f1cbc7dabd, for GNU/Linux 3.2.0, stripped
      - howinteresting 4y ago
        I specifically said git rebase --interactive. I know the non-interactive rebase is in C.
  - MarkSweep 4y ago
    While there are fewer Perl and shell commands than in the past, several remain. Scroll down to git-add—-interactive.perl to see: https://github.com/git/git/tree/master https://github.com/git/git/tree/master
  - yamtaddle 4y ago
    My install directories sure look like it's still that way. And I'm not using a decade-old git. I discovered this fact about git far more recently than a decade ago, in fact (though I was using it back then).
- bsder 4y ago
  Mercurial worked very nicely on Windows for a lot of years that Git didn't. It was a complete waste of Mercurial developer's time that would have been better spent creating a GitHub equivalent. If it doesn't come from Microsoft, Windows developers don't care. Learn that lesson or repeat the mistake.
moonchrome 4y ago
>and it’s actually quite nice for development If we are talking about stuff like backend web development then I'd say no, it's actually a pain to work with - few people bother deploying to Windows these days, many libraries/frameworks treat it like a second class citizen, tooling doesn't translate well (or at all). Even frontend webdev is very unixy due to node/npm and popularity of Macs in that space. When you're talking about OpenCV, GPU related things, game dev then the situation is reversed. So it highly depends on what you're developing.
- vbezhenar 4y ago
  I think we each live in our own bubbles. I see very few people on macs or linuxes, almost everyone uses Windows and they're fine with web development. What's so unixy about node/npm? They feel like very good windows citizens.
  - Cu3PO42 4y ago
    For the most part npm has worked for me on Windows, but it's so incredibly slow compared to even npm in a Linux VM on the same host. I understand this is mostly due to FS overhead related to a multitude of small files. Obviously this isn't a deal breaker in most situations, but it is a bit annoying. I've observed similar performance problems running Webpack on Windows in the past.
    - j16sdiz 4y ago
      > I understand this is mostly due to FS overhead related to a multitude of small files. No. It was the VFS design. They have lots hooks and extension points for 3rd party, there is no way to improve without breaking backward compatibility. It was the reason why many antivirus was broken in the first few releases of windows 10.
    - easton 4y ago
      There’s a possibility this is due to corporate antivirus. Many AV solutions (seemingly not Windows Defender) scan every file that’s written, massively slowing down IO, but they can’t scan VHDs. Excluding the folder where node_modules is or running npm inside WSL2 has good performance on my work laptop, in a random windows folder not so much.
hot_gril 4y ago
> It’s hard to take tools seriously that don’t work on it. In my experience, most software development tools don't work on it, at least not as well as on Unix-like systems. But I'm not a game dev.
ok123456 4y ago
Visual Studio has pretty good native support for CMake. Going from Make to CMake would have been a better decision than trying to use Bazel. There's a standard find_package/find_library macro and definitions for OpenCV (which is your use case here). Then use either Microsoft's C++ package manger or Conan to actually install the libraries.
Gibbon1 4y ago
I had a recent issue on windows with build times increasing 10X, turned out the Unix approach of spawning lots of processes was triggering the corporate antivirus. Didn't cause the build to fail but the result was the antivirus was scanning everything the process touched or wrote to disk. And make + gcc opens and closes a huge number of files.

by trzy 4y ago

yamtaddle 4y ago

Right—in some sense it's not really Windows' fault that something like Git is barely-portable and relies on a rube-goldberg-machine pile of scripts and binaries in several languages with the result that it has to ship half a unix environment to work somewhere that's very non-unix, or that open-source software in general treats Windows the way web developers treat Firefox. OTOH, in practice, if you're using a lot of open source tools and have developers working on every single halfway-plausible OS except windows, things are probably pretty OK, but then you throw Windows in the mix and suddenly the time you spend supporting your builds & tools shoots way up. That makes it feel like it's Windows' fault.

cma 4y ago
Android is an even bigger pain, suddenly you have to call Java code just to map memory and can't even have a simple C api for something as low level as that.
- yamtaddle 4y ago
  As a development and/or build environment? Never used it that way, myself. Agree that as a build target, and as far as its various first-party developer-facing features and libraries and SDKs and such go, it's got weirdly-many rough edges and half-baked-but-heavily-promoted junk for such a major platform.
hactually 4y ago
Git is written in C. It hasn't been a "rube-goldberg-machine pile of scripts and binaries in several languages" for a long time (almost a decade).
- howinteresting 4y ago
  Has git rebase --interactive been rewritten in C yet or is it still a bunch of Perl?
  - yrro 4y ago
    $ file -L /usr/lib/git-core/git-rebase /usr/lib/git-core/git-rebase: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=95d963a593ffeeb306e8525aacce02f1cbc7dabd, for GNU/Linux 3.2.0, stripped
    - howinteresting 4y ago
      I specifically said git rebase --interactive. I know the non-interactive rebase is in C.
- MarkSweep 4y ago
  While there are fewer Perl and shell commands than in the past, several remain. Scroll down to git-add—-interactive.perl to see: https://github.com/git/git/tree/master https://github.com/git/git/tree/master
- yamtaddle 4y ago
  My install directories sure look like it's still that way. And I'm not using a decade-old git. I discovered this fact about git far more recently than a decade ago, in fact (though I was using it back then).
bsder 4y ago
Mercurial worked very nicely on Windows for a lot of years that Git didn't. It was a complete waste of Mercurial developer's time that would have been better spent creating a GitHub equivalent. If it doesn't come from Microsoft, Windows developers don't care. Learn that lesson or repeat the mistake.

moonchrome 4y ago

>and it’s actually quite nice for development If we are talking about stuff like backend web development then I'd say no, it's actually a pain to work with - few people bother deploying to Windows these days, many libraries/frameworks treat it like a second class citizen, tooling doesn't translate well (or at all). Even frontend webdev is very unixy due to node/npm and popularity of Macs in that space. When you're talking about OpenCV, GPU related things, game dev then the situation is reversed. So it highly depends on what you're developing.

vbezhenar 4y ago
I think we each live in our own bubbles. I see very few people on macs or linuxes, almost everyone uses Windows and they're fine with web development. What's so unixy about node/npm? They feel like very good windows citizens.
- Cu3PO42 4y ago
  For the most part npm has worked for me on Windows, but it's so incredibly slow compared to even npm in a Linux VM on the same host. I understand this is mostly due to FS overhead related to a multitude of small files. Obviously this isn't a deal breaker in most situations, but it is a bit annoying. I've observed similar performance problems running Webpack on Windows in the past.
  - j16sdiz 4y ago
    > I understand this is mostly due to FS overhead related to a multitude of small files. No. It was the VFS design. They have lots hooks and extension points for 3rd party, there is no way to improve without breaking backward compatibility. It was the reason why many antivirus was broken in the first few releases of windows 10.
  - easton 4y ago
    There’s a possibility this is due to corporate antivirus. Many AV solutions (seemingly not Windows Defender) scan every file that’s written, massively slowing down IO, but they can’t scan VHDs. Excluding the folder where node_modules is or running npm inside WSL2 has good performance on my work laptop, in a random windows folder not so much.

hot_gril 4y ago

> It’s hard to take tools seriously that don’t work on it. In my experience, most software development tools don't work on it, at least not as well as on Unix-like systems. But I'm not a game dev.

ok123456 4y ago

Visual Studio has pretty good native support for CMake. Going from Make to CMake would have been a better decision than trying to use Bazel. There's a standard find_package/find_library macro and definitions for OpenCV (which is your use case here). Then use either Microsoft's C++ package manger or Conan to actually install the libraries.

Gibbon1 4y ago

I had a recent issue on windows with build times increasing 10X, turned out the Unix approach of spawning lots of processes was triggering the corporate antivirus. Didn't cause the build to fail but the result was the antivirus was scanning everything the process touched or wrote to disk. And make + gcc opens and closes a huge number of files.