6 ms·

That has nothing to do with Windows as an Operating System -- thats just part of the tooling that is included. Feel free to install additional tools into the PA

by stirno 13y ago

That has nothing to do with Windows as an Operating System -- thats just part of the tooling that is included. Feel free to install additional tools into the PATH on Windows and get the same capabilities. A lack of understanding of how to do something on a very different OS != you can't do it. I very much dislike PowerShell personally but its incredibly capable in modern versions of windows. We use it with Chef to automate our server configuration/setup.

deathanatos 13y ago
> as an Operating System -- thats just part of the tooling that is included An operating system includes the tooling that comes with it. This is what distinguishes Debian from other linux distributions: what tooling comes with it? It matters because it directly determines what you as a user can get done quickly, without needing to go through the trouble of installing additional functionality. (Or, as a developer, what you can do without needing to distribute or include additional functionality.) Windows is particularly bare in what it comes with: many tasks that I need to accomplish require additional tools. I often field questions of "how to do X on Windows?" that cause me to think, "well, this is a built-in command in Linux… in Windows, you could download X or Y, but they're not scriptable to what you want to do…" This is what drove me to Linux: The batteries are included. And they're scriptable.
- tracker1 13y ago
  I keep a utils directory added to my path, and generally have windows builds of all my common unix tools there. Easy peasy.
