Tips for wandering faculty

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Tips for wandering faculty

kirby urner-4
By wandering faculty, I mean you're invited to gigs in a room you
don't control and maybe have never seen before -- my situation rather
often.  A lab tech has likely installed Python ahead of time, but in a
lab situation, there's always the question of rights, especially write
rights.  The typical thing is to not know or care about
/site-packages, and so to have no writable access to *any* disk space
on the default Python path.  Your mileage may vary.

We have several ways of addressing this situation, both from within
the bash shell (if using Linux or maybe OS X) or from within Windows.
To keep things Pythonic, I mix the subject of namespaces, essential
early Python, with the example of sys, and sys.path in particular.
Here's an importable resource you're able to append to, meaning
whatever home directory you *can* write to is appendable to sys.path
per this session.  And that's a good thing.  Plus it reinforces the
core concept:  import menagerie as zoo and/or from zoo import Dog,
Monkey, Human.  Many side bar topics also feature (including escape
characters, if you want to stick with Windows backslash notation -- I
have a take-it-or-leave-it attitude, as Python is quite willing to use
forward slashes even on Windows).

I like this segment for another reason:  unlike some educators, I have
no interest in "shielding" my students from the gross reality of some
hunkering OS, complete with kernel, GUI resources and whathaveyou.

Yes, a Linux system is huge and complicated.  No, I don't favor
"insulating" students from that hugeness, by constructing some dream
world atop it and inside it, but unaware of it.  This whole idea that
we must "protect" students from this context is an anathema to me, as
it's hypocritical.  The people who *build* your pseudo or virtual
reality need to know about these underlayers, these pipeworks and
clockworks.  Their not wanting to clue you in is a sign they're not
treating you as a peer, but as a rat in some maze of their own
devising.

It may sound like I'm taking aim at Squeak here, but I'm not really.

Squeak provides a more open source world that goes almost to the chip,
just like Linux.  You have access to the source code if you want it,
down to where SmallTalk meets C, at which point there's not a lot to
see (others have commented on this piece -- what Python might stand to
gain from once the intended meetings happen in the Bay Area).

More I'm taking aim at curricula which haven't discussed the file tree
by the time we're dealing with 15 year olds.  If you're already 15,
and have no access to a bash shell, or the concepts of hard disk and
filesystem, then IF you're actually using a hard drive with a file
system, you're being ripped off, big time.  Time to shop for a smarter
set of teachers.  Learn about partitions, standard trees and variants,
search paths, config files.  Don't let them hide that stuff behind a
curtain.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

Chuck Allison
ku> I like this segment for another reason:  unlike some educators, I have
ku> no interest in "shielding" my students from the gross reality of some
ku> hunkering OS, complete with kernel, GUI resources and whathaveyou.

But novices can handle only so much. I agree that we don't want to
create artificial worlds, but we must take care on how much and what
we present on day 1. The surest way to lose students is to talk about
things they don't understand and see no need for. Kernels are not day
1 material (for anyone).

The other issue, of course, is the variety of learning paradigms. Some
people are more visually oriented than others. When I taught Python to
adult testers last year we didn't need a visual approach (although we
used Komodo for easy development). But when my 14-year old nephew last
year said, "Uncle Chuck, teach me to program!", I had his attention
for 30 seconds and then he was gone because I had nothing graphical
(i.e., Alice-like) for him to play with. He just could not grasp
typing 2+3 at the command-line ad getting 5 out. Who cares about a
linear conversation with a computer console?

--
Best regards,
 Chuck

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

kirby urner-4
> But novices can handle only so much. I agree that we don't want to
> create artificial worlds, but we must take care on how much and what
> we present on day 1. The surest way to lose students is to talk about
> things they don't understand and see no need for. Kernels are not day
> 1 material (for anyone).
>

I show excerpts from the documentary 'Revolution OS' (not the whole
thing), in which Linus himself does a good job of describing the job
of an operating system.  I don't do this on day one though, like you
say.

