Agreed. And what seems to get overlooked is that BOINC is open source. Whoever really wants a particular feature is free to get out the C++ reference manual and implement it. And if it's done in a modular way that doesn't mess up the rest of the code, I'd be happy to check it in.
-- David Lynn W. Taylor wrote: > I think we're more than a bit off-topic for the developers' list. This > whole discussion probably belongs in Alpha, and not here. > > I did not say that "power users" weren't of value. In fact, I agree > that people who use and care enough about BOINC to devote the time and > study are a major asset. > > Where I have a problem is with "power user features." > > For example, the idea of selecting the mix of projects that can run at > any one instant seems problematic. > > Let's take one scenario: > > I have a four core system, and I'm signed up for four projects. Let's > assume for a moment that I have equal resource shares. > > ... and let's assume one of those (call it LHC, for historical reasons) > has work sometimes, and not at others. > > Strict interpretation of the rule says that when LHC is out of work, and > my queue is empty, I can't use that core for other processing because > that would mean two instances of the same project running at the same time. > > So, idle cores and debt that will run away because the rule doesn't > allow more than one work unit per project -- and that means no way to > make up for projects that are overworked. > > Sure, there are users who could tune that to work, but there are also > ways to create a whole lot of edges and impossible situations. > > Martin raised questions about a "Computer Science" view vs. "Computer > Engineering" and frankly, as an applications programmer, I'm not sure > how to tell how large the cache is, or what other programs are running > that could bump my data or code from the cache. > > I do know how to arrange loops to minimize the odds of a cache fault, > but that's the limit. > > So, I think it's good to listen to power users (and anyone else) when > they start pointing out problems. > > What I worry about are the solutions that many power users "demand." > > While I don't believe a "mom and pop" scenario like you suggested exists > (I don't think the common set-and-forget cruncher is more than dimly > aware, or even dimly interested, in what BOINC is doing on a day to day > basis), is that user better served by more buttons and knobs, or are > they better served by a "per processor" DCF? > > Limiting the total number of work units probably makes a lot of sense > (as a safety in case of a poor DCF), but how many power users would > accept that? It doesn't seem like a popular idea. > > ... and personally, I'm just a little bit offended by the "We're power > users, they'd better cater to us or else!" attitude. Milo Bloom said it > best when he said "The first sign of a nervous breakdown is when you > start thinking your work is terribly important." > > But that's my personal opinion, it's not a technical position, nor does > it represent anyone but myself. It does not represent BOINC, SSL, or > the Regents of the University of California. > > Anyone who sees a problem and reports it is an asset. If it's possible > to change BOINC so that it solves the problem without help, that's the > best possible result. \ _______________________________________________ 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.
