Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2007

Tip: Looking for answers? Try searching our database.

Detecting CPUs and cores

Thread view: 
Chris - 30 Jul 2007 19:25 GMT
Is there any way for Java to detect the number of CPUs that are
available? Runtime.getRuntime().availableProcessors() returns the number
of cores, not CPUs.
Joshua Cranmer - 30 Jul 2007 21:59 GMT
> Is there any way for Java to detect the number of CPUs that are
> available? Runtime.getRuntime().availableProcessors() returns the number
> of cores, not CPUs.

I don't think that is possible. The only OS I have experience with is
Windows, and that treats a dual-core as two CPUs; I believe that *nix
systems do the same as well.
Daniel Dyer - 30 Jul 2007 22:56 GMT
>> Is there any way for Java to detect the number of CPUs that are
>> available? Runtime.getRuntime().availableProcessors() returns the number
[quoted text clipped - 3 lines]
> Windows, and that treats a dual-core as two CPUs; I believe that *nix
> systems do the same as well.

I think that's reasonable behaviour.  My dual-core Mac does the same under  
OS X.

What's slightly less helpful is that my Windows PC at work returns 2 from  
availableProcessors() despite the fact that it is single-core, albeit with  
Intel's Hyper-Threading.

Finding out any more about the processors is probably going to require  
some JNI.

Dan.

Signature

Daniel Dyer
http//www.uncommons.org

Lew - 31 Jul 2007 02:20 GMT
> What's slightly less helpful is that my Windows PC at work returns 2
> from availableProcessors() despite the fact that it is single-core,
> albeit with Intel's Hyper-Threading.

That's not Window's nor Java's fault.  The HT processor is electrically
equivalent to two CPUs to the rest of the system.  So are multi-core CPUs.

Here's the $64,000 question - what is the value of knowing the number of dies
on which the cores reside?  A "core" /is/ a CPU as far as any practical use of
it goes; same for the two virtual cores seen in a HyperThreaded processor.
You program them in every respect as if they were completely separate; the
fact that they happen to share some real estate couldn't be less relevant.

A difference that makes no difference is no difference.

Signature

Lew

Eric Sosman - 31 Jul 2007 03:07 GMT
>> What's slightly less helpful is that my Windows PC at work returns 2
>> from availableProcessors() despite the fact that it is single-core,
[quoted text clipped - 11 lines]
>
> A difference that makes no difference is no difference.

    Well, yes: But it *does* make a difference.  The difference
doesn't arise from the die layouts per se, but from attributes
that tend to go along with them.  The cores may share resources
in ways that interfere and make their "computational power" non-
additive.  Intel's hyperthreaded chips, for example, share a
single execution unit and a single path to memory; only one "CPU"
at a time can initiate an operation on either resource.  Similar
remarks apply to Sun's T1 processor; the thirty-two "strands"
share eight execution units, one on-chip cache, and one floating-
point unit, but multiplex across four memory channels.

    The differences make a difference -- but taking proper account
of them is far more involved than simply counting cores or chips.
You need to get into the architecture of what's shared and what
isn't, which components can run in parallel and to what degree,
and so on.  This is well outside the scope of what cross-platform
Java is equipped to handle; one would need a lot of supplementary
information to make sense out of whatever number one obtained.

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Lew - 31 Jul 2007 03:58 GMT
Lew wrote:
>> A difference that makes no difference is no difference.

>     Well, yes: But it *does* make a difference.  The difference
> doesn't arise from the die layouts per se, but from attributes
[quoted text clipped - 14 lines]
> Java is equipped to handle; one would need a lot of supplementary
> information to make sense out of whatever number one obtained.

Given that I was speaking from the parochial point of view of being a
comp.lang.java.programmer, we are in agreement.

In Java terms, it makes no difference.  The Intel HT is able to interleave
execution between its two virtual "cores" in its single actual core because of
its architecture; it actually achieves speedup from the parallelism.  As a
Java programmer, one is divorced from the details of the "actual" differences
that you describe.  As a Java programmer, the difference(s) make no
difference.  Therefore as a Java programmer there really is no (useful)
difference between the multi-core imitation that an Intel HT gives, the actual
multi-core of an X2, or the separate die CPUs of a two-way Xeon motherboard.

Of course I realize that in some universe there are differences between these
that matter; that is the Zen of the pithy maxim that I offered.  So let's
recast that cute little poster saying in order to maximize satori,

"When does the difference make a difference?"

Signature

Lew

Patricia Shanahan - 31 Jul 2007 05:35 GMT
...
>     The differences make a difference -- but taking proper account
> of them is far more involved than simply counting cores or chips.
[quoted text clipped - 3 lines]
> Java is equipped to handle; one would need a lot of supplementary
> information to make sense out of whatever number one obtained.

A programmer may have determined experimentally that two threads running
on different cores get significantly more throughput than one, but that
the same two threads running hyper-threaded get less throughput than
one. The program is written so that the number of threads is a free
parameter.

The program should limit the number of threads to be no more than the
number of cores, but cannot because it cannot tell the difference
between two separate cores and a single hyper-threaded core.

Patricia
Twisted - 31 Jul 2007 06:08 GMT
> ...
>
[quoted text clipped - 15 lines]
> number of cores, but cannot because it cannot tell the difference
> between two separate cores and a single hyper-threaded core.

Actually, it's the responsibility of the OS (or maybe the VM) to
schedule threads in such a way as to maximize throughput, modulo
thread-priority semantics anyway.
Patricia Shanahan - 31 Jul 2007 06:19 GMT
>> ...
>>
[quoted text clipped - 18 lines]
> schedule threads in such a way as to maximize throughput, modulo
> thread-priority semantics anyway.

It would be wonderful if the OS could ensure that increasing the number
of threads, within the limit of the number of hardware threads, never
makes performance worse. Unfortunately, the CPU dispatcher faces a
couple of problems:

1. It also has to ensure that all threads make some progress. If it does
not, it may be hanging a thread that should interact with a human being
or another system.

In the 1970's, I would kick a thread out for seconds to minutes at a
time to ensure that the jobs I was running had all the memory they
needed to run with minimal paging, but that was on batch systems.

2. It is often not obvious whether time is being wasted or not, when it
comes to overloaded caches, branch predictors etc.. The programmer can
measure real throughput, in transactions per second or equivalent. The
dispatcher can only measure how much CPU time it is giving a thread, not
the effectiveness of that CPU time.

Patricia
Twisted - 31 Jul 2007 06:25 GMT
> 2. It is often not obvious whether time is being wasted or not, when it
> comes to overloaded caches, branch predictors etc.. The programmer can
> measure real throughput, in transactions per second or equivalent. The
> dispatcher can only measure how much CPU time it is giving a thread, not
> the effectiveness of that CPU time.

Really? It can't, by some law of mathematics, actually briefly run the
threads separately, then simultaneously, and see how fast their
program counters advance?

Anyway, if it's ever the case that running two threads concurrently on
HT is slower than running them sequentially on HT (as in it actually
takes longer clock time for both to finish), it sounds like evidence
that the hardware implementation of HT in that case is woefully broken
and perhaps that it was misdesigned, or even that HT as a whole is a
poor cousin of true dual-core processors. In which case poor HT
performance is really a hardware problem and again not the software
developer's responsibility to fix.
Joshua Cranmer - 31 Jul 2007 22:31 GMT
> Really? It can't, by some law of mathematics, actually briefly run the
> threads separately, then simultaneously, and see how fast their program
> counters advance?

Take two programs:
Program A:
     mov ecx, 10000
head: add eax, [ebx+ecx]
     loop head

Program B:
0xb7023480: <<operations with huge cache miss rate>>
     ...
     jmp far 0xb8023480

Program A would be doing useful work (presumably) yet only advance its PC
by a few bytes wheras Program B has advanced it by several MBs without
doing anything.

I don't know of any way to access the actual number of instructions
executed (it doesn't seem to have much of a use to me), so any heuristic
to measure usefulness would probably end up taking more time to compute
than savings generated.
Eric Sosman - 31 Jul 2007 23:28 GMT
> [...]
> I don't know of any way to access the actual number of instructions
> executed (it doesn't seem to have much of a use to me), so any heuristic
> to measure usefulness would probably end up taking more time to compute
> than savings generated.

    Some CPUs (all UltraSPARCs for sure, at least some models
from Intel and AMD, probably Power) have counters that increment
on assorted low-level events: instruction issue or retirement,
branch prediction failure, various kinds of cache misses, and so
on.  Exactly what gets counted and how you get access to the
count(s) is highly model-dependent, but it's certainly not out of
the question to find out how many instructions a thread executed
during its time on a CPU.

    ... but that still doesn't tell you what you want, which is
the thread's rate of "progress."  For example, a thread spinning
on a spin-lock is executing instructions at a pretty good clip
(excellent locality in both the instruction and data streams), but
is making no "progress" whatsoever.

    A slightly different but related (and possibly apocryphal)
story tells of a computer company that did a lot of instruction
tracing on their machines.  Then they designed a new chip to
run the traced instruction sequences just as fast as possible --
but despite all this optimization, the new chip seemed to be no
faster (maybe a touch slower) than the old one.  Then it dawned:
A CPU spends the huge majority of its time in the idle loop, which
their new chip executed at breathtaking speed ...

    Instruction execution need not equate to "progress."

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Lew - 31 Jul 2007 12:05 GMT
> A programmer may have determined experimentally that two threads running
> on different cores get significantly more throughput than one, but that
[quoted text clipped - 5 lines]
> number of cores, but cannot because it cannot tell the difference
> between two separate cores and a single hyper-threaded core.

It is likely that the two hyper-threaded cores will achieve more throughput
than on one of those "cores".  The reason Intel provided hyperthreading is
that it increases throughput on the chip.

Signature

Lew

Daniel Dyer - 31 Jul 2007 12:18 GMT
>> A programmer may have determined experimentally that two threads running
>> on different cores get significantly more throughput than one, but that
[quoted text clipped - 8 lines]
> throughput than on one of those "cores".  The reason Intel provided  
> hyperthreading is that it increases throughput on the chip.

That's the theory, but it's less clear cut than with a "proper" dual core  
chip.  There is anecdotal evidence of people turning *off* Hyper-Threading  
in the BIOS to improve the performance of their applications.

http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm
http://www.javalobby.org/java/forums/t54590.html

I haven't personally benchmarked the effect of Hyper-Threading but, if  
your application is relying on the result of availableProcessors() to fine  
tune it's concurrency strategy, it's important to be aware that 1 HT CPU  
may behave quite differently from 1 dual-core CPU.

Dan.

Signature

Daniel Dyer
http://www.uncommons.org

Lew - 31 Jul 2007 13:04 GMT
Lew wrote:
>> It is likely that the two hyper-threaded cores will achieve more
>> throughput than on one of those "cores".  The reason Intel provided
>> hyperthreading is that it increases throughput on the chip.

> That's the theory, but it's less clear cut than with a "proper" dual
> core chip.  There is anecdotal evidence of people turning *off*
[quoted text clipped - 8 lines]
> fine tune it's concurrency strategy, it's important to be aware that 1
> HT CPU may behave quite differently from 1 dual-core CPU.

There is evidence that multiple CPUs can reduce throughput relative to a
single CPU, too.  It depends on the software.

I am not arguing that HyperThread is as effective as multiple cores.  In fact,
HT is a hack devised by Intel to counteract excessive pipeline stalling, so it
stands to reason that its performance would differ perhaps significantly from
true multiple-CPU scenarios.  The trick is to discern when the number of CPUs
reported by Java is a reliable number and when it isn't.

My point is that most times to the Java world it doesn't matter.  You use the
number as reported.  Like every performance issue, especially in Java, it is
nigh impossible to make /a priori/ judgments about the impact this will have,
especially cross-platform /a priori/ judgments.  So unless we decide in a
particular case that the difference makes a difference, we pretend that it is
no difference.  To the JVM, a HT (with both "cores" enabled) acts like two
CPUs, smells like two CPUs, quacks like two CPUs, so we pretend that it is two
CPUs.

Performance optimization comes after the fact.

Signature

Lew

Eric Sosman - 31 Jul 2007 13:31 GMT
>> It is likely that the two hyper-threaded cores will achieve more
>> throughput than on one of those "cores".  The reason Intel provided
[quoted text clipped - 4 lines]
> Hyper-Threading in the BIOS to improve the performance of their
> applications.

    One computer company (no, not the one I work for -- not
to my knowledge, anyhow) has published benchmarks in which it
disabled one of the two cores on each dual-core chip, getting
better throughput by reducing competition for the on-chip cache.

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Arne Vajhøj - 12 Aug 2007 04:13 GMT
> That's the theory, but it's less clear cut than with a "proper" dual
> core chip.  There is anecdotal evidence of people turning *off*
[quoted text clipped - 3 lines]
> http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm
> http://www.javalobby.org/java/forums/t54590.html

I think the "turn of HT" idea is still widely used, but without
any foundation.

It is very easy to make tests that show up to 30% effect of HT
on multithreaded Java apps.

I seem to recall that when HT first came out there were indeed
a problem with current SUN JVM where it gave sligtly worse
performance due to cache issues but it was fixed in the next
release (which must have been 1.4.something).

But I can not find the article via Google. And a quick test
with SUN Java 1.2.2, 1.3.1, 1.4.2 and 1.5.0 did not find the
problem.

But I will strongly recommend people to turn on HT today.

Arne
Patricia Shanahan - 31 Jul 2007 14:29 GMT
>> A programmer may have determined experimentally that two threads running
>> on different cores get significantly more throughput than one, but that
[quoted text clipped - 9 lines]
> throughput than on one of those "cores".  The reason Intel provided
> hyperthreading is that it increases throughput on the chip.

On average. For typical threads, especially threads that appear in the
benchmarks that they simulate during processor design.

Patricia
Twisted - 31 Jul 2007 06:06 GMT
>      The differences make a difference -- but taking proper account
> of them is far more involved than simply counting cores or chips.

There is no real "taking proper account of them" for the programmer to
do, other than that to get maximum use you need to have at least as
many concurrent threads of program as there are cores/hyperthreads/
whatever. In otherwords, at least the number returned by
availableProcessors().

Optimizations for the details of the specific hardware architecture's
details are for the JIT.

Only JVM coders need concern themselves with these.
Roedy Green - 31 Jul 2007 12:38 GMT
>taking proper account of them is far more involved than simply counting cores or chips.
That is one aspect of a bigger problem, tweaking an app to run most
efficiently on different machines. There are various parameters you
intensive algorithms.  There is no one size fits all.
See http://mindprod.com/jgloss/tweakable.html and
http://mindprod.com/project/tweakable.html
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

David Gourley - 31 Jul 2007 20:50 GMT
> Here's the $64,000 question - what is the value of knowing the number of
> dies on which the cores reside?  

Some 3rd party software vendors are now licensing software based on
number of sockets instead of number of cores....

which may mean that to comply software has to perform a socket check.

Dave
Twisted - 31 Jul 2007 21:10 GMT
On Jul 31, 3:50 pm, David Gourley <d...@NOSPAM.gourley.plus.com>
wrote:

> > Here's the $64,000 question - what is the value of knowing the number of
> > dies on which the cores reside?
[quoted text clipped - 3 lines]
>
> which may mean that to comply software has to perform a socket check.

This sort of brain-dead artificial scarcity enforcement deserves to
fail. It doesn't even cost the vendor proportionately to the number of
users or installed copies, let alone the number of dies, cores,
sockets, or hyperthreads. Why in Christ's name do they feel justified
in making the price so proportional then? Even copyright law provides
no legal or rational basis for charging proportionally to anything but
installed copies or perhaps copies in concurrent use. Even supposing
multi-CPU (but not single dual-core CPU?!) systems spawned two
transient copies during execution in place of one, such transient
copies as are made during normal use of the software are legit as per
17 USC section 117(a)(1) and do not require separate permission from
(or payment to) the copyright holder. One legitimately purchased and
installed copy can be used as the user sees fit as per first sale
doctrine; they only infringe if they install more copies or install
and keep but sell the original media or something.

The only (flimsy) legal justification these companies can muster is
some dialog-box text they claim somehow constitutes a legally binding
contract between the user and the vendor that supersedes all existing
tacit agreements made through the process of purchasing a copy from
the retail outlet as well as all state and federal law governing
retail sales and copyright, supposedly enforceable despite the vendor
having no signed document to that effect as evidence of such an
agreement having been made, and despite being a contract of adhesion
even if so.

As for moral justification for why they deserve to be paid for every
separate CPU chip it runs on ... well they have none of course. That's
just pure unadulterated greed.
Roedy Green - 31 Jul 2007 21:35 GMT
On Tue, 31 Jul 2007 20:50:18 +0100, David Gourley
<dave@NOSPAM.gourley.plus.com> wrote, quoted or indirectly quoted
someone who said :

>which may mean that to comply software has to perform a socket check.

with JNI you can get the CPU model number.  You can create a database
of information about various models. The problem is, the list is
enormous.

my little JNI utility can extract the following information.

cpuIdVendor:AuthenticAMD
cpuIdBrand:AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
cpuIdStep:2
cpuIdModel:11
cpuIdFamily:11
cpuSerNo:0
rdtsc:51095894167442

If you have docs on how to extract other info, I would be glad to add
it.  It comes with source, intended to be used in your own code.
see http://mindprod.com/products1.html#PENTIUM

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Lew - 01 Aug 2007 00:27 GMT
>> Here's the $64,000 question - what is the value of knowing the number
>> of dies on which the cores reside?  
[quoted text clipped - 3 lines]
>
> which may mean that to comply software has to perform a socket check.

Are they doing this with Java software?

I know that some Java partisans think it's the everything language, but that
sort of thing seems much more like systems programming than "write once, run
anywhere"-land.  In any event, they couldn't use Java directly in a
cross-platform way to do that license check; they have to be relying on JNI or
some other platform-specific means to get this information.

Please understand that here in clj.programmer I am asking such $64K-questions
in a Java-centric way.  I never denied that knowing this type of information
is useful, I only question how useful in a Java-oriented, cross-platform context.

As to whether this licensing approach works "better" than by the less
customer-friendly core count, the more friendly server count, or the commonly
offered concurrent usage count, what Everrr!  Companies are simply seeking a
reasonable metric of usage volume on which to base pricing, as is their right.
 One could argue in favor of various metrics, but they're all negotiable
anyway.  Their purpose is merely to give vendor and buyer a common language
for the negotiation, is all.  As long as the terms are (intelligibly)
disclosed negotiations can proceed in good faith.

Signature

Lew

Twisted - 01 Aug 2007 00:55 GMT
> Companies are simply seeking a
> reasonable metric of usage volume on which to base pricing, as is their right.

I don't know where you get this from. It makes sense for the electric
company, whose costs grow in proportion to clients' usage. But a
software vendor? The one cost that might grow in proportion to client
usage is support, and charging by the hour or by the incident for
support makes a lot more sense than charging by software usage; for
example a client better able to manage their installations without
outside help is rewarded with lower support costs in the one case but
not the other.

There's also nothing in copyright law to support metering usage in any
way other than "per install". We don't see differential pricing of
books based on usage. Charging extra to use the same software on a
dual-core machine is about as logical per copyright and other laws as
offering books with a 50% discount for one-eyed people. :P

>   One could argue in favor of various metrics, but they're all negotiable
> anyway.  Their purpose is merely to give vendor and buyer a common language
> for the negotiation, is all.  As long as the terms are (intelligibly)
> disclosed negotiations can proceed in good faith.

WHAT negotiations? Have you ever actually been able to negotiate EULA
terms with a software vendor instead of just having their one-sided
legalese fun-fest shoved in your face by a popup? I sure haven't.
Lew - 01 Aug 2007 01:00 GMT
> WHAT negotiations? Have you ever actually been able to negotiate EULA
> terms with a software vendor instead of just having their one-sided
> legalese fun-fest shoved in your face by a popup? I sure haven't.

Yes.

Signature

Lew

Twisted - 01 Aug 2007 01:07 GMT
> > WHAT negotiations? Have you ever actually been able to negotiate EULA
> > terms with a software vendor instead of just having their one-sided
> > legalese fun-fest shoved in your face by a popup? I sure haven't.
>
> Yes.

Well lucky you. Too bad your experience is highly nonrepresentative
and thus of no help to the vast majority of software users out there.

Personally, not only am I sticking as much as possible to free
software in the future, but I'm also absolutely refusing to ever spend
a dime on any software that requires I pay extra to run it on a dual-
core machine. Artificial scarcity is simply getting ludicrous. Next
they'll try outright metering usage like it was a rental ... or like
AOL used to do with every single bit of distinct functionality. We all
know what happened there: cheap, low-cost, priced-by-cost, commodity
internet access ate AOL alive. Software "rental" models will just
accelerate the demise of the traditional commercial software industry
as it gets chewed up and splinters of bone spat out by Gnu/FSF
offerings and the like. Microsoft is notably avoiding any talk of
rental models, probably because they just know that if Vista or
Windoze 7 or whatever was charged by the hour or some such bullsh!t,
it would be handing the desktop market to Linux on a silver platter.
(In the server market, they already did, and have been regretting it
ever since.)
Lasse Reichstein Nielsen - 01 Aug 2007 02:11 GMT
> I don't know where you get this from. It makes sense for the electric
> company, whose costs grow in proportion to clients' usage. But a
[quoted text clipped - 4 lines]
> outside help is rewarded with lower support costs in the one case but
> not the other.

You're missing the point. It's not whether it makes sense, but whether
you can get people to pay more.
The more hardware a company is willing to buy for the software
to run on, the more important the software appears to be, and the
more money the software seller can demand.

Perfectly logical, from a money making point of view :)

/L
Signature

Lasse Reichstein Nielsen  -  lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
 'Faith without judgement merely degrades the spirit divine.'

Twisted - 01 Aug 2007 02:55 GMT
> > I don't know where you get this from. It makes sense for the electric
> > company, whose costs grow in proportion to clients' usage. But a
[quoted text clipped - 6 lines]
>
> You're missing the point.

No, I am not.

> It's not whether it makes sense, but whether you can get people to pay more.

In a proper, competitive market, you can't get people to pay much more
than your expenses, because if you try a competitor can easily
undercut your price while still operating at a profit.

Obviously, anywhere where software is being charged for by this sort
of extortionate scheme the market is insufficiently competitive, which
is not at all good for the consumer.

> Perfectly logical, from a money making point of view :)

