On Sun, Jun 8, 2014 at 9:54 PM, Ryan Schmidt wrote: > I have old PowerPC machines that I use for this purpose. The problem is not > hardware; additional PowerPC machines can be acquired if they are useful to > anyone. The problem is getting developers (both upstream and within MacPorts) > to fix problems on these old systems.
But at the moment even those developers who would be willing to fix the problems don't have a chance to debug anything (if they aren't willing to spend money buying old hardware which isn't useful to them for anything else; or as two users pointed out already: they simply lack space to have another box running on the desk). (I'm certainly not interested in using Sparc Solaris, even less so in buying one and maintaining the software up-to-date. But by getting access to a solaris build farm, I was able to report and fix a number of issues in different pieces of software.) > I may be able to provide access to such systems, if that would be useful; my > concern would just be with security. The first probably insecure idea is to > give interested developers ssh accounts with sudoer permission to run the > port command. Alternately, giving each user a restricted account and a > private copy of MacPorts would be more secure, but take more disk space, > though that's probably acceptable. Yes, giving every user sudo permissions would be a bit weird. I'm not sure if another option would be (1) doable and (2) acceptable: not to give anyone sudo permissions, but to provide some way of interface to allow users to install and uninstall ports globally from the latest/official SVN only. This couldn't work if there were lots of users (constantly trying to install and uninstall the same or conflicting ports), but with a modest number of users it might work. Or maybe try to build a list of non-conflicting packages that users/developers need and keep them up to date with a cron job. Plus of course give users sufficient space to allow a personal installation of MacPorts in their home folder. With a global installation containing all dependencies developers could still debug most problems with just "port build <my new package>" using dependencies from the global installation and doing the build inside $HOME/.macports. But I'm just brainstorming. In any case maintaining such a machine would certainly need at least a bit of work for the admin. > Daniel is correct that we should be encouraging users to upgrade to OS X > versions that receive security updates from Apple. However, some old machines > (e.g. PowerPC) machines cannot run newer versions. When the alternative is to > throw out an otherwise working computer, I would rather that old computer > continue to be usefully employed than taking up space in a landfill. > > Giving developers having older Macs access to newer systems is a less > pressing need, in my opinion. I agree. (The main advantage could be to let developers work on a faster machine for demanding builds: my core 2 duo laptop from 2009 needed 4 hours to do the same build that a four core iMac from 2011 finished in 40 minutes.) But yes, the problem will sooner or later fix itself. (I was advised to try ccache.) On Mon, Jun 9, 2014 at 9:30 AM, Daniel J. Luke wrote: > I would recommend that people who intend to make use of older hardware should > do so with OSes that continue to get security updates But then again, given the low number of such users it's probably a lot more profitable to write malware for XP than it is for Leopard. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
