[Novalug] basic Q's about flash boot of live CD

Bryan J. Smith b.j.smith@ieee.org
Wed Mar 24 00:22:31 EDT 2010


Allow me to step back ...


First off, "the big deal" is because of first-hand experience.  Since I
"have a red Fedora," people love to bark at me.  I've had _so_many_
people complain they can't update Fedora 9, 10, 11, etc... on their USB
stick.  I quick discover they are running "yum update" on the stick itself.

That's when I point them at the builder tool.  Most work with that and,
no, most users have _no_problem_ using it.  If they can put the image
on the USB stick in the first place, they have _no_problem_ using the
tool to build a new squashfs.  It easy enough.

That's why I'm adamant about telling users to rebuild the image instead
of just downloading the "release" version of the Live CD and turning it
into a USB device and running "yum update" on it (and getting all those
updates).  Teach them "The Right Way(TM)."  I would _never_ proliferate
them to use "yum update" on the media live.  Again, that's what really
got me going.  ;)

Secondly, every time I build a read-only image, I clean out a lot of things
that aren't needed.  There is so much under /usr/share/ that is not, let
alone even the RPM database will let you reclaim 10s of MiBs.  I've fit
both RHEL 5 and Fedora 9-10 in as little as 128MiB of NAND EEPROM,
with accessibility support.  At first I got it down to 192MiB, but eventually
128MiB.  Maybe that's no longer a bit deal now that NAND EEPROM has
over quadrupled in capacity in just the last 18 or so months.  But it can
mean a drastically reduced firmware update cycle and network traffic
for embedded devices.  ;)

Third, as far as Gecko files, I pre-setup Gecko to use a fixed profile
location, and the ./cache/ directory points to tmpfs.  I have been doing
this for years.  Creating mandatory and default Firefox profiles is none-
too-difficult.  It's one of the reasons I've been meaning to look at what
the Live tools create, and add this if it doesn't already.

Maybe it just defaults to no disk cache, which would also work.

Lastly, I think we agree that a few packages would be just fine.  But
I will re-iterate that if it's more than a few, one should be rebuilding
the image.  And, again, if an user can figure out how to put it to the
USB device, then they don't have a problem using the tool.  I didn't
understand that argument one bit.

This goes back to the first part, where people assume the Live USB is
just "like a hard drive."  It's not.  It shouldn't be either, at least not with
today's NAND EEPROM lifespan (which is absolutely atrocious and still
results in NAND EEPROM device failure rates in excess of 2.5" disk
failure rates, sadly enough).  Using NAND EEPROM as read-only as
possible, not doing heavy read-write changes like mass binary swap
outs with YUM-RPM operations, is what NAND EEPROM is ideal for.

Again, I wouldn't be taking issue if I didn't feel this point wasn't being
discarded so quickly.  ;)




----- Original Message ----
From: Peter Larsen <plarsen@famlarsen.homelinux.com>

No problems. I'm still a bit confused on why this turned out to be a big
discussion ;)
...
I'm not sure I follow you here. I don't see it's much different from
most other operations that need temporary/cache files. I would dare say,
that most users wouldn't know how to create an updated master USB image.
This provides an easy and fast way to keep your USB stick updated and
gives you the ability to add new features fast without having to treat
the system any different than installed.
...
MBs of data is what you donwload with almost any standard browser
session. It also writes that to disk. And unlike browsing, yum is done
once or twice. Browsing is done over and over again. It would seem to be
more harmful than yum?
...
I would agree that eventually you would need an updated image. But
simply to update your installation or add a software package or two, I
don't see a problem. 



More information about the Novalug mailing list