I install Boinc on my new PC running pure 64 bits from Linux-Debian. When I try to get knew task I get the following message, and no new task:
Tue 13 Jun 2006 06:18:10 PM CEST|rosetta@home|Message from server: platform 'x86_64-pc-linux-gnu' not found
What can I do about it?
thierry

---

We don't have a 64-bit version of the client as of yet. Sorry.... -KEL

---

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=1216

---

LUE

As stated above, there's no 64-bit version of Rosetta. There's been discussions on the regular (non-Q&A) forum about why this is, and the conclusion from me and others that looked at it is that there's very little likelyhood that the performance would be noticably better [there are plenty of applications where they are faster, and some that are slower, rosetta would fall in the "doesn't make any difference" category, from reverse-engineering studies - without access to the source code of Rosetta, that is.]

To solve this, you basicly need to install support for 32-bit apps, or alternatively [a poorer choice in my mind] not run Rosetta.

It's clearly an extra burden to build (and test) one more version of Rosetta. And the 64-bit version, although a different binary, would be near identical in all aspects - except it would only be able to run on reasonably new machines from AMD and even newer Intel-based machines... Most machines sold 3 years ago had 32-bit processors, and I guess about half of the ones sold last year did too. Even today, many machines are sold with 32-bit processors [from Intel - the AMD processors that are in production today are all 64-bit capable]. It also, of course, assumes that the user has a 64-bit OS.

If you look at the OS-statistics on Boincstats, you'll see that 64-bit OS's aren't exactly the majority [by inference, as it's not clearly stated which bitness the OS has in the list]... Whilst in Windows XP is available in 64-bit, it's really not frequently the version used. Windows XP is 900,000 of the instances in Boincstats [all projects]. Linux is 89000 instances. So about 10% of the Windows XP instances. Not all of those Linux's will be 64-bit by any amount.

Unfortunately, the CPU breakdown doesn't separate the 64-bit capable and 32-bit only processors either, so we can't judge there. But Intel processors [that are less likely to have 64-bit capabilities as they haven't had that feature very long], are clearly in the majority, although the most popular AMD processor is Athlon64 3000+. But the four first places in the list is Intel processors, with around 250K procesors together, and AMD's processors in 5th, 6th and 7th place are around 75K processors, with one of those being a 32-bit version, so around 20% of the processors are guaranteed to be 64-bit in those 325K "top" ones. There's obviously LOADS more processors in the list, but I think the message is pretty clear...

--
Mats

---

We don't have a 64-bit version of the client as of yet. Sorry.... -KEL

How about doing a filter on the request so that instead of an error message, we AMD 64 users automatically get the 32 bit Linux app instead, at least until such time as a 64 bit app is available? Google platform 'x86_64-pc-linux-gnu' not found and you will find that there are way too many posts out there asking for info, or giving work-arounds. This should be handled either by BOINC itself, or by each application, and should be somewhat transparent to the end user. And while you're at it, take care of the freeBSD folks, too, since they have basically the same problem.

---

How about doing a filter on the request so that instead of an error message, we AMD 64 users automatically get the 32 bit Linux app instead, at least until such time as a 64 bit app is available?

I agree. I just put my new AMD64 3800+ X2 (Suse 10.1 x86-64) on Rosetta. Because it reports being platform type "x86_64-unknown-linux-gnu" it got the error and wouldn't run. The only way to get work was to add an app_info.xml file and "steal" the 32 bit app from one of my other Linux boxes. It runs fine this way except...

Changing the app to a new version is a real pain using this method. First I have to notice that a change is needed, wait for the existing work to clear (or abort them), then make the change. I would like to be able to automatically get the 32 bit app. Also, I haven't found a place to download the app directly. I would have been out of luck if I didn't have another Linux system.

We don't have a 64-bit version of the client as of yet. Sorry.... -KEL

I think "One Norse" is on the right track. I can accept that you haven't compiled a new client for 64 bit users. What is unbelievable is that right now you are basically refusing processor cycles from 64 users. At the very least, provide the info we need to make a customized app_info.xml, or even some directions to run BOINC in a 32 bit wrapper...

---

We don't have a 64-bit version of the client as of yet. Sorry.... -KEL

I think "One Norse" is on the right track. I can accept that you haven't compiled a new client for 64 bit users. What is unbelievable is that right now you are basically refusing processor cycles from 64 users. At the very least, provide the info we need to make a customized app_info.xml, or even some directions to run BOINC in a 32 bit wrapper...

There are only 4 offical boinc platforms.
Linux, Windows and MacOS-X x86 (32bit) and Mac-OS-X PPC.

If you are running a 64bit BOINC client then it is unofficial client in itself. You should get the person who developed the 64bit client to add the alterations to do the automatic requesting of the 32bit application if there is no 64bit one. That would sove the problem for all projects in the same situation.

---

Team mauisun.org

BOINC clients (official or otherwise) advertise their capability by the platform ID. It's up to the server to respond appropriately. Project servers map this ID to the appropriate executable. Some project servers (like Rosetta) don't do this for 64 bit clients. It probably hasn't occurred to them that they need to do this for 64 bit clients. I suspect doing this on the client side is difficult. That's not the BOINC architecture.

Here's my app_info.xml file. It works for me. Of course you have to find the Rosetta executable somewhere. As I said before I got mine from one of my 32 bit Linux computers. You didn't say which Linux you have, but Suse 10.1 (64 bit) runs just fine without wrappers.

<app_info>
<app>
<name>rosetta</name>
</app>
<file_info>
<name>rosetta_5.36_i686-pc-linux-gnu</name>
</file_info>
<app_version>
<app_name>rosetta</app_name>
<version_num>536</version_num>
<file_ref>
<file_name>rosetta_5.36_i686-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

I ended up 'solving' the problem for now by downloading the 32 bit boinc client app from the main boinc website, and modifying the startup and configuration files that were installed by the Debian boinc installer. After adjusting a few lines to point to the newly downloaded app, it requested all 32 bit project files, and is running OK for now. I still think this issue should be dealt with by someone above the user level, especially since 64 bit machines are becoming more widely used.

---

I ended up 'solving' the problem for now by downloading the 32 bit boinc client app... modifying the startup and configuration files that were installed by the Debian boinc installer.

Gaaaah! Did you do all this just to get the 32 bit app? I "complained" earlier about not having direct download access to the Rosetta apps. This is really needed until a fix for the 64 bit clients is implemented.

I agree again. Someone at Rosetta needs to make a server change to handle 64 bit app requests.

I ended up 'solving' the problem for now by downloading the 32 bit boinc client app... modifying the startup and configuration files that were installed by the Debian boinc installer.

Gaaaah! Did you do all this just to get the 32 bit app? I "complained" earlier about not having direct download access to the Rosetta apps. This is really needed until a fix for the 64 bit clients is implemented.

I agree again. Someone at Rosetta needs to make a server change to handle 64 bit app requests.

Purple Rabbit,
I did say that the 64bit is un-official* so it should not really be up to the project to supply a fix for you. You know you are using an unofficial 64bit client when you could just as easily use the official 32bit client (that is up to you).

The fix for the client side developer would be to put somewhere in the code some thing like 'platform * not found' send request for platform 686' or whatever platform you want ti to report as. This would fix it for ALL project and any other future projects that some along.

While it shouldn't be too much of a problem to do the server side part. Most projects just install boinc and use as it with little cusomisation other than to get the project running.


*Since it is unofficial it is either up to the person creating it to overcome the problems of using it or the users responsibility. It is not supported by boinc or the projects (normally, i.e. unless they say so).


P.S. Rosetta@Home is probably not the best project to run if you are using override files since the application regularly updates, we have had 3 updates recently. That is part of Rosetta projrct in itself.
Hopefully they will alter the server side to help out, but then if you can run the 32bit application you are not running it in pure 64bit mode (no real idea why you would want to disable 32bit support myself), in which case you can just tun the standard 32 bit boinc client, like One Norse did.

According to the BOINC site for alternate clients created by other people
[ur]http://boinc.berkeley.edu/download_other.php[/url] You will see who created the debian based boinc.

---

Team mauisun.org

Gaaaah! Did you do all this just to get the 32 bit app?

Well, after a lot of hunting, it amounted to not so much work.The hunting involved a little effort until I (finally) got a clue and googled "Debian boinc." and found the project pages.

1) Do the Debian installation with apt, or aptitude, or apt-whatever. I use adept with Kubuntu. (about 4 clicks of effort on my part)
2) I then uninstalled boinc using adept, but did not use the purge option. This removes the executable, but leaves the configuration files in place. apt should have a similar option. (another four clicks)
3) Get the 32 bit client: First, make a directory on the disk you want to use for boinc: mine is /mnt/hda/downloads/
Go to the Berkley boinc site:http://boinc.berkeley.edu/index.php
Click on 'Download and run BOINC software
Click on 'Download BOINC' and save the file to your directory.
boinc comes as a 'self-extracting archive.' run it (instructions are at http://boinc.berkeley.edu/sea.php

3) Debian initializes boinc with a script file called /etc/init.d/boinc-client (this line is just a FYI)
4) The startup script reads options out of /etc/default/boinc-client (note the directory change). Edit this file (you'll need root privileges) and change the
BIONC-USER, BOINC-DIR and BOINC-CLIENT so that they point to the software you just installed

I prefer to comment out the original, and enter my own line so I have to original to back up to without hunting.

# Original ENTRY: BOINC_USER="boinc"
BOINC_USER="myusername"

# Original ENTRY: BOINC_DIR="/var/lib/boinc-client"
BOINC_DIR="/mnt/hda/downloads/BOINC"

# Original entry: BOINC_CLIENT="/usr/bin/boinc_client"
BOINC_CLIENT="/mnt/hda/downloads/BOINC/boinc_client"

You have to change the BOINC-USER to someone with read/write privileges in the directory you want to use for data (using your own login should work fine). The BOINC-CLIENT must point to the executable boinc-client that was extracted from the archive. The BOINC-DATA directory could be anything to which you have read/write access.

5) Restart your system, and you should see a line about boinc being started as the system boots. If you want to be sure your changes took place, edit the /etc/init.d/boinc-client script file and change either the NAME= or DESC= lines to make a different message show up at boot.

6) To run the boinc manager, you'll need to either run it from a shell /(your directory)/boincmgr or create an icon on your desktop which points to the same executable boincmgr.

All in all, it took much less effort to make the changes than it did to write this post.

---

Additional thoughts on my earlier post:
In step 5, if you wanted to just start the boinc client without restarting the system, you can open a shell, and type in:
/etc/init.d/boinc-client start
and you should get up and running with less hassle.


Even though its not as automatic as installing boinc through apt, as a work-around this approach has a couple of advantages over creating app-info files.
1) You only need to do the modification once, and it should work for every boinc project you want to join.
2) You will not need to edit the app-info files every time a project gets updated.
3) You will not need to edit the configuration files when the boinc client gets updated, just stop the boinc client:
/etc/init.d/boinc-client stop
download the new self-extracting archive in the same place as you downloaded the first one, extract it. then start the new boinc client:
/etc/init.d/boinc-client start

---

You know you are using an unofficial 64bit client when you could just as easily use the official 32bit client (that is up to you).

The problem is that it is far from 'just as easy' to use the 32 bit client. Using the 64 bit one involves a couple of clicks in the package manager, using the 32 bit involves more stuff that the average end user would not be familiar with.

The fix for the client side developer would be to put somewhere in the code some thing like 'platform * not found' send request for platform 686' or whatever platform you want ti to report as. This would fix it for ALL project and any other future projects that some along.

I agree, the person at Berkley who is in charge of the linux client application should put this in the next version.

While it shouldn't be too much of a problem to do the server side part. Most projects just install boinc and use as it with little cusomisation other than to get the project running.

We 64-bit linux users just want the same level of automation: install it and it runs!

I agree that Rosetta, or any other boinc project, is not necessarily the right place to do the modifications. On the other hand, if word got out that Rosetta's software was cooperating automatically with the 64-bit versions of the linux client, you might just be able to recruit a bunch of pretty high performance pc's to your project without 'too much of a problem.' :)

---

You know you are using an unofficial 64bit client when you could just as easily use the official 32bit client (that is up to you).

The problem is that it is far from 'just as easy' to use the 32 bit client. Using the 64 bit one involves a couple of clicks in the package manager, using the 32 bit involves more stuff that the average end user would not be familiar with.

The fix for the client side developer would be to put somewhere in the code some thing like 'platform * not found' send request for platform 686' or whatever platform you want ti to report as. This would fix it for ALL project and any other future projects that some along.

I agree, the person at Berkley who is in charge of the linux client application should put this in the next version.

While it shouldn't be too much of a problem to do the server side part. Most projects just install boinc and use as it with little cusomisation other than to get the project running.

We 64-bit linux users just want the same level of automation: install it and it runs!

I agree that Rosetta, or any other boinc project, is not necessarily the right place to do the modifications. On the other hand, if word got out that Rosetta's software was cooperating automatically with the 64-bit versions of the linux client, you might just be able to recruit a bunch of pretty high performance pc's to your project without 'too much of a problem.' :)

