In comp.os.linux.advocacy, Roy Schestowitz
on Wed, 31 Dec 2008 03:08:24 -0800 (PST)
> Linux Confiscation At School.
> ,----[ Quote ]
> | What concerns me here is that schools tend to be teaching
> | kids that using computers is about learning to use
> | microsoft products such as word, powerpoint etc, all very
> | well, but how about introducing elements of computer
> | science into the classroom and not just leaving it as an
> | option for further education. Anyhow, the event is fully
> | talked about in the the tech guy podcast.
> The Linux laptop goes to school
> More Ways That Open Source Could Benefit Schools
I've got news for you....NOBODY uses computers.
At best, the erstwhile Windows users or Linux user
is moving a soap bar around (or clicking on one of
the buttons), sending serial commands to a serial port
(or a USB in lieu thereof). These commands go through a
driver, which interrupts the kernel. The kernel is about
the first place where the soap bar pusher is actually
interacting with something resembling a modified von
Neumann architecture but there's still a long way to go.
So the kernel processes this information, and decides
where it should go. If I'm not mistaken, there's usually a
daemon (in Linux, it's X proper; Windows I'd have to look
but it's probably a top-level message dispatcher) waiting
for mouse events; it chews on these events and passes
them on to whoever is expecting mouse events (which for X
becomes a multiprocess problem). Finally, the application
(or more likely a GUI widget library) gets to try to grok
what the soap bar's movements/buttonpresses mean.
Hardly a direct path to the computer for the typical user.
Keyboard stuff and CLI-based stuff is similar; if X is
involved the keyboard event path is similar to the mouse,
unless one is using a terminal emulator, in which case
pseudo-terminal devices get involved as an intermediary.
If X is not involved, Linux uses a console/serial driver --
the *real* terminal device, as it were.
Files are similar; if I write blocks to a file, the
application tells library to tell the kernel to put the
record somewhere; the kernel converts it into a block write
and can go through several layers of indirection.
Boiled down, all this means is that "computer teaching" is
at best a misnomer (unless the kids actually build their
own computers a la the ELF/1802, and even then that's
a bit of a misnomer as well, as the 1802 is basically a
building block as opposed to wiring up the transistors
oneself); one is communicating with other applications,
utilities, kernels, libraries, programs, code, and hoping
such communicates back to you, on a rather sophisticated
device set well back from the actual user. To that end,
one should probably learn the applications at best until
a higher level of schooling (do grade school kids really
need to learn int $0x80?), though it would be nice if
there were more emphasis on standards, perhaps.
One then goes into politics -- which applications?
Which vendor? At this point the kiddies might very
well be ushered out of the room, cigarettes lit, and an
entertaining (and ultimately profitable) discussion had
until the wee hours of the morning.... :-)
As for science....I'll admit to some curiosity as to what
is meant here, but then, we're not quite to the point that
we can predict precisely what [*]
unsigned f(unsigned x)
unsigned n = 0;
while(x != 1)
if(x % 2 == 0) x /= 2;
else x = 3*x+1;
will do, without actually running it...and some problems,
such as the halting problem, are known unsolvable at the
most general level.
I can go on about monitors, semaphors, and such, but
you get the idea.
[*] cf "Collatz Conjecture" for more details.
"Your mother was a hamster and your father smelt of
elderberries!" - Monty Python and the Holy Grail
** Posted from http://www.teranews.com **