Hacker News Reader

Comment by reacweb | Hacker News Reader

If I encounter an issue on Linux (that I can reproduce), I can investigate it to its root (sometimes in the kernel driver) and fix it (or find someone who has fixed it). On windows, I have only seen issues fixed either by reinstalling applications (mostly randomly) and praying or by using annoying work arounds. IMHO, the cost is higher in Windows.

View on HN

This is to some extent only a consumer approach. There are tools allowing in depth debugging. Given a big enough budget you'll also get direct help from MS. This relies on very skilled staff though.

Sure, it's easier to debug kernel things on Linux. But you certainly can debug Windows as well.

Stuff suddenly starting to work on reboot for Windows is getting old.

I don't know what to use Windows servers for if it wasn't for a project that uses MetaTrader.

We have these old Windows admins now learning to work with Linux. What drives me insane is their habit of randomly rebooting machines if something isn't working right. There is a problem with a Linux box, they ask you to take a look at it, you SSH in, type "uptime"... bam, it's two and a half minutes. A lot of precious diagnostic information has been lost.

alias reboot='echo "This is not Windows!"'

Real Linux admins know how to invoke the real 'reboot' command.

Make sure to set SSH to log in directory to vim. Unlike Real Linux admins know how to quit vim so it will be no issue for them.

Wouldn't their login session end after quitting vim?

Yes, but you can get to a shell without quitting vim. <esc>:sh

init 6

Oh please, they started Gnome and used the shutdown command from the menu.

With the growing ubiquity of the linux port of svchost.exe(systemd), nested hypervisors, containerization, et al. Rebooting (where feasible) has already become a front line option.

This Reboot-to-Fix mindset encroaches on other domains as well. My car had a weird issue when it would't pair to the phone, auto-technician: "reboot!" Someone here say that I'm probably a *nix admin vs a Windows user, and that's true, but every time I try to do adminsy things on a Windows box, the tools are just not there, or the interface to the tool is like controls in an alien spaceship. I find myself completely and hopelessly lost. Trying to find stderr, stdout, logging, grepping, finding, the tool to work with PKI certs, all fearsome in their inscrutability. Are there Windows kernel old-timers who can help me with the learning curve? No. Most Windows admins don't have a habit of digging deep because that's not the culture, because the tools weren't/aren't there. And reboot fixes most things on Windows.

This is a roundabout way of saying: "I know more about Linux's internals than Windows'." Essentially you're a power user of Linux and a consumer of Windows. I'm not sure that's Windows' fault.

That's not entirely true...

Given Linux's history as OSS, it has historically been easier to be familiar with the inner workings of Linux than Windows simply by having access to the code. Other than reading System Internals, becoming MCSE certified, etc. it was really hard to know much about Windows. I'm not saying every Linux user has read the source but being built on top of OSS does allow the user to dig deeper if one wanted to. I say this as someone who started out his career in Windows and Microsoft and then later went to Linux (because I went from corporate to startup). It's much easier to pinpoint a problem with OSS and Linux, especially in situation when the documentation is lacking. It took me a lot less time to have a decent knowledge of Linux and OSS systems than it was for me to know the equivalent on Windows and Microsoft.

This effect gets compounded when you consider an entire ecosystem.

Yeah, I mean why doesn't everybody dig through the kernel sources on Windows when they encounter a bug like that?

The vast majority of Linux users will never poke around the source to the Kernel ferreting out a bug, but they do have the option. On Windows it's much harder to get access without being a Microsoft employee.

It does not end with the kernel. Of course it is possible to run proprietary software on Linux and OSS software on Windows, but I have rarely had to deal with proprietary software in Linux. That is only in small part because I avoid it.

I'm not a kernel hacker. But I have on occasion cracked open the source for some product on which I relied to find out why it was behaving contrary to my expections. Much more I have done that with a library upon which I was relying.

Many many times more often I have sought answers from authors or experts of a lib, etc. to clarify what I didn't understand from documentation.

All of this is easier and frendlier with open systems. MS is coloring itself more open recently, but they and the ecosystem built upon them and around them have a long way to catch up. From my perspective the gap is so large and so pervasive that I don't even bother kicking the tires any more. I don't know if MS will make it there in my productive lifetime. If they do, I think the ground will have to have shaken dramatically so many times that it will get my attention. So, I will continue to ignore them until then.

Reply on news.ycombinator.com