One of the stumbling blocks here is it is some debian developer that is building the client for the debian distribution (I assume it's coming with your disto.) It is not the BOINC developers, they do not supply a 64bit client. So it's probably up to the disto/debain developer to supply you with a one click solution.

I am not a developer I just follow what going on.

---

Team mauisun.org

My main point is that BOINC allows a number of platform types including 64 bit platforms. The 64 bit platforms are not currently supported by many projects and may require work arounds (app_info.xml file) or a compilation of an executable. Where I get the 64 bit BOINC client is irrelevant. It's open source and the BOINC architecture supports it.

Although a project is not required to support the extended platform format, it's almost trivial for the Rosetta server to map the "x86_64-unknown-Linux-gnu" or whatever platform to the 32 bit app. They should do this. It may not work for all Linux distros, but it would be a good start. The distros that don't work should be documented (by someone, somewhere--the project doesn't need this task)

From a user's point of view, Rosetta should have a place where one can download the current app. This beats having two machines (one 32 bit) to get the app. Having to scrounge it from another machine or doing what One Norse did is beyond what a normal user should have to do. If they can map the 64 bit app requests then that would be great.

Other projects do this successfully. Rosetta can too. What's the big deal? I'm using Suse 10.1 Linux x86-64 so my mileage may differ from yours.

My main point is that BOINC allows a number of platform types including 64 bit platforms. The 64 bit platforms are not currently supported by many projects and may require work arounds (app_info.xml file) or a compilation of an executable. Where I get the 64 bit BOINC client is irrelevant. It's open source and the BOINC architecture supports it.

Although a project is not required to support the extended platform format, it's almost trivial for the Rosetta server to map the "x86_64-unknown-Linux-gnu" or whatever platform to the 32 bit app. They should do this. It may not work for all Linux distros, but it would be a good start. The distros that don't work should be documented (by someone, somewhere--the project doesn't need this task)

From a user's point of view, Rosetta should have a place where one can download the current app. This beats having two machines (one 32 bit) to get the app. Having to scrounge it from another machine or doing what One Norse did is beyond what a normal user should have to do. If they can map the 64 bit app requests then that would be great.

Other projects do this successfully. Rosetta can too. What's the big deal? I'm using Suse 10.1 Linux x86-64 so my mileage may differ from yours.

I wouldn't say the architecture 'supports it' as such. There is nothing specific to 64 bit in there it just happens to work. (and afaik you do need to alter a few things to get it to compile.) So yes it does matter where it comes from, since that matters where support comes from.
This should alter if/when Dr. Anderson and Rom Walton decide they need to better support 64bit clients (see Rom Walton Q&A blog).

But anyways, all I'm saying is don't put the problems on to the projects when it's not thier fault.
What you are saying is becuase you can compile boinc (since it's open source and there is nothign stopping you) that the project should support my un-official Z80 client.

anyways, you may want to look at this
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=2549 Linux x86-64 bit client doing what I suggested.
Hope that helps.

As for the download, there file always has been available (just read the main message forum, this Q&A is basically never looked at or used except for a few of us memebers that happen to visiti here, that is something we have asked Rosetta@home to fix ;-)

Current Application Versions and which platforms are available
https://boinc.bakerlab.org/rosetta/apps.php
Download from (normally the last one)
https://boinc.bakerlab.org/download/

Hope either helps you until Rosetta@Home decide what to do.

---

Team mauisun.org

My only point was if the project could easily support the 64 client by mapping it to the 32 bit app then I wanted to encourage them to do so. If not, then end of discussion. I never "demanded" that they support it. It just seemed like an easy thing to do so why not? They may not know this is a problem for a small, but growing group of people.

If nothing else then a link to get the 32 bit app would be nice so I can use the new version with my updated app_info.xml file. I think this is also a simple request, but if the project doesn't want to, end of discussion.

I have a working solution, but it's a kludge. A little help was all I asked. Running the 32 bit BOINC client wasn't appealing to me because I run projects that do have a 64 bit app.

The source code is "official". The compiler makes it work on a specific machine. The project supports specific machines. They can pick and choose. I only wished to encourage them to support mine!

I'd like to have your Z80 version :-) My Heathkit H89 hasn't done anything useful in 18 years. Does it run with 64KB RAM? BTW mine is a 2 MHz Z80 with 5 floppies totaling 1.6 MB of storage (minus 24 KB for Heath DOS, but I can handle CPM too).

I'm done. Both of us have made our points. End transmission :-)

Other projects do this successfully.

Can you point me towards a project that'll make it easy for me donate work?

---