Slashdot Mirror
Advice On Teaching Linux To CS Freshmen?
copb.phoenix writes "I'm a sophomore Computer Science student teaching computing labs to a freshman class, getting ready to go over the major ins and outs of the Linux terminal and GUI. While I have my own ideas and the professor over this class to lean on, I've found it difficult to get the few students that I've tried to teach in the past to connect the dots and understand how it relates to what they already know about computers. Does anybody out there have any advice on how to engage and inspire our upcoming class? (Perhaps important: Our machines are running Ubuntu Hardy.)"
Didn't someone already ask this same question in the last couple weeks?
You've given us rather little in regards to guidance. Is this class part of a larger arc focusing on security? Programming?
Really, if they are going to be any good, they will most likely ALREADY know what Linux is and how it works.
If they don't, really, don't bother them with it. It'll just confuse them.
Have them set up a basic LAMP server. That's how I learned Linux. Or for something somewhat more practical for them, how about a seedbox or a mythtv-box. Frankly, the best way to learn linux is to just get your hands dirty.
Charming man. I wish I had a daughter so I could forbid her to marry one. -Arthur Dent
The ones that are dedicated and actually want to learn will be able to figure it out pretty easily, if they don't already know their way around *nix.
The majority will whine and complain and ask over and over again "why can't we just use Windows". These are the ones that in my experience usually end up withdrawing from CS programs and enrolling in IS and MIS programs. There isn't really much you can do to encourage them.
teaching them how to update those hardy's :P
as a basement dweller i seriously needed an anime hookup. i spent 4 days straight learning how to compile programs, then mplayer, then what a codec was, via system libraries, the gui, how to compile E16, how torrents and other p2p worked.
figure out something that drives today's youth with the same vigor, from the subdomain of scholastics. figure that out and you're a rich, rich person.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
Many GUI applications can be controlled via GUI commands. Showing this helps students understand the link between the magic that goes on under the hood, and the actual action that takes place to make that happen.
Sure, not everything is a GUI shell over a CLI program, but the concept of typing a command isn't that different from one of making an API call to Qt or GTK+.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
I'd start with a two-pronged approach.
1. GUI. Using something like Ubuntu, although I'm generally a CentOS bigot, teach them how to do all the things they know how to do in Windows: download and install software (using apt, for instance) and how to add an icon to the desktop. Teach 'em where to find applications of interest.
2. Start teaching the command line. There are times when a GUI... anyone's GUI... is too cumbersome/restrictive to do things quick and dirty.
2a. introduce them to 'script' and the concept of shell (batch) scripting.
2b. as an addendum to 2a, above, give 'em an overview of the major shells and explain why Tom Christiansen thinks csh is totally unsuited for scripting.
Don't preach about how much better Linux is than Windows... If they continue, they'll understand themselves. If they fall by the wayside, they never would have understood, anyway.
Never ascribe to malice that which can adequately be explained by tenure.
i think exploring the ubuntu directories wouldnt be a bad idea. if they know about computers, theyll see a lot of their knowledge reflected on how ubuntu (and other GNU/linux systems) are setted. i mean, the boot directory, the etc directory, dev directory and others, are interesting to explore. and how users are managed too. why theres a home directory? why so many limitations with access like 744, 777 and others. why the existence of a ROOT or even sudoers. :) greetings from Argentina, im kilinkis
a ton of things are interesting about unix based systems, i think it is the proper way to do computers science
Spot on.
If you want to confuse the poor windows brainwashed dears then try to teach them the Bash Shell and the Linux/Unix command line. That will only turn them off Linux for life.
Switch it around and find things that make you drop into a shell.
regex - very powerful.
parsing OOTB
Command chaining. - the awsome power of 'sed' & 'awk'.
Do stuff that Windows just can't do. Find the USP's for FOSS/Linux etc
Sell that to the poor dears.
CS students with no experience with Linux when they start?
Damn.
Uninstall Ubuntu, and have them setup arch or Gentoo. In all seriousness thats how all of my friends who i can say are good with Linux first were able to fully understand it. Other than that, don't let them use the GUI for a while get them comfortable doing everything in terminal.
That alone should keep the little SOBs bussy for a few weeks, and then the fighting can start.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
These are the types who will mostly not graduate beyond "I can admin a server because I know where to point and click" anyways.
Even the simplest of tools, like vi or ssh, are pretty much beyond them.
You won't get any sound advice if you don't tell us the background of your students. It is the most important thing in any tutoring class. If they have no idea what an OS is, perhaps you should start there. If they know how to use Windows (and understand what an operating system is actually doing), perhaps you could start by making a comparison of the two systems. Oh, and please, do not start with the "on UNIX everything is a file" thing. This has never, ever, helped anyone at that stage. Perhaps you could make a historical review to show, e.g. that in the before time, DOS was the OS and Windows was a GUI. Then tell them that Linux is the OS and Gnome is the GUI. If they get that, then jumping from DOS to Bash will be easy. And some general advice: If possible, do not guide them through a trivial task as a tutorial to show them how "things are done". I have always found such tutorials boring and uninspiring. Instead, give them a book, a manual, an online link or whatever where they can search for stuff and an easy task to perform. Make it like a competition: "let's see who can figure it out fiiiiiirst!" kind of thing. Also, remember that it has to be something that they can accomplish by looking in the material you gave them. The exercise is not for pumping up your own ego when you come to them after two hours with an answer that they could have never found.
Teach one half of the class vi, and the other half emacs. Then join the class back together for a discussion seminar.
I am TheRaven on Soylent News
Find an old Pentium I machine, install Redhat 5, show them a remote ssh -X session running an app on a server.
Compile a modular or monolithic kernel for your exact hardware and needs.
They're CS students, so at least a couple kids in that class have certainly used Linux before. When it comes to teaching the GUI - you shouldn't have to teach anything. It's pretty much the same as Windows or Mac - if they can't figure it out just because it's a little bit different, they certainly shouldn't be in CS - or any science or engineering major for that matter.
As for the command-line: Make the point that it's similar to what they're used to, but far more powerful. I.e., ls instead of dir, cp instead of copy - new names, same commands. But then show something like ffmpeg or some of the Gimp command line options - hammer in the point that you can do complex tasks like video or graphics editing just by typing in a quick command. And then show some piping - that's a big, important part of *nix IMO. Show that you don't have to reinvent the wheel if you can chain things together. And finally do some very basic shell scripting, to show how you would automate some of that stuff.
A few of my friends and I had already learned the ins and outs of Linux by Learning on Slackware 3.0 way back when before entering high school. This is pretty late to be starting, but it's a good call to be taking a proactive approach now. In any case, I would recommend getting a simple book on Linux installation, running, etc.
Here's a good one: . There are probably better ones, but it's useful nonetheless.
Once you can install and configure the entire OS via command-line and Vi, as well as write and build a simple C project using makefiles, you should be set. From there you could learn a bit on Bash scripting if you want, or you could even go as far as to learn how to build your own kernel. That is definitely a worthwhile exercise. Also, I strongly agree with Arker above. Go the Slackware route. To paraphrase an old quote: "Learn Ubuntu, know Ubuntu. Learn Slackware, know Linux"
In my second year at least, was "C programming in a UNIX environment".
It scarred me for life. But you learn so so much about how *nix works from the inside. I'm assuming "CS" is the developing sector , not learning how to get it to run.
What does Linux run?
Google ... Wall Street... CERN... Watson (IBM machine kicking humans ass' in Jeopardy)... Several if not most of the top SuperComputers in the world .... the list goes on... It also runs the majority of webservers on the net [citation needed] as well as on the majority of cell phones on the planet [citation needed]. Linux is pretty much everwhere these days, and most people don't even know it. Make them aware of this fact.
What is Linux?
A kernel. You could describe to varying degrees of technicality what this is, and that all OS' have a kernel, but whatever you decide make sure it's accurate, and most importantly clearly relatable to your students.
Why should your target audience care about Linux?
Simply put, it is designed with the idea of community and free communication of its components. Simply put, the idea of a freely distributable kernel and codebase gives the user the freedom to create, learn, and improve for the betterment of its implementation (word this better than I ..). Now would also be a good time to explain what a distro is, and why there are so many. Also, discuss package management and it's usefullness.
Where is Linux going?
Everywhere it isn't, which isn't too many places, including their present personal computer.
The point: Communicate to your audience effectively and get them excited about, AT MINIMUM, trying it out (here enters virtualbox). Explain that it is ok to screw up your first install (we all did!!!!!!) and learn what you did wrong. How, learning to use Linux, will possibly make them think different about computers, how they use them (the GUI ?!?!?!) , and that with minimal effort and understanding of the underlying code, they can help improve Linux, the framework built around it, and how it is ultimately used. AND, that yes! There is a learning curve. Challenge them, but don't scare them.
Is this just a class on what Linux is and how to use it, a class on system administration, a class on operating system architecture, a little of everything?
I would say to:
- First give students a broad overview of what tools there are, GUI and command line. Let them see it is useful and what the big moving parts are. Wow them a little.
- Explain what Linux is:
- What is free and open source software and why is that important
- Some history behind why Linux exists, and how it got there
- Explain why Linux and the tools on top of it are important, who and what is using it and how
- Explain terms things like distributions, the choices available, live cds, etc
- Get technical:
- Introduce the shell and some basic scripting
- Explain software installation and choices
- Explain the boot process and system configuration files
- Do a concrete project, like set up a simple web server, starting from a clean install
I would take a look at what the typical future classes the student's might take and demonstrate how Linux lets them do the things they will be learning in depth later, giving them a broader introduction to the computer science curriculum where you are teaching. In the end, they need to see that Linux is a useful tool that gives them power and choices that Windows and Mac don't always give them, and that is something important to their future education and employment. And have some flexibility to follow the interests the students present in the class.
I'm assuming that this is your first time teaching anything (at least officially... we all teach often in our lives) and so my advice will dwell more on that then the technical aspects.
As a teacher, your responsibility is to help them learn. Remember that learning takes place inside the student's head; you can present the information, but if it they don't learn it, it is not a success.
1) Some people have indicated that the students "should" know certain things. I'm assuming that the class has no pre-requisites, so you shouldn't be assuming that they know anything. Many people who do things like that do so to make themselves feel better; these students are the ultimate newbs, and treat them like you'd like to be treated. Remember that they are not stupid, just uneducated, and they are in your class to correct that.
2) When you give an assignment, make sure you have done it yourself, on a box that has nothing more installed on it than what they will have installed on theirs. Nothing is so frustrating for students and embarrassing for instructors as an assignment that can't be done because something silly wasn't set on their boxes, such as path variables.
3) Remember that things that don't take you very long will take them many times longer, probably 3-5x as long. So if the assignment you give them takes you an hour to do,... You may want to give them that much work, but make sure it's because you planned it, not because you didn't think it would take that long. I would also recommend giving an estimated time, which should be for the average student it class, and tell them that if it is taking them longer, they need to get help somewhere.
4) Read through the assignments carefully, making sure that they are unambiguous. Not just to you, with your great wealth of knowledge, but to someone of the students' level.
5) Plan to spend significantly more time than expected on all this. This includes time in class explaining things that you expected them to know or thought were obvious and outside the class preparing your lectures, labs, etc. Until you've taught a class 2-3 times, there are always time sinks that you didn't anticipate.
Good luck!!!
First, if they aren't "engaged" in learning Linux, why the hell did they sign up for the class in the first place? (Or is this a deparmental idea to force-feed Linux to a bunch of Windows-trained students?) Second, why is a sophomore teaching a freshman class? I have issues with grad students doing what the profs are paid to do, so I have serious issues with a sophmore taking this on. If the university/department feels this is an important course, it should be taught by a prof, particularly to freshmen. (Or does the department feel that a prof's time is wasted on lowly freshmen?) OK, so maybe more that two questions.
I'm biased.. But I think that the concept of pipes can really be impressive.. so
ps aux | grep username | grep -v grep | awk '{print "kill -9 "$3}' | bash
is awesome to understand.
Have them do a dpkg -l on a box and make an install script for hundreds of packages. Have them hunt for credit cards #'s using regular expressions, then pipe those through a cc# validator script (yes how to use a computer for evil-- a nice weeklong break of doing bad things).
Teach them how to use Wget to stalk on facebook... heck that will keep them engaged the most, though it does rack up their dark side force points a little too quickly.
RTFM
It's not spectacular, but I have some basic classroom materials up here: http://seandiggity.dreamhosters.com/cll
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
Not to be mean-spirited, but this generally means that either you don't have a strong enough grasp on the subject material and ability to relate it in terms to which your students can relate, or your students don't actually know anything, or enough, about computers, or you/they have too much system-specific knowledge and not enough general knowledge.
Computers are simply a tool, albeit a complex one, that can be used for many, many purposes. One must know the capabilities and, more importantly, the limitations of this tool. For that to happen, they must know how it works. Not simply how Linux works, but general concepts of what goes on and why. Better understanding of these are more universally useful as they are applicable to most other systems.
Teaching the "major ins and outs of the Linux terminal and GUI"? That's pretty basic, but the concepts are not specific to Linux. I would argue that focusing too closely on Linux specifics would be like teaching a class in Excel rather than spreadsheets. This can lead to tunnel vision later.
Case in point, we once had a fresh-from-college hire who installed SunOS - not Solaris mind you, so this was a long time ago - his Sun workstation, configured root's home directory as "/root" - as was on the Linux system he used in college - and then wondered why not everything worked as expected on his system. Granted, in a perfect world it would have worked, but in reality some systems and applications have assumptions for "root".
The lesson being: Learn systems in general, learn how they differ, tailor your work to the system. Just my $.02, with 25+ years as a system admin, system programmer on almost every kind of Unix (and, sigh, some Windows) systems known, from Cray to PC.
It must have been something you assimilated. . . .
don't bother..
That was the case for my introductory csc course; almost everybody already knew linux.
I read TFA and all I got was this lousy cookie
From my experience, the best way anyone learns anything at all is by being introduced to some aspect of it that is basic, fun, and practical to that relative interest(s).
The filesystem is one aspect of a computer system where the GUI and the command-line complement each other very well.
Navigating the filesystem graphically should be familiar to the students (esp. with Windows backgrounds) and the basics of "changing directory" (cd) and "listing" (ls) will demonstrate the basic elements of navigating. The drag-and-drop metaphor can be demonstrated with "cp" and "mv" and you can go from there to "find", pipelining, etc. Come up with some examples about what kinds of operations are easier in which mode.
[...] Teaching Linux [...]
Best thing is to not "teach Linux," but to "teach on Linux."
All hope abandon ye who enter here.
After you cover the basics, you should give them simple tasks which can be easily automated in shell but can take hours of clicking in GUI due to sheer amounts of data to process. These tasks can vary from sorting files from one big directory to several subdirectiories according to filename or contents to generating useful stats from a huge log file. And don't forget to make them both read and search man pages as much as possible.
I think that the trick may be to cater to their imaginations. The young have all kinds of desires concerning computing that adults may have shed off already. I'm still eager to recreate that certain girl from high school. The catch is that they have been exposed to some neat stuff through their friends as far as programs go. So try to sell them on what the future can do for them with computers. robots, etc.. Towards that goal Linux and Ubuntu in particular can make it rather easy to set up computing clusters. The imagination runs wild when we begin to think about what a few thousand high end personal PCs might do for us or for that matter a few thousand game machines all working together.
Replacing actors with a collection of characteristics from famous actors might spark their interest. There are already bands on tour where some of the instrumentalists are robots. And any software that they could work on to convert sound to a written score for the piece might hold some of them in eager attention. In other words take that god complex that lurks within all of us, that desire to be really powerful, wrap that with some goal to which they have a strong emotional attachment and try to build sample programs to accomplish each portion of the goal.
I can imagine having a wrist watch type of device that is uber educated across a variety of fields that interacts with my surroundings and speaks up with huge expertise when I am in various situations. If we could develop reactive, portable, intensely educated devices imagine what we could do. You could walk up to a milling machine like an advanced machinist with 40 years of top experience and do everything that machinist does. You would simply have to be willing to listen to the machine on your wrist direct everything that you do. If you want a tomato farm the machine could tell you every little motion needed to create and run that farm. If you want to invest in the stock market the device could control those actions as well. You would still have choices as the device could point out more than one great way to go. If you get that dream alive then you can talk about numerous programs such as compression and fast info access in both code and hardware in order to store and use such great sums of data etc..
Here are a few things which have worked in my classes:
1. Start from scratch. Give them an ISO of a command-line only Linux, like Debian netinstall.
2. Command-line only. Seriously. Give them a handout with the basic commands (man, dir, cat, touch, etc.), and ask them to figure out what they do.
3. For their midterm project (you're having them do projects, right?), ask them to build a LAMP server.
4. For their final project, have them build something to run on the LAMP server - such as a basic SNMP-based Network Management System, or maybe even a code repository if the class isn't that advanced. Either will force them to learn a scripting language, Linux networking, sudo, cron, file permissions, etc.
5. Finally, like so many other posters have pointed out, if you have some students in the class who already know Linux, turn them loose to create something of their own to show the rest.
I know it can be a bit of stretch for first year students to actually build and run a LAMP server, but really, these are things any CS student needs to know. There are a million step-by-step books on the topic, and I've had students quite regularly go from naught to Guru during a single semester. If the motivation is there, they will learn. Don't be afraid to push them.
This may mean allowing different student to persure different products. Some can build a web server, some can write an online application, so can write security utilities. I recall one class that taught fortran through the calculation of the radius of the Bohr atom.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
As others have said 'teaching computer labs' is a bit ambiguous. The fact that you are talking about a 100 series class, I'm assuming means something more along the lines of 'how do I work in this linux based computer lab', not 'how do I learn everything there is to know about linux'.
Though the majority of the people here are flabbergasted that those in a CS class haven't touched linux already, it is a different time. Keep in mind, those same people haven't touched VMS . . or punchcards. A brief history of linux and why it is useful couldn't hurt. Some key notes like the number of systems that use it for web based systems can bolster the view that it isn't just some basement nerds hobby OS. Brief = Brief, keep it 5-10 mins to keep eyeglaze from setting in. Some of the students are there for the joy of learning, some are there just for the degree so that they can make money. A few stats on how linux = money for them personally would be good, avarice is a motivator.
In your shoes, I think I'd cover the basics you'd need to know in any OS first. "How do I copy a file?", "How do I move a file?", "Can I get that deleted file back?". Moving up to how do I use the editors (both GUI and CLI). Knowing vi is great and all, but it can be a big mouthful the first time you look at it. Keep it simple. Most importantly, teach them how to find the answer to their questions when you aren't there. Linux has been around long enough that there are often a dozen ways to accomplish the same thing and some of the advice out there is outdated or just convoluted. Having some prepared cheat sheets for them would probably be good.
Once you've had time to cover the basics, spend time doing question and answer. You don't necessarily know how much exposure these people have had to Linux. They will have had experience with windows or mac os (and hopefully you have too). Let them ask 'How do I do X in linux that I know how to do in -myOS-'. This is of course dependent in how expert you are with those OS's. If your answers end up being "Its much easier in linux, all you do is X" you are going to win converts. If you can't give an easy answer, don't try while standing in front of them and fudgin your way through it; note it down and get back to them tomorrow. If you've ever watched someone try to figure out an answer in front of you, you can get misdirected by the different places the knowledgable user checks to get to the end goal. Many freshman enter university with a laptop, have them bring it with them. Often they can show you what they want to do quicker than explain it.
Cover the things they care about. If they don't know pidgin, show it to them (and how to remove it since these are shared machines). Here's your facebook page (I know, I'm ill suggesting it too), here's a feature rich office app to try out, and anything else the kids on my lawn care about.
Finally, show them how to interact with linux systems using their OS of choice. Just because you run windows doesn't mean you can't be a linux fiend. If they can get on servers remotely via SSH, show them how so they can keep poking at their own pace.
I wouldn't encourage them to install linux on their personal systems if they aren't familiar with it; they'll end up frustrated when they don't know how to accomplish a task and can't figure it out before the next time they get in to ask you. The minute they reinstall back to Windows/osX, you've likely lost them.
I'm a bit confused why a sophomore is teaching those 1 year behind... The professor is surely paid enough...
Uh, this is *computer science*, that is exactly the sort of thing they have to learn and understand and actually *do*.
I had a friend that had some prior networking training, but did helpdesk approach me about learning Linux. His ultimate goal was to learn how to be a sys-admin. I trained him well enough for him to get a real SA job. Here's what we did.
We got a cool but really old server he had out. It was a 4 way Pentum 233, with scsi, and raid (in other words an old, but "server class" machine). We started by installing Gentoo Linux, by building the stage 2 environment, then compiling the kernel. Along the way, I made sure he had a complete understanding of what he was doing. I think this alone took 6 weeks. He had to learn bash, and vi along the way so he could do what was needed. We covered the kernel, the init process, kernel modules, swap files, file systems, disk management, user management, permissions, logging, etc.
Once it was up, we never bothered with installing Xwindows. We built sshd, sshd in, and then made it into a lamp server. I also gave him assignments like figure out a way to serve up a file from your nas device over apache from your server, etc.
Once we did that, we switched over to Redhat Enterprise Linux, showed him the ease of working with a package based system.
Now that I recall, we used O'reilly's running linux as a general reference, and guide as well. After about a year of him learning it, and having me give him real world type labs, he got a Unix admin job for a major university.
print out this xkcd.com/627/ highlight the google one
and move on
warning pointless sig
but chris taylors' thesis is something i give to unix neophytes who might be interested in learning more about unix and vi.
it either scares them away, or draws them in, but that's up to them to figure that out, evangelism will eventually just wear you out.
IMHO taylors' writing style is amusing and might keep a reader engaged. even though it is unix agnostic i think the ability to speak to the uninitiated and offer them a quick stepping stone document without being overly cryptic or aloof is more helpful then sudden immersion into uber geekdom.
you want to scare a neophyte away, try encouraging them to read unix koans of master foo
three can keep a secret, if two are dead - benjamin franklin
You need to find a way to make it relevant. None of them are going to put in the time necessary to understand it if they don't see how it's useful to them. If the students are in a networking or security related program, maybe show them nmap, or kismet. If they're in a programming track, then LAMP would be a better place to start. Asterisk is also a cool proof of concept to show what linux can do. As I said, If you show them stuff that has no application to them or their field of study, then they're not going to care. The linux "cool factor" does not apply unless you already posses the geek gene, and more often than not, the people in today's computer classes are there because they think they'll be able to use what they learn to get a job and make money. Unless you can show them how linux can help them accomplish this goal, then it's useless knowledge to them.
I'd start with one of the introductions by Kernighan ... Software Tools, the C programming language, the Unix programming environment ... for me the key to unix was the idea that complex things could be built out of simple components ... and some shell programming ... from CLI to API ... that type of thing.
"Everything is a file." The rest is learning by doing.
I have been professionally teaching IT people since 1998. That's a really long time. It's not exactly the same as freshmen. Though I learned some things over the years:
;-D
Don't forget to talk about the history and the philosophy; while it might seem less important than getting everything in their heads; motivation is key. Because it's hard. Really hard; for them in the beginning. Motivation is everything. Don't waste your time with complicated stuff which can be easier (such as trying to fill their head with vim as joe is there too - if they like Linux, later they'll come back to vim).
Talk about the hippy-like Richard Stallman who got everything started and what the Free Software Foundation is all about; freedom in a digital future and such. And about the 'other side' within the community with the 'OpenSource' people who just think it's very convenient to be able to work together, but not morally wrong to write proprietary software. Whichever you prefer; 'welcome to the opensource community'.
Involve them.
If you can come up with something which can help them to accomplish something; go for it. Whether it's a LAMP box with Dyndns or something completely different. If they think something is 'stupid', point out that it's OpenSource, so they have the freedom to change it and fix it according to their wishes.
And don't forget: 'Have Fun!'
Good luck!
Jasper
He is a C.S. student teaching a freshman lab; nothing in his post indicates that the freshmen in question are C.S. students. In fact, since they're freshmen it's pretty likely they're undeclared. Yet already we see tons of condescending answers that are based on the assumption that this is a C.S. class.
I assume these are normal English, History, Physics, Education, Sports Medicine freshmen.
Show them the things they use every day...
- Pidgin
- Claws Email (or Thunderbird or Evolution)
- Firefox (Tab Kit, Sage, Read-It-Later plugins)
- Facebook - MySpace
- YouTube
- Twitter (some twitter client)
- Local University web portal, email
- Google -maps, voice, earth, news
- Picassa
- LibreOffice
- GIMP
- Amarok
- DVD::RIP
- WINE with Notepad++
- Synaptic for loading over 24K different "apps" - all free
- Update Manager for maintaining every app and the OS from 1 place.
and how to boot a LiveCD to rescue their MS-Windows system later. Back-In-Time for hourly, automatic, snapshots. Use the "smart remove" setting. Tell them there's no need for antivirus with Linux today.
Afterwards, ask them what else they'd like to see.
Ask who has Apple music players and tell them to go frack themselves.
Don't. That's what my school did, and it's very representative of the kind of help they'll get online. Have you ever tried to get help in a linux IRC channel? You're more likely to win the lottery and never have to use linux anyway.
I would teach them basic bash scripting, and about /proc and /sys. Then I would have them write scripts to automate extracting information from /proc and /sys in bash using grep, sed and maybe awk. Teaching them how to work with Linux from the shell and how to pull information out of the kernel like this should give them some good insights into the operating system and its tools.
Additionally, I would teach them how to write init scripts and how to do "fun" things to get them excited about Linux.
We *nix nuts often think that *nix is the best, but we also often forget that we didn't come to this conclusion of someone else's volition. We came to it because we learned it for ourselves. In general, the first psychological reaction of "do this because I said so" is "screw you." You won't "get them to connect the dots" if that's what you're blatantly trying to do. They will do it of their own volition, however, if you just be your enthusiastic self, and talk about why you like this feature or that. When they can apply the skills you teach them to their own projects, they will be hooked, but the key is that they have to do it.
If they're fresh to the *nix terminal, or *nix in general, start slow, and, for the students' sake, consider doing just rote labs at first. The major ins and outs of the terminal are many and varied, so covering them all will be difficult and overwhelming. Instead you might introduce them to the shell by way of a simple set of exercises (programming or otherwise) that build on each other week-by-week. As commands are needed, introduce them, but no sooner; any sooner and you risk overwhelming them. The first CS course has historically provided an incredible learning curve, not due to the conceptual bits you want students to learn, but to the outside learning that we take for granted once we know it. Small things, like the directory structure (i.e. strange/new/arcane compared to Windows), all the command line flags, and the excess of information that comes way too fast.
Skilled teachers introduce their subjects like a conversation: they don't blow their wad in the first 2 sentences. They start slow, introduce a concept, munge it, then build from there. Introducing the maze of power and concepts that is the shell really can't be done in one single class. Getting "them to connect the dots" is not within your control. Just as you can lead a horse to water, but you can't make him drink, so too is it with your students. Have a project into which they can sink their teeth, like building C/C++ program with a few different files, or writing a shell script to collect data from 5 of their classmates computers via ssh. When they can take ownership, they'll connect the dots on their own.
Finally, remember that this is an introductory course, so they likely will not know what you may think they should. They are not stupid, just uneducated on this subject; remember that they're there to change that.
Hopefully, at this point they can figure out how to use a GUI by trial and error. I would introduce them to the customizability not available on Windows with being able to choose Gnome, KDE, Unity, Avant Window Navigator, etc. Also little niceties like middle click pasting, multiple desktops, and focus follows mouse that they may have never seen.
Since they are CS students, I would also cover the basics of developing on Linux that may be unfamiliar:
Basically, cover enough so when a professor gives them a programming assignment in subsequent semesters, they should be able to focus on the code more than the operating system. A typical assignment toward the end of the class would reflect mastery of the development environment but require little programming expertise, something like "create a .deb package containing a program that displays hello world in a Gtk window" or "submit a git bundle with a change from hello world to hey there world."
This space intentionally left blank.
Why are you teaching an OS to CS students?
Seriously WTF... and to *freshman* no less?
I am afraid the sophomore has failed to grasp the point of CS, and unfortunately it looks like most of the posters here dont have a grasp either.
You do have to make some specific choices when teaching CS, but never the whole god damned OS as the 'subject.' You would choose a specific set of programming languages when teaching computational theory, algorithms, and so forth..
CS is not equal to "using computers"
"His name was James Damore."
Get them to install vanilla Slackware on their machines. For assignments: compile, package and run a custom kernel; configure, compile, install and run the Gnome desktop (no slapt-get); etc. At the end of term, let them switch to the distro of their choice and ask them to compare and contrast with Slack. They'll understand the fundamentals, appreciate simplicity, but also appreciate package/dependency management and other conveniences of some of the larger distros.
Disclaimer: Not intended as a potshot/criticism of Slackware, I just think it's got the simplest boot sequence, clean and well written scripts, and simple configuration. If you want more than that, figure it out.
If they are freshman in a college CS class and aren't familiar with *nix operating systems, it is too late. Just send those people on over to the business school, because they have no use in a CS department.
Find a few dozen poor middle or high-school kids, give them free access to a few machines running a very basic Linux install (RedHat, Ubuntu, CentOS, Slax, it doesn't matter) with free open internet and a link on the desktop to a browser pointed to sourceforge....and come back in about 3-months. Give them a couple of pointers, and come back in another 3 months. Sure, there will be tons of porn, hacked machines, torrents, malware distribution, and other trash. But there will also be 2 or 3 kids who LOVE CS and could put most of your current CS program juniors and seniors to shame. There will be another dozen who are at least proficient.
What does that tell you? It tells you that those who show up to a college CS class without such knowledge grew up in abject poverty or have no real interest in CS. College should be more about those who WANT to learn than about those who have their parents money and nothing better to do with their time. I don't have the time or the desire to handhold spoiled rich lazy shallow consumers through their acquisition of a CS diploma. Especially when they'll promptly brain-dump whatever they manage to pick up, and become a M$ buying CIO who still couldn't manage to write a "hello world" batch script. I'm not exaggerating. There are ALOT of CIOs who can't even find a Windows command prompt, let alone navigate a *nix.
Have them get an AMANDA environment up and running. You could run the clients as virtual machines for additional abstraction or use physical machines and even vary the client OS-type. It builds CLI knowledge, server configuration, client-server model, etc.
If this is a trade school then start right away teaching them how to set up a LAMP system as others have suggested. However if this is a university then do not teach Linux. Teach concepts. Linux is just one of various places to implement or try out these concepts. The LAMP system is something a university student should be figuring out on his/her own time.
... So in a compilers class the professor taught the concepts and theories behind parsing, code generation and optimization and the TA taught you how to use lex and yacc under BSD to implement a compiler for your class assignments. Similarly in a graphics class the professor taught the math and theory of 3D graphics, transformations, perspective, hidden line/object removal, etc and the TA taught you how to use dedicated graphics workstations (today this would just be OpenGL). Now if you wanted to use a different environment and tools you were free to do so but you were on your own.
My undergrad CS was in a unix-based environment(*). Professors in class taught concepts that could be applied in a variety of different environments. Teaching assistants (TA) in study/discussion sessions taught implementation detail like editors, compilers and other tools for the environment provided by the school - which in this case was BSD, vi, cc, lex, yacc,
So if you are a university and your labs are Linux based, great. Your TA's should help students with all the implementation details of getting their assignment going under Linux. However Linux should not appear in the classroom that much, it is just the tool of the day, more of an implementation detail than a core concept. The university classroom should spend most of its time on concepts that transcend the tools of day, regardless of whether that tool of the day is MS Windows, Mac OS X or Linux; or Direct 3D or OpenGL.
(*) FWIW this was a DEC VAX based environment. I would have loved to have had a Linux or FreeBSD running on my PC rather than having to dial in over a modem from home when not on campus.
Let's be honest. Kids go to college to learn how to make money. Explain to them what kinds of jobs they can get if they take the time to learn linux. My impression during college was that programming on Windows was a way to make money, programming on Linux was programming for fun or for a cause. Now I'm out of college making money programming on Linux and doing some cool stuff too. I would have paid a lot more attention had I known...
Perhaps you should try to get them into sales. If they are having trouble connecting those simple dots as college freshmen, they are clearly not computer people.
Have them set up a basic LAMP server. That's how I learned Linux. Or for something somewhat more practical for them, how about a seedbox or a mythtv-box. Frankly, the best way to learn linux is to just get your hands dirty.
Given that we are discussing freshman computer science students we are probably talking about a university environment, not a trade school. Linux is not really a legitimate topic itself, its just a tool, its just a convenient place to do class assignments while learning core ideas and concepts. Setting up a LAMP box is something university level CS students should do on their own time. For a longer discussion see http://ask.slashdot.org/comments.pl?sid=1952834&cid=34898826.
I agree. The only thing you should do is to show people briefly the possibilities of the system/software. They will either be impressed and interested and be learning it by themselves in no time or they are not really interested in the CS subject and you should indeed "not bother". I think the parent could be scored "insightful" as well.
One of the best experiences I had with learning linux was installing ARCH, which requires you to really customize the system as you install, not to mention some inevitable troubleshooting. While going through the installation process you are going to have to read the step by step guide, which covers some really great aspects of the OS and forces you to get comfortable with *gasp* the command line.
Granted there is a plethora of other things to learn beyond just an installation, but I found it to be a really great step by step learning process. Not to mention the distribution is as bare bones as it gets and forces you to choose everything you want in your sytem, thus making you LEARN about it.
Just install KDE 4 and tell them it's Windows 7 Education Edition or something like that.
PlusFive Slashdot reader for Android. Can post comments.
Make it relate to how they use computers... free... more options, games... playonlinux.com/en & secretmaryo.org & wine I run fedora using kde.. kde pacman, battleships... all the old school retro games.. make them be able to relate to it first, to the point where they can see the practicality and fun in using the system. then work from there to show them the web server sides, ftp server sides... unreal tournament 2004 shipped with a Linux install... the box has Tux on it. show them virtual box instead of vmware. show them nvidia has drivers.. I would suggest fedora 11, kde, with the games first ( biggest default of install games I have seen ) I then upgrade from 11 - 14.. its what i'm doing for my sister who is tired of windows and virus' . I soon have to try wine and her sims games, or playsonlinux which does a different implementation of wine. mpg321 command line mp3 player.. lynx command line web browser.. show them games, ease of use, free, and then move from there, once you have them.... rest should be good. vlc player .. hope that helps I understand that what I suggest is not ideal for school setting to introduce new students, so maybe before semester begins do some of this that way first class can be school related..
Get them to create a very simple command line application that takes a single argument and gives a single output. run it with the argument and see the output, all the other stuff is plain sailing afterwards.
Also do show off the many useful GUI admin functions that exist in modern linux, and tell em the most important thing about Gnu_linux/nix: everything is a file!
There are a LOT of things you could teach them... too many for one semester, in fact. My suggestion is that you start with things that will allow them to "feel" proficient with the OS first. Make Linux USEFUL to them. Assuming that this is a semester-long class, then this is my $0.02.
So, think: what does a freshman in college want to do with a computer?
- Check email
- Surf the web (ok, ok, look at pr0n)
- Download stuff
- Possibly do some sort of homework
So first few days, teach them how to check school email, ftp, ssh, etc. Every time you have to enter a server, show some basic network diagram of how you are connecting (ex: 192.168.x.x -> gateway -> internet ->target server. Be specific: specify ports, etc), and say something like "later in the semester, we'll learn how to set up each of these servers." That's a good segue into later classes on how to set up apache, bind, exim (or whatever), ftpd, etc. CS students may get guidance from their programming instructors about the nuances of the compilers, so I suggest just showing them how to install/invoke them.
Last part of the semester you can talk about hardening techniques. Require the latest/greatest Securing Linux O'Reilly book (I'm sure people from here can suggest books), and go through a high-level survey about how to secure services once they are set up. Show how to use netstat, iptables, nmap, etc etc. Re-reference the basic network diagram and now tell them what ports are, and why they are important.
My feeling is that if you show the students HOW to do something, being CS students, they'll want to figure out WHY it works. At that point, they dig as deep as they want into it.
Good luck!
This message was posted using recycled electrons.
It's funny you should ask as I've written and delivered just such a course (sadly copyrighted but not CC'd).
You didn't give any real specifics so here are is some general opinion/advice:
1. Most people in a CS course know at least one operating system well enough to be productive. At root all OS do the same things, they just do them in different ways. Compare the following across three OS:
a. boot sequence
b. directory structure
c. desktop environment
d. development environment
e. application management
f. security
g. networking
h. multi-system management
2. All material should be delivered in practical fashion, all key concepts/techniques should have immediate practical example.
3. Teach the history, and start with Knuth and TeX. The context and justification of the development and design of the OS, and its development process (at least as important), is crucial. This can make it much easier to explain why things are different, why things are similar, and how they all work together. It's also great material as the personalities are often powerful and idiosyncratic, and the stories almost parables.
Have fun. It's one of _the_ most enjoyable classes I've taught.
science in government
> By the time someone is 17 or 18 years old, they either know Linux or they don't. At that age, they've got their lot in life and if they haven't picked up Linux stuff by now, fuck 'em.
That's a remarkably shortsighted view. The tech community is better off being welcoming, and the economy is better off when the tech community is welcoming.
I didn't know linux when I went to college. I learned about unix-based OS/s there, though only a little bit from the school. Using it on school systems taught me a bit, but I didn't really begin to get it until I started running a second machine as a linux mailserver, and then switched my main one over to linux after six months or a year. By the time I graduated I was one of the leaders of a student group that maintains dozens of services for hundreds of orgs and thousands of users.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
Don't spend a lot of time in the start teaching them about Gnome or KDE. That will just give them the impression that Linux is fundamentally the same as Windows or OSX (Yes, I know OSX is BSD based but one of it's prime selling points is that the user doesn't have to think about what's under the hood). The danger in starting with the GUI is that they'll get the impression that the GUI is the OS and all the /etc, /bin and /var stuff exists to support the GUI when the opposite is more true.
/home/cs101/assignments/ . Replace {username} with you username on this machine. (introduce `tar czf`, introduce cp)
Give them all a user account with shell only (no X) on some headless machine somewhere and make them do their work there. Have it be a different distro than what their desktop machines are; in your case I'd recommend CentOS as being different enough to understand that there can and will be some variation between two different "Linux" machines in the real world. Teach them to actually do work on a machine that they have no physical access to and make sure they "understand" (rather than simply "know") that physical access to a machine is not required to do real work on that machine. Make them do their work in vim or emacs and turn it in by dropping tarballs into a shared directory.
Somewhere about 3/4 into the semester, bring them over to the GUI and show them a IDE like netbeans (free, easy to use and supports a decent variety of languages). Spend your GUI time teaching them that on *nix the GUI exists primarily to support tools that exist in the CLI.
On the last week that isn't review, give them access to a Solaris and a HP-UX machine and give them an assignment to do on both machines that is similar (but not quite identical) to something you gave them just before the GUI switch.
Possible first assignment: (notes in parenthesis are for you and not to be included in the actual assignment)
1. Create a directory named "assignment-01" in your home folder. (introduce mkdir)
2. Within "assignment-01" create the following sub-directories "pets", "color", "os" (introduce cd)
3. In the os directory create a text file named "home" with one line naming the OS you use at home. ex. "Windows 7", "OSX Snow Leopard", "Amiga OS", etc. (introduce vim)
4. In the color directory create a small HTML web page named "color.html" complete with well formed <html>,<head> and <body> tags. In the body of this page name your favorite color and make it display in that color. If your favorite color is white or too light to read on a white background, change the background color to black or lie about you favorite color and pick a new one. (multi line editing, interpreting requirements, that warm fuzzy feeling of making something "real"; check for opening and closing tags on html elements, mention in class bonus points if they include a DOCTYPE and/or a page title but do not list in the written assignment)
5. In the pets directory create a Comma Separated Value, CSV, file with one line per pet in your home. The column should be as follows {Pets name, type of pet [cat, dog, goldfish, etc.], latin name for species}. All columns should be wrapped in double quotes. If you have less than 3 pets, create imaginary pets until you have at least 3. (create machine readable text files)
6. In the assignment-01 directory, create a text file named "hello" with one line reading "Hello, World" (necessary for a later step)
7. create a tar zip file with the name cs101-{username}-01.tar.gz of the assignment-01 directory and copy the resulting file to
8. Move hello from your assignment directory to your home directory. (introduce mv)
9. Since you're on Linux now you need to let go of your old OS. Delete the os subdirectory and it's contents. ( introduce `rm -r` )
10. Make sure your instructor can review your work by making the assignment-01 directory readable but not writable to the cs101 group. (chmod, ls -l and maybe chgrp)
My God! It's full of eval()'s.
...I'd advice that anyone who would send their kid to a college where a SOPHOMORE is teaching a lab to pull their kid from that school.
I was a university CS professor for most of my career, and the easiest things to teach students are the things that they want to learn. What that is will vary, but working in a lab, one on one, you will have a lot of opportunities to find out what the individuals are interested in. Don't worry if it's not the same thing to every student; they will talk and teach each other what you have taught them, and they will learn it better that way
The one thing you can can be certain they want to learn are things that will help them get a good grade in the course. So if it is a programming course, teach them how to login, manage files, and to use whatever IDE you are using for the course, whether it is vi, emacs, eclipse, or something else. While you are doing that, talk to them and see what else they are interested in, and try to run with that.
I disagree with some of the comments here that have suggested philosophy and history. That is great stuff, but do not make the mistake of thinking that just because it interests you, it will interest them. Give them a taste, sure, but dwell on things that will help them get a good grade, and then let them suggests breadth or depth beyond that.
Oh yeah, sed, awk and regex are going to convert Windows/Mac users to command line Linux.
Not.
Linux is for people who want to hack around and get to the guts of the OS because they're interested in that sort of thing. Everybody else is going to be too distracted by the fact that flash doesn't work properly.
No sig today...
Give them a box of computer parts and a printed copy of linuxfromscratch.org and tell them their grade for the class is going to be the one displayed on a web page served by apache under Linux installed on the machine they assemble from those parts by the end of the semester. Best class they'll ever take on Linux.
Ahhh, the relentless energy of a young, new teachers assistant who will expend countless hours in the pursuit of "something" in order to feel like he is helping freshmen out. Don't get me wrong, good on you for getting into this endeavor, teaching is very rewarding and will sharpen you ability to interact with people very quickly. That being said, if you do not have clear goals to teach, you will quickly spin your wheels, loose the interest of your students and become very frustrated. You said you have a professor you are working under. Apparently he or she is not very good at expressing the desired end state of the class. Or you are not a very good listener.
Teaching is easy. Answer these questions:
1) What skill, knowledge or technique should a student have mastered by the end of the course.
This list should be extensive, but finite. Once again ask your boss.
2)To what standard should each student be able to execute, recite or whatever the aforementioned tasks.
This is not your standard. You are not an expert, you are a college sophomore. Find the expert (presumably your boss) and ask him or her. If he or she is
not the real expert, find one.
After numbers 1 and 2 are answered, complete the following:
3)Constantly evaluate the students to see who is progressing along the learning continuum. Some will soak it up like sponges, some will be too high to know what day
it is. Focus on the students who want to be there and use them to leverage the fence sitters to your side of the fence. Let the ones who will not put in any effort go.
4)Repeat step 3 until the semester is done.
5)Take a well deserved drink.
Seriously. If you do not have clearly defined, articulated, measurable tasks and goals, you need to get into something touchy feely, like philosophy.
OS X has a command line. If there's a reason to switch, that's not it.
Do you even lift?
These aren't the 'roids you're looking for.
WTF? An introduction to the Linux command line/shell (pipes, "find", etc) might be useful, but teaching a GUI to CS students is just insulting and a waste of time.
Has it occurred to you that the problem might be you and your choice of topic rather than the students?
For a "linux terminal" class with some meat to it, how about a Perl class instead?
Say what you will about Eric S. Raymond, reading his (free) book The Art of Unix Programming is the best way to understand the design philosophy behind any Unix system, not just Linux. And it has general applicability as well.
I learned Linux by installing it on my desktop and forcing myself to run it as my primary OS. What taught me the most? When things went wrong.
I recommend coming up with ways to break the computer wherein fixing it will cause learning. Start by assigning the use of a utility or system service that is actually configured incorrectly and isn't running. This teaches things like: run the program from the command-line to see what it is outputting to stdout, look at log files, edit configuration text files. Make things harder by breaking boot services, changing the xserver configuration so that it starts as a command-line, etc. Finish by breaking grub, or deleting /etc/passwd and forcing them to boot into single-user mode to fix things.
Troubleshooting a computer is the best way to learn...
The Right Reverend K. Reid Wightman,
These are CS students. Discounting the ones who will be quickly switching majors or dropping out, sed, awk and regex are going to convert Windows/Mac users to command line Linux.
Really, it's just plain mean to wait until senior year for the weed out class. Freshman year is the time to ditch people who think that a love of playing computer games means that they will get to enjoy a well-paid career as a game designer.
Once they are setup with a linux distro, tell them that they need to obtain an application that will allow them to read and write Microsoft Office format files. "What?" "How much will that cost?". Introduce them to OpenOffice. Require assignments to be submitted in OpenOffice format.
...I'm Your local UNIX guru. Today You will learn that everything You have learned about computers is fundamentally WRONG.
Today You will learn a flavor of historys most successful operating systems, an operating system running on everything from the biggest supercomputers to the smallest PDA.
Today You will learn Linux.
In order to really get any appreciation for Linux whatsoever instead of a bunch of students that are in the class because it's required, the students have to have a practical use for it.
I tooled around with Linux for a few years off and on but really didn't get into it until I wanted my own web server but didn't want to screw around with IIS.
Since then, my practical uses for Linux have increased to include things like a thin client server and network security monitoring/data aquisition. The point is: it has to be useful to them personally.
The game.
If you're trying to teach OS concepts, I found "Operating System Design: The Xinu Approach" (Comer) a good text. Otherwise, have the kids install a LAMP stack.
Luke, help me take this mask off
Teach them a variety of Operating Systems and operating system concepts, keep ideologies away from teaching, your students will benefit more.
what does linux have to do with intro computer science, seriously? if you're teaching a class to network admins or a class on OS's then maybe. but intro cs should just be programming, data structures, big O, sorting, searching, etc.
sounds like youre just a linux geek looking for an excuse to convert windoze/mac fanboys
1) If they aren't interested by themselves (or learn by themselves) why the fuck are they studying CS to begin with?
2) Shouldn't you have a plan with _WHY_ you want to include Linux in the class? What's the purpose of the course? Just because it sounds good with putting Linux on a piece of paper? Then maybe you shouldn't have created the course.
Personally I guess I would had started with users vs super-user/root, groups and file permissions, process ids, pipes, jobs, man, basic vi, shell-scripts, regexp/sed, crontab, ...
Me too was in the same situation this year. I had to teach the command line interface and a bunch of commands. I wanted to make things more funny and incorporated a few add-ons besides plain "I do - Now you repeat". So students could learne command line interface while doing something that kept them motivated. Some hints in no particular order:
1. As a number of people suggested: LAMP in a nice try. Setting everything up was good but THE promise that we will create a phishing site at the end was what kept them going :). We just saved a login page of a bank, learned some HTML on the way and wrote a simple php echo script which printed username and password on the screen. We learned, config files, file system, editors (I showed some, but they all prefer Gedit :)), cron, tail (for logs), etc.
2. Cracking passwords is one of the most funny examples I do. This year I used Gawker's list of leaked password hashes, a small dictionary of 100 most common passwords and John The Ripper (cracking 700k hashes in 14 seconds on one core). While adapting the list and the dictionary we used awk, sed, wc, grep (I cant remember what else ;)), pipes, explained the file system, etc. Students really loved it!
3. I also taught them nmap (with e.g. redirecting IO to a file), telnet (sending email on a SMTP is always interesting), traceroute, tcpdump (on a gateway when they login to a ftp site so I collect (fake) passwords :)) and similar examples that (I hope) keept them interested.
4. Bash scripting can be taught with some simple yet useful examples. This year we created a simple script that creates a HTML photo album from images in a folder (checking if the directory is empty, splitting file names, checking extensions, renaming, using image magic to figure out file detailes, etc - needles to say we used a lot of command line commands).
Through all these examples students learn a bunch of simple and more complex commands.
We did it most of these exercises in a sandbox, they had to install the who OS (Ubuntu Linux in my example but command line interface is the same in all distros) and a lot of commands themselves and they were administrators of their environments which made them happy.
Someone suggested that such examples could rack up their dark side forces - before hacking passwords or using nmap I TELL them to use this knowledge for their own security and what can happen if they put their noses in someone else's system uninvited.
Hope it helps you (or someone else).
lp mk
If they haven't already looked at linux, it's because they lack the innate curiosity to find out more about their chosen profession.
These are the types who will mostly not graduate beyond "I can admin a server because I know where to point and click" anyways.
Even the simplest of tools, like vi or ssh, are pretty much beyond them.
Wow, what an arrogant, asinine point of view. These are college freshmen that we're talking about here. Yes, there's a good chance that many of them have had no exposure to Linux, since statistically speaking, most college freshmen probably come from households which have only used Windows or Apple PCs. They're majoring in computer science because they want to learn about computers, not because they already know about them, duh.
I'm glad that I didn't have teachers, parents, or friends with this attitude. When I started out as a computer science major, I knew my Commodore 64 in and out, but I had maybe touched an Intel-based PC a handful of times. I was dumb as dirt too, and I didn't know a damn thing about various Unix- or PC-based editors. I was motivated, though, so I came up to speed. Believe it or not, you were dumb as dirt at one point, too. Back when vi and ssh were beyond you (and I'm 100% sure that at one point, they were), how would you have liked it had someone told you that those simple tools were pretty much beyond you, and that you probably would never graduate beyond "I can admin a server because I know where to point and click"? Such comments are completely non-productive, and irrelevant to the submitter's question.
Maybe some of them will drop out of CS. Maybe some of them really don't understand what they're in for and will leave. But then again, I'll bet that there are quite a few who are going to college to learn about stuff they want to know, not more about stuff they already knew. Some will undoubtedly be part of the next generation of people who will make fun of you someday as one of those old fogies who can't keep up with the stuff they're working on.
Timothy,
I have been teaching high school students, college students, and colleagues for almost 20 years. My lab is running all Linux PCs. My high school students have been compiling and running Linux distros every other year (Even stage 1 Gentoo and LFS). They also learn C++, PC Repair, and Networking (CCNA). If they can handle a good immersion in Linux, so can your students. If I were in your position I would:
1) Look up the certification standards - LPIC-1 is a good place to start.
2) Look at some comparative curriculum - Buy TestOut, get a book from the library, etc.
3) Update the computers that you are using (with permission). Hardy is way too old.
4) Plan the topics that you will cover.
5) Teach to the students strengths and interests.
Good Luck,
ST
Use OpenSuSE, everything in OpenSuSE can be done thru the GUI: installation, configuration, administration, software maintenance... everything.
Don't use the command line when it is easier for you, it will be interpreted as missing GUI functionality.
The problem as I see it is this: "Back in the day" (hah!) when I installed Mandrake for the first time, then Red Hat, then Slackware on my store-bought "first PC" at university, of my own volition, it was an absolute pain in the fucking neck to get it working. There seem to be a lot of people who are saying "the best way to learn is by installing it yourself" or "if they haven't already tried it they are n00bs and should quit CS and take up needlework". But the fact of the matter is that when most people try "Linux" these days, it's Ubuntu, which, I hear, is a piece of piss to install. Hell, the last time I installed Slackware (aside from the clunky-looking installer) it was incredibly straightforward.
My point is, there's actually value in teaching the inner workings of Linux because there's no guarantee anymore that you'll encounter sed, awk, vi or even a command line just because you're using "Linux".
Here are all of the documents from a class I taught. Advanced Linux Usage, a special topic course.
https://docs.google.com/leaf?id=0B1VZQff8I3deMGFhODA2MTktODBjNi00ZjA0LWE5ZGMtMjMxNDFmOTRmOWUz&hl=en
Includes Syllabus as well as some quizes, exams, and class notes.
feel free to email me if you have any questions. willm.wade(at.)gmail.com
And how exactly is that supposed to give them programmer level proficiency in CLI and basic understanding of system structure, which is probably the sole point of the class?
I think that the heart of any OS is found on the command line. Yes, you need to learn vi(m) and maybe emacs, but I think that can be done by using them to do other tasks.
I developed my skills through shell scripting. A great book on the topic is Unix Shell Scripting by Stephen G. Kochan and Patrick H. Wood. The concepts are usable in just about any environment, plus they'll learn the main tools found in the shell.
The first day I'd assign reading Neal Stephenson's "In the Beginning was the Command Line" ( http://www.nealstephenson.com/command/ and http://www.cryptonomicon.com/beginning.html online ). I've used it in situations with even non-technical people to explain "Why Linux", and it's highly entertaining even if one is an expert. As another poster said, there is some "History and Philosophy". I also use it as an ESL text for engineering graduate students :-)
I used vi for years, and had convinced myself I actually preferred it to, say, the editor in Visual Studio. It's definitely true that there are things you can do super-fast in vi once you commit its commands to sense memory - once you've mapped the brain-dead 'join' command away from the Shift-J keystroke. Is there anybody who hasn't been driven nuts by having their entire file collapsed into a single line just by trying to 'scroll down' with Caps Lock on?
That said, I've gotten used to using a PC editor (EditPlus) on files in a Samba-mounted filesystem, and I'm probably not going back. Not a second too soon, it turns out, since the unix server where those files live has been moved to another site, and vi over a VPN is nasty. I still find it useful for quick editing at the command line, though - in a DOS command window too. But if you're gonna teach 'em vi, teach 'em how to remap the commands while you're at it.
Posted from my Android phone. Oh, I can change this? There, that's better...
You really need to break their will - to use the GUI. It's not terribly useful for people who will be using Linux as a server or development platform. They don't need a course to tell them these basic, largely intuitive things.
They need to start from the core of the system; ie, what the system does as it boots.
Walk them through that. Have them read over and analyze the output from dmesg, for starters.
Then start them with some basic console commands. ls, du, who, ps, top, mv, cp, ln, rm, kill, ed/vi/nano, find, whereis/where/which, less/more/cat, and echo are useful, but also be sure to let them know how to find help, and where to look for things - man, apropos, info,, etc. Be sure to include the process of how to use these commands adeptly: man and apropos will go a long, long, long way.
I can't emphasize the use of apropos and man enough. Teach them how to use these things - ie, "how to help yourself" and they will be competent Linux users able to adapt to a myriad of other systems as well (with time).
Touching on hardware interface commands (lspci, lsusb, etc.), system proc files (/proc), exit codes, lsof, and other "programmer useful" things would be nice, too. Package management (dependencies, managers, frontends, interfaces, etc.) would likewise be useful.
Once they understand the kernel boot process, the basics of shell operation, and the system boot process (init/upstart/rc/whatever), they should be well on their way to competence. (Then, of course, there are the usual 'gotchas' everyone runs into in their course of growth - the accidental rm -rf, or killall on a non-Linux system, for instance.)
I would verge towards overloading them with work to encourage them to dig in, instead of going too lean. If you must, grade on a curve - there's a lot to learn here if you're not a competent "professional" already, and a lot of stuff to "unlearn", if coming from the Windows side of things (eg. "errors").
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
If none of those reasons sell someone on Linux, then they most likely will be happier doing something else.
If I have seen further it is by stealing the Intellectual Property of giants.
Actually... :)
My girlfriend has a Mac. Right now, I have a Windows machine beside hers, because I'm gaming on it a good bit. I make up for this by having a Linux server farm, so I do "real" work on those machines.
She's seen where I've had issues on my Windows machine. I get frustrated. She watched me work through a mystery blue-screen problem that turned out to be a particular version of the video driver was causing. It was very difficult to diagnose, and using the Microsoft provided driver, or the manufacturers most recent driver was not the fix. {sigh}
On her machine, she was running into some issues also. She plays a few full-screen games. One of the games was performing horribly. To diagnose it, I ssh'd to her machine while she was gaming. Using standard tools (like top, ps, and kill), I was able to help her out. For example, from the desktop, she knew she had closed an application. From top, I could see that it not only wasn't dead, but it was taking up half the memory in the machine. While she was playing the game, I could see the system was using over 80% of the memory (2Gb), and and when it started swapping, that's when the performance went to hell. I helped keep the machine performing ok by killing unwanted applications while she was playing. You can't do that on a Windows machine without a bit of 3rd party magic and virgin sacrifices.
Then there was parsing some information. She has a book cataloging program. She wanted to import the information from one application to another one. She pointed & clicked around for a while, and was making very slow progress. She was to the point where she had a file with almost 2000 records, that she needed to clean up to import. It would have taken her quite a while, so I shelled in and did "cat file.txt | cut -f 2 -d , | sort > import_me.txt" Voila, one line, and it was done. Again, standard tools for *nix, Linux, and OSX, that are not standard for Windows (adding 3rd party apps doesn't count).
I've been trying to encourage her to get familiar with working in the shell. She understands what to do.
We're to the point of wanting to set her up with a hackintosh. I have spare hardware that would build her a very nice fast machine with more memory than hers has. Even the 2GB upgrade was expensive for the Mac. It's outrageously priced from Apple, and still overly expensive from 3rd parties. We ordered it from Crucial, who had the best price for the required full buffered RAM. She likes the idea of my spare 6GB RAM, and faster CPU, than spending thousands on a new Mac. Her only consideration now is how pretty the case is going to be. There's an alienware-like case on CompUSA's site that I'm considering for her. :)
Serious? Seriousness is well above my pay grade.
Doesn't this answer your problem? http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/
Make some exercises through which they'll learn command line. Few examples I used (in a practical course for freshmen):
1. Cracking passwords: We used Gawker's leaked list of hashes, a 100 words dictionary and john the ripper. We learned, sed, awk ("editing" the list), touch, editors (they all ended up writing in Gedit :)), wc (counting lines), installing applications, and whatever command suits you here.
2. Create a phishing site: set up LAMP, did some configuring, saved the login screen of a bank, learned some html, created a php script that printed the user name and the password on the screen, used editors, installed applications, cp, mv, and whatever command suits you here.
3. Net tools: these are always interesting like ping, traceroute, nmap (finding services and software packages and search google for holes - have your own example), telnet (sending email on a SMTP server), whois, dig, tcpdump (scan the traffic on a gateway grabbing password while they try to ftp :)), ssh (make them create users for other in the class to log in to their machines), scp (make them copy one file to other computers), ddosim (we compiled it and simulated ddos attack on the LAN)
5. Shell programming - nice to include all commands they already know and new ones. We did a simple script that created a HTML photo album from a directory of images. The script included checking if the directory is empty, splitting files, renaming them, checking for extension, imagemagic to find image details and conversion, etc. etc (do a lot of checks using a lot of commands)
They all had to install their own VM in which they had total control and they also had to install a lot of packages which weren't installed by default. They were administrators on their machines which they really liked! They could have their VM's running and ssh to them from home.
I also agree with others that some concepts must be thought, but the students must have fun as well.
lp mk
Linux is for people who want to hack around and get to the guts of the OS because they're interested in that sort of thing. Everybody else is going to be too distracted by the fact that flash doesn't work properly.
Hmm. People who want to hack around and get to the guts. People who are interested in that sort of thing. You mean like...CS students? You know, the people the whole question is about...
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
If you are not running Linux in a Virtual Machine do it. then they can take root control when ever they want Mess up there config and then go back to a save point or just reinstall without messing up others work. Install Some current and older versions of them as as files to distribute. If this is a class where they should be comfortable messing around with things, stuff will get messed up but they should try to fix it first, then restore/reinstall. Slackware a few years back was a good one for CS people who wanted to learn there was little in the way of gui config programs so you would look on pages like linuxquestions and retype parts of config files to make it do what you wanted. it also did not have package utilities so you would have to compile your own code and find what it depends on. But the big thing is if they are CS students they should not be afraid of there computers, they should be able to complete most any task they can in windows by using the open sourced programs that are out there like Libre office, Fire fox, Gimp, etc. they should know that wine exists but take pride in using it as little as possible. Hopefully they will use linux as a 2nd os on there computer or on a virtual machine (Some laptops still have issues with linux so a VM helps solve those problems) and most of the open sourced programs are also around for windows so they can use those in there every day life. Hope that gives some ideas of what I would look for in a class like that as a CS Junior .
You can do all of that in powershell as well. But I expect you are still using windows XP, and wondering why it's acting like a 10 year old OS.
I've taught an intro course to UNIX and systems administration to MIS students years ago. The concepts are the same for Linux. And I've got a pretty good background in instructional design. If your students are starting off, teaching them complex sed/awk stuff, packages, pipes, and the GUI is going to start already leaving them behind. And there are so many people who work on that stuff, but don't understand the basics.
In the course I taught, I started with things that many of them, even the Linux users among them, never knew about their systems. Such as the fundamental that *everything* in UNIX/Linux is a file. Directories are really files. The keyboard is a file. So is the display. And the network card. That is an important concept to understand later why redirection, pipes and the like work as well as they do.
I also taught things like symbolic vs. hard links. And how that all relates to inodes. Therefore, how you can move or copy files and create symbolic links that can change the one or the other. True of just about every file system.
Then you can get into how processes work. And how all of them spawn from one root process (initd). Children, zombies and the rest come into play, and the kill command, and how to use a tool like top to see how they all work. And how to reset them when they run amok. I used Mark Sobell's book on UNIX, but he has newer ones out on Ubuntu and Linux and such as well.
You can then continue with a basic editor like vi, which is a good one simply because it's likely going to be on just about any system they'll come across. Emacs is not as ubiquitous, so I won't get into a war over which is better. If you like emacs, you can install that too, but some systems won't have it and you may need basic vi or even ed skills to get the box going enough to get emacs installed. The same is true for shell programming. I would use bash, simply because the context and syntax carries across most systems well, regardless of the type (Linux, BSD, Mac OS X).
Once they get all that you can get them into pipes and redirects and how they can be used to create wonderful things by coupling lots of simple tools together.
And all of that even without a GUI!
Ich suche die Leidenschaft, die keine Leiden schafft.
....why am I paying $20,000 a year (on the low end) for my kid to go to school and study Computer Science just to have a freakin sophomore teach him?
Major WTF?
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Roughly, this is how the labs are laid out:
Week 1: I have the students install Ubuntu via wubi. Wubi isn't without its problems but it's a good compromise to our Windows-only systems. Having the students do the installation is a learning process in itself. Explore the Ubuntu interface, list out applications, compare to Windows, etc. Install software via Synaptic.
Week 2: Command-line exercises. I set up an Ubuntu machine where they can log in. I give them stuff to do with files and directories and such. I have them create HTML pages, compile C and Java programs. I have them use "The Linux Command Line" as reference.
Week 3: More command-line exercises. Stuff with sort, grep, find, cut, etc. I have them do stuff that's difficult to perform with GUI but easy to do with CLI.
Week 4: Students install VirtualBox and a command-line only virtual machine. This gives them an idea what it's like to install Ubuntu on a full system. Optional: install Ubuntu on USB flash drive.
Week 5-Week 6: Students install the LAMP stack and some popular CMSes like WordPress, Joomla, Drupal. Again, I force them to use only the command line.
Week 7: Students install and work with Tomcat. Just some basic programming and deployment with Netbeans. This provides some perspective beyond PHP.
Week 8-Week 9: Programming languages: assembly, C, Java, Python, Perl, command-line PHP, Ruby. Not too in-depth, just enough to give them a taste of each. I use combinations of ps, time, and strace to explain processes and system calls.
Week 10: Wine, with some Windows games, and Dosbox, with some DOS games. Used to explain system calls, APIs, and emulation.
Week 11: Explanation of the Linux boot process and Windows boot process. See my presentation (needs some updates.)
Week 12-13: Compiling the Linux kernel.
Week 14-15: Linux networking. DHCP, DNS, routing, mail services, etc.
Week 16: Webmin
Week 17-18: Their choice of operating system to work on.
Every sem I tweak my labs further, but more or less, it's laid out as above. So far, the response has been good. Enrollment varies, but at one time I was getting 100 or so students to use Ubuntu. As an added activity, we run an open source mini-conference in school for other students and Software Freedom Day. Some of my students eventually get jobs involving open source.
Drop me an email if you want to trade notes. I'd be happy to share some of my lab exercises with you. I also teach an information security class (using mostly Ubuntu, too) and an open source class. Our class blog gives some idea of what the students are working on.
how dare you show a /.er common sense!
I rarely post on /., but this is something I feel I need to get my $0.02 in on. I love computers for the power that they give you to solve problems. I have a BS in applied math and an MS in CS. I hate linux. I have a linux system and I absolutely hate having to deal with it. In fact, I don't have any coworkers that like to work with linux either. There's a simple reason for that. I see a computer as a powerful too to help me write software to implement my algorithms. Anything that makes that process take more time annoys me. Linux is for people who like to tinker with computers. Some CS people just want to write algorithms, or just want to write beautiful interfaces, or maybe just make interesting applications. There are others that love the OS and its interface with the hardware. Remember to keep in mind that just because someone is a "CS student" doesn't meant that they should know how to use, or even like, linux. Telling intro students that they have to either like linux or GTFO is counter-productive and you could drive off someone who could have made great advances in CS otherwise.
Actually, I'm on Windows 7 x64 Ultimate.
Lets consider what comes with the OS, not what you have to install. I know cygwin does a lot. I see that there's a SUA "Utilities and SDK for UNIX-based Applications_AMD64.exe" that Windows has available, if you have the "Subsystem for UNIX-based Applications" turned on. You still have to download almost 500MB from Microsoft, so I won't consider that "comes with the OS".
In Windows 7, lets poke around with powershell, as you suggested.
Oops, that doesn't work. Ok, lets try a few other things.
Ok, that really sucked, and was really ugly. I had to snip out the other 7 lines on each error to get through the filters on here.
I already know "which" works on OSX, so lets look around OSX.
Nice. How about an older Linux machine...
It can pretty much be said that any OS other than Windows, comes with the same standard tools. But hey, some people love Windows. I use it a lot too. I have to support an awful lot of Windows desktops, and servers. Standards there are rough. There are plenty of things that give Windows admins headaches. Just try telling a user how to do something without first asking "what version of Windows are you using", or already knowing. Knowing your average user, if you ask, they won't know. And yes, I was just brought in to a place where a lot of the desktops are still WinXP, and don't have enough memory nor drive space to upgrade to anything else.
Serious? Seriousness is well above my pay grade.
Teach them the differences between the two major Linux distributions, Debian and Red Hat.
And how these difference( Configuration Files, init scripts, file system layout, etc, etc, etc) make it a total pain in the ass when trying to learn.
[/endrant]
I found that learning about the toolchains, the reasons for having sources (or just headers) available on-system, and compiling my own apps from sources has had the effect of really showing me (and others, who I've had go through these concepts) how the openness of linux ties in with programming and creating software.
This is damn crazy. Let them figure it out on their own ok? When I was a freshman did any one teach me how to use the cdc cyber NOS? Dec VMS or TOPS20? NO!
We found the manuals and read them or figured it out on our own. STOP HOLDING THE CHILDRENS HANDS.
Don't teach them Linux unless that's what the class is about.
My 1st-year CS intro course (CS 1300) was taught in Python, but that's not particularly important because virtually any decent programming language is acceptable.
An intro CS course should be focused more on things like algorithms, data structures, time/space complexity, and other theory. It's not the place to teach system administration and it's not the place to teach software engineering.
Pragmatically speaking, people are going to have to compile and run code. So you might end up having to teach some basic Linux skills. At my university we ran RHEL 4.x on the lab machines at the time (now they're on Ubuntu), and there was a weekly lab section where the TAs could provide 1-on-1 instruction on how to get things working. A substantial fraction of the class was already familiar with Linux, but there were also a good number of students who weren't.
The point is that the mechanics (e.g. "type make") should be addressed during the labs if possible, or in the instructions for the assignments, or during office hours, or during an (optional) concurrent course. The intent should be to provide the necessary skills for students who have no Linux background without devoting much of your (very limited) lecture time to it. If you spend a week or two trying to teach Linux, you'll find that 1/3 of your students don't show up.
That's so completely wrong I just don't where to start.
Linux (with the nvidia binary drivers) gives me the power of a minicomputer (I'm an old CLI geek) and us (me, wife & kids) simultaneous access to modern s/w and h/w without having to worry about malware.
(FreeBSD is certainly in the same class, but I have no reason to use it instead of Debian Sid.)
"I don't know, therefore Aliens" Wafflebox1
Try a Linux from scratch or source distro against a binary distro to show how the system is integrated and the fact that a source distro can have gcc and glibc replaced and recompiled vs a binary distro which is a nightmare to wedge in or damn near impossible. You can show tool chains and from command line to gui use and compiler intricacies of various code bases and libraries. People should go from learning source code distros first then move on to binary ditros so they have a better understanding of package management and how their system can go haywire fast jacking with mixed up repositories.
and beer
Windows is not *nix, so yes, it doesn't use the same commands. Then again, why doesn't linux support DOS/CPM commands? While *nix commands are text-stream based, Powershell uses a more modern object oriented approach.
top: Get-Process
top using WMI:Get-WmiObject Win32_PerfFormattedData_PerfProc_Process | `
where-object{ $_.Name -ne "_Total" -and $_.Name -ne "Idle"} | `
Sort-Object PercentProcessorTime -Descending | `
select -First 5 | `
Format-Table Name,IDProcess,PercentProcessorTime -AutoSize
ps: Get-Process
ps: ps
grep: Select-String
sort: Sort-Object
cut: Split
Anyone who can't figure out how to teach Linux basics probably should not be teaching CS at a college to begin with.
I used to teach Linux, a few years back, in TAFE (provides further education in Australia, from high school, but not to the level of universities).
I created all the coursework myself. If it helps, below is my lesson outline. I designed it to be generic Linux for the most part, but when I get specific, I concentrated on RedHat. At the time, that was the Linux distribution that most people were aware of. If I was doing it today, I would probably go for Ubuntu.
----------
Week 1
Introduction to Linux
A brief history of Unix
How Unix is organised
Features of Unix/Linux
Week 2
Installation of Linux
Steps to installing Red Hat on your computer
Week 3
The Linux Console
An Introduction to the Shell
Basic Linux commands
Shutting down the system
Week 4
Managing Files
The Linux Directory structure
Week 5
Redirecting I/O
Basic Regular Expressions
Unix Permissions and Attributes
Week 6
Using VI
Linux Kernel Modules
Week 7
Unix Shell Scripts
Scheduling and Cron
Week 8
Adding and Removing Users and Groups
Managing devices and Mounting Filesystems
Week 9
Mid-semester Lab Test
Week 10
Managing Processes
The Unix boot process
Week 11
Setting up a Linux Printer
Using a Linux Printer
Week 12
Linux Networking
Week 13
Unix Network Services
FTP and Telnet
Week 14
Linux Network Filtering
Week 15
RedHat RPM
XWindows
Week 16
Revision
Week 17
Exam
It can pretty much be said that any OS other than Windows, comes with the same standard tools.
Well I think that pretty much sums up where the vast majority of your experience comes from. Let's run down a quick list off the top of my head of OS's and let's see if they support these "standard tools":
Windows: No.
Mac OS: No.
BeOS: No.
VMS: No.
OS/2: No.
Morph: No.
Gem: No.
AmigaOS: No.
CPM: No.
DOS: No.
Cisco's IOS: No.
RealTime OS: No.
By "standard tools" I think you meant linux, and similiarly unix.
Why learn linux? What's the point? Seriously I'm taking a cs lab right now teaching linux and we just went over shell scripting. The biggest question I have is how is this useful to anybody ever? Oh in VI if you press 5dd you can cut 5 lines!!! Except in notepad this is a completely trivial problem. Why use linux when there's already windows?
You wanted inspiration; hopefully this inspires you. I presume these kids know how to program *something*. If not, this is going to be a painful experience anyway.
First of all, the shell (bash, let's say) is an immediate prompt for the bash programming language. If any of them have used Python, they'll know what you're talking about.
It would be nice to have a couple of things set up: Man pages on a website, and some .bashrc macros matching dos, like "dir".
Second, the shell has very easy access to the filesystem, with , >>, and cat. Let's summarize that you can read files with cat (file) or cat >> (file). cat (file) creates what I'll call a "list argument". Note that when "properly" used, "cat" is practically never necessary in bash, but it can make things clearer here.
Third, all commands are functions, but you only get one list argument input and one list argument output per command. And they're backwards from most programming languages. In Python you'd say print(sort(list)) or something, but in bash you say cat list | sort | cat (where the first cat reads the list and the second prints it.
Fourth, grep and cut. Treat any file like a database table. Grep is like the Where clause, and cut is like the Select clause.
Fifth, maybe functional programming for bash. You've already seen filter - it's called grep. Map is called "xargs". Sorry, there is no "reduce" that I know of.
(T>t && O(n)--) == sqrt(666)
A surprising amount of networking utilities are almost the same in *nix and windows, especially things you need for serious troubleshooting.
Apocalypse Cancelled, Sorry, No Ticket Refunds
n/t
Here is what you need:
- Start with some basic commands. You need a cheat sheet with a one line description. man pages are pure garbage as a reference until you are well acquainted with and know the language
- Command line editing and file editing. Cover both vi (or vim) and Emacs
- They do need to understand the command line, pipes and redirection
- Next they need to understand some of the more complex text processing commands
- ...and some comms commands. ping, traceroute, netstat etc.
- Teach them about configuring the system, what the various directories
The course I taught was laid out for me by a Unix professor who knew it inside out. It went on to teach perl, C, shell scripting and it did it by setting small assignments. The technique had it's pros and cons but was definitely more suited to the elective I was teaching than a beginners course. Therefore I'd probably go more along the lines of feaching intros to each, what they're good for, how powerful even short programs can be. Let them know what tools exist (eg. command line debugger). Show them something fast (large file IO if you have fast machines, fast computation etc.). Show them something resource intensive (maybe something that creates a large number of processes in parallel).
A good book or curriculum would help immensely. Linux beginner books vary widely and can get dated quickly, but there are some very good ones.
These posts express my own personal views, not those of my employer
top using WMI:Get-WmiObject Win32_PerfFormattedData_PerfProc_Process | `where-object{ $_.Name -ne "_Total" -and $_.Name -ne "Idle"} | `Sort-Object PercentProcessorTime -Descending | `select -First 5 | `Format-Table Name,IDProcess,PercentProcessorTime -AutoSize
And they say linux is 'hard'...
There's no place like
If you don't like the userland, change it, don't whine about it. Last time I compiled the Linux kernel, it didn't include any command line tools either. I encourage you to download MSYS (super-lightweight Cygwin) from devkitpro, let the self extracting archive do it's thing, then add it's bin folder to your PATH environment variable... There's no easier way to get bash and friends on your Windows.
Well having gone through a few courses that tried to teach me Linux I have a few ideas of what you should not do.
You probably do not want to teach it through assignments that simply require linux for no good reason, like "learn Linux because your assignment answers must be handed in with Linux end of line characters"
Or simply learn Linux because we want you to.
Personally I have not learned anything useful when doing assignments that simply have to learn something for the sake of learning.
I would teach Linux, and all other concepts, (if possibly) through realistic challenges/assignments.
Think of why they should learn Linux (not simply because you think it is better) and why they will need that knowledge, and give them assignments on those problems, forcing them to learn Linux to complete it.
Troll is not a replacement for I disagree.
You should really start with basics and build up gradually. Get them to learn how to open a command line shell, then start typing commands in command lines. A fun place to start is the fortune command, which you could make sure is available by installing the "fortune" package; this prints a random message. Next tell them the basics of command line editing and the "history" command. Then have them use the command line to launch the GUI text editor (gedit) to make them understand that tasks launched at the command line are just as good as things run using icons in the GUI.
IMHO shell scripting is tricky and difficult. It starts easy, but very quickly becomes insane as you try to learn the weird quoting rules. I suggest to show them a very simple shell script basically just running a few commands in a row; for anything more complicated than that go straight to Python.
Definitely teach them about package management. Have them boot an Ubuntu live CD and then have them install the fortune package, run it, remove it again.
I am a huge fan of vi, and have been for decades, so believe me when I tell you to not try to teach vi or emacs. Just have them use GEdit and focus on the tasks at hand.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
That's like, what 6 years old? You could as well teach them PDP and VAX!
Install a fresh distro that matters, like Debian, Fedora or Slackware.
1st lesson: GNU/Linux is a swiftly moving target!
If there was say a well established set of rules that virtually all operating systems followed, wouldn't you think it would be prudent that the ugly kid on the block follow those rules? I've worked on Linux, Solaris (and cousins), BSD (and cousins), OSX, Irix, and Digital Unix. I've also worked on every Windows platform since Windows 3.1, and touched OS/2 and BeOS. Every modern OS (like, you can still find one in production), except for the Windows platform, you can use the same tools on any of them, with rare exceptions. They don't require add-ons for standard tasks. They don't rename standard tasks to obscure names. They "just work"(tm).
Serious? Seriousness is well above my pay grade.
I was going to write something like that as about the only thing I can think of that might impress a windows user - proper access to the processes which are running, real information about what's going on, etc.
Then there's proper file systems that don't constantly tell you files "can't be deleted because...".
No sig today...
Hmmm, let me think on this for a second.
To ping a host until abort:
Everyone else: ping [hostname]
Windows: ping -t [hostname]
(and -t isn't compatible to anything on other platforms)
Everyone else: traceroute
Windows: tracert
(and damned if I haven't typed "traceroute" a million times on various Windows machines)
Everyone else: netstat -a -n | grep LISTEN
Windows: netstat -a -n
Except, there's no obvious way to only show listening ports. And I tried the previously mentioned select-string as a replacement for grep in both cmd and powershell, and that doesn't work either.
So, completely compatible, except they aren't.
Serious? Seriousness is well above my pay grade.
First, ditch 8.04 (Hardy) in favor of 10.04 (Lucid). Hardy ends its LTS phase before the end of the spring semester, but Lucid will be supported until April 2013.
Second, tell the students to bring a CD or thumb drive, and make sure they all end up with Live CDs or bootable thumbdrives in the first week. Then give homework assignments using their own computers booted into Ubuntu.
Third, use VirtualBox to run multiple copies of the OS and show them how to set up VPNs between their virtual machines.
Jaws will hit the floor. Life-long windows users will convert to Linux and worship St. IGNUcious.
Prepare them for the future- teach them how to use Windows.
It will give them job skills that will last a lifetime, instead of delusions that will last until they get discouraged and buy a MacBook (such as my favorite delusion, "This is teh year of Teh Lunix On Teh Desktop"). Plus, it will prevent them from being "that guy" who always says Windows can't do such-and-such, who gets embarassed by some Windows dude telling him Windows has been doing for at least a decade whatever it's claimed to not be able to do.
It can pretty much be said that any OS other than Windows, comes with the same standard tools.
Well I think that pretty much sums up where the vast majority of your experience comes from. Let's run down a quick list off the top of my head of OS's and let's see if they support these "standard tools":
Of all the operating systems you listed, only two are supported today (while the others could be in use by happy geeks, I hardly think they are in any professional use): Windows and Cisco's IOS (I don't know what you mean by "RealTime OS", any RTOS in particular?
Off the top of my head, I can think of Linux, BSD, Mac OS X and Solaris, which (excluding Windows) combined makes up almost the entire market for server operating systems.
The whole point of a text UI is it's expressivity and, once you pass the learning threshold, the speed in which you can do pretty advanced stuff. The Windows hack with camel-case command names, longer than a whole goddam command line on Unix, isn't really impressive at all; it seems totally unusable in practice. Am I supposed to write a whole novel each nice I'd like to rename all files in a directory using a regexp?
Have them do a linuxfromscratch book http://www.linuxfromscratch.org/ keep them off a gui and surf with links or wget. I learnt on a box w/250mags HD space and 64k ram.
Here is your Useless Use of Cat Award ;)
I work in IT and have to manage both Unix and Windows servers and some occasional desktops and I respectfully disagree - PowerShell and WMI are better than unix tools and SSH for managing systems via the commandline once you know them.
With PowerShell Microsoft took a step back and basically said if we designed a whole shell and all of the commands from scratch what can we achieve for modern server command-line management? What they came up with is an object-oriented approach where you do not need to parse text with your pipes but actually send whole objects with all of their properties - and you can still query against those properties even further down the piping chain. Not only that, since they designed all of the commands centrally and at nearly the same time they all pipe perfectly well into each other. It has great support for csvs to quickly pull raw data in and out from Excel where you can do a bit more fine-tuning as well. For their server commands they tend to fit the get- set- mould and they do tab completion of not just the commands but all of the commandline options/flags as well. They have the help command which is the equivilent as man too. The power of this is amazing - particularly in server maagement. Here is a few examples:
Let's say I want to change the mailbox quota for all users in the Boston office on Exchange - I can do this:
get-mailbox -filter {office -eq "Boston" } | set-Mailbox -UseDatabaseQuotaDefaults:$false -IssueWarningQuota 800MB -ProhibitSendQuota 900MB -ProhibitSendReceiveQuota 1GB
Let's do some bulk account creation from a CSV:
The following one-liner creates mailboxes for all team members listed in an Avalanche.csv file, which contains NHL Avalanche team roster information with the following column format:
Pos,No,Player,Age,Ht,Wt,Born,Exp,Birth City
$password = Read-Host "Enter password" -AsSecureString
import-csv Avalanche.csv | foreach {new-mailbox -alias "avalanche$($_.No)" -Name $_.Player -password $password -database "Mailbox Database" -org Users -UserPrincipalName "avalanche$($_.No)@example.com"}
These are the sorts of tasks that were really hard to do on Unix where you had to use sed and awk to massage text outputs of commands as you piped them around etc. When you go OO and design all of the commands around it you get an amazing experience. And using WMI you can run these commands not just on the local system but on any system where you have appropriate permission and have not firewalled it off on the local network.
And we are not going to get into the great Group Policy changes with recent versions of Windows - I can set any registry key or file permission or run any script (powershell or vb or even batch) on a system/user matching a wide variety of detailed criteria (OU, Site, Security Group, etc). And that is even before the enterprise management tools like SCCM or Altiris are figured in. I have had to manage a bunch of Macs before and I'd take a bunch of Windows 7 PCs and even Server 2008 R2 Boxes over them any day now that I know how to do it properly...
If you teach the browser first and the shell last then students will be much more interested. If you understand about HTML, CSS, JavaScript, the DOM, HTTP, httpd, FTP, and TCP/IP then you have the context to learn bash.
You're trying to teach auto mechanics to students who likely can't drive because they've been using DOS and their brains are like putty. Get them driving a Unix first through showing them the Web they already know is actually a Unix app (well, technically a NeXT app, but close enough) and then drill down through the layers.
In other words, start from close to the user, not close to the kernel.
Teach them on Ubuntu first, then move them to Slackware which tells them what is REALLY happening. It also shows pretty well that all that GUI-fication going on, even in Windows, can be merely a wrapper around a file format. Heck, Word is merely that for 90% of uses.
It helps too to show the GUI output and how you get that down as a text file and slack is better at that than Ubuntu.
Also knowing the differences may help when going to the real world, where they may use Red Hat, Solaris or something else. When you know several options, you learn where the commonality is and work from there.
"This is man. This is apropos. Start typing."
Nice straw man. Here's a news flash for you. In your OP, you didn't say a damn thing about reading or writing. You also didn't say a damn thing about teaching methods. Both of those are completely separate conversations, some of which I might actually agree with you on.
No, you specifically referred to "looking at Linux" as the measurement of whether or not a person deserves a chance to learn more about computer science, which is, as I said, an arrogant and asinine point of view. By the way, if you think that one's proficiency with Linux directly corresponds with their ability as a computer scientist, you're sadly mistaken. I know several brilliant people who have had little or no exposure to Unix-based operating systems. Obviously, I encourage anyone who wants to go into the field to learn about Linux, but I sure as hell wouldn't classify knowing how to use vi and/or ssh as a prerequisite.
I'm at a loss - this is a second-year college student that is trying to shape the course taught by a professor to first-year college students? How much are the students paying for this class?
The lab should compliment the lectures, not the other way around. It sounds like this second-year student wants to make converts out of windows users, I don't think that's why they are taking the class.
It is your job to help the students work with the tools provided to complete the projects for the course your lab period supports, try to evangelize Linux and you'll lose students attention, period. If students want to know more than the basics, they can come to you OR research it on their own...
To be honest, the poster sounds like too many Linux 'enthusiasts' - they want you to embrace Linux as deeply & completely as they themselves do, and won't take no for an answer.
If you can't put together a decent "how to work with the Linux-based CS lab for class CS101" pamphlet, consider using selected portions of existing works, like Kier Thomas' Linux Pocket Guide:
http://www.ubuntupocketguide.com/index_main.html
It was written for Ubuntu 8.04, but could easily serve as the basis for a how to get started guide (and the students will appreciate not having to buy another textbook)...
Ken
I say just teach them enough to pass the class. If they want to learn more feel free to show them more. But don't stress out over trying to Evangelicalize them to the Linux way, really it isn't worth it. Some of them will stick to Microsoft and make their living doing MS Coding, others will learn Linux and be interested enough to be comfortable with it, and others will really love it and ditch all things Microsoft.
Focus on teaching them enough to pass the class is the only way to go.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
When the only tool you have is a hammer, everything looks like a nail. The way then is to explain to students that by maintaining tunnel vision, they will not be as skilled as the competition, and on graduation, will find it harder to get a good job. In the class, you will have some GURUS, and try to get them to motivate their peers. See what you can do to make the use of Linux a positive experience. Good luck
Leslie Satenstein Montreal Quebec Canada
You are doing things in a different way. This is a mind stretch moment.
When I went form DOS to Mac, one of the concepts that took me a bit to realize is that the syntax is inverted:
In a gui world, much of the itme, syntax is Object -> Verb. Select what you want, then what you do to it.
In a cli world, the verb comes first.
In vi it varies. 6} the 6 is an adverb, modifying how many paragraphs to go. But in :s/foo/bar/g the adverb (g) comes at the end.
***
One of the ways that will help you teach is to present the same task in both a gui and cli way to do it.
So as an example use an event log, and go through it looking for certain types of events. Then show them grep and sort
When I learned to use a NeXT one of the joys of it was that for most things there was a GUI way (good for doing it the first or occasional times) and a CLI way (good for frequent, automated use.)
SMIT, the AIX admin interface, was way cool in that as you used the GUI interface there was a window that constructed the cli command that was going to actually do the work.
Another cool thing to show them is how easy it is to monitor a bunch of computers/processes with a combination of x11 and xterm. When I was sysadmin I frequently had 30-40 xterms spread over 8 virtual workspaces.
Third Career: Tree Farmer Second Career: Computer Geek First Career: Teacher, Outdoor Instructor, Photographer.
please disregard
I want my Cowboyneal
I agree. Please tell the *nix community to adopt the standards set by the OS's that currently have 95% marketshare and we can all be happy.
Still in production:
VMS
OpenVMS
Windows Vista
Windows 7
Windows CE
Windows Phone 7
Android
iOS
XBox 360
PS3
Cisco IOS
Linksys Embedded OS
RealTime OS
None of these can you drop to a command line and "just use" *nix commands. Stream piping and forking isn't "modern" it's archaic. It's been around for nearly 30 years.
OpenVMS latest release was just 6 months ago. I'd say that's still fully supported.
Yes, all OS's derived from *nix typically have the same basic set of commands. Those OS's that don't derive from *nix typically do not have the same set of commands.
Off the top of my head, Windows 95, XP, ME, 2000, Vista, 7, etc. combined makes up almost the entire PC market (including server) operating systems and out number those based on linux nearly 20:1. All of these support DOS commands (derived from CP/M), and most either come with or can support PowerShell.
The whole point of a PowerShell is it's simplicity and uniformity of how things work from one command to the next, which has a smaller learning curve than *nix. Commands ALWAYS follow verb-noun format, and the commands are case insensitive, so calling them a hack with camel-case is about as appropriate as calling them a hack with ElItE-SpEaKnEsS-CaSe. In practice, most commands additionally have aliases, and you can make your own aliases as well.
Of course commands that have a built in command in *nix will be longer when they don't have an exact equivalent in PowerShell, that's to be expected. But there are a ton of things that would be extremely long, impossible, or prohibitively complex for *nix (without 3rd party/non standard tools) to do that PowerShell does with ease. For example what's the standard way of processing through an XML fragment, iterating through subnodes and executing a program passing the subnode values as parameters using no 3rd party tools in *nix? PowerShell it's trivial. How about about what Physical disk in a remote machine on the network is getting used the most? Again, trivial. What's the screen resolution of a remote machine? What format is the primary partition? What what the longest running SQL query on your database server? What is the average response time of your primary drive? What is the average response time? Anything and everything that is available from the registry, the performance counters, or WMI is accessible easily.
There are three key points here:
1) You need to be clear why the students are being offered this course. What are they expected to gain from it? (I hope you know this already, but you haven't told us.)
2) You need your professor to be very clear to you about what work is good enough to pass the course. Good students (which I assume you are) often have great difficulty in accepting work which is below the standard they set themselves, but clearly there must be a big gap between what you are used to doing which receives high marks and what just scrapes through.
3) Go through the basics very slowly. Part of the point of the course must be to encourage the students to go on and work to really master the subject. You need to give the impression they can get on top of it. Hurrying them through half-understood material will not give them the confidence to go further. Always have some extension exercises for students who do zip through your material. You can give them little challenges to work on while you assist the bulk of the students towards getting a good grasp.
[4) if there are a lot of absolute beginners in your class, request a second person to be your helper. Having two people makes a huge difference.]
give them a shell account and have them learn man and other cmd line tools, no gui.
Thank you. Even though my inability to stop and think to realize that our intstitution's arrangements for classes isn't the same as everywhere, much of the advice is still sound, and I'm reading through the vast majority of the comments. For those who asked for clarification time and time again, the following snippets of information seem to be the ones most needed: The course actually has a split purpose that goes three ways - teaching Linux, teaching a lot of fundamental theory in programming (loops, data structures, etc), and teaching C++ to the students. It is taught in two halves (each being a semester long course), and I'm helping teach the first half. As to the teaching itself, in the labs, they learn the practical part - where they actually use the machinery and things they're lectured on. In lectures, they learn history (in Computing), theory, and the concepts behind a lot of what I will most likely be responsible for. My professor is teaching the largest chunk of everything, but our planned focus is for him to teach lectures and for me to teach labs. The college is liberal arts, 4 years for most programs of study. My personal experience... Well, let's say I get most modern versions of Windows for free through MSDNAA and still get frustrated if I even have to spend the school's bandwidth to download a copy. I love Linux! And indeed, that is part of why I was selected for a potential candidate for helping teach this course - my love of FOSS, my ability to use everything needed in the class, and my seemingly endless patience and reason with people. Beyond that, I'm going to be going through these over the next week or so and reading them. Everyone's input is appreciated, and I would like to thank everyone.
oo is great for encapsulation and inheritance and you can have it under unix with dozens scripting languages, but it`s a complement or glue to those tools you call archaic, in fact most people familiar with both would do a `top` replacement by filtering ps in one third of the lines you used if they want readability, or in a perl one-liner if they are showoffs.
tomhudson, What have you ever done with any of the OS' mentioned that was any good as rated by others in the sciences of computing? Nothing I can find attached to the name tomhudson. tomhudson, You're just another dime a dozen wannabe tech wasting his days on slashdot because he's not good enough to have an actual job in the arena of computing.
Answer the question in my subject line above, tomhudson. Or, are you just "talking out your ass" again, as you usually do? We already know you don't know shit about this curriculum and that you do not have a computer science or computer information systems degree, so why on earth are you trying to play "expert" on something you have NO clue/idea/experience in yourself?? We already know the answer: tomhudson the wannabe is trying to play "expert" again as per his usual, in areas he has NO CLUE, or actual experience, in.
http://slashdot.org/comments.pl?sid=1952834&cid=34915292
http://slashdot.org/comments.pl?sid=1952834&cid=34915292 answer the question there at the url where it was asked of you. Why do I get the feeling that tomhudson is talking out of his ass again as is his usual, on things he has no experience or clue in (such as actually having a CSC degree to his name)? If anyone is the "straw man" here, it's tomhudson the bullshit artist.
http://slashdot.org/comments.pl?sid=1952834&cid=34915292 answer the question there at the url where it was asked of you tomhudson. I get the feeling that tomhudson is talking out of his ass again as is his usual, on things he has no experience or clue in (such as actually having a CSC degree to his name).
http://slashdot.org/comments.pl?sid=1952834&cid=34915292 , and answer the question there at the url where it was asked of you, tomhudson. Personally, I get the feeling that tomhudson is talking out of his ass again, as is his usual, on things he has no experience or clue in (such as actually having a CSC or CIS degree to his name), and yet he's talking as if he actually has taken and passed the entire gamut of coursework for a degree in the computer sciences? Let's see if he actually has said degree(s) and let him answer the question that was asked of him in the url above. He'll run away from it, as is his usual.
http://slashdot.org/comments.pl?sid=1952834&cid=34915292 , and answer the question there at the url where it was asked of you, tomhudson. Personally, I get the feeling that tomhudson is talking out of his ass again, as is his usual, on things he has no experience or clue in (such as actually having a CSC or CIS degree to his name), and yet he's talking as if he actually has taken and passed the entire gamut of coursework for a degree in the computer sciences? Let's see if he actually has said degree(s) and let him answer the question that was asked of him in the url above then.
http://slashdot.org/comments.pl?sid=1952834&cid=34901396 answer the question there tomhudson. Make us laugh at you acting like you actually have a computer science degree to your name you actually earned (and we know you do not have that, and yet, you talk as if you do. You're always acting the "expert" tomhudson, so let's see how much of an expert you are and produce proof of your expertise in a degree in the computer sciences to your name, you wannabe).
Teach them Windows instead. I've got to compete with these young whippersnappers, and I'd prefer they be hobbled as much as possible.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Nobody gives a crap about how to navigate the terminal or GUI. These concepts are too abstract to be useful, and too boring to care. People learn by making connections to things that are important to them. You're talking about a group of CS students, so what will a CS student most likely want to do? Off the top of my head: online research and collaboration, writing technical papers, authoring and compiling code... What do these tasks involve? You're the teacher. :)
An object wrapping utility (call it obj) that takes the relevant command as an argument, checks options, and parses the output as a standard YAML encoded document would achieve that. So, when you want to create an object from the output of a command (assuming obj has appropriate descriptors), you just
$my_object = obj command -a -b -c -d=5 --foo=enable.
Want to get a member - enter the get utility
get $my_object member_val.
Sound reasonable?
I know tobacco is bad for you, so I smoke weed with crack.
I was a freshman in CS and had a course in Linux. I absolutely hated it. There is enough to learn about the basics of computer operation that you don't need to muddle their minds with legal bullshit, legacy crap, and "desktop customization". Just stick to windows. They weren't made for the lowest common denominator for no reason.
Install a bare minimum shell environment and have the students learn why Linux has the industry's best IPC mechanisms and why Linux has the best bar none performance. Instead of trying to each them Linux step by step have them see why it's a much more powerful environment then Windows. In truth most Linux classes are taught horribly and actually leave the students asking more questions and leave hating the system.
If I were teaching it I would let the students explore and give them only one big project which needs to reply on all the different aspects of the Linux environment which make it special. If they are able to finish it then they can draw there own conclusions about what they think. If not then well then deal with that when it comes. I think for the first time I've ever seen, Linux should be taught with a simple, do it yourself and figure it out method, instead of the here's the shell, here's the message Q approach.
After all aren't don't most Linux users have to figure this stuff out for there self when they start.