> The other issue, of course, is the variety of learning paradigms. Some
> people are more visually oriented than others. When I taught Python to
> adult testers last year we didn't need a visual approach (although we
> used Komodo for easy development). But when my 14-year old nephew last
> year said, "Uncle Chuck, teach me to program!", I had his attention
> for 30 seconds and then he was gone because I had nothing graphical
> (i.e., Alice-like) for him to play with. He just could not grasp
> typing 2+3 at the command-line ad getting 5 out. Who cares about a
> linear conversation with a computer console?
>

I tell my Saturday Academy kids that if they're serious about
programming, they need to learn to be "brutally lexical" -- and then I
go on to demonstrate what that means (which *doesn't* mean we never do
graphical).

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

ianb
In reply to this post by kirby urner-4
kirby urner wrote:
> Yes, a Linux system is huge and complicated.  No, I don't favor
> "insulating" students from that hugeness, by constructing some dream
> world atop it and inside it, but unaware of it.  This whole idea that
> we must "protect" students from this context is an anathema to me, as
> it's hypocritical.  The people who *build* your pseudo or virtual
> reality need to know about these underlayers, these pipeworks and
> clockworks.  Their not wanting to clue you in is a sign they're not
> treating you as a peer, but as a rat in some maze of their own
> devising.

Personally I wish *I* could be insulated from more of this; leaky and
imperfect systems make this impossible at the moment.  A strong
abstraction is great -- at some point you may need to understand what
that abstraction is built on, but even then it is nice to be able to
retreat back into the abstraction so you can focus on what's really
interesting and new that you are doing.

There's a bunch of examples of this which I think are uncontroversial.
Things like GC, pointers, characters (which are missing in Python),
TCP/IP (which few people access directly anymore), the underlying
mechanisms of threads and processes, and a bunch of other things that
are so basic I have a hard time remembering they exist.

Anyway, tangential to this, but maybe useful, I wrote a script to create
isolated Python environments that doesn't require the cooperation of the
system Python installation:
http://blog.ianbicking.org/workingenv-revisited.html -- it may be useful
for educational environments as well; easy to set up, and easy to throw
away if you mess up your environment.  Though it's dependent on
PYTHONPATH, which isn't very accessible in a typical Mac or Windows
environment (unless you are using one of those in a unixy style);
hopefully someone familiar with those environments can suggest something.

In this case, I think the status quo -- which forces you to think about
the entire system, package management, etc -- is simply dumb.  It's dumb
for experienced programmers and dumb for newbies.  For experienced
programmers the status quo is sloppy and implicit; for newbies the
status quo is dangerous and inaccessible.  Neither group is well served.
  Kind of like manual memory management... we shouldn't mistake design
problems for deep and useful ideas.  There's hard and deep and useful
ideas too; I'm just pointing out that not all hard things are deep or
useful ;)


--
Ian Bicking  /  [hidden email]  /  http://blog.ianbicking.org
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

kirby urner-4
> Personally I wish *I* could be insulated from more of this; leaky and
> imperfect systems make this impossible at the moment.  A strong
> abstraction is great -- at some point you may need to understand what
> that abstraction is built on, but even then it is nice to be able to
> retreat back into the abstraction so you can focus on what's really
> interesting and new that you are doing.
>

That's nice if you're not just into escapist fantasy.  Great to bliss
out in a well-designed and productive environment, no one arguing with
that.  But that's no excuse for keeping kids clueless too long.

> There's a bunch of examples of this which I think are uncontroversial.
> Things like GC, pointers, characters (which are missing in Python),
> TCP/IP (which few people access directly anymore), the underlying
> mechanisms of threads and processes, and a bunch of other things that
> are so basic I have a hard time remembering they exist.
>

