This rant starts of pretty badly, with "Windows bad, Unix good, Windows especially bad because it doesn't have Unix tools".
Reverse that statement. Is Unix bad because it doesn't Windows tools?
> but simultaneously there was nothing to lean back on: no shell, no Unix tools like sed/awk, no SSH. I
He joined in 2014, when Windows had a superior shell and remoting system that eliminates the requirement for low-level string parsing tools like sed/awk entirely!
PowerShell + WinRM + Desired State Configuration (DSC) was all pretty mature at the time, and I had used these technologies to manage huge fleets of servers solo without issues.
Then, almost none of this heroic database backup efforts would have been required if they had just a commercial database product, e.g.: one designed for Windows such as SQL Server.
In 2014 it supported AlwaysOn Availability groups that allowed multiple synchronous and asynchronous replicas! It also has had true online backups since before 1997.
His second mistake is that backups can be incremental, but a restore in a (true) disaster is a full restore by definition! Differential + Log backups are great to capture data regularly during the day, but the business requirement is usually that a full restore must complete in a reasonable time.
Typical commercial databases plus the product he mentioned could easily backup and restore tens of terabytes in setups I've seen directly to or from any proper database engine without having to through "NFS" on the way. Typically you'd use a native backup agent.
This whole article sounds like a self-important Unix engineer refusing to touch commercial products, lack of understanding of business requirements, and an allergy to Windows.
I respectfully disagree. Having been an admin for both (started out as a Windows developer and NT4 sysadmin, so you can’t say I wasn’t experienced) I’ve always found UNIX to be vastly easier to manage servers.
Yes, Bash has a lot of warts (so much so that I wrote my own shell) but Powershell creates lots of new warts of its own.
As for automation, Windows doesn’t even come close to
UNIX-like systems for east of scripting and automation. There’s just no contest.
Bash might be ugly at times but at least its ugliness is consistent. I’ve lost count of the number of times I’ve found parameters parsed differently between applications (because Windows passes parameters as a single string rather than an array of arguments like POSIX systems), or that so called headless installers still have GUI prompts and/or spin off a non-blocking process so it’s challenging figuring out when it’s complete. Or Powershell routines come back with an unexpected type thus breaking your entire pipeline. Or don’t even support basic help flags so you cannot discover how to use the damn routine to begin with. Or the utterly ridiculous numeric error code that MS returns rather than descriptive error messages. Or its over engineered approach to logging that makes quick inspections of the systems state far more involved than it should be, or even just managing simple things like software updates requires while other expensive 3rd party solutions because the whole application and OS package management situation is fundamentally broken at its foundations …I could go on. But suffice to say there’s so many painful edge cases to consider with Windows.
Windows does get somethings right though: RDP is a great protocol and its backwards compatibility story is second to none. But for server administration, Windows feels like a toy OS compared to most UNIX-like systems. As in it has support for pretty much anything you’d want to do
With modern server management processes but yet everything it does support it does so in a really awkward and immature (technologically speaking) way.
I’m sure it’ll get there though. But likely not before I retire
What are you talking about - Windows was always terrible for an admin. Unix was and is vastly superior when it comes to remote admin. Having used both (Powershell is powerful yes, but it's nowhere as fluid as a Unix shell).
That's just not true. It feels true to Unix admins trying to do Unix things on Windows and getting frustrated when nothing feels familiar.
Let me quote the article directly: "no SSH"
WinRM is roughly equivalent and superior in many ways. E.g.: It takes quite the effort to produce a report of "some setting or flag" across a fleet of servers with SSH, Bash, Sed, Awk, etc..
This will connect in parallel to all the servers in the list (could be thousands!), 32 at a time by default. It'll get all of the process info (memory, cpu time, etc...) for a game server, and then add the source server computer name as an extra column. Dumping this to a valid CSV is a no-brainer.
Put this in a scheduled task and you've got something Excel or Power BI or whatever can pick up and chart, graph, or send to a manager.
Try this with Linux. Seriously. Sit down and do the equivalent: many servers in parallel, batched to prevent overload, server name as an extra column, valid CSV output with proper quoting of quote characters, etc...
Oh, did you notice the lack of authentication rigmarole? The whole thing is secured and encrypted via Kerberos automatically. Copy the equivalent of that too. (Assume you have 10K servers that you haven't manually added the SSH keys of into your local workstation config.)
Put the script in the reply.
PS: I know some Unix people think that brevity is more important than time-to-solution, so to head off that whole argument:
PS C:\> Get-Alias | ? ResolvedCommandName -in ( 'Invoke-Command', 'Get-Process', 'Export-Csv' )
CommandType Name
----------- ----
Alias epcsv -> Export-Csv
Alias gps -> Get-Process
Alias icm -> Invoke-Command
Alias ps -> Get-Process
> Try this with Linux. Seriously. Sit down and do the equivalent: many servers in parallel
On my phone so not going to type the full command line out ostensibly it would be:
xargs ssh ‘ps process-name’
I’d need to pull the man pages up to double check which flags you’ve specifically requested. But the above is the general gist of it.
——
I think it’s pointless to compare such granular features side by side though. For every microscopic thing Windows better Linux will have others it does better too. And visa versa. It’s the overall administration at a higher level I’m more interested in:
How long does it take to go from a new requirement to a deployed service? How easy is it to automate? To adapt? To scale? To fix? Or even forget fixing entirely and just run as a fleet of ephemeral instances.
Windows can and does support everything Linux does too. But Linux is just generally easier to work with (in my 30 years of experience managing both).
I wouldn’t say Linux is the peak of UNIX-like systems either though. But that’s a whole other argument for another day :)
It's not even remotely the gist of it. The output of that is formatted (pretty-printed) text, not CSV. You won't know which computer the output came from. You can't use this output in any meaningful way. It's not useful to the business.
ssh can't connect to multiple servers at once (other tools like multissh can). However, most such tools aren't designed for and aren't capable of scaling up to a thousand or more servers.
Windows PowerShell and WinRM can, yet people like you just blindly dismiss it, assuming that it "must" be worse than Unix/Linux, since everyone knows that Windows doesn't even have a shell!
To quote the original article: "there was nothing to lean back on: no shell"
Windows has a shell, the author of the article just wasn't aware of its existence, let alone its comparative feature set.
I'm well aware of the existence of powershell and CMD, such things are not a real luxury when you're limited to whatever Windows provides you with as utilities as opposed to the astonishingly wide plethora of commandline utilities available else where (where everything is a file and is easy to read, parse, filter, save-).
Windows 2012r2 came with Powershell 4.0, which I'm sure you'll agree was limited in ways that bash is not, since bash is a collection of utilities and doesn't require deep integration with the platform to function.
For example in your example above you use 'Export-Csv', but that was introduced in Powershell 7.0
Am I saying that it's not possible? Not really, powershell can probably do everything I need it to, but it's not as simple as `ssh user@host` and I'm talking in a way that feels native to the system. It requires a paradigm shift in thinking that most of our developers didn't embrace and discoverability is just lower there anyway.
Claiming that winrm is better than SSH is... just the most absurd thing I've heard this year.
The main reason that I got annoyed with Windows though is not the eggregious license cost- it wasn't that it used an enormous amount of resources- the documentation was really nice!
It was that my iteration times on toying with things went from 5 minutes to 25 minutes in the minimum, that doing any kind of exploratory work meant near certainty that I'd be RDP'ing.
This is not a "I hate windows" rant, but the defensive position you have taken here is frankly unpaletable. Windows has it's strengths, and perhaps I am not the person to charter a course to a fantastically well designed "Windows-centric" solution to problems -- but fuck, it worked honestly and it worked better than any of the Windows admins in Ubi could have mustered. Maybe that's a statement about the general competence of windows admins or just the ones at Ubi, I don't really know.
But Windows is a poor fit for dynamic server workloads such as those. The only reason it was chosen was because the game was developed on Windows and against Windows APIs - some of which were even better than Linux ones at the time, like IOCompletionPorts, which I have extolled virtues upon - rewriting the software to work on Linux would have been a hugely time intensive process. That decision cost Ubisoft literally millions of euroes and was a decision that was later reversed- after I left.
It is literally that simple. Nay, simpler, because authentication is automatic and secure:
Enter-PSSession 'hostname'
Oh, I'm sorry... too verbose and readable.
etsn 'hostname'
> since bash is a collection of utilities[1] and doesn't require deep integration with the platform to function.
You're also unaware of just how elegant PowerShell's extensibility model is. It runs circles around traditional shells, because you can whip up a new "native" command in just minutes, but with features that would take a week of C programming against the Unix byte-oriented pipeline.
The first time I saw something like this, it blew my mind:
Import-Csv 'serverspec.csv' | New-VM
I wrote some spectacularly complex scripts in bash, and it always felt like digging through dirt, looking for nuggets of gold that everyone promises is there, but I just can't find it.
[1] Those utilities are hilariously inconsistent not just between each other, but between distros and even distro versions. E.g.: SSH is so easy, right? Okay, write me a script that can create a sudo-enabled user and install an SSH key for them on every popular Linux made in the last decade. Include Redhat, Ubuntu, Amazon Linux, and whatever else is reasonable. Three "Linux admins" failed at this task, and I had to resort to using ChatGPT and then fixing up the result by testing it against a dozen VMs that took me a day to spin up.
> It is literally that simple. Nay, simpler, because authentication is automatic and secure:
You keep saying that as if there’s no such thing as secure automatic authentication on SSH yet people have been doing exactly that since before AD was even a thing.
> Three "Linux admins" failed at this task, and I had to resort to using ChatGPT and then fixing up the result by testing it against a dozen VMs that took me a day to spin up.
You do realise that you can get bad Linux sysadmins as well as bad Windows administrators?
Plus it’s not really fair to compare managing different distributions to managing a Windows (unless you’re counting Windows 95 and CE as part of your fleet). Most businesses standardise on one Linux distro (or BSD flavour) and only diversify from that if that absolutely have to. It’s not because Linux is harder than Windows. It’s because managing multiple different core stacks is harder regardless of whether that’s Linux and Windows. Or Linux and BSD. Or Windows 95 and Windows XP. Or different base distributions of Linux.
The first rule of managing large fleets of servers is homogenise as much of it as you can.
This is a great discussion from everyone! I have learned a lot about Powershell here, so thank you!
That said, the comparison to a homogenous windows env and a mixed flavor linux environment is disingenuous. Using multiple flavors of linux is just multiple OSes, of which Windows would be another. The best advice here is to stick to one flavor of linux, which should be possible because there are no licensing fees!
There is an often overlooked downside to “options”: it means that even well-meaning people will pick inconsistent things unless ruthlessly forced into compliance.
Single-choice vendors like Microsoft or Apple remove this variability, which is a big benefit at the scale of large enterprise or “entire ecosystems”.
Linux is too flexible, and the inevitable consequence of this is that I have customers that each have a dozen incompatible variations in production.
Even if each customer had precisely one version of one distro, my scripts wouldn’t be safely portable between them if they don’t happen to pick the same distro!
I’ve got decade-old complex PowerShell scripts I’ve reused across a dozen unrelated customers. That’s a significant benefit.
People do standardise on a distro within companies though (I made this point to you elsewhere too the last time you claimed otherwise).
And it’s not like Microsoft doesn’t change things around between different releases of Windows. I’ve ran into just as many compatibility issues with edge case software between different versions of Windows as I have with Linux. The key is just understanding the base of your OS as well as your software. This is as true for Windows as it is Linux.
And I have Bash scripts written in the 90s, before Powershell was even a thing, that still work now. In fact one of the biggest complaints about POSIX is the age of the specification. So it’s strange that you’re talking about Powershell as if it’s unique in its compatibility promise.
I’m honestly questioning just how much experience you have in this field because you talk as if everyone misunderstands Windows yet then go on to make the exact same misconceptions about Linux (and POSIX in general).
> It's not even remotely the gist of it. The output of that is formatted (pretty-printed) text, not CSV. You won't know which computer the output came from. You can't use this output in any meaningful way. It's not useful to the business.
You can add all of that easily. Printing hostnames or turning text to CSV isnt a hard job on any computer. I was doing this in the 90s on Windows, years before Powershell. And on pre-OSX macs (think System 8 and 9) connected via AppleTalk. So modern Linux systems are clearly not going to struggle in that regard.
And you’re now just doing exactly what you criticised the author for: making up bullshit requirements based on what you’re familiar with and then using that as some lame excuse to call everything else garbage.
> ssh can't connect to multiple servers at once (other tools like multissh can). However, most such tools aren't designed for and aren't capable of scaling up to a thousand or more servers.
You’re making distinction that doesn’t exist. It doesn’t matter if you’re spinning up multiple SSH sessions from one program, or multiple programs each with a singular SSH session. It’s still the same number of outbound network connections (and likely same number of processes too).
What matters is how those connections are managed. And the code I exampled does run those connections in parallel.
> Windows PowerShell and WinRM can
Bash can. It just needs to call a process. Just as PowerShell is calling a process to do it.
Saying SSH cannot whereas Powershell can is comparing apples to oranges. SSH isn’t itself a shell, it’s a secure client/server protocol that allows you to run remote code inside a pseudo-TTY. Generally that would be a shell, but it doesn’t have to be.
(Source: I’ve written multiple shells for both Windows and Linux over the years)
> yet people like you just blindly dismiss it,
That’s not what I did. You’re now making assumptions about me. Ironically “blindly dismissing” my comments in the process.
> assuming that it "must" be worse than Unix/Linux,
I dont need to make assumptions. I have a hell of a lot of experience managing Windows systems. 25+ years in fact.
I’ve also written plenty of server side software for Windows too. And network enabled Windows malware (pre-NT4 college network. I mostly just used it to siphon off other peoples quotas from the college ISDN line. But it taught me enough to earn a career in IT)
> since everyone knows that Windows doesn't even have a shell!
Literally no one said that outside of the article.
Windows clearly has several shells: explorer.exe, cmd.exe, Powershell. Plus lots of frontends for remote services via RPC.
I also credited RDP as being excellent too.
> To quote the original article: "there was nothing to lean back on: no shell"
I’m not the author of that article so I don’t really understand why you’re using that to prove a point about my own ignorance.
> Windows has a shell, the author of the article just wasn't aware of its existence, let alone its comparative feature set.
We aren’t talking about the article though. We were talking about your generalised point that Windows is easier to administer than UNIX-like platforms.
If truth be told, I stopped reading the article after about 3 paragraphs because it was pretty obvious that it wasn’t a well thought out piece. But that doesn’t mean I agree with you any more than the author. You’re both at the extreme opposite ends of reality.
No it isn’t. The problems you describe are literally what the Unix command line was invented to solve, way back in the 70s. And what every other pipe-supporting command line shell, PS included, has been inspired by since.
If you want to talk about which shell you personally prefer writing scripts in, then that is a different matter. I have zero issue with people preferring Powershell (heck, Linux can run PS these days). I even wrote my own shell because I felt I could do better than Bash. But don’t make bullshit up like “Linux can’t print host names nor CSV” when that’s basically the MVP for any command line interface.
> Less talk, more script source, paste below please.
Do test it first though, several people have submitted hilariously incomplete, invalid, or partial solutions.
I honestly don’t see why I should bother. I’m on my phone, cooking breakfast and playing with my kids. And it’s pretty clear you’ve already made your mind up. So I don’t see why I should give up family time to win an argument with a random internet commentator who’s clearly never going to get anything beneficial from the exchange anyways.
The fact that you don’t understand how ssh nor xargs work just demonstrates that you’re not in position to make these kinds of comparisons in the first place.
So take my word for it or don’t. I don’t really care any more. But I’m not going to interrupt morning and fire up a laptop just to write a script that you’ll instantly dismiss for whatever arbitrary and biased reason you dream up next.
I'm sorry, but this comes across as exactly the same kind of bias as the author. "my knowledge of windows sysadmin methods means Unix methods are crap".
I'm afraid it's horses for courses, it's always been. We'll all pick our own preferences of course,but let's not assume total superiority over "them".
Winrm is nowhere near equivalent to SSH. It's terrible. Just try using anything that uses window's DPAPI over winrm. You have no such limitations with SSH. Also it's authentication mechanisms are vastly superior (SSH key pairs).
The whole point of UNIX is to use independent, composable tools that speak the same interface. If the interface is space-separated values, use space-separated values. If Excel or PowerBI don't use that then don't use Excel or PowerBI.
Your boss uses Excel and doesn't like it when the reports\ read\ like\ this because you ignored his requirements. Your coworker is also angry at you now, because when he scheduled your script to run regularly, the output occasionally turns into gibberish because of inconsistent handling of special characters and error conditions, breaking automations randomly.
I spotted several errors in your provided "solution", which ought not be possible, because I'm a person that uses Linux briefly every few years.
The problem statement isn't a made up, artificial, or toy scenario. The few times I have to use Linux, it's to do this kind of activity. "Run a command on all Linux servers in the data centre" is something I had to do just recently, and it turned into a multi-month exercise involving six people. It would have been an hour with Windows. Think "look for log4j", "install an agent", or "report on the kernel version used".
Problems like this seem trivial, but it is precisely the independent nature of those tools that makes them not composable.
For example, 'ps' has different output and different capabilities on different systems! You can't naively run it across multiple systems, because output will be an inconsistent mess. You can't then sort, filter, aggregate, or do anything useful with its output.
"aux" is the wrong option to use. It'll pretty-print the output, which forces it to truncate long values. It'll return date times with inconsistent offsets, depending on each server's individual time zone and regional settings. It'll strip the year off, so if you want the 'date' a process started, it won't be obvious if it has been running for 1 month or 13 months.
If any servers aren't already in your ssh keychain, then your command will... what? Freeze? Output errors into the report? Prompt for your input thousands of times, one per server? In parallel? How... did you expect this to work!?
saying your thousands of servers wont have ssh keys installed when they have arbitrary software installed is disingenuous at best.
thousands of servers are managable only with orchestration solutions, this is a solved problem. the unix world also has evolved from a bash for loop to ssh into servers and read outputs.
i can solve your task in comparable time with pyinfra or ansible executing arbitrary python code on every node with not just csv output but whatever you dream up.
The big problem with Powershell vs Unix is lack of documentation. Seriously, everything takes 100x less time to figure out on a Unix platform than Powershell. And my life is to short for that.
That being said powershell is much more discoverable _for me_ because it’s simple objects that get piped. I don’t have to figure out how to parse the text of a traditional shell. I can just get things done.
but where was powershell (introduced in 2006) on unix (introduced in 2016) when admins needed it since epoch?
the tools i have learnt might have more cryptic names but they were there since the beginning.
it took microsoft an awfully long time to realize cmd.exe just wont cut it.
also powershell has no choice but to include the kitchen sink to be usable because there is little composability in the windows shell world compared to the cambrian explosion of unix utilities.
It depends on exactly what and how you're doing it.
I have as devops managed both a small fleet of windows boxes (~20 machines) an a similar amount of Unix (Linx-based) machines.
Remote management of Windows was initially a pain to set up but once it was running it was fantastic. Being able to manage the entire application layer with properly tested, versioned code written in C# is an absolute killer. Things like debugging/logging etc are also "just there", and SQL Server is a fantastic database.
The Linux alternative on the other hand was easier to update and had some benefits to the developers (you can sort-of recreate a production-like environment in containers locally). The management after that was a huge pain because everything seems to have been built McGuyver style. I like Postgres but prefer using SQL Server (probably personal preference at this point tbh).
Things are different nowadays: systems like Kubernates apparently simplify the Linux side and make it affectively trivial to deploy and do cool stuff such as dynamically scale systems. It's also more efficient as you can remove the overhead of the Virtual Machines. It doesn't take much imagination to see that that would make a Unix-based system better.
I agree with everything you've said, but to add to that: there are these weird inflection points with both platforms.
A single "small business" server is easier to run on Windows and it'll do everything you need it to do with minimal fuss. Easy GUI admin consoles are available, etc...
For 2-3 servers it swings back to Linux because some things are just easier at that scale.
For 10-1000 servers that aren't all identical, I prefer Windows because of things like Active Directory, GPOs, DSC, etc...
Above 10K and especially above 100K scale the Windows licensing costs become absurd and you're likely deploying thousands of identical nodes (web farms, HPC clusters, etc...) and then Linux becomes very compelling. This is why all of the FAANGs run primarily Linux, because at the multi-million-node scale it's the best option by far.
Interestingly, container technology is maturing in Windows as well, especially with Server 2022 and Windows 11.
However, it still has a few rough edges, so I'm waiting to see how it all pans out...
> For 10-1000 servers that aren't all identical, I prefer Windows because of things like Active Directory, GPOs, DSC, etc...
I run over 1000 Windows boxes and AD/GPOs are terrible. GPOs are spaghetti by design. There are no concepts of infrastructure as code with these tools, and they're quickly becoming liabilities at any scale. There aren't any real ways of making repeatable and reversible changes so these infrastructures via code.
Broaden your horizons a bit and you'll notice these are not the way.
Using Chef on top to manage DSC is the only thing that allows me to keep my sanity, and the more config I pull out of GPO and AD the happier everyone becomes, and the safer all of our systems are. Windows is terrible because it's too heavyweight and too opaque. It is the opposite of an agile choice of operating system.
> I prefer Windows because of things like Active Directory, GPOs, DSC
I felt the same until we had a bug which broke the network adapters under high throughput of packets per second (of course, we didn't know the cause, but the machine was bumped off the network until a reboot which wiped away debug info).
Going via the IPMI yielded a "Can't connect to AD" message, and the rotating local "Administrator" account password was unrealistically hard to acquire (ubisofts fault, not windows); which lead to me writing this: https://github.com/dijit/statham (but in Go, this is a rust reimplementation) so that we could all have local accounts. :|
> container technology is maturing in Windows as well, especially with Server 2022 and Windows 11.
I'm actually using Windows Kubernetes nodes today, it has two huge notable drawbacks.
1) The base container image needs to match the kernel version, meaning you need to build containers for Windows Server 2019-ltsc, Windows Server 2022, Windows 10 and Windows 11
2) The containers are enormous, one of mine is sitting at 6GiB and takes 4 minutes to pull on GKE.
and the minor drawback of; the instructions to make a bare metal kubernetes windows worker node are sporadic, outdated and otherwise largely missing.
> The base container image needs to match the kernel version
The kernel ABI has been stabilised in 2022 & 11, which means this is no longer an issue. I tested it and it seems to work as advertised. E.g.: both Windows 11 and 11 22H2 OS can both run a variety of 2022 and 2019 containers, and can run "RTM" and semi-annual 2022 containers in process isolation mode.
> the instructions to make a bare metal kubernetes windows worker node are sporadic, outdated and otherwise largely missing.
I wouldn't even try. Just use Azure Kubernetes Service (AKS), AWS EKS, or something similar.
That sounds great. As this should be very useful for my workplace, it would be great to have an official source to cite on this. Unfortunately, my Google-fu hasn't returned much right now.
If you know of any Microsoft documentation pages, blog posts or something similar on this, can you point me in the right direction? Thanks! :)
> I agree with everything you've said, but to add to that: there are these weird inflection points with both platforms.
Spot on.. and I do like both platforms with a slight favour for Linux because licensing can be a hassle (unless MS still do those special Enterprise deals and you have one) and you can kind of get around the messy Linux things and it's generally easier to work with unknowns/new things in Linux (as the MS world abstracts too much).
It's good that we have the options and any adult Developer/Systems Admin would recognise that and take advantage of it.
I know people will now argue into oblivion about powershell vs bash, but I actually wonder why was this person hired in first place to manage windows based systems what clearly seems not be his domain of expertise?
In my experience it is often better to hire people who are curious, motivated and at least a little bit intelligent than people who already possess specific skills.
You can argue until you're blue in the face about if my approach was the right one, ultimately though what we did worked, was incredibly lean, easy to understand/troubleshoot/debug and most importantly it served the goals of the business.
Could we have gotten up to speed with the Windows way of doing things?
Probably.
There were so many niggling problems with the platform that were not part of my prejudice, that if we continued to go that route I am certain that 1000's of our person-hours would have been consumed even if we had been absolute experts, things like the fact that windows bonding in 2012R2 was done in userland, that joining to the domain requires a reboot (which will break your software if it's registering to take workloads on boot), that powershell versions are often incompatible and that interface devices are very difficult to deterministically reference.
Windows sysadmins seem to come in two varieties:
1) Experts who know exactly what Windows is thinking at all times
2) Button mashers
Unix/Linux engineers have a much broader range of knowledge, and there's certainly more of them on the senior end.
It's counterproductive to hire people who go against established procedures and built systems at company just because they have high quality opinions about one piece of software or another.
>He joined in 2014, when Windows had a superior shell and remoting system that eliminates the requirement for low-level string parsing tools like sed/awk entirely!
These debates always remind me of this quote (referring to C++) here on HN by another user:
It seems like grappling with these arcane features feels productive, at first.
You enter a flow state and after a while, something works that didn’t work before.
It’s only when you step back and ask what actually got accomplished that you realize it’s time wasted.
That's what Linux feels like to me. People enjoy solving arcane problems, digging through man pages, download esoteric commands. Heck I enjoy this stuff too! Recently I had a lot of fun playing around with parallel compression tools available on Linux.
It's fun... but it's rarely as productive as not having to deal with the challenge in the first place.
There's not much of a debate. Windows as a server is dead outside sme shops. This isn't the 90s anymore. But it is very nostalgic hearing people talk up microsoft. It's not something I'd heard in the last 15 years.
Reverse that statement. Is Unix bad because it doesn't Windows tools?
> but simultaneously there was nothing to lean back on: no shell, no Unix tools like sed/awk, no SSH. I
He joined in 2014, when Windows had a superior shell and remoting system that eliminates the requirement for low-level string parsing tools like sed/awk entirely!
PowerShell + WinRM + Desired State Configuration (DSC) was all pretty mature at the time, and I had used these technologies to manage huge fleets of servers solo without issues.
Then, almost none of this heroic database backup efforts would have been required if they had just a commercial database product, e.g.: one designed for Windows such as SQL Server.
In 2014 it supported AlwaysOn Availability groups that allowed multiple synchronous and asynchronous replicas! It also has had true online backups since before 1997.
His second mistake is that backups can be incremental, but a restore in a (true) disaster is a full restore by definition! Differential + Log backups are great to capture data regularly during the day, but the business requirement is usually that a full restore must complete in a reasonable time.
Typical commercial databases plus the product he mentioned could easily backup and restore tens of terabytes in setups I've seen directly to or from any proper database engine without having to through "NFS" on the way. Typically you'd use a native backup agent.
This whole article sounds like a self-important Unix engineer refusing to touch commercial products, lack of understanding of business requirements, and an allergy to Windows.