Re: New CD image creation tool
On Tue, Dec 19, 2000 at 03:36:52PM +0100, J.A. Bezemer wrote:
[image template]
> > Yes, I also considered making it human-readable somehow - but with all
> > the literal data, it would look extremely messy even if you uu-encoded
> > that. In fact, that's what in the end led me to split up the
> > information into two parts; one binary part and one readable part
> > containing the info on where to get the packages. (At first, I wanted
> > to put everything into one file.)
>
> Okay. But then I'd suggest cutting it a little more to the left (or
> whatever side ;-), namely that only the literal binary data is in
> one file, and the "CD creating recipe" along with all other
> human-readable data in another file (or maybe even two/three files).
> Besides readability it would also allow "cooking" the CD image with
> a shell script (parsing with "read", creating with "cat >> .iso" and
> "tail -c +N | head -c M >> .iso"; okay, crude and inefficient, but
> should work).
Hm, why would you want to use a shell script when I'm planning to
write a full-blown program to do it? It would have the advantage that
one can use it while the "proper" thing is not yet ready, but beyond
that...?
> > I don't like it, either - hmm... maybe "image template" sounds better?
> > While we're at it, I'll call the human-readable file "location list"
> > from now on, until someone comes up with something better. ;)
>
> How about the concept of "cooking" a CD image? We have "special
> ingredients" (i.e. the literal binary data), a "recipe" (image
> template) and a "grocery list" of places (i.e. FTP/HTTP sites) where
> to get the "standard ingredients". Should be understandable even to
> people who didn't ever touch a computer before ;-)
LOL. "Baked Potato 2.2 rev35", eh? :-)
[to check or not to check for .deb presence before d/l]
> I agree that checking would be an advantage, but it should not cost
> too much. ls-lR.gz is quite big (1.3M on
> http://ftp.us.debian.org/debian/) (and some mirrors have US and
> non-US combined in one ls-lR, others don't); scanning directories
> doesn't work with HTTP servers and with FTP (using package pools) it
> will transfer about the same size as the UNzipped ls-lR (~10M).
> Checking every single file is only easy with HTTP and will still
> cost ~500 bytes(?) * 2000 files/CD = ~1MB per CD.
>
> Furthermore, when using pools checking is not a really big issue
> since everything should (at least _can_) still be available. Don't
> concentrate on it now, you can very well add this "new feature!"
> later (and I guess making it optional and "off-by-default" would be
> best for most users).
OK - right now I can't see a good, efficient solution for checking
whether the packages are there, either. :-/
> > > > 1) Should run on as many platforms as possible
> > > > 2) Should support both GUI facilities and command-line-only operation
> > > > 3) Should provide libraries for socket programming
> > > > 4) Should not require the user to install additional software to run
> [Java is also not "The Perfect Solution For Everything"(tm) ;-]
I've also gotten off it a bit, and have been investigating further
alternatives: It seems both GTK+ and a library providing BSD-style
socket operations are available for Windows, so I could use C++. That
would also have the advantage that I can re-use some code from rsync
and maybe wget.
(For other archs, where no GTK+ is available, there'll be a
command-line mode. In any case, don't expect the GUI version anytime
soon.)
> Don't worry about the clients too much at this point. Just like the
> Pseudo-Image Kit, the file formats are ("should be") easy to
> interpret/use in any language. Start with a simple implementation in
> whatever language you like best and write fastest ;-)
I used to think like that, but in my experience, this "code first,
think later" attitude will result in big problems later on. It really
helps to sit on your twitching fingers for a while and consider your
options. :)
> The main problem at this point is the "recipe generator"; you should
> probably start working on that first.
Just my thoughts!
All the best,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://atterer.net
¯ ´` ¯
If they give you ruled paper, write the other way -- Juan Ramón Jiménez
Reply to: