If distcc was included on the LiveCD, people could use it to make compile- drones out of etc. windows boxes thats doesn't do anything right now, without touching the data on the computer, so it could just be rebooted afterwards, and run as normal. Reproducible: Always Steps to Reproduce: 1. Add distcc to LiveCD 2. Release ISO of new LiveCD 3. Make me happy :) Actual Results: I would be able to use several windowsboxes as compile-drones :) Expected Results: Same as above :)
this is on the todo list, its a little more complicated then just adding distcc to the cd though. I think it will be a nice feature when implented.
how much longer do we have to wait?
feature request
great, thanxs in advance
How hard would this be to add to the specs?
distcc might have to write to a fs, and in that case, it would take more hacking than just adding it to the spec file. I will research it though.
distcc works great on the livecd (all my experimentals had it) one livecd had a 60day uptime for it. Main problem is keeping livecds version of gcc up to date with portage. This adds around 20meg to the livecd size if i remember.
woot... this bug is already here... So... if the problem is keeping gcc up with what's in portage, whynot provide a binary distcc package that can be installed immediatly on use of the livecd... so it would go like: boot from livecd partition drives grab distcc binary ebuild, install it somehow start ltsp, network boot the whole computer lab... and go go go!
Possible, but rather complicated.
In my opinion, it is a BAD idea to provide distcc on the regular LiveCD and here's my reasons why: 1. As LiveWire said, keeping versions up-to-date with portage is hard, epsecially since we have a set release cycle for the LiveCD 2. It adds about 20-30MB of space to the LiveCD, since we have to keep gcc around 3. It adds a daemon on the regular LiveCD which could possibly be exploited I see nothing wrong with providing distcc on one of the larger CDs, but as it is, we have quite large LiveCDs already. Adding 20-30MB to the "minimal" CD would be a waste of bandwidth/user's time, since it would be unused by most.
I guess we have to look at possible benefits from gaining distcc, then compare them to the costs: 1. How much time can distcc save anyone (how long does the stage that it would be used at take with, and without distcc, and one, or two computers) ----- What are the costs: an extra 20mb!!! just for distcc?? gcc is already included.. i can't immagine it takeing 20mb! ... 20mb = 5 minutes to lots of people... and just tons of people who don't have two computers... and if it takes 2 hours to boot strap... it's not worth downloading distcc. ----- other secondary benefits: ability to plop a livecd in the drive, and have it just boot, and run a simple command, and have it be a distcc client. (why not just netboot?--> people don't have control over the networks they use!, or they'd disrupt dns/netbooting/dhcp for other computers on the net) extended utility for the livecd after the initial install... ------------- fact finding: 1. The livecd is normally only used for boot strapping. this isn't a large portion of the install.. and then we want to use the new gcc and system tools to build the rest of the system... ----------- >1. As LiveWire said, keeping versions up-to-date with portage is hard, epsecially since we have a set release cycle for the LiveCD if there was a simple (run one command and enter an ip) way to use the newly compiled gcc from the system, and clone it to other computers, via netbooting, then use that... we might even be able to copy gcc without using the binary pacakges? >2. It adds about 20-30MB of space to the LiveCD, since we have to keep gcc around don't you already have gcc on the liveCD? oh, see above, just grab it from the system you're using as the hub. >3. It adds a daemon on the regular LiveCD which could possibly be exploited it should be off by default, and... hopefully people use distcc on their LANs in a way that isn't forwarded by their router...
it really depends on how nicely squashfs decides to play. distcc adds the extra 20-30MB because GCC is not included by default on the livecds. I will add distcc if the following are met: 1. squashfs is proved to be stable 2. it is not enabled by default (which it would not be by default) 3. we can keep the versions sane If one of those cannot be met, then we will not include it.
I think the impossible part would be to keep the versions sane. I would much rather see a separate *tiny* distcc-enabled release. We could either add it to our regular mirrors, or distribute it via BitTorrent. The reasoning behind this is that the distcc LiveCD, which would still be usable to install from, would be released with each version of GCC in portage. I tend to think that distcc on the LiveCD, which would only be useful for bootstrap during install, or for turning non-Linux machines into distcc clones, would be too hard to keep working between releases with portage. The number of bug reports would be too great. Having a separate distcc CD would solve this. The main reason I am saying I would definitely NOT like to see distcc on the LiveCD is the sheer number of bug reports I am seeing in bugs.gentoo.org involving programs and GCC 3.4, which is apparently not 100% compatable with GCC 3.3.x, so I can already see problems with 2004.2 and supplying distcc. Would we use GCC 3.3.x? GCC 3.4? If we chose one, we would get requests/bugs for the other. It just ends up as a non-ending cycle of not pleasing the users. It would be fairly simply, however, to release TWO distcc LiveCD's, one for GCC 3.3.x and one for GCC 3.4, that aren't part of the normal release cycle.
can we change this to: create a distcc package that can easilly be downloaded/plugged into a livecd... Oooh.. modules for live cd's It would be super nice to be able to burn a livecd, and then be able to add modules to it... I think it's possible to have a bootable multi-session disk..
My idea would be much simpler (on us) and that is to simply have a distcc CD (otherwise identical to a minimal CD) that we release via the new official Gentoo BitTorrent Tracker which we have been working on and we keep updated as new versions of GCC arrive. This would keep the amount of work to a minimum for the people doing the CD builds (re-snapshot and rebuild... 3 commands total...) to keep them up-to-date and it wouldn't take up more space on the mirrors.
i am going to close this and defer it to a later release. we need to get some other things up and working (BT, etc) before we can even consider adding this to our ever increasing list of TODOs.
