Re: Toaster: cdwrite.sh
Michael Paoli
http://rww.name/scripts/cdwrite.sh
code. I can think of many things to add/tweak, but it would be quite
useful to have a better idea of where we wish to be headed with it -
that would also be very useful for additional (potential) contributors.
So, questions, and stuff that might be rather to quite useful:
Version control repository - do we have a version control repository
for this code? That would be a good thing - especially while it's in
development (and even after). Would allow folks to grab latest or other
versions, merge and compare various contributions, etc.
I'm presuming somewhere under:
> code: http://git.sugarlabs.org/projects/toaster
... a particular place yet for the existing cdwrite.sh?
How 'bout a wiki page - have one of those somewhere for this particular
bit of software? Would be good to note/track on there stuff like:
design goals/criteria, wish list items, various design questions (and
their answers)
priorities
estimated level-of-effort for various portions (and that can also then
be used to adjust/reorder priorities as appropriate).
If there isn't already suitable wiki page or location for one to be
created, let me know, and I could probably create such under some
BALUG.org resource(s).
I'm presuming somewhere under:
> wiki: http://wiki.sugarlabs.org/go/Activities/Toaster
... a particular place yet for the existing cdwrite.sh and whatever it
may evolve to become?
Anyway, for starters, some questions, etc. that come up:
Copyright/ownership/license - shouldn't this go under some highly
standard Open Source license, and be assigned to OLPC or other suitable
entity?
Interpreter - wouldn't it be best to use /bin/sh, and stick with
POSIX/SUS as feasible, lest it break the instant bash changes some
bashism?
Shouldn't the name of the file just be cdwrite or something like that,
without ".sh" extension - that way if/when it's rewritten or replaced
with a binary or script in some other language or whatever, the name of
the executable can remain the same?
What exactly is the intention of:
[ $1 -ne $1 ]
... to ensure both self-same arguments are numeric (and match)?
Are targets to be, or at least potentially be more generic than CD,
e.g. other optical (DVD-R[W]), USB, other types of removable memory,
etc.? Perhaps then also some name other than "cdwrite" for the program?
stat(1) is quite standard on most Linux distributions, is it present by
default for these XOs? (can work around that if it's not).
perl(1) is quite standard on most Linux distributions, is it present by
default for these XOs? (perl(1) is also relatively large, so it may be
intentionally omitted - and it may be desirable to keep it off). What
about same question for Python?
checksums - might it be infeasible to fetch these from Internet (may be
used in offline scenarios)?
If/when we do/can check such checksums, shouldn't we also check
cryptographic signatures?
As bandwidth may be spotty/limited and/or unavailable, should we
effectively cache some checksum/signature data (so we can avoid
unnecessary/unavailable fetches, especially if we already got it before
not too horribly long ago)?
various observations:
eject -t will only close the tray for some types of drives
sleep 10 # wait for spin up
... better to do some loop that checks with 1 sec. sleep and max of say
10 seconds, so program can proceed once media is confirmed available,
trimming excess wait to about a second or less?
optical burn speed - even 8 is too high for some media types (e.g. some
have max of 4x). Should we read info. from drive and/or media to
determine speed? Or is our burning program "smart enough" to figure out
an optimal max speed?
What about +-RW media - should we detect and at least minimally blank it
first if needed (e.g. if it already contains other data). If it's
already got data, should we check if it might happen to already have
what we want to burn, or ask the user, or ???
We've got what we're copying - should we do a byte-by-byte read
comparison to validate? For all media types, or just optical targets?
What about floppy (if that might get used at all)?
Should have better checking / error handling if the burn/copy fails (but
looks like that's already know todo item)
beep - I'd think some suitable echo (e.g. echo -en '\007') ought to
work, but some more testing/investigation may be appropriate there.
Just a single beep, or do we want to be a bit more persistent - but not
too annoying?
USB memory stick or the like will require different handling than eject
or the like.
> Date: Sun, 14 Aug 2011 14:10:02 -0700
> Subject: Switching Gears: Toaster BASH script
> From: Grant Bowman <gran...@fedoraproject.org>
> To: xoto...@googlegroups.com
>
> I would like to change the focus to get something working for deployments.
>
> We have bash code to use as a basis and/or for comparison. This BASH
> script http://rww.name/scripts/cdwrite.sh can be basis for our work.
> Robert Wall wrote it and I contributed code for it. We have both used
> it to burn CDs for Ubuntu and other .iso images for quite awhile now.
>
> I would like to add a simple UI, eventually making it simple enough to
> primarily use the game keys on the XO to control the script.
>
> One option of questionable but perhaps useful value I have used to put
> a UI on a shell script is iselect. It is unfortunately not packaged
> for versions of Fedora I tried. The script is called "habit."
> https://github.com/grantbow/hacks/blob/master/habit It is a text
> based version of http://activehabits.com java android app.
>
> Who would like to help make a solution that works for kids at OLPC
> deployments to share open source software via burned CDs and USB
> sticks? There are many subtasks that need to be completed, not all of
> which I can specify to help people get started in a clearly defined
> way. We are pretty close in functionality but going the last way to
> make it usable for kids using XOs is critical to it's success. If you
> think you know what to try, please try something and let us know via
> the email list how it goes.
>
> Grant
>
> As a reminder here is our project description.
>
> This activity is intended to do two things
> * create USB sticks (such as Sugar on a Stick)
> * create a CD or DVD disc from an .iso image if the necessary USB
> burner hardware is available
>
> The goal is to allow any XO or anyone walking up to an XO-1 in book
> mode to select and create a
> bootable USB stick or disc.
>
> wiki: http://wiki.sugarlabs.org/go/Activities/Toaster
>
> bugs: http://bugs.sugarlabs.org/
>
> code: http://git.sugarlabs.org/projects/toaster
>
> open hatch: http://openhatch.org/+projects/Toaster%20Sugar%20Activity
>
> theme song: http://www.youtube.com/watch?v=GrF_K1w2haE
> From: "Grant Bowman" <gran...@gmail.com>
> Subject: Toaster URLs
> Date: Sun, 14 Aug 2011 13:34:24 -0700
>
> http://groups.google.com/group/xotoaster
>
> current code. http://rww.name/scripts/cdwrite.sh
Grant Bowman
The feature of google group html descriptions was removed so you
didn't see the links. I should have given you the wiki url too. Sorry
about that.
lots of documentation: http://wiki.sugarlabs.org/go/Activities/Toaster
bug tracker example, use "component: Toaster":
http://bugs.sugarlabs.org/ticket/1606
More comments inline.
On Mon, Aug 15, 2011 at 9:32 PM, Michael Paoli
<Michae...@cal.berkeley.edu> wrote:
> So, ... I've had a fair look over the
> http://rww.name/scripts/cdwrite.sh
> code. I can think of many things to add/tweak, but it would be quite
> useful to have a better idea of where we wish to be headed with it -
> that would also be very useful for additional (potential) contributors.
>
> So, questions, and stuff that might be rather to quite useful:
> Version control repository - do we have a version control repository
> for this code? That would be a good thing - especially while it's in
> development (and even after). Would allow folks to grab latest or other
> versions, merge and compare various contributions, etc.
> I'm presuming somewhere under:
>>
>> code: http://git.sugarlabs.org/projects/toaster
>
> ... a particular place yet for the existing cdwrite.sh?
As we have version control I will tag and remove the existing code
that we will probably not use much.
I will double check license compatibility of releasing this to OLPC
users. Things that upgrade cdwrite.sh should be contributed back to
Robert Wall via his email address. I've invited him to join this email
list though we are basically forking that cdwrite.sh code (which I
contributed to) for our new purpose.
> How 'bout a wiki page - have one of those somewhere for this particular
> bit of software? Would be good to note/track on there stuff like:
> design goals/criteria, wish list items, various design questions (and
> their answers)
> priorities
> estimated level-of-effort for various portions (and that can also then
> be used to adjust/reorder priorities as appropriate).
> If there isn't already suitable wiki page or location for one to be
> created, let me know, and I could probably create such under some
> BALUG.org resource(s).
> I'm presuming somewhere under:
>>
>> wiki: http://wiki.sugarlabs.org/go/Activities/Toaster
>
> ... a particular place yet for the existing cdwrite.sh and whatever it
> may evolve to become?
These wiki pages have not been updated for the change in direction yet.
> Anyway, for starters, some questions, etc. that come up:
>
> Copyright/ownership/license - shouldn't this go under some highly
> standard Open Source license, and be assigned to OLPC or other suitable
> entity?
The git code already uses GPLv3 to be compatible with other OLPC XO
activities. In the current version Robert has made some changes. In an
older version on my disk it says:
# Version 0.5
# - Argument checking
# - Added improvements from Grant Bowman
# - Header standardization; added MIT license text
I'll talk to Robert ASAP. He and I co-founded http://www.dvlug.org
with some others. I don't know if he is able to attend this evening in
Walnut Creek as he has been busy with school.
> Interpreter - wouldn't it be best to use /bin/sh, and stick with
> POSIX/SUS as feasible, lest it break the instant bash changes some
> bashism?
The interpreter on the OLPC has been the Fedora standard in Fedora
9-14. I don't know if it has changed between builds. What is specified
in the file might link to bash already. I don't know how many bashisms
are in the current code right now.
> Shouldn't the name of the file just be cdwrite or something like that,
> without ".sh" extension - that way if/when it's rewritten or replaced
> with a binary or script in some other language or whatever, the name of
> the executable can remain the same?
Sure. In our case I think toaster would be a good name. Again, we are
caught in the transition of this project.
> What exactly is the intention of:
> [ $1 -ne $1 ]
> ... to ensure both self-same arguments are numeric (and match)?
Seems like it.
> Are targets to be, or at least potentially be more generic than CD,
> e.g. other optical (DVD-R[W]), USB, other types of removable memory,
> etc.? Perhaps then also some name other than "cdwrite" for the program?
Yes. We have two cases to cover. a) iso image to a USB cdrw device and
b) iso image to a bootable USB stick. The location of the iso images
may vary but as we are now doing a script it would make sense to me to
pass it on the command line. If we could auto-detect for example the
`pwd` and give a menu that would be a future enhancement to make it
easier for kids to use.
> stat(1) is quite standard on most Linux distributions, is it present by
> default for these XOs? (can work around that if it's not).
Good question, we will have to verify.
> perl(1) is quite standard on most Linux distributions, is it present by
> default for these XOs? (perl(1) is also relatively large, so it may be
> intentionally omitted - and it may be desirable to keep it off). What
> about same question for Python?
Python is very much a part of the OLPC as sugar is written i python. I
don't know about python versions as they have changed from build to
build or perl.
> checksums - might it be infeasible to fetch these from Internet (may be
> used in offline scenarios)?
>
> If/when we do/can check such checksums, shouldn't we also check
> cryptographic signatures?
I've personally had troubles with checksums of burned disks. I usually
manually verify .iso checksums. As we are not specifying exactly what
the source of the ,iso images are to be burned and as the tool may be
used with many different ones I do not know how to automate this in a
way that is also "user friendly" for the toaster target audience. I
think a FAR more important first step is to get something working
without trying to automate looking over the user's shoulder.
> As bandwidth may be spotty/limited and/or unavailable, should we
> effectively cache some checksum/signature data (so we can avoid
> unnecessary/unavailable fetches, especially if we already got it before
> not too horribly long ago)?
For our project we MUST assume that no network is available at all.
> various observations:
> eject -t will only close the tray for some types of drives
True. In a custom version of cdwrite.sh that I use locally I comment
out some of that logic.
> sleep 10 # wait for spin up
> ... better to do some loop that checks with 1 sec. sleep and max of say
> 10 seconds, so program can proceed once media is confirmed available,
> trimming excess wait to about a second or less?
In my customized local version I modify that number with a safe value
depending on what burner I am using at the time. For our project I
think a higher default value with a customization config file or
parameter might be better.
> optical burn speed - even 8 is too high for some media types (e.g. some
> have max of 4x). Should we read info. from drive and/or media to
> determine speed? Or is our burning program "smart enough" to figure out
> an optimal max speed?
Do you know how to do that? One thing we need to be prepared for after
our initial release is support of the users. I think from field trials
we will quickly learn about the types of drives being used. Putting in
some logging / debugging code that could be easily mailed to us might
help us troubleshoot reported problems too.
> What about +-RW media - should we detect and at least minimally blank it
> first if needed (e.g. if it already contains other data). If it's
> already got data, should we check if it might happen to already have
> what we want to burn, or ask the user, or ???
If they are using +-RW they can blank it themselves for now. Maybe in
the future we can add this but the amount of work and testing required
might be significant compared to the initial project scope.
> We've got what we're copying - should we do a byte-by-byte read
> comparison to validate? For all media types, or just optical targets?
> What about floppy (if that might get used at all)?
Edge cases can be in later versions. We need to get something minimal
and simple working with a good UI for our target audience, OLPC
laptops in the field with whatever cd burners and/or USB sticks they
have. We have not done any research yet to understand the needs of
people in the field other than opinions from the olpcsf.org meetings
and the lightning talk I gave during the olpcsf.org conference in Oct,
2010.
> Should have better checking / error handling if the burn/copy fails (but
> looks like that's already know todo item)
Yes, we were working on stdout and stderr parsing code with wodim in
python for the activity and made some progress though if we do a shell
script the handling is different now.
> beep - I'd think some suitable echo (e.g. echo -en '\007') ought to
> work, but some more testing/investigation may be appropriate there.
> Just a single beep, or do we want to be a bit more persistent - but not
> too annoying?
We can try a few options like that once everything else is functional
and the UI is acceptable to at least our own uses of the software.
> USB memory stick or the like will require different handling than eject
> or the like.
Yes, true. cdwrite.sh is written for the relatively stable use case of
CDs. Toaster is a much more ambitious effort.
Grant Bowman
On Fri, Aug 19, 2011 at 1:03 PM, Robert Wall <rob...@rww.name> wrote:
> Hi Grant,
>
> First off, I'll be at DVLUG tonight, so we can go over this there if the
> following doesn't answer your questions. I find Google Groups tiresome,
> so I'll skip actually joining that group, but I did take a look at the
> web archive. I guess you're talking about the "Toaster: cdwrite.sh"
> thread?
>
> cdwrite.sh is licensed under MIT (aka Expat), so you're all welcome to
> use it in a GPL3 project. The copy on my website is staying MIT
> licensed, though. If you have improvements that you don't mind
> relicensing from GPL3 to MIT, I'll be happy to take them, but that's
> entirely optional. My rationale for staying with MIT for my copy is that
> I don't think GPL3 is appropriate for small scripts (FSF's GPL FAQ
> recommends using a "simple all-permissive" license for works about the
> same size or smaller than the GPL license itself due to the size of GPL,
> in fact.). I'm happy that cdwrite.sh is useful in a larger project,
> though, and understand fully that you need the protection that GPL3
> offers for Toaster.
>
> I don't do copyright assignment as a general rule, but I doubt there's
> anything you'd want to do with assigned copyright that can't be done
> with MIT. If there is, let me know and I'll look into options.
>
> I notice that you're using git for source control on Toaster. I'm not
> that familiar with version control systems other than bzr, but if it
> would help your efforts, I can throw cdwrite.sh into github or
> something.
>
> I'll take a look at Toaster and see if I can help out once I get settle
> in at college. In the meantime, I might mention it in an upcoming blog
> post on my website (in the context of "something I did is useful to
> someone! cool!"). Thanks for poking me about it again :)
>
> Robert
>
> PS: feel free to copy or quote this email on the Toaster list if it
> helps the discussion.
>
Grant Bowman
I've got an XO setup here in Nairobi, Kenya and making some CDs with
cdwrite.sh now. I hope we can provide some safety features for those
less interested in editing shell scripts to change the variables like
I am doing.
Grant