> there is a real likelihood that FairPlay does > violate the DMCA as it's worded even though the > clearest purpose of it is to ensure continued > rights to use of legally purchased material.
Why do you think that? I strongly disagree. I think there is a real likelihood that a lawyer who knows how to shop for jurisdictions could run up a bill to bankrupt OSDN pretty easily, and this might just make the RIAA mad enough so that they would (perhaps by proxy through Apple) do just that, but I think it's pretty clear that playfair does not violate the DMCA in any way, so I'd like to understand on what grounds you are accusing the project managers of violating federal law.
GPL is just a powergrab. The significant difference between the GPL powergrab and, say, the Apple iTunes SLA powergrab is that the GPL powergrab is defensive. I can understand and empathize with a human's desire to defend theirself by any means necessary, whether I agree with it or no, while simultaneously decrying or even decapitating the bastard who is attacking said human.
I think the dual channel memory is what is making
the difference in the case you describe. You're
getting a 16% bump instead of a 5 or 6% bump because
the memory channels are being used more effectively,
not just the core. In a single-channel memory system, I think the HT would only make a 5-6% difference. (This is an hypothesis, derived from my mental model of HT CPU operation, which can be used to confirm or disconfirm the model.)
> Sharepoint is VERY easy to use/implement on a base > level. The learning curve remains small for users > as you add features, and only increases marginally > for the admins/developers.
These are hardly competitive selling points. They are features common to every open-source wiki or content-management system that I've ever used, with the possible exception of TWiki, which frankly sucked.
Being closed source is a good enough reason to disqualify a product from being used in a mission-critical role, since it could fail and be discontinued or be demonstrated to have show-stopping security failures at any time, and the enterprise has no recourse but mission failure.
I'm not so sure they will all be sold. Palm dumped truckloads of Palm 3s in a secured landfill, just to prevent them from getting into the marketplace and undermining the price point of their newer products.
I won't argue with any of your points, which all seem to me to have a sound basis; rather, I will try to balance those points with a hypothetical consideration: I suspect that the death rate due to inadequate medical care is several orders of magnitude greater today than it was when the standard of medical care was primitive, say, 100 years ago. This signifies the existence of an intensely inequitable global distribution of wealth.
I think that wealth distribution follows an approximate Zipf distribution. Even in the U.S. alone, the wealthiest 13,000 households command greater wealth than the least wealthy 20,000,000. Whether this is good or bad depends on your criteria, but also on the mechanics of the econonmy. Just as an engine requires uneven heat distribution to perform a productive function, some degree of inequity seems obligatory in order to incent labor without corporal compulsion.
I think the proportion of persons dying of starvation or inadequate medical care (relative to the mean) would be a good measure of the eggregiousness of inequitable distribution.
Each claim is independent of the others, but they are written from absurdly general to excruciatingly specific, so that in court the barratrist can apply the broadest claims that the court will countenance. Making a very specific claim does not in any way mitigate the breadth of the most general claim made in a given patent.
HT does wonders for the P4 in the bandwidth tests,
because they are not taxing the execution core; they
are only stressing the limits of those parts of the
CPU which are replicated. In fact, I can go a step
further and say that they aren't even taxing those
parts in any meaningful way, because the P4 just
plain has fat pipes. Forthcoming dual-channel revisions
of the Athlon64 will do another leap-frog, and put
that architecture's bandwidth in the lead for a while, but it hasn't happened yet.
The real-world apps demonstrate that the 5% of
die space spent on HT doesn't result in much more
leveraging of the execution core, in practice.
I can't imagine why anyone would care what the P4
numbers were without HT, since no one will ever
run it that way now that OSen are supporting it.
As regards FreeBSD's kernel threads, the answer is
"not really" since the overwhelming bulk of the benchmarks was spent in userspace (less so for the compile benchmarks than for the crypto ones). Notice that the
user time numbers favored the Athlon64 no less than
did the wall time numbers.
I think it's interesting that the synthetic benchmarks all favored the P4 (a highly academic design) while the user load tests all favored the 64.
The article as phrased suggests that GTR is hitherto unconfirmed by observational data. That is not the case:
The aspects of the General Theory of Relativity
which are addressed by this experiment are consistent
with experimental data for the perihelion of Mercury
which actually predated
and motivated the General Theory, and
are confirmed every day by gravitational lensing
effects used very practically by astronomers, as
recently reported here on slashdot.
It's a popular Senior or Graduate physics exercise to design experiments demonstrating GTR -- and a somewhat more ambitious exercise to perform them.
This one is notably primarily for being bloody expensive and having blown it's schedule by such a
honking big margin.
> It's hard and you never get it right the first time.
The latter is true, the former is not. Yes, I've designed and implemented, in solo and in teams, numerous UIs which were released into the public marketplace, and fulfilled their functions quite well. If your criterion of success is that it is perfect for all users, regardless of culture or literacy or gender or sheer bloody-mindedness, they were all failures, but the existence of whinging complaints is not, in my view, an indicator that a UI design was not successful.
The main reasons why UI designs fail are that either (1) the designer assumes too much insight in the user base or (2) the designer lacks insight herself. The former is due to the character flaw of arrogance endemic among the intelligent, and the latter is due to the character flaw of laziness endemic among the unintelligent. Hence my conclusion: Any morally decent individual with a bare modicum of technical skill can do a UI quite well, if they have a smidgin of understanding of the application domain and are willing/empowered to do basic usability studies.
Now the coincidence of those four factors may be so rare as to make well-executed UI designs seem like hens teeth, but its not because they are hard to make. It is because the circumstances which conspire against them are so overwhelming.
> HTTP sucks for file transfers, frankly. You need a full-fledged web-browser just to view the index of files on an HTTP server.
Pfft. It's trivial to recognize the URLs (libwww:HTParse).
> # handling authentication.
mod_auth_mysql, mod_auth_ldap, mod_auth_... Vastly more configurable and utile than any FTP server I've ever seen, Apache runs on every popular web server platform.
# handling sessions.
Why would you care?
# keeping statistics
The number and range and functionality of even the *free* tools to convert Apache logs into reports boggles the mind.
# limiting connections
mod_throttle
# communicating error messages
HTTP's error system is essentially a somewhat more mature clone of that used in FTP.
I haven't seen you make any actual, valid points here.
He's got the "UI is spooky" meme stuck in his cranium. It's distorting his view. This view holds that while coding device drivers or application logic is easy because its math, UI is spooky because it's human, and that requires a cognitive psychology doctorate and an MFA to do right. This is, of course, bullshit, so it's not surprising that he is mislead into drawing erroneous conclusions and basing his critical reply to ESR on those errors.
In fact, UI is not hard anymore (since we don't have to use the Xt object model, the most overengineered piece of object-oriented crap that ever came out of an ivory tower). Instead we have simple UIs and simple object -event models like KDE's components and QT's slots to hide the complexity (most of the time), and vastly more examples of consistent and market-persistent UI designs since back in the day, making UI design and implementation so dead simple the bulk of the time that any barely or even not quite competent coder is without excuse.
No, ESR hit the nail on the head this time. (Even a broken clock is right twice a day?) The upshot is that CUPS is one of the least well-integrated systems on the modern Linux workstation desktop, and it's a real burden on the viability of further popularizing the platform. But fixing it would not be hard. What is hard, and what ESR is addressing, is the more important problem of fixing the underlying cause, which is endemic: Development-centricity so all-consuming that the most gracious and diligent contributors to the public good will overlook the most elementary aspects of the public use of their software.
HTTP does all that. There are well-defined and well-implemented (Squid) cache-tree protocols for HTTP. This is very old stuff. FTP is just plain obsolete. It ads *zero* value over HTTP, and it's harder to use. Trying to bring FTP up to the standards of HTTP is a futile effort too, since HTTP is mature on many more dimensions, and does not suffer from the gross defects of the more primitive FTP such as transmission of port numbers as stream data.
Slashdot Mirror
> there is a real likelihood that FairPlay does
> violate the DMCA as it's worded even though the
> clearest purpose of it is to ensure continued
> rights to use of legally purchased material.
Why do you think that? I strongly disagree.
I think there is a real likelihood that a lawyer
who knows how to shop for jurisdictions could run
up a bill to bankrupt OSDN pretty easily, and this
might just make the RIAA mad enough so that they
would (perhaps by proxy through Apple) do just that,
but I think it's pretty clear that playfair does
not violate the DMCA in any way, so I'd like to
understand on what grounds you are accusing the
project managers of violating federal law.
It was always a good idea. They've got 1.1 billion
mouths to feed. The more money they can suck out of
the U.S. and Europe, the better.
GPL is just a powergrab. The significant difference
between the GPL powergrab and, say, the Apple iTunes
SLA powergrab is that the GPL powergrab is defensive.
I can understand and empathize with a human's desire
to defend theirself by any means necessary, whether
I agree with it or no, while simultaneously decrying
or even decapitating the bastard who is attacking
said human.
I think the dual channel memory is what is making the difference in the case you describe. You're getting a 16% bump instead of a 5 or 6% bump because the memory channels are being used more effectively, not just the core. In a single-channel memory system, I think the HT would only make a 5-6% difference. (This is an hypothesis, derived from my mental model of HT CPU operation, which can be used to confirm or disconfirm the model.)
http://www.winmx.com/
> Sharepoint is VERY easy to use/implement on a base
> level. The learning curve remains small for users
> as you add features, and only increases marginally
> for the admins/developers.
These are hardly competitive selling points. They are features common to every open-source wiki or content-management system that I've ever used, with the possible exception of TWiki, which frankly sucked.
Being closed source is a good enough reason to disqualify a product from being used in a mission-critical role, since it could fail and be discontinued or be demonstrated to have show-stopping security failures at any time, and the enterprise has no recourse but mission failure.
I'm not so sure they will all be sold. Palm dumped truckloads of Palm 3s in a secured landfill, just to prevent them from getting into the marketplace and undermining the price point of their newer products.
I think that wealth distribution follows an approximate Zipf distribution. Even in the U.S.
alone, the wealthiest 13,000 households command
greater wealth than the least wealthy 20,000,000.
Whether this is good or bad depends on your criteria, but also on the mechanics of the econonmy. Just as an engine requires uneven heat distribution to perform a productive function, some degree of inequity seems obligatory in order to incent labor without corporal compulsion.
I think the proportion of persons dying of starvation or inadequate medical care (relative to the mean) would be a good measure of the eggregiousness of inequitable distribution.
I have no idea how that metric plays out.
Severance is for management.
Your title describes your comment well. I suppose next you are going to tell me that sneering and hyperbole prove your point.
I wonder if Microsoft is really just an elaborate scheme to gain control of the grammar!
Each claim is independent of the others, but they
are written from absurdly general to excruciatingly
specific, so that in court the barratrist can
apply the broadest claims that the court will
countenance. Making a very specific claim does not
in any way mitigate the breadth of the most general
claim made in a given patent.
Yup. And I'm the guy who pounds them, with my
little hammer.
I knew someone would catch on one day. I guess my
monopoly position is shot now.
Ok, all you westerners look alike to me, but this guy doesn't dress like an African.
Then try going to the NYT to get the scoop on Dimona
or the JFK assassination or Lyndon LaRouche.
The real-world apps demonstrate that the 5% of die space spent on HT doesn't result in much more leveraging of the execution core, in practice. I can't imagine why anyone would care what the P4 numbers were without HT, since no one will ever run it that way now that OSen are supporting it.
As regards FreeBSD's kernel threads, the answer is "not really" since the overwhelming bulk of the benchmarks was spent in userspace (less so for the compile benchmarks than for the crypto ones). Notice that the user time numbers favored the Athlon64 no less than did the wall time numbers.
I think it's interesting that the synthetic benchmarks all favored the P4 (a highly academic design) while the user load tests all favored the 64.
It's a popular Senior or Graduate physics exercise to design experiments demonstrating GTR -- and a somewhat more ambitious exercise to perform them. This one is notably primarily for being bloody expensive and having blown it's schedule by such a honking big margin.
"J'anus". How refreshingly frank. And Frankish!
Already done.
> It's hard and you never get it right the first time.
The latter is true, the former is not. Yes, I've designed and implemented, in solo and in teams, numerous UIs which were released into the public marketplace, and fulfilled their functions quite well. If your criterion of success is that it is perfect for all users, regardless of culture or literacy or gender or sheer bloody-mindedness, they were all failures, but the existence of whinging complaints is not, in my view, an indicator that a UI design was not successful.
The main reasons why UI designs fail are that either (1) the designer assumes too much insight in the user base or (2) the designer lacks insight herself. The former is due to the character flaw of arrogance endemic among the intelligent, and the latter is due to the character flaw of laziness endemic among the unintelligent. Hence my conclusion: Any morally decent individual with a bare modicum of technical skill can do a UI quite well, if they have a smidgin of understanding of the application domain and are willing/empowered to do basic usability studies.
Now the coincidence of those four factors may be so rare as to make well-executed UI designs seem like hens teeth, but its not because they are hard to make. It is because the circumstances which conspire against them are so overwhelming.
> HTTP sucks for file transfers, frankly. You need a full-fledged web-browser just to view the index of files on an HTTP server.
Pfft. It's trivial to recognize the URLs (libwww:HTParse).
> # handling authentication.
mod_auth_mysql, mod_auth_ldap, mod_auth_...
Vastly more configurable and utile than any FTP server I've ever seen, Apache runs on every popular web server platform.
# handling sessions.
Why would you care?
# keeping statistics
The number and range and functionality of even the *free* tools to convert Apache logs into reports boggles the mind.
# limiting connections
mod_throttle
# communicating error messages
HTTP's error system is essentially a somewhat more mature clone of that used in FTP.
I haven't seen you make any actual, valid points here.
He's got the "UI is spooky" meme stuck in his cranium. It's distorting his view. This view holds that while coding device drivers or application logic is easy because its math, UI is spooky because it's human, and that requires a cognitive psychology doctorate and an MFA to do right. This is, of course, bullshit, so it's not surprising that he is mislead into drawing erroneous conclusions and basing his critical reply to
ESR on those errors.
In fact, UI is not hard anymore (since we don't have to use the Xt object model, the most overengineered piece of object-oriented crap that ever came out of an ivory tower). Instead we have simple UIs and simple object -event models like KDE's components and QT's slots to hide the complexity (most of the time), and vastly more examples of consistent and market-persistent UI designs since back in the day, making UI design and implementation so dead simple the bulk of the time that any barely or even not quite competent coder is without excuse.
No, ESR hit the nail on the head this time. (Even a broken clock is right twice a day?) The upshot is that CUPS is one of the least well-integrated systems on the modern Linux workstation desktop, and it's a real burden on the viability of further popularizing the platform. But fixing it would not be hard. What is hard, and what ESR is addressing, is the more important problem of fixing the underlying cause, which is endemic: Development-centricity so all-consuming that the most gracious and diligent contributors to the public good will overlook the most elementary aspects of the public use of their software.
You misspelled HTTP(S).
HTTP does all that. There are well-defined
and well-implemented (Squid) cache-tree protocols
for HTTP. This is very old stuff. FTP is just
plain obsolete. It ads *zero* value over HTTP,
and it's harder to use. Trying to bring FTP up
to the standards of HTTP is a futile effort too,
since HTTP is mature on many more dimensions,
and does not suffer from the gross defects of
the more primitive FTP such as transmission of
port numbers as stream data.