Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Education Linux

Advice On Teaching Linux To CS Freshmen? 467

Posted by timothy
from the treat-them-like-your-future-boss dept.
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.)"
This discussion has been archived. No new comments can be posted.

Advice On Teaching Linux To CS Freshmen?

Comments Filter:
  • by fineghal (989689) on Sunday January 16, 2011 @01:58PM (#34898320)
    You've given us rather little in regards to guidance. Is this class part of a larger arc focusing on security? Programming?
    • Re: (Score:3, Funny)

      by Anonymous Coward

      Start with vi and go from there.

    • by perpenso (1613749) on Sunday January 16, 2011 @03:13PM (#34898826)
      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.

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

      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.
  • LAMP (Score:4, Interesting)

    by neochubbz (937091) on Sunday January 16, 2011 @01:59PM (#34898328) Homepage
    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.
    • by allometry (840925)

      I picked up Linux when I was 16, working for a local ISP. It was the first time I ever worked with a RADIUS server to auth our dial-up clients.

      I was encouraged by the sysadmin to try out Debian and just go nuts with it. I remember doing a complete install, getting X to work and then proceeding to fuck everything up. By the time I was 18, I was proficient enough at setting up a LAMP stack from scratch on Gentoo and eventually getting a Tomcat and Apache to work together with mod_jk.

      What sold me on learning L

      • by neochubbz (937091)
        Yeah, I picked up Linux when I was about 13 or 14. I was trying to set up a web server for a forum my friends and I ran. While my server never really got off the ground, I used what I learned to set up web servers and websites for business and student organizations at school.
    • While you're at it, teach them how to use vim. Knowing how to use the editor well will make all those little administrative tasks so much easier.

      • Don't forget to teach them punchcards, too!

        Seriously, vi(m) is an editor. Some like it, some do not, but it is not anything but an editor. Editors are dime a dozen, and most of them can do as much as vi can.

        • by Americano (920576)

          Given that most command shells have a Vi and an Emacs command-line editing mode, I'd say that a day or two spent reviewing some of the easy ways of getting things done in vi/vim or emacs would be time well spent.

          Yes, they *can* learn it on their own. Just like you can toss somebody into the deep end of the pool and say "Thrash around for a bit while I go have a sandwich, when I get back, we'll see if you've learned to swim!"

      • I wouldn't start on vi. I'd start with nano because it follows the same logic as programs the students would likely be familiar with. On most distros nowadays even when you run visudo you get nano.

        The key here is to make the learning curve not resemble the White Cliffs of Dover.

        • by AlXtreme (223728)

          +1 nano. Around 10 years ago during my CS undergraduate classes everyone could just pick what they were used to, but students that were still getting used to this here shell thingy were nudged to use nano first during the unix introduction class. Easy to pick up and get stuff done and graduating to emacs (or vi if you like colons) is relatively easy.

          And to the sibling post about nano not conforming to any standard: you're right. But when you've barely touched the surface of programming it's a relief to have

    • Here here. Good idea.

      Other possibilities:
      a firewall
      a proxy server
      a group source code repository

    • by perlith (1133671)
      How did this get modded up?

      This is a FRESHMEN course. It is VERY LIKELY the concepts of "Linux" / OS, "Apache" / Web Server, "MySQL" / Database, "Perl/PHP/Python/whatever" / Scripting are all completely new to them. You want to throw all four concepts at a group of 18-year olds who may have never seen them. Fine, maybe as an optional reading for those interested, but not as a requirement.

      Look up North Carolina State University's E115 course. It is a required one-hour course all College of Engineerin
    • 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 [slashdot.org].

  • by digitalsushi (137809) <slashdot@digitalsushi.com> on Sunday January 16, 2011 @02:02PM (#34898338) Journal

    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.

    • by tomhudson (43916)

      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.

      Porn, booze and drugs.

      That's been available freely on any campus LONG before open source was a buzz-word.

  • by Sivar (316343) <charlesnburns[@]gmail...com> on Sunday January 16, 2011 @02:02PM (#34898340)

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

    • by tunapez (1161697)

      I learned my meager CLI skills by installing Dapper server, then xubuntu gui and then proceeding to dissect the link commands, investigating switches/man pages and Goog'ing for fixes because many things didn't work right. Linux not quite working as well as Windows was a bonus for me(in hindsight, not at the time), and I'm better off because of it. Believe it or not, for that reason I am also thankful to Microsoft for Vista. If Vista wasn't a steaming pile I would have continued to put off delving into the L

  • by GPSguy (62002) on Sunday January 16, 2011 @02:03PM (#34898350) Homepage

    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.

    • by jedidiah (1196)

      Simply make them use it for their assignments.

      It could be Linux or it could be any other Unix. It could even be MacOS System 6.

      This isn't exactly a new problem.

    • by AchilleTalon (540925) on Sunday January 16, 2011 @02:45PM (#34898656) Homepage
      Command line usage and basic shell scripting is a must. Emphasize on pipe usage, quick and dirty scripting right on the spot.

      Another thing that should be teach to them is the disk space organization. This is quite different from Windows and newbies tend to put everything in a single huge filesystem. They should know some basic principles about LVM and all the kind of filesystems available with differences between them. Not an indept review, but a basic review of what is available and what they can do with this stuff.

  • by excelsior_gr (969383) on Sunday January 16, 2011 @02:16PM (#34898430)

    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.

  • by TheRaven64 (641858) on Sunday January 16, 2011 @02:19PM (#34898454) Journal
    Teach one half of the class vi, and the other half emacs. Then join the class back together for a discussion seminar.
  • 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 inste

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

    • by gomiam (587421)

      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.

      I'm sorry you have such a fragile skin ;) Joking aside, "the developing sector" includes, usually, things like "getting it to run" (installation and maintenance). You don't program in a vacuum, and if you develop enterprise software you will have to worry about little things like that.

    • by Haedrian (1676506)

      (Added):

      Just to give an idea of the things we did, the assignments were

      1. Multi-player (different user) version of snake on the same machine. Needed to use shared memory to pass information - no pipes.

      2. A system whereby a function is executed remotely over an internet connection and returns an input. Think "Web services" written in C.

  • by perry64 (1324755) on Sunday January 16, 2011 @02:25PM (#34898510)
    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!!!
    • by Have Brain Will Rent (1031664) on Sunday January 16, 2011 @03:35PM (#34899002)

      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.

      As someone with long time teaching experience let me give my own version of #1 above:

      1) Find out what they know. Survey the class to see what computers, systems, computer-like devices etc. they have had experience with and then you can perhaps take a lesson or two to try and get everyone up to about the same general level of understanding as their fellow classmates (as it pertains to the course of course). After your first feedback do a bit of research and try to find them some extra material for the ones who will need to do the most catching up, for them to read/examine on their own time.

      Otherwise you will be spending the entire semester with a set of students who will be having fundamentally different problems learning the same material.

  • by tempest69 (572798) on Sunday January 16, 2011 @02:28PM (#34898530) Journal
    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.
  • 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.

    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 compu

    • by rjstanford (69735)

      Good points here. Additionally, learning the command line is like learning the wrench. It takes a few minutes to get the basics down, the rest is all in how you use it in different ways to solve different problems.

      Besides, after the first week, what you should be teaching is scripting, the concept of gluing together prebuilt tools to work on a given data stream to do wonderful things.

      The Power Tools book could be a good asset to you, here. Tons of great, short, impressive examples of things that are rela

  • Doesn't compute (Score:5, Insightful)

    by ThePhilips (752041) on Sunday January 16, 2011 @02:39PM (#34898614) Homepage Journal

    [...] Teaching Linux [...]

    Best thing is to not "teach Linux," but to "teach on Linux."

    • Best thing is to not "teach Linux," but to "teach on Linux."

      Yes, I'd agree with this. Nobody reads man pages for fun, but will happily read them to figure out why things aren't working when they have a goal in mind. Give them a basic (interesting!) project to do (parse some data to do something neat or somesuch?), tell them about man pages and other internet resources and let them have at it. Be around to help if things don't work though: don't forget how incredibly frustrating getting stuck during debugging in an unfamiliar system can be.

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

  • The computer is a general purpose tool which is specialized through the software. Teach the kids the basics. Have them practice the basics in class, then as quickly as possible design and implement products. The biggest mistake that I have seen is teaching the tools outside of context.

    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

  • 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

  • but chris taylors' thesis [http] 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 the

  • by internet-redstar (552612) on Sunday January 16, 2011 @02:51PM (#34898698) Homepage
    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:

    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!' ;-D

    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.

  • Don't (Score:2, Flamebait)

    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.

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

    • configure, make, make install
    • dev packages versus runtime packages
    • Setting up autoconf
    • Directory hierarchy
    • Intro to major CLI based text editors: vim, emacs, nano, etc.
    • Intro to CLI based source control: git, hg, svn, bzr, etc.
    • Building packages
    • Basic CLI commands: ls, cd, man, pwd, grep, sed, awk, pipes, etc.
    • Use of tools like gcc, gdb, ldd, strace, etc.
    • Overview of graphical toolkits and how to link software with them: Qt, Gtk, etc.

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

  • 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"
  • by cskrat (921721) on Sunday January 16, 2011 @03:57PM (#34899136)
    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.

    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 /home/cs101/assignments/ . Replace {username} with you username on this machine. (introduce `tar czf`, introduce cp)
    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)
  • Linux from scratch (Score:4, Interesting)

    by sprior (249994) on Sunday January 16, 2011 @04:10PM (#34899210) Homepage

    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.

  • by adamofgreyskull (640712) on Sunday January 16, 2011 @05:08PM (#34899584)
    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".
  • by deek (22697) on Sunday January 16, 2011 @09:58PM (#34901432) Homepage Journal

    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

Power corrupts. And atomic power corrupts atomically.

Working...