We use 'Warriors of the Net' (a movie) to introduce TCP/IP (by "we" I
mean the Silicon Forest based educators I work with).  It makes as
much sense to start with TCP/IP as it does with RAM and CPU in some
ways.  It's easy to look at processes through any kind of task manager
(bash or Windows, doesn't matter).

Learning to kill a process is pretty basic.  I'll have kids start 'em
just to kill 'em.  They enjoy the sense of power this gives them.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Turtles all the way down (was Re: Tips ...)

Paul D. Fernhout
kirby urner wrote:
 > Ian Bicking wrote:

>>Personally I wish *I* could be insulated from more of this; leaky and
>>imperfect systems make this impossible at the moment.  A strong
>>abstraction is great -- at some point you may need to understand what
>>that abstraction is built on, but even then it is nice to be able to
>>retreat back into the abstraction so you can focus on what's really
>>interesting and new that you are doing.
>>
> That's nice if you're not just into escapist fantasy.  Great to bliss
> out in a well-designed and productive environment, no one arguing with
> that.  But that's no excuse for keeping kids clueless too long.

Isn't "abstraction" mathematically simplifying something somehow, or
creating an alternative mapping of part of the system to a symbol system
you are comfortable working with?  And isn't "fantasy" making up new stuff
you like (even if only in your mind) from bits and pieces of ideas you
have experience with?  So, isn't even much of GNU/Linux is an
"abstraction" away of many hardware details, like file systems are
abstractions hiding how many disk platter you have and what sectors are in
use, and "device nodes" are another abstraction, as are the "services" the
kernel provides? They could all be provided other ways (or not at all),
using other APIS, and are different on other computers and OSs throughout
history (and may well change in the future). And, by contrast, the Linux
kernel only a "fantasy" of Linus Torvalds (at one much earlier point, for
some short time before he set to coding).  So, when kids learn the guts of
Linux, it seems they are still learning only an abstraction that was once
a fantasy. Maybe something to remind them about occasionally.

I liked Ian's point and your response because it reminds me of that Star
Trek:TNG episode where people think they are leaving the Holodeck, only to
find out later the ship they are in is still really just a virtual one and
they are still on the Holodeck. For all we know, this reality is just a
"escapist" simulation too: :-)
See:
   "Are You Living In a Computer Simulation?"
   http://www.simulation-argument.com/

The more practice kids have mastering (and even creating or transcending)
various new-to-them systems of rules the more prepared they will be for
whatever life (or death :-) may throw at them down the road.  Also, it is
in our choices of what systems of rules to learn that we make some of
life's hardest and most important decisions. So, by all means, it is good
to encourage kids to get into details (like inodes) underneath
abstractions (like files) when they want to, as a new and potentially
useful sort of set of rules to master. But, just remind them, there always
may be another layer of "turtles" :-).
    http://en.wikipedia.org/wiki/Turtles_all_the_way_down

A related motivational CP4E question for kids who have probably all see
the movie "The Matrix":
Turtle -> Python -> OS -> Hardware -> Physics -> Universe -> Turtle?
Of course, that question may be just too explosive for some classrooms?

To somewhat address the original "Tips" question, and to address a genuine
issue of computer literacy as GNU/Linux rises in dominance, and to address
this issue of mastering multiple levels of abstraction, perhaps kids and
even some teachers could be encouraged to make a tiny GNU/Linux
distribution to make a Python interpreter shell that boots from on a
diskette or USB stick or CDROM, and creates a RAM disk for classroom
experiments. It isn't that hard.
See:
   http://www.linuxlinks.com/Distributions/Floppy/ [has one already]
   http://www.linuxfromscratch.org/ [general instructions]
Then you would have a custom Python which would be useful for wandering
faculty (assuming the admins let you reboot the machine, and it was
configured to allowing booting from removable media).

--Paul Fernhout
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

PC terminology to end processes? (was Re: Tips ...)

Paul D. Fernhout
In reply to this post by kirby urner-4
kirby urner wrote:
> Learning to kill a process is pretty basic.  I'll have kids start 'em
> just to kill 'em.  They enjoy the sense of power this gives them.

I see the value in encouraging kids to have a sense of their own power,
but I have a script on my system (just for myself) which lets me type
"stop" instead of "kill".

