Slashdot Mirror
Alternatives To SF.net's CompileFarm?
cronie writes "Not long ago, SourceForge.net announced the shutdown of the Compile Farm — a collection of computers running a wide variety of OSes, available for compiling and testing open source projects. SF.net stated their resources 'are best used at this time in improving other parts' of the service. I consider this sad news for the OSS community, because portability is one of the strengths of OSS, and not many of us have access to such a variety of platforms to compile and test our software on. As a consequence, I expect many projects dropping support for some of the platforms they can't get access to. Are there any sound alternatives with at least some popular OS/hardware combinations? Any plans to create one? (Perhaps Google or IBM might come up with something?)"
Naaahhhhh. Nice thought, but no computational utopia yet.
How about vendors supply compile farm gateways linked from SF.NET for use by SF members. Great way for hardware vendors to show off their new stuff to folks that might be inclined to buy or have influence in the purchase decision.
Kinda like a hands-on remote(?!) demo.
SciTechPulse. Geek News Netcast. Hot Polynesian Geek Chick Host Silulu.
I think thats kind of the point. Its more like write once, debug everywhere.
Hardly. The future is and has long been one of "write once, test anywhere". And that's the need the compile farm filled. Writing once and expecting it to automatically run everywhere without modifications is a pipe dream.
I use VMWare Workstation and Virtual PC to do testing and whatnot, negating the need for multiple systems in my home office. I have, for example, Windows XP Pro, Windows 2000 Pro, OpenBSD, FreeBSD 5.5 and FreeBSD 6.2 all set up as seperate virtual systems on a single computer.
Who needs a compile farm when most of what we need can be run from a single moderately decent workstation?
Feed the need: Digitaladdiction.net
Posted By: wdavison
Date: 2007-02-16 00:13
Summary: Compile Farm News
As of 2007-02-08, SourceForge.net Compile Farm service has been officially discontinued.
Shutdown on Feb. 8, announcement on Feb. 16th?
With behavior like that, SourceForge can't be considered a safe location for important code. I'd suggest that it's time to get projects off SourceForge. Make offsite backups of anything important now.
Latest announcement from VA Software, which owns SourceForge:
VA Software Corp., whose software and online media are targeted for the open-source software community, said Thursday it named Scott E. Howe to its board of directors.
Howe is president of a division of digital marketing company aQuantive Inc.
"Scott's extensive knowledge of the media markets will be invaluable as we continue to focus on our core media assets and strive to secure alliances in the global competitive landscape," VA Software President and Chief Executive Ali Jenab said in a statement.
VA Software slipped a penny to close at $4.24 on the Nasdaq Stock Market.
If VA Software thinks they're now a "media company", it's time to get off SourceForge.
That's not much use for testing compiling on Solaris on SPARC64, or Tru64 on Alpha, etc...
VA Software owns Slashdot:
http://www.ostg.com/about/index.htm:
Ergo, VA Software is a media company.
Time to get off Slashdot.
Yes, because all those rich web applications will run on... rich web applications?
--S
-- sigs cause cancer.
Can we start a community driven project similar to Compile Farm where people with systems contribute their system time in an anonymous fashion. Something like a p2p compilation.
Get your software packaged by Debian (which you probably want to do anyway), and it will get built on (currently) 15 architectures of GNU/Linux, along with 3 non-Linux architectures (kfreebsd-i386, kfreebsd-amd64, hurd-i386), with more popping up occasionally.
It's rarely about getting stuff going on a platform, but rather making sure nothing regresses. Compile farms are useful for doing the following:
- compiling the software on all platforms
- running automated test suite
- automatically building packages periodically
- determining what percentage of the code your test suite covers
- verifying the built package works
Patches from users cant reproduce all of these things, and this is where compile farms come in handy. Whether it makes sense for something like sourceforge is another matter.
http://www.testdrive.hp.com/
HP dude Bdale Garbee has said HP is delighted if people use testdrive to test their code on different architecture and OS combinations.
- The application provider's OS
- The application provider's network services
- The application
- The client's OS
- The client's network client
And this is supposed to be a less complicated system to write, distribute, and debug than traditional systems that you can do away with traditional compile-farms? Software is a service, no need to install anything. Unless, of course, you want to print something. Or is that a service too? Burning a DVD is a service? Put your DVD-R in the drive, connect to your favourite DVD authoring service, and... go to sleep. Maybe tomorrow your disc will be done. Unless DVD or HD-DVD quality video is something you expect to get solely off broadband.There are so many exceptions to what software-as-a-service can reasonably do that the majority of people who are reading this do on a daily basis that I just have to laugh when people bring this up. Beyond a wet dream for Microsoft where they lovingly sit back and watch the monthly subscription dollars roll in, this is never going to happen.
I can donate hardware and sysadmin man-hours, but I need either space, electricity, and bandwidth or money (which can obviously get me space, power, and bandwidth). I have lots of platforms just sitting in storage, and I plan to ebay most of it unless someone can get help for an interesting and useful project like this. The architectures I can provide are as follows:
4x Sgi o2 (MIPS both R10k and r5k) currently running IRIX, but I could install Linux, NetBSD or OpenBSD
Compaq with Xeons (eight way SMP 4GB RAM) Debian or FreeBSD
Sun (four way SPARC64 SMP 2GB RAM) running Solaris, but I could install Linux
Sgi octane2 (MIPS R14k 1GB RAM) IRIX
HP visualize J6700 (dual SMP PA-RISC64 4GB RAM) running Debian, could install HP-UX
HP precision book (PA-RISC32) running HP-UX, could install Linux or OpenBSD
Sun (SPARC64) running OpenBSD, could install Linux or Solaris
Plenty of boring x86 machines, some older PA-RISC32 junk, and probably other RISC boxen that I forgot about....
Send an email to
unixclan
REMOVE THIS IF YOU ARE NOT A BOT
@
gmail.com
If you think you can help me host an alternative compile farm.
------ Take away the right to say fuck and you take away the right to say fuck the government.
The openSUSE Build Service: http://opensuse.org/Build_Service (supporting Mandriva, Debian, openSUSE, SLED, SLES, Ubuntu, Fedora...).
sourceforge has been having increasing numbers of problems recently. Their shell service for instance was down for weeks not too long back. That's happened many times over the last few years, and it's been a source of real problems, since its the only way to get access to update projects.
Their entire service was off-line for a while last week, not fun.
I've moved my project to google code project hosting. Their service is simpler, but reliable. The addition of a wiki is really helpful, and uploading new releases is trivially easy.
google could offer a compile farm with ease. I expect it won't be long now that sourceforge have removed theirs.
When I first started using sourceforge four years ago I liked the service, but when they moved to having paying customers, everything started to decline for the free hosted projects. They said it wouldn't but it still occurred.
I'm of the opinion that sourceforge got too complex, and now they can't manage all the aspects they wanted to include. No doubt if everyone paid it would be easier, but not many open source developers have free funds for such things. If people had to pay then small incomplete projects might not even get off the ground. Mine certainly wouldn't have, since I was a student, and financially limited.