Hacker News new | ask | show | jobs
by irahul 5378 days ago
I have never used Windows servers, and I am curious how do you do things which are obvious on Linux on a windows server?

1. Can SQL server deployment be automated? I remember reading somewhere it is mostly GUI administration, though things might have changed with WMI.

2. How do you manage IIS? Say you need to restart IIS on 200+ servers?

3. What is the remote model? Windows doesn't have a decent command line, so ssh will be weird.

Do you write custom code for all this, because I find the ecosystem on Windows sorely lacking.

3 comments

Two words: Power Shell. Well, one word.

PS is a "decent command line" for Windows, that can handle most of the things you discuss pretty well.

Why should I learn a new toolchain when I already have one that's just as good but has been around for 30+ years? It's fun to reinvent the wheel, but as a user, sometimes enough is enough. Just give me bash and the coreutils, kthx.
You're completely killing innovation this way. Your bash and coreutils work on Windows, they're just not as useful in that environment. Would you also expect to have bash and coreutils on Lisp Machine?

Also if you don't know this anything about new toolchain, how can you say that your old one is "just as good"?

Caveat: I have been heavy Linux user for past 7 years, but I'm not so quick to dismiss alien technology, especially when it addresses obvious flaws in Unix -- e.g. piping plain text with parsing and printing it again on all stages seems so ancient, I would much rather like to be able to use structured data instead. Also, you could remove the overhead of process initialization if your command line tools are just functions, and not executables. Just sayin'.

PS is just a piece of the puzzle. In fact, if I were to automate things on Windows, I would pick perl/python/ruby(on linux, I use shell scripts only for jobs which are less than 50 lines).

The major question is does the objects which are to be automated lend themselves to automation?

Here is one of the results I found while looking for 'sql server automate'

http://msdn.microsoft.com/en-us/library/ms187061.aspx

If I were talking about MySQL/PostgreSQL, they lend themselves very well to automating. The shell script just calls the relevant programs.

Likewise, if I am automating nginx, shell is just the glue. nginx provides the nut and bolts, and scripting is the wrench.

Unless IIS, SQl server et al. provide similar facilities, powershell isn't going to help.

I haven't used SQL server in a long, long time. My doubts were from some articles I have read:

http://hal2020.com/2011/07/27/porting-microsoft-sql-server-t...

nix DBA’s used shell scripts as their primary management tool, but the SQL Server of that day was not scriptable. Would those DBA’s accept the use of GUI tools?

So it looks like it used to be the case that it wasn't scriptable, but it is now.

You can script and automate IIS and MSSQL using powershell. I'm willing to bet dollars against pesos that if MS hasn't made everything in Windows scriptable via Powershell, they are currently working towards it.

http://msdn.microsoft.com/en-us/library/hh245198(v=SQL.110)....

#3 is Remote Desktop, not sure on the other 2
I make it short: 1. Of course 2. You write a script. Or simply use something out of the Systems Management Product Family (awesome btw) 3. WMI or Powershell should do the job.

You rarely write custom code when scripting....most use cases a covered by a huge library MS offers. The rest is available through google :)

We have run large Windows Server Farms at my past company (SaaS Business) and maybe 3-4 Linux Servers...the ones causing the most trouble where the Linux ones. One reason: Every dummy can administrate a Windows machine....not so a Linux machine! That fact forced the Ops team to get rid of the Linux machines as quick as the could.

Every dummy can administrate a Windows machine....not so a Linux machine! That fact forced the Ops team to get rid of the Linux machines as quick as the could.

So you choose a inferior mediocre alternative just because you can hire mediocre folks to handle it(you mentioned 'dummy'). Ultimately having sufficient technical debt to make your miserable for the next decade.

Linux command line isn't very upfront friendly for sure, but its strength lies in automating as much as you can, programatically. When you talk of administration things go beyond cleaning up files and giving access to users. You must have abilities/tools to quickly hack up solutions to programming problems while problems in operations. That's why bash/sed/awk/perl and other Unix text processing utilities are so big on the server side. Unix forms a complete programming ecosystem in itself apart from being an OS.Windows command line is not just weak but literally useless in this area.

Its like saying just because anybody can use notepad, Emacs is useless.

Unfortunately, this is how business works. If they can hire an operations team full of Windows lusers and pay them $30K a year instead of Linux admins that cost $60K a year, they usually do that.

The thought never crosses their mind that you get what you pay for, and 1 qualified Linux admin can replace an entire team of Windows admins due to automation, scripting, and superior manageability of Linux.

Look at it this way: you should never trust a single guy to manage your entine system. You need to have backup in case of the flu, accidents, anything.
What do you think makes it inferior and mediocre?
Reasons: --------