Even in a virtual world of computing, is teaching kids to "kill" a good
message? Language does effect thought to an extent.
   http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis

I feel a bit the same way about some user manuals that go on about
"depressing" or "hitting" buttons. "Press" is a better choice I think.

Also, someday those processes might represent sentient AIs and attempting
to "kill" them might have serious consequences. Perhaps good to to get
kids thinking about the potential rights of any sentience, even now. :-)

--Paul Fernhout
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

Michael Tobis
In reply to this post by ianb
Ian, among his talents, has a knack for terse, interesting
generalizations. His style is so laid back that sometimes I wonder if
other people notice how clever some of the things he says are. For
instance:

"we shouldn't mistake design
problems for deep and useful ideas.  There's hard and deep and useful
ideas too; I'm just pointing out that not all hard things are deep or
useful"

That's a keeper.

On the other hand, let me remind everyone that many people despair of
this list because it spends too much time on impractical generalities.

So I would add that we shouldn't mistake interesting conversations for
progress. Many of the topics raised here are hard and deep but, at
least for present purposes, still not very useful.

I believe should keep the conversation germane to the intersection of
Python and education, specifically, to the development of Python tools
that are relevant to education.

I don't know what the twentieth precept is, but I nominate:

"La perfection est atteinte non quand il ne reste rien a ajouter, mais
quand il ne reste rien a enlever" -Antoine de St Exupery

Let's try to say less and say it better.

mt
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Turtles all the way down (was Re: Tips ...)

ianb
In reply to this post by Paul D. Fernhout
Paul D. Fernhout wrote:

> To somewhat address the original "Tips" question, and to address a genuine
> issue of computer literacy as GNU/Linux rises in dominance, and to address
> this issue of mastering multiple levels of abstraction, perhaps kids and
> even some teachers could be encouraged to make a tiny GNU/Linux
> distribution to make a Python interpreter shell that boots from on a
> diskette or USB stick or CDROM, and creates a RAM disk for classroom
> experiments. It isn't that hard.
> See:
>    http://www.linuxlinks.com/Distributions/Floppy/ [has one already]
>    http://www.linuxfromscratch.org/ [general instructions]
> Then you would have a custom Python which would be useful for wandering
> faculty (assuming the admins let you reboot the machine, and it was
> configured to allowing booting from removable media).

