Augustine has donated a 64-bit BOINC core for Linux, Crunch3r has donated one for some other operating called Windows. Most projects have a thread called AMD64 in which Augustine has posted download links for both the Linux version and the Windows version. Perhaps try those and let us know if you find anything wrong with them. I've heard they are both simply marvelous.

I'm sure they are great, in fact.. I intend on using Crunch3r's.

HOWEVER - It would be nice to have one that is supported, and 'official', since - With the advent of Vista and EMT64/AMD64/x86_64 .. The 64-bit OS is coming wether we want it to or not.

Better to start now and get the kinks worked out while we're still sortof ahead of the game.

---

Surely even the most regal 64-bit distro uses 32-bit apps too.

Nah. If an app is not GPLed, then it's not admissible to include it into distro. If it is GPLed, you compile it from sources.

You get totaly 64-bit distro.

Hell, half of 'usual' things wont work (such as many of modern web pages with all the java-script and flash content), but who cares?

;)

---

Metod ...

Actually i use 64 bit Kubuntu. The work to make it run all 32bit apps took all of 10 seconds.
Im forced for now to run Firefox in 32bit for Flash and Java. Only the plugin is not available for 64bit FF ( the general java stuff comes in 64bit). other than that i haven't found a single thing that doesn't work on my hardware software setup and things only improve with time.

I currently use Augustine's client and it works fine but i was after an officially supported 64 bit client and don't really see why people think this is such a terrible idea.

We need a standard id string for 64 bit currently as its not official. Some people are using x86_64-pc-linux others support x86_64-unknown-linux.

There are a few projects supporting 64 bit with native apps and others send 32 bit apps in a wrapper. Some projects have speed improvements and others im told have none (i highly doubt this as anything supporting 64 bit also supports SSE2 which means it can be compiled with some optimization built in without leaving any machine unable to run it) but i guess thats the individual projects business.

As for sending 32 bit apps to 64 bit machines if no 64 bit app is available its a great idea and im all for it. If we have a standard to work off for both Linux and windoze it can only help as 64 bit is only becoming more common not less so.

We need a standard id string for 64 bit currently as its not official. Some people are using x86_64-pc-linux others support x86_64-unknown-linux.

Platform names are already standardized by BOINC. See the platform list. If projects or clients use different names, they're Doing It Wrong :)

I currently use Augustine's client and it works fine but i was after an officially supported 64 bit client and don't really see why people think this is such a terrible idea.

It isn't a terrible idea. It's just that the BOINC devs seem to have enough to do with the 32-bit version. If they were to get into the position of officially supporting a 64-bit client too then maybe they would be spread too thin and development would slow down.

I suspect the plan at Berkeley is to get a few more features added and get all the bugs worked out (ok, most bugs) and then port it to 64-bit. That will take time. One way to speed it up would be to get Augustine and Crunch3r to join the BOINC dev team and then get Dr. Anderson to appoint them the offical 64-bit developers or porters or whatever title is appropriate. Lately, Augustine and Crunch3r seem to quickly come out with 64-bit compiles of every new 32-bit release. If that's all those 2 did, just port the 32-bit to 64 without adding new features/functions, so the 64-bit is merely a copy of the 32-bit wrt features/functionality, then Berkeley could make that their official 64-bit version and everybody would be happy. Yep! There ya go, problem solved! Somebody tell Augustine, Crunch3r and Anderson what the new plan is ;-)

We need a standard id string for 64 bit currently as its not official. Some people are using x86_64-pc-linux others support x86_64-unknown-linux.

Platform names are already standardized by BOINC. See the platform list. If projects or clients use different names, they're Doing It Wrong :)

Agreed. It may not be the best standard. Perhaps there is room for improvement. But it is the standard and should be adhered to otherwise it creates mayhem and indecision. Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply.

We need a standard id string for 64 bit currently as its not official. Some people are using x86_64-pc-linux others support x86_64-unknown-linux.

Platform names are already standardized by BOINC. See the platform list. If projects or clients use different names, they're Doing It Wrong :)

Maybe someone should tell SETI

---

CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1

Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply.

Any client that uses a different name wouldn't get work from a project with correct names. Any project with different names wouldn't give work to clients following standard.

Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply.

Any client that uses a different name wouldn't get work from a project with correct names. Any project with different names wouldn't give work to clients following standard.

Of course. But that does not solve the problem, it merely restates the problem. I can restate it yet another way... If project A uses x86_64-pc-linux-gnu for 64-bit Linux hosts and project B uses x86_64-unknown-linux-gnu for 64-bit Linux hosts then 64-bit Linux clients that identify themselves as x86_64-pc-linux-gnu cannot crunch project A. I believe that is what is happening now, correct me if I am wrong, but I think SETI is using x86_64-unknown-linux-gnu.

There, that's the problem. An example of the mayhem and indecision created by that problem is Einstein's position that they do not plan on supporting AMD64 until other projects conform to the standard. At CPDN, in response to requests for sending their 32-bit app to 64-bit systems, Carl is babbling utter nonsense about not having a 64-bit app and not being able to make their source code public which is true but not relevant to what has been requested of him. Apparently Carl wants to sidestep the entire issue of projects not conforming to the naming standard and derail any conversation on the topic by acting like a total idiot and pretending he doesn't understand the question. Can't say I blame him considering how childish and stubborn some project admins are. Then we have others requesting official 64-bit clients to force compliance to the standard when it's obvious that is not going to solve the problem either. Yah, that's mayhem and indecision.

