Teaching Linux/Unix Basics to Microsoft Junkies?

flupps asks: "I've been asked to hold a two-day crash course in a class of students that currently are studying to become MCSD certified. I'm looking for ideas how to set this up. I was thinking about starting with some general file system descriptions, where to find what files, the man pages, the tab-button, etc. After that move on to some of the daemons and just explain what they do." He's got at least one idea to start with (below), but what must-have skills or demonstrations would you add?

I also plan to set a database program in VB (one of the certificates in the MCSD suite) against a MySQL or Postresql db and show that there are free alternatives that works as well as SQL server.

What would you think could be a good addition to teach them?

This is in no way meant to be a very advanced course, but I want to show some of the excellence of *nix and why you sometimes can save time and stability and maybe make them interested and read up more by themselves afterwards.

Any suggestions very welcome.

Comments

the best combo IMHO

[Gavitron_zero]

is teaching cat | grep . I don't think I use any command combo more than this other than ls -al. Piping and redirection is really important stuff for Microphiles to learn right away. It's a great way to show off the power of a CLI.

Software Installation

[Apreche]

Make sure you teach them how to compile and install software. When I first learned *nix I learned how to navigate the file system, run things, edit files, move things around, etc. But it took me like a week to figure out how to install and set up new software. I remember having the hardest time with it because every single piece of software was different. There was no standard setup.exe or *.rpm all the time. I had to make, make install. And that didn't always work either. That, imho is one of the major differences and difficulties there is in moving from windows to *nix. In windows once you've installed one piece of software you've installed them all.

Re:Software Installation

[mickwd]

Sorry, but I can't agree about compiling stuff for a basic *introductory* course.

Firstly, it'll scare them, and secondly, all that most people will remember is that they HAD to compile stuff to get the operating system to work. Management in their place will get to hear about it, and this impression about Linux will stick.

For a basic course, yes, you could show them how simple it is to install, say, RPM packages (or deb equivalents, I guess) - and how to remove them (often a messy experience on windows). Show them that the compilation is often already done for them. You could even show them "rpm -ql" and "rpm -q --scripts" to show them that they can find out *exactly* what will happen when they install and remove stuff (and without reboots, too).

Show them KDE (maybe even KDE3.0). You might not agree with me that it's currently the best Linux GUI environment, but it is the most like Windows. Want to show them 'man' pages ? Show them man:/command_name in konqueror. Show them the big things that are good about KDE, and also the little things that are good about KDE (e.g. middle-button clicks on scrollbar regions to move the scrollbar there in one operation).

Show them how to cut-and-paste using the mouse. It's different to how it's done in windows, it works between KDE and Gnome apps, and it will stop them thinking they can't cut and paste in Linux. Show them there are other editors than 'vi' and 'emacs' - editors beginners can use easily.

Show them the command line, that's very important, but don't go overboard - don't reinforce their views that the command line is too difficult. Show them some simple, powerful stuff. Stuff like 'grep', 'ls', piping commands together... Think of examples that are simple on Linux/Unix, but very difficult to do on Windows.

Don't give them too much unnecessary info about how daemons work, where config files live, etc, etc. This is an *introductory* course. Just let them be assured that it all works. Get them enthusiastic. If they are, they'll get hold of copies for themselves, and start finding out more for themselves - but you have to build that enthusiasm, put their fears to rest, and show them things they can do more easily (or better) in Linux than in Windows.

gone fishin

[yack0]

instead of doing like MCSE and giving them fish, teach them how to fish.

"This is /etc - it's where most of the config files are.
This is /usr/bin - it's where most user programs live
This is /usr/sbin - it's where most superuser programs live

If you're interested in using a command and don't know how, use 'man command' and get them familiar with how to use commands. "

You've got two days - so some basic 'how to get info' and then examples of getting that info, would be good.

Possibly a run down of 'in Microsoft, you have IIS, in Unix there's apache, ftp, etc'. 'In MSFT, you have ipconfig /all - in unix we have ifconfig' some basic translations of basic stuff.

How about running through the 'Administrative tools/Common' menu in 2000 and showing them where all those toys live in *nix - or where they might be able to find them.

But make sure you teach them how to fish for themselves - I suppose MSFT has the help pages, but man pages are our best equivalent. Or homepages for the package in question where applicable.

Good luck!

Keep it simple (and don't oversell mysql)

[mgkimsal2]

I also plan to set a database program in VB (one of the certificates in the MCSD suite) against a MySQL or Postresql db and show that there are free alternatives that works as well as SQL server.

I would qualify that - you'll probably have at least one person in the group who's up on MySQL and/or PostgreSQL deficiencies (yes, they have them). Don't try to convince them that MySQL can be a drop-in replacement for SQL Server 2000. Both MySQL and PostgreSQL *can* be used in many situations, and should be considered along with other options re: price/performance, but don't go overboard and talk down to MS people saying MySQL is as good as (or better) than SQL Server. It does a disservice to everyone involved.

Covering RPMs and/or apt-get technology might be useful at the end of 2 day overview.

What would help more than anything else is showing people where/how to get help - online resources (RPMfind, for example) and whatnot. There's only so much you can cram in to two days - don't overdo it. Cover the basics in detail, and give resources to visit afterwards for people who want to learn more and/or experiment.

Comment removed

[account_deleted]

Comment removed based on user account deletion

philosophy

[martinflack]

You need to back up and do something more fundamental before you start showing them filesystems and daemons. You need to compare the two competing philosophies that drive Windows and Unix cultures.

Windows is a goal-orientated, large application model that strives to make normal tasks very easy. Broadly speaking, Windows admins generally respect order, simplicity, and navigability. Everything gives feedback, to a fault. Everything is an object you can click on. Data is encapsulated and handled by expert applications. Application designers make lots of decisions. All problems are handled by rebooting or reinstallnig.

Unix is a tool-oriented, small programs working together model that strives to make all tasks doable. Broadly speaking, Unix admins generally respect extensibility, configurability, and stability. No news is good news, to a fault. Everything is a file. Data is transparent. End-users and admins make lots of decisions. All problems are handled by reading logs, diagnosing, and making small changes.

After this balancing act, then you can begin to lead them down your path of showing them practical items. At each point you can refer back to these fundamentals. For example, when it /etc, you can explain why Unix admins think text file configuration is inherently more stable and powerful than registry keys, because without such an explanation the Windows admins will typically see it as quaint and backward. Again, when you get to /dev, you can show the inherent debugging power of being able to do things like "tail /dev/midi00" to debug a connector on the computer, even if that data is not useful immediately. You can show how grep, awk, and perl can be chained together to do advanced data processing (on text) that would not be possible on Windows without a specific feature to make it happen. The key is to refer back to a specific philosophy for each exercise, so they can see the big picture.

None of them will watch a hands-on lecture and run out screaming "I've got to convert to this immediately! He broke out this thing called grep and it was.... it was.... AMAZING!" :-) Rather, you want to give them a clear understading of our culture, and just like how a high school senior goes to a college campus and says, "Yeah, I can see myself here" you might kindle an interest in some of them to find out more about how we *nix people think.... and that would be the first step to bringing them over.