Well, you could also just include Python without the OS ;)  I think that
would be easier.  Has anyone tried Movable Python
(http://www.voidspace.org.uk/python/movpy/)?  It's only for Windows, but
I assume the technique is mostly portable (though some of the libraries
are not so easy, I imagine, like wxPython).  Anyway, I'm sure you could
fit Python for several OS's onto one CD plus some useful libraries, and
save some time doing setup, which is otherwise a great way to waste a
lot of class time.  Has anyone put together such a bundle?  Or maybe
it's already out there, even if written for other reasons.


--
Ian Bicking  /  [hidden email]  /  http://blog.ianbicking.org
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Bootable Python CDs?

Paul D. Fernhout
In reply to this post by Paul D. Fernhout
I previously wrote:
> Then you would have a custom Python which would be useful for wandering
> faculty (assuming the admins let you reboot the machine, and it was
> configured to allowing booting from removable media).

I just noticed this:
    http://wiki.python.org/moin/PythonCd
"Welcome to your Python CD! This is a bootable CD based on [Debian
GNU/Linux and KNOPPIX. The special thing about it is that it has lots of
Python stuff!"

Anyone used it?

I'm curious: is it even practical to expect to walk into most modern
educational computer lab in a typical school and expect to be able to
reboot all the computers to run from your own Python CD? Do people's
school computer labs typically allow a boot from removable media?

I know it was quite possible to boot your own stuff when I ran an
educational computer lab (or rather, impossible to stop. with those
motherboards) but that was a long time ago (back in the days of 5-1/4 and
Token Ring). I don't know what typical admin policies would be now. But
todays' motherboards seem much more likely to have an option for picking
the boot medium on reboot (but also more options to disable media booting
which you would need to get into the BIOS settings to change).

--Paul Fernhout
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Bootable Python CDs?

Doug Blank-3
On Wed, 2006-04-26 at 19:05 -0400, Paul D. Fernhout wrote:

> I previously wrote:
> > Then you would have a custom Python which would be useful for wandering
> > faculty (assuming the admins let you reboot the machine, and it was
> > configured to allowing booting from removable media).
>
> I just noticed this:
>     http://wiki.python.org/moin/PythonCd
> "Welcome to your Python CD! This is a bootable CD based on [Debian
> GNU/Linux and KNOPPIX. The special thing about it is that it has lots of
> Python stuff!"
>
> Anyone used it?
>
> I'm curious: is it even practical to expect to walk into most modern
> educational computer lab in a typical school and expect to be able to
> reboot all the computers to run from your own Python CD? Do people's
> school computer labs typically allow a boot from removable media?

I haven't used this CD, but we do have a similar disk with all of our
Python-based robotics stuff here:

http://pyrorobotics.org/?page=PyroLiveCD

including a Python-based wrapper on a 3D simulator (Gazebo) that you can
control from Python. You can drive a helicopter from Python! How cool is
that?

It is very practical to turn a regular lab of Windows machines into a
lab of Linux machines (as long as they don't have the "boot from CD"
locked down with a BIOS password, which they might. You can mount any
disk and fiddle with it, so there are some security issues here.). Do
note that you need to have a CD for each machine, as it reads from the
CD as it needs to. This also makes it a little slower on the start-up.
If your machines have good RAM and CD-ROM drives, you'll barely notice
though.

These disks are great for giving tutorials at workshops and conferences,
and very nice to have so students can do their work at home.

-Doug

> I know it was quite possible to boot your own stuff when I ran an
> educational computer lab (or rather, impossible to stop. with those
> motherboards) but that was a long time ago (back in the days of 5-1/4 and
> Token Ring). I don't know what typical admin policies would be now. But
> todays' motherboards seem much more likely to have an option for picking
> the boot medium on reboot (but also more options to disable media booting
> which you would need to get into the BIOS settings to change).
>
> --Paul Fernhout
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
>
--
Douglas S. Blank       Computer Science
Assistant Professor    Bryn Mawr College
(610)526-6501          http://cs.brynmawr.edu/~dblank


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Turtles all the way down (was Re: Tips ...)

kirby urner-4
In reply to this post by ianb
> Anyway, I'm sure you could
> fit Python for several OS's onto one CD plus some useful libraries, and
> save some time doing setup, which is otherwise a great way to waste a
> lot of class time.

That sounds feasible in some cases. At Saturday Academy, I phone in
what I'd like in the lab, maybe a few weeks ahead of time.  I don't
personally install stuff, nor necessarily have the rights to (I'm not
usually root nor even sysop on PSU systems).

I bring one of my own laptops to demo my stuff from the instructor desk.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

kirby urner-4
In reply to this post by Michael Tobis
> On the other hand, let me remind everyone that many people despair of
> this list because it spends too much time on impractical generalities.
>

You may so remind, but I will remind everyone too that this is also a
celebrated list, the subject of a PhD thesis, with a long and
venerable history, including many memorable performances by Tim Peters
himself.  I can't think of many lists that have been more productive.

> So I would add that we shouldn't mistake interesting conversations for
> progress. Many of the topics raised here are hard and deep but, at
> least for present purposes, still not very useful.
>

To whom?  Do you really get to pass judgment at such a high level?  I
don't even remember your being here very long.

> Let's try to say less and say it better.
>
> mt

Let's try to be less obnoxiously sanctimonious.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: PC terminology to end processes? (was Re: Tips ...)

kirby urner-4
In reply to this post by Paul D. Fernhout
On 4/26/06, Paul D. Fernhout <[hidden email]> wrote:
> I see the value in encouraging kids to have a sense of their own power,
> but I have a script on my system (just for myself) which lets me type
> "stop" instead of "kill".

I'm disgusted that "kill" isn't politically correct enough.  We're
engineers, not politicians.

> Even in a virtual world of computing, is teaching kids to "kill" a good
> message? Language does effect thought to an extent.

Sheesh.

> I feel a bit the same way about some user manuals that go on about
> "depressing" or "hitting" buttons. "Press" is a better choice I think.
>

OK, so now you're just being funny.   Hah!

> Also, someday those processes might represent sentient AIs and attempting
> to "kill" them might have serious consequences. Perhaps good to to get
> kids thinking about the potential rights of any sentience, even now. :-)
>
> --Paul Fernhout

