Create my own linux ISO

Brian Hawkins brianhks at activeclickweb.com
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.

Brian

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 yahoo.com> 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 activeclickweb.com>
>> To: Provo Linux Users Group Mailing List <plug at plug.org>
>> 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: http://plug.org, #utah on irc.freenode.net
>> > Unsubscribe: http://plug.org/mailman/options/plug
>> > Don't fear the penguin.
>> > */
>> >
>> >
>>
>>
>> /*
>> PLUG: http://plug.org, #utah on irc.freenode.net
>> Unsubscribe: http://plug.org/mailman/options/plug
>> Don't fear the penguin.
>> */
>>
>>
>>
>> /*
>> PLUG: http://plug.org, #utah on irc.freenode.net
>> Unsubscribe: http://plug.org/mailman/options/plug
>> Don't fear the penguin.
>> */
>>
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> 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 : http://plug.org/pipermail/plug/attachments/20070308/916e25f6/attachment.bin 


More information about the PLUG mailing list