But not from a consumer rights point of view. It's high time
government stopped aiding and abetting corporations ripping off
consumers and returned to representing "we, the people". A good start
might be to strike down the legal artifice whereby corporations are
treated as a form of artificial "person". Don't let them be campaign
donors (just their employees and stockholders as individuals -- and
even then, don't let them donate to more than one party in a given
election cycle). Don't treat them as having any rights. Most
importantly, don't represent them. Represent only the actual people,
individual human beings that are capable of suffering in poverty or
dying or whatnot. The worst that can ever happen to a corporation is
bankruptcy, and given that it happens in a decent industrialized and
progressive democracy this doesn't kill the employees, just send them
looking for new work, which they should easily find if they have any
skills or talent that remain in demand.

Corporations have no special rights, particularly no right to exist or
to turn a net profit. Giving them such rights takes away from we, the
people. Corporations have their place in a society built on
competitive markets and free people with freedom of transaction. Let's
put them back in their place.
Arne Vajhøj - 04 Aug 2007 03:02 GMT
> In a proper, competitive market, you can't get people to pay much more
> than your expenses, because if you try a competitor can easily
> undercut your price while still operating at a profit.

Note that expenses in this context includes "normal profit".

Arne
Twisted - 04 Aug 2007 04:20 GMT
On Aug 3, 10:02 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
> > In a proper, competitive market, you can't get people to pay much more
> > than your expenses, because if you try a competitor can easily
> > undercut your price while still operating at a profit.
>
> Note that expenses in this context includes "normal profit".

