As a Windows administrator, what were the issues you encountered with trying to learn a linux distro?

I know that you're out there. You've heard of this "linux thingy" and thought you might give it a spin on the weekend. You gave it a whirl, started the machine up, and something didn't quite work as expected.

I've done admin work in both Windows and Linux. I've also watched people "struggle" with trying to grasp Linux. This appears to happen again and again, so the question(s) become:

• What were your expectations?

• How were those expectations not met?

• What was the basis of those expectations? Was it your prior experience?

EDIT:

The most coherent answer with complete examples will be awarded. If I can't find an answer that explains the bulk of difficulties encountered, this will be turned into a wiki.

CLOSE:

Re-edited the title to make it 'less inflammatory'.

Solution 1:

I could see a big expectation let down with Windows admins who think that everything can be solved via some GUI tool. This shouldn't even be assumed in Windows...

EDIT:

Some more specifics that I've heard of or run into personally:

• Devices as files in the file system
• Different distros put the same binaries in different places
• Keeping track of what happens in which different run level for the purposes of startup and shutdown (although it is nice to have the granularity in my own humble opinion)
• What the he!! distro is good for what.
• Keeping track of what abbreviations mean what in files, device names, shell commands
• Keeping track of what switches do what for all of the shell commands
• Which command line shell is best for what and why
• Keeping the darn thing updated (although this has gotten significantly better in the past few years!)
• Apparent necessity to recompile down to even the kernel in order to get certain features enabled or disabled
• Driver support (even though this is also an ongoing battle every time a new Windows edition emerges :)
• "A computer should be pretty" instead of white command text on a black or dark-blue background.
• Is it free? Is it not free? Isn't EVERYTHING in Linux supposed to be free?? What do you mean you write software for Linux and you want me to pay for it?? (seriously, I've seen this one out there...)
• What do you mean "IFCONFIG" <> "ifconfig"?? So what if I've got caps-lock on?

I think there are a lot of expectations of "do it for me" coming into an open-source world from a closed-source world. In the open source world there are a ton of options available to you that you don't see in the closed-source world and frequently it's up to you to wade through them to determine if they're right for your environment. If you're born into the closed-source world this is a bit of an eye-opener.

Solution 2:

I think the biggest problem is mapping common tasks using that I use in Windows to Linux.

In Windows, I can pretty easily figure out what's starting up when the machine comes up. It took a while to find that equivalent in Linux.

In Windows, I can see all the devices and files associated with it's driver. I can easily diagnose problems. In Linux you have to know what you're looking for in /dev or forget it.

Same with understanding drives and partitions. In windows, a hard drive is a hard drive, where in linux, is it a scsi device? IDE?

Setting display settings. xorg.conf, window decorators and changing settings in cde, kde, gnome were all different from Windows, and confusing since each distro is different. Remote displays, display redirection, etc.

dealing with USB devices

User accounts and Security groups. How long before you figured out what the wheel group was?

Kernel modules were a mystery

Solution 3:

Mostly that they are two very different beasts, and that there is no way you can take what you know of Windows and try to map it to Linux/Unix. The same applies in the reverse direction of course: I've seen folks who I would rate as very competent Unix admins having genuine difficulty with Windows. I'd safely enough say that 90% of the problems people have arise from bringing preconceptions from one environment over to the other.

Solution 4:

I'll bite.

1. I expected to find drivers for all of my hardware from the manufacturer's website. This being the case for Windows, I figured it was a legitimate idea for Linux. Not so. Most of the drivers you need are either 3rd-party reverse engineered drivers found on SourceForge, or are already in the kernel. Which leads into:
2. I expected that manufacturer's drivers were going to be better than open-source drivers. Not really. Sometimes they have uses (the nvidia and ati proprietary drivers, for example), but the ratio of good-to-awful drivers is about 50/50 for proprietary, and 85/15 for open-source drivers. Having a distribution that includes a lot of software makes it easier to access such drivers.
3. I thought that everything would "just work" off the bat. In many cases, it did, but I realized that Linux isn't like Windows in that regard. Linux doesn't do anything until you tell it to. This works very well when you're an expert, but it's hampering when you don't know what to tell it.
4. I thought I'd pick it up quickly. I didn't. It took about 3 years of reading, experimenting, and fixing (and sometimes reformatting) until I really got the hang of it. Make sure you have a test server to experiment on, and do don't anything to production until you're sure it works.
5. Read the Rute Guide. It's your friend.

Solution 5:

My biggest issue was coming mostly from the GUI world of Windows and OS X... and thinking I could do what I needed from a GUI in Linux. In this first I try failed miserably. My second try was setting up everything from CLI, and that was actually WAY better. Right now, I still don't think I can do everything I want from the GUI.