> 4. I can't log into a different project and try workunits from it because > that project will give me weeks of work, which I don't want.
That alternate project will only "give" you weeks of work if you ask for it. Decrease your work requests (cache size) when testing repaired hardware. > On Tuesday, 17 November 2015, 11:58, Charles Elliott <[email protected]> > wrote: > > You people are going to wind up being cruel, now not without realizing it. > Been there, done that, not fun! If someone has a flakey hard disk, memory, > or video card, then he or she is going to create error workunits, perhaps a > lot of them. Then the @Home project cuts the user off. This is what I was > thinking at the time: > > 1. This is my main system, and while I am screwing around with this project, > and trying to get my computer working again, I am not doing any real work. > > 2. Now that I think I have finally fixed the problem, the project says I > have to wait 24 hours or more for more workunits before I can try it out. > > 3. Even when the project starts dribbling out workunits to me again, it > will only be a few a day. > > 4. I can't log into a different project and try workunits from it because > that project will give me weeks of work, which I don't want. If I take > their workunits and wind up aborting hundreds of them, then I really am > being irresponsible. > > 5. This whole damn @Home stuff is costing me hundreds of USD in electricity > per month and thousands for new DIY computer parts and equipment per year. > Why do they treat me so bad? > > > You must have noticed that the active user percentage on many projects is in > the lower single digits. I tend to believe that the inflexible and > arbitrary way @Home projects treat users when they have a problem has to be > part of the reason for the low percentage of active users. There are people > that will create error workunits in the hundreds per day if you let them, > and I have seen this go on for weeks before anyone catches them, but these > people I believe are in a small minority. Why ruin the @Home experience for > everyone for a few bad guys? > > There has to be an easy way for a user to be taken off an @Home project's > s--- list. > > BTW, the environment for these @Home projects is becoming harsher and > harsher. In my area (Philadelphia, Pennsylvania, USA), the electricity > supplier is sending letters to customers telling what the customer's > electricity consumption is as a percentage of neighbors' consumption. > Consumption is commented on. "Why is your electricity use so much higher > than your neighbors'?" (Don't you care about the environment?) > "There was > some improvement last month." (Can you do more?) > > > Charles Elliott > > > > -----Original Message----- > From: boinc_dev [mailto:[email protected]] On Behalf Of > Henri Heinonen > Sent: Monday, November 16, 2015 5:48 PM > To: Richard Haselgrove > Cc: BOINC Developers Mailing List > Subject: Re: [boinc_dev] WU Black List for user/host? > > Yes, but for user IDs. > > Henri. > > 2015-11-12 19:37 GMT+02:00 Richard Haselgrove > <[email protected]> > : > >> Like >> https://boinc.berkeley.edu/trac/wiki/BlackList ? >> >> >> >> > On Thursday, 12 November 2015, 17:25, Henri Heinonen < >> [email protected]> wrote: >> > > I propose a WU Black List where you can enter a user ID and/or >> > > host ID >> so >> > the BOINC server won't send further workunits to those > users/hosts. >> > This should prevent scammers and people with some misconfigured > clients. >> > >> > Henri. >> > _______________________________________________ >> > boinc_dev mailing list >> > [email protected] >> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> > To unsubscribe, visit the above URL and (near bottom of page) enter >> > your email address. >> > >> > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