If by that you mean "a thin margin on top of parts, labour, shipping,
and handling" then fine. Keep in mind that the "labour" already
included is where all the salaries come from. A tough, competitive
market should keep any of those from being out of whack (such as the
CEO's) ideally as well.
Joshua Cranmer - 04 Aug 2007 15:43 GMT
>> > In a proper, competitive market, you can't get people to pay much
>> > more than your expenses, because if you try a competitor can easily
[quoted text clipped - 7 lines]
> keep any of those from being out of whack (such as the CEO's) ideally as
> well.

No, I think that she means "profits equal to that which would be
generated by the normal rate of return," which makes more sense since you
should put your money elsewhere if it can't get you the normal rate of
return.
Patricia Shanahan - 04 Aug 2007 16:02 GMT
>> On Aug 3, 10:02 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>>> In a proper, competitive market, you can't get people to pay much
[quoted text clipped - 11 lines]
> should put your money elsewhere if it can't get you the normal rate of
> return.

It's also important to take into account the timing of expenses.
Typically, the costs for software are heavily front-loaded. It may be
necessary to employ many programmers for several years before gaining
much return.

The money paid to those programmers, and associated costs (office space,
workstations, unlimited free drip coffee, administration expenses,
benefits...), could have been invested elsewhere from the time it is
paid until the time it is recouped from the revenue stream.

The degree if risk also affects what is a "normal" rate of return.

At one extreme, government bonds for established, stable countries have
low risk but low rate of return. At the other extreme, venture capital
companies expect that many of their investments will fail, and need a
very high return from each of the few successes to cover those losses.

Software tends to be a high risk business, more like venture capital
than stable government bonds.

Patricia
Twisted - 05 Aug 2007 19:38 GMT
> The money paid to those programmers, and associated costs (office space,
> workstations, unlimited free drip coffee, administration expenses,
> benefits...)

Workstations are reusable, you know. Or do you mean the electricity
costs from running them, and suchlike?

> Software tends to be a high risk business, more like venture capital
> than stable government bonds.

An odd claim, given that the costs can clearly be made virtually zero,
as evidenced by the sheer quantity of software that is generated by
hobbyists, or as part of the free software movement, etc.; the barrier
to entry and minimal costs given reasonable efficiency are quite low.
I wonder if the high costs you cite are peculiar to the development
environment of commercial software houses, where the coders have
clueless managers looking over their shoulders constantly (and the
managers themselves demand ludicrously high salaries given they don't
do anything that resembles anything that I'd call "work"), and they
are made to go to an expensive, inefficiently heated and cooled,
inefficiently lit office building to work instead of permitted to do
it on their home computer, and ... etc. etc.; open source is often
vastly more efficient it seems, where the "managers" giving
requirements information and feedback to the developers are the users
themselves, and the developers can use their existing floor space and
equipment, etc. so there's no big expensive tower full of cubicles; no
manager salaries; with no attempts at claiming proprietary "IP" and
other such BS there's no lawyers to pay; there's just the coding and
the distribution of copies. It's clearly vastly more efficient. It's
no wonder Linux and OpenOffice are starting to seriously threaten
Microsoft, if Microsoft's development and delivery are inherently
inferior and inefficient!
Patricia Shanahan - 05 Aug 2007 20:15 GMT
>> The money paid to those programmers, and associated costs (office space,
>> workstations, unlimited free drip coffee, administration expenses,
>> benefits...)
>
> Workstations are reusable, you know. Or do you mean the electricity
> costs from running them, and suchlike?

No, I mean the cost of owning or leasing the workstation for the
duration of the software development. If I were to try to sell, now, a
computer that cost $1,000 a couple of years ago, I would get a lot
less than $1,000 for it. If I had invested the money two years ago in US
Government bonds scheduled to mature today, I would get more than $1,000
back.

That difference combines two forms of cost, the depreciation on the
workstation and the opportunity cost of the capital used to purchase it.

If I leased the workstation the company I leased it from would have made
similar calculations, and those costs would have been included in their
charges.

Patricia
nebulous99@gmail.com - 05 Aug 2007 21:07 GMT
> >> The money paid to those programmers, and associated costs (office space,
> >> workstations, unlimited free drip coffee, administration expenses,
[quoted text clipped - 9 lines]
> Government bonds scheduled to mature today, I would get more than $1,000
> back.

[snip rest]

A strange attitude. Might be the result of renting your hardware
instead of buying it. You could just buy it and then develop as much
software on it as you pleased. A common off the shelf home computer
that's a few years old (but no more) is perfectly adequate to run
Eclipse and whatever other development tools you need. Of course,
anything you develop that has steeper system requirements will require
a different testing machine.

Another place where FOSS development seems to get superior efficiency.
It gets developed with hardware that's generally "free", in that it's
a sunk cost purchased for other reasons, and tested on same, and even
more, on the end-users' machines. FOSS development basically doesn't
involve any hardware expenses that are purely for the purpose of the
FOSS development.
Patricia Shanahan - 05 Aug 2007 21:12 GMT
>>>> The money paid to those programmers, and associated costs (office space,
>>>> workstations, unlimited free drip coffee, administration expenses,
[quoted text clipped - 17 lines]
> anything you develop that has steeper system requirements will require
> a different testing machine.

That just changes the amount of money per workstation, not the fact that
computers depreciate with time or that invested money increases in value
with time.

Patricia
nebulous99@gmail.com - 05 Aug 2007 21:21 GMT
> That just changes the amount of money per workstation, not the fact that
> computers depreciate with time or that invested money increases in value
> with time.

It makes the ongoing costs of the development workstations only what's
needed to keep them in operating condition, since you need never
replace them.

I notice you don't address my remarks about how FOSS seems to develop
far more efficiently, with those front-loaded costs vastly lower per
unit of functionality than commercial software development.
Patricia Shanahan - 05 Aug 2007 21:35 GMT
>> That just changes the amount of money per workstation, not the fact that
>> computers depreciate with time or that invested money increases in value
[quoted text clipped - 3 lines]
> needed to keep them in operating condition, since you need never
> replace them.

But you still paid for them up front, losing the money you paid for them.

> I notice you don't address my remarks about how FOSS seems to develop
> far more efficiently, with those front-loaded costs vastly lower per
> unit of functionality than commercial software development.

If there happens to be free software that meets all your needs and has
acceptable licensing terms you should definitely use it.

The difficult case is when there is no free software that does the job,
and too few people, relative to the size of the program, feel like
developing it for fun. That is when software starts costing money, as
you are dealing with programmers who insist on being paid to do that
task, and provided with office space, equipment, etc.

Patricia
Bent C Dalager - 06 Aug 2007 09:08 GMT
>> I notice you don't address my remarks about how FOSS seems to develop
>> far more efficiently, with those front-loaded costs vastly lower per
[quoted text clipped - 6 lines]
>and too few people, relative to the size of the program, feel like
>developing it for fun.

The vast majority of such requirements are met by in-house development
projects, for which licensing issues are a moot point. The costs are
covered by revenues from the company's main business.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Joshua Cranmer - 06 Aug 2007 23:46 GMT
>> That just changes the amount of money per workstation, not the fact that
>> computers depreciate with time or that invested money increases in value
[quoted text clipped - 3 lines]
> needed to keep them in operating condition, since you need never
> replace them.

Under your guidelines, you would be saying that the ACME Company should
be using its vintage UNIVAC from the 1950's that is easily outclassed by
my TI-89. Even in more modern cases, replacement of workstations is
probably needed.

Take my laptop: it is (was at the time of this scenario) about 5 years
old. I wanted to upgrade to Windows XP (required for certain pieces of
software). Guess what? It has 64 MB of RAM, gotta go upgrade that! And
there's more: half of its hard drive is unusable due to corrupt sectors.
 (It has a damaged keyboard as well--the shift key came off). By that
time it becomes cheaper just to get a new computer.

If you continue to insist that workstations need never be replaced, then
tell me where to find a 1 GB stick of PC-133 MHz DDRAM (so that more
than 1.5GB of RAM can be supplied to a computer).

Signature

Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Twisted - 07 Aug 2007 17:16 GMT
> nebulou...@gmail.com wrote:
> >> That just changes the amount of money per workstation, not the fact that
[quoted text clipped - 6 lines]
>
> Under your guidelines...[snip]

URRGH! Will you stop ARGUING and just LISTEN? The people deserve
access to tools and commodities at prices not much elevated above the
marginal cost of providing them. End of story. Finito. You cannot
argue against that without being pro-monopolist and plutocratic, or
even communist, rather than true-capitalist.
Joshua Cranmer - 08 Aug 2007 02:26 GMT
> URRGH! Will you stop ARGUING and just LISTEN?

I am sure that many people would be happy to ask you do to that as well.

> The people deserve
> access to tools and commodities at prices not much elevated above the
> marginal cost of providing them. End of story. Finito. You cannot
> argue against that without being pro-monopolist and plutocratic, or
> even communist, rather than true-capitalist.

You can neither argue against that if you are pro-monopolist,
plutocratic, communist, or whatever. The term 'deserve' automatically
makes your argument an appeal to emotion and not a valid point because
it is a subjective and unquantifiable quality. Besides, the article
'the' is definite and therefore refers to a specified subset of people;
you have not given this subset.

I suppose, in retrospect, that one could define a utility metric that
measures how well-off people are and use that as a definition: "people
deserve X" would be equivalent to "the utility metric Z would be higher
if X were the case", but then the validity of utility metric Z itself
would be called into question. In any case, define your position in a
more verifiable way and then

In any case, a product selling for "little more" than the marginal cost
will not be found in the long term assuming that a given company will
take whatever measures it can to maximize profit, within bound of the
law. If it at any point in time it cannot make the normal rate of
return, the corporation will find that it can make more money by putting
its money elsewhere (like some safe T-bonds) and will withdraw from the
market. In the process, supply of said product will decrease, increasing
the equilibrium price. Aggregating the suppliers together means that the
price will equalize at the level needed to achieve normal rate of return.

Signature

Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Bent C Dalager - 08 Aug 2007 10:05 GMT
>In any case, a product selling for "little more" than the marginal cost
>will not be found in the long term assuming that a given company will
[quoted text clipped - 5 lines]
>the equilibrium price. Aggregating the suppliers together means that the
>price will equalize at the level needed to achieve normal rate of return.

In a truly competitive marketplace (as is generally considered
desirable in capitalistic theory), all products will see only a
miniscule profit on top of production/distribution cost. This is one
of the beauties of capitalism in that it provides useful, inexpensive
products compared to most - perhaps all - other economic models.

In such a market, however, it is difficult to make a huge profit and
become insanely wealthy. This is considered by many to be a problem.
There are some tried and true methods of circumventing this problem
however, including (but certainly not limited to):

* Becoming immensely huge so that even one cent per item turns into
millions on the bottom line. (E.g. Wal-mart)

* Sinking lots of investment money to get into an industry with high
barriers to entry. (E.g. cutting edge microchip manufaturing)

* Operating in a market with artificial government imposed
monopolies. (E.g. entertainment, software and general invention)

Twisted seems to be having a go at the latter and saying that these
industries should be forced to compete in a free market rather than
ride the government gravy train.

Cheers
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Twisted - 09 Aug 2007 00:35 GMT
> > URRGH! Will you stop ARGUING and just LISTEN?
>
> I am sure that many people would be happy to ask you do to that as well.

There's a big difference though. I'm right. You're wrong. Give it up
already!

[a bunch of nonsense snipped]

> I suppose, in retrospect, that one could define a utility metric that
> measures how well-off people are and use that as a definition: "people
> deserve X" would be equivalent to "the utility metric Z would be higher
> if X were the case"

That's basically the case, using freedom as the basis of the metric.
Maximizing it. The greatest self-determination for the greatest
number. I thought it was as obvious as the nose on my face that such a
metric is the basis for any rational determination of morals, ethics,
and public policy in a free and just society. Is it not?

> In any case, a product selling for "little more" than the marginal cost
> will not be found in the long term assuming that a given company will
> take whatever measures it can to maximize profit, within bound of the
> law. If it at any point in time it cannot make the normal rate of
> return

You're assuming that under the conditions in question (namely, all
markets are quite competitive) that the "normal rate of return" won't
be much lower than it is now.

You're also assuming that commodities would continue to be provided by
for-profit companies as a profit center. That is likely not the case.
Commodities would be provided by for-profit companies as a loss-leader
to drive sales of non-commodities, and commodities would also likely
be provided by non-profit entities that pay the salaries of their
workers and do compete (as the workers would rather not lose their
jobs) and also claim tax benefits relative to for-profit entities.

> In the process, supply of said product will decrease, increasing
> the equilibrium price. Aggregating the suppliers together means that the
> price will equalize at the level needed to achieve normal rate of return.

Ultimately, the normal rate of return would appear to influence
prices, but something surely influences the normal rate of return. I'd
speculate that dumping IP law and having the guy holding the "interest
rates" knob twist it fairly far to the left might do the job and
launch the next renaissance of human achievement and growth potential.
More likely, some alternate superefficient economy will arise and
leave the existing one eating dust. Possibly sentient machines, or
just automated point-trading systems resembling, and perhaps derived
from, the bandwidth allocation algorithms used by BitTorrent and its
ilk. There's always the next level up in competition -- the whole
system potentially encountering a competitor that might have superior
efficiency, and having to adapt to match, or die trying, or die for
lack of trying.

> Beware of bugs in the above code

Indeed. Your posts to this thread lately are full of them. :P
Joshua Cranmer - 09 Aug 2007 22:18 GMT
>> I suppose, in retrospect, that one could define a utility metric that
>> measures how well-off people are and use that as a definition: "people
[quoted text clipped - 6 lines]
> metric is the basis for any rational determination of morals, ethics,
> and public policy in a free and just society. Is it not?

Freedom is somewhat intangible; you still have not defined a utility
metric: a *number* that I can cull up from mashing economic statistics,
like U(X) = price of a Big Mac / time worked to create that Big Mac.

[Snip load of BS]

Wow, now I see why you like doing that!

>> In the process, supply of said product will decrease, increasing
>> the equilibrium price. Aggregating the suppliers together means that the
>> price will equalize at the level needed to achieve normal rate of return.
>
> Ultimately, the normal rate of return would appear to influence
> prices, but something surely influences the normal rate of return.

Am I denying that? No.

> I'd speculate that dumping IP law and having the guy holding the "interest
> rates" knob twist it fairly far to the left might do the job and
> launch the next renaissance of human achievement and growth potential.

It might also send inflation rates soaring above 10%.

>> Beware of bugs in the above code
>
> Indeed. Your posts to this thread lately are full of them. :P

How much code have I posted in this thread? Exactly 0 characters.
How many times have I quoted something yet mangled the context? Less
than you have.

Signature

Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Twisted - 09 Aug 2007 22:52 GMT
> Freedom is somewhat intangible, blah, blah, blah...

The truly important things often are. But an economic proxy could be
margins. Fat margins suggest lack of choice on the part of consumers.

> [Snip load of BS]

ExCUSE me? I do not post BS; you post BS, remember? :P

> > I'd speculate that dumping IP law and having the guy holding the "interest
> > rates" knob twist it fairly far to the left might do the job and
> > launch the next renaissance of human achievement and growth potential.
>
> It might also send inflation rates soaring above 10%.

And you came up with this figure how? The tried and true butt-trumpet
method perhaps? :P

> >> Beware of bugs in the above code
>
> > Indeed. Your posts to this thread lately are full of them. :P
>
> How much code have I posted in this thread? Exactly 0 characters.

Your Java code isn't where the bugs are, I'm afraid.

[accuses me of intentional misquoting]

ExCUSE me?

Apologize!
Joshua Cranmer - 04 Aug 2007 16:12 GMT
>>> Note that expenses in this context includes "normal profit".
>>
[quoted text clipped - 4 lines]
> you should put your money elsewhere if it can't get you the normal rate
> of return.

P.S. I am sorry if I got the gender wrong. I had assumed that Patricia
had made the earlier referent post, and in my speed, I forgot to verify
that fact. I humbly apologize.
Arne Vajhøj - 06 Aug 2007 00:27 GMT
>>>> Note that expenses in this context includes "normal profit".
>>> [...]
[quoted text clipped - 6 lines]
> had made the earlier referent post, and in my speed, I forgot to verify
> that fact. I humbly apologize.

No hard feelings.

Arne
Twisted - 05 Aug 2007 19:31 GMT
> "profits equal to that which would be generated by the normal rate of return,"

And what, precisely, is this "normal" rate of return? If it's more
than the bare minimum needed to keep the company afloat, then
something's inefficient and someone's probably getting ripped off,
including the consumers. If your total costs in providing me a foobar
would be $1, then charging much more than $1.05 or so for that foobar
seems excessive; you get to pocket a nickel, and consumers like me get
to have the foobar for roughly what it costs to provide one, and not
much more. Charge much more, and a) your competition can undercut your
price and still turn a profit, and b) consumers like me have to pay
much more for a foobar than what a foobar costs to provide, which is
unfair. People who can actually afford the marginal cost of a foobar
may nonetheless be denied access, without justification since they can
bear the cost of providing them one by hypothesis. Unfortunately, lack
of sufficient competition makes this all too common and results in the
poor having much less access to things than they should, given they
could pay the marginal costs; it artificially inflates the cost of
living which does nobody any good in the long run.

Of course, if you're like most of the posters here you make your money
selling non-commodity software at fat margins and hate the idea that
all useful tools should be available as commodities, even though such
would be vastly enabling to people and, in the longer term, vastly
increase the rate at which the economy generates wealth by lowering
costs and barriers-to-entry. Of course, lowering barriers to entry
also generates more competition, which as businessmen you'll all
really hate too...
Arne Vajhøj - 06 Aug 2007 00:27 GMT
>>> In a proper, competitive market, you can't get people to pay much more
>>> than your expenses, because if you try a competitor can easily
[quoted text clipped - 3 lines]
> If by that you mean "a thin margin on top of parts, labour, shipping,
> and handling" then fine.

No it is a profit equivalent what else profit you could have gotten.

If we go from macro economics to business, then consider it the
interest you could get from putting your money in a savings account
or invest in government bonds. If you business gives less profit than
those, then you will (at least if you are profit maximizing) put
the money in them.

Arne
Twisted - 06 Aug 2007 18:41 GMT
On Aug 5, 7:27 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
> > On Aug 3, 10:02 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
> >>> In a proper, competitive market, you can't get people to pay much more
[quoted text clipped - 12 lines]
> those, then you will (at least if you are profit maximizing) put
> the money in them.

Sounds like a more competitive economy would automatically have lower
interest rates then, as interest rates must themselves be tied to the
rate of return on investments. So the substantial amount of
uncompetitive monopoly rents that can be extracted right now raises
the rate of return on some things and makes every other business seek
to raise prices to keep up a similar rate of return, and ends up
raising interest rates and, presumably, causes inflation in the longer
term.

This suggests that ending all monopoly rents would cause some initial
upheavals, but eventually a low-inflation and low-interest but rapidly
innovating and wealth-generating economy.

Who stands to lose in such a situation, that they'd oppose (with overt
or covert machinations) such a development? Well, it looks like the
whole banking industry, as well as the actual monopolies...
Eric Sosman - 01 Aug 2007 02:19 GMT
>> Companies are simply seeking a
>> reasonable metric of usage volume on which to base pricing, as is their right.
[quoted text clipped - 4 lines]
> dual-core machine is about as logical per copyright and other laws as
> offering books with a 50% discount for one-eyed people. :P

    Hey, Twisted: This is *my* product, and *this* is how much
I want you to pay me to use it under *these* terms.  Nobody is
forcing you to accept my terms nor to pay my price -- but nobody
is forcing me to let you have my product on *your* terms and at
*your* price, either.  If you don't agree to my terms and don't
accept my price, then don't use my product: You have, by your
actions, shown that my product isn't worth that much to you, so
you must be willing to do without.  Go twist somewhere else:
twist and shout.

    You may think my pricing policies foolish, and you may even
be right -- but that doesn't diminish my right to indulge my
folly.  Who died and made you Pope?

>>   One could argue in favor of various metrics, but they're all negotiable
>> anyway.  Their purpose is merely to give vendor and buyer a common language
[quoted text clipped - 4 lines]
> terms with a software vendor instead of just having their one-sided
> legalese fun-fest shoved in your face by a popup? I sure haven't.

    Terms are always negotiable.  Negotiators approach the table
with different strengths and weaknesses, and it may happen that
your negotiating position is insufficiently strong to get Seer
to budge from theirs.  Well, what that means is that Seer is
charging more than you think the product is worth: You therefore
make a bad trade by trying to pursue the deal.  See what you
can do with Pregres or YourTRM instead -- or if you *really*
*really* need the Seer product, then admit that it's worth more
to you than you originally said.

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Twisted - 01 Aug 2007 02:58 GMT
>      Hey, Twisted: This is *my* product, and *this* is how much
> I want you to pay me to use it under *these* terms.  Nobody is
> forcing you to accept my terms nor to pay my price -- but nobody
> is forcing me to let you have my product on *your* terms and at
> *your* price, either.

The market would be forcing you if the market were doing its job.

> If you don't agree to my terms and don't accept my price, then
> don't use my product: You have, by your actions, shown that my
> product isn't worth that much to you, so you must be willing to
> do without.

I should have the choice of a more reasonably priced, nigh-identical
product, given that the price you're asking far exceeds the cost of
providing it. If I don't have that choice there is market failure.

>      You may think my pricing policies foolish, and you may even
> be right -- but that doesn't diminish my right to indulge my
> folly.  Who died and made you Pope?

The problem is if you can indulge your folly and not be eaten alive by
competitors with more reasonable, but still profitable, pricing. That
indicates market failure.

[snip a bunch of stuff including several unfamiliar names or
references that are not explained]
Eric Sosman - 01 Aug 2007 03:57 GMT
>>      Hey, Twisted: This is *my* product, and *this* is how much
>> I want you to pay me to use it under *these* terms.  Nobody is
[quoted text clipped - 3 lines]
>
> The market would be forcing you if the market were doing its job.

    *You* are the market.  And you can force me by walking
away from my putrid deal, in all your mighty millions.  I will
end up on the breadline, and cease to trouble you (except
now and then to beg for alms).  I repeat: *you* are the market:
flex your muscles or go sit in the corner.

>> If you don't agree to my terms and don't accept my price, then
>> don't use my product: You have, by your actions, shown that my
[quoted text clipped - 4 lines]
> product, given that the price you're asking far exceeds the cost of
> providing it. If I don't have that choice there is market failure.

    "Price" and "cost" are different things.  "Cost" is something
I as a manufacturer cannot avoid incurring (I do my level best to
keep it as low as possible, but whatever I cannot eliminate remains
"cost").  "Price" is what I ask and what you are willing to pay
(if you aren't willing to pay, then there's no transaction).  May
I ask a price lower than my cost?  (Ever heard of a "loss leader?")
If so, why may I not ask a higher price?  You are *always* free to
walk away and do without my overpriced junk.  Who's stopping you,
you big, muscular market?

>>      You may think my pricing policies foolish, and you may even
>> be right -- but that doesn't diminish my right to indulge my
[quoted text clipped - 3 lines]
> competitors with more reasonable, but still profitable, pricing. That
> indicates market failure.

    So I'm eaten alive -- I don't see evidence that you are
inconsolable.

> [snip a bunch of stuff including several unfamiliar names or
> references that are not explained]

    O-kay: let's take it very, ve-ry slowly.  Did you ever see
the movie "2001: A Space Odyssey?"  Do you remember the name of
the computer who/which was such an important character in that
movie?  "HAL," right?  "H," "A," "L."  Did you never notice --
or if not the not the noticing type, were you never told -- of
the interesting relationship between those three letters and
another set of three letters also related to computers?  I Bet My
socks you can figure it out, given time and a running start.  If
you ponder it long enough, maybe you'll also be able to unscramble
"YourTRM."

    "Seer" is a different kind of obfuscation, whose decipherment
requires something the initiates call "vocabulary."

    But none of these word games is important.  The point is
simply that if I offer to let you use my product in accordance
with terms T and for consideration of a payment P, but you think
T and P are out of line with my product's worth to you, then you
can try to talk me down.  If I am obstinate, you can just walk
away from the deal, having made a wise economic choice.  We are
both happy: You didn't pay more than my product was worth, I didn't
give in to your attempt to rob me -- two happy people; what's your
objection to that?

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Twisted - 01 Aug 2007 05:20 GMT
public final post EricRebuttal007 {

[snip]
>      "Price" and "cost" are different things.  "Cost" is something
> I as a manufacturer cannot avoid incurring (I do my level best to
> keep it as low as possible, but whatever I cannot eliminate remains
> "cost").

Are you intentionally missing the point? My point is that when there
is open competition in the marketplace, prices are driven down to
costs plus thin margins, rather than being hugely inflated above
costs. And therefore that if anyone is charging highly inflated prices
and not either going out of business or being forced to lower them by
market forces (their choice), the market is therefore failing to work
properly and furnish sufficient competition in that space. I want bugs
like that fixed. :P

>      "Seer" is a different kind of obfuscation, whose decipherment
> requires something the initiates call "vocabulary."

[and a bunch more stuff about obfuscation]

What the f.ck did you think that was, proprietary source code?

It was a usenet posting. The object of the game is to communicate
clearly and meaningfully. Intentional obfuscation is clearly a losing
strategy.

Then again, maybe I have misunderstood usenet. Sometimes it sure does
seem as if the object of the game is to aggravate, flame, and
generally disagree with everyone else without regard to reason or
logic, and particularly without any consideration of those pesky
things called facts. :P

>      But none of these word games is important.  The point is
> simply that if I offer to let you use my product in accordance
[quoted text clipped - 5 lines]
> give in to your attempt to rob me -- two happy people; what's your
> objection to that?

That the very fact that you are making the terms of your deal so
onerous proves that there is no alternative to walk away to.

Also, that you're violating copyright law, particularly the doctrine
of first sale, by attempting to tell me what I can and cannot do with
a copy after I've purchased it already. That's as illegal as if I were
to infringe the copyright by making and selling copies without your
permission.
Eric Sosman - 01 Aug 2007 17:58 GMT
Twisted wrote On 08/01/07 00:20,:
> [...]
> What the f.ck [...]

   Good-bye.

Signature

Eric.Sosman@sun.com

Twisted - 02 Aug 2007 01:30 GMT
>     Good-bye.

And nothing else.

I guess I'll take that as a capitulation.
Roedy Green - 05 Aug 2007 15:51 GMT
>> Companies are simply seeking a
>> reasonable metric of usage volume on which to base pricing, as is their right.
It makes sense to charge according to the VALUE a customer gets from
your product.  

It seems illogical to me that I pay the same for a program I hardly
ever use, and one I use continuously.  You need some sort of scheme to
share the cost pie of providing the service.  So long as the seller
has not wangled a monopoly position, he should be free to cook up any
scheme he pleases. The market place will punish the irritating
schemes..
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Twisted - 05 Aug 2007 19:43 GMT
On Aug 5, 10:51 am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> It seems illogical to me that I pay the same for a program I hardly
> ever use, and one I use continuously.

It seems illogical to me that I pay different amounts for things that
cost the same amount to provide to me; and it seems like a ripoff any
time someone insists that I pay vastly more for something than it
costs to provide me with it. Not to mention unfair.

> You need some sort of scheme to share the cost pie of providing the service.

You're comparing apples and oranges here. You're discussing something
like electricity, where the costs of providing it scale up with their
usage; or net connectivity, or similarly. I.e. a *service*.

I'm talking about a computer program; a piece of executable code that
performs some useful function when run. Whoever wrote it and shipped
me a copy has a single large cost when they make the first ever copy,
and a single small cost when they make and ship my copy. They don't
have any ongoing costs proportional to my subsequent usage, assuming I
don't bother them for support or anything.

I should be able to buy or otherwise get this copy and then use it for
as long as it will function, the same as if I bought a car. Of course,
software can be kept functioning potentially indefinitely, modulo
keeping backups or the original install media, avoiding incompatible
updates to the operating system or whatever, continuing to have
hardware it runs on, etc.

> So long as the seller
> has not wangled a monopoly position, he should be free to cook up any
> scheme he pleases. The market place will punish the irritating
> schemes..

Including any scheme that charges a lot more than cost, and certainly
any that charges based on usage when the "provider"'s costs don't grow
proportionately to your usage but rather remain constant.
Roedy Green - 07 Aug 2007 19:58 GMT
>I'm talking about a computer program; a piece of executable code that
>performs some useful function when run. Whoever wrote it and shipped
>me a copy has a single large cost when they make the first ever copy,
>and a single small cost when they make and ship my copy. They don't
>have any ongoing costs proportional to my subsequent usage, assuming I
>don't bother them for support or anything.

The argument is should I base the price on MY cost or the VALUE the
customer gets from my work?  Capitalist theory says you should raise
your price to the point you start making less money because of the
lower sales.

The end user is not all that interested in your costs.  Whether you
were blew a bundle on start up costs, or did it for a song, and what
your incremental and support costs are, he consider YOUR problem.

Basically he is interested in the value HE extracts from your program.
If customer A is able to extract more value out of a program than
customer B, A will be willing to pay more than customer B.  SO it
seems logical if you can find a way to charge A more  that B, you are
going to earn more money, than if you used a flat cost where some
customers did not buy because it was too expensive and others coasted
happy to pay considerably less than the program was worth to them.

This partly why I suggest using rental and an service as the basic
mechanism for delivering computation.  The more hours per month, the
more seats, the more the customer should pay.  They are getting more
value.

Any scheme is arbitrary.  The schemes that makes the creator the most
money and keeps the customers happiest and gets the programs most used
are the ones I would prefer to use.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Twisted - 07 Aug 2007 21:46 GMT
On Aug 7, 2:58 pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> The argument is should I base the price on MY cost or the VALUE the
> customer gets from my work?  Capitalist theory says you should raise
> your price to the point you start making less money because of the
> lower sales.

You also omit to mention that capitalist theory says that in a
competitive market you won't be able to raise it very much above your
marginal costs.

You also omit to mention that capitalist theory says that an
uncompetitive market is a Bad Thing(tm).

> SO it
> seems logical if you can find a way to charge A more  that B, you are
> going to earn more money

You neglect to note that doing so is underhanded and dishonest.
Advocating discriminatory pricing? Shame on you! How consumer-hostile.
And again a properly competitive market won't let you get away with
sh.t like that. If you offer the same thing to B at a lower price B
can turn right around and sell it to A for a penny more, turn a
profit, and you quit being able to sell to A at a high price as he
buys from B instead of from you. Of course, you have to raise the
price for B somewhat to make up for this, but instead of charging $50
to B and $150 to A you charge $100 to everyone, more-or-less exactly
as it should be modulo the other effects that should apply to your
pricing.

The only way you can stop this is by doing something truly dirty, like
using legal bludgeons or gratuitous technical "features" to make the
thing you sell to B non-transferrable to A.

But capitalist theory says that owning one's private property,
including being able to resell it or otherwise dispose of it as one
sees fit, is a good thing.

So what you're contemplating is bad. Naughty, naughty Roedy!

> This partly why I suggest using rental and an service as the basic
> mechanism for delivering computation.  The more hours per month, the
> more seats, the more the customer should pay.  They are getting more
> value.

It will never fly unless you force it somehow, because customers will
always pay less in the long run by buying a copy than by renting a
copy, and will pay even less by using a FOSS program instead of paying
anyone anything.

So you would have to outlaw FOSS and ownership of copies of software
in order to get your way. So much for being a capitalist; a capitalist
must accept the existence of such competition, including competition
that undercuts your price, or sells people an eternally functional
copy of some software that does the same thing you'd charge them
monthly to do.

Too bad, so sad.

You cannot be allowed to have your way or it is the end of the 21st
century "knowledge economy"; people like you, given the chance, would
strangle it in the cradle to ensure their own profits at everyone
else's expense. Make all my software much buggier and more expensive
will you?! Over my dead body! You can have my personally-owned and
eternally functional software when you pry it from my cold, dead
fingers! Plentiful, cheap, commodity software is a feature, not a bug!

> Any scheme is arbitrary.

Until the market applies corrections to prices. Your get-rich-quick
scheme hinges on it not doing so, and therefore on some pretty nasty
coercion. May you fail spectacularly.

> The schemes that makes the creator the most
> money and keeps the customers happiest and gets the programs most used
> are the ones I would prefer to use.

Then why do you suggest the schemes that make the creator the same
amount of money as before**, make the customers saddest*, and gets the
programs least used** then?

* Because you steal their software and rent it back to them, and they
must pay lots more for the same benefits, and must give up some of
their software because the costs have shot up so dramatically, plus
you hold their data hostage, and they have lost more of their property
rights in their things.
** Because people have a certain total budget for spending on
software. The more expensive it is on average, the less it gets sold.
So in fact software makers don't make any more money than before. They
make that same amount, only they do so while providing less software.
OK maybe their costs go down so they do show a small profit relative
to before, but it won't actually work to get rich quick; sorry to
burst your bubble there. And software will be much less used. In fact,
if usage is metered people will severely ration their usage.

Your suggestion makes the whole world poorer. The whole world! Even
YOU!
Customers are poorer because they must pay more for the same stuff,
and since they only have so much money they actually have to pay the
same amount for less stuff. So they have less stuff.
Worse, stuff they could just pay for and then own they now are forced
to pay over and over again for. Would you like it if your household
furniture could not, through some legal artifice, be yours, and had to
be rented by law? You couldn't buy chairs or tables or a desk; you had
to rent them. After a while the rental adds up to much more than the
price of buying one and still you have to keep paying or they
repossess your chairs and tables and desk. I don't think you'd like
that would you?
Plus there's the intrusive and gratuitous enforcement scheme. Given
it's designed to prevent the software from working some of the times,
this DRM will make the software especially prone to the worst category
of bugs, showstopper bugs. Also there's an incentive to hold the
user's data hostage to force them to keep paying you for the privilege
of being able to access it; this you'll spin as an "anti-piracy"
measure to stop people cracking the software for indefinite use, while
neglecting to point out how it also creates a lock-in that will let
you jack up prices until you bleed everyone dry. And even then there's
really only so much money to go around, and the end result is you end
up no richer and everyone else ends up poorer.
Oh yeah, and you also end up poorer. First, because of all the
software YOU use whose costs have shot through the roof, both directly
in price-tag terms and in terms of showstopper bugs introduced by all
that evil DRM. Second, because the whole WORLD ends up poorer, and the
sinking tide drops all boats, including yours.

I wish you bad luck with this scheme, I really do.
Bent C Dalager - 08 Aug 2007 10:23 GMT
>You neglect to note that doing so is underhanded and dishonest.
>Advocating discriminatory pricing? Shame on you! How consumer-hostile.

This is quite common and some of its current implementations seem to
work reasonably well. It's generally called market segmentation and
attempts to exploit various mechanisms that encourage wealthy people
to spend more on the product than what the less wealthy are prepared
to do.

A few examples would include:

1. Price-drops over time. You see this as a matter of course in the
computer games market. Games will come out at a high initial price
($50 perhaps) and slowly drop down over time, eventually ending up in
the bargain bin ($10 to $20 perhaps). The wealthy people will buy it
the day it comes out (preorder it even) at full price while the more
stingy will pay less, later.

2. Mail-in rebates and coupons in general. These are annoying and take
a fair bit of time and attention from the customer. They are therefore
not appealing to the wealthy customer who has better things to do with
his time (and whose hourly wages may even make it a financially
superior option to work an extra 15-30 minutes rather than take that
same time handling the rebates/coupons) whileas the less wealthy will
often find them a highly valuable supplement to their domestic budget.

While these may be seen as evil mechanisms, it should be considered
that they also contribute to making products cheaper than they
otherwise would have been to poorer people and personally I don't
consider that a bad thing.

>And again a properly competitive market won't let you get away with
>sh.t like that. If you offer the same thing to B at a lower price B
>can turn right around and sell it to A for a penny more, turn a
>profit, and you quit being able to sell to A at a high price as he
>buys from B instead of from you.

The problem is, the well-off people don't care about those savings
anyway, so the market for B is really rather limited. In fact, A may
find it more valuable being able to brag to his friends about how he
buys all of his games (say) at full price anyway. Humans have always
liked to flaunt their wealth when they have it. Admitting that you get
your stuff cheaper by having your neighbour collect coupons or
whatever may be socially embarrassing.

Cheers,
    Bent D
Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                   powered by emacs

Twisted - 09 Aug 2007 01:19 GMT
> The problem is, the well-off people don't care about those savings
> anyway, so the market for B is really rather limited. In fact, A may
[quoted text clipped - 3 lines]
> your stuff cheaper by having your neighbour collect coupons or
> whatever may be socially embarrassing.

There'll always be the ability to sell gilt-plated versions to the
superrich who seek to buy statu