Message boards :
BOINC client :
Official 64 bit clients
Message board moderation
Previous · 1 · 2 · 3 · Next
Author | Message |
---|---|
Send message Joined: 2 Sep 05 Posts: 45 |
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. |
Send message Joined: 9 Sep 05 Posts: 128 |
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 ... |
Send message Joined: 17 Feb 07 Posts: 35 |
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. |
Send message Joined: 19 Jan 07 Posts: 1179 |
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 :) |
Send message Joined: 21 Feb 07 Posts: 22 |
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 ;-) |
Send message Joined: 21 Feb 07 Posts: 22 |
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. 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. |
Send message Joined: 6 May 06 Posts: 287 |
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. 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 |
Send message Joined: 19 Jan 07 Posts: 1179 |
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. |
Send message Joined: 21 Feb 07 Posts: 22 |
Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply. 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. |
Send message Joined: 19 Jan 07 Posts: 1179 |
Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply. 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... |
Send message Joined: 21 Feb 07 Posts: 22 |
Any project devs who don't comply with the standard should be pilloried and have rotten vegetables thrown at them until they comply. 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. |
Send message Joined: 31 Aug 05 Posts: 51 |
Clownius gave us... I'm using Augustine's 5.8.17 on Ubuntu, but the BOINC Manager doesn't work with it. |
Send message Joined: 21 Feb 07 Posts: 22 |
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. |
Send message Joined: 17 Feb 07 Posts: 35 |
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. |
Send message Joined: 19 Jan 07 Posts: 1179 |
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. |
Send message Joined: 31 Aug 05 Posts: 51 |
I'm using Augustine's 5.8.17 on Ubuntu, but the BOINC Manager doesn't work with it. 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. |
Send message Joined: 31 Aug 05 Posts: 51 |
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. |
Send message Joined: 10 Mar 06 Posts: 73 |
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 |
Send message Joined: 31 Aug 05 Posts: 51 |
When I select run_client, the client runs, when I select run_manager, nothing happens. 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. |
Send message Joined: 12 Apr 07 Posts: 2 |
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. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.