Slashdot Mirror
Teaching Linux/Unix Basics to Microsoft Junkies?
flupps asks: "I've been asked to hold a two-day crash course in a class of students that currently are studying to become MCSD certified. I'm looking for ideas how to set this up. I was thinking about starting with some general file system descriptions, where to find what files, the man pages, the tab-button, etc.
After that move on to some of the daemons and just explain what they do." He's got at least one idea to start with (below), but what must-have skills or demonstrations would you add?
I also plan to set a database program in VB (one of the certificates in the MCSD suite) against a MySQL or Postresql db and show that there are free alternatives that works as well as SQL server.
What would you think could be a good addition to teach them?
This is in no way meant to be a very advanced course, but I want to show some of the excellence of *nix and why you sometimes can save time and stability and maybe make them interested and read up more by themselves afterwards.
Any suggestions very welcome.
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.
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.
The GeekNights podcast is going strong. Listen!
instead of doing like MCSE and giving them fish, teach them how to fish.
/etc - it's where most of the config files are. /usr/bin - it's where most user programs live /usr/sbin - it's where most superuser programs live
/all - in unix we have ifconfig' some basic translations of basic stuff.
"This is
This is
This is
If you're interested in using a command and don't know how, use 'man command' and get them familiar with how to use commands. "
You've got two days - so some basic 'how to get info' and then examples of getting that info, would be good.
Possibly a run down of 'in Microsoft, you have IIS, in Unix there's apache, ftp, etc'. 'In MSFT, you have ipconfig
How about running through the 'Administrative tools/Common' menu in 2000 and showing them where all those toys live in *nix - or where they might be able to find them.
But make sure you teach them how to fish for themselves - I suppose MSFT has the help pages, but man pages are our best equivalent. Or homepages for the package in question where applicable.
Good luck!
-- There is no sig line, only Zuul.
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.
creation science book
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.
Please don't use "SQL server" to describe "Microsoft SQL server". "SQL server" is a generic term.
Hail to the king, baby!
Just make sure that they read:d .html
http://www.fsf.org/philosophy/right-to-rea
It is a cool little short story that appeared in the Communications of the ACM. It will show them that there are larger issues at stake beyond merely getting their immediate tasks accomplished.
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.
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.
Emacs would be better because at least you can type stuff straight in after running it, and it has some menus, and saving files is simple ctrl key stuff. In vi, doing 'i' to start editing, and then wondering why the cursor doesn't wrap around at the end of lines, and then "esc", ":" "w" to save the file is just too much for these people. Vi isn't normal! vilearn is a good tutorial program, but these people are not here to learn Vi. Mention Vi as an editor available on every Unix system, mention that it is complicated, but they can use gvim as an OLE editor within Visual Studio...
Pico is suitable - it is easy to use and has a help system. In a GUI environment, just use gedit or kate or whatnot.
Overall I agree with the people that advocate showing what you can do with a Unix system, not how to do it. Show the development tools available, show the services available, etc. Show differences between Windows and Unix equivalents. Don't be evangelical about Unix, be realistic. Explain that the systems are different, and both have advantages and disadvantages...
In my opinion, the idea of getting Microsoft junkies to sit down and understand Unix is beyond your typical Microsoft junkie's ability. I'm not trying to sound condescending in that, either. I just think that theres a point where someone gets so entrenched in one way of doing, and one way of thinking, that they lose the ability to "switch gears" and pick up something fundementally different. I'll give you two examples:
There was a guy I worked with named Brad. Brad was an ardent Windows guy. He knew nothing about any other OS'es other than Win32, other than their names. In his mind, Win32 was the pinnacle of operating systems because it simplified complex tasks down to a predictable series of point-and-click operations, and like most Win32 gurus, he had absolutely no idea how anything worked under the hood. He had no idea what a kernel was. Infact, anything below the driver level was completely black box to him. In summary, Brad, even though he knows his stuff, is completely oblivious to the merits and drawbacks of his own platform, because to pursue Win32 know-how as a career path assumes that you enjoy remaining ignorant about certain aspects of the machines youre running. It resembles something more of a religious belief than it does a philosophical belief.
Unix, in its form and in its structure, is the polar opposite of Win32 in regard to how you approach it. You're not only encouraged to grab a shovel and dig deep into the platform, you're required to do so if you expect to gain mastery over it. That being said, Win32 users are unaware of this process. They think in surface-layer terms, whereas Unix people know their systems from the ground up.
What makes matters worse, is Linux, and the idea that the whole damn platform can be looked at, dissected and understood down to the source. While this is an advantage to a Unix guy (since we are used to doing such things) , it presents an insurmountable task to a Win32 user, who's concept of computing often does not extend below the GUI.
Here's another anecdote that illustrates the point i'm trying to make: Where I worked, a bunch of Win32 users were given the task of conducting performance evaluation and testing of RAID arrays under AIX. I appeared to be the only guy in there who had anything more than a extremely cursory knowledge of Unix. After a day or two, I began to wonder why all of the AIX hosts were being rebooted so often. I had a look at all the machines and their uptimes, and discovered that these boxes were being rebooted about once a day. I asked why. They looked like deer caught in the headlights....It turns out that whenever they were trying to remedy a config-related issue, their first instinct was to reboot the damn machine to fix it. To explain the concept of "uptime" would have been futile. To explain the notion that "rebooting is not how you fix a problem in Unix.".
In short, they just plain don't get it, and its doubtful they ever will.
Cheers,
Bowie J. Poag
An MCSD isn't an MCSE. Your audience is a group developers. They're not interested in sysadminstuff. They're interested in developer tools.
:)
You've got two tracks to cover here, as I see it.
1) "Free stuff" that makes Linux distros good for developers,
2) Generally free stuff that they wouldn't see as "pure" MCSDs (due to the ties between "Linux" and "free")
For 1), show them stuff that comes with the distro of your choice, like compilers, IDEs, change management tools. Show them MySQL and Postgres, yes. Show them editors.
For 2) Don't forget Java-- Eclipse, JBoss, etc. Don't forget the Mozilla developer aids like Bugzilla. Sourceforge & Freshmeat & Slashdot.
Finally, the MCSD has this development process framework called "MSF." Show these guys something fun like Extreme Programming.
TTFN
[Error 407: No signature found]
Comment removed based on user account deletion
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.
/., freshmeat.net, linux.com, 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.
2. Push remote access, like ssh, which gives a user full control of the box from remote, something that is difficult to do in NT w/o consuming many resources (TB2,etc)
3. SAMBA. Install Samba from the cd and show how they can manage and use their (precious) Network Neighborhood stuff, connect to remote computers, etc.
4. Routing. Show how any linux box can setup firewalls and complex routing with a few commands.
5. Security. Run nmap against your now-configured linux box and compare it to, say, a windows 98 box. Show that linux can be locked down for the miscellaneous user.
6. Support.
Maybe not everything can be covered in two days, but hopefully this helps. I was once a M$ kinda idjit, but the above points, as well as many other good suggestions already discussed in this thread, helped me to kick the GUI.
Not your typical post from,
AntiChristX
Daring to remain below 5 karma indefinitely
The first thing I got taught is "UNIX is hell to visit, but heaven to live in". That phrase is very true I think. At first UNIX might seem strange and odd in several ways, but when you get the hang of it you appreciate it's design and fundamental thoughts.
Well, first off, I myself work in the exact same environment as the people you are trying to teach. I've been working in with a VB+MSSQL combination for about two years now.
:)
Unless you can show them a good graphical replacement for Windows as the UI, I would focus on using the alternatives on the back-end only. Despite the reputation VB has around here, it does have it's proper place. Many people who work with VB (like myself), aren't necessarily "Microsoft Junkies", as you say, but ordinary programmers who need to make a living, and don't particularly care what they're working with, so long as they're programming. In this case, it comes down to what the customers want. Until Linux is on the desktop, the customers will keep demanding Windows, so it wouldn't do much good to try to convince these programmers to use Linux for the interface.
Focusing on the back-end, I would show them how they can connect their VB applications to the database, and focus on that connection. Once the connection is made, they know what to do with it. If you can show them how easy it is to use, they can bring this knowledge back to their bosses. This will impress their bosses, because they can essentially give their customers what they want at a lower price, due to MSSQL being out of the picture.
But guaranteed, if they take ideas of using Linux for an interface instead of Windows back to their bosses, it'll get tossed out the window. Believe me, I know - I've tried it before. At least doing this, you can win one battle at a time - first the database backend, and then the front-end at a later date.
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.
"Aahhhhhh!!! Passwords in plaintext."
No, not with the Windows telnet server it isn't. By default it's set to use only NTLM authentication, which is encrypted. You can set it to accept plaintext as well but that's not the default.
You need to back up and do something more fundamental before you start showing them filesystems and daemons. You need to compare the two competing philosophies that drive Windows and Unix cultures.
After this balancing act, then you can begin to lead them down your path of showing them practical items. At each point you can refer back to these fundamentals. For example, when it /etc, you can explain why Unix admins think text file configuration is inherently more stable and powerful than registry keys, because without such an explanation the Windows admins will typically see it as quaint and backward. Again, when you get to /dev, you can show the inherent debugging power of being able to do things like "tail /dev/midi00" to debug a connector on the computer, even if that data is not useful immediately. You can show how grep, awk, and perl can be chained together to do advanced data processing (on text) that would not be possible on Windows without a specific feature to make it happen. The key is to refer back to a specific philosophy for each exercise, so they can see the big picture.
None of them will watch a hands-on lecture and run out screaming "I've got to convert to this immediately! He broke out this thing called grep and it was.... it was.... AMAZING!" :-) Rather, you want to give them a clear understading of our culture, and just like how a high school senior goes to a college campus and says, "Yeah, I can see myself here" you might kindle an interest in some of them to find out more about how we *nix people think.... and that would be the first step to bringing them over.
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.
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Comment removed based on user account deletion
If you just focus on standards and deamons you only show them several single aspects of a unix system without showing them the unix system itself. When they are on the way to an MSCD they already have a vision of an OS and how it should work. you can't fight against that with some standards here and some deamons there. They must learn why unix samples all functionality in a virtual tree and why it bases on tools. This helps them to understand why Samba is not just a clone of a Windows Strategy and why the Filesystem Hierarchy is not just complex but functional etc.
Don't forget the glue, and that is the unix philosophy. It gives the audience the information they need to stay away from prejudices and to find correct answers and assumptions on their own thinking.