edwinnathaniel 13y ago
On ubuntu: sudo apt-get install [x] How would you do that on Windows? Does it require you to open a browser and download the software? Does it require you to FTP to a server to grab the file? Does it require the server to fetch it via network file system and launch the installer UI? Do you have to add the tool to "PATH" on windows? (unless the installer does it for you... which is variably on Windows platform). The culture of Windows platform unfortunately dictates you how to use Windows as an OS. Now let's go to Development Code type of dependencies (we're talking about libraries and stuffs here). NuGet has reached the "accepted" level of dependency management _recently_ (for a while in the past, it couldn't download the Source Code as well. Maven, RubyGems, and others can) while other platforms have dependency management for years _and_ integrated to developer daily workflow. What about scripting the build for .NET type of development? I don't know the exact number but I still see people not using MSBuild (or even know what it is) or NAnt. Most Java IDEs would generate build.xml for your project and would provide you hints that you should be using that instead of "Build Project" (or perhaps the "Build Project" is tied to Ant, by default). Besides, both MSBuild and NAnt are painful compare to Maven, lots of boilerplate stuff to setup. What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else. I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server! Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy. I think the pattern is rather quite obvious: Microsoft/.NET community has always been behind everybody else. At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist.
- stirno 13y ago
  You've move the goalposts a bit here, but for the sake of discussion... On windows we have Chocolatey available to help with application-level package management, granted you need to install it first but I would argue thats not much different than needing to add a PPA or new apt source before apt can install the right app/version you're looking for.. @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin ugly command, but it works. Then: cinst [x] It isn't perfect but its getting better. No UIs launched, all done via console. Handles adding items to the path, handles portable executables, etc. NuGet is great, apart from a few issues and has been in that state for quite some time. Not sure why we require things to be good for a decade before we're ready to talk kindly about them without the air quotes. There are a ton of tools for scripting .NET builds but the real trick is that most people don't need to do anything 'special'. msbuild Solution.sln or msbuild Project.csproj Your project files can include any number of pre/post build targets to handle any scenario you can imagine. Again, not perfect but manageable. If this isn't to your liking you can use all the build tools for other languages if you like.. Many people like Rake as a general purpose tool and others have done the work of providing msbuild integration there for you. Your .csproj file is built for you by Visual Studio (or by hand if you wish) and from there you can add much of what you need for your builds. I have worked on several very very large codebases for enterprise projects and there has never been any serious amount of 'boilerplate' to setup for builds. What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else. For CI, you can use TFS if you wish (really, really easy to do but somewhat limited in its ease of customization), or Jenkins, TeamCity, CC, Bamboo, whatever.. Its the same for any language. Pick a CI tool, install it, use it. Hardly a weakness of one platform over another. As far as deployment, that depends on the type of application you're building. Could be as easy as a git push that deploys to Azure/AppHarbor or it could by a PowerShell script or possibly a ClickOnce deployment. Any one of these can be triggered from the VS IDE. I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server! Certainly this must be the norm then. Capability to deploy from the IDE is great for testing but the same things are available for scripting to put in a real deployment process. Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy. Yes, containers are great. Windows doesn't have them in the sense that Linux does with LXC. Vagrant can and does work well on Windows. The licensing situation isn't as you think though for most .NET devs - they are likely working with MSDN provided software which provides licenses. As for scripting installs, again - chocolatey. Vagrant + chef is a win on any platform. I do wish it worked with Hyper-V client services properly though. At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist. At the end of the day: people believe what they want to believe. Windows as a platform is incredibly capable. Its not perfect and it can't compete on every level but it is getting better constantly. I work with Windows daily - using .NET, Node.js, Ruby, Python and more. I also work with Linux daily doing the same things. The biggest issues I encounter have more to do with package developers using non-portable code than anything.

by stirno 13y ago

deathanatos 13y ago

> as an Operating System -- thats just part of the tooling that is included An operating system includes the tooling that comes with it. This is what distinguishes Debian from other linux distributions: what tooling comes with it? It matters because it directly determines what you as a user can get done quickly, without needing to go through the trouble of installing additional functionality. (Or, as a developer, what you can do without needing to distribute or include additional functionality.) Windows is particularly bare in what it comes with: many tasks that I need to accomplish require additional tools. I often field questions of "how to do X on Windows?" that cause me to think, "well, this is a built-in command in Linux… in Windows, you could download X or Y, but they're not scriptable to what you want to do…" This is what drove me to Linux: The batteries are included. And they're scriptable.

tracker1 13y ago
I keep a utils directory added to my path, and generally have windows builds of all my common unix tools there. Easy peasy.

edwinnathaniel 13y ago

On ubuntu: sudo apt-get install [x] How would you do that on Windows? Does it require you to open a browser and download the software? Does it require you to FTP to a server to grab the file? Does it require the server to fetch it via network file system and launch the installer UI? Do you have to add the tool to "PATH" on windows? (unless the installer does it for you... which is variably on Windows platform). The culture of Windows platform unfortunately dictates you how to use Windows as an OS. Now let's go to Development Code type of dependencies (we're talking about libraries and stuffs here). NuGet has reached the "accepted" level of dependency management _recently_ (for a while in the past, it couldn't download the Source Code as well. Maven, RubyGems, and others can) while other platforms have dependency management for years _and_ integrated to developer daily workflow. What about scripting the build for .NET type of development? I don't know the exact number but I still see people not using MSBuild (or even know what it is) or NAnt. Most Java IDEs would generate build.xml for your project and would provide you hints that you should be using that instead of "Build Project" (or perhaps the "Build Project" is tied to Ant, by default). Besides, both MSBuild and NAnt are painful compare to Maven, lots of boilerplate stuff to setup. What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else. I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server! Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy. I think the pattern is rather quite obvious: Microsoft/.NET community has always been behind everybody else. At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist.

stirno 13y ago
You've move the goalposts a bit here, but for the sake of discussion... On windows we have Chocolatey available to help with application-level package management, granted you need to install it first but I would argue thats not much different than needing to add a PPA or new apt source before apt can install the right app/version you're looking for.. @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin ugly command, but it works. Then: cinst [x] It isn't perfect but its getting better. No UIs launched, all done via console. Handles adding items to the path, handles portable executables, etc. NuGet is great, apart from a few issues and has been in that state for quite some time. Not sure why we require things to be good for a decade before we're ready to talk kindly about them without the air quotes. There are a ton of tools for scripting .NET builds but the real trick is that most people don't need to do anything 'special'. msbuild Solution.sln or msbuild Project.csproj Your project files can include any number of pre/post build targets to handle any scenario you can imagine. Again, not perfect but manageable. If this isn't to your liking you can use all the build tools for other languages if you like.. Many people like Rake as a general purpose tool and others have done the work of providing msbuild integration there for you. Your .csproj file is built for you by Visual Studio (or by hand if you wish) and from there you can add much of what you need for your builds. I have worked on several very very large codebases for enterprise projects and there has never been any serious amount of 'boilerplate' to setup for builds. What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else. For CI, you can use TFS if you wish (really, really easy to do but somewhat limited in its ease of customization), or Jenkins, TeamCity, CC, Bamboo, whatever.. Its the same for any language. Pick a CI tool, install it, use it. Hardly a weakness of one platform over another. As far as deployment, that depends on the type of application you're building. Could be as easy as a git push that deploys to Azure/AppHarbor or it could by a PowerShell script or possibly a ClickOnce deployment. Any one of these can be triggered from the VS IDE. I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server! Certainly this must be the norm then. Capability to deploy from the IDE is great for testing but the same things are available for scripting to put in a real deployment process. Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy. Yes, containers are great. Windows doesn't have them in the sense that Linux does with LXC. Vagrant can and does work well on Windows. The licensing situation isn't as you think though for most .NET devs - they are likely working with MSDN provided software which provides licenses. As for scripting installs, again - chocolatey. Vagrant + chef is a win on any platform. I do wish it worked with Hyper-V client services properly though. At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist. At the end of the day: people believe what they want to believe. Windows as a platform is incredibly capable. Its not perfect and it can't compete on every level but it is getting better constantly. I work with Windows daily - using .NET, Node.js, Ruby, Python and more. I also work with Linux daily doing the same things. The biggest issues I encounter have more to do with package developers using non-portable code than anything.