The only Powerbook that uses a 45W is the 12" Powerbook. Everything else is 65W.
Virtually every Dell comes standard with a 65W power supply.
Most HP notebooks use a 65W power supply. The 135W power supply is only for a limited number of machines - zd7000 (P4), zv5000 (Athlon 64), zx5000 (P4) - all "desktop replacement" class machines with large (15"+) screens, none using a mobile processor.
The IBMs vary a bit more. The X series uses a 56W, the R and T series use 72W, and the G runs at 120W (hardly surprising, uses desktop CPUs).
Regardless of the actual wattage, making a power consumption comparison between a notebook and a brand new multi-core desktop processor is highly disingenuous.
You don't need to be a chicken to smell a bad egg.
Though in this case it's not so much a bad egg as a mediocre one. The current Intel design is little more than a pair of cores slapped onto a single piece of silicon, with little integration between them. The AMD design leverages the advantage of having multiple cores by allowing communication directly over the on-die system request interface rather than the external front-side bus.
Re:Well, let's have a look
on
McVoy Strikes Back
·
· Score: 4, Informative
The C implementation of PHP was released in 1995. Language constructs existed in the beta versions also released later that year.
Whether you think its a "shoddy piece of work" or not, it clearly isn't a clone of a product released a year later.
Use of plural verbs in conjunction with a singular noun denoting a group is, in fact, commonly used by native speakers in Britain and other parts of the world.
That's assuming you manage to keep each SPE running at 100% efficiency and are doing exclusively vector processing. In other words, even 25 GFlops is a fantasy number for anything but highly specialized applications.
The PowerPC element (PPE) of the Cell is not simply a G4 or G5 processor. It's am much simpler design overall. It only issues two instructions per clock cycle, compared to eight on a G4, and is strictly in-order execution only, which complicates optimization on a multi-tasking general purpose computer.
Those fancy vector units are also not tuned for general purpose computing. The 250+ GFLOP numbers that have been widely quoted are for single percision mathematics with non-standard rounding. There is a stricter double percision mode available, but it's a full order of magnitude slower.
Are package managers usually over strict on their enforcement though?
Package managers, no. They simply enforce what is specified in the packages. Packages, on the other hand, sometimes are overly specific in their dependencies.
Specificalluy, it seems many times I will have a version of a library installed that is newer than the version of the library the package manager is looking for. Shouldn't the libraries be backwards compatible and are they typically backwards compatibile (guess typically needs to be always though for a package manager to consider it sufficient).
Not necessarily. Newer versions of libraries can change the ABI in incompatible ways. Libraries on Linux systems are typically versioned to allow older versions of the library to be provided in parallel with the newer version; e.g. you might have both libmysqlclient.so.10 and libmysqlclient.so.12 installed, so you're compatible with applications build for both MySQL 3.23 and MySQL 4.1.
I think I ran into problems when I wanted to get IEEE1394 libraries installed on my computer to control my cable box. I couldn't find any packages, so I had to use tarballs, and I think these may have replaced some older library with a newer library, which then caused the package manager to go berserk.
The disadvantage of tar installs is that the package manager doesn't know about the new files, and of course won't know that you got rid of the older install.
Unfortunately this is a hard problem to get around, and one of the reasons why going outside the package manager usually requires some care if it's going to work at all. To my mind it's a bigger issue for the home desktop user, who is likelier to want to play with the latest and greatest (and often unpackaged), and doesn't have the expertise to do their own packaging.
On the other hand, in a business environment, the software set is usually going to be a lot smaller and more well established, especially in a server environment. Most of the time the bundled packages are going to be sufficient, so they've been tested to all work together. And in packages requiring customization, it's actually pretty trivial to maintain packages in house; I personally handle somewhere in the neighborhood of 40 or 50, and it's hardly my primary task.
So you maintain your own repository. Is there software to auto deploy updates to tens of thousands of machines based upon their machine name, location, role or other details? And maintain an inventory of what machines need updating, and what machines have what software?
How many people manage "tens of thousands of machines"?
What an organization requires from package management is highly variable, and isn't even consistent between departments in some cases. Desktop machines have a completely different support profile from servers, and "desktop support" servers (e.g. file and print) differ from, say, public web servers.
For a company of the size your talking about, something like Zenworks or Red Hat Network may well make sense, as they do provide an extremely high level of centralized management. On the flip side, with that kind of support base, the cost of developing an in-house solution is also pretty damn low "per machine" as well.
And frankly, the "scripts and cron jobs to do all that stuff" really isn't the momentus undertaking that you seem to imply. In fact, I'd say it's the easy part. It took me less than a week to develop our solution, which has the side benefit of being integrated with the build system, so any new installs automatically have the latest versions of the packages.
Probably the biggest time sink is the QA phase, and even most of that we have automated testing for. The next is staged rollout, since we do pilot upgrades in order to ensure a QAed package is behaving as expected in production (it's rate, but occasionally a problem will only crop up under load).
They include yum, but the primary package update tool is still up2date. What's really cool is that in addition to RHN, it now also support yum, apt, and local file repositories.
What seems to work for me in that instance is leaving the dialog open, but dragging it nearly entirely off screen.
You know what bugs the fuck out of me? Windows XP changing the behaviour of the "turn off" option to "download updates". The rare times I actually do boot into Windows only serves as a reminder of why I don't like doing it.
People who refuse to use package updates because of "dependency issues" are usually using them incorrectly. Package managers do not create dependencies, they record and enforce them.
Used properly, a package system is a solution, not a problem. When I want to install something I don't even consider dependencies, I simply type "up2date " and it pulls in everything that package needs and installs them in the proper order.
The only real downside is that third party packages are often poorly created. Failure to follow platform conventions (e.g. paths) is the most common "sin". Ultimately I think user oriented distributions need to settle on a more reasonable release schedule. The ridiculously short cycle of Fedora (4-6 months) is way too volitile and really hinders any meaningful packaging effort, and the glacial cycle of Debian (almost 3 years since the last major update) precludes support for modern desktop packages. As the major desktop technologies (Gnome, KDE, Mozilla, etc) mature, this should help to rationalize distribution release cycles as well.
The most common end user mistake, in my experience, is circumventing the package manager - forcing packages, ignoring dependencies, installing from tarball, etc - and then wondering why it doesn't work. To some degree it's understandable. There is plenty of cool software out there that's simply unavailable without building from scratch, and a lot of the people who try Linux are curious and want to explore the cutting edge. But it should never be forgotten than on the cutting edge things break. A lot. Sometimes dramatically. If you want stability and predictability, you simply have to wait until the bugs are ironed out and things are neatened up for "mass market" distribution.
Comparing windows to whatever open source platforms an organization happens to be running is utterly meaningless. Patching procedures vary wildly between Linux distributions, and between Linux and other open source platforms. For example, I know admins who manually recompile software on at least a half dozen platforms for some common daemons (like sshd). Others, including myself, simply test and roll out vendor supplied packages for the most part.
Another aspect they seem to gloss over in the summaries is that a lot of the costs are lower on Linux, and they only come up with reduced numbers for Windows by dividing it by the number of running machines. Well, duh, economies of scale are always a boon. Riddle me this - if the costs are cheaper with OSS for patch preperation, patch management training, management oversight, configuration and inventory management, et cetera, wouldn't a homogenous OSS environment be cheaper than a homogenous Windows environment?
Another bit that's not mentioned in the news story is that the capital outlay for management tools was much higher on Windows. They then go on to break that down to per system costs to prove that OSS is oh so much more expensive. Thing is - fairly sophisticated patch management comes out of the box with a number of major OSS platforms. I'd guess that all the costs on the OSS side were probably a handful of customers who stuck with OpenView or Tivoli because that's what they're standardized on. For them, it'd be a constant cost regardless of platform.
Overall, this just points out the problems with drawing conclusions from numbers dervied from (a fairly small) survey. Differences in platform and practice yeild results that are incredibly different from this survey. I know one person who's responsible for over two hundred systems on his own. According to this report, that would require well over 6000 "hours per year of support effort", despite the fact that he works well under 2000 hours a year (40 hour week minus paid time off) and that's far from all "support effort".
$112 is "around $100". As I reiterarted, I was comparing pricing on motherboard, case, and processor; not complete systems. And it turns out the Asus system I quoted includes the case, floppy, and cdrom for near the price I gave in the original post.
As for the rest, you don't need to go mini-itx to go Via. If we want to make that a requirement of the comparison, you can forget the "cheap" (over $200) Pentium M board I used in the prior comparison, and start looking at boards that starting at around $325.
On the Via side, you can get pretty damn cheap including the board, case, cpu, and power supploy. Looking at iDOTpc, they range from $199 (EPIA 5000, 533MHz fanless) to $324.00 (EPIA MII 12000, 1.2GHz). Still cheaper than just the motherboard for the Intel solution.
It's really a matter of what you're priorities are. The "bottom of the barrel" system I quoted is from a reputable manufacturer (Asus) using Via's own north and south bridge sets. Given that virtually all Via solutions use the integrated peripherals are comparable to the more expensive bretheren. So really, it's only bottom of the barrel if the 800Mhz cpu and 266Mhz FSB aren't fast enough. For a lot of people, they are.
Maybe I'm in the wrong corner of the world on this one, but I think Red Hat is the distribution becoming less and less relevant.
Last quarterly result from Novell states $26,314,000 in revenue from new software licenses in the "Linux and Platform Services" segment. Last quarterly result from Red Hat states $45,393,000 in Enterprise subscriptions.
Somehow I think they're still a teeny bit relevent. And considering their year over year increase in subscription revenue was 120% from last year, I'd say they're not about to fade away.
The biggest threat Red Hat faces right now is that IBM could settle with SCO and then release its own Linux along with workstations and servers based on the Cell processor.
IBM doesn't need to settle with SCO to release it's own version of Linux. All it needs to do is... release it's own version of Linux. Hell, they could download RHEL, rebuild, rebadge, and sell that.
Given that Cell outperforms x86 by an order of magnitude and doesn't have the security weaknesses built into the x86, this would leave them fighting to hold an ever decreasing share of a shrinking market.
What insightful commentary. Anyone who seriously believes the Cell processor outperforms conventional architectures by "an order of magnitude" for anything but specialized tasks needs to lay off the crack pipe. That big impressing 256 GFlop figure that's been bandied around is the theoretical "if you fill every pipeline" number, is almost entirely comprised of FP operations (guess what - most business servers aren't busy rendering pretty pictures), and is for a single precision pipeline which rounds in a non-standard way.
Know what the performance hit is for IEEE854 double precision FP? A full order of magnitude. There goes all that theoretical performance, and you lose the benefit of the industry dominant instruction set, and gain a whole set of programming peculiarities of the new architecture, such as the lack of a branch prediction unit even in the PPC core.
I said "around $100" for "board, chip, case, and integrated everything - video, tv out, firewire, ethernet", which is about right. The price I quoted for the Intel solution was board and chip only as well (and even that's still $100 more than a Via system).
And no, I would certainly not recommend a Via for heavy number crunching, but I did say there were serving entirely different market segments than Intel - named low cost, low power desktop solutions and embedded solutions. Typically these segments aren't called on for heavy number crunching, especially with acceleration of encryption features on-die, and MPEG-2/4 being accelerated by the north bridge.
Re:Maintainability of Perl code?
on
Perl Medic
·
· Score: 0, Troll
"MOD THIS UP INSIGHTFUL!!!! by Anonymous Coward Wednesday February 30, @09:34AM"
That is so incredibly lame, I can't even find the words.
O'Gara is editor-in-chief of "LinuxGram", which isn't surprising since she's the founder of G2 Computer Intelligence, the publisher of that periodical. That has no official affiliaction with LinuxWorld or Sys Con.
To be fair, she wasn't fired by Sys Con, since she has never held a position there. Use of the term was meant to contrast with the allegation of censorship, rather than be a precise description of the business relationship.
She wasn't fired - not censored, fired - for her opinion. She was fired for producing a particularly odious example of yellow journalism and stepping over the line with a gross violation of privacy. One which may well be legally actionable.
In the case of peanut butter, it's not just the economies of scale. If you look at the ingredients you'll see the peanut oil has been replaced largely by cheaper oils - often rape seed, soy bean, or cotton seed. Cotton seed, in particular, is a favourite of bargain brands because it's very cheap, since it's essentially a waste product of cotton production and fares poorly as an independently marketed product due to it's saturated fat content (higher than any other common oils aside from tropical sources such as palm or coconut).
On top of that, the added oils are hydrogenated. Aside from avoiding the seperation seen in natural peanut butters, this also extends shelf life, which also drives costs down.
Slashdot Mirror
The only Powerbook that uses a 45W is the 12" Powerbook. Everything else is 65W.
Virtually every Dell comes standard with a 65W power supply.
Most HP notebooks use a 65W power supply. The 135W power supply is only for a limited number of machines - zd7000 (P4), zv5000 (Athlon 64), zx5000 (P4) - all "desktop replacement" class machines with large (15"+) screens, none using a mobile processor.
The IBMs vary a bit more. The X series uses a 56W, the R and T series use 72W, and the G runs at 120W (hardly surprising, uses desktop CPUs).
Regardless of the actual wattage, making a power consumption comparison between a notebook and a brand new multi-core desktop processor is highly disingenuous.
s/a mac/a laptop/
You don't need to be a chicken to smell a bad egg.
Though in this case it's not so much a bad egg as a mediocre one. The current Intel design is little more than a pair of cores slapped onto a single piece of silicon, with little integration between them. The AMD design leverages the advantage of having multiple cores by allowing communication directly over the on-die system request interface rather than the external front-side bus.
The C implementation of PHP was released in 1995. Language constructs existed in the beta versions also released later that year.
Whether you think its a "shoddy piece of work" or not, it clearly isn't a clone of a product released a year later.
The Cell PPE is an in-order chip with only two execution units, not a Power5, which supports out of order execution, and has eight execution units.
The Xbox cores, however, are also dual issue, which does match the Cell PPE. No woder on OOE.
Use of plural verbs in conjunction with a singular noun denoting a group is, in fact, commonly used by native speakers in Britain and other parts of the world.
That's assuming you manage to keep each SPE running at 100% efficiency and are doing exclusively vector processing. In other words, even 25 GFlops is a fantasy number for anything but highly specialized applications.
Considering that the Playstation 3 specs include an Nvidia chip with more transistors than the Cell itself, I doubt they're particularly pissed.
The PowerPC element (PPE) of the Cell is not simply a G4 or G5 processor. It's am much simpler design overall. It only issues two instructions per clock cycle, compared to eight on a G4, and is strictly in-order execution only, which complicates optimization on a multi-tasking general purpose computer.
Those fancy vector units are also not tuned for general purpose computing. The 250+ GFLOP numbers that have been widely quoted are for single percision mathematics with non-standard rounding. There is a stricter double percision mode available, but it's a full order of magnitude slower.
Are package managers usually over strict on their enforcement though?
Package managers, no. They simply enforce what is specified in the packages. Packages, on the other hand, sometimes are overly specific in their dependencies.
Specificalluy, it seems many times I will have a version of a library installed that is newer than the version of the library the package manager is looking for. Shouldn't the libraries be backwards compatible and are they typically backwards compatibile (guess typically needs to be always though for a package manager to consider it sufficient).
Not necessarily. Newer versions of libraries can change the ABI in incompatible ways. Libraries on Linux systems are typically versioned to allow older versions of the library to be provided in parallel with the newer version; e.g. you might have both libmysqlclient.so.10 and libmysqlclient.so.12 installed, so you're compatible with applications build for both MySQL 3.23 and MySQL 4.1.
I think I ran into problems when I wanted to get IEEE1394 libraries installed on my computer to control my cable box. I couldn't find any packages, so I had to use tarballs, and I think these may have replaced some older library with a newer library, which then caused the package manager to go berserk.
The disadvantage of tar installs is that the package manager doesn't know about the new files, and of course won't know that you got rid of the older install.
Unfortunately this is a hard problem to get around, and one of the reasons why going outside the package manager usually requires some care if it's going to work at all. To my mind it's a bigger issue for the home desktop user, who is likelier to want to play with the latest and greatest (and often unpackaged), and doesn't have the expertise to do their own packaging.
On the other hand, in a business environment, the software set is usually going to be a lot smaller and more well established, especially in a server environment. Most of the time the bundled packages are going to be sufficient, so they've been tested to all work together. And in packages requiring customization, it's actually pretty trivial to maintain packages in house; I personally handle somewhere in the neighborhood of 40 or 50, and it's hardly my primary task.
So you maintain your own repository. Is there software to auto deploy updates to tens of thousands of machines based upon their machine name, location, role or other details? And maintain an inventory of what machines need updating, and what machines have what software?
How many people manage "tens of thousands of machines"?
What an organization requires from package management is highly variable, and isn't even consistent between departments in some cases. Desktop machines have a completely different support profile from servers, and "desktop support" servers (e.g. file and print) differ from, say, public web servers.
For a company of the size your talking about, something like Zenworks or Red Hat Network may well make sense, as they do provide an extremely high level of centralized management. On the flip side, with that kind of support base, the cost of developing an in-house solution is also pretty damn low "per machine" as well.
And frankly, the "scripts and cron jobs to do all that stuff" really isn't the momentus undertaking that you seem to imply. In fact, I'd say it's the easy part. It took me less than a week to develop our solution, which has the side benefit of being integrated with the build system, so any new installs automatically have the latest versions of the packages.
Probably the biggest time sink is the QA phase, and even most of that we have automated testing for. The next is staged rollout, since we do pilot upgrades in order to ensure a QAed package is behaving as expected in production (it's rate, but occasionally a problem will only crop up under load).
They include yum, but the primary package update tool is still up2date. What's really cool is that in addition to RHN, it now also support yum, apt, and local file repositories.
What seems to work for me in that instance is leaving the dialog open, but dragging it nearly entirely off screen.
You know what bugs the fuck out of me? Windows XP changing the behaviour of the "turn off" option to "download updates". The rare times I actually do boot into Windows only serves as a reminder of why I don't like doing it.
People who refuse to use package updates because of "dependency issues" are usually using them incorrectly. Package managers do not create dependencies, they record and enforce them.
Used properly, a package system is a solution, not a problem. When I want to install something I don't even consider dependencies, I simply type "up2date " and it pulls in everything that package needs and installs them in the proper order.
The only real downside is that third party packages are often poorly created. Failure to follow platform conventions (e.g. paths) is the most common "sin". Ultimately I think user oriented distributions need to settle on a more reasonable release schedule. The ridiculously short cycle of Fedora (4-6 months) is way too volitile and really hinders any meaningful packaging effort, and the glacial cycle of Debian (almost 3 years since the last major update) precludes support for modern desktop packages. As the major desktop technologies (Gnome, KDE, Mozilla, etc) mature, this should help to rationalize distribution release cycles as well.
The most common end user mistake, in my experience, is circumventing the package manager - forcing packages, ignoring dependencies, installing from tarball, etc - and then wondering why it doesn't work. To some degree it's understandable. There is plenty of cool software out there that's simply unavailable without building from scratch, and a lot of the people who try Linux are curious and want to explore the cutting edge. But it should never be forgotten than on the cutting edge things break. A lot. Sometimes dramatically. If you want stability and predictability, you simply have to wait until the bugs are ironed out and things are neatened up for "mass market" distribution.
Comparing windows to whatever open source platforms an organization happens to be running is utterly meaningless. Patching procedures vary wildly between Linux distributions, and between Linux and other open source platforms. For example, I know admins who manually recompile software on at least a half dozen platforms for some common daemons (like sshd). Others, including myself, simply test and roll out vendor supplied packages for the most part.
Another aspect they seem to gloss over in the summaries is that a lot of the costs are lower on Linux, and they only come up with reduced numbers for Windows by dividing it by the number of running machines. Well, duh, economies of scale are always a boon. Riddle me this - if the costs are cheaper with OSS for patch preperation, patch management training, management oversight, configuration and inventory management, et cetera, wouldn't a homogenous OSS environment be cheaper than a homogenous Windows environment?
Another bit that's not mentioned in the news story is that the capital outlay for management tools was much higher on Windows. They then go on to break that down to per system costs to prove that OSS is oh so much more expensive. Thing is - fairly sophisticated patch management comes out of the box with a number of major OSS platforms. I'd guess that all the costs on the OSS side were probably a handful of customers who stuck with OpenView or Tivoli because that's what they're standardized on. For them, it'd be a constant cost regardless of platform.
Overall, this just points out the problems with drawing conclusions from numbers dervied from (a fairly small) survey. Differences in platform and practice yeild results that are incredibly different from this survey. I know one person who's responsible for over two hundred systems on his own. According to this report, that would require well over 6000 "hours per year of support effort", despite the fact that he works well under 2000 hours a year (40 hour week minus paid time off) and that's far from all "support effort".
I wonder what percentage of IT workers even has a CS degree is.
The rest of Old SCO is now Tarantella, I believe.
Which was just bought by Sun.
$112 is "around $100". As I reiterarted, I was comparing pricing on motherboard, case, and processor; not complete systems. And it turns out the Asus system I quoted includes the case, floppy, and cdrom for near the price I gave in the original post.
As for the rest, you don't need to go mini-itx to go Via. If we want to make that a requirement of the comparison, you can forget the "cheap" (over $200) Pentium M board I used in the prior comparison, and start looking at boards that starting at around $325.
On the Via side, you can get pretty damn cheap including the board, case, cpu, and power supploy. Looking at iDOTpc, they range from $199 (EPIA 5000, 533MHz fanless) to $324.00 (EPIA MII 12000, 1.2GHz). Still cheaper than just the motherboard for the Intel solution.
It's really a matter of what you're priorities are. The "bottom of the barrel" system I quoted is from a reputable manufacturer (Asus) using Via's own north and south bridge sets. Given that virtually all Via solutions use the integrated peripherals are comparable to the more expensive bretheren. So really, it's only bottom of the barrel if the 800Mhz cpu and 266Mhz FSB aren't fast enough. For a lot of people, they are.
Maybe I'm in the wrong corner of the world on this one, but I think Red Hat is the distribution becoming less and less relevant.
Last quarterly result from Novell states $26,314,000 in revenue from new software licenses in the "Linux and Platform Services" segment. Last quarterly result from Red Hat states $45,393,000 in Enterprise subscriptions.
Somehow I think they're still a teeny bit relevent. And considering their year over year increase in subscription revenue was 120% from last year, I'd say they're not about to fade away.
The biggest threat Red Hat faces right now is that IBM could settle with SCO and then release its own Linux along with workstations and servers based on the Cell processor.
IBM doesn't need to settle with SCO to release it's own version of Linux. All it needs to do is... release it's own version of Linux. Hell, they could download RHEL, rebuild, rebadge, and sell that.
Given that Cell outperforms x86 by an order of magnitude and doesn't have the security weaknesses built into the x86, this would leave them fighting to hold an ever decreasing share of a shrinking market.
What insightful commentary. Anyone who seriously believes the Cell processor outperforms conventional architectures by "an order of magnitude" for anything but specialized tasks needs to lay off the crack pipe. That big impressing 256 GFlop figure that's been bandied around is the theoretical "if you fill every pipeline" number, is almost entirely comprised of FP operations (guess what - most business servers aren't busy rendering pretty pictures), and is for a single precision pipeline which rounds in a non-standard way.
Know what the performance hit is for IEEE854 double precision FP? A full order of magnitude. There goes all that theoretical performance, and you lose the benefit of the industry dominant instruction set, and gain a whole set of programming peculiarities of the new architecture, such as the lack of a branch prediction unit even in the PPC core.
I said "around $100" for "board, chip, case, and integrated everything - video, tv out, firewire, ethernet", which is about right. The price I quoted for the Intel solution was board and chip only as well (and even that's still $100 more than a Via system).
And no, I would certainly not recommend a Via for heavy number crunching, but I did say there were serving entirely different market segments than Intel - named low cost, low power desktop solutions and embedded solutions. Typically these segments aren't called on for heavy number crunching, especially with acceleration of encryption features on-die, and MPEG-2/4 being accelerated by the north bridge.
"MOD THIS UP INSIGHTFUL!!!! by Anonymous Coward Wednesday February 30, @09:34AM"
That is so incredibly lame, I can't even find the words.
O'Gara is editor-in-chief of "LinuxGram", which isn't surprising since she's the founder of G2 Computer Intelligence, the publisher of that periodical. That has no official affiliaction with LinuxWorld or Sys Con.
To be fair, she wasn't fired by Sys Con, since she has never held a position there. Use of the term was meant to contrast with the allegation of censorship, rather than be a precise description of the business relationship.
She wasn't fired - not censored, fired - for her opinion. She was fired for producing a particularly odious example of yellow journalism and stepping over the line with a gross violation of privacy. One which may well be legally actionable.
In the case of peanut butter, it's not just the economies of scale. If you look at the ingredients you'll see the peanut oil has been replaced largely by cheaper oils - often rape seed, soy bean, or cotton seed. Cotton seed, in particular, is a favourite of bargain brands because it's very cheap, since it's essentially a waste product of cotton production and fares poorly as an independently marketed product due to it's saturated fat content (higher than any other common oils aside from tropical sources such as palm or coconut).
On top of that, the added oils are hydrogenated. Aside from avoiding the seperation seen in natural peanut butters, this also extends shelf life, which also drives costs down.