5 ms·
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 (Powershe
by sgt 4y ago
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).
- radicalbyte 4y agoIt 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.
- jiggawatts 4y agoI 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...
- radicalbyte 4y ago> 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.
- dijit 4y ago> 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 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.
- jiggawatts 4y ago> 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.
- jiggawatts 4y agoThat'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.. Now try this with PowerShell: Invoke-Command -ComputerName $varWithListOfServers { Get-Process 'ubiserver.exe' } | Export-Csv 'report.csv' 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 Ta-da, now it's just as unreadable as Unix: icm -CN $s { ps 'ubiserver.exe' } | epcsv 'report.csv'
- hnlmorg 4y ago> 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 :)