Teaching Linux/Unix Basics to Microsoft Junkies? 570
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.
the best combo IMHO (Score:5, Insightful)
Not to discourage you .... (Score:5, Insightful)
If you're just trying to get them familiar with Unix, nevermind I guess, but I'm just saying that unless you give them tasks / goals instead of just 'showing' them, they really won't see the benefits.
You might also take into account their view on this class. Much like people that have to take a G.E. course in something they have no interest in, they may smile and nod, regurgitate, and retain nothing. Are they here to learn, or because they have to?
Software Installation (Score:5, Insightful)
gone fishin (Score:5, Insightful)
"This is
This is
This is
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
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) (Score:5, Insightful)
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.
show how to start an app from another X-server (Score:2, Insightful)
Re:Dont get carried away (Score:1, Insightful)
Don't be afraid of "the curve." (Score:2, Insightful)
I'd suggest pointing out the local sources of information, "man", "info", the "--help" parameter convention,
Next, describe the "small tools, fitting together like legos" philosophy. Talk about the power of the pipeline, and illustrate shell scripts. Point out that shell scripts are themselves commands in a pipeline.
Describe how things are bug to run. manually, cron, at, inetd, at boot.
Point out the innate networkability of Unix. A lot of the time, one isn't sitting at the console of a box when administering it.
Talk about the source+compile+install procedure -- something that will be pretty foreign to microserfs.
Discuss the packaging system of linux distributions. Show the ease of administration that Debian (e.g.) allows, and the "freeness" of most software, and the license and budget problems that it can save.
Oh, yeah. Teach 'em that "vi" rules over "emacs", too.
Reading (Score:1, Insightful)
http://www.fsf.org/philosophy/right-to-rea
It is a cool little short story that appeared in the Communications of the ACM. It will show them that there are larger issues at stake beyond merely getting their immediate tasks accomplished.
Re:Software Installation (Score:3, Insightful)
'would you like XYZ support?'
'would you like the ABC option?'
where as installing under *nix is a self motivated process, i.e. if you want it, type it into the conf file yourself or pass it in as a param when you make.
the windows culture is one where you wait for the program to point and prod you, whereas under *nix you have to know what you can do before hand and then choose accordingly.
Re:Software Installation (Score:2, Insightful)
Do they know DOS? (Score:3, Insightful)
I'm also assuming they don't need to know how to set up and install a system, just be a user. They should know how to configure their own environments, set environment variables, etc. System stuff should be limited to the software they might be using and managing -- where are the logs and conf files, how to install, and so forth.
Free alternatives to costly software is a great idea. What about a brief discussion of Apache, JavaServer/JSP, Xerces, Xalan, etc? No need to get into the nitty gritty, but let them know there are free, multiplatorm alternatives to everything. My alternative to Visual Studio is Visual SlickEdit [slickedit.com].
Re:Not to discourage you .... (Score:5, Insightful)
Consider offering the course as a two day project where the end goal is to get a web site up and going. Don't get caught up in programming -- focus on using an existing app that needs mysql or other similar database. (It is also a great opportunity to introduce them to OSD and Freshmeat.)
MAKE SURE YOU HAVE A VERY COMPLETE WELL WRITTEN STEP BY STEP GUIDE TO EVERYTHING. Do not assume they know how to login. Do not assume they will know to su before running make install. Do not assume they know that --help is a good way to find out what command line parameters are.
Have a good list of recommended texts for follow-up reading including a good general purpose introductory text. (A good intro sysadmin text for windows converts is Linux Administration: A Beginners Guide, 2nd Ed. I know that a lot of college courses use this.)
As you're going through the course, be sure to include "Hot Tips" or something similar. Little details, tips, and tricks that make what they are doing fun or provide a neat "whiz-bang" feature. It also gives you a good connection to the students since they will feel like you're giving them the real scoop on Linux rather than a pre-canned course.
Do not -- I REPEAT -- Do Not Make Fun of Microsoft. You will discredit yourself if you do. Do not make fun of Microsoft certificate programs (after all, these students are there because of a Microsoft certificate program) and instead encourage them to learn about as many different ways of doings things as possible. Encourage the exploration of different operating systems (MacOS, Unixen, and Windows at the very least).
Finally, when introducing tools, don't give too many options. Show one common way that will work and when appropriate, pick the easiest tool to use. For example, when the time comes to edit a configuration file, don't waste time teaching vi yet. Instead, start with one of the GUI editors that are most like notepad or pico if you're showing how to use the cli. Tell them that there are better and more powerful editors available like vi and emacs and give references to web sites that will tell them more. Offer to answer questions after the class if they are curious about the alternatives.
ALWAYS SHOW PROGRESS. SET MILESTONES. EVERY 1-2 HOUR SECTION SHOULD HAVE A RESULT THAT THEY CAN SHOW TO OTHER PEOPLE.
Save the "advanced topics" for the end like creative use of pipes, cli tricks, and remote logins. (Remote logins will especially throw microsofties for a loop at first because it will be very different for them.)
Make sure you have a security section. This should be first thing in the morning on the second day as they will need to be fresh and have something on their servers worth securing. Try to cover the high level stuff like turning off services they don't need and how to see what services are running. Show them netstat and ssh. A great hot tip section would be to show them nmap. ("It's a hacker's tool. Oooohhhhh!")
Finally, watch their eyes when you talk. Look for people getting lost. Take things slowly, don't talk down to them. Be patient. Expect to answer really dumb questions that will seem completely intuitive to you. Occationally relate stories about when you were learning and how tricky something was. Students love hearing that their teacher had a few mishaps along the way too. It reminds them that the path to becoming a good administrator includes making mistakes.
Best of luck.
Re:Software Installation (Score:5, Insightful)
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.
Start by making a unix/dos command page. (Score:3, Insightful)
DOS Unix
cd cd
md mkdir
rd rmdir or rm- f -f
type cat
more more
attrib chmod
edit vi, pico, emacs
Do this for the filesystem too. initab and rc.d are like autoexec.bat and config.sys. It will be tons easier for them to learn if they already have a foundation to build on.
Re:Don't forget VI (Score:2, Insightful)
Emacs would be better because at least you can type stuff straight in after running it, and it has some menus, and saving files is simple ctrl key stuff. In vi, doing 'i' to start editing, and then wondering why the cursor doesn't wrap around at the end of lines, and then "esc", ":" "w" to save the file is just too much for these people. Vi isn't normal! vilearn is a good tutorial program, but these people are not here to learn Vi. Mention Vi as an editor available on every Unix system, mention that it is complicated, but they can use gvim as an OLE editor within Visual Studio...
Pico is suitable - it is easy to use and has a help system. In a GUI environment, just use gedit or kate or whatnot.
Overall I agree with the people that advocate showing what you can do with a Unix system, not how to do it. Show the development tools available, show the services available, etc. Show differences between Windows and Unix equivalents. Don't be evangelical about Unix, be realistic. Explain that the systems are different, and both have advantages and disadvantages...
I wouldn't bother. Seriously. Here's why. (Score:2, Insightful)
In my opinion, the idea of getting Microsoft junkies to sit down and understand Unix is beyond your typical Microsoft junkie's ability. I'm not trying to sound condescending in that, either. I just think that theres a point where someone gets so entrenched in one way of doing, and one way of thinking, that they lose the ability to "switch gears" and pick up something fundementally different. I'll give you two examples:
There was a guy I worked with named Brad. Brad was an ardent Windows guy. He knew nothing about any other OS'es other than Win32, other than their names. In his mind, Win32 was the pinnacle of operating systems because it simplified complex tasks down to a predictable series of point-and-click operations, and like most Win32 gurus, he had absolutely no idea how anything worked under the hood. He had no idea what a kernel was. Infact, anything below the driver level was completely black box to him. In summary, Brad, even though he knows his stuff, is completely oblivious to the merits and drawbacks of his own platform, because to pursue Win32 know-how as a career path assumes that you enjoy remaining ignorant about certain aspects of the machines youre running. It resembles something more of a religious belief than it does a philosophical belief.
Unix, in its form and in its structure, is the polar opposite of Win32 in regard to how you approach it. You're not only encouraged to grab a shovel and dig deep into the platform, you're required to do so if you expect to gain mastery over it. That being said, Win32 users are unaware of this process. They think in surface-layer terms, whereas Unix people know their systems from the ground up.
What makes matters worse, is Linux, and the idea that the whole damn platform can be looked at, dissected and understood down to the source. While this is an advantage to a Unix guy (since we are used to doing such things) , it presents an insurmountable task to a Win32 user, who's concept of computing often does not extend below the GUI.
Here's another anecdote that illustrates the point i'm trying to make: Where I worked, a bunch of Win32 users were given the task of conducting performance evaluation and testing of RAID arrays under AIX. I appeared to be the only guy in there who had anything more than a extremely cursory knowledge of Unix. After a day or two, I began to wonder why all of the AIX hosts were being rebooted so often. I had a look at all the machines and their uptimes, and discovered that these boxes were being rebooted about once a day. I asked why. They looked like deer caught in the headlights....It turns out that whenever they were trying to remedy a config-related issue, their first instinct was to reboot the damn machine to fix it. To explain the concept of "uptime" would have been futile. To explain the notion that "rebooting is not how you fix a problem in Unix.".
In short, they just plain don't get it, and its doubtful they ever will.
Cheers,
Think MCSD for Linux (Score:1, Insightful)
You've got two tracks to cover here, as I see it.
1) "Free stuff" that makes Linux distros good for developers,
2) Generally free stuff that they wouldn't see as "pure" MCSDs (due to the ties between "Linux" and "free")
For 1), show them stuff that comes with the distro of your choice, like compilers, IDEs, change management tools. Show them MySQL and Postgres, yes. Show them editors.
For 2) Don't forget Java-- Eclipse, JBoss, etc. Don't forget the Mozilla developer aids like Bugzilla. Sourceforge & Freshmeat & Slashdot.
Finally, the MCSD has this development process framework called "MSF." Show these guys something fun like Extreme Programming.
TTFN
Comment removed (Score:5, Insightful)
Show them the dev environment (Score:3, Insightful)
Forget about MySQL. It's a nice DB but can't really compare to Oracle or SQL Server.
My final tip: Don't try to convert them or bash MS solutions, that would only alienate them. Just show how to get the work done in unix, and maybe they'll realize it's easier and develop further interest.
More Ideas tailored for Micro-weenies.. (Score:2, Insightful)
2. Push remote access, like ssh, which gives a user full control of the box from remote, something that is difficult to do in NT w/o consuming many resources (TB2,etc)
3. SAMBA. Install Samba from the cd and show how they can manage and use their (precious) Network Neighborhood stuff, connect to remote computers, etc.
4. Routing. Show how any linux box can setup firewalls and complex routing with a few commands.
5. Security. Run nmap against your now-configured linux box and compare it to, say, a windows 98 box. Show that linux can be locked down for the miscellaneous user.
6. Support.
Maybe not everything can be covered in two days, but hopefully this helps. I was once a M$ kinda idjit, but the above points, as well as many other good suggestions already discussed in this thread, helped me to kick the GUI.
Not your typical post from,
First thing to teach (Score:2, Insightful)
Microsoft "Junkie" (Score:2, Insightful)
Unless you can show them a good graphical replacement for Windows as the UI, I would focus on using the alternatives on the back-end only. Despite the reputation VB has around here, it does have it's proper place. Many people who work with VB (like myself), aren't necessarily "Microsoft Junkies", as you say, but ordinary programmers who need to make a living, and don't particularly care what they're working with, so long as they're programming. In this case, it comes down to what the customers want. Until Linux is on the desktop, the customers will keep demanding Windows, so it wouldn't do much good to try to convince these programmers to use Linux for the interface.
Focusing on the back-end, I would show them how they can connect their VB applications to the database, and focus on that connection. Once the connection is made, they know what to do with it. If you can show them how easy it is to use, they can bring this knowledge back to their bosses. This will impress their bosses, because they can essentially give their customers what they want at a lower price, due to MSSQL being out of the picture.
But guaranteed, if they take ideas of using Linux for an interface instead of Windows back to their bosses, it'll get tossed out the window. Believe me, I know - I've tried it before. At least doing this, you can win one battle at a time - first the database backend, and then the front-end at a later date.
The point is to teach (Score:3, Insightful)
IF you are ever in a situation where you are teaching a class on Linux don't be cocky, condescending or anything like that and don't try to turn it into some kind of wizbang tradeshow. Teach people the basic things they need to know, how to navigate the CLI, how to work RPMs, how to manage users, how to look at what's running and so on. Give them real knowledge they can use. IF you do that, you make Linux less sacry and forieng and maybe they start to use it. IF you act as you've suggested all you are going to do is reenforce the stereo type of *nix people as stuck up assholes that hate Windows for no good reason.
Teach, don't preach. It's a class, not a chruch.
Re:A few thoughts. (Score:3, Insightful)
No, not with the Windows telnet server it isn't. By default it's set to use only NTLM authentication, which is encrypted. You can set it to accept plaintext as well but that's not the default.
Re:Not to discourage you .... (Score:1, Insightful)
/bin,
Same for lib and modules
Re:gone fishin (Score:2, Insightful)
Prepare a cheat sheet of commands for them, showing the Windows and the Linux version (e.g. cp and copy, rm and del, etc.).
Check out a very intro book ("Linux for Dummies"?) just to see some of the topics it might cover.
"Think Unix" is a great book for teaching the how and _why_ of the command line.
Try to come up with some things that they might want to do under Windows that would be hard to do but easy to do under Linux. Use that example to show commands and pipes. For example - "tell me how many machines accessed this webpage last month". Maybe that's easy to do under Windows, I don't know. But show how you'd do it under Linux, with a pipeline of cat, cut, sort, uniq, and wc. That might be a complex example (for a simple question!) but it shows the power of the command line.
Most of all, make it fun. Show them what's cool. Show them that they can do the same things under Linux that they can do under Windows. Like playing MP3s, videos, reading Office documents, running Word (with Wine), and even playing Solitaire and Minesweeper!
randy
philosophy (Score:5, Insightful)
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.
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.
Checkmark compatibility (Score:4, Insightful)
Sure, DOS has had scripting and pipes from day one (well, unless you tried MSDOS 1.0). Were they as useful as their Linux counterparts? No freakin' way.
Why does TYPE not take stdin? Why is "copy con" equivalent to "copy con:"? (And, why is "copy con.txt" ambiguous?)
How can a batch file determine if a directory exists? Hint:
if exists c:\foo\con
yields different results in different DOS versions
DOS for the longest time failed the basic tests. And for the longest time, I was working with the MKS toolkit, replacing the ones that didn't quite do what I wanted them to do with copies ported from comp.sources. But it never became UNIX.
NT is still rife with inconsistencies in the CMD shell, and I don't know (nor care to know) if or when they get partially fixed.
The point is: if you want to use Windows, use Windows tools. Learn how to use VB Script to its effect. Learn MSVC if you must. Prentending that it's another UNIX if you squint right will hurt you. Windows is not designed to be UNIX.
Every time I use Windows on the premise that an OS is an OS and a command shell is a command shell I get hurt. I should have learned that lesson from VMS years before.
Does anyone knows if the Posix subsystem still exists in Windows XP? That was the worst checkmark compatibility I ever saw. You could run Posix code on NT, to allow NT to be purchased by the federal government. And unless you wanted to do actual work with it, the compatibility was fine.
It is completely beyond me why people are porting Apache to Windows. NT comes with a perfectly functional web server, why bother replacing it? Don't get me wrong, I hate IIS with a vengeance, but the loopholes in the underlying operating system (like the $::DATA bug) will have to be special cased in Apache too. And the $DEITY like privilege issues that plague the IIS indexing server will plague Apache just as well.
Possibly even worse, because code ported from UNIX will have to be modified to suit NT's security model, a redesign from scratch really is the only appropriate way to deal with such huge gaps in design philosophy.
Comment removed (Score:3, Insightful)
You must teach the roots of Unix (Score:2, Insightful)
If you just focus on standards and deamons you only show them several single aspects of a unix system without showing them the unix system itself. When they are on the way to an MSCD they already have a vision of an OS and how it should work. you can't fight against that with some standards here and some deamons there. They must learn why unix samples all functionality in a virtual tree and why it bases on tools. This helps them to understand why Samba is not just a clone of a Windows Strategy and why the Filesystem Hierarchy is not just complex but functional etc.
Don't forget the glue, and that is the unix philosophy. It gives the audience the information they need to stay away from prejudices and to find correct answers and assumptions on their own thinking.