| You don't have to be crazy to work here... but it helps? |
[Jul. 14th, 2009|10:27 am] |
One hour of every four I have spent in my tech career has been fixing a Microsoft product. You know, when you make a mistake in Linux, usually, 9 times out of 10, it's your own damn fault. But you can tell it's your fault because most people who write open source/GNU stuff have decent logging. Microsoft has a little GUI window called "Event Log" which isn't a text file but a kind of database of events without a decent grep filter of any kind, but a crude "Find..." option.
Linux is rock-solid stable, which sometimes leads to a problem where you "set it and forget it." For years. Make a box, set up Apache, tune some things for PHP, sent up snmp to check for problems, and boom... 4 years later, you wonder what the hell is on the box because you forgot what you did, and didn't document it (I do, though, for just these reasons, you just have to remember where the notes are). I have had Linux boxes with 2 year uptimes, which is kind of bad, since that means you have missed a dozen or so security updates, but rarely are they attacked. Windows you have to reboot a lot. If anything, because the latest security patch forces you to reboot. Most of my Windows boxes at work have uptimes of 30 days or less. In my entire career, I have repaired just two compromised Linux boxes. I can't count how many Windows boxes I have wiped. More than 100, surely. Sometimes you do a DnR on a Windows system because it just takes far too long to diagnose and repair them. Most high-level Windows sysadmins I know do this unless the data is just to valuable to lose in a reformat.
When I used to do QA for AOL, Windows users were so used to crashes and problems, they were often far better educated than Mac folks when reporting bugs. Mac folks were so unused to crashes, they were shocked and even insulted when shit went wrong. And AOL software went wrong a lot. Still does, from what I hear. Linux folks, especially the GUI set that are prevalent now with the rise of Ubuntu, still have a lot of stuff that goes wrong, often with hardware interaction and GUI scripts that conflict with other scripts. Thus most are still pretty educated as the Windows folks were back in the day. Numerous help forums have honed early Linux adopters to grep through error logs and whatnot. But in 2014? Maybe Linux will be completely run by masses not used to looking under the hood.
So, like with Windows 95 beta testers back in the day, when troubleshooting Windows servers, so much of the OS is cockeyed and nonsensical, it's only my experience that has made me a better admin. You could know how a network stack works inside and out, but that won't help you much when trying to determine why a running service on Windows isn't reachable from one subnet. Can't grep a tcpdump. You got to know what set of menus, sub-menus, tabs, and checkboxes to click. Gets in my way. Command lines are MUCH faster in the end. Finding an error in Linux is like looking over a field of moving objects, and looking for one that doesn't look right. Finding an error in Windows is having to go through a maze with doors, traps, and puzzles to try and find if you can see that error, and then the same goes for fixing it.
It's like a special kind of insanity. And over time, I am actually learning this insanity. It reminds me of why I was made a FanTekk BBS sysop.
The FanTek BBS was run by some of the craziest software imaginable. "Nitelite," Paul Swanson's BBS software for the Atari ST, was built from Pascal over a Motorola 68000 chipset for mutli-line BBSing. The BBS program itself had its own proprietary language which made no sense whatsoever. It was based on commands that looked like "K6:" or "PRL!" which were often riddled meta-commands and lacked any sort of consistent structure. It was as if the designer had grouped commands by letter as he thought of them, so the "L" commands had no real grouping as opposed to the "K" or "M"-based commands. KR2 may have meant "write to a file" and G1 might have meant "read a file" but G2 might have meant "send user to chat room." The entire chat room, I think, was a meta command, which made no sense except if pulled from a menu.
The file directory system was DOS-based, but used letters that had little bearing on actual locations. I recall "X:\" was a kind of "virtual directory" which had to do with the BBS loaded into memory as opposed to the actual files on a disk. "K:\" was the read-only program executables, and "L:\" would be the read/write data, if I recall. Totally insane.
The BBS was not ANSI compatible, but I knew a slew of VT100 escape codes, and so hacked the menus to have colors, rewdraw themselves, and so on. I redesigned a new chat room from scratch because the software author was so tired hearing from Bruce, he gave us the source code and told us to compile the damn thing ourselves if we thought he could do better. And we did (thanks to ALICE PASCAL). Sadly, Pascal for the Atari had a memory pointer limit of 2^15, which meant anything that went over the number 32,768 (number of files, message board ID number, number of e-mails posted since start, etc), the system crashed.
Previous sysops, like Allon, Suzi, Darryl, and Ralph, had a saying. "You have to be a special kind of crazy to manage this system. Punkie has that kind of crazy." I am not sure if that was meant as a complement, but I took it as such. In fact, whenever I can't figure out something, a voice in my head says, "You fucking managed the FanTek BBS. If you can do that, you can do this."
It takes a special kind of crazy to manage Microsoft products. |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}