It has a lot of files that are not on limewire and it downloads very reliably. It downloads from multiple clients at the same time. If the remote side disconnects it saves state and picks up later when the file reappears somewhere else - this is perhaps it's best feature.
Sometimes (if a large/rare file) it takes a long time to download, like days, but after seeing this work you get used to it and consider it as a real background activity. Check back in a couple days, it's magically there.
There are several interfaces. I'm using the web interface, which is fine but took some figuring out.
It also requires a bit of unix skills to install (first install fink, then symbolically link/usr/local/lib/libdl.dylib ->/sw/lib/libdl.0.dylib)
It looks like several people (well, more than several)
posted responses without reading beyond the lead-in.
If you're one of them, yes, the argument here is in the general ballpark of
"software estimation is hard or impossible",
but it actually says something more specific than that.
The article does NOT say the following:
software estimation is impossible
objective software estimation is impossible therefore
software estimation is impossible
The article DOES say
Various software engineering authorities claim that objective software estimation
is possible [paragraph 3, quotes on first page].
objective software estimation is in fact not possible
[body of article]
From this, it does NOT conclude either of the points 1,2 above.
Instead, it concludes:
Software construction is inherently creative and subjective,
having more in common with physics than manufacturing;
software estimation is inherently subjective [conclusion, Bollinger quote].
Because software is used in the government, in vehicles, and
other places where it can potentially have a negative
on people's lives, we (software writers) have an ethical
responsibility to not over-represent our ability to estimate
(especially when it comes to estimation of software quality- r.e. correctness claim
in the supplementary material).
Now some of the response posts, paraphrased:
"The article says that estimation must be objective
rather than subjective"
No, it does not say this.
"The article says that subjective software estimation is not useful"
It also does not say this.
"The article says that we are looking for exact answers, not estimates"
or
"the article doesn't understand what `estimate' means"
No, the article distinguishes subjective and objective estimates,
and specifically discusses the case of an objective estimate with bounds in detail.
"People/organizations can make accurate estimates, I made one last week"
or "Estimation is hard, I double my estimates and still miss them".
Ok, but slightly off topic:
the article is specifically talking about those who claim objective estimates.
"You can do objective estimation, and I did it last week using COCOMO"
And where did you get an objective estimate of the complexity of a new project?
Read the article...
"I think I'm the only person who has read this far".
Yes, you are. Your boss is monitoring you, get back to work.
"Software estimation needs common sense, not advanced mathematics."
Certainly. The 'manufacturing' camp of software estimators
(Humphrey quote in the
supplementary material)
say or hint that software construction can be made into a repeatable,
fairly boring process where projects are always on time and programmers are
like factory workers. This may or may not be true (I don't think it is),
but regardless: to make this view seem more science than philosophy some
of these people have fallen into the trap of cloaking their
estimating process with formal notation and claiming or hinting objectivity.
This part is wrong.
On the contrary, [conclusions to the article and the
supplementary material]:
Good estimation therefore requires experience and judgment.
The software industry should value human experience, intuition, and wisdom
rather than claiming false objectivity and promoting
entirely impersonal "processes".
See this for a couple of small but real benchmarks on the IBM java; source included. Java speeds have improved considerably and are continuing to improve. Someday soon they'll be at the point where it's not an issue (e.g. 1.3x slower than C). Note that on one of the benchmarks the IBM jdk is *faster* than g++ -O. Huh? The processor was a celeron; I assume that the IBM jdk used PII instructions whereas g++ -O needs an additional flag. But still...
Slashdot Mirror
I've had very good luck with mldonkey.
/usr/local/lib/libdl.dylib -> /sw/lib/libdl.0.dylib)
It has a lot of files that are not on limewire and it downloads very reliably. It downloads from multiple clients at the same time. If the remote side disconnects it saves state and picks up later when the file reappears somewhere else - this is perhaps it's best feature.
Sometimes (if a large/rare file) it takes a long time to download, like days, but after seeing this work you get used to it and consider it as a real background activity. Check back in a couple days, it's magically there.
There are several interfaces. I'm using the web interface, which is fine but took some figuring out.
It also requires a bit of unix skills to install (first install fink, then symbolically link
It looks like several people (well, more than several) posted responses without reading beyond the lead-in. If you're one of them, yes, the argument here is in the general ballpark of "software estimation is hard or impossible", but it actually says something more specific than that.
The article does NOT say the following:
The article DOES say
From this, it does NOT conclude either of the points 1,2 above. Instead, it concludes:
Now some of the response posts, paraphrased:
No, it does not say this.
It also does not say this.
No, the article distinguishes subjective and objective estimates, and specifically discusses the case of an objective estimate with bounds in detail.
Ok, but slightly off topic: the article is specifically talking about those who claim objective estimates.
And where did you get an objective estimate of the complexity of a new project? Read the article...
Yes, you are. Your boss is monitoring you, get back to work.
Certainly. The 'manufacturing' camp of software estimators (Humphrey quote in the supplementary material) say or hint that software construction can be made into a repeatable, fairly boring process where projects are always on time and programmers are like factory workers. This may or may not be true (I don't think it is), but regardless: to make this view seem more science than philosophy some of these people have fallen into the trap of cloaking their estimating process with formal notation and claiming or hinting objectivity. This part is wrong.
On the contrary, [conclusions to the article and the supplementary material]:
How about some real numbers? A java vs. C/C++ benchmark page is here
See this for a couple of small but real benchmarks on the IBM java; source included. Java speeds have improved considerably and are continuing to improve. Someday soon they'll be at the point where it's not an issue (e.g. 1.3x slower than C). Note that on one of the benchmarks the IBM jdk is *faster* than g++ -O. Huh? The processor was a celeron; I assume that the IBM jdk used PII instructions whereas g++ -O needs an additional flag. But still...