In December 1969, my first program ran -- on an IBM 1620, in assembly, on cards.
If I had the card deck, it would be almost impossible to run that program today. The same thing is true on a lesser scale with everything I do. I almost have to run VMware to have environments where everything works. ... and I've just concluded a fairly rough "Beta" on my main project. We'll be back in Beta for the next version before the end of the year. My biggest single bane is the "tester" that does not test. They give the appearance that all is well, but no actual results. I'm frustrated over the amount of work that I have to do to monitor the people who promised (in writing) that they would test -- time that could be spent developing useful features. When you stop testing, you're saying that you don't care if the problems you see ever get fixed, and you're saying that you don't want to insure that you'll have an upgrade path. I haven't contributed very much because I haven't seen many problems. I don't have a multi-core multi-GPU machine (I don't game, and I don't do much graphics). But I do run the latest, on a slightly antique OS, and hopefully I'm checking to make sure the single core, slow machine doesn't get lost with all the multi-core mega-go-fast features. But hey, it's your call. I have my opinion, and that is if you care enough to be on the developers list, you should contribute. I know a lot of people get frustrated because they do try to contribute, and they don't see their contributions realized in code right away. Again, as someone who has been doing this for four decades, it doesn't mean you weren't heard, and it doesn't mean your contribution was ignored. Often, ideas and suggestions evolve into something that looks completely different. -- Lynn Mikus Grinbergs wrote: >> More to the point, by simply declaring that he's staying on 6.4.5, Mikus >> is no longer helping develop new versions of BOINC, he's hindering it. > > It is absolutely correct that I've given up on developing new > versions of BOINC. My reason is that BOINC development is no longer > helping me in my participation in distributed computing projects. > > My "big" system is running the 5.10.45 client. Why? Because none > of the newer clients fetch as much work as I need. I typically > connect once a day, and "squirt" work up/down. I then disconnect > until the next day. What happens when I run with a newer client is > that I manually wipe out all history, and enough work gets > downloaded. But the next day, *less* work gets downloaded than was > crunched. And the same thing the day after. Very soon, the new > work being downloaded does not add enough to the ready queue to keep > the system crunching for 24 hours. I must perform an "unscheduled" > download to keep the system from going idle, and have to manually > wipe history to restore download volume. [With 5.10.45, what gets > downloaded each time is about the same as what got crunched since > the last download.] [My guess is that the newer clients are > refusing to download work from "overworked" projects that have work > available, so as to supply crunching capacity to the "underworked" > projects -- which unfortunately happen *not* to have work to do !!] > > It seems to me that BOINC development in the "work fetch" area is > solving server throughput problems for large projects by adding > constraints to the clients. I have enough trouble with occasional > retrying of transfers -- when they miss a "squirt", they miss a day > -- if a result upload misses several "squirts", the workunit may end > up missing its deadline. Now BOINC development has come up with > "project deferrals" -- I'm fairly sure that's incompatible with how > I participate. If BOINC development were willing to provide a way > to "opt out" from some of the new "work fetch" constraints, I'd be > willing to continue to help. As it is, things which used to work > with old versions of BOINC no longer work for me with new versions. > > mikus > > > p.s. I laugh at one particular project. They limit the amount of > work given out at one time, and they set a short deadline. The > result: I connect for a "squirt"; a few WUs get downloaded, and > immediately go into EDF; no more WUs get downloaded until the next > "squirt" - which is tomorrow. If they allowed a larger amount to be > downloaded, my system has the capability to crunch them all in less > than 24 hours -- but the "supply" policy that project has chosen > ends up limiting the very benefit (have-others-do-the-crunching) > that distributed computing provides. > > _______________________________________________ > 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.
