Create my own linux ISO

Brian Hawkins brianhks at
Thu Mar 8 17:01:56 MST 2007

It's even better then that.  When I release MyLinux 1.1 I do it as a 
full bittorrent image.  You can download it all by itself.  If however 
you have already downloaded MyLinux 1.0 the client can utilize a little 
extra info that is placed in the .torrent file to find matching blocks 
in 1.0 and apply them to the 1.1 image.  It is really quite cool.


Steve wrote:
> Ok let me see if I got this straight.
> You have MyLinux 1.0 you release as a torrent.  Next you want to
> release MyLinux 1.1 also as a torrent.
> What you are trying to do is to have the MyLinux 1.1 torrent released
> not as a single large iso, but as a patch delta against MyLinux 1.0
> with only the differing files coming down the pike?
> If thats the case, I wouldn't mess with bittorrent at all.  You would
> be much better using SVN or RSYNC.  Another alternative especially if
> your choosing to use bit-torrent as a method of saving your server
> from melting down on release day, would be to use AWS (Amazon
> WebServices).
> The final option I could see, if you really have your heart set on
> Bit-Torrent is to release each .rpm .deb or whatever as a seperate
> torrent and then create a master list (either a large file or a single
> tracking server) of some sort which points to each individual packages
> torrent.
> In this way you could do a bit-torrent update system, and never bother
> with a point release at all.  And of course making a release would be
> as simple as changing the repo master list as new packages are
> commited.
> On 3/8/07, Michael Brailsford <brailsmt at> wrote:
>> For testing during development, you don't need to do what you want.  
>> Certainly, for testing before you are done and before you turn it in, 
>> test it with a lot of real world stuff.  For that you can get 
>> creative, like use current and previous versions of any distro you 
>> want, diff them independently of your torernt-doohickey, transport 
>> then files with your doohickey and then independently verify that the 
>> diff on the receiving end is identical to the diff on the sending 
>> end.  But for development, you should probably consider that you want 
>> a small package to test with so you can reduce your edit-compile-test 
>> cycle.  A diff is a diff is a diff.  It doesn't matter if you are 
>> diffing a 700MB linux distro, or a 1MB tarball.  Get the algorithm 
>> right, and size becomes a matter of scaling, not a hindrance to your 
>> development.  The point afterall is to create differential torrents, 
>> not to create linux isos.
>> You should maximize your test set for ease of development without 
>> compromising the validity of the tests.  When you are done with 
>> development, go nuts on testing it with all sorts of stuff.  After 
>> all, almost every other engineering discipline in the world starts 
>> with small models of the real thing for testing, before moving on to 
>> the real thing.  It only makes sense to apply the same rules to 
>> software engineering.
>> But hey, do what you want.
>> -Michael
>> ----- Original Message ----
>> From: Brian Hawkins <brianhks at>
>> To: Provo Linux Users Group Mailing List <plug at>
>> Sent: Thursday, March 8, 2007 2:24:54 PM
>> Subject: Re: Create my own linux ISO
>> Yes that and I want a real life data set.  I'm trying for something that
>> is commonly downloaded using bittorrent.  Linux ISO images are what came
>> to mind first.  I think I can get done what I need by tearing apart an
>> image and them putting it back together with different compression
>> techniques.
>> Thanks
>> Brian
>> Nicholas Leippe wrote:
>> > On Thursday 08 March 2007 12:16, Michael Brailsford wrote:
>> >
>> >> Why not do something like create a directory called /tmp/test_data 
>> and copy
>> >> in a few header files or other text files, maybe copy in the whole
>> >> /usr/include directory to get a bigger size.  Then you can do:
>> >>
>> >> $ tar czf /tmp/test.iso /tmp/test_data/*
>> >>
>> >> Then you can just make an edit in a file in /tmp/test_data and 
>> recreate
>> >> your "iso", then transfer it and compare what you get on the other 
>> end with
>> >> what you sent.
>> >>
>> >> A whole linux distro iso, while nifty, is significant overkill.
>> >>
>> >
>> > It may be overkill for verifying the correctness of his 
>> implementation, but I
>> > think he wants a bit larger data set for better performance metrics.
>> >
>> >
>> > /*
>> > PLUG:, #utah on
>> > Unsubscribe:
>> > Don't fear the penguin.
>> > */
>> >
>> >
>> /*
>> PLUG:, #utah on
>> Unsubscribe:
>> Don't fear the penguin.
>> */
>> /*
>> PLUG:, #utah on
>> Unsubscribe:
>> Don't fear the penguin.
>> */
> /*
> PLUG:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3347 bytes
Desc: S/MIME Cryptographic Signature
Url : 

More information about the PLUG mailing list