1. Windows was never originally designed to work as a Server side operating system at the first place. They started to drive it on the server side when they first discovered the Internet had a huge commercial potential to sell machines on the backend. There fore all means of getting things done on a windows machine for a developer have to go somehow through a set GUI's to get work done programatically. This sucks from a programmers perspective, programming is all about level of customizability.

2. Command line on windows sucks, apart from just removing, adding files/directories and running commands anything else is just a pain. The UNIX command line is a complete interpreter in itself(bash).

3. The UNIX operating system is more than an OS, its a complete programming ecosystem in itself. The whole concept of everything being a file or a process is just so elegant. You can endlessly leverage native tools like sed/bash/awk/cut/tr/perl and other text processing utilities to solve any problem with a combination of text files and processes. Which is not easily possible with windows, heck using those tools on windows is big pain. They are often ported with limitations.

4. Debugging, is a breeze. Checking logs is a breeze. Text processing utilities and endlessly configurable tools make it very easy for system administration with the help of pipes. This is very crucial for system administrators. They often want to do stuff without the help of programmers to get quick solutions when they get paged at 2 in the night.

5. Many other development features like Inter process communication with tools like DBus. Sockets et al are vastly superior in UNIX than windows.

6. Many programming languages were developed(Perl/Ruby/C) with entire context of UNIX in mind. Therefore they natively work very well with UNIX.

7. Vast resources of knowledge of troubleshooting and maintenance available for UNIX. Which makes things newbies easier to deal with it.

8. Unix is open source, its freely available. And will be there for a long time. People who supply it do it on passion and pure volunteer effort and will do it for fun and because they like. Windows can be killed by anytime for profit.

9. Vendor lock in problems. I don't understand why I should use all MS specific software all over. I can't scale horizontally due to cost issues. Also apart from .NET developing for any other technology sucks on windows.

10. Lack of multiuser login, Servers need many people to login and work at the same time. For testing and for development reasons.Servers are just so much more than deployment only boxes.

11. GUI overhead, Why should I spend my computing resources on OS and GUI when I should I actually be spending them on my applications?

12. Registry is a pain on Windows, I don't have to worry about those hassles on UNIX.

The list goes on and on...

Not to defend Windows here, because it certainly has its flaws, but you're so deluded it's not even funny any more. You seem to like 'openness' so much, but the concept of 'open mind' seems to be completely lost on you.

"There fore all means of getting things done on a windows machine for a developer have to go somehow through a set GUI's to get work done programatically."

This alone is enough to discard anything you say about this topic. You obviously have no idea what you're talking about. Everything in Windows is programmable, through a standard object model, and the facilities to put them into any program are standardized, too.

"Which is not easily possible with windows, heck using those tools on windows is big pain."

Windows != Unix. If you are a bricklayer and you get into gardening, would you complain that your concrete mixer doesn't work well for shoveling a garden? Unix tools on Windows is a crutch for people who refuse to adjust to the environment they're in (or as a band aid for a quick and dirty port of Unix functionality).

"tools like DBus. Sockets et al are vastly superior in UNIX than windows."

Windows != Unix. The concurrent tasks model in Windows is based on threads, not process spawning. Don't take your Unix prejudices to Windows when you write software for Windows. Are you seriously suggesting there are no working ipc mechanisms in Windows? There are vast amounts of functionality to do so, and on a much deeper level than just 'pipe text from one process to the next' (i.e., a proper object model that can be used to share code written in several languages and with which you can pass objects and not just text).

"Lack of multiuser login,"

WTF are you talking about? Have you ever seen a Windows box since Windows 95?

"Registry is a pain on Windows, I don't have to worry about those hassles on UNIX."

What? Are you saying you prefer 25 different file formats, spread out in non-standard ways, without a standardized layout? Or are you saying that editing Apache config files with sed and awk is a good idea? If so, you're clearly off your rockers. Of course you can hack together something that 'mostly works', but at least with the registry you have a standard format, standardized and cross-language APIs and a (more or less) standard organization of data.

Now I'm not defending the implementation of the registry; it has outlived its design. But being against the idea is lunacy - why do you think the Gnome guys realized in the early 2000's that they needed something similar?

Here's the thing about the registry: with a bunch of config files in /etc, I already have many, many tools for managing them because they're just text files like every other text file. With the Windows registry, if I want version control or something like that, I have to invent the tools myself. This is a waste of my time unless I am in the business of selling products for Windows.

UNIX is about being generic. Yes, it means Apache and Varnish have different config file formats. But it also means that I already have the tools I need to automate my configuration so I don't have to care.

(Yes, Windows is programmable. But when you start having to compile software to automate your deployment, it becomes engineering and becomes a task of its own. Compare this to a quick command-line oneliner, and you'll see why people prefer UNIX. Engineering is about knowing how much you need to get something accomplished. Sometimes you do need to write highly-advanced configuration software. But other times, you don't. Windows doesn't give you that choice.)

WTF are you talking about? Have you ever seen a Windows box since Windows 95?

Why is it so difficult for people to make a point without making personal remarks?

Foreword: I've been using various flavors of Linux for a good chunk of the last decade (since 2001) and totally ignored Windows until last year, so I am no Windows fanboy.

2. This may be true for the good old cmd.exe but.. have you tried PowerShell? I've been playing with PowerShell 2 on Windows 7 and found that it leaves little to be desired. It is self-documenting (a-la Emacs). It can be extended using .NET. You can pipe entire objects instead of unstructured text streams. Coming from a strong UNIX background I /am/ impressed and actually think it is way better than a POSIX-compatible shell. I even wrote a couple of scripts [1] to post-configure my Windows 7 installation in a similar way I do on Linux with Puppet [2].

7. This is true even for Windows, in my experience. Every time I do a Google search for troubleshooting I am directed to Microsoft's Knowledge Base or the (free) MSDN website.

11. AFAIK, you can uninstall the GUI component on Windows Server 2008 (you will be left with a heavily stripped down GUI, without the usual graphical shell)

12. It may be a pain but at least it is a consistent way to store configuration settings and it is widely adopted as such. Compare it with the plethora of different configuration file formats used on a typical Linux/Unix workstation (Mac OS X being the exception since they seem to consistently use XML-based property lists almost everywhere). Each system has its strengths and weaknesses but I wouldn't call the Windows Registry "a mess".

I don't comment on your other points either because I don't have enough first-hand experience with it (1, 4, 5, 9, 10) or because I partially agree with you (3, 6, 8).

Anyway, it seems that you're a coming from a strong UNIX mindset and that you try to forcefully shoehorn it to Windows (3rd and 4th points), along with (my guess) lack of experience in certain areas of Windows administration (2nd point).

As for me: I was really impressed by Windows 7. Some things I really miss are a decent Window Manager (but this is true of every commercial OS I've ever tried) and a good software management solution (either a decent, standardized, package manager, an AppDir mechanism like OS X or both).

_____

  [1]: https://github.com/lvillani/powershell-2
  [2]: http://puppetlabs.com/
> I've been using various flavors of Linux for a good chunk of the last decade (since 2001) and totally ignored Windows until last year, so I am no Windows fanboy.

You know there is a fallacy there, don't you? It's perfectly possible to ignore something for decades and still fall in love with it later. I've seen lots of Windows and Linux fanboys fall for OSX and become very annoying in the process.

I can believe you are no Windows fanboy without you presenting credentials.

it seems that you're a coming from a strong UNIX mindset and that you try to forcefully shoehorn it to Windows

I come from backend server based mindset and find it difficult to shoehorn the concepts there to a desktop operating system. For no justifiable reason. I still see no reason why I must use Windows on my backend.

I fail to see the need to endlessly shoehorn Windows for all my backend tasks(powershell included) when I can get everything of that in a Vanilla linux installation.

If you say Windows is good desktop operating system, you are correct in your own right. But literally there is no comparison between the UNIX and Windows on the server end.

On the similar lines, there are many things in Windows (like directory share on network, printer settings) which are far more easier to use than on Linux.

> 1. Windows was never originally designed to work as a Server side operating system at the first place.

That's not exactly correct. Windows NT was designed to compete against Unix in the desktop workstation and non-dedicated server market. It was designed by a team formed mostly by DEC alumni. I call it "the bastard child of VMS" for a reason.

> 8. Unix is open source, its freely available.

Linux and BSD are, but OSX and Solaris are only partially open source and AIX and HP-UX are very proprietary.

> 10. Lack of multiuser login,

I believe Windows servers can currently host more than one user session. I used this with NT TSE and I don't think this feature was removed since the late 90's (when I used it). It may be some idiotic license restriction.

> 11. GUI overhead

Windows' GUI is rather primitive. I can't imagine the resources it consumes are relevant these days. I have seen more sophisticated stuff on Symbian phones.

> I believe Windows servers can currently host more than one user session.

Yes. Windows XP and Server 2003 Standard allow one local login plus two Terminal Server (remote desktop) sessions. Windows Server 2003 Enterprise and Datacenter Editions allow more (but nobody ever bought those flavors because Standard was so much cheaper.) I'm not familiar with Windows 2008 Server but the policies are probably similar.

The limit of two remote sessions in the regular editions is arbitrary, but was chosen mostly for RAM constraints; the windowing environment for each user plus the tasks they're likely to run will consume a few hundred MB of RAM or more. The advanced editions support RAM beyond the 4 GB 32-bit limit.