Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Linux Software

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.

This discussion has been archived. No new comments can be posted.

Teaching Linux/Unix Basics to Microsoft Junkies?

Comments Filter:
  • by Gavitron_zero ( 544106 ) on Sunday April 14, 2002 @02:51PM (#3339555)
    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.
    • Powerful, true, but on the other hand most of the power comes from regexp syntax that might be a little off-putting to someone who's never seen that before.

      • by soloport ( 312487 ) on Sunday April 14, 2002 @05:43PM (#3340243) Homepage
        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 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!
    • by macpeep ( 36699 ) on Sunday April 14, 2002 @03:43PM (#3339757)
      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.
      • by weave ( 48069 )
        This is all true but a lot of useful information isn't available easily from the CLI without hunting down additional tools from resource kits or learning some scripting languages and all the COM interfaces or whatever it is called.

        For example, I had a devil of a time figuring out how to do something simple like "quota username" to see how much quota someone is using without right-clicking the drive, picking quota tab, waiting to resolve 15,000 SIDs so I could find the username I was looking for. There is a perl script in the resource kit, but it runs forever (I stopped it in frustration after 15 minutes) since I assume it's trying to resolve SID to usernames and our NT domain controller has 15,000 accounts... (the server in question was a w2k member server, of a NT 4 domain).

        But to get back to topic, I don't understand why. It's not easy moving from unix sys admin to windows or visa-versa. That's mainly why each camp hates the other platform. I'm more comfortable with UNIX admin, and I'm sure if I had the time to invest in learning Windows admin, I could easily throw the needed scripts together to get what I need out of the box.

        Two days isn't going to cut it. Just go over basics in philosophy and try to avoid platform wars..

      • BTW:

        * In XP, tab completion is on by default.
        * There's also a built-in utility called findstr, which offers many options that find does not.
      • by driehuis ( 138692 ) on Sunday April 14, 2002 @09:56PM (#3341164)
        Use the right tool for the right platform.

        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.
    • Don't forget sed and awk!!! the cat, grep, sed, awk combo can do anything! Well quite a lot anyway.
  • by ciryon ( 218518 )
    No, you don't need to reboot after....[insert any task here]
  • man pages (Score:5, Informative)

    by Arctic Fox ( 105204 ) on Sunday April 14, 2002 @02:52PM (#3339564) Homepage Journal
    Show them how to use man pages (or what they are), appropos, etc....
    man heir is a good start for disk structure. (if you're on a BSD, i'm not sure Linux distros have that.
    /etc files should be covered... /etc/fstab etc...
    Explain the Unix philosophy, with small apps doing one thing well, and how they can be glued together to do complicated things.
  • by DrPascal ( 185005 ) on Sunday April 14, 2002 @02:53PM (#3339568) Homepage
    But as someone that has migrated a Windows 2000 Advanced Server box to Linux, I can say that the best way these guys can learn is to just USE it out of necessity. I had played with Linux quite a few times, and it wasn't until I actually had a goal/list of things I actually had to configure that I really learned what was going on.

    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?
    • 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?

      Very good advice. I'd steer clear of the love or hate it dichotomy, though. Almost everyone can learn something of utility from what you're teaching (if nothing else, explaining the mail daemons will help them understand how their email works) and knowing their agenda will help you decide what a paritcular student might be excited by.

    • by xanthan ( 83225 ) on Sunday April 14, 2002 @03:53PM (#3339788)
      As someone who has to frequently teach content networking concepts to salesfolk, I cannot express the need to be goal oriented enough. Going through the filesystem and saying "here's this and there is that" is nice, but unless you can show (because they won't necessarily "see") an immediate use, what you've just taught will be useless.

      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.


      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.
      • As an off and on newbie (depending on the area), I can tell you that the hardest thing I had to learn on my first anti-Microsoft migration attempt was simply WHERE things are.

        I didn't learn until well after I needed it that /var was for things of variable size, like logs and databases and whatnot, or that /etc was for configuration files, etc.

        Teach the basics as you're teaching the less than basics... if you go into /home, let them know what they should expect to find in it... what kind of data, what kind of programs, what kind of configuration files, etc.

        Other than that, the above post seemed to be righteously accurate.

        • Make sure they understand the file system structure. First thing. Teach them soft links. Teach them mounting. Show them that *NIX doesn't have drive letters, everything is a file.
          Show them that they can mount remote filesystems and cd to them like a regular directory. I've noticed that that amazes UNIX newbies more than most other things. Show them about their "user space" the home directory and how their files can be protected from other peering eyes (permissions are a little advanced, but that'll help them to undertsand the security aspect of unixen)
    • That's true of just about anything. But I've taught the "token Unix course" to MCSE/MCSD students many times and most of them just aren't ready to jump in.

      The sad truth is that most of them will end up as help desk jockeys or operators and stay there for the duration of their IT carreers.

      The key to success is to hold their hands while they do some task that they think is useful. Setting up a file server for MCSE types or building a simple PHP application for MCSD types.

      Everybody knows that they won't know enough to be really be useful on their own once they leave - especially if it's just a two day course. But the ones who really are destined to be developers will have gotten enough of a taste that they can learn for real once they're free of the classroom. The others will at least learn that Unix exists and is used widely - something they won't learn from their other classes.

  • by Anonymous Coward
    Coolness factor:
    This is how you win 'em over. No x, not even texty vi or emacs. Nothin' but BASH.
    Just sit there and do routine things moving thousands of files around your filesystem, starting a few web server processes, just random unixy stuff that it would take several hours to get done on Windows. I know windows junkies: they're always typing "cmd.exe" and acting cool about having a "tail" to look at logfiles.
    Show them a thing or two.
    Keep talking throughout.
    And convince them that they're nothing.
    At the end, mention:
    "By the way, I didn't do all this locally. I'm logged in at a server I manage over in Canada. Check out the uptime". What? Longer than Windows 2000 has been out? (Nevermind that it's at Service Pack 2 already, and without that, your security's hosed).
    Watch an evil, broad grin work its way across their faces.
    • Although I think the sadistic tone of your post is very funny, it's realistically a bad angle.

      One thing that Windows based users think of Linux users is that they are pretentious and cocky when it comes to using computers ... quite frankly, because that is how the [insert most appropriate word like "majority" here] of them are.

      By zooming around and doing the amazing things one can do in Bash (I am a big fan), you simply alienate them, and push them away. It almost says to them "ha, ha, you CAN'T DO this." That's poor teaching. The message you want to convey is "You can do this too, and it's not too tough."

      Another angle (!): Ever tried installing Cygwin/SSH on a Windows 2000 box? I have it running on a machine or two, and if you have the HOME set to /Documents And Settings/$USER, it really makes remote access beautiful. Maybe you can have them try this as well, and it might be a stepping stone.
  • show that there are free alternatives that works as well as SQL server.

    Ive used all three databases you mention. Without a doubt, SQL Server is by far the "best" database. I think you do have to temper what you say, because if you run around making statements like that, then it puts doubt on the other things you say.

    I dont mean to cast dispersions on MySQL or PostreSQL, they are very good databases, but not in the same league as SQLServer, IMHO.

    • I dont mean to cast dispersions on MySQL or PostreSQL, they are very good databases, but not in the same league as SQLServer, IMHO.

      I'm also interested in hearing why you think Microsoft SQL Server is better than PostgreSQL. I've used PostgreSQL and Oracle and feel that PostgreSQL is as good or better in many situations. I'd be surprised if MS SQL Server had any real advantages over Oracle (except price, and it can't compete with PostgreSQL there).

      Oracle's two big advantages, as I see them, are:

      • Large database features. There are a million features that contribute to this. Manufactured views, clustering, different tablespaces, quotas, replication, etc.
      • Extra software. Stuff like Oracle Forms & Reports is really great for rapid development. I haven't seen anything cross-database or PostgreSQL-specific that can match that at all.

      On the other hand, PostgreSQL has:

      • Ease of administration. Oracle administration seems really, really complicated, even when you don't use any of those extra features. [*] PostgreSQL is very simple to set up correctly and keep running correctly. In my experience, keeping a database healthy is little more than doing a vacuum analyze in a cron job or something.
      • Lower cost. You can get the database free, with volunteer support from the mailing lists. If you want paid support, you can buy it as the RedHat Database, still with a much lower cost than Oracle.
      • Open source. I don't think I need to say here why this is good.

      Now, MySQL...I don't understand why you'd use it when PostgreSQL is available. I certainly won't take quite as seriously anyone who advocates using it. It's not even a relational database, by definition. See Codd's Rule #10 [], for example. (I don't think any database supports all of these rules perfectly, but MySQL in particular is quite sad.)

      [*] - I don't actually administer an Oracle database. I just use one and try to have some understanding of how its administration is done.

  • by Apreche ( 239272 ) on Sunday April 14, 2002 @02:55PM (#3339581) Homepage Journal
    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.
    • yes, this and configuring software before and after you install it. i remember one of my hardest hurdles to get over was that windows had gotten me used to the installer always asking me questions.
      '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.
    • I would agree with the above 100%, and would also suggest you highlight the Windows Registry vs. Unix-style configuration through the liberal use of configuration files. As a VB developer (I know, haha) who develops and delivers a heck of a lot of applications, the WORST part of Windows is by far the interdependency of DLL's and OCX's and the obfuscation and/or complexity of their configuration. Make sure you clearly illustrate the open nature of Unix's insides, and drive home the fact that low-level configuration results in maximum control, and therefore, maximum ability to identify and correct problems when they do occur. Any VB developer knows the horrors of the old 'DLL Hell', and will FULLY appreciate this.
    • by mickwd ( 196449 ) on Sunday April 14, 2002 @03:56PM (#3339791)
      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.
    • Likewise, make sure you teach them how to use the package management system properly. Make sure they know that downloading and compiling stuff is usually wrong; most Windows people I know will attempt to do this, because it best fits the pattern they know for installing "freeware" (Winamp, etc.), when they should have just typed "apt-get install xmms" or "urpmi xmms".
  • gone fishin (Score:5, Insightful)

    by yack0 ( 2832 ) <keimel@gm a i l . com> on Sunday April 14, 2002 @02:55PM (#3339583) Homepage
    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!

    • I love yack0's suggestion. I would add this: if these people are MS junkies, you might have to teach them very basic UNIX skills: ls, rm, cd, more, less, pico, etc. Believe me when I tell you that you'll have at least one student who doesn't have even this level of skill.

      Since this is a crash course, you can probably get away with giving them a short cheat sheet and recommending that they get their hands on a copy of Linux in a Nutshell. But don't forget to incorporate at least something about UNIX basics into the course.

  • by lizrd ( 69275 ) <{su.pmub} {ta} {mada}> on Sunday April 14, 2002 @02:55PM (#3339584) Homepage
    where to find ... the tab-button, etc.

    If they can't manage that on their own, there's no hope at all.

    In a more serious note, I'd try to focus on the similaraties between cmd.exe syntax and bash/sh syntax and possibly get a bit into basic shell programming.

  • Set up tomcat /w SOAP [], and show a simple VB app or ASP page interacting with a "hello world" SOAP call. Real world, simple setup, shows the potential to mix environments...
  • by mgkimsal2 ( 200677 ) on Sunday April 14, 2002 @02:59PM (#3339600) Homepage
    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.
  • SSH/X-forwarding (Score:3, Interesting)

    by OblongPlatypus ( 233746 ) on Sunday April 14, 2002 @03:00PM (#3339604)
    Just show them the beauty of ssh and X-forwarding. It never fails to impress my Win/Mac-using friends when I run the latest version of our Java project application directly from the unix server at school.
  • One of the first things I found cool on UNIX was being able to start Netscape on one machine and have the screen displayed on another. And explain that this IS NOT Netop, PCAnywhere or VNC or another 3rd-party tool, but a natural part of X. X was DESIGNED to do this whereas Widows (Windows) needs a thirdparty-tool to do a much a technically less advanced screencapture.
  • I'd simply show them the Unix stuff that is cross platform. Start off with things such as Apache or even PHP.

    More than likely, if they are going for their MCSE cert, they will be running Wind'rs no matter what you tell them, but showing them these cross platform apps might be the seed to slowly merge them to other platforms. For instance, I run both Apache and PHP on most of my servers...I run them on Wind'rs, MacOS X, Unix. They are VERY stable across platforms. I still run IIS5.0 on one machine, but thats because I have clients that NEED ASP. I use to develop against ASP, but now use PHP on everything because I never know what platform I'm going to be running on.

    After that -- because everyone needs to know how to set up a web server -- grab the Posix Tools from Cygwin (??? I think thats where I get them...I just google everytime) and install them on Windows. You get all the nice commands that ya do on unix, but on Windows. Its VERY nice because Windows doesn't come with a very good Kill command (there is one on the Resource Disc...but I prefer these ones better)...sometimes you REALLY need a service to quit and their is no other way.

    Start showing folks these xplatform tools and show them how they only need to memorize one set of instructions instead of a dozen that do the same things across a dozen platforms (the CLI stuff on Windows isn't the same even across their different platforms...they change the names of apps too readily). How do you get to a Command Line on Windows? Is is CMD? Is it Dosprmpt? Depends on the version. Things like this.

    I install the cross platform tools so people can be familiar with the Unix stuff...hell I've got my boys so brainwashed that when I ask them to hit one of my unix boxes, they now tell me its 'just like windows'. Once you can safely work around a machine without having to stumble, you then feel a little braver and may actually explore a bit. Maybe then they figure out why a Unix box is so much nicer and more stable than the same PC...

    • I find myself typing cmd.exe on my Windows 98 boxes at school and my mom's computer when I am trying to do stuff.

      She has a tendancy to get utterly confused at the reason I seem to do everything with the keyboard...she said she's almost never seen me use a mouse. Quick use of Winkey shortcuts, TAB combos, and the command line almost totally make it unnecessary.
  • The learning curve is daunting to newbies, so show them that a Unix command line is not something to be afraid of. How?

    I'd suggest pointing out the local sources of information, "man", "info", the "--help" parameter convention, /usr/share/doc/*, the packaging system (in that order). That's to show that the blinking cursor of a shell is a possible place to start looking for help, in the same way that immersion in a foreign language is the best way to learn it.

    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. :)
  • A few thoughts. (Score:5, Interesting)

    by mrsam ( 12205 ) on Sunday April 14, 2002 @03:13PM (#3339644) Homepage
    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.
    • Re:A few thoughts. (Score:2, Interesting)

      by graf0z ( 464763 )
      I have to give 2d apache/linux crash-courses regularly to admins, which are mostly MS-only with none up to medium network knowledge (yes, they are admins in their companies ...). Most of the suggestions of mr sam work, espacillay the ssh stuff, but they have to do it on their own! If they manage to do all these nice gimmicks, you got them! So: show them what you want to show and then let them do the same (but free choice of details like pathnames and such). So let admins...

      • install a linux distri on their own (i use RH)

      • edit "index.html", start preinstalled apache and ask their neighbor how do you like my new homepage?(this is the second point after installing, just to impress)

      • set up useraccouts, start sshd and then change places for going on administrating their boxes remotely

      You get the idea ... there should be similar tasks for coders. But a warning: they will get it slowly. The command line (you will do all the importing things only in bash, don't you?) is absolutely new to them, so you will have to explain over and over again (ext2, absolute/relative path (although it is the same in win)). emacs/vi it definitely necessary, but it's a showstopper.

      Another thing: Some facts you can tell them over and over again like "do not use telnet, it's fucking unsafe, use ssh", but if you do not demonstrate it or let them explore it, they won't understand the importance. So proof your statement using tcpdump (they will love it!).

      • emacs/vi it definitely necessary, but it's a showstopper.

        Simple solution - do what I did for my father. Install nano (an open-source pico clone). It's relatively easy to use (very similar to the 'edit' program that came with the later DOS's).

        This way the users learn how the system functions with respect to the scripts, and after they're hooked, get them on vi/emacs. If they're not hooked, then there's no reason to learn vi/emacs anyway.

    • Not to try and make it a Linux tradeshow. If I go to a Linux class and all they do is try to show off the nifty things Linux does without teaching me anything I want to know, I'm going to wlka out and get a refund. The point of teaching a class is just that, to teach. It's not for advocacy or verbal masturbation. What's more you are likely to alienate the very people you hope to educate. When you act like a condecending jerk and crow on about how superior your OS is, it just makes people shut down. More, if you get someone who's knowledgable about both systems, they are going to call you to carpet on the fact that Windows can and does do most of what you are selling as Linux only features like SSH for remote administraton. For example: not only can you install an SSH server in Windows if you like but Windows XP comes with a built in remote administration feature.

      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.
  • You can do it through anecdotes, or just regular asides, but I believe it is invaluable to divulge them a set of ubiquitous linux/unix principles.

    • I don't mean to list many, because I guess they're obvious, but some important ones are
    • **The functionally in unix is partially hidden functionality.. this means that a lot of times a program can do lots of things you want it to, but it simply isn't apparent like it is in windows. In windows a lot of the workings most people want are very accessible on the surface (though note that if you want it to do something uncustomary... then you're in a pit!), though in unix you usually have to dig some. This is a bad example, but yesterday I was writing some SNMP code using the excellent net-snmp (ucd-snmp) packages, and needed it done now, so to learn some variable structures exactly I used headers and gdb to dump some exact var info.. that's a linux way.

      many windows people when approached with linux view features they don't see as features that don't exist.
    • files. It's all files. devices, filesystems, directories (nothing unusual there), named pipes, etc. Maybe show off some fun stuff (like you can use mount [device] to mount a CD image file and use it is if you'd mounted a CD. showing off this type of stuff would make this concept stick I feel (and reiterate =))
    • Flexibility. different UIs are a nice way to show this easily
    • Make sure to nail some FUD too.
  • After you teach them the basics (navigating the filesystem, creating/editing/moving files) you should teach them the thing that takes most newbies a month to figure out (I mean really figure out) on their own. Compiling software. Now, this is not a small topic, it's a big one. If they wanted to install kdelibs from source, they would need qt, libxlst, libxml2, but they wouldn't know it.

    The best thing you can do for a newbie is teach them how to find what they need to find to install or compile all the software they want. Start off with something simple like an Apache/PHP w/MySQL setup.

    Give them the three tarballs (and they should know how to open them after the basics) and tell them to try to compile the three pieces of software together. With some tutoring they'll end up having something, more or less, working (hopefully) by reading README files and the INSTALL files after you've told them they use the configure script to start the ball rolling.

    If they run into a rut, then you help them. Once they do get everything compiled together, get them on the path of figuring out how to install MySQL into /opt/mysql and apache in /services/www. This will have them reconfiguring and learning how all the flags work.

    Finally, get them to install something that will rock their brains a bit. Once they realize that they're having a hard time, tell them where they can go to get libs, dependancies, etc. (freshmeat, rpmfind, etc.). Navigating the box is one thing, but knowing how to install software makes all the online docs suddenly make sense. Anyone have any comments about this approach?

  • An excellent book (Score:4, Interesting)

    by SpookComix ( 113948 ) <> on Sunday April 14, 2002 @03:17PM (#3339661) Homepage Journal
    I was born and raised in Microsoft land (MCSE since 1999), and although I've been playing with Linux for several years out of curiosity, I didn't get serious about it until a year ago. I've seen hundreds of books on Linux, and own several myself, but the one I recommend hands down over all the rest, especially in your case, is "Linux Administration: A Beginner's Guide" by Steve Shah. [] It's written specifically with your kind of users in mind. From the blurb:

    Steve Shah writes to the millions of people who are familiar with Windows (and perhaps NT and/or 2000) but not with *nix. (He's even provided a 16-page blueprint section comparing how to perform common tasks in Linux and Windows 2000.)

    It helped me over the hump when I became serious about learning Linux, and I use it as a resource still today. Even if you don't use it as a guide for your class, I'd highly recommend that you mention it to your students.


    • Another interesting book: Sam's Teach Yourself Unix in 10 Minutes. It's a very short, reference-oriented book that's physically little and easy to carry, and it's a lovely introduction to the shell, redirection and I/O paths, permissions, navigating the file system and the network, etc. -- a kind of "Unix Users' 101" if you will.

      I have no financial interest in promoting the book since I didn't write it, but I was an editor for the book and found it to be lean and concise and still recommend it to this day.
  • These people may only know about Windows and Microsoft solutions. If so, you'd better give real world examples of what is done with Unix now.

    Unix is used because it scales well and is rock solid. With Linux you also get the price advantage, though that isn't so important in big projects. Quality and stability are and you should be able to show that Unix is high quality.

    For a MS-only person it's important to be able to use Unix only in some places. Samba is a great example. Same goes with Apache. They might also like the possibility of producing cross platform solutions. Kylix/Delphi is a great example here.

    Don't get into any religious fights. Just tell/show places where Unix is a great solution but do it without bashing Microsoft.

  • Speaking as someone who routinely uses, and actively advocates the use of, both Windows and Linux together, I have several suggestions:

    First, don't make excuses for Linux's weaknesses. You may have students who criticize, quite rightly, the current Linux desktop. Rather than defend it, accept the criticism and move on. You don't want your students to make their conclusions about Linux based on how it looks on the surface.

    Second, as you're planning with database services, show them the benefits of Samba and Apache. If any of your students are responsible for admining servers they should be able to relate to these services as well. One point of caution though: They'll be used to using GUI's to administer services and may be turned off by the idea of editing text configurations. I have explained, with great success, that good text configs don't obfuscate your options. Sometimes the most powerful options are buried in GUI's. In a text file, the option you want is just '/option' away.

    Lastly, and most importantly, your students will need to know where to get help in the future. Some like to read books, so introduce them to O'Rielly's animal farm (as I like to call it). There's also web and IRC locations support options. Remember that the Linux community has won awards for support, so you want to play that up. Linux support is one of those free things where you actually get more than you paid for. Be sure, however, to advise on where to ask what level of question. Newbie questions often get ridiculed on IRC, for example.

    Good luck with your class. I would suggest that once you've put together your materials, you may want to submit a follow-up story. Perhaps you'll plant the seed for a class LUG's can offer all over.
  • Teach them about the difference between directory entries and inodes (hard links, files disappearing only after close) and show them how this allows one to replace files in use without reboot.

    Second, teach them about symbolic links and how this makes it possible to separate logical from physical file locations.

    Third, show them how to do tasks with shell pipelines (don't forget to explain that file globbing is done by the shell rather that by each command).

    Finally, show them that there is complete documentation for everything.

  • Being an MCSD student, I think you need to focus on what can be done with Linux systems and services, not how to do it. To me personally something isn't interesting to learn unless I have a use for it. While ls, grep and cat sure are useful, they don't tell me anything of what I can do with them or why I'd even want to learn a bunch of new commands on a new OS just to run some obscure a-patchy-webserver. Show them how MySQL works, show them how Apache with PHP works. Show them what they can do with a Linux box and when they might find it useful to install one instead of an expensive windows server.

    So show not just how to grep, cat and ls, but give them enough info about what they can do with a Linux box so they might feel tempted to try it on their own. Go through the common services they might come across and what they can do and briefly explain the normal Linux commands as you use them.

  • I've turned a Pro-microsoft Unix Basher around to the point at which they came to me and asked me to setup a *nix lab for them.
    It was my Partner at my volunteer job thingy at school. I am the co-director of the CNE High school Tech Dept. There is me, and my partner, Rob. Rob lies, rob lies alot. At the beginning of the year, he had me convinced he has his A+, his MCSE, and an Associates Degree in Comp Sci, aswell as 2k$ in Microsoft stocks. Since then, I have found none of this to be true, yet he does know a damn lot about adminning NT and somewhat of 98. I take more care of the teachers computers, the lab computers, and stuff like that. I make sure defrag is ran in all the labs and on all the teachers computers monthly, etc, etc. I also upgrade, fix, and repair. I can strip a computer to the mobo and have it back together in 2 minutes, Rob can re-install NT from corrupted back-up tapes.
    Anywho, I setup a linux lab (redhat 7.1 with XFS and icewm for those who want to know) as an internet surfing lab at the middleschool. So far since November all I've had happen is one X server crap itself, and I just re-ghosted it.
    Rob manages the 98 lab (I keep it running, it just installs software and such.) Imagine 5 groups of 30 highschoolers a day in there. It is not fun. Stuff gets deleted, uninstalled, one machine had 10 copies of AIM installed, etc.
    Then there is the 486 Lab, which is primarily for typing and some internet research. After seeing the sucess of my Linux lab (some students are supposedly confused by it, but I don't see how, Netscape is pre-started and that is all there is), he finally came to me and said, "I want to put linux in the 486 lab". know that any current distro would be slower than my overweight grandma, and that no older ones would easily allow a journaled FS to be setup, we are now planning on installing QNX R4, but its similar enough to be counted, eh?
  • Yes, you'll be out a few bucks for the cd's, but why not bring in a copy of red hat, mandrake, debian, whatever you want. Maybe two different distros to show the variety. Whatever distro you are comfortable with. Bring enough for everyone, that way everyone can walk out with the ability to do whatever you showed them.

    Let them know about the local lug if there is one.

  • Jon Lasser has an excellent book which assumes you're a computer user, but new to Unix. He starts out with "Unix Documentation" or "how to understand poorly written man pages" as I like to call it. Then he talks about "Files and Processes", "Redirection and Pipes", and "Networking". Later he gets into vi, regex, and shell programming. Finally he talks about the X Window System.

    It's a good book. I learned Unix from reading it. The book would be a good starting point to creating an interesting class.
  • Check out Linux for Windows NT/2000 Administrators by Mark Minasi with Dan York and Craig Hunt. It's from Sybex. Can't recommend it enough, got me started - explains everything from a Windows point of view, and doesn't bore you with things you already know from Windows experience.
  • that there are free alternatives...

    WHOA! Hold on there.

    What is the course you are teaching? An intro course on *NIX? Ok, great - but why are you now trying to throw in Free Software? That is not what the course is about!

    Forget trying to convert any of these M$ students. That is definately not what they are there for. What you should be doing is teaching them the basics of *NIX. Don't try to mix in political rhetoric. Whether or not MySQL/PostGreSQL can beat SQL Server is completely irrelevant to the course.

    Stick to teaching *NIX intro stuff, don't get into Proprietary vs. Free. In 2 days you will not convert any MSCD students. Really.

  • After you show them where the man pages are and how to use the tab key be sure to show them something useful or they're just going to ask "why do I want to do this?". For example, run through a simple shell script. Like this one that allows you to quickly update your web page:


    rm -f ${1}.html && \
    wget${1}.html && \
    vi ${1}.html && \
    exec ftp

    Think of examples that do things Windows just doesn't let you do like running X applications remotely. Here's a must read regarding that topic:

    Remote X Apps mini-HOWTO []

    The Xnest script from the above would be good.
  • Have two computers to demonstrate on. One is a Windows box and one is a Linux box.

    Show them how to do something in Windows, which they should be familiar with, then show them the Linux way of doing things. This will help them remember it better and become more comfortable with Linux.

    For example, something as simple as changing Screen Resolutions. It's a basic thing and it shows how the two are different.

  • Do they know DOS? (Score:3, Insightful)

    by dsoltesz ( 563978 ) <> on Sunday April 14, 2002 @03:38PM (#3339741) Homepage Journal
    If these Windows users also know DOS (I don't know if that's a fair presumption) one approach is the Unix Guide for DOS Users approach -- give them a list of the basic commands and their Unix counterparts. That combined with man/info can certainly give them a jump start. (Unfortunately, the book I'm thinking of appears to be out of print.) As for the basics, Windows users will appreciate knowing how to (ab)use ln.

    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 [].

  • Since they are going to be using thier MS certifications in an MS environment, it might be good to introduce some Unix-style tools available for Windows like those in Cygwin [].

    The only downside to this is that those unfamiliar with modern Unix-like systems might see Cygwin as all that Unix is. I've had some Cygwin users insist to me that Linux really should have a GUI, for example.

  • I'm sure that many of the posters here suggesting teach-this or teach-that mean well, but most seem to me to be missing the point. You don't start teaching a class or course without an objective, unless you are naive or dumb. The first two things you have to know with any class are a) what do they know when they come in and b) what should they know when they leave. Ok, for this group we have a fair idea of what they know coming in (but all the same, it helps to know if they are CS grads, MIT professors or high school dropouts :) ).

    So the next thing is the outcome you want. Why are they being taught? Whose idea was it? Is it just for information, or are they supposed to be able to DO something with this new knowledge they are supposed to be acquiring? Is it just a general awareness class or what? If you don't know that, you haven't a chance in hell of getting it right.

    Once that's known you can figure out what you want to introduce them to. There are some materials you might care to use free for download from if that helps you with some training notes.

    As someone who makes part of his living from Unix and Linux training (the former for 25 years, the latter for 5 years) I'll happily share my experiences of introducing Microsofties to things like the command line and the intricacies of Linux.

    They will be impressed by networked X - I save that for the last couple of hours, since people typically remember most about the last thing they saw and you want to leave a good impression.

    The filesystem won't be hard for them, neither will NFS. They will keep asking about domain authentication, but I'd steer clear of NIS :)

    The most important thing I can say is that they will HATE HATE HATE anything command-line oriented. The fastest way to lose them is to start harping on about it. The really bright ones will pick that up for themselves later, but for the introduction, use something like SWAT for Samba admin - webmin will do that and most other things too. I can't emphasise that enough, it's based on real-life experience.

    The rest of the class plan you will have to pick when you know what you are trying to get them to do when they leave.

    Finally, don't try to teach too much. Two days is VERY limited, the best you are likely to do is get them interested and reduce the fear level. To get people through even basic stuff like LPI 101 and 102 is around ten days of classroom and exercise sessions. In two days they can only get a taster. If you haven't taught in this kind of situation before, you will be astonished how little can be covered in two days from a standing start :(

    Best of luck!

  • Definitely start with:
    Rute User's Tutorial and Exposition []

    Best learning (and reference) resource I've ever seen for Linux.

  • These are aspiring .NET developers, right? You don't mention the rationale to be teaching them about Unix but presumably it's to teach them about the platform.

    Most of the suggestions people are making (show them how you can change or theme window managers, install a distro, perform maintenance over ssh, ridicule them) seem to be aimed at MCSEs or admins, not at developers. I still haven't quite figured out whet .NET and its free implementations are or do, so I can't make very useful suggestions (someone come up with better ideas) but I'd imagine teaching them about things like paths, libraries, gcc, scripting languages and available toolkits would be helpful. I don't know how usable Mono and the Qt or Gtk bindings are but you may want to look into them and show them if there's anything yet to show.

    Or Glade, Qt Designer, KDevelop...

  • I use Apache, XnView, Gvim, PHP, the Gimp, mySQL, and many other applications under windows. Show them that GPL does not have to be an all or nothing step, you can mix and match win32 and GPL, and have a system that you are mostly familiar with, and high-performing apps, for less then the cost of a pure Microsoft solution.

    Then, show them the ease of linux remote administration, the windows compatability, and how linux is usually faster/more reliable on slower hardware. Show them the stability of linux vs windows.

    I'm my experience, the disadvantage you have is warez. There are plenty of 'free', easy to use software for windows if you know where to look. Bring up BSA horror stories, and talk about the GPL.

    Just my $.02

  • I think Sun Microsystems had a pretty good idea in writing a Sun Blueprint that basically takes a look at how to do a task under Windows NT and then shows the corresponding task under Solaris. It is published by Sun and is called "Solaris Guide for Windows NT Administrators". You can find further information on it at the Sun Blueprints Publications website: []

  • Given that you are only going to have two days for this crash course, the amount you'll be able to accomplish is probably minimal. I taught a Linux class a little over a year ago that was a week long so I had the benefit of a bit more time. But I do have a couple suggestions.

    The biggest one is, teach them how to find out more. These are people who may be used to getting their tech support from paid vendors, and when working with Linux you can get frequently superior support from on-line resources. Teach them how to effectively use google and google groups to get "tech support". One of the most valuable tricks I learned early on with linux was simply looking for an error message in quotes. 90% of the time, somebody already asked the same question and somebody else has already answered it.

    Another thing I would suggest is get them familiar with the basics of getting around on the command prompt. Give them a reference sheet with the most useful commands and the most useful switches for those commands. Then if you don't have time to cover them in detail, at least a cursory explanation and that reference sheet should give them the foundation they need.

    Next, I would show them how easy it is to download and compile tools. Find some small piece of software that you use routinely, and then show them how to build it. Knowing that most packages can be constructed using the standard ./configure, make, make install, can take that edge of fear off that might be associated with having to compile their own tools. Just be sure you know it works on the machines you have to work with.

    Overall thought I think the focus, given your short time, should be making them feel comfortable with working on Linux. If you get them comfortable, then they can figure it out from there :).
  • by t0qer ( 230538 ) on Sunday April 14, 2002 @04:12PM (#3339847) Homepage Journal
    One of the things that helped me out was a page I found that showed me the unix equivalent of dos commands. It looked sorta like this.

    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.

  • 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.

    • I agree completely. It's a fundamentally different way of looking at operating systems and changing someone who is as entrenched as an MSCE would be in W32 is damned difficult.

      On the other hand, moving a *nix guru over to W32 isn't difficult at all... they already know the details of how things should work, so it's just a matter of learning which buttons to push and which concepts have been redefined ("domains" to name just one).
    • by danheskett ( 178529 ) <danheskett&gmail,com> on Sunday April 14, 2002 @05:16PM (#3340115)
      I feel compelled to respond, because basically, I feel that you are spreading a terrible number of untruths and poor generalizations.

      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.
      That is condescending, and its entirely untrue. If you really believe that any class of user is unable to learn than you seriously wrong. I've seen every imaginable type of user learn just abotu anything. I've seen users barely able to hunt-and-peck trained into impressive C coders. I know several average, run of the mill end-users who've transformed into very professional sys-admins. I've seen experienced Unix people switch to Windows, and vice versa. Your basic assumption is entirely false. The premise is false. Anyone can learn new skills, especailly in the computer realm.

      to pursue Win32 know-how as a career path assumes that you enjoy remaining ignorant about certain aspects of the machines youre running
      That is entirely, profoundly, and completely untrue. If you really believe that, you must then believe that the only people working on the lower-levels of Windows work for Microsoft. And that is patently false. I write kernel level code for Windows from time to time. I customize and develop drivers as needed. I muck about with all the same things that even the most ardent Unix guru deals with.

      The fundamental problem with your argument is that you fail to recognize the various roles that people play within an organization. Windows (and indeed Unices) allow extremely high compartmentalization of tasks. Is a PHP developer living in ignorance if he can't fully detail to me the methods of thread-safe C programming? Is a Gnome programmer living in the darkness if he can't fill me in the compressin techniques used by the Remote X protocol?

      The point is that your friend Brad was compartmentlized, yet still remained mostly effective (as you said, he knew his stuff). That is a strikingly good quality to have. The main difference between the Windows and Unix gurus is not anything more than the level at which their knowledge is abstracted. In the Unix world, you say that most of the gurus know their system from the ground up. That is patently false. Their are but a handful of people worldwide who understand the full complexity of any major OS (Unix, Windows, anything). At some point your knowledge is abstracted to the fundamental "if I do this, then this other thing will occur" level. Like I said, the difference with most Windows and Unix professionals is the degree. Chances are the Unix types start at a much lower level than the typical Windows guru. But be clear, most of the people you make mention couldn't elobrate on how various Unices check for dirty caches, or fill me in the methods of determing proper MTU settings in different network roles.

      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 we go again with the "Unix people are better because they can handle source". In college I used Pine for e-mail. If there was a bug in Pine, was I going to go through it and fix it? No. Again, this is a clear case of compartmentalization. Many many many Windows professionals prefer to move out of those compartments and into ones that make more sense for them. Somehow, if we choose not to involve ourselves in the complexities of "off-by-one" programminer errors, stack corrution, or latency reduction patches we are some type of luddite. So many of us are the front lines of end-user support! That's our job, thats our dedication in many cases! And all we get in return is slander from people who choose to dig deeper. Somehow you seem to think that if we don't all choose to be BOFH we are useless, an unneeded appendage.

      My own philosophy is to get only as deep as needed to solve a problem. That's my job - to solve problems. On my own time I love to dig, explore, hack about, and what not. And yet you slander me and people like me for no reason.

      Finally, a few comments about your RAID example. When you say Win32 users, I assume you meant professionals, engineers, developers, or something. Never send an end-user to do a professionals job, regardless of the platform. It really just doesn't make anysense. IT seems clear to everyone reading that they were entirely unqualified to service/work on those machines. The question is, are they qualified to service/work on Windows machines? It seems clear that answer is no. So the big thing is, why bring them up at all? Simply to slander Windows users. Thats the only logical explanation. So fine, I can slander UNIX types as well. I have friend Brian. He was working remotely on a Slackware server, when he decided to update glibc via SSH. He removed the symlink pointing to the in-use version before he had the new version in place. Every dynamically-linked prorgam that used glibc failed to run. He ended up having to drive 12 hrs round trip to fix the problem. The idea of "symlinks" would be futile to explain to him.

      One other note, about uptime. One thing I find curious is that in about 50% of the cases where I have to deal with Unix people they are obessed with "uptime". Anecdote: with one joint project, we made a whole slew of changes to *nix box, to virtually every daemon, service, and server running actually. I suggested that after we did all this we would want to reboot the box. The guy flipped out. Freaked out. Absolutely went nuts: "I've got 200 days of uptime going here!". We were in a live user environment, of course and this was 50% of a load balanced site. So he went off and manaually restarted everything, essentially "rebooting" everything but the kernel. Users were of course disrupted. At the end of it, everything was okay, but users experienced about 15 minutes of downtime (just about the same amount of time required for a reboot). The point? The users still experienced downtime. That's all that matters. Uptime is a usless pride building number. Availability, well thats whats key. Sure, the kernel on that box had been running for hundreds of days - but users - they hadn't gone hundreds of days without a loss of availability. I think in the Windows world many of us a really strong appreciation that users don't care about uptime, only availability. I'll frequently issue a reboot when in fact I could just mucked about shutting things down and restarting them. To me, its just easier to reboot when either way users lose their connection. And when that lose of availability is unavoidable, I just bite the bullet and try to plan better next time. Basically the point is that I know dozens of Unix types who are slaves to uptime.

      They just don't get it. Its all about the users, not them, not their OS, not their silly numbers.

  • One of the things that gets me interested in things and makes me want to learn more about it is when I see something really useful or cool or whatnot done with what I want to learn about. Take electronics for example, my electronics teacher got me interested on the first day by pulling out a mic/transmitter array that could be used for very devious purposes (say, room tapping). This caught my attention quick (I'm 16, what d'ya expect). A good way for you to teach them, especially in crash course format, would be to get them to want to be able to do something "up there", like piping
    • very
    certain data from an often used program on your server to, say, a log file or even another program. Try to make it look as easy as possible, emphasise that it can be done with any program, any file. Stuff like that cannot be done with any microsoft OS unless the programs are written or re-written specifically for the purpose.

    On top of that, when you have them doing something on their own, be doing something on your own computer (X running, blah blah blah) that would amaze a windows user. Use enlightenment with a really good theme while doing something that has to do with class or even just burn time. On the off chance they see what you're doing, they might start looking at Linux as being more and more attractive;)

    Of course, this might not work, the students having less care for anything else other than Microsoft, their souls having been sold to them and all :-P

  • The Unix Philosophy (Score:3, Informative)

    by rubinson ( 207525 ) <rubinson@email . a r i z o n> on Sunday April 14, 2002 @04:31PM (#3339923) Homepage
    You've only got two days and from what it sounds like, students are being forced to attend so they're not going to want to be there. They're not going to learn much unless you peak their interest.

    I'd suggest teaching them the basics of the Unix philosophy - small is beautiful, make each program do one thing well, avoid captive user interfaces, etc. If you don't already have a copy, pick up Gancarz's The Unix Philosophy which describes the various tenets clearly and concisely. (Hell, if you're allowed to or have a budget, make the text a required purchase. It's cheap.)

    Something like this would be far more useful than 'ls|grep' or "/etc is where system-wide configuration files are stored" because it would provide them with a new way of approaching computers.

    p.s. For extra points, contrast the Unix philosophy which assumes that you know what you're doing with the DOS/Windows philosophy which assumes that you don't know what you're doing. You might even want to begin your class by reading/assigning Scoville's Unix as Literature [] which nicely depicts how different Unix is from other operating systems.
  • There are many other good ideas here. I'd like to add my 2 cp for xargs, find, and grep.

    These shell commands are good by themselves but great when used together.

    find /etc | xargs grep "eth0"
    will find every config file under /etc (and all subdirs under /etc) that file that references the string "eth0". This can be a life saver when you found a reference to some constant or variable but you have NO idea where it is set. The command combo I gave above is probably the only reason I managed to get my firewall configured, the first time it did it.

    Do this from a GUI with three or four shell windows open, so you can grep in one window and keep a file or two open (runing vi, or whatever) in the others. Then do the same thing with NO GUI (yes, Linux runs great like this, esp. on old crapy machines, e.g. my firewall again). Show them how to use ALT-Fn to get multiple screens with out the GUI.

    Show them also

    find .
    to look in the current directory, and
    find <b>dir</b> -type f
    will locate only regular files (ignoring links), which is nice for reducing spam.

    Also show them

    xargs -i command {} more args ...
    for when xargs can't append the commands, or needs to run them singlly.

    Also, point out The Linux Documentation Project isn't the be-all or end-all, but some of their how-to's are invaluable if you have nowhere else to turn.

    Good luck!

  • ESR's Drag.NET (Score:2, Interesting)

    by bemis ( 29806 )
    check this out. []

    ESR did this piece about setting his wife (a windows-junkie-lawyer) up under Linux/KDE ... it's amusing, not entirely serious, but might prove helpful.


    -The fellow who thinks he knows it all is especially annoying to those of us who do. - Harold Coffin
  • If you go in with a bunch of preconcieved notions about what these people know and don't know about Unix, you won't reach them. The certification they are going for looks like its for developers. There are certifications for Office, and there are probably idiots in there. The people going for this certification are programmers / developers / engineers, and you should treat them with professional respect. That means not going in like a Linux Hare Krishna looking for conversions. See if they have used Unix / Linux before. See what they know how to do, etc. Show them how to use Emacs or maybe vi. Your job is to teach them as much as you can in two days about a system with a steep learning curve.

    Every comment here says that you should be pushing linux, how simple it is, etc. The beauty of CLI, the elegance of | . If you want to go that route just write on the board "I am LETE I OWNZ YOU". But I think you should give these people credit. They are learning VB or C#, and most people might think that makes you a loser, but give them credit for trying and withhold your judgement.
  • by crudeboy ( 563293 ) on Sunday April 14, 2002 @05:26PM (#3340177)
    Since they are studying to be developers, show them unix from a developers point of view. Show things like version control (with cvs), how to compile code (gcc etc.). Make a point that all you need to develop applications is there right out of the box free of charge. Tell them about relevant things in unix systems (sockets, pipes, daemons).

    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.

  • 1. Start/stop kernel module services. Show how you can change the network setup by editing /etc/sysconfig (or wherever), stop it, and restart it, all in a few moments.

    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. /.,,, sourceforge. Show that there is active community involvement in all aspects of development, and that when problems arise, they are not occluded, but rather discussed and FIXED.

    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,
  • by buchanmilne ( 258619 ) on Sunday April 14, 2002 @06:15PM (#3340385) Homepage
    If you are going to do nothing else, show them how to integrate a linux box into their windows network. At the end of this, you want them to be confident enough to install linux dual-boot at the place of work.

    So you are going to need to show them that it is possible to mix'n'match windows and linux.

    (Mandrake 8.2 comes with winbind mostly setup - see or at least samba and joining a samba box to a windows domain. Something like LinNeighborhood for accessing shares.

    2)Rdesktop or vnc or X on cygwin
    The chances are they are going to have windows servers around, so make sure they know they can get into them from linux. From the other side, make sure they know they can get into their linux boxes from windows and run graphical apps, either with vnc or by running X on cygwin. (Need I mention rdesktop and vnc are standard on Mandrake ...)

    Show them why unix is better in some regards:

    3)Please choose a decent distro. Please don't show them how to resolve dependencies on packages with rpm, but show them the right tool for installing software (apt or urpmi).

    4)Show them how to effortlessly setup a firewall. Mail server, web server, proxy server.

    Give them something they can apply on windows:
    5)Show them that they can run PHP on IIS, and apache on windows (for better security). Show them cygwin.

    6)Give them something to tie it all together. Maybe write a small php webpage that can send email to a windows domain account, or something that queries a db (or both).

    7)Remind them that they should not be running X on their servers (aka you have a choice not to run a GUI).

    8)Remind them not to hit CTRL-ALT-DEL when they want to log in locally ;-)

    9)Show them the really good gui tools around, things like Kdevelop, OpenOffice, Evo, Konqueror,Gimp etc

    10)Show them your favourite command-line features. Bash-completion, vi (they don't need to use it, but show them that a console editor can do syntax-highlighting), mc, lynx, ssh (with password-less key-based logins), X ssh-tunnelled.

    11)Show them how easy it is to change hardware (like an ethernet card change with kudzu or similar) with a single reboot and virtually no downtime.

    12)Give them CDs for the distro you used, and another CD with similar stuff for windows (cygwin, apache, mysql, mysqlfront etc).

    I think your problem is going to be fitting it all into 2 days!
  • by bytewize ( 324814 ) on Sunday April 14, 2002 @06:17PM (#3340396)
    I've been giving linux courses to windows nerds.

    The first time I used Redhat 7.2. It turned out to be a mistake. The next time I used mandrake 8.2 and that worked well.

    The graphics seems to impress more than the cli.(Unfortunately) Things that you as a unix person are impressed by dont work well for windows people. This was a real problem for me as I use the cli for most of my work. You have to learn to use the kde tools like konqueror and kwrite.

    In 2 days you wont be able to do much more that show them the power of Linux. You need at least a week.

    Here are some of my tips based on the experiences that I have had.

    Make them install mandrake with a full graphics install with dual boot.

    Show the wizards and control center

    Show them X -query and rdesktop.

    Windows people seem to prefer kde to gnome but dont forget to show them choice. Install both so you can show them evolution.

    Also the web admins really impress them. (Swat, webmin and cups)

    Mandrake has a beta of Staroffice (silverclub members only). Get it. (email me if you want it)

    Dont even bother showing vi. Somehow it doesnt work for windows people.Use kwrite instead.

    Make sure you install all the games. During my course the games really got them going.For some strange reason "frozen bubble" was a big hit.

    Teaching the students the cli with commands like grep, cut etc. didnt impress much until they wrote their first script. I had them write a simple menu to start different commands. Then they understood the power of unix.

    Get them to run ssh to each other. For windows admins this is very impressive. Installing kiofish in kde is also impressive.

    If you want my course material, I'll be happy to send it to you. Its in swedish and not that good but you could send it through babelfish and get som ideas. Its for the cli so it wont be useful unless you can increase the course to at least 5 days.

    These are some of my experiences. Hope they help you.

    Regards kenneth karlsson
  • MCSD not MCSE (Score:5, Informative)

    by Dr. Evil ( 3501 ) on Sunday April 14, 2002 @06:22PM (#3340409)

    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.

  • by Merkins ( 224523 ) on Sunday April 14, 2002 @07:26PM (#3340680) Homepage

    I have been teaching myself how to use Linux over the last week.

    I have been running Ipcop as a firewall for a few months and getting into the shell and poking around finally got the better of me and I decided to give Linux a good go.

    My goals were :

    1. Get it installed and running
    2. Get X working.
    3. Figure out the difference between a desktop and a window manager ;)
    4. Get Samba running
    5. Get apache running
    6. Get PHP and Postgress SQL running to learn them and get a simple web app together (I am a SQL Server / ASP developer by day ....yeah ok ok, shut up... not all of us a morons, just most unfortunately)

    SO far I am doing well. I had some Red Hat 7.1 CDs and have that running. Gnome and Enlightenment work for me, although I am mainly using enlightenment as it is a pretty crappy machine. I got Samba to work so I have a share set up in my Windows workgroup. I have Apache running. I have VNC Server and SSH running so I can do it all from my Windows Laptop using PuTTy and VNC (the only spare monitor I had was really crappy).

    The only thing I have left to do is configure PHP and a database and I am happy.

    But I do have a point....

    The most important thing I have learned. Is Google Groups search is your best friend. There are so many little quirks and pitfalls for someone setting this sort of stuff up by themselves for the first time. No tutorial can cover them all. Teaching people how to find answers is the best lesson of all. Especially when it is 1am and they have just managed to completely stop something from running (Samba, X etc), it is important to know how to get an answer when you have no one holding your hand.

    End of the story....I am loving it! If most of my computer use didn't involve SQL Server I could see myself switching.

  • philosophy (Score:5, Insightful)

    by martinflack ( 107386 ) on Sunday April 14, 2002 @09:30PM (#3341099)

    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.

  • by ahde ( 95143 ) on Sunday April 14, 2002 @10:13PM (#3341207) Homepage
    teach them aliases, because it helps get rid of the fear of memorizing odd or complex commands. But since computer users don't even know simple commands like "dir" anymore, that's probably moot.
  • best project (Score:3, Interesting)

    by psych031337 ( 449156 ) <> on Monday April 15, 2002 @03:37AM (#3341915)
    OK... I am a guy that has seen DOS, 4DOS, numerous Redmond products. I currently am stuck to W2K and I probably will be for quite some time as it is damn reliable. Linux was never a issue to me, mainly because I have to eat (and therefore earn bucks admin'ing Win OSes).

    But what really fused my interest and admiration for linux was configuring a dedicated router on outdated hardware. There are quite some "linux router on a disk" projects out there, look for Coyote, FreeSCO or FLI4L (which is maintained by bunch of german guys).

    Get your people to setup a working design for a linux router. The beauty of the project is that they can just make a boot disk, reboot the box they are working on and test it for real. The simplicity of the projects has quite some advantages - it takes out the "cluttering" some distros have (as in having /bin, /sbin, /usr/bin, /usr/local/bin, ...) . The systems generated by (say) FLI4L are full linux systems, but without most of the fuss.

    These systems are probably all you need to teach the basics of piping and redirection, the /var and /proc concept, shell scripting and automating/streamlining processes, blah blah. To me the FLI4L is the essence of linux - a small thing to get the job done, with no waste of resources. On the other hand, there is basically nothing you CANNOT do with FLI4L - install a SMB server and print servies, control LEDs hanging off the serial port, httpd, ftpd, telnetd, mount NTFS, you name it.

    Excuse me for praising FLI4L here, other router distros are probably just as good, but FLI4L has the flexibility to astonish even people like me.

Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian