Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software The Almighty Buck Hardware

Multi-Core Chips And Software Licensing 248

i_r_sensitive writes "NetworkWorldFusion has an article on the interaction between multi-core processors and software licensed and charged on a per-processor basis. Interesting to see how/if Oracle and others using this pricing model react. Can multi-core processors put the final nail in per-processor licensing?"
This discussion has been archived. No new comments can be posted.

Multi-Core Chips And Software Licensing

Comments Filter:
  • by Iesus_Christus ( 798052 ) on Tuesday July 20, 2004 @10:17PM (#9756247)
    If the efforts of other corporations bent on protecting their intellectual property (RIAA) are any indication, per-processor licensing will move to per-core licensing. If the RIAA can force you to pay multiple times for the same song (which you, unfortunately, cannot move between preferred mediums), then it would make sense that software companies bent on collecting money would make you pay multiple times for one processor. On the other hand, they are somewhat different issues: usage of music would be governed under fair use (in theory), while usage of software (at in terms of licensing per processor) would be governed by the EULA or another contract between the corporation and customer.
    • Alternatives (Score:3, Interesting)

      by MrChuck ( 14227 )
      I worked at a company and we busted our butts making software that was core-enterprise type software.

      To help envision it, lets say its a firewall - the firewall has no concept of "users" really, it routes packets. (it's not a firewall, but the situation is close enough).

      Now our basic question, which we reluctantly answered with per-processor licensing, was how to charge for it.

      If you buy our software and your company of 20,000 people is RELYING on it you'd pay more than if your company of 50 people

      • Re:Alternatives (Score:2, Insightful)

        by Waffle Iron ( 339739 )
        So what models of licensing do you WANT that will keep the vendor and the buyer in business and happy?

        Why not have your software measure how much real work it's doing. If over time it exceeds the amount of processing that the user paid for, then it starts to throttle itself back. That would be a lot more accurate than going with a crude measure like "number of CPUs" anyway.

        • Re:Alternatives (Score:3, Interesting)

          by topham ( 32406 )
          And I, as the end user, can trust the measurement of the software ' cpu usage, how?

          • Many years ago (back when all processing was done on big boxes) that model was used. As I recall accounting of CPU time used was done by separate CPU time accountng software rather than the app itself. The model, however, was largely abandoned as it was found that the administration of it was prohibitively expensive.

            Stephen

          • Re:Alternatives (Score:3, Interesting)

            by chthon ( 580889 )

            Asking the vendor to open the source about the measurement system and using programs like ethereal or iptraf to compare what is being measured.

        • Why not have your software measure how much real work it's doing. If over time it exceeds the amount of processing that the user paid for, then it starts to throttle itself back.

          No doubt then they'd have to work out a way to charge you for using that additional functionality...
      • Assuming it is a firewall, just charge by the number of computers on the local side of the firewall that packets are being routed for. If the user pays for 50 users, have it remember the states of sockets for 50 computers. If the user pays for 20,000 users, it could handle the states of sockets for 20,000 computers.

        I realize it isn't a firewall, but the solution works for nearly any networking tool. Charge by connected systems rather than users. Failing that, you can always assume the honesty of your
      • this is a common thing. it's called value-based pricing. IMO, it's crap. personally I think the right way to go about this type of thing is to sell different versions of your product. you can limit the cheaper version however you want to create an incentive for the more expensive version.
        • this is a common thing. it's called value-based pricing. IMO, it's crap. personally I think the right way to go about this type of thing is to sell different versions of your product. you can limit the cheaper version however you want to create an incentive for the more expensive version.

          Or more likely they create one version, deliberatly cripple it in order to make it look as though they have different versions. Then get upset when knowlage of how to undo their crippling hacks leaks...
    • Whoa. You're comparing RIAA tactics to non-free (as in _libre_ and dollars) software vendors.

      Your comparison is totally inappropriate.

      With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.

      After all, whey you're paying for performance, the vendor (and buyer) wants to find a useful billing metric that's easy for everyone to understand. Anyone who's dealt with Veritas's 20 or so tiers wil
      • With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.

        While I agree that there is nothing dodgy about it, one should also factor in processor speed and other issues that affect the amount of useful output that can be extracted from the s/w.

        I point this out because it is not a theoretical possiblility, but has been used in the past. In the area that I work, in the early days of commercial

      • With per-cpu licensing, the assumption is that the software can do more for you on a multi-cpu system, hence you pay more for it. There's nothing terribly dodgy about this.

        I don't know. I think it's a bit, hmm, unnatural. You know, I pay the processor vendor (or computer vendor) for the additional power, why the software vendor?
        Hmm, I didn't answer to defend the RIAA example, but thinking about it, there is an analogy with music. It's like saying you have to pay more for a CD because you have more applian
        • I also don't pay more for a DVD player just because I have a big TVB screen, just because this enables me to "get bigger value" out of that player.

          Well, in a few years, you'll have to bring a complete description of your video playing system to the shop, where you then get a video stick (DVD will not be supported any more - too little control) for a price evaluated from your setup. Say, $2 per Display Inch (sum over all displays you want the DVD played on, other displays will not show it due to DRM), $1 p

      • I actually ran into the per-processor licensing with database connector software on Linux. A Xeon shows up in linux as two processors due to the hyper threading. Of course hyperthreading is not as fast as 2 distinct CPU's either. It threw the salesman for a loop - he had no idea what the license would be. Turned out they were way overpriced anyway, and a FOSS driver worked fine.

        Oracle was licensing based on power units a while back. Any idea if they are stiill doing that? From what I understand, they basic
    • by Anonymous Coward
      Are Siamese twins required to buy two tickets to the movies?
    • Fortunately, the GPL will also follow suit, offering pre-core freedom.
  • by photon317 ( 208409 ) on Tuesday July 20, 2004 @10:18PM (#9756249)

    I don't if it's any indication of what they'll do for dual-core, but on Hyperthreading Xeon's, Oracle charged us RAC licensing fees per physical processor, even though most OS tools show twice as many virtual processors.
    • by Dark Lord Seth ( 584963 ) on Tuesday July 20, 2004 @10:33PM (#9756357) Journal

      That's because HyperThreading is a neat and very low level trick that makes it appear like there are two processors. A dual-core processor doesn't use any tricks and physically contains two processing cores on one chip. Of course, this could lead to some very interesting things such as an dual core AMD proc using one shared on-chip memory controller or Intel procs with dual-cores AND hyperthreading for a total of 4 procs.

      I'm looking forward to dual-cores.

      • Your implied claim ("hyperthreading isn't really two processors") only makes sense with an overly simplistic view of what a "processor" is.

        Let's say the basic components in a processor are: instruction fetch, instruction decode, load/store units (memory save/load), various execution units (that do the adds, multiplies, etc.), and a register file. Current hyperthreading allows for relatively fine grained switching between threads, so I believe there are two separate register files, but all the other units

        • by yakovlev ( 210738 )
          The thing you have to realize is that in modern processors, what few execution units exist are starved already. Adding more doesn't really make that much difference. The performance problems come from the caches, and we already build the fastest L1 caches we can for the single processor case.

          While your statement "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?" is mostly correct, it really doesn't fully recogn
      • I was recently involved in a conversation about the usefulness of dual core machines as home machines. The typical home machine is only really giving focus to one CPU intensive program at a time, max. Intel and AMD are obviously moving in that direction (and it doesn't stop at dual-core) and the reason is a little surprising. According to an Instat article published recently, Intel is doing it to overcome leakage current / power. As technology gets progressively better, leakage power has become progress
        • You may be right about the one CPU intesive program at a time but it may be running more than one intensive task at a time. If a program is written with hyperthreading and or SMP in mind you can spilt it to multiable threads. For a game you could have one tread handle AI and another what graphics and game play the Video card does not.
          When ecoding video one thread could handle the images and the other the sound.
          There are lots of times when a home system could use more than one processor. Most systems already
    • However, Oracle is free to change their licensing once again.

      Remember, it was just a few years ago that Oracle introduced, and then was forced to abandon, the "Power Unit". According to that licensing schema you paid $15-100 / Power Unit to license their product (depending on version, year, etc).

      A power unit was a mhz, so for example:
      - single server with 2x400 mhz CPUs could cost $100*2*400 = $80,000.

      On the other hand, if they were still using this today, you could be priced for a fast four-way:
      $100 * 4
      • by nettdata ( 88196 ) on Tuesday July 20, 2004 @11:33PM (#9756684) Homepage
        However, Oracle is free to change their licensing once again.

        Oracle Licensing is like mountain weather... if you don't like it, wait 10 minutes and it'll change.

        Seriously, though, Oracle changes their licensing more than any other software company I've ever dealt with.

        I won't be surprised to see their licensing change after they get some push-back from their customers.

        The other thing they DO have a history for, though, is NOT helping customer out when it comes to a license change. I've seen customers sign the deal on a Monday, only to have new pricing come out on the Tuesday. If they'd waited a single day, their software licensing would have been around half of what they paid.

        Joy.
  • by millisa ( 151093 ) on Tuesday July 20, 2004 @10:19PM (#9756262)
    A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor. Page has doc with more info on MS specifics [microsoft.com]
    • Sometime recently (it's late and I need sleep, so if you want you can look for yourself), I believe Microsoft said that they would charge per socket when it came to multiple-core CPUs. This was an important point that was brought up when AMD announced that it would begin production of dual-core Athlon64 CPUs later this year.

      How they would detect multiple cores in a single socket was not discussed. Maybe there will be something in the chipset that will cover that.
      • They say they can tell the difference between the logical and real processors (and I'm tempted to believe them since SQL2kSp3 does seem to handle the load distribution across the physical procs gracefully). They've got enough monkeys at enough keyboards that I'd wager they will be able to tell the difference . . . and as pointed out by the A/C above HT *is* different since they are logical procs, but if they keep the same stance and continue using the term 'Physical Processor', they might keep the licensin
    • A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor.

      Pretty reasonable because the second virtual processor isn't as nearly [intel.com] as good as having two physical processors for most server applications since the virtual processor runs only when the real processor isn't busy [intel.com]. For regular syst
  • no (Score:5, Insightful)

    by dark404 ( 714846 ) on Tuesday July 20, 2004 @10:20PM (#9756266)
    Most likely per-"Physical Processor" will be changed to per-"Physical Processor Die" since the multi-cores still share a die.
    • However, monitoring will then become an issue. Right now, a program licenced to a 2-processor box can kick and scream if the OS is telling it there's four processors available to it.

      The seperation between "logical processors" and "physical processors" is just not something software likes very much. If the software thinks there's four processors, the vendor's gonna want to charge by that unit.
      • by gfody ( 514448 )
        it's more likely that the software would only utilize 2 cpus even though there are more available.

        with some of the systems we use you have to purchase a license key that tells it how many threads/processes/ips whatever.
  • No, but PostgreSQL and Linux can :)
    • hee hee (Score:3, Insightful)

      by MrChuck ( 14227 )
      Yeah, postgres and linux do well on a pair of redundant 32CPU machine that's being HAMMERED, running with 32GB of memory in use and more waiting.

      I love the view that Linux can replace all machines. There's no place for proprietary software.

      Now, I'll mostly agree with Windows because too often Windows is being cobbled together and shoved into the data center (my servers need a windowing system just to boot? I have machines I've never seen or touched that I've installed from 12000 miles away and run fo

      • At least you caught the smiley :) We all know Linux doesnt scale that well... yet.

        But I sure don't miss the old days.
      • Yeah, postgres and linux do well on a pair of redundant 32CPU machine that's being HAMMERED, running with 32GB of memory in use and more waiting.

        IBM certainly thinks that Linux is either ready to handle that, or will be before long. In fact, IBM has put a tremendous amount of money into getting Linux to scale on their big iron, and it doesn't look like that's going to stop any time soon.

        I don't have any 32-way machines sitting around, but I did recently benchmark PostgreSQL on a 4-way Opteron, li
  • As long as IBM is making mainframes there will be per processor fees...and they have been around for 40 years so I see at least another 40. Heck, now they even charge different amounts for a processor depending on what you are going to run on it.
    • Poor guy, yet another fool moderator missed the point and marked you as a troll.

      I suspect that moderator works for oracle and doesnt like you speaking the truth.

      Of course the real point is that software companies ... and really ALL companies of everytype will charge you as much as they can get away with. THERE IS NO STORY HERE!

      Now I'll go fishing for karma ..

      DUMP ORACLE, USE POSTGRESQL ... its open source, its free, it has evolved to handle most companies needs. If Oracle tries to screw you, you hav
  • Toast. (Score:5, Funny)

    by scowling ( 215030 ) on Tuesday July 20, 2004 @10:21PM (#9756281) Homepage
    Yeah, I'm looking forward to the day where you have to pay a license fee for each element in your toaster. Who needs to toast more than one slice of bread at a time, right?
    • Nah. I'll just replace my heatsink/cooling element with bread on my multi-cored processor. If you had a server rack, then maybe you could flip the one on top over to toast both sides at once.
  • I don't follow CPU development beyond what I need for my day job and what I read here (how's that for pathetic?), but do multi-core CPUs necessarily mean SMP on (in?) a single slab or does it more often mean more pseudo-SMP of the hyperthreading variety?
  • Buy Robot (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Tuesday July 20, 2004 @10:23PM (#9756288) Homepage Journal
    Businesses charge the maximum they can, for maximum total profit: "what the market will bear". Per-processor prices are just a way to negotiate how much money the customer can make from the software, therefore how much is available from their revenue to pay the software supplier. Just like when an employee negotiates their income, they are negotiating for a share of their employer's revenue to which their work contributes. I'd like to see a software licensing model that treats the software's work as automated labor, and negotiates accordingly. Like some kind of profit sharing. People don't get paid up front, why should the software company? That allows a timeframe for a "test drive" during which both parties can get benchmarks on the actual value of the software.
    • Businesses charge the maximum they can, for maximum total profit: "what the market will bear".

      Linspire looks poised to change the market.

      Per-processor prices are just a way to negotiate how much money the customer can make from the software

      Well exactly how much money does a residential customer customer make from the Windows XP Home Edition operating system software?

      Microsoft Windows XP's desktop license model currently limits the home edition to one processor and the professional edition to tw

      • license economics (Score:3, Insightful)

        by Doc Ruby ( 173196 )
        You're right in questioning the home user's cost:benefit analysis in terms of revenue, although many people do use eg. Windows XP to make money, or save money, at home. But I haven't heard of Microsoft requiring non-business customers to pay a per-processor license - are there any (working) dual processor gaming machines which cost more for their Windows license than their single processor versions? AFAIK, WinXP Home shuts off all but one processor to keep corporate customers from buying it for less than Pr
        • Re:license economics (Score:2, Interesting)

          by afidel ( 530433 )
          Nah, the biggest thing keeping business's from running Home Edition is the fact that it can not join a domain. This isn't an issue for small business's, but neither is the lack of multi-cpu support. Btw there are basically zero games that take real advantage of a second CPU, the reason are varied but basically come down to the GPU being the limiting force, multi-threaded code being harder to code and debug, and finally a lack of demand.
          • So it boils down to the same thing: multiproc is for biz, single-CPU is for home. Join that on multiproc costs more than single-CPU, and the per-processor fee is a way that Microsoft charges businesses more than home users. Which they can, because the biz processing generates more money to pay Microsoft. It's not that complicated, although the extra complexity allows Microsoft to maximize its profit without doing so in obvious terms of sharing the profits it can increase.
          • Btw there are basically zero games that take real advantage of a second CPU

            From comments made by John Carmack in the past, that's only going to be true until August 5th [slashdot.org].

            John's said that the game is fully multithreaded - as an example, the audio, specifically, runs in its own thread. I don't recall (or he didn't say) just how many different threads will be created and used, but video games actually have huge potential benefits in an SMP system. Between physics, sound, rendering, AI, environment, a
      • Microsoft Windows XP's desktop license model currently limits the home edition to one processor and the professional edition to two, counting a single-core multithreaded processor as one processor. However, if Windows XP counts a multi-core CPU as two processors, then it won't boot both processors, and by the time PC vendors phase out single-core x86 processors, all OEMs will have to pay extra for Windows XP Pro.

        XP is licensed per *physical* processor. A dual core CPU, like a hyperthreaded CPU, is still a

    • People don't get paid up front, why should the software company? That allows a timeframe for a "test drive" during which both parties can get benchmarks on the actual value of the software.

      People usually get paid by the time period, not by how much work they actually accomplish in the hour or year. Only people in sales get a comission that's a direct percentage of the revenue that passes through them. For everybody else, pay doesn't usually directly get tied to actual performace.

      Software vendors want to
      • People get paid by the time period, but only retain their jobs if they produce an acceptable amount in that period. Of course, in most dysfunctional corporate environments, production of asskiss counts as much or more than the revenue, if others can be "managed" into making up the slack. Tying pay to performance is typically resolved during raise negotiations - although it's usually ignored by intimidated labor, and defaults to an unspoken agreement to pay the labor less than it generates. That's more susta
  • this is all BS. (Score:4, Insightful)

    by rokzy ( 687636 ) on Tuesday July 20, 2004 @10:28PM (#9756320)
    demanding more money for multi-core is ridiculous. if you're going to do that, why not charge more for faster CPUs? why should it cost twice as much to use, for example, a 2-core 1GHz CPU than a 1-core 2GHz CPU?

    on the other hand it may push more people to OSS.
    • Re:this is all BS. (Score:5, Informative)

      by jsprat ( 442568 ) on Tuesday July 20, 2004 @10:52PM (#9756466)
      It is BS. But Oracle used to charge per "processing unit". It took into account the speed of the chip you planned to run it on as well as the number of processers in the system and the number of expected connections. Or you could purchase the "Web server" edition, which would have broken our company.


      Today, Oracle's price list [oracle.com] is 11 pages of different price plans that would confuse a car dealership!

  • maybe not (Score:4, Insightful)

    by jdkane ( 588293 ) on Tuesday July 20, 2004 @10:28PM (#9756323)
    At issue is that software vendors such as Oracle and Microsoft that license software on a per-CPU basis are likely to consider each processor a separate CPU, a practice that means double the licensing costs for enterprise users

    Well, these rules are obviously not written in stone. "likely" is speculative. Let's wait and see what they *actually* decide to do. Rules can change as technology changes. The enterprise users should speak up about this issue and provide feedback.

    Obviously Oracle considers an n-core chip as n processors. However they are not going to be able to compete if another database company does the opposite with its licensing. However, maybe they'll all follow each other just for the sake of quick $.

  • by Fooby ( 10436 ) on Tuesday July 20, 2004 @10:30PM (#9756339)
    Writing multithreaded applications (or SMP-capable operating systems) that work well is hard work. It's always going to make sense for proprietary software vendors to charge extra for software that takes advantage of additional processors. Unless SMP and/or dual-core becomes ubiquitous, I something like per-processor licensing sticking around, unless the mythical day when free software eclipses proprietary software does in fact come about.

    And I think single-core, single-CPU systems will stick around for a long time, if not for the indefinitely foreseeable future. CPUs get faster all the time, and since it's much easier to engineer single-core, single-CPU systems, so single-processor systems will remain the preferred solution for the low end. Look at something as basic as pipelining, that is an ancient technology in terms of processor design, yet there is still a place for non-pipelined processors at the very bottom of the chain, where microcontrollers are concerned.

    • Writing multithreaded applications (or SMP-capable operating systems) that work well is hard work

      Yeah, so what? Once the engineering and coding is done, it's done. Or are you telling me that by upgrading a machine from two CPUs to four CPUs somehow cost the developers more money?

      and since it's much easier to engineer single-core, single-CPU systems,

      Actually, it's MUCH easier to simply put two of your cores on a single die than it is to put all of the R&D into a new architecture to fill th
  • Already answered (Score:2, Informative)

    by nusratt ( 751548 )
    (for now). I've already seen official statements by vendors, explicitly saying that multi-core won't affect their licensing. I've seen none even hinting the other way. If this article says otherwise -- explicitly, naming names -- then that's news.
  • Can multi-core processors put the final nail in per-processor licensing?"

    So, like a nail in a voodoo doll, MCPs are tortuting per-processor licensing? Cool as that may be, I think the saying is "put the final nail in the coffin of [ . . . ]"

    Sorry for being pedantic, but it sounds funny without the coffin part.
  • I think it is interesting that, Windows running on a 2 CPU machine requires a 2 CPU license, but, say, 5 instances of VMWare running on a single CPU, each hosting an instance of Windows, requires five licenses. (Six if the instances of VMWare are themselves running on Windows)

    Also, what if there was a VMWare-like program that simulated a SMP machine? Would that require a multiple CPU license to run Windows? Even if this program that emulated a SMP machine was running on a single CPU?

  • ...when I learned that enabling hyperthreading was going to allow MS to charge twice for a single processor.

    KS
  • Uh, okay (Score:3, Insightful)

    by NanoGator ( 522640 ) on Tuesday July 20, 2004 @11:21PM (#9756627) Homepage Journal
    I don't mind paying Intel a little more for dual core machines. I don't mind paying Microstar extra for a motherboard that supports that processor. I don't mind paying Microsoft extra for using dual core processors. But... on a per app basis? So.. I'm paying for 2x the performance, right? What if I buy a machine with ~twice the megahertz?

    Maybe I'm just knee-jerk reacting here. I'm just not all that impressed with this new scheme to wring money out of people, even if they are big corps etc. I mean, if the software did something special with more processors, that'd be a little different. I just don't want the double-dipping to happen. Hardware makes the speed.

    Okay, I'm done redundantly ranting. I'm just annoyed with the prospect in a year or two of adding new machines to the render farm and then having to 'upgrade' the software.
    • It's not a new scheme, it's been around for years. I do agree with you that it's a stupid practice though. Mostly I think they do it because they can. Once you've graduated to multiple processors the vendors figure you're living in the big leagues and you won't mind paying the big bucks.
    • What if I buy a machine with ~twice the megahertz?

      Two comments:
      Double the MHz does not equal double the speed. There are many reasons for this, for example: All other things being equal, if the program and its data fit completely in a CPU cache, a processor with twice the MHz would indeed be close to twice as fast on a single task. Since that's rare, the CPU spends a lot of time waiting for stuff to be read or written from memory or disk, which is glacial in comparison. Moreover, disk and memory spee
  • by Thagg ( 9904 ) <thadbeier@gmail.com> on Tuesday July 20, 2004 @11:32PM (#9756678) Journal
    i_r_sensitive is extremely optimistic if he feels that multi-core processors are going to mean the end of per-processor licensing. I would think that most software licensors are looking toward multi-core chips as the gravy train finally pulling into town.

    When you think about it, any licensing deal is a contract between a software provider and a software user. If the price doesn't make sense, then the contract won't happen.

    Depending on the cost of the processor chips, the computer chassis they plug into, and the license cost -- per processor licensing could save people money when they move to multi-core machines -- assuming that the two-core machine really is twice as fast at the application as two single-core machines. If the chips don't cost much more, you save the hardware, energy, and cooling costs of the second chassis. This could be a big win.

    This is one of those cases where the market will decide. In [my] visual effects business, company policies are all over the map. Pixar allows you to run RenderMan on dual-proc machines with a single license. It believe (could be wrong, we have only 2 proc machines)) that Shake will run on however many processors you have in one box using just one license. Other software requires a separate license for each processor.

    But really, when I say "software requires", that's wrong and stupid. It's the contract you have with the software provider that requires it, and contracts are often quite malleable.

    Thad Beier

  • wake up fools (Score:5, Informative)

    by GISGEOLOGYGEEK ( 708023 ) on Tuesday July 20, 2004 @11:37PM (#9756700)
    Why are any of you surprised?

    Oh ya, its because you can only think with the open source half of your brain.

    Of course software companies will try to charge you more money any chance they can!

    Just like every other product you can buy anywhere, if they can sell it for more, they will.

    Wake up!

    Until you complain enough, they will reap what they can from this conundrum.

    If you don't like how Oracle screws you on your new dual core processor, then send them packing, I'd bet that Postgresql / PostGIS is now sufficient for the needs of most enterprise database users .. AND ITS FREEEEEE.

    In fact, I personally am going to skip the chance at ever having the topic at hand affect me .....

    Today I called, found out that, ESRI in canada charges $13,500 for a 1cpu license of ArcSDE or $19,000 for a 2cpu license, it remains to be seen what they define as a CPU.

    But instead of blowing that $19,000, I am installing PostGIS to serve my spatial datasets. Screw them! ... they really didnt like it when I pointed out that I'll be saving $52,000 by using MapServer + Postgresql + PostGIS over their ArcIMS + ArcSDE/Oracle setup.

    And the joke is on them as my system is faster, easier to setup / deploy, and can handle much bigger raster datasets in a fraction the time.
  • MIPS rating (Score:2, Interesting)

    by kiwirob ( 588600 )
    I can't remember exactly, but back when I was working as a IBM mainframe software engineer I had a feeling the IBM and CA who provided various software for our mainframes charged some software based on MIPS (Million Instructions Per Second) ratings of the virtual machines that the software was running on. Why don't software companies just do the same thing. Establish a performance benchmark and charge based on that. That way you can use single, dual or multi core processors or multi CPU machines and not

    • That's still like changing the price of a car based on how fast you're going to drive it, and is sufficiently retarded that it can only survive in markets where the barriers to entry are pretty high.

      steve
  • This is old news (Score:2, Interesting)

    by owsleyd ( 656706 )
    Both HP and IBM have had dual core chips for a while now. There are a number of advantages to moving to dual core processors. The most important is that it helps to improve performance without as much heat generation as two single core processors. Another advantage to dual core processors is that you can share caches, which have some very distinct advantanges in multiprocessor environments. By sharing cache processors can check the shared cache without interupting eachother. By improving the performanc

How many Unix hacks does it take to change a light bulb? Let's see, can you use a shell script for that or does it need a C program?

Working...