Right.  Be fearful little huddly creatures, all aquiver and afraid o
dat big bad AI monster.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: PC terminology to end processes? (was Re: Tips ...)

ianb
kirby urner wrote:
> On 4/26/06, Paul D. Fernhout <[hidden email]> wrote:
>> I see the value in encouraging kids to have a sense of their own power,
>> but I have a script on my system (just for myself) which lets me type
>> "stop" instead of "kill".
>
> I'm disgusted that "kill" isn't politically correct enough.  We're
> engineers, not politicians.

I like kill too.  It's like the difference between "self" and "this";
self is the personification and anthropomorphic form, and this is the
object form.  I like self more.  I like metaphors.  And putting science
fiction and theatric effect aside, I can't imagine any future where
killing processes is at all related to killing people, so I don't think
it can be taken too seriously.


--
Ian Bicking  |  [hidden email]  |  http://blog.ianbicking.org
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Bootable Python CDs?

Grégoire Dooms
In reply to this post by Paul D. Fernhout
Paul Fernhout wrote:

> I previously wrote:
>> > Then you would have a custom Python which would be useful for wandering
>> > faculty (assuming the admins let you reboot the machine, and it was
>> > configured to allowing booting from removable media).
>>    
>
> I just noticed this:
>     http://wiki.python.org/moin/PythonCd
> "Welcome to your Python CD! This is a bootable CD based on [Debian
> GNU/Linux and KNOPPIX. The special thing about it is that it has lots of
> Python stuff!"
>
> Anyone used it?
>  

I did not try that one but developped my own a few years ago:

http://www.info.ucl.ac.be/~dooms/python/python.html
It is  a morphix mainmodule which is easily complemented by minimodules.
I have been using it since to teach Python to adults.
The CD includes  VPython, Jython, mysql, Boost.Python, etc...
I gets a little old now and would need a upgrade (Python 2.3, some newer
network cards not supported).
> I'm curious: is it even practical to expect to walk into most modern
> educational computer lab in a typical school and expect to be able to
> reboot all the computers to run from your own Python CD? Do people's
> school computer labs typically allow a boot from removable media?
>  

At the place where I use this CD, they disable USB but let me boot from
the CD.

Best,
--
Grégoire Dooms.

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Turtles all the way down (was Re: Tips ...)

Laura Creighton
In reply to this post by ianb
In a message of Wed, 26 Apr 2006 17:56:57 CDT, Ian Bicking writes:

