On Thursday 13 February 2003 10:47, Frank Robers _ SOTL wrote:
> > Ok, help us here if you can. What kind of system basics?
>
> Before one can adequately understand the complex systems one has to have a
> firm grasp of what happens in a minimum basic system.
Absolutely.
> Such a system would have to incorporate such items as memory management, a
> text screen, a keyboards, and a storage devices such as a floppy.
> Additional devices can be mentally extrapolated from these basic devices.
Introduction to Computers 101?
- What is a CPU?
- What is RAM?
- What are input and output devices?
- What is mass storage?
- How does a mouse/keyboard work?
- What is a TTY?
- What is a bus?
- What is a network?
At some level, I'm almost willing to point people to HowThingsWork.com and
start from there:
http://electronics.howstuffworks.com/pc1.htm
Having run an ISP on my own and been through the tech support nightmare of
telling people how to plug a machine into the wall, I can tell you that I
don't want to teach people computers just to explain how Linux and OpenSource
software in general works.
Some baseline of knowledge is really neccessary: a computer course at the
local community college or a visit from your geeky 12 year old nephew might
be in order.
I'm far more interested in showing how software components interact for those
who are at least familiar with computers in general.
> (Least someone misunderstand the above the reference to a text screen
> refers to a command line screen not a graphics screen.)
A "TTY", ala teletype terminal. Do we reference back to punched cards as well?
Starting with the basic tenants of Unix design principles is a good idea,
however.
> The the idea is to learn the basics of the smallest - meaning least
> packages possible - possible Linux system that will theoretically run a PC
> size computer.
1. A kernel
2. A user-space application such as a shell.
You don't "need" anything more than this. Sure, you want /sbin/init if you
want anything more than painfully simple single-user mode, but the components
from that point forward depend on what "features" you need. Things like getty
are there to manage TTY devices. Others, like /bin/login are there to
authenticate users before giving them a shell. You only need libraries if you
wish to share code between binaries to save space and overhead. Describing
the purpose of each piece of software and the reasoning behind them would go
a long way toward proper education.
> If one uses theoretical operating system for discussion then there is no
> need to have a real world running system which would require time and
> effort to configure and construct and which would bring nothing to the
> presentation.
But using a theoretical operating system is something you do in college to
describe the basics to CS and EE majors who *must* know these things
abstractly to understand how the hardware functions.
I prefer to show practical applications of device drivers being used to
communicate with hardware so that folks can *follow* and *reproduce* things
on their own.
A whiteboard discussion or well thought out slideshow presentation is a good
idea as well, however. Relying on nothing *but* VNC recorded sessions really
doesn't help draw the abstract ideas and inter relationships for many
concepts.
> The objective is simply a blackboard presentation of data flows and program
> requirements.
How can we capture this and play it back or display it online? I'm interested
in any/all OpenSource tools that might do this well. Something generated into
HTML would be fine, with short flash video clip pop-up links to catch
demonstrations of commands that are mentioned in the tutorial.
> Considerable thought should be given as to how such a small basic Linux
> system PC system would interact with system Bois with absolutely NO
> consideration given to writing code.
Are you talking about a walkthrough from BIOS->LILO/GRUB->KERNEL? I can do
this now with VMWare in a VNC session without much effort.
Bootstrapping is the HAIRIEST stage. There are inane bits of archane legacy
compatibilities that make describing technical bits in detail *extremely*
difficult to most newbies. In fact, a suprising few CS/EE types actually
understand many of the specifics of how this works - particularly on
bastardized PC hardware.
Imagine a lecture series on BIOS versions alone: Award, AMI, Phoenix, MrBios,
proprietary BIOSes, hell - what about that nice old XT "basic ROM". Remember
that? Try walking through chipset initialization and memory checking (ECC,
parity, non-parity, etc), chipset register tweaking using Advanced BIOS
options, and other inane bits of detail that can make a user's PC die in a
POST beeping frenzy. Next explain legacy ISA IRQ assignments, commonly used
IO addresses, and conventional real-mode memory ROM mapping. Then imagine
describing CHS addressing, LBA addressing, LBA32 extensions, INT13 hooking,
and BIOS drive identification. Then there's the pain involved in describing
stage1/stage2 bootstrapping that isn't something I looking forward to either.
PCs are a horrible mess of legacy that can leave anyone but a PC tech in a
world of confusion.
> Such simple system should require simple block devices showing registers
> and such as a maximum.
Standard BIOS settings? Is there such a thing? ;)
-- - Ian C. Blenke <icblenke@nks.net>(This message bound by the following: http://www.nks.net/email_disclaimer.html)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:18:42 EDT