Linux-Noob Forums

Quote:That's cool, I work at amsterdam hospital; amsterdam university is part of it. part of is where I work and the other part is in central Amsterdam(that's probably where your good friend works

He works at the science labs, UVA.nl - you know that?

 

Quote:Good idea about keeping a personal log. thanks for the tip.

I have a series of files in a directory (actually /export/install/linux/docs) - simple plain-text files - but with names like "mysql.txt", "raid.txt", "migration-plan.txt" which I drop notes in.

 

I know my memory is quite poor, so I make an effort to capture information in note format and can refer to them later. I started doing it with some programming templates (loop construct, conditions, function declaration, array handling) for different languages I use (perl/php/java/javascript/etc) so that I have something to refer back to.

 

Plus, doing them in plain-text means "grep" can locate a file quite easily for me!

 

To me, there's nothing more frustrating than scratching your head with "now.. how did I do that again?" thoughts, knowing full well that at the time I should have recorded what I did. Just taking snippets of notes haven't half helped my sanity at times!

I'm not real familiar with al the divisions of the uva, but I think where he works is in central Amsterdam part of the uva, I work in Eastern Amsterdam where the hospital is and most of the medical/information courses.

 

 

I good point about making them in plain text files. Started making it in open office. Although I don't know any programming language. If I have ever time in the future I want to learn either Perl or python cuz I've heard is quite useful as Linux admin. But first things first. Going to try to setup virtualmin package this evening and to try to setup a mail server with zafara or squirrel mail.

An update on my studies since I started this topic a while ago. I was following CBT Nuggets debian but I I caught myself watching too much rather than doing. So I started this preperation LPI-1 exam book and will be working through that. I agree with you that playing around and trying things out works best as learning new things. But Linux is so big, I find it hard to keep focuses on what all is important to learn. So using a book or other study material kind of gives me a structured guideline to work by and when I want to try something different or want something more detailed I search the internet or forums. Does that make sense? To me it does at least :)

Most books tend to follow a similar path: grouping a number of topics together, and then focus upon the HOW - eg: how to manage users.. how to manage hardware... how to manage software... etc.

 

In courses I teach, I try to get across the WHY, WHO, WHEN (and the "what if not") - what are the benefits of doing such an action, who should be expected to do it, how often (could it be automated), what would happen if it was not done (firewalls, logwatch, etc). This focusses more upon objective-based learning than task-based: people will do something because they understand the benefits of doing so, rather than do it because they've been taught to.

 

Dunno if that makes sense... but it's become my driver for most things nowadays. "why *am* I doing this?" is a frequently-asked question!

Quote:Most books tend to follow a similar path: grouping a number of topics together, and then focus upon the HOW - eg: how to manage users.. how to manage hardware... how to manage software... etc.

 

In courses I teach, I try to get across the WHY, WHO, WHEN (and the "what if not") - what are the benefits of doing such an action, who should be expected to do it, how often (could it be automated), what would happen if it was not done (firewalls, logwatch, etc). This focusses more upon objective-based learning than task-based: people will do something because they understand the benefits of doing so, rather than do it because they've been taught to.

 

Dunno if that makes sense... but it's become my driver for most things nowadays. "why *am* I doing this?" is a frequently-asked question!

 

That sounds real interesting Dave :)Would it be possible for me to get a copy of your one of your beginners linux courses, I would be willing to pay for it. If not no problem I understand, then I'll just have to do it with what I do have. I just find it an interesting point you made, and I find it sounds alot more useful knowing why you do something instead of because you were taught so. Cuz now that you have mentioned it, it sounds alot like what I've come across so far in books you do it because they say so.

I run two such courses: 2-day Intro covering basics of commands, general shell familiarity.

 

The 3-day admin takes it further, covering:

- user administration

- basic security (logfile analysis, setting policy and some firewall configs)

- software management (list,install, update, remove, compile)

- hardware management (listing/adding, checking modules)

- disk management (adding/removing disks, partitioning, filesystem creation)

- filesystem and basic performance tuning (quotas, system monitoring tools)

- backup and recovery

- recovering from boot issues.

 

Although I insist that attendees of the admin use the intro as a pre-requisite, generally if they know cd/ls/cat/vi and have familiarity with redirection/pipes and man pages then they're fine to attend the admin.

 

My course notes are - unfortunately - more of a terse summary of topics covered, including examples, and aren't written to be self-taught guides... the idea being I don't stand at the front and read them out: I take people through the concepts, walking them through commands to show what they do, then discuss what has been learned. We then review the course notes to see a record of what they've just done before letting them loose on the exercises when they can have an unassisted go.

 

Much of what I cover has been posted here already on the forums! However, I'm happy to cover any topics if you're struggling on anything.

ah ok :)I will just start going through the book I have and just take notes and try and learn if I have any questions I will ask. Just one question. I need some advice on taking notes when learning new things in Linux. I find it that most topics are so detailed that it's hard to take out the main thing of that topic instead of the subject with all its details.

Then my notes become to detailed and the concept becomes harder to learn. Cuz I think if I was able take out the basic idea/concept out of a topic/idea easier than my notes would be easier to understand and learn and easier to practice with. You know what I mean?

Quote:I need some advice on taking notes when learning new things in Linux..... Cuz I think if I was able take out the basic idea/concept out of a topic/idea easier than my notes would be easier to understand and learn and easier to practice with. You know what I mean?

Yup. Try the following:

 

1. Approach it from a task viewpoint, rather than topic viewpoint. "Setting up new users" or "managing FTP stuff", rather than "pure-pw" and "usermod". Try to break the task down into numbered steps to follow, as though you're writing your own guide on how to do something - make it flow rather than information dump.

 

(for good examples of this, look at the Linux HowTos)

 

2. Categorise your notes into specific groupings - setting up drupal and setting up apache may all come under "web stuff". Apache/FTP/mail may come under "server stuff". It doesn't need to be completely specific, just different directories to drop your notes into. It makes it quicker to locate specific notes.

 

3. Flow: In all my cheat-sheets, I often flick between explanatory text and commands+output, just to show:

a: what is being achieved (and why)

b: what command (or format of) to type

c: what output should the command give (indicates success)

 

Also: how do I check what I've done?

d: how can I verify the results?

 

(example: for b, I would use the "pure-pw useradd" command. for c, I get nothing back.. for d, I use "pure-pw show" to query and report on the newly-created account)

 

4. Presentation: consider the format of your notes. A lot of good documentation is presented using diagrams, pictures, lists (numbered/bulletted), flowcharts, etc - you should be able to capture a lot of information at a glance without having to weed through piles of text.

 

Now, if you look back through that advice, you'll see that I've followed my own principles - numbered points with emboldened words to show the purpose of each point. Give that a go...

thanks :)