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?)"
That's not much use for testing compiling on Solaris on SPARC64, or Tru64 on Alpha, etc...
The only problem is that the people compiling aren't the same as the people who are buying.
Not Meta-modding due to apathy.
Personally, I see less and less need for compiled and distributed software as broadband internet becomes ubiquitous and rich internet applications become more sophisticated. As it stands now, there is very little that traditional software does that can't be replicated on the web using the right technology. Software as a service is slowly becoming a reality and compiled software is soon to go the way of the dinosaurs.
Anthony Papillion
Advanced Data Concepts, Inc.
"Quality Custom Software and IT Services"
It was announced afterwards for a reason. They're not really taking it down because nobody wants it or anything, it's because they lack manpower to keep it working. It basically needs a lot of work to get it back in a usable state, and it's not widely used, so they're just dropping it.
This is the classic downside of "software as a service".
Not to be a jerk, but even if the future of computing is "write once, run anywhere," doesn't it still stand to reason that the code should be tested to make sure it can indeed run anywhere? I tend to agree that languages like Java which abstract away much of the OS and hardware specifics will become suitable for more and more tasks as system performance increases, but 1)There will always be applications in which hardware and/or OS-specific optimization will be necessary, and 2) Even without considering this, only a fool would trust such abstraction layers (i.e. the JVM) implicitly, claiming multiplatform support without ever having testes on the platforms in question.
You seem to have mixed up "users" and "developers." For most people, anything that involves a command line IS rocket science. When a techie comes along and ports something and makes it available, it can be a huge gift to the normal users. When everyone figures it is too easy and not worth doing it for the newbies, you end up in a situation where an essential program like GimpShop for Windows ends up with the Linux version lagging far behind the latest release of Gimp, and the Windows version being even more lagged behind Linux GimpShop.
True, but remember that the more software that eventually runs on your platform, the more people who are likely to adopt it.
It's expensive: power, cooling, rent on the building with the rackspace, and bandwidth all add up to a considerable chunk of change. And the professional skills to run such a farm are unusual and expensive to hire, or to contribute. Even a modest Q/A testing and evaluation farm can cost a few hundred thousand dollars a year when you add up all the costs.
I don't know if it would be suitable for the sort of thing you're talking about, but HP has (or atleast they had it a year or so ago), a thing where you can telnet into a variety of different systems they had. Mostly OpenVMS and HP-UX running a a few different architectures. I know that you didn't have network access from the box that you telnetted into, but I don't know what other restrictions there were. It might be something to check out if you're interested in making software for some of HP's higher-end stuff, but don't have the hardware to run OpenVMS or HP-UX.
Every time you post an article on Slashdot, I kill a server. Think of the servers!
And even if you don't see a problem with it, what about those OS devs who do actually kind of like the idea of testing on a variety of hardware? There aren't many hobbyists who can afford to buy servers from HP and IBM.
For most open source software you're completely correct - it'll never run on anything more exotic than a Core Duo. But if you're developing something other than desktop applications (e.g. programming languages, libraries, frameworks, etc) and you want your software to be used by the widest possible audience; you need to test it on as many architectures and operating systems as possible.
As a consequence, I expect many projects dropping support for some of the platforms they can't get access to.
Do we have any actual data on how popular the service was? I think this was a neat idea, but if it wasn't being used it won't be missed...
-= This is a self-referential sig =-
I believe he meant this kind of power.
I've heard this argument before. From a vendor's point of view, it is so divorced from reality as to be laughable. Let's face it, if you, as a developer, have enough pull to direct a couple million US dollars toward a hardware contract (or even a few hundred thousand), you probably aren't sucking around for free equipment and resources. If you don't have the ability to throw that much cash at a vendor, there isn't a lot of incentive to talk, is there? Workstation/server vendors have different cost structures and markets than PC vendors.
Using the compile farm to do regular automatic compiles of the latest code (if there are any changes) was one of the most usefull features of SF. *sigh*