>Well, you could also just include Python without the OS ;)  I think that
>would be easier.  Has anyone tried Movable Python
>(http://www.voidspace.org.uk/python/movpy/)?  It's only for Windows, but
>I assume the technique is mostly portable (though some of the libraries
>are not so easy, I imagine, like wxPython).  Anyway, I'm sure you could
>fit Python for several OS's onto one CD plus some useful libraries, and
>save some time doing setup, which is otherwise a great way to waste a
>lot of class time.  Has anyone put together such a bundle?  Or maybe
>it's already out there, even if written for other reasons.
>
>
>--
>Ian Bicking  /  [hidden email]  /  http://blog.ianbicking.org

I've used Knoppix http://www.knoppix.org to provide a bootable
linux system packed with whatever it was I wanted to teach.  So far it
hasn't been python that I have been teaching, but I see no reason why
this shouldn't work.

Laura

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Bootable Python CDs?

Laura Creighton
In reply to this post by Paul D. Fernhout
In a message of Wed, 26 Apr 2006 19:05:20 EDT, "Paul D. Fernhout" writes:

>I previously wrote:
>> Then you would have a custom Python which would be useful for wandering
>
>> faculty (assuming the admins let you reboot the machine, and it was
>> configured to allowing booting from removable media).
>
>I just noticed this:
>    http://wiki.python.org/moin/PythonCd
>"Welcome to your Python CD! This is a bootable CD based on [Debian
>GNU/Linux and KNOPPIX. The special thing about it is that it has lots of
>Python stuff!"
>
>Anyone used it?

I didn't even know about it.  Thanks.

>I'm curious: is it even practical to expect to walk into most modern
>educational computer lab in a typical school and expect to be able to
>reboot all the computers to run from your own Python CD? Do people's
>school computer labs typically allow a boot from removable media?

Around here all student machines get completely wiped every month
(sometimes every week) without fail.  Otherwise they are packed
with viruses, porn, and other junk.  So bring-your-own distribution
is the way to go.  The only tricky thing is making sure that the
students -- who want to save their own work on a CD -- actually
do this properly.

<snip>

>--Paul Fernhout

Laura
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Tips for wandering faculty

Stuart Williams
In reply to this post by kirby urner-4
>>>>> kirby urner writes:

>> So I would add that we shouldn't mistake interesting conversations for
>> progress. Many of the topics raised here are hard and deep but, at
>> least for present purposes, still not very useful.

> To whom?  Do you really get to pass judgment at such a high level?  I
> don't even remember your being here very long.

>From the perspective of someone who recently joined, I don't remember
you being here very long either, and I hope this isn't a list where
the worth of a post is based primarily on how long the poster has been
in the club.

Stuart.
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Bootable Python CDs?

Paul D. Fernhout
In reply to this post by Laura Creighton
Laura Creighton wrote:
> So bring-your-own distribution
> is the way to go.  The only tricky thing is making sure that the
> students -- who want to save their own work on a CD -- actually
> do this properly.

Wow, I had not even thought about students saving their work beyond to a
RAM disk for the session. Nor had I really thought they would take the
initiative to use a CD-ROM burner, but I guess those are common in school
labs now? And I can see how it would be tricky, if you boot from a CD, to
be able to write to a CD, since the system often has to load applications
or libraries from CD. Any tips or pointers to links for managing this
properly? I think I did it once, but I think I used an external USB
writer. Here is a tip on that which seems to imply you need two CD-ROM
drives (one for reading, and one for writing)
  http://www.eleli.de/knoppix/docs/tutorial/english/k3b.html
Sounds then like the ideal computer set up, from the point of traveling
faculty, would be a lab full of machines that may have no hard disk but
have a CD-ROM reader (or even DVD-ROM reader, for bigger distros) and also
a separate CD-ROM burner (so students can save their work like they used
to do with floppies, but not worry about being able to eject the CDROM the
disto is running from). I've seen these two-CD machines in stores, I
wonder if they are common in computer labs or classrooms these days?
Or does anyone carry around a few external USB CD-ROM burners with them
for kids to use to save their work?

USB Flash drives with 64MB these days are about $10 retail, so is it
possible to expect people to bring their own, or alternatively give them
out in class to keep (if it was a paid gig), to use to save their work
from done from the bootable CD? Do computer lab PCs in schools now
typically have at least one up-front USB ports for easy access?

Of course, how important is it in in most cases for students to really
save their work from playing with Python for one session? Is this really
needed?

And now, another thought, maybe if there was some easy way to save your
work to the Python site or some other web hosting service (gmail?) then
you would not need to worry about kids writing their stuff to CD or USB,
they could just run some magical Python application that would stash their
Python work on the network somewhere for later retrieval. I can see the
value of that as something to consider building into a Python educational
environment.

I know, for me, this newer 2005 version of Knoppix with the UnionFS
http://www.oreillynet.com/sysadmin/blog/2005/03/knoppix_38_and_unionfs_wow_jus.html
is a big deal in my own use (since I often wanted to use some package that
was not up-to-date on them, but I had a network). With UnionFS in Knoppix
you can boot and still grab new packages with apt-get from the network
transparently. So, if you are going to a computer lab with network access
  to the outside world (is this taken for granted these days in the USA?)
then you could boot with either a plain or a somewhat customized Knoppix,
but still get users to download the latest Python and version of other
learning software from the network with a command line "sudo apt-get
install package-name".

Probably more chance of things going wrong relying on a network, but less
need to update your CDs every time you make some change to your
demonstration environment. For example, you could keep the latest Python
learning environment on your own web site or publish it through Debian,
but have the lab all boot a customized Knoppix with an apt sources file
which includes a reference to your own web server if needed. Then, you
have at least the older version of your stuff on the CDs, but you also
have the option of getting newer stuff. Still, it seems like a pain to
burn dozens of custom CDs (when you can get them for a dollar or even free),
   https://shipit.ubuntu.com/
so working with off-the-shelf solutions like an Ubuntu Live CD and having
the kids fetch and install your own specific latest Python software off
your website using the network is easiest (if you can trust the network to
be there). Though that would take getting everyone to type at least few
lines on the command line, one to fetch the package from the web to /tmp
"cd /tmp; wget http://myserver/wonderful_python_educational_app.deb", one
to install it with "dpkg -i wonderful_python_educational_app.deb", and one
to run it "wonderful_python_educational_app". Of course this could also be
done without apt if you just had an archive with a regular directory you
unpacked to /tmp and then did a
"python wonderful_python_educational_app.py".

I like the notion too that you could burn CDs for people to take home to
do stuff there too.

I remember when the NeXT system with the first magneto-optical drives came
out, and the big excitement was people could have their whole environment
on a 256MB disk to take with them and boot from and do their work on
public computers. It sounds like this is being realized to an extent for
everyone now with bootable CDs. So, the free licensing of GNU/Linux is
making a real difference then in what educators can accomplish with Python
in computer lab on a practical basis (since you could not legally burn
your own CDs with Windows or Mac OS/X on them, without special
arrangements with those companies).

By the way, not so sure about Mac labs; that would take a separate distro,
like a bootable CD of YDL (Yellow-Dog Linux) if such exists?
   http://www-128.ibm.com/developerworks/library/l-ydlg5.html
   http://www.terrasoftsolutions.com/products/ydl/
Anyone successfully boot Mac labs with YDL CDs to run Python under
GNU/Linux? It looks like you can do it other ways though to use stuff from
Apple:
   http://en.wikipedia.org/wiki/LiveCD#Apple_Macintosh_OS-based
(but I am not sure about the licensing issues there either for personal or
lab use). Here is recent discussion implying Ubuntu will do it too:
   http://www.htmlforums.com/archive/index.php/t-69520.html
and it looks like some success with the latest Intel macs:
   http://digg.com/apple/Ubuntu_Live_on_Mac_Mini_with_Ease_
and looking further, looks like it is definitely doable in theory with Ubuntu:
   http://www.ubuntuforums.org/archive/index.php/t-21233.html
(whether that works in practice in Mac labs is a different story, of course).

So, it sounds like with a bunch of CDs, some for Intel/PC and some for
PPC/Mac, itinerant faculty could (theoretically) handle working in a known
environment with current Python support in a lot of computer labs. And
then they could possibly also download the latest specific environment
they wanted through the network if there was one (or alternatively,
distribute the latest environment from a few USB FLASH drives passed
around the lab?)

Thanks for all the other replies (that robot oriented Python distro looks
like a lot of fun!) It sounds like it is a real possibility in many
situations in education to either use off the shelf Knoppix-derived
bootable CDs, or alternatively rolling your own GNU/Linux distro, to make
sure the lab is running Python (or another app) the way you want (at
least, for Windows/PC labs). And what's more, it's actually being done in
practice by some.

--Paul Fernhout

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
123