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.

Re:the best combo IMHO

[macpeep]

I'm not saying that the Win NT / 2K / XP command line is as powerful as a UNIX one, of course, but:

1) Windows has tab completion. It's just not turned on by default. (Do help cmd from the shell in Win 2K (at least) to get a description of it. You can also configure the completion char to something other than tab..)

2) cat exists, it's called type

3) grep exists, it's called find. If find isn't sufficiently powerful for you, you can always get grep for Windows.

4) piping and redirection works more or less exactly like in UNIX with the same syntax even

Of course all of this stuff isn't as commonly used on Windows as it is in UNIX, but it doesn't mean that it's not there.

Re:the best combo IMHO

[soloport]

Start with the familiar:
1) Install a distro (preferably one that will have the easiest time with the hardware)
2) Configure a windowing environment (prefereably one that looks the most like Windows)
3) Show them an Office suite (preferably one that's comperable to MS-Office)
4) Fire up some awesome games (preferably XPilot ;-) or LBreakout)
5) Start up a variety of browsers (preferable w/ Quicktime, Flash, RealPlayer, XMMS)
6) Configure and use an e-mail client, Jabber/Yahoo/AIM client (Gaim's good)
7) Spend some time on XMMS with various skinns -- and point to http://www.jazzradio.net/ and say, "This is coming from Germany"
8) Show them Palm Pilot support (Jpilot's the best)
9) Show them Quanta's HTML, PHP, SQL, Java and C/C++ syntax coloring
10) Show them a GUI file manager (e.g. Konqueror, et al)

Last, but not least, show them SWAT, Webmin and other easy-to-use administrative tools. You want to leave them with the sense that the Linux environment will be friendly, not ominous.

Let them at least start with some motivation to want to learn more!

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.

A few thoughts.

[mrsam]

Here are a few random suggestions, in no particular order.

* Open a relatively complicated page in MSIE, the same page in Mozilla-win32, and the same page agin in Mozilla-linux. Go to a bunch of annoying web sites, with Mozilla's pop-up/pop-down filters enabled.

* Use ssh to log in to a box halfway across the world. Demonstrate some simple system administration tasks, and the fact that anything you can do at the console you can also do remotely, via ssh.

* Run either Gnome or KDE. Change the themes, a couple of times, demonstrate the customizable UI. Switching between one of the mac Aqua-like themes, some star trek theme, and one of the Winxx-lookalike themes should be very effective.

* Install a distribution in server mode (no X11). Demonstrate the extreme modularization of Linux, such as you can complete get rid of all GUI support, and use only the disk/network services to turn a box into a network appliance.

* Install Windows and Linux on the same box. Boot into Linux; then mount and browse Windows partitions. Make a casual remark that Windows cannot browse Linux partitions in the same way.

* When the Linux box boots up, and is busy going through the initscripts, starting all the services, explain that if one service fails to start for some reason the boot process will continue and the machine should still be mostly usable. Ask if anyone experienced a situation where a Windows driver kept croaking during the boot process, and what happened alter.

I recall an incident about three years ago when UMAX shipped a buggy driver for their scanners. The driver was faulting on machines with USB ports, and CPU speeds over 400 Mhz (something about some timing loop), forcing a complete crash during the Windows boot cycle, with the subsequent reboot falling back into safe mode.

The Linux equivalent for this would be something like SANE, which runs completely in user mode, and therefore cannot crash the entire OS.

* Use samba to browse the local windows network neighborhood.

* If you have a fat pipe, forward X11 over ssh, and run remote X applications on the local terminal.

* Install a base distribution package right out of the box. I'll use Red Hat 7.2 as an example. Apply all the errata to bring the box up to date, except for the kernel, without rebooting. Even install a new version of glibc (the equivalent of msvcxxrt.dll) without rebooting the box. Install a new kernel on the remote machine, make sure that LILO or GRUB is all set up, then remotely reboot the box into the new kernel.

Comment removed

[account_deleted]

Comment removed based on user account deletion

MCSD not MCSE

[Dr. Evil]

Most of the comments I've been reading have been going off about administration and configuration. These are people going for a developer certification. That means they probably already know a lot about programming, and they probably already know a fair bit about programming under Windows.

Going in there and giving them a Linux sales-pitch would be a waste of their time.

Database connectivity sounds like a cool thing to demonstrate, you might want to demonstrate the basic development tools and documentation available at their disposal. Show them an easy editor to use.. something consistent with the editors used in the Windows world, show them gcc and some neat stuff like xxgdb. The ones who are clueful enough to care will pick it up when they leave.

IMHO the most important thing to explain to them is software licensing. It is quick, but when they realize that if they like to develop software, they'll clue in that developing their apps for Linux is easier.

A few tiny things like that would probably take up all the time you have. Cygwin might help them know how to develop apps from Windows to target Linux boxes.

My experience with MCSDs and other Windows developers is that they don't really care about the OS, they just care about writing apps and using OSes to make money by solving problems.

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.