Comment by bigfudge
19 days ago
This probably reflects my own prejudices, but it always struck me that MS based IT people wouldn’t work with anything else, basically because they couldn’t.
That stack optimises for not really having to understand what you’re doing, but also avoiding any major foot guns (and having the general arse covering that buying IBM used to provide, but which MS now does). The price you pay is that everything is horrible to work with. But if the alternative is not really being able to get anything done at all then so be it?
The Windows ecosystem does a lot of things that, to me, as a Linux/MacOS user, seem like a weird bunch of crazy decisions that are different just because.
Whether that's true or not, it does mean that a lot of people who came up on Windows IT don't have a mental framework for how to run or manage Linux systems. Likewise, when I'm trying to diagnose something on Windows it just seems like the entire thing is a disaster; where are event logs? In the event viewer! How do I filter them? It's a mess! Can I search them? Kind of! Do they have information to help me diagnose the problem? Almost never!
On Linux, I know all the tools I need to solve all the problems that come up; on Windows, I have only minimal concept of how things work, and very little way to diagnose or debug them when they go wrong, which is often.
For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds, but I'm a Linux IT dork and I have no clue.
> For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds
Windows and Linux dork here (heh). It has to do with how various computer manufacturers implemented the Sleep/Standby State (S3/S4), how they've resisted implementing a common standard at the hardware level, and how Microsoft eventually gave up arguing and patched around it with their own Modern Standby system in the S0 state.
https://learn.microsoft.com/en-us/windows-hardware/design/de...
Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).
> Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).
This has always been my experience, going back I'd say at least to the early 2000s on cheap laptops, and all the way back to the earliest days of sleep and hibernate on desktops, where sleep just doesn't matter that much.
When I started dabbling in boot code around 2006, I read a bunch of the specs and one of them was ACPI, which I only scratched the surface of.
I think until then it had just not occurred to me that a modern paged protected OS would even want to call into any code supplied with the computer, vs. having it come from a driver disk, or be built in to the kernel where everyone can see it.
The whole idea of a bytecode interpreter running random code supplied by a fly-by-night system builder is a little unsettling.