Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Unix Operating Systems Software

Learning Unix Concepts Through Fiction? 17

AntiPasto asks: "Technical reading is often difficult to digest. With a new project called HotelNix I hope to create a database of stories that teach concepts one would normally read in man pages. We all know that these tasty tidbits can be at the very least archaic, so could the Unix world benefit from a public-domain, user-contributed technical story archive? What kinds of writing would be beneficial to readers on many levels, and in what ways could we index it?" Interesting project. I think this might help Unix newbies more than seasoned admins in learning concepts, but that in and of itself would be worthwhile.
This discussion has been archived. No new comments can be posted.

Learning Unix Concepts Thru Fiction?

Comments Filter:
  • The idea is good and has merits. However people tend to remember rymes easily -- like

    righty tighty lefty loosy

    You might try this aproach. However, im not jsut saying come up with a bunch of stupid rymes-- rather take the fiction aproach but maybe give it a poetic spin (think homer's Iliad but in a modern setting). It sounds off beat, but those are often times the ideas that work best. After all who would have ever that that open source software would have worked as well as it has.
  • Having just been de-virginixed over this last weekend, I have found that there is so much I'd like to know about UNIX and the many incarnations. I'm afraid that not having used the OS,that I don't know how to run it like it was designed to run. I know it's really based around giving the developing mind the tools for creating, but if your like me and have never seen the likes of a single line of UNIX code(my terms give that away), then this is where the issue is for me, and maybe for others who would like to know more. Most would say go back to school. I agree, I should. I'd devote a mass chunk of time to learning what I should have learned back when my friend and I had a Commodore 64 that we messed around with.

    The man docs are suited for those who have taken the painstaking time to learn everything about how to program. I, unfortunately, have not. I'm doing well if I code a whole page in HTML and don't blow it out on the first upload. So you can see where I'm at.

    I've been in the computer environment for about the last 10-15 years or so. I forget what year it was when we got terminals in grade school. '84? '85?, but most of my interaction has all been in the graphic type environment. From what I understand, the GUI is not every ones favorite place to be when working on a system. I like my terminal access in Linux. It let's me know that I have the power to manipulate the system at it's core. But what the heck am I going to do when i get there?

    I've been a Windows user since 3.1 and I know little dos. I have gotten so used to running installations in Windows, that when it comes to running tar or rpm file, I don't know what to do. I'm sure that the hardcores are sitting there chuckling to themselves right now chanting "newbie, newbie", but when I say this it's most like ly to get a laugh from any veteran Unix user. Is it possible to pre program installs in to the rpms and zips? to autorun upon completetion? So many files with so many different variables make it more frustrating than difficult. For a person with knowledge of enough commands to possibly "break" some thing in the process, it gets a little scary in that neck of the Woods. Or, in the cases so far, not even get them to unzip. For instance, I need to rebuild my GIMP library that I had running in windows, but I can't get the unnzip right? I've read howtos (maybe not enough) but no go. Once I get the install thing down, unzipping is mastered, and how to deal with things at /root, then I'll be ready to devote all of my time on a system to Linux. Rignt now I keep that C: drive handy just in case. But I haven't been back for four days. :-)

    The UNIX concept is what originally attracted me to running it in some form eventually. Now I do. The thought of being able to customize a computer system to be able to be so personalized just blew me away. Sure you can run all the programs you want in any other OS, but it doesn't run like it does in Linux. Not to mention the whole concept behind the entire OpenSource Development. That alone is the single most reason that any one should be interested. It's a community, not a competition. The appeal of the mass spread of knowledge resources is the ultimate way to get people on the same level. If it means doing this by documenting usage in a pooled information format that a newbile like myself can grasp, then it gets my vote. Heck I'd even like to contribute to it's success by doing idiot checks.:-)

    Thanks for taking the time to read this.

    Converted.

  • i know what you mean, and i wish this story were on the front page (be easier to get more comments, and therefore more information).

    i remember my troubles, when the various docs had different things to say about tar. some systems it was one way, some another. some said to 'gunzip |tar xvf -' others said to 'tar -zxvf' and still others said to 'gzip -dc |tar -xvf -', and they were all accurate ... depending on style, and if you were using a bsd or vms based system. it was impossible to remember what to use, though. and at the time, rpm was hard to find.

    this idea of a modernized homer's illiad thing for unix sounds cool. i hope something comes out for it.

    but as a farewell, the one thing that best saved me was this: 'makewhatis' and 'apropos'

    good luck, and i hope you find the help you want/need

  • Human beings love stories/parables/poems of all kinds - witness the Bible/Zen tales/Pachatantra. I think it will be a great idea. In fact stories are the kind of thing that outsiders could comprehend. You know the Windoze(I'm one) people for whom Unix/Linux is incomprehensible.

    There could be two or may be more than 2 types of stories. General concept understanding stories/parables and even command based stories (Like how you learned a command and its arguments).

    Another interesting point is that stories are passed on. Especially good ones. Remember Asimov about how the Galactic empire collapsed when people destroyed all the robots/manuals and could'nt repair the tech. stuff. Maybe if they had good stories about the tech. stuff they would have never lost the knowledge. ;-)

    Regarding indexing of stories - Concept stories would be slightly difficult but the command line stories would be easy.

  • Does anyone remember the 'Thing King' [ucalgary.ca]?

    It's a way of describing virtual memory...
  • by po_boy ( 69692 ) on Friday December 15, 2000 @08:24AM (#557433)
    Sounds a bit like routergod [routergod.com] which includes such articles as Alicia Silverstone on ISDN and Charles Manson On Static Routes. Always have a good reference handy!
  • by CrayDrygu ( 56003 ) on Friday December 15, 2000 @08:33AM (#557434)
    I have gotten so used to running installations in Windows, that when it comes to running tar or rpm file, I don't know what to do. I'm sure that the hardcores are sitting there chuckling to themselves right now chanting "newbie, newbie",

    Yep! But hey, I was in your position not too long ago (maybe a year to 1.5 years), and I know what it's like. How to deal with tar and RPM files took me forever to memorize, but I eventually got it. Here's a brief overview that'll work for about 99% of them:

    tgz/tar.gz:
    tar zxf file.tgz
    cd file
    ./configure
    make
    su -
    make install

    The z tells it to uncompress the file, since it's been compressed with gzip (if you have just a .tar, you can leave that out). x means extract. f means use the file specified (as opposed to a device like a tape drive or floppy).

    Everything after the tar command is for compiling programs -- if your tarball isn't source code, you can skip those.

    Oh, and no, there's no "-" in front of the "zxf". tar is weird like that (though I think it'll work with the - too).

    rpm:
    rpm -Uvh file.rpm

    U means Upgrade, but it works for installs too. v is for Verbose, gives a litte more info on what it's doing. And the h tells it to display hash marks (#) as a sort of progress bar.

    Uninstalling RPM files is a little different, as you need to specify the package name instead of the file name. The command is "rpm -e package". To find a package name, it's helpful to make a list of all the packages installed on your system:

    rpm -qa |sort > rpmlist.txt

    Then just open that file in your favorite text editor and find the package you want. Or do it from the command line with grep:

    rpm -qa |grep "package"

    Now print this out on an index card and keep it near your linux systems. =)

    --

  • `I know this -- this is a UNIX system'
  • Stories do a great job of introducing/teaching new ideas. But real learning comes from doing.

    No matter how many times I watch McGyver or the A-team, I still can't build defensive weapons from stuff in my garage.

    And, no matter how much porn I see, I still can't seem to do the Venus Butterfly with a starlett. ;->

  • Thank you. Consider me spending this weekend getting this dialed in. I presume in six months to year, I'll look back it myself and laugh very hard.

    Thanks Agian!
  • Something else with tar that I do.

    If you want to be able to see everything that got unpacked, add the `v' option. It's for verbose output, and it shows filenames and path.

    This can backfire for larger tarballs with lots of files. You'll have $BIGNUM lines of filenames fly past your screen at astonishing speed.

    I like to do this:

    tar xvfz file.tar.gz >> /home/zkenyon/file_files

    It gives me a nice list of what I just unpacked, which can be helpful if there are problems later.

  • A database of stories would be great for those of us who work by ourselves out of choice or necessity (I live in a remote Asian dictatorship where the internet is illegal) Unwritten lore, knowledge that's not in books is hard to get when you're not part of a group of people who help each other out. Stories are easier to read, understand, and remember than the MANual. Actually... Real Men probably become Men through all the virile manly effort required to interpret and use MAN pages, to go beyond them. No doubt any programmer or system administrator comes of age by trouble shooting nasty problems with the sparse info given by a MAN page, but *how he actually goes about this troubleshooting* that's *a good story*. You don't have to call it a story, call it a "case study" if you want, but I'd prefer mine salted with a little science fiction or adventure. A great book I'm reading now makes good use of case studies: Java Design Patterns: A Tutorial by James W. Cooper.
  • Fiction is a good way to get interested in science, but it doesn't always work well as a practical teaching method. What science there was in Jurassic Park was mostly contained in the introduction, and even then, it didn't teach us how to care for an embryo, run a PCR machine, or even use a pipetman. You couldn't clone E. coli with the information in that book.

    Science fiction works better - I've picked up quite a bit of physics from Niven's stuff. However, I don't know how you'd incorporate an OS into science fiction and make it interesting. Maybe I just haven't thought it through well enough.

    I've searched high and low for good computer books aimed at the newbie, and mostly I've been very disappointed. In order to use most O'Reilly books, you have to have some background in programming, or you have to have had your hands deep into the OS you're working with. The "For Dummies" series, on the other hand, is poorly organized IMHO. Most newbies aren't looking for instruction in how to administer a network or run a server. Most of us just want to be able to run the OS or program on our desktops at home. You could divide topics up into Things That Readers Want to Do and Suggestions for Readers Who Don't Know Where to Start. "Installing Unix", "Basic Commands", and "Common Setbacks" would be a good place to start.

    If you really want to use a fictional format, I guess you could start out with Sally, who has little computer experience, works as a secretary, and wants to get a good job so she can leave her no-good two-timin' wife-beatin' husband. So she decides to learn how to use Unix on her Pentium II at home. Readers could go through the basic introduction with her, encounter problems with her, and share in her discoveries. Hell, you can even address security issues when she wants to make sure her husband can't hack into her box. At least it would be more interesting to newbies than most man pages, and they wouldn't feel stupid.
  • Don't forget the 't' (test) option - use in place of 'x' to make tar perform a test unpack - it shows you what will happen when you use x, without actually writing any files. I always do this before unpacking an archive, to see whether it's going to make a folder for the unpaced files or make a mess of the current directory. Oh, and pipe 'less' or 'more' to keep everything from flying by before you can read it.
  • Or Wanye's World II:

    Garth:"Hey. That's a Unix book." (pointing at Garthette's copy of Steven's Unix Network Programming.

    Garthette: Yeah.

    Garth: Cooool.

    Tom Swiss | the infamous tms | http://www.infamous.net/

  • This wouldn't have anything to do with Britney Spears' Guide to Semiconductor Physics [britneyspears.ac], now, would it?


    --
  • I thought that Cryptonomicon and Snow Crash were great at teaching concepts like crypto and how the Internet works. My (mostly) non-technical wife read it and understood much of what Stephenson was saying.

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...