At the heart of the problem is 1 or 2 assinine project leaders who refuse to comply with the existing standard. Build all the official 64-bit CCs you want, those assinine project leaders will still be assinine project leaders. Throw them in the pillary and pelt them with rotten veggies and smelly dead aminals until they get a brain. If that doesn't help then just fire their sorry arses out the door.

Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply.

Any client that uses a different name wouldn't get work from a project with correct names. Any project with different names wouldn't give work to clients following standard.

Of course. But that does not solve the problem, it merely restates the problem.

I know, I just gave actual *reasons* on why the devs should be tortured according to your guidelines :) Also, if a client uses a wrong name and doesn't get work, the user can't really complain to the project...

Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply.

Any client that uses a different name wouldn't get work from a project with correct names. Any project with different names wouldn't give work to clients following standard.

Of course. But that does not solve the problem, it merely restates the problem.

I know, I just gave actual *reasons* on why the devs should be tortured according to your guidelines :) Also, if a client uses a wrong name and doesn't get work, the user can't really complain to the project...

Agreed. Oh well, the projects I want to crunch all do it the right way. I have no desire to crunch SETI or any project like Einstein that lets SETI's goofyness dictate what they do. They can both go pound sand.

Clownius gave us...

... so i would like to move onto a 64bit client and i know many other users would too.

Augustine has donated a 64-bit BOINC core for Linux, Crunch3r has donated one for some other operating called Windows. Most projects have a thread called AMD64 in which Augustine has posted download links for both the Linux version and the Windows version. Perhaps try those and let us know if you find anything wrong with them. I've heard they are both simply marvelous.

I'm using Augustine's 5.8.17 on Ubuntu, but the BOINC Manager doesn't work with it.

---

I'm using Augustine's 5.8.17 on Ubuntu, but the BOINC Manager doesn't work with it.

Can you be more specific?

About 30 minutes ago I installed Augustine's 5.8.17 on Fedora Core. No problems so far.

Its working with mine. This is basically just the client itself it doesn't come with a manager. How did you install/how are you running BOINC? We should be able to track this down fairly quickly.

Install the official package, then overwrite only the client with Augustine's one. The package contains the rest of the files needed, like the manager.

I'm using Augustine's 5.8.17 on Ubuntu, but the BOINC Manager doesn't work with it.

Can you be more specific?

About 30 minutes ago I installed Augustine's 5.8.17 on Fedora Core. No problems so far.

When I select run_client, the client runs, when I select run_manager, nothing happens.

I have to use BOINC Manager on another computer to open the Manager functions or use Boincview.

---

Its working with mine. This is basically just the client itself it doesn't come with a manager. How did you install/how are you running BOINC? We should be able to track this down fairly quickly.

I installed BOINC from the SETI download URL, then I put Augustine's files in the directory.

I run BOINC by selecting run_client.

---

When I select run_client, the client runs, when I select run_manager, nothing happens.

Only the core client is replaced with a 64-bit one. The original 32-bit manager can still be run without problems alongside the 64-bit client (see README.x86_64-pc-linux-gnu from my tar ball).

Try "boincmgr" instead.

HTH

---

When I select run_client, the client runs, when I select run_manager, nothing happens.

Only the core client is replaced with a 64-bit one. The original 32-bit manager can still be run without problems alongside the 64-bit client (see README.x86_64-pc-linux-gnu from my tar ball).

Try "boincmgr" instead.

HTH

I looked at the readme again.........I don't see anything that would explain why the Boinc Manager doesn't run.

I use the same exact script (run_client) that was in the original BOINC pkg from SETI to run your client. The client starts and runs just fine. I can see the client running from another computer using the BOINC Manager or Boincview.

When I use the same exact script (run_manager) that was in the original BOINC pkg from SETI to run the manager, nothing happens. The BOINC Manager does not start.

Thank you.

---

ABC@home looks like it is able to recognize my Pentium 4 running 64 bit Linux, without any additional work on my part after installing boinc. From boinc Message tab:

"Thu 12 Apr 2007 07:27:11 AM PDT|ABC@home|Finished download of file abc-finder_1.02_x86_64-pc-linux-gnu"

A couple minutes later I see 2 tasks 'Running' and one 'Ready to Report'. SETI & Einstein lack a configuration update on their server, I guess.

"Wed 11 Apr 2007 11:26:21 PM PDT|Einstein@Home|Successfully attached to Einstein@Home
Wed 11 Apr 2007 11:27:41 PM PDT|Einstein@Home|Scheduler request succeeded
Wed 11 Apr 2007 11:27:41 PM PDT|Einstein@Home|Message from server: platform 'x86_64-pc-linux-gnu' not found
Wed 11 Apr 2007 11:33:12 PM PDT||Fetching configuration file from http://setiathome.berkeley.edu/get_project_config.php
Wed 11 Apr 2007 11:34:45 PM PDT|http://setiathome.berkeley.edu/|Scheduler request succeeded
Wed 11 Apr 2007 11:34:45 PM PDT|SETI@home|Message from server: platform 'x86_64-pc-linux-gnu' not found

But since ABC has it right, and presumably other projects do too, I'm not going to bother with custom scripts on my client for a problem that obviously can be handled once, for all project members, on the project server.

The Projects tab of both SETI & Einstein show that both have deferred communication for 24 hours, but in light of the discussion above, I'm detaching from both in favor of better administered projects.