Hacker News Reader

Comment by jmkni | Hacker News Reader

Another reason Windows Vista did so badly was that it really needed a clean install to make it work properly.

This is true of all Windows versions, but was particularly true of Vista, and of course the reality was:

* Very few people carry out a clean install when they get a new computer. This is as true today as it was ten years ago

* Hardware manufacturers loaded the PC's up with terribly written adware before shipping (this situation has improved slightly)

The requirements for Windows 10 aren't that much more than Vista, so, the average person would get their new Vista PC running on a Core 2 Duo/Pentium D and 1-4GB of DDR2 Ram, loaded up with crapware and not do a clean install, and it would run horribly.

By the time Windows 7 came out, the PC manufacturers where writing slightly more efficient crapware, hardware was generally a bit more powerful, and they had fixed a tonne of bugs in the OS itself.

View on HN

I can attest to the relatively low requirements of Windows 10. I'm running it on a circa 2008 Core 2 Duo with 4Gb of RAM. It's my Plex Server.

Windows... On a server? interesting

I am forced to host many of our services on Windows machines at work. I can attest there is nothing 'interesting' about it :)

It's not what GP was referring to, but... https://en.wikipedia.org/wiki/Windows_Server

Not what I was originally referring to, but yes at work our entire system is 30+ Windows Servers running C# programs and services using Consul, Nomad, Mongo, Sql Server, and Memcached.

Continuous integration and deployment is all done with Microsoft agents orchestrated by VSTS (Microsoft's hosted version of TFS). Yes we use git

Easy to maintain and no performance issues.

I wish more people in the bay area understood that Microsoft has a really awesome development and server ecosystem.

I came into a midsized company as the dev lead with no real development shop with free reign, a decent budget, and management support to build the department the way I saw fit. I had never used VSTS and had heard nothing but bad things about TFS. They already had it and I decided to play around with it. I was amazed how easy it was to create a CI/CD environment that followed generally accepted best dev ops practices.

Windows is the second most widely used server operating system in the world, second only to Linux. It's pervasive in companies outside of the tech industry, to give one example of typical usage.

Linux and Windows together dominate this market so thoroughly that everything else (UNIXes, BSDs, macOS) is practically a rounding error.

If you want to serve files to Windows machines and you don't mind the license and painful remote administration, it's a reasonable choice. Guaranteed SMB compatibility.

How is remote administration painful? All 30+ servers I run have VSTS agents. I can do most administration by running Powershell scripts and choosing the deployment groups based on the purpose of the server. I have Consul agents for health checks, Consul watches for alerting and/or automatic recovery, Nomad for running executables across the app servers, HashiUi for monitoring and controlling the Nomad pool.

I can approve and deploy a release from my iPad (the website is painful on my phone) by logging into Microsoft's Visual Studio Team Services website.

I won't even start to gush about how easy setting up a build and release pipeline is in VSTS compared to the other tools I've used.

It is painful in the mindset of typical unix guy who is used to being able to "just ssh somewhere and vi /etc/something", which is not the way you want to manage large deployments but works even for large-ish ones. On windows there is no real middle ground between use GUI for everything and automate everything.

Also with unix servers various bastion hosts and similar "security measures" are minor inconvenience and usually even supported by automation tools, while on windows this usually ends up being major PITA.

The biggest pain for Windows remote automation is security around accessing servers remotely, I'll grant you that. I gave up. That's why I have VSTS agents on every box. I can easily write a script and tell each agent to pull the script down and do X locally and insert the results if needed into a Mongo collection. But for the few times I do need to treat my servers like "pets" instead of "cattle". I do everything from the GUI.

There was a time when our net ops team did something and I couldn't Remote Desktop into a server to do something urgent and if course I couldn't just SSH into it where I had to write a quick Powershell script and deploy it via VSTS to make a change. It was ugly.

On the other hand the PITA-ness probably isn't that much caused by the OS itself but by it's historical security track record and mentality of ops and security teams that is caused by that.

Geez mate, just get PSRemoting setup (not hard) and use invoke-command and or enter-pssession...

We have three different different AD domains - one on prem (well at colo center) and two separate AWS environments. Getting them to be friendly with each other isn't possible. Since the local VSTS agents poll and only need outbound connections, I don't have to deal with firewall issues or domain issues. Also, I can run a script in parallel across as many agents as I want to. You can have as many concurrent agents running on a VSTS account as you have MSDN licenses.

Besides, I already have sane deployment groups and tags defined by server environment and function. I might as well leverage them.

It's been years since I last worked with Windows, but:

1) You can install an SSH server on Windows boxes just fine, then use Putty to SSH directly into PowerShell. PowerShell is not a classical shell, but rather a REPL for a procedural, imperative and object-oriented DSL for system configuration and administration based on .NET, with much saner syntax than my beloved zsh. In short, it works quite well.

2) With PowerShell capabilities - I'm a bit fuzzy on the details here, was a long time ago - you don't even need the SSH server, you can issue remote commands from your local PS instance. It required a bit of configuration up front, IIRC, but then you could replace your local session with a remote one with a single command.

So, in my experience - and note that it was probably nearly a decade ago! - Unix-style remote management was absolutely possible and not that much less convenient. And PowerShell is really a solid tool, with easy access to all of .NET and all of the system; the only annoyance I remember was certificate/signature management, dunno if it got any better.

The problem isn't a Powershell, remote administratoon is tightly tied into the Windows security framework which can really be a pain with tooling.

But part of the problem is I have a real prejudice toward local agent based solutions with a central server coordinating everything.

Tablet with Z8300 low end Intel CPU and 2 GB RAM. Originally ran Windows 10 fine.

MS updates have made it worse because they stopped caring about this segment. Same story with phones on Windows 10 mobile.

Reply on news.ycombinator.com