Java Forum / General / August 2007
Detecting CPUs and cores
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
|
|