3 ms·

TL;DR: I don't get it. Why bother with Windows at all if you are not going to use it anyway? Ninja-addition: but don't get me wrong, the writeup is quite nice

TL;DR: I don't get it. Why bother with Windows at all if you are not going to use it anyway? Ninja-addition: but don't get me wrong, the writeup is quite nice anyway! And if you are in a mixed environment where you need to run MSBuild locally for win32 apps and do a small amount of local-linux it might make sense. <slight-rant> Windows isn't a nice self-hosting toolbox OS with *nix semantics and probably never will be, no matter how much emulation or subsystem layers are added. In a way, macOS is moving a bit in that direction as well, but without killing the foundation it is built upon. Perhaps, if at some point either the NT kernel gets replaced (no, it's not a bad kernel, it's just a 'different' kernel with no compatibility towards BSD, Linux, Unix, Mach, L4, or any other open kernel) it will allow for a more toolbox/developer-centric environment. Now, while this argument might seem like the one about "I need things to be open source because I want to touch it" (which gets stale pretty quickly since 50% of the users never do this or probably don't even have the skills), it's not what I'm aiming for. It's more about the fact that you can interrogate, manipulate and visualise all levels of the system you are working on, in an identical way you can do on your target system. While most types of actions have comparable methods on Windows, there is nothing like a /sys /dev or /proc on Windows, you can't easily 'see' what you are doing, and that is a really problematic thing once you get past the entry-level web development. Most of the inspection and introspection on Windows comes in the form of closed source bulky IDE's that may or may not have that single feature you needed to figure out why your program has trouble reading some device node or why it's performance varies depending on connections, handles or other OS-dependant actions. At best, you can do some stuff with the sysinternals suite, but that doesn't even come close to basic tools like top,ps,lsof,sysctl,ldd,strace,gdb. The whole Windows ecosystem is so tightly bound to opaque systems that cannot be reached unless you dig around in some GUI, it makes it hard to do basic debugging. While it has gotten better over the years, we are still stuck with a ton of half-invisible things in ancient GUIs or MSC plugins that have an impact on your work but have nothing to do with your target system. Basically, you now have to maintain two systems of which one isn't really the one you wanted to work with in the first place. It's not that you can't do it, it's just that much harder to do on Windows. This is not unique to Windows, and applies to smaller scopes as well. If you build an application in an IDE and you want to automatically test and integrate it, but you didn't check how to build, link and package your product because the IDE did it for you, you suddenly can't reliably do what you needed to do, and you have to reverse-engineer the somewhat opaque process that the IDE did for you in the background and reproduce it using toolbox-tooling in order to automate it or deploy it on your target system. While not using that IDE isn't the super-solution either, purely depending on one blind/black-box integrated system is hardly the smartest choice out there. </slight-rant>

falcolas 9y ago
Not all companies allow OS choices. It's more common in B2B, where your clients have security requirements that are not as easily fulfilled with Linux.
- oneplane 9y ago
  Well, just because nobody did it and it was hard to get started with it doesn't mean it can't be done. On top of that, sec requirements are often missing the point entirely (i.e. "complex" passwords that rotate every 30 days -- people will just write them down and stick them on the monitor, on top of that, complexity requirements are 99% bs because they don't actually increase the entropy or security, both Troy Hunt and XKCD agree [it's on the internet so it must be true!]) Another thing is that this points to another issue; just because the "no"-department (old-style security / CISO) thinks something should be done in one way doesn't mean you just take it, if they have a wrong idea or if a policy doesn't do what it says it does, having a conversation might actually make things better. Same goes for taking on a job, if there are policies in place that prevent a good working environment, either the policies need to be updated or you might as well not take the job. (and yes, that is more often an option than you might think, at lest where I live -- I know that is purely anecdotal/N=1) Reasons not to change or not to make things better are easy to find, it's the solutions that are hard.
  - falcolas 9y ago
    I don't disagree with anything you said... yet I'm stuck on a non-Linux machine writing Linux code. I'm stuck changing my password on a yearly basis (it could be worse). I'm stuck with a "take control of your machine at any time" daemon constantly running in the background. Not because my own companies IT department is populated by sticks-in-the-mud, but because we work with the financial information of some of the largest companies out there. As such, what they say goes.

falcolas 9y ago

Not all companies allow OS choices. It's more common in B2B, where your clients have security requirements that are not as easily fulfilled with Linux.

oneplane 9y ago
Well, just because nobody did it and it was hard to get started with it doesn't mean it can't be done. On top of that, sec requirements are often missing the point entirely (i.e. "complex" passwords that rotate every 30 days -- people will just write them down and stick them on the monitor, on top of that, complexity requirements are 99% bs because they don't actually increase the entropy or security, both Troy Hunt and XKCD agree [it's on the internet so it must be true!]) Another thing is that this points to another issue; just because the "no"-department (old-style security / CISO) thinks something should be done in one way doesn't mean you just take it, if they have a wrong idea or if a policy doesn't do what it says it does, having a conversation might actually make things better. Same goes for taking on a job, if there are policies in place that prevent a good working environment, either the policies need to be updated or you might as well not take the job. (and yes, that is more often an option than you might think, at lest where I live -- I know that is purely anecdotal/N=1) Reasons not to change or not to make things better are easy to find, it's the solutions that are hard.
- falcolas 9y ago
  I don't disagree with anything you said... yet I'm stuck on a non-Linux machine writing Linux code. I'm stuck changing my password on a yearly basis (it could be worse). I'm stuck with a "take control of your machine at any time" daemon constantly running in the background. Not because my own companies IT department is populated by sticks-in-the-mud, but because we work with the financial information of some of the largest companies out there